AWS Key Management Service (KMS) gerencia chaves criptográficas (KMS keys) e fornece APIs para encriptação/descriptografia e controle de acesso.

🎯 Para a certificação

Espera-se que você entenda envelope encryption, diferenças entre chaves gerenciadas pela AWS e customer-managed, a interação entre key policy e IAM, deleção vs desativação de chaves, e quando escolher KMS em vez de CloudHSM.

Resumo

Pense no KMS como o cofre de chaves de um prédio: ele não guarda os documentos em si, mas guarda e protege as chaves que abrem os cofres menores onde os documentos ficam. O KMS nunca expõe a chave-mestra diretamente para uso externo — toda operação de criptografia/descriptografia com ela acontece dentro do próprio serviço, de forma auditável.

KMS key (antigo "CMK" — Customer Master Key, termo ainda usado informalmente): a chave-mestra gerenciada pelo KMS.
Envelope encryption: dados são criptografados com uma chave de dados temporária (DEK), que por sua vez é criptografada pela KMS key.
Grants: permissões temporárias e granulares para usar uma key, sem precisar editar a key policy.
Key policy: o documento que controla, em primeira instância, quem pode usar e gerenciar a chave.

1. Envelope Encryption

Fluxo: gerar uma data key (DEK), criptografar os dados com a DEK localmente, e criptografar a própria DEK com a KMS key.

Explicação didática: imagine que você quer trancar uma mala grande (seus dados). Em vez de usar uma chave-mestra gigante (a KMS key) diretamente na mala — o que exigiria chamar o KMS toda vez, com latência de rede — você gera uma chave pequena e descartável (a Data Encryption Key, DEK), tranca a mala com ela localmente, e depois guarda essa chave pequena dentro de um cofre trancado pela chave-mestra. Assim, só uma chamada ao KMS é necessária (para proteger a DEK), e toda a criptografia pesada do arquivo acontece localmente, sem latência repetida.

1.1 GenerateDataKey vs GenerateDataKeyWithoutPlaintext

Duas variações da mesma operação, para cenários diferentes:

GenerateDataKey: retorna a DEK em texto claro (para criptografar os dados imediatamente) e a versão criptografada da DEK (para guardar junto dos dados, e usar depois na descriptografia). Uso típico: você vai criptografar algo agora mesmo.
GenerateDataKeyWithoutPlaintext: retorna só a versão criptografada da DEK, sem nunca expor a versão em texto claro para o chamador. Uso típico: você quer guardar a DEK criptografada para uso futuro, sem manter a versão em claro na memória agora.

2. Key policy x IAM — como as duas se relacionam

Esse é o ponto mais mal compreendido do KMS, e o conteúdo original não explicava a mecânica. A key policy é a fonte primária de autoridade sobre uma KMS key — sem uma declaração na key policy permitindo, nenhuma IAM policy sozinha consegue conceder acesso a essa chave.

Por padrão, quando você cria uma chave, a AWS gera automaticamente uma key policy que dá acesso total ao usuário/role root da conta ("Principal": {"AWS": "arn:aws:iam::<conta>:root"}). É justamente essa linha que habilita o restante da delegação a acontecer via IAM: com essa permissão de root já presente, as IAM policies de users/roles individuais podem então conceder acesso específico à chave, porque a key policy "abriu a porta" para que o controle de acesso IAM normal da conta seja aplicado.

Key Policy (permite root) → IAM policies de users/roles (concedem acesso específico) → uso efetivo da key

Se alguém remover essa concessão ao root da key policy (um erro comum e perigoso), a chave fica isolada — nenhuma IAM policy, por mais permissiva que seja, conseguirá conceder acesso a ela, porque a key policy nunca abriu essa porta.

3. Tipos de chave

3.1 Quanto à origem/gestão

AWS-owned keys: chaves usadas internamente por serviços AWS, você nem vê nem gerencia — mais simples, menos controle.
AWS-managed keys: aparecem na sua conta (ex: aws/s3), criadas automaticamente na primeira vez que um serviço precisa de criptografia, mas o ciclo de vida (rotação, política) é controlado pela AWS.
Customer-managed keys: você cria, controla a key policy, decide sobre rotação, pode desativar/deletar, e tem visibilidade total de uso via CloudTrail — a opção quando há requisito de auditoria e controle granular.
Imported key material (BYOK — Bring Your Own Key): você importa seu próprio material de chave (gerado fora da AWS) para dentro de uma KMS key — dá controle total sobre a origem da chave, mas exige que você gerencie a disponibilidade desse material (se você deletar o material importado, a chave para de funcionar imediatamente, sem o período de espera de uma deleção normal).

3.2 Quanto ao algoritmo

Simétricas: a mesma chave criptografa e descriptografa — é o tipo padrão e mais comum, usado pela maioria dos serviços integrados ao KMS (S3, EBS, RDS).
Assimétricas: um par de chave pública/privada — usado quando outra parte precisa criptografar dados sem ter acesso à chave privada (que nunca sai do KMS), ou para assinatura digital verificável externamente.

