Equipes que operam criptografia em nuvem costumam tratar a rotação de chaves como uma caixa de seleção de compliance: ligar, esquecer, considerar o risco resolvido. A prática é útil, mas o efeito é mais estreito do que o nome sugere. A decisão prática deste guia é separar o que a troca periódica de material criptográfico entrega — limitar a exposição acumulada de uma chave — daquilo que ela não entrega: recriptografia de dados, contenção de comprometimento e governança de chaves assimétricas. A ação prioritária é inventariar quais chaves gerenciadas têm rotação ativa, verificar se ela de fato ocorreu e definir um processo manual para as categorias que os provedores não giram automaticamente.
O problema de fundo
Chaves criptográficas são o ponto em que algoritmos fortes fracassam por operação fraca. A publicação NIST SP 800-57, emitida em maio de 2020, resume o risco em uma frase: má gestão inadequada de chaves compromete algoritmos fortes, porque a proteção depende do ciclo de vida completo — geração, uso, rotação e destruição — e não apenas da escolha do algoritmo. No contexto de nuvem, esse ciclo é dividido entre o provedor, que opera o módulo criptográfico, e o cliente, que decide política, períodos e quem pode usar cada chave. A divisão cria uma zona cinzenta em que times assumem que a nuvem gira tudo, sempre, e que a troca apaga o passado. Nenhuma das duas premissas se sustenta na documentação dos dois principais provedores.
Um paralelo útil vem da própria arquitetura de controle em nuvem: assim como políticas de perímetro restritas limitam o que uma credencial consegue alcançar, como discutimos no guia sobre SCPs e RCPs contra acesso externo, a rotação limita por quanto tempo um mesmo material secreto permanece exposto a abuso. Os dois controles se complementam, mas nenhum deles substitui o outro, e nenhum funciona sem verificação periódica de que está mesmo aplicado.
O que a rotação resolve
A rotação automática troca o material secreto que protege a chave lógica, mantendo o identificador estável. No AWS KMS, chaves gerenciadas pelo serviço são giradas todos os anos sem intervenção, e a rotação de chaves gerenciadas pelo cliente é opcional. O efeito prático é reduzir o volume de operações e o tempo de exposição associados a uma mesma versão do segredo: se um material vaza por um lado-canal ou por acesso indevido registrado em log, a janela em que ele serve como chave válida de cifragem é limitada pela data da próxima troca.
Para chaves simétricas de criptografia, a troca é transparente para aplicações: o texto cifrado antigo continua legível porque o serviço guarda as versões anteriores do material e escolhe a correta na descriptografia. Isso elimina o argumento clássico contra rotação — medo de quebrar integrações — e transfere a discussão para política: qual período, quais chaves entram e como provar auditoria.
O que ela não protege
Aqui mora a ilusão mais cara. Nos dois provedores citados, a rotação não recriptografa dados já protegidos: as versões antigas do material continuam existindo e capazes de decifrar tudo o que foi cifrado com elas. Trocar a chave depois de um vazamento não invalida o acesso do invasor ao material antigo, não desativa versões comprometidas e não apaga dependências. Rotação é higiene de ciclo de vida, não resposta a incidente.
Diante de suspeita de comprometimento, o caminho é outro: desabilitar a versão suspeita, revogar o acesso a ela no plano de identidade e executar um processo de recriptografia planejado. O Google Cloud KMS recomenda explicitamente validar os procedimentos de rotação antes de um incidente real, porque é no ensaio que a equipe descobre quem depende de qual versão e quanto tempo leva a migração. Esse ensaio também expõe um custo esquecido: versões antigas continuam ativas e gerando cobrança até serem destruídas, o que força uma política de recriptografia e limpeza, não apenas de troca.
Períodos e tipos de chave
No AWS KMS, o período padrão de rotação é de 365 dias, contado a partir da habilitação, e pode ser ajustado com o parâmetro RotationPeriodInDays para atender contratos ou regulamentos mais rígidos. O provedor recomenda rotação automática sempre que suportada, sob demanda quando a automática não se aplica e manual nos demais casos.
A fronteira técnica importa mais que o número. A rotação automática do AWS KMS vale apenas para chaves simétricas de criptografia com material gerado pelo próprio serviço; chaves assimétricas, chaves HMAC e chaves em keystore externo ficam fora. O Google Cloud KMS segue a mesma linha e não oferece rotação automática para chaves assimétricas, porque a nova versão exige distribuição da parte pública e atualização das aplicações que assinam ou verificam. Para essa categoria, o processo manual precisa estar documentado: gerar nova versão, distribuir a pública, migrar consumidores, agendar aposentadoria da antiga. Times que concentram chaves de assinatura em um único fluxo sem runbook descobrem a dívida na pior hora.
Checklist de auditoria
A verificação abaixo pode ser executada em uma semana por uma pessoa, na maioria dos ambientes, e transforma a rotação de item de fé em item de evidência.
| Prioridade | Ação | Como verificar |
|---|---|---|
| P1 | Inventariar chaves sem rotação automática | No AWS, GetKeyRotationStatus por chave; no Google Cloud, inspecionar o agendamento de rotação de cada chave |
| P1 | Confirmar que rotações ocorreram de fato | ListKeyRotations no AWS e eventos RotateKey no CloudTrail; no Google Cloud, histórico de versões da chave |
| P1 | Tratar suspeita de comprometimento fora da rotação | Desabilitar a versão, revogar acesso no IAM e acionar o plano de recriptografia |
| P2 | Documentar rotação manual de chaves assimétricas | Runbook com geração, distribuição da pública, migração e aposentadoria da versão antiga |
| P2 | Planejar recriptografia e destruição de versões antigas | Mapear dados por versão de chave e programar destruição após confirmação de não uso |
O monitoramento merece assento permanente na operação, não só na auditoria anual. O evento de rotação aparece nos trilhos de observabilidade da nuvem — CloudTrail e EventBridge no caso da AWS — e deve alimentar a mesma esteira de logs mínimos que a equipe já mantém para detecção, no espírito do endurecimento criptográfico aplicado em outras fronteiras, como o SSH do GitHub. Alarme simples e eficaz: chave com rotação habilitada e sem evento de rotação no período esperado.
Por fim, a política escrita. Defina em uma página quais tipos de chave existem no ambiente, o período de cada um, quem aprova exceções e qual evidência comprova execução. Sem isso, a resposta à pergunta “nossas chaves giram?” continua sendo um achismo caridoso — e a criptografia, por melhor que seja o algoritmo, herda a fragilidade do processo que a administra.