AWS KMS: boas práticas para criptografia, chaves e controle de acesso
A criptografia só protege se o controle de acesso à chave estiver correto. Veja como usar o KMS sem brechas.
O AWS KMS gerencia as chaves de criptografia que protegem dados em praticamente todos os serviços da AWS. O ponto que muita gente ignora é que criptografar não é o suficiente: o que realmente importa é quem pode usar a chave para descriptografar. Uma chave com política permissiva demais transforma a criptografia em uma falsa sensação de segurança, porque qualquer identidade com acesso amplo consegue ler os dados.
Este guia trata do uso defensivo do KMS, com foco em controle de acesso às chaves: tipos de chave, key policy, grants, rotação, envelope encryption e auditoria. O objetivo é que a chave seja uma fronteira real de segurança, e não apenas um item marcado como habilitado.
Tipos de chave e key policy
O KMS oferece chaves gerenciadas pela AWS e chaves gerenciadas pelo cliente. As gerenciadas pela AWS são convenientes, mas você não controla a política nem a rotação. Para dados sensíveis, prefira customer managed keys, que dão controle total sobre quem pode usar e administrar a chave e permitem políticas específicas por contexto.
A key policy é o controle de acesso primário da chave e se soma às permissões de IAM. O erro mais comum é uma key policy que delega amplamente ao IAM da conta, fazendo com que qualquer principal com permissão genérica de KMS consiga usar a chave. Separe claramente quem administra a chave de quem apenas a utiliza, e evite curingas no principal.
Administradores da chave: criar, desabilitar, alterar política
Usuários da chave: encrypt, decrypt, generateDataKey
Evite conceder ambos os conjuntos ao mesmo principal amploRotação, grants e envelope encryption
Habilite a rotação automática anual das customer managed keys quando aplicável. A rotação troca o material criptográfico mantendo o mesmo identificador, sem exigir recriptografia dos dados. Para concessões temporárias e granulares, use grants em vez de inchar a key policy, porque grants podem ser revogados e têm escopo restrito.
A maioria dos serviços usa envelope encryption: o KMS protege uma chave de dados, que por sua vez criptografa o conteúdo. Entender esse modelo ajuda a dimensionar custo e desempenho, já que chamadas excessivas ao KMS podem gerar throttling e custo, enquanto o cache de chaves de dados, quando bem usado, equilibra segurança e eficiência.
Auditoria e segregação
Todo uso de uma chave do KMS é registrado no CloudTrail. Isso permite responder perguntas críticas em uma investigação: quem descriptografou determinado dado, quando e a partir de onde. Monitore eventos sensíveis, como tentativas de desabilitar ou agendar exclusão de chave, que podem indicar tanto erro operacional quanto atividade maliciosa.
- Usar customer managed keys para dados sensíveis
- Separar administradores de usuários da chave na key policy
- Evitar curingas de principal e delegação ampla ao IAM
- Habilitar rotação automática quando aplicável
- Usar grants para concessões temporárias e revogáveis
- Monitorar no CloudTrail desabilitação e exclusão de chaves
Checklist prático
- Usar customer managed keys para dados sensíveis
- Escrever key policy separando administração de uso
- Evitar curingas no principal e delegação ampla ao IAM
- Habilitar rotação automática anual quando aplicável
- Usar grants para acesso temporário e granular
- Restringir uso da chave por condição quando fizer sentido
- Monitorar uso e administração da chave no CloudTrail
- Alertar sobre desabilitação e agendamento de exclusão de chave
- Revisar periodicamente quem pode descriptografar
- Documentar a finalidade de cada chave relevante
Boas práticas
- Trate a chave como fronteira de acesso, não apenas como item habilitado
- Separe administração e uso para evitar acúmulo de poder
- Prefira grants revogáveis a inflar a key policy
- Use o CloudTrail para responder quem descriptografou o quê
- Considere chaves distintas por contexto ou ambiente
- Proteja contra exclusão acidental com período de espera adequado
Erros comuns
Key policy que delega amplamente ao IAM da conta
Qualquer principal com KMS genérico consegue usar a chave e ler os dados.
Mesmo principal administra e usa a chave
Acúmulo de poder facilita abuso e dificulta a segregação de funções.
Usar somente chaves gerenciadas pela AWS para dados sensíveis
Você perde controle sobre política e rotação onde mais precisaria dele.
Não monitorar exclusão de chave
A exclusão de uma chave torna os dados protegidos irrecuperáveis.
Curingas no principal da key policy
Concede uso da chave muito além do necessário.
Quando procurar apoio especializado
Modelar key policies e segregação de acesso a chaves em um ambiente com muitos dados sensíveis exige cuidado. A GUARDIASEC avalia criptografia, gestão de chaves e exposição no serviço de Segurança AWS e Cloud Security, com foco em controle de acesso real.
Perguntas frequentes
Chave gerenciada pela AWS ou pelo cliente?
Chaves gerenciadas pela AWS são convenientes para casos simples, mas você não controla a política nem a rotação. Para dados sensíveis, prefira customer managed keys, que dão controle total sobre quem administra e usa a chave, permitem políticas específicas e habilitam rotação configurável. O controle adicional é o que torna a criptografia uma fronteira real.
A rotação de chave recriptografa meus dados?
Não. A rotação automática do KMS troca o material criptográfico subjacente mantendo o mesmo identificador de chave. Os dados existentes continuam acessíveis e novas operações usam o material mais recente. Isso reduz o risco de uma chave de longa vida sem exigir o esforço de recriptografar tudo.
Por que a key policy importa se já tenho IAM?
A key policy é o controle primário de acesso da chave e se combina com o IAM. Se a key policy delega amplamente ao IAM da conta, qualquer principal com permissão genérica de KMS passa a poder usar a chave. Escrever uma key policy específica, separando administração de uso, é o que evita acesso indevido aos dados criptografados.
O que acontece se uma chave for excluída?
Os dados protegidos por ela tornam-se irrecuperáveis, porque sem a chave não há como descriptografar. Por isso a exclusão tem um período de espera e deve ser monitorada de perto. Trate o agendamento de exclusão como evento de alta severidade e proteja por política quem pode executá-lo.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.