Cookbook: exercício de kill-switch

O kill switch e o portão de negação de todo o ambiente. Ativa-lo e deliberadamente barato — nível admin, sem quorum — porque uma paragem que espera consenso não e uma paragem. Reativar e deliberadamente caro: duplo controlo, sem break-glass. Não vai querer descobrir uma lacuna em nenhuma das direcoes as 03:00.

Um exercício num inquilino de não-produção e a única forma segura de provar que o portão de paragem nega cada ponto de atuação, que as aprovações pendentes são canceladas atomicamente, e que a reativação realmente requer dois humanos distintos. Execute-o antes de precisar dele.

Pre-requisitos

• Um inquilino de não-produção. O exercício ativa uma paragem real de todo o ambiente. Execute-o contra staging ou dev, nunca produção.
• Três utilizadores humanos no mínimo. (1) Um ativador de nível admin; (2) dois aprovadores de reativação distintos (editor ou superior) que satisfacam o piso de duplo controlo critical; (3) um pos-revisor não envolvido (editor ou superior) que feche a pos-revisão obrigatória. O pos-revisor pode sobrepor-se a um aprovador se não for o ativador.
• Uma lista de pontos de atuação governados para testar — deploy apply, orchestration fire, voice open, model execution, budget spend, mais quaisquer superficies personalizadas que tenha ligado.

Passo 1: Ativar o kill switch

O ativador aciona o kill switch com uma string de razao obrigatória:

# A chamada API — substitua o seu host, porta e cabecalho de autorizacao.
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

Ativar e deliberadamente barato: nível admin, uma razao, sem quorum de aprovação, sem elevação, sem break-glass. A linha de paragem torna-se a única fonte de verdade. Cada portão de atuação governado consulta-a ao vivo em cada ação e falha fechado num erro de leitura.

Na mesma transacao que a ativação, cada aprovação de atuação pendente dentro do escopo e cancelada — uma intencao pre-paragem não pode amadurecer numa concessão no momento em que o ambiente volta. Anote o timestamp; verificara o registo para isto mais tarde.

Passo 2: Verificar negação

Com o kill switch ativado, tente cada atuação governada que o seu ambiente tem ligada. Cada uma deve retornar negada.

Pontos de atuação a testar:

Teste cada ponto que o seu ambiente tem provisionado. Se tem superficies de atuação personalizadas ligadas através do núcleo de governança, inclua-as também.

Verifique também o que deve continuar a funcionar:

A paragem interrompe o ambiente agentivo, nunca os controlos que o governam. As ações de governança permanecem disponíveis:

• Ler o mapa de acesso — GET /v1/access-map deve retornar normalmente.
• Ver o registo de auditoria — GET /v1/audit/export deve retornar o registo, incluindo o evento de ativação que acabou de criar.
• Listar aprovações — a fila de aprovação e legível; as aprovações previamente pendentes devem aparecer como canceladas.

Se qualquer ponto de atuação retornar algo diferente de negado, ou se qualquer ação de governança estiver bloqueada, pare o exercício e investigue. O kill switch tem uma lacuna.

Passo 3: Reativar o ambiente

Reativar nunca e unilateral. Requer uma aprovação de duplo controlo fresca no nível critical: dois humanos distintos, re-verificados estruturalmente na mudança. Há deliberadamente nenhum caminho de break-glass para reativar — “o ambiente permanece parado” e o estado seguro.

O ativador (ou qualquer admin) pede a reativação:

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

Isto cria um pedido de aprovação de nível critical. Dois aprovadores — cada um humano distinto, nenhum usando um token de sistema — devem cada um aprova-lo via POST /v1/approvals/<request-id>/decide com {"decision": "approve"}. O piso de duplo controlo e aplicado do lado do servidor: a guarda de decisor duplicado impede uma pessoa de contar duas vezes, e um token de sistema e recusado (sem garantia humana). Mesmo que o nível de política seja rebaixado, o piso estrutural mantém-se — uma ação critical não pode passar com um aprovador. Quando ambas as aprovações chegam, o ambiente e reativado.

Passo 4: Verificar restauração

Repita cada tentativa de atuação do Passo 2. Cada uma deve agora ter sucesso (permitida, ou encaminhada para o fluxo de aprovação normal). Se algum ponto permanece negado após a reativação, a reativação não se propagou totalmente — investigue antes de dar o exercício como concluido.

Passo 5: Fechar a pos-revisão

Uma pos-revisão obrigatória por um humano não envolvido e estruturalmente necessária antes que outra ativação de kill-switch possa ocorrer. O revisor deve ser alguém que não foi o ativador:

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

Até que esta revisão seja fechada, uma ativação subsequente de kill-switch esta bloqueada. Isto é por design — não pode acumular ativações para fugir ao escrutinio.

O que verificar no registo

Após o exercício, exporte o registo de auditoria e verifique a trilha completa:

olivares audit export --format json --since <drill-start-timestamp>

O registo deve conter, por ordem:

1. Evento de ativação — o admin, a razao (“scheduled quarterly drill”), o timestamp e o nível de garantia da sessão de ativação.
2. Cancelamentos de aprovação — cada aprovação pendente dentro do escopo que foi cancelada na mesma transacao que a ativação.
3. Eventos de negação — um para cada tentativa de atuação que foi recusada durante a paragem.
4. Pedido de reativação — o pedido de aprovação no nível critical.
5. Duas decisões de aprovação — uma por aprovador, cada uma nomeando a identidade humana distinta.
6. Evento de reativação — o ambiente restaurado.
7. Evento de pos-revisão — o revisor não envolvido, as suas notas, o timestamp de encerramento.

Cada registo transporta os campos de integridade de cadeia (seq, prev_hash, hash, sig). Uma entrada em falta ou fora de ordem significa que o registo tem uma lacuna — investigue antes de confiar nele num incidente real.

Frequência

Execute o exercício trimestralmente. O kill switch e a última linha de defesa; se tem uma lacuna quer encontra-la numa janela programada, não durante um incidente. Adicione o exercício ao seu calendário operacional juntamente com outros exercícios de continuidade (restauração de backup, failover, ativação de break-glass).

Se o seu ambiente muda materialmente — novos pontos de atuação ligados, novos inquilinos provisionados, motor de políticas trocado — execute um exercício não programado para cobrir a nova superficie.

Relacionado

• Governança — o modelo de autorização, níveis de risco e design do kill-switch.
• Kill switch — o portão de negação de todo o ambiente em termos de produto.
• Governar e aprovar — o fluxo de aprovação ao vivo e mecanica de duplo controlo.