Vai al contenuto principale
Hai già una policy del firewall di cui ti fidi in staging, e ne vuoi una seconda per la produzione con due regole cambiate — oppure vuoi irrigidire la policy live senza perdere traccia di cosa è cambiato. Entrambe sono mosse di ciclo di vita della policy: allestisci una seconda policy come punto di partenza, e fai affidamento sulla version che si incrementa a ogni update per sapere che la tua modifica si è propagata. Questa pagina è il riferimento del ciclo di vita — diramare, version, default e abilita/disabilita/elimina. Per la configurazione iniziale vedi Crea e collega; per la grammatica delle regole vedi Regole del Firewall.
Tutta la gestione delle policy avviene nella console (o nelle rotte di gestione /api/workspace/firewall/*, che si autenticano con la tua sessione / token di accesso — non una chiave di relay sk-orca-…). Solo le chiamate /v1/* del tuo agent usano la chiave di relay. Creare, modificare e impostare come default una policy sono azioni Developer+; leggere l’elenco delle policy e la sua version è aperto a ogni Member.

​
1. Dirama la tua postura in una seconda policy

Non c’è alcun verdetto “fork” o pulsante di copia — un nome di policy è univoco per workspace, quindi il pattern è allestire una seconda policy versionata indipendentemente e farla divergere liberamente senza toccare l’originale. Due modi per seminarla:
1

Crea la nuova policy, poi scrivi le sue regole

Apri Security → Firewall → Policies → New policy. Una nuova policy viene creata con nessuna regola e il tuo default_verdict scelto — scrivi le sue regole nell’editor (o copiane alcune dalla policy sorgente a mano). Dalle un nome univoco nel workspace (es. prod-firewall accanto a staging-firewall).
2

O applica un template di caso d'uso

La galleria Templates (POST /api/workspace/firewall/templates/apply) crea una nuova policy più tutte le sue regole in una singola transazione — Coding, Support, RAG, Data, DevOps, Browser o Baseline. Più veloce della scrittura a mano quando un template corrisponde.
3

Diverge e collega

Modifica le regole della nuova policy — irrigidisci il deny della shell distruttiva, sostituisci un host della allow-list di egress — poi collegala alla chiave di produzione tramite firewall_policy_id, o marcala come default del workspace. La policy sorgente è intatta.
Una seconda policy è il modo sicuro per testare una postura più rischiosa. Allestine una, attiva la shadow mode su di essa, collegala a un’unica chiave canary, e osserva il feed degli eventi — la policy di produzione su ogni altra chiave continua ad applicare invariata.
Ogni policy porta la propria provenienza, il proprio conteggio di chiavi collegate e la propria linea di version.

​
2. La version che si incrementa a ogni update

Ogni policy del firewall ha un intero version. Parte da 1 quando la policy è creata e si incrementa di uno a ogni update — una modifica di regola, un cambio di verdetto di default, un toggle di abilita/disabilita, un cambio di shadow-mode. È monotono e non si resetta mai. 
// GET /api/workspace/firewall/policies/:id  → (abridged)
{
  "id": 42,
  "name": "prod-firewall",
  "enabled": true,
  "is_default": true,
  "default_verdict": "audit",
  "shadow_mode": false,
  "version": 7,          // bumped from 6 → 7 by your last save
  "rule_count": 11,
  "attached_key_count": 3
}
La version è il tuo segnale di propagazione: il gateway mette brevemente in cache le policy risolte, e ogni salvataggio invalida quella cache così la tua modifica ha effetto sulle chiavi collegate entro pochi secondi — nessun redeploy, nessuna modifica al codice dell’agent. La version non guida la cache; è un contatore di modifiche monotono che rileggi. Quando salvi una policy e vuoi confermare che la modifica è live, rileggi la policy e controlla che version sia avanzato.
La version della policy è un contatore di modifiche, non un punto di ripristino. Ti dice che la policy è cambiata e permette al gateway di propagare la modifica — non è un diff o un rollback per versione. Per una storia versionata completa con diff e revert a un clic, quella capability vive sui Guardrails: GET /api/guardrail/:id/history, …/history/diff e POST /api/guardrail/:id/revert (il revert è Developer+). Per le policy del firewall, la tua traccia di audit e il mantenere una policy known-good declassata nell’elenco sono come preservi un punto di ripristino — vedi §5.

​
3. Imposta e sposta il default del workspace

Un workspace può marcare una policy come default. Ogni chiave senza il proprio firewall_policy_id si risolve su di essa (ordine di risoluzione).
  • Modifica una policy e impostala come default del workspace. Promuovere un nuovo default declassa il vecchio nella stessa transazione — non c’è mai una finestra con due default, e mai una finestra con nessuno a metà scambio.
  • Allestire una seconda policy è un modo pulito per far avanzare il default: costruisci la nuova policy, regola, valida sotto shadow mode, poi promuovila. Il vecchio default rimane nell’elenco, declassato, come tuo fallback.
Spostare il default cambia l’applicazione per ogni chiave non collegata in una volta. Se il nuovo default irrigidisce il default_verdict a deny, le chiamate che le tue regole non consentono esplicitamente iniziano a bloccarsi immediatamente. Fai il rollout di un nuovo default dietro la shadow mode e osserva Events prima di promuoverlo.

​
4. Abilita, disabilita ed elimina

Disattivare Enabled impedisce a una policy di risolversi. Ma ricorda il fall-through del firewall: una chiave la cui policy collegata è disabilitata ricade sul default del workspace — disabilitare non toglie la chiave dallo scope del firewall. Per rimuovere una chiave dall’applicazione, scollegala (imposta firewall_policy_id a 0), non limitarti a disabilitare la sua policy. (Questo differisce dai guardrails, dove un collegamento disabilitato si risolve in nessuno.)
DELETE /api/workspace/firewall/policies/:id (Developer+) rimuove una policy — ma restituisce 409 se una qualsiasi chiave la referenzia ancora. Scollega o ri-punta quelle chiavi prima, poi elimina. Questa guardia è il motivo per cui allestire una seconda policy, anziché riscrivere sul posto, è il modo più sicuro per evolvere una policy da cui dipendono chiavi live.
Un nome di policy è univoco all’interno di un workspace, quindi una seconda policy ha bisogno di un nuovo nome. Usa una convenzione che sopravvive al ciclo di vita — staging-firewall / prod-firewall, o un suffisso di data — anziché policy-copy-2.

​
5. Traccia di audit

Ogni creazione, update (che include una promozione a default o un cambio di shadow-mode) ed eliminazione di policy scrive una riga di audit — sia una riga del workspace sia una riga admin centrale — dopo il commit della modifica. Un salvataggio fallito (nome duplicato, verdetto invalido) non scrive nulla. I blob delle regole e i segreti non vengono mai scritti nel log di audit. Quindi, anche se le policy del firewall non portano una storia di diff-e-revert propria, la traccia di audit ti dice chi ha cambiato quale policy, quando, e la version monotona ti dice quante volte è cambiata. Abbinalo al mantenere una policy known-good declassata nell’elenco, e hai un percorso di ripristino pratico.

​
6. Ciclo di vita in breve

AzioneRottaRuolo
Elencare le policy (+ version, conteggi)GET /api/workspace/firewall/policiesMember
Leggere una policyGET /api/workspace/firewall/policies/:idMember
Creare una policy (senza regole)POST /api/workspace/firewall/policiesDeveloper+
Applicare un template (policy + regole)POST /api/workspace/firewall/templates/applyDeveloper+
Update (incrementa version)PUT /api/workspace/firewall/policiesDeveloper+
Eliminare (409 se ci sono chiavi collegate)DELETE /api/workspace/firewall/policies/:idDeveloper+
Prima di fare affidamento su una policy nuova o appena promossa, eseguine un dry-run nella scheda sandbox Test — restituisce il verdetto, la regola corrispondente e la motivazione senza dispatchare nulla. Vedi Testa le regole.

​
Dove andare dopo

Crea e collega

Il percorso di configurazione iniziale — crea una policy e puntale una chiave.

Shadow mode

Fai il rollout di una policy nuova o ri-defaultata senza modificare il traffico live.

Firewall + Guardrails

Come le policy di azione si compongono con i guardrail di testo — e dove vive il revert versionato.

Scope: chiavi, policy, workspace

Come si risolvono il collegamento e il default del workspace.