Rotação de segredos sem uma página às 3 da manhã

A API key tinha dezoito meses. A política de segurança dizia rotacionar trimestralmente. Ninguém rotacionou porque rotacionar significava: gerar chave nova, atualizar o vault, redeployar todos os serviços simultaneamente, rezar para que nada cacheasse a chave antiga, fazer rollback se algo falhasse. A rotação virou uma negociação trimestral que sempre perdia para o trabalho de features — até uma chave aparecer em uma exportação de logs. Rotação de segredos sem queda não é um checkbox de feature do vault. É uma decisão de arquitetura: sistemas aceitam duas credenciais válidas durante uma janela de graça, deploys avançam gradualmente, e chaves antigas são retiradas só depois que o tráfego comprova uso zero.

Segredos que não podem rotacionar sem downtime não rotacionam. Envelhecem. Segredos envelhecidos são impacto de breach previsível. O objetivo é uma rotação suficientemente entediante para rodar em schedule — automatizada, reversível e invisível para os usuários.

Why rotation breaks production

Failure mode	Cause
Validação de chave única	Serviço aceita apenas um segredo ativo
Deploy simultâneo exigido	Todos os consumidores devem atualizar na mesma janela
Credenciais cacheadas	SDK ou pool de conexões retém segredo antigo após atualização
Variáveis de ambiente hardcoded	Rotação exige redeploy por instância
Sem telemetria de uso	Não dá para confirmar que a chave antiga está inativa antes de revogar
God-key compartilhada	Doze serviços, uma rotação coordena doze deploys

Sistemas de chave única forçam rotação big-bang — o mesmo modo de falha das migrações de schema big-bang. Períodos de graça com chave dupla aplicam lógica expand/contract às credenciais: expand (adicionar chave nova como válida), migrate (consumidores pegam a chave nova), contract (revogar chave antiga após a prova).

Um runbook de rotação que começa com "agendar manutenção" é um documento que não vai rodar trimestralmente.

Dual-key grace period pattern

Durante o período de graça, validadores aceitam ambas key_current e key_next:

Phase 1 — Expand
Vault: key_v1 (active), key_v2 (issued, not yet deployed)
Validators: accept v1 only

Phase 2 — Migrate
Deploy services with key_v2 in config (v1 still works)
Validators: accept v1 OR v2
Monitor: log which key ID signed each request

Phase 3 — Contract
All traffic on v2 (metrics confirm)
Validators: accept v2 only
Revoke v1

Duração do período de graça: longa o suficiente para todos os consumidores deployarem pelo menos uma vez — tipicamente 24–72 horas com cadência de deploy diária, mais para times com deploy semanal ou parceiros externos.

Para chaves de assinatura JWT e segredos de cliente OAuth, o mesmo padrão se aplica com kid (key ID) nos headers do token — validadores buscam a chave pública ou o segredo correto por ID. OAuth scopes and authorization design cobre o scoping de credenciais; rotação fica mais fácil quando cada serviço tem segredos acotados em vez de uma god-key compartilhada.

Rotation by secret type

Secret type	Rotation approach	Grace period notes
API keys (internal)	Validação dual-key no gateway	Log key ID por request
Database passwords	Usuário com duas senhas ou dois usuários DB	Drain do connection pool no deploy
TLS certificates	Períodos de validade sobrepostos	Prática padrão — aplicar a mesma disciplina a API keys
JWT signing keys	JWKS com múltiplas entradas kid	Publicar chave nova antes do switch de assinatura
Third-party API keys	Depende do provedor; muitas vezes manual	Escalonar: chave nova ativa antes de revogar a antiga
CI/CD tokens	Tokens duplos válidos na config do pipeline	Padrões de CI/CD secrets in production

Rotação de banco de dados sem queda: criar app_user_v2 com senha nova, conceder privilégios idênticos, deployar apps apontando conexões novas para credenciais v2, drenar pools de conexão antigos, remover usuário v1 quando contagem de conexões for zero.

Automation and observability for boring rotation

A rotação deveria ser agendável e alertável:

