O portão HITL garante que nenhuma ação de agente de alto risco prossiga sem julgamento humano. Este cookbook percorre o ciclo de vida completo de aprovação — desde o momento em que uma ação governada dispara um pedido através da resolução de nível de risco, decisões humanas e a válvula de escape break-glass — para que possa rastrear cada parte movel antes de a encontrar em produção.
Se ainda não leu o modelo de autorização, comece com Governança. O guia Governar e aprovar cobre a mesma maquinaria de uma perspetiva de operador; esta página e a referência passo a passo.
O ciclo de vida do pedido
Um pedido de aprovação abre deny-closed e com limite temporal. Começa pending, transporta uma
expiracao e não autoriza nada até que humanos suficientes o tenham decidido. O pedido não pode
baixar a sua própria fasquia — uma política de aprovação correspondente e autoritativa para o limiar e
prazos.
O pedido e vinculado a um hash de plano do payload exato da chamada de ferramenta. Esta e a defesa anti-TOCTOU: se a ação subjacente muda entre o pedido e a decisão, o hash não correspondera e a aprovação não pode vincular. Uma aprovação obsoleta nunca autoriza uma ação diferente.
Resolução de nível de risco
Quatro níveis conduzem quanto controlo humano uma ação governada requer:
| Nível | O que significa |
|---|---|
low / medium | Atribuído apenas por política de aprovação explicita — nada predefinido aqui |
high | O predefinido para qualquer coisa que chegue a fila de aprovação. Requer uma aprovação humana |
critical | Piso obrigatório de duas pessoas (NIST SP 800-53 AC-3(2) autorização dupla) |
O nível e re-derivado do conjunto de políticas ativo a cada decisão, nunca lido de um snapshot armazenado. Uma mudança de política tem efeito imediato. Uma linha obsoleta nunca pode manter a fasquia abaixo da classificação atual — isto é deny-closed por construção.
O conjunto critical incorporado cobre o genuinamente irreversivel: implantação e retirada em produção,
eliminação e apagamento de dados, aplicação de segurança e alterações de kill-switch, custódia
e rotação de chaves, e desligamento de NHI.
Uma política de aprovação com um risk_tier explicito pode elevar ou baixar o predefinido por ação.
Mas nunca pode baixar uma ação critical abaixo do piso de duplo controlo.
Passo a passo
1. Uma ação governada aciona um pedido
Uma ação governada — deploy apply, agent fire, sobreposição de orçamento, ou qualquer ação que corresponda a uma
política de aprovação — chega ao motor de aprovação. O motor abre um novo pedido no estado pending.
2. O pedido vincula-se a um hash de plano
O pedido regista um hash do payload exato da chamada de ferramenta. Esta vinculação a hash de plano e a defesa TOCTOU: a decisão só autorizara a ação para a qual o pedido foi criado.
3. O nível de risco resolve a partir da política atual
O motor avalia o conjunto de políticas ativo (RBAC, ABAC nativo e qualquer PDP externo) para derivar o nível de risco. O nível nunca e guardado de uma avaliação anterior.
4. Um revisor humano decide
Um humano com papel suficiente emite um approve ou deny. O servidor aplica três
invariantes neste ponto, baseados na identidade estavel do utilizador:
- Separação de deveres. O requerente não pode decidir o seu próprio pedido. Baseia-se na identidade estavel do utilizador, não na string de credencial que uma única pessoa poderia variar.
- Guarda de decisor duplicado. Um índice único protege contra uma corrida de decisor duplicado — um humano conta uma vez para o limiar.
- A expiracao vincula. Um pedido expirado nunca pode receber uma decisão vinculante, mesmo antes de uma varredura materializar a expiracao. O estado efetivo e re-derivado a cada decisão.
5. Ações críticas: duplo controlo com AAL3
Para o nível critical: o limiar tem piso de dois aprovadores humanos distintos. O
piso e aplicado tanto na criacao (o limiar armazenado nunca pode começar abaixo de dois) como
re-aplicado na decisão (um pedido criado antes de a ação se tornar crítica ainda não pode
passar com um humano).
Cada humano decisor deve ter uma sessão verificada por hardware — elevação por WebAuthn ou PIV (AAL3). Um token de sistema não transporta garantia humana e e recusado.
6. A decisão regista no registo
Cada decisão adiciona uma linha imutável a trilha de decisões do pedido e um evento de registo que regista a decisão, o estado resultante e o nível de risco sob o qual foi tomada. O registo e apenas adicao, encadeado por hash e assinado com Ed25519 — reescrever a historia e criptograficamente detetável.
Expiracao
A expiracao e derivada na leitura, não escrita uma vez. Um pedido expirado nunca pode receber uma decisão vinculante mesmo que nenhuma varredura em segundo plano tenha materializado a expiracao ainda. O estado efetivo e sempre re-derivado, portanto uma varredura lenta e um atraso cosmetico, não uma falha de segurança.
Configuração de políticas
As políticas de aprovação permitem sobrepor o nível de risco predefinido por classe de ação. Uma política com um
risk_tier explicito pode mover uma ação de high para low, ou elevar um medium para
critical. A única restrição: nunca pode baixar critical abaixo do piso de duplo controlo. O requisito de duas pessoas para ações irreversiveis e estrutural, não
configurável.
Break-glass
Quando um quorum e inalcançável — o incidente das 03:00 onde o segundo aprovador esta a dormir — o break-glass fornece uma válvula de escape auditada. E ruidoso por construção.
A ativação requer tudo isto:
- O ativador e um admin, sempre um humano real — um token de sistema e recusado.
- Uma elevação AAL3 fresca (WebAuthn ou PIV).
- Uma justificacao escrita registada na mesma transacao.
- Uma sessão ativamente gravada como pre-condicao.
Limite temporal: a concessão predefinida e de uma hora, com máximo rígido de 24. Uma emergência que precisa de mais tempo e um modo operacional, não uma emergência, e deve passar pelo duplo controlo normal.
Cada utilizacao e registada. Cada ação tomada sob break-glass adiciona uma linha imutável e um evento de registo nomeando a concessão, a ação e o sujeito. Uma ação que prosseguiu sob break-glass e permanentemente distinguivel de uma devidamente aprovada.
Revisão pos-facto obrigatória. Uma nova concessão não pode ser ativada enquanto qualquer concessão anterior esteja por rever. A revisão deve vir de um humano diferente do ativador. Não pode acumular emergencias para fugir ao escrutinio.
O break-glass relaxa um quorum em falta; nunca sobrepoe uma rejeição explicita. Um pedido que alguém deliberadamente negou permanece negado.
O que é registado
Cada decisão — aprovar, negar, expirar ou uso de break-glass — adiciona a dois locais:
- A trilha de decisões do pedido: uma sequência imutável de linhas de decisão no próprio pedido, cada uma transportando o decisor, o veredicto e o timestamp.
- O registo de auditoria: um evento encadeado por hash, assinado com Ed25519 que regista a decisão, o estado resultante do pedido e o nível de risco sob o qual foi tomada.
Ambas as escritas acontecem na mesma transacao que a mudança de estado. Não pode tomar uma decisão governada que o registo silenciosamente esqueca.
Relacionado
- Governar e aprovar — o guia de operador que cobre a mesma maquinaria.
- Governança — o modelo de autorização, postura de auto-auditoria e mecanica do kill-switch.
- Cookbook: exercício de kill-switch — o exercício do portão de negação de todo o ambiente.
- Kill switch — a página de produto para a paragem de emergência.