💡 Para a prova: cenário de criptografia de dados em serviços AWS (S3, EBS, RDS) → chave simétrica. Cenário de assinatura digital ou terceiros externos precisando criptografar sem ter a chave privada → chave assimétrica.

4. Rotação de chaves

Para customer-managed keys simétricas, é possível habilitar rotação automática anual: o KMS gera novo material criptográfico para a chave, mas mantém as versões antigas do material internamente — dados criptografados com a versão anterior continuam sendo descriptografáveis normalmente, porque o KMS sabe qual versão usar para cada operação. O ID e o ARN da chave não mudam com a rotação.

⚠️ Chaves assimétricas e chaves com material importado (BYOK) não suportam rotação automática do KMS.

5. Desativar vs Deletar uma chave — a diferença crítica

Este é um ponto que a versão original cobria pela metade (só desativação) e é uma pegadinha clássica de prova:

Desativar (Disable): reversível. A chave para de poder ser usada imediatamente, mas pode ser reativada a qualquer momento, restaurando o acesso sem perda de dados.
Deletar (Schedule Key Deletion): irreversível, e por isso a AWS não permite deleção imediata — você agenda a deleção com um período de espera obrigatório de 7 a 30 dias. Durante esse período, é possível cancelar a deleção. Depois que o período expira e a chave é efetivamente deletada, qualquer dado criptografado só com essa chave se torna permanentemente irrecuperável — não existe "restaurar" depois disso.

💡 Regra para a prova: se o cenário descreve "impedir uso temporariamente, mas manter possibilidade de reverter" → Disable. Se descreve "remover definitivamente" → Schedule Key Deletion, com atenção ao período de espera como salvaguarda contra erro humano.

6. Multi-Region Keys

Por padrão, uma KMS key existe numa única região. Multi-Region Keys permitem criar uma chave "primária" em uma região e replicá-la como chaves "réplica" em outras regiões — todas compartilham o mesmo material de chave (mesmo ID de key material), mas cada uma tem seu próprio ARN por região.

Isso permite criptografar dados numa região e descriptografá-los diretamente em outra, sem precisar fazer uma chamada de API cross-region — útil para cenários de disaster recovery ou replicação de dados entre regiões (ex: réplicas de DynamoDB Global Tables, backups replicados) onde os dados criptografados precisam ser lidos em outra região sem depender da região original estar disponível.

7. Encryption Context

Um conjunto opcional de pares chave-valor (dados não secretos) que você pode associar a uma operação de criptografia/descriptografia como contexto adicional autenticado. O KMS exige que o mesmo encryption context usado para criptografar seja fornecido para descriptografar — se não bater, a operação falha, mesmo com a chave certa.

Dois benefícios práticos: (1) uma camada extra de integridade — impede que um texto cifrado seja "reaproveitado" fora do contexto original pretendido; (2) aparece nos logs do CloudTrail, tornando a auditoria mais rica (você consegue ver não só "quem usou a chave", mas "para qual contexto/registro específico").

8. Grants

Permissões temporárias e granulares para usar uma key, concedidas via API (CreateGrant), sem precisar editar a key policy. Diferente de uma mudança na key policy (que é uma operação administrativa mais pesada), um grant é ideal para delegação programática e de curto prazo — por exemplo, um serviço AWS delegando a outro componente uma permissão específica e temporária de usar a chave em nome do usuário, sem tocar na política principal.

9. KMS vs CloudHSM — a comparação que a prova adora cobrar

Característica	KMS	CloudHSM
Modelo	Multi-tenant (hardware compartilhado, gerenciado pela AWS)	Single-tenant (hardware dedicado só à sua conta)
Gerenciamento	Totalmente gerenciado pela AWS	Você gerencia o cluster HSM
Nível de compliance	FIPS 140-2 nível 2 (nos módulos usados)	FIPS 140-2 nível 3
Integração nativa com serviços AWS	Ampla (S3, EBS, RDS etc. usam KMS diretamente)	Limitada — geralmente via integração customizada
Controle sobre o hardware	Nenhum	Total — você é o único com acesso ao HSM
Caso de uso típico	A grande maioria dos casos de criptografia em serviços AWS	Requisitos regulatórios estritos que exigem hardware dedicado e certificação de nível 3

💡 Para a prova: se o cenário menciona "requisito regulatório específico exigindo hardware criptográfico dedicado e certificação FIPS 140-2 nível 3", a resposta é CloudHSM, não KMS — mesmo sendo mais operacionalmente pesado.

10. Boas práticas