• Automated issuance — vault gera key_next em schedule.
• Deployment hooks — pipeline CD injeta a última versão do segredo; sem atualizações manuais por SSH.
• Key usage metrics — contar autenticações por key ID; dashboard mostra progresso de migração v1 → v2.
• Revoke gate — check automatizado: uso de v1 = 0 por N horas antes de revogar; ack humano para produção.
• Rollback — se v2 causa erros, validadores ainda aceitam v1 durante o período de graça.

Alertar sobre: rotação vencida, período de graça terminando com tráfego v1 restante, deploy falho de nova versão do segredo.

Zero trust for internal APIs assume que credenciais rotacionam e têm escopo acotado — chaves internas estáticas de longa duração sem rotação minam o modelo.

Organizational habits that make rotation stick

Rotation owner per secret class. Não "time de segurança" em abstrato — owner nomeado para creds de banco de dados, chaves de API gateway, tokens CI.

Rotation in deploy path. Serviços buscam segredos do vault no startup e em intervalo — não só em build time. Rotação sem redeploy é possível quando apps refrescam credenciais.

No secrets in git. Óbvio mas bloqueia automação. Rotacionar segredos commitados exige reescrita de histórico — não é rotação.

Partner lead time. Integrações externas podem precisar de semanas de aviso. Períodos de graça se estendem ao SLA do parceiro, não só à cadência de deploy interna.

Game day. Drill trimestral de rotação em staging — ciclo dual-key completo cronometrado e documentado. Rotação em produção deveria ser mecânica ensaiada, não cirurgia nova.

How should teams implement outage-free secret rotation?

Essas decisões evitam programas de rotação que morrem após a primeira tentativa falha.

How long should dual-key grace periods last?

No mínimo: dois ciclos completos de deploy de cada consumidor mais o TTL do connection pool. Para deploys diários, 48 horas é um piso razoável. Consumidores externos podem precisar de 30 dias — documentar em acordos com parceiros.

Can all secrets use dual-key validation?

Não. Algumas APIs de terceiros emitem uma única chave ativa. Mitigação: solicitar segunda chave com antecedência, sobrepor manualmente, aceitar janela breve de risco. Segredos internos — controle total — sempre deveriam suportar dual-key.

When should old keys revoke automatically vs manually?

Automatizar revogação quando métricas mostram uso zero por período definido E taxa de erro estável na chave nova. Ack manual para segredos tier-0 (pagamento, chaves raiz de auth). Nunca auto-revogar sem telemetria de uso — revogar em silêncio causa quedas piores que segredos envelhecidos.

A common argument runs the other way

A visão oposta sustenta que rotação frequente aumenta o risco — que mudar credenciais com frequência cria mais falhas induzidas por deploy do que previne por roubo de credenciais.

A frequência de rotação deveria coincidir com o tier de risco. Chaves internas de baixa sensibilidade podem rotacionar anualmente com suporte dual-key. Chaves de alta sensibilidade rotacionam trimestralmente ou ante mudança de pessoal. A alternativa à rotação não é estabilidade — é duração de exposição desconhecida quando as chaves vazam. Rotação dual-key reduz o risco de deploy a quase zero quando períodos de graça são respeitados.

NIST e frameworks de compliance esperam cada vez mais capacidade de rotação — não teatro de rotação, mas capacidade comprovada de mudar credenciais sem queda.

Key takeaways

• Rotação que exige janelas de manutenção não acontece — segredos envelhecem até o breach.
• Períodos de graça dual-key: validadores aceitam credenciais antigas e novas durante o rollover.
• Log key ID por autenticação para confirmar uso zero de chave antiga antes de revogar.
• Rotação de banco de dados usa usuários ou senhas duplas com drain do connection pool.
• Automatizar emissão, injeção no deploy, métricas de uso e gates de revogação.
• Ensaiar ciclo completo de rotação em staging trimestralmente.

Conclusion

Rotação de segredos sem uma página às 3 da manhã é uma propriedade de design, não um lembrete de calendário. Sistemas que aceitam duas chaves durante janelas de graça rotacionam numa terça às 14h como qualquer outro deploy. Sistemas que aceitam uma chave rotacionam em postmortems de incidentes.

O passo de inventário: listar cada segredo de produção, marcar se rotação dual-key está suportada hoje, marcar data da última rotação. Lacunas em suporte dual-key são trabalho de engenharia; lacunas em datas de rotação são risco acumulando à vista.