Saltar para o conteúdo principal
Você já tem uma política de firewall em que confia em staging, e quer uma segunda para produção com duas regras mudadas — ou quer apertar a política ao vivo sem perder o controle do que mudou. Ambos são movimentos de ciclo de vida de política: levante uma segunda política como ponto de partida, e apoie-se na version que incrementa a cada update para saber que sua mudança se propagou. Esta página é a referência de ciclo de vida — ramificar, versionar, padrão e habilitar/desabilitar/deletar. Para configuração de primeira vez veja Criar e vincular; para a gramática de regras veja Regras do Firewall.
Todo o gerenciamento de política acontece no console (ou nas rotas de gerenciamento /api/workspace/firewall/*, que autenticam com sua sessão / token de acesso — não uma chave de relay sk-orca-…). Apenas as chamadas /v1/* do seu agente usam a chave de relay. Criar, editar e tornar padrão uma política são ações Developer+; ler a lista de políticas e sua version é aberto a cada Member.

​
1. Ramifique sua postura em uma segunda política

Não há um veredito de “fork” ou botão de cópia — um nome de política é único por workspace, então o padrão é levantar uma segunda política versionada independentemente e divergi-la livremente sem tocar na original. Duas maneiras de semeá-la:
1

Crie a nova política, depois crie suas regras

Abra Security → Firewall → Policies → New policy. Uma nova política é criada com nenhuma regra e seu default_verdict escolhido — crie suas regras no editor (ou copie algumas da política de origem à mão). Dê a ela um nome único no workspace (ex.: prod-firewall ao lado de staging-firewall).
2

Ou aplique um template de caso de uso

A galeria de Templates (POST /api/workspace/firewall/templates/apply) cria uma nova política mais todas as suas regras em uma única transação — Coding, Support, RAG, Data, DevOps, Browser ou Baseline. Mais rápido que criar à mão quando um template combina.
3

Diverja e vincule

Edite as regras da nova política — aperte o deny de shell destrutivo, troque um host de allow-list de egress — depois vincule-a à chave de produção via firewall_policy_id, ou marque-a como padrão do workspace. A política de origem fica intocada.
Uma segunda política é a maneira segura de testar uma postura mais arriscada. Levante uma, ligue o shadow mode nela, vincule-a a uma chave canária, e observe o feed de events — a política de produção em cada outra chave continua aplicando inalterada.
Cada política carrega sua própria proveniência, sua própria contagem de chaves-vinculadas e sua própria linha de version.

​
2. A version que incrementa a cada update

Cada política de firewall tem um inteiro version. Ele começa em 1 quando a política é criada e incrementa em um a cada update — uma edição de regra, uma mudança de veredito padrão, um toggle de habilitar/desabilitar, uma virada de shadow-mode. É monotônico e nunca reseta. 
// 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
}
A version é seu sinal de propagação: o gateway cacheia políticas resolvidas brevemente, e cada save invalida esse cache para que sua edição entre em vigor nas chaves vinculadas em segundos — sem redeploy, sem mudança no código do agente. A version não conduz o cache; é um contador de mudanças monotônico que você lê de volta. Quando você salva uma política e quer confirmar que a mudança está ao vivo, releia a política e verifique que a version avançou.
A version da política é um contador de mudanças, não um ponto de restauração. Ela diz a você que a política mudou e deixa o gateway propagar a edição — não é um diff por versão ou rollback. Para histórico versionado com diff e revert em um clique, essa capacidade vive nos Guardrails: GET /api/guardrail/:id/history, …/history/diff, e POST /api/guardrail/:id/revert (revert é Developer+). Para políticas de firewall, sua trilha de auditoria e manter uma política rebaixada-mas-conhecida-boa na lista são como você preserva um ponto de restauração — veja §5.

​
3. Defina e mova o padrão do workspace

Um workspace pode marcar uma política como o padrão. Cada chave sem seu próprio firewall_policy_id resolve para ela (ordem de resolução).
  • Edite uma política e defina-a como padrão do workspace. Promover um novo padrão rebaixa o antigo na mesma transação — nunca há uma janela com dois padrões, e nunca uma janela com nenhum no meio da troca.
  • Levantar uma segunda política é uma forma limpa de avançar o padrão: construa a nova política, ajuste, valide sob shadow mode, depois promova-a. O padrão antigo permanece na lista, rebaixado, como seu fallback.
Mover o padrão muda o enforcement para cada chave não vinculada de uma vez. Se o novo padrão aperta o default_verdict para deny, as chamadas que suas regras não permitem explicitamente começam a bloquear imediatamente. Faça o rollout de um novo padrão atrás de shadow mode e observe Events antes de promovê-lo.

​
4. Habilite, desabilite e delete

Alternar Enabled para desligado impede uma política de resolver. Mas lembre-se do fall-through do firewall: uma chave cuja política vinculada está desabilitada cai de volta para o padrão do workspace — desabilitar não tira a chave do escopo do firewall. Para remover uma chave do enforcement, desvincule-a (defina firewall_policy_id como 0), não apenas desabilite sua política. (Isso difere dos guardrails, onde um vínculo desabilitado resolve para nenhum.)
DELETE /api/workspace/firewall/policies/:id (Developer+) remove uma política — mas retorna 409 se qualquer chave ainda a referenciar. Desvincule ou re-aponte essas chaves primeiro, depois delete. Essa proteção é por que levantar uma segunda política, e não reescrever no lugar, é a forma mais segura de evoluir uma política da qual chaves ao vivo dependem.
Um nome de política é único dentro de um workspace, então uma segunda política precisa de um novo nome. Use uma convenção que sobrevive ao ciclo de vida — staging-firewall / prod-firewall, ou um sufixo de data — em vez de policy-copy-2.

​
5. Trilha de auditoria

Cada criação, update (que inclui uma promoção-de-padrão ou uma virada de shadow-mode) e deleção de política escreve uma linha de auditoria — tanto uma linha de workspace quanto uma linha central de admin — depois que a mudança é commitada. Um save falho (nome duplicado, veredito inválido) não escreve nada. Os blobs de regra e segredos nunca são escritos no log de auditoria. Então mesmo que as políticas de firewall não carreguem um histórico de diff-e-revert próprio, a trilha de auditoria diz a você quem mudou qual política, quando, e a version monotônica diz a você quantas vezes ela mudou. Combine isso com manter uma política rebaixada-mas-conhecida-boa na lista, e você tem um caminho de restauração prático.

​
6. Ciclo de vida em resumo

AçãoRotaPapel
Listar políticas (+ version, contagens)GET /api/workspace/firewall/policiesMember
Ler uma políticaGET /api/workspace/firewall/policies/:idMember
Criar política (sem regras)POST /api/workspace/firewall/policiesDeveloper+
Aplicar um template (política + regras)POST /api/workspace/firewall/templates/applyDeveloper+
Update (incrementa version)PUT /api/workspace/firewall/policiesDeveloper+
Delete (409 se chaves vinculadas)DELETE /api/workspace/firewall/policies/:idDeveloper+
Antes de depender de uma política nova ou recém-promovida, faça dry-run dela na aba sandbox Test — ela retorna o veredito, a regra correspondente e o motivo sem despachar nada. Veja Testar regras.

​
Para onde ir a seguir

Criar e vincular

O caminho de configuração de primeira vez — crie uma política e aponte uma chave para ela.

Shadow mode

Faça o rollout de uma política nova ou re-tornada-padrão sem mudar o tráfego ao vivo.

Firewall + Guardrails

Como políticas de ação se compõem com guardrails de texto — e onde o revert versionado vive.

Escopo: chaves, políticas, workspaces

Como o vínculo e o padrão do workspace resolvem.