Break-glass testável: acesso de emergência sem improviso

O acesso de emergência é a decisão que separa uma interrupção controlada de uma madrugada de improviso: quando o provedor de identidade cai, o segundo fator dos administradores falha em bloco ou o cluster perde o quórum do etcd, a equipe precisa entrar, decidir e restaurar com credenciais que já existiam, já funcionavam e já estavam sob alerta. Este guia monta essa camada em três frentes — estado do cluster, credenciais reservadas e rastro de auditoria — com base na documentação primária do Kubernetes, da AWS e da Microsoft, e termina com o ciclo de ensaio que transforma o plano em evidência verificável.

O problema do acesso improvisado

Break-glass é o mecanismo que libera privilégio máximo fora do fluxo normal de acesso quando esse fluxo deixou de funcionar. O erro comum é tratá-lo como uma senha guardada em um cofre e nunca mais testada: na hora do incidente, descobre-se que a credencial expirou, que a política de acesso condicional bloqueia justamente a conta reservada ou que ninguém sabe quem tem autoridade para abrir o envelope. A consequência aparece em RTO estourado — o tempo para restaurar o serviço cresce não pela falta de backup, mas pela incapacidade de alcançá-lo.

Antes de desenhar a solução, fixe as metas da própria camada de emergência. O RPO aqui é o intervalo aceitável entre o último backup testado e o momento da crise; o RTO é o tempo entre a decisão de acionar o break-glass e o primeiro comando administrativo executado. Se esses dois números não estão escritos e acordados com o negócio, o plano não existe — existe a intenção de um plano.

O backup que sustenta tudo

No Kubernetes, o etcd guarda todo o estado do cluster: objetos, segredos, configurações e o histórico que o plano de controle consulta para decidir o que executa. A documentação oficial do projeto descreve o etcd como um repositório chave-valor consistente e de alta disponibilidade que serve de armazenamento para todos os dados do cluster, e recomenda fazer backup antes de qualquer upgrade. Quando a maioria dos membros do etcd falha de forma permanente, o cluster é considerado perdido do ponto de vista de controle: pods continuam rodando, mas nada novo é escalonado até a restauração do snapshot.

O snapshot do etcd é rápido e barato; o que quase ninguém tem é a restauração ensaiada. Um ciclo mínimo inclui: disparo agendado do snapshot com etcdctl snapshot save, verificação de integridade com etcdutl snapshot status, cópia da mídia para um destino separado do cluster — em outra conta e com retenção imutável, para que o mesmo comprometimento que derrubou o ambiente não consiga apagar a cópia — e um restore executado em ambiente de teste a cada ciclo. A cópia que nunca foi restaurada é uma hipótese, não um backup.

Em clusters gerenciados, onde o etcd é invisível, a responsabilidade muda de ferramenta, não de obrigação: a documentação do provedor passa a ser a fonte primária do que entra no backup do plano de controle e do que exige solução própria — volumes persistentes, objetos externos e segredos de aplicação frequentemente precisam de camada complementar. Registre em qual documento do provedor essa fronteira está descrita; é a evidência que a auditoria vai pedir quando perguntarem se a recuperação foi planejada ou descoberta na hora.

Credenciais reservadas, fora do fluxo

A segunda frente é identidade. A AWS recomenda configurar o acesso de emergência ao console antes de qualquer interrupção, porque a janela para criar o acesso já fechou quando a pane começa: sem permissão para criar os papéis IAM necessários, a organização fica do lado de fora do próprio console. A mesma lógica vale para qualquer provedor de identidade: o caminho alternativo precisa existir, com papéis e permissões mínimas definidas, antes do dia em que o caminho principal falha.

As contas reservadas seguem regras próprias: não pertencem a nenhuma pessoa, não sincronizam com diretório federado, usam método de autenticação diferente do administrativo cotidiano — se o dia a dia usa aplicativo de autenticação, a reserva usa chave de segurança de hardware — e ficam guardadas em cofre físico ou lógico com custódia registrada. Como essas credenciais contornam os controles normais por desenho, a rotação de chaves precisa alcançá-las também: a chave que abre a porta dos fundos não pode ser a mesma há anos.

O ponto que mais falha em produção é a exclusão da conta reservada das políticas de acesso que bloqueiam login. Uma política que exige dispositivo compatível ou rede corporativa vai negar exatamente a credencial desenhada para o cenário em que essas condições não existem. A conta reservada deve ficar em grupo próprio, excluído das políticas restritivas, e essa exclusão precisa estar documentada como decisão de risco assinada por alguém com autoridade — não como acidente de configuração que ninguém revisa.

Alerta e rastro em cada uso

Credencial que ninguém observa é porta aberta silenciosa. No guia de DevOps da AWS, todo uso de papel break-glass precisa disparar alerta e alarme imediatos, amarrados aos procedimentos de resposta e recuperação. Na prática, isso significa regra de detecção dedicada: qualquer login dessas contas abre um chamado automático, notifica a equipe de segurança e inicia o relógio da revisão pós-uso.

O log dessa camada também é evidência de governança. Normalizar os eventos no SIEM antes de escrever as regras evita o falso positivo crônico que leva a equipe a silenciar o alerta — o pior resultado possível para um detector cujo valor é disparar talvez uma vez por ano. Cada uso legítimo gera revisão pós-mortem: o que foi feito, por quem, com qual autorização e quando as credenciais retornaram ao cofre com registro assinado.

Ensaio periódico com evidência

A régua do ciclo vem da documentação de identidade: as diretrizes da Microsoft para contas de acesso de emergência do Entra ID determinam validar a funcionalidade dessas contas pelo menos a cada 90 dias, incluindo a capacidade de entrar e executar tarefas administrativas. O ensaio precisa cobrir o caminho inteiro, não só a senha: abrir o cofre, autenticar na estação reservada, executar a ação mínima prevista no runbook, verificar se o alerta disparou no SIEM e devolver a credencial com o termo assinado.

Agende o ensaio como mudança planejada, com a mesma seriedade de um failover de banco de dados. Se o teste falhar — credencial expirada, exclusão de política removida por engano, alerta que não dispara — trate a falha como incidente de resiliência com prazo de correção, não como nota de rodapé para a próxima reunião. O histórico dos ensaios anteriores é o que transforma a promessa de RTO em número defensável na frente do negócio.

Checklist de implantação

Prioridades de implantação

P1: garantir que existam credenciais reservadas testadas e o backup do estado do cluster com restore ensaiado — são as duas falhas que transformam incidente em crise prolongada. P2: formalizar a exclusão das políticas de acesso como decisão assinada, ligar o alerta dedicado no SIEM e calendarizar o ciclo trimestral de ensaio com evidência arquivada. A ordem importa: nada do restante serve se, na hora H, a porta não abre.

Fontes

• Kubernetes — Operating etcd clusters for Kubernetes
• AWS — Set up emergency access to the AWS Management Console
• AWS Well-Architected — Implement break-glass procedures
• Microsoft — Manage emergency access accounts in Microsoft Entra ID