Use envelope encryption para grandes volumes de dados, evitando chamar o KMS repetidamente para cada operação.
Restrinja key policies e use grants para operações específicas e temporárias.
Automatize rotação para chaves simétricas customer-managed e monitore uso via CloudTrail.
Use encryption context sempre que houver benefício de auditoria e integridade adicional.
Nunca remova a permissão de root da key policy sem entender completamente a consequência (perda de capacidade de delegar via IAM).
Prefira Disable a Schedule Key Deletion quando houver qualquer incerteza sobre se a chave ainda é necessária.

11. Como cai na certificação

Cenário "reduzir chamadas ao KMS ao criptografar grandes volumes" → envelope encryption.
Cenário "controle granular, rotação e auditoria completa da chave" → customer-managed key.
Cenário "impedir uso temporariamente, mas manter reversibilidade" → Disable.
Cenário "remover definitivamente, com salvaguarda contra erro humano" → Schedule Key Deletion (7–30 dias).
Cenário "IAM policy concede acesso a uma key, mas o acesso continua sendo negado" → verificar se a key policy permite essa delegação (ex: se a permissão de root foi removida por engano).
Cenário "criptografar numa região, descriptografar em outra sem chamada cross-region" → Multi-Region Keys.
Cenário "camada extra de integridade e rastreabilidade por registro nos logs" → Encryption Context.
Cenário "requisito de hardware dedicado, FIPS 140-2 nível 3" → CloudHSM, não KMS.
Cenário "delegação temporária e programática, sem editar a key policy" → Grants.

12. Exercícios práticos conceituais

Desenhe o fluxo de envelope encryption para um arquivo armazenado em S3, incluindo a chamada de API específica usada.
Explique quando usar customer-managed keys em vez de AWS-managed.
Escreva um exemplo de caso de uso para grants em vez de alterar a key policy.
Liste a diferença de impacto entre desativar e deletar uma CMK ativa por engano.
Explique por que remover a permissão de root da key policy pode "quebrar" o controle de acesso via IAM, mesmo que as IAM policies pareçam corretas.
Descreva um cenário onde CloudHSM seria exigido em vez de KMS, e por quê.

13. Questões de Revisão

Questão 1

Qual é o principal benefício da envelope encryption?

Questão 2

Quando é recomendável usar customer-managed keys em vez de AWS-managed keys?

Questão 3

Qual ferramenta registra o uso de KMS keys para auditoria?

Questão 4

O que é um grant no KMS?

Questão 5

O que acontece se uma KMS key for desativada enquanto ainda é usada por aplicações em produção?

Questão 6

Uma equipe agenda a deleção de uma KMS key customer-managed que ainda protege dados críticos em produção, sem perceber o erro. O que a AWS faz para reduzir o risco desse tipo de engano?

Questão 7

Um usuário tem uma IAM policy que concede permissão total (`kms:*`) sobre uma KMS key específica, mas ainda assim recebe "Access Denied" ao tentar usá-la. A key policy dessa chave não contém nenhuma referência a esse usuário nem ao root da conta. Qual é a causa mais provável?

Laboratório Prático

Objetivo: criar uma customer-managed key, observar a interação entre key policy e IAM, e praticar envelope encryption via CLI.

Pré-requisitos: conta AWS com permissão para KMS e IAM, AWS CLI configurada.

Tempo estimado: 25 minutos

Possíveis custos: KMS cobra por chave customer-managed ativa por mês (valor baixo) mais por uso de API além da cota gratuita — praticamente nulo para testes pontuais.

Passos:

Crie uma customer-managed key simétrica via console, observando a key policy padrão gerada (permissão de root).
Crie um IAM user de teste com uma policy concedendo kms:Encrypt e kms:Decrypt para essa key específica.
Usando as credenciais desse user na CLI, criptografe um pequeno texto: aws kms encrypt --key-id <id> --plaintext "teste".
Edite a key policy removendo a permissão de root, deixando só a permissão do user específico. Tente criptografar de novo — dependendo da configuração, observe como a ausência da permissão de root pode impactar a resolução de outras permissões IAM não explicitamente listadas na key policy.
Restaure a key policy original (com permissão de root).
Pratique envelope encryption: gere uma data key com aws kms generate-data-key, observe os dois campos retornados (Plaintext e CiphertextBlob), e simule descriptografar a DEK depois com aws kms decrypt.
Agende a deleção da key de teste (schedule-key-deletion com --pending-window-in-days 7) e confirme, no console, o status "Pending deletion" com a data prevista — depois cancele a deleção (cancel-key-deletion) para restaurar a key ao estado ativo.

Resultado esperado: você confirma na prática a mecânica de envelope encryption via CLI, e observa o comportamento da key policy controlando o acesso e o fluxo de deleção reversível dentro do período de espera.

Limpeza dos recursos: agende a deleção definitiva da key de teste (se não for mais necessária) e remova o IAM user criado.

Referências:

AWS KMS Developer Guide: https://docs.aws.amazon.com/kms/
Conceitos do KMS: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
Key Policies: https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html
Rotação de chaves: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
Multi-Region Keys: https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html
AWS CloudHSM: https://docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html