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, condições, grants, rotação, envelope encryption, ciclo de vida 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 amploChave simétrica ou assimétrica
A maioria dos casos de uso pede chave simétrica, que criptografa e descriptografa com o mesmo material e nunca sai do KMS. Chaves assimétricas existem para cenários específicos, como assinatura digital ou criptografia por uma parte externa que só tem a chave pública. Escolher assimétrica sem necessidade adiciona complexidade e limita quais serviços da AWS conseguem usar a chave de forma transparente.
Condições que restringem o uso da chave
Uma key policy fica bem mais forte quando usa condições para limitar o contexto de uso, em vez de só listar principals. Condições permitem, por exemplo, exigir que a chave só seja usada por meio de um serviço específico, restringir o uso à sua organização ou amarrar a operação a um contexto de criptografia. Assim, mesmo uma credencial válida só consegue usar a chave dentro do contexto esperado.
"Condition": {
"StringEquals": {
"kms:ViaService": "s3.sa-east-1.amazonaws.com",
"aws:PrincipalOrgID": "o-exemplo123"
}
}A condição kms:ViaService garante que a chave só seja usada quando a chamada chega por um serviço autorizado, como o S3 ou o EBS, e não diretamente por uma identidade. A condição aws:PrincipalOrgID limita o uso a principals da sua organização, o que bloqueia acesso vindo de contas externas mesmo que o principal seja referenciado de forma ampla.
Contexto de criptografia
O contexto de criptografia é um par de dados autenticados, mas não secretos, que você associa a uma operação. Ele não altera o texto cifrado, mas precisa ser reapresentado igual na descriptografia, o que amarra o uso da chave a um contexto específico e aparece no CloudTrail. Usado em condição, permite que uma chave compartilhada só descriptografe dados marcados com o contexto correto, reduzindo o risco de uma carga ler o que pertence a outra.
Rotação, grants e envelope encryption
Habilite a rotação automática 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.
Grants no lugar de política inchada
Grants são úteis quando um serviço ou uma carga precisa de acesso pontual à chave, por exemplo para um serviço criar um recurso criptografado em seu nome. Em vez de editar a key policy a cada caso, um grant concede uma permissão específica, com escopo restrito, que pode ser revogada depois. Isso mantém a key policy estável e legível, enquanto as concessões operacionais ficam registradas e reversíveis.
Ciclo de vida: exclusão, alias e multi-region
A exclusão de uma chave é irreversível e torna irrecuperável qualquer dado protegido por ela. Por isso o KMS não apaga na hora: ele agenda a exclusão com um período de espera configurável. Antes de considerar a exclusão de uma chave, desabilite-a e observe se algo quebra; se nada depende dela por um bom tempo, aí sim avalie o agendamento, sempre monitorado.
# Desabilita a chave e observa impacto antes de qualquer exclusão
aws kms disable-key --key-id <id-da-chave>
# Se um agendamento for feito por engano, cancele dentro do prazo
aws kms cancel-key-deletion --key-id <id-da-chave>Referencie chaves por alias, não pelo identificador cru espalhado em código e configuração. O alias dá um nome estável e permite trocar a chave subjacente sem caçar identificadores por todo o ambiente. Cuide para que o alias aponte sempre para a chave correta, já que um alias reapontado muda qual chave passa a ser usada.
Chaves multi-region replicam o material entre regiões mantendo o mesmo identificador, o que ajuda em cenários de disaster recovery e replicação de dados criptografados. O contraponto é que ampliam a superfície: cada réplica é um ponto onde a chave pode ser usada. Use multi-region só quando o caso pedir replicação entre regiões, e mantenha a key policy de cada réplica igualmente restrita.
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
- Restringir uso por kms:ViaService, aws:PrincipalOrgID e contexto
- Habilitar rotação automática quando aplicável
- Usar grants para concessões temporárias e revogáveis
- Referenciar chaves por alias, não pelo identificador cru
- 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
- Restringir uso com kms:ViaService e aws:PrincipalOrgID quando fizer sentido
- Usar contexto de criptografia para amarrar operações a um contexto
- Habilitar rotação automática quando aplicável
- Usar grants para acesso temporário e granular
- Referenciar chaves por alias em código e configuração
- Desabilitar a chave e observar antes de agendar exclusão
- 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
- Use condições para limitar o contexto de uso da chave
- 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 desabilitando antes e 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 sem condições
Concede uso da chave muito além do necessário, inclusive fora da organização.
Referenciar a chave pelo identificador cru em vez de alias
Trocar a chave vira caça a identificadores espalhados por código e configuração.
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
O que é o AWS KMS e para que ele serve?
O AWS KMS (Key Management Service) é o serviço de gestão de chaves de criptografia da AWS. Ele cria, armazena e controla o uso das chaves que protegem dados em repouso e em trânsito em serviços como S3, RDS, EBS e Secrets Manager. O valor do KMS não está só na criptografia em si, mas no controle de acesso à chave: quem pode administrar e quem pode usar cada chave, com cada operação registrada no CloudTrail. Criptografia sem controle de acesso à chave protege pouco.
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 com condições 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 e aplicando condições, é o que evita acesso indevido aos dados criptografados.
O que é o contexto de criptografia no KMS?
O contexto de criptografia é um conjunto de pares de dados autenticados, mas não secretos, associado a uma operação de criptografia. Ele não fica cifrado, porém precisa ser reapresentado idêntico na descriptografia e aparece no CloudTrail. Serve para amarrar o uso da chave a um contexto específico e, quando usado em condição na política, permite que uma chave compartilhada só descriptografe dados marcados com o contexto correto.
Devo usar chaves multi-region?
Somente quando o caso exige replicar dados criptografados entre regiões ou sustentar disaster recovery entre regiões. A multi-region key mantém o mesmo material e identificador nas réplicas, o que simplifica esses cenários, mas amplia a superfície porque cada réplica é um ponto de uso. Se os dados vivem em uma única região, uma chave regional comum é mais simples e reduz a exposição.
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. A prática segura é desabilitar a chave primeiro e observar o impacto; 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.