Gerenciamento de Chaves, Acesso Cross-Account e Design com CMK usando KMS e Envelope Encryption
_Category: Data Protection_
Criptografar dados sem gerenciar adequadamente as chaves de criptografia é como trancar uma casa e deixar a chave embaixo do tapete. O AWS KMS (Key Management Service) existe exatamente para resolver esse problema. No exame SCS-C03, o KMS aparece em cenários compostos envolvendo S3, EBS, RDS, Secrets Manager e muito mais. Quem entende os tipos de chave, o modelo de permissões e o fluxo de Envelope Encryption consegue identificar o padrão certo na maioria das questões sobre KMS.
---
O Problema que o KMS Resolve: Os Riscos de Gerenciar Chaves Manualmente
Gerenciar chaves de criptografia de forma manual é como guardar joias em um cofre e colar a combinação em cima da porta. Os antipadrões mais comuns são: embutir uma chave AES-256 diretamente no código-fonte, armazená-la em variáveis de ambiente em texto puro ou salvá-la no disco local do servidor.
O AWS KMS resolve esses problemas de três formas. Primeiro, o material da chave (key material) fica dentro de um HSM (Hardware Security Module), o que impede que qualquer pessoa — inclusive a própria AWS — extraia a chave mestra em texto claro. Segundo, toda operação de criptografia e descriptografia passa pela API do KMS, gerando um registro de auditoria completo no CloudTrail. Terceiro, o controle de acesso fino integrado ao IAM pode ser aplicado por chave individual.
No exame, quando você vir palavras-chave como "log de auditoria", "rastreamento de acesso a chaves" ou "gerenciamento centralizado de chaves", o KMS é o caminho certo. Se o requisito for "controle físico direto do hardware HSM", aí a resposta aponta para o CloudHSM.
---
Tipos de Chave: Customer Managed Key vs AWS Managed Key vs AWS Owned Key
O KMS oferece três tipos de chave. A diferença é parecida com comprar um carro, alugar um ou chamar um táxi: o nível de controle varia bastante.
| Tipo | Customer Managed Key (CMK) | AWS Managed Key | AWS Owned Key | |------|--------------------------|-----------------|---------------| | Quem cria | Cliente | AWS (criada automaticamente por serviço) | AWS | | Edição da Key Policy | Sim | Não | Não | | Rotação (Rotation) | Manual ou automática (anual) | Automática (anual) | Gerenciada pela AWS | | Log no CloudTrail | Registro detalhado | Registrado | Não exposto | | Custo | US$ 1/mês por chave + chamadas de API | Gratuito | Gratuito | | Exemplo de uso | CMK própria para criptografar S3 e EBS | Chave padrão do S3 SSE-KMS, criptografia padrão do RDS | Chave interna do S3 SSE-S3 | | Compartilhamento cross-account | Sim (controlado via Key Policy) | Não | Não |
No exame, se o requisito for "controlar a Key Policy diretamente", "usar a chave em outra conta" ou "desativar o acesso à chave imediatamente", a resposta obrigatória é o Customer Managed Key (CMK). A AWS Managed Key é conveniente, mas o cliente não pode editar sua Key Policy.
Um detalhe importante sobre rotação: CMKs criadas com Imported Key Material não suportam rotação automática. A prática recomendada nesses casos é criar um novo CMK e redirecionar o Alias do KMS para ele manualmente. Ao reatribuir apenas o Alias, nenhuma alteração no código da aplicação é necessária para migrar para a nova chave.
!3 tipos de chave do KMS
Como Funciona o Envelope Encryption
O Envelope Encryption é o conceito central do KMS. Imagine uma carta com uma senha escrita que é guardada dentro de um envelope lacrado por uma chave mestra — é exatamente isso. Em vez de enviar os dados diretamente ao KMS para criptografar, você gera uma chave de dados temporária (Data Key, ou DEK), usa ela para criptografar os dados localmente e, em seguida, criptografa essa DEK com o CMK do KMS. É uma estrutura em dois estágios.
Fluxo de criptografia: chamada à API GenerateDataKey → KMS retorna a DEK em texto claro e a DEK criptografada → dados são criptografados localmente com a DEK em texto claro → a DEK em texto claro é descartada imediatamente da memória → os dados criptografados e a DEK criptografada são armazenados juntos.
Fluxo de descriptografia: a DEK criptografada é enviada à API Decrypt do KMS para recuperar a DEK em texto claro → os dados são descriptografados → a DEK em texto claro é descartada imediatamente.
Essa estrutura tem duas grandes vantagens. Dados volumosos são processados localmente com rapidez (o KMS processa diretamente apenas até 4 KB), e desativar o CMK invalida todas as DEKs de uma só vez, bloqueando o acesso aos dados de forma centralizada.
Armadilha comum no exame: em criptografia no lado do cliente (CSE), ter apenas kms:Encrypt e kms:Decrypt não é suficiente. A permissão kms:GenerateDataKey é necessária para gerar a DEK. No upload de múltiplas partes no S3, arquivos pequenos passam apenas com kms:GenerateDataKey, mas o estágio de CompleteMultipartUpload para arquivos grandes também exige kms:Decrypt.
---
Modelo de Permissões: As Três Camadas — Key Policy, IAM Policy e Grant
As permissões do KMS funcionam em três camadas sobrepostas. Pense em um sistema de controle de acesso a um edifício corporativo.
| Camada | Analogia | Características | Quando se aplica | |--------|----------|-----------------|------------------| | Key Policy | Política mestra de acesso ao edifício | Política baseada em recurso, fixada diretamente na chave. Obrigatória para que a IAM Policy tenha efeito | Sempre ativa | | IAM Policy | Crachá do funcionário | Política baseada em identidade (vinculada a roles ou usuários). Válida apenas se a Key Policy delegar ao root da conta | Sempre ativa | | Grant | Autorização temporária | Delega operações específicas a um Principal específico por tempo limitado. Muito usada internamente por serviços AWS (EBS, ECS etc.) com CMKs do cliente | Efeito imediato; pode expirar ou ser revogada |
A regra mais importante: se a Key Policy não incluir o Principal raiz da conta (), nenhuma IAM Policy vai conseguir acessar a chave, por mais permissiva que seja. Se essa instrução de delegação ao root estiver ausente, a recuperação da chave se torna impossível. O console do KMS a inclui automaticamente, mas ao criar chaves via API ou IaC, é preciso ter atenção.
A condição kms:ViaService permite o uso da chave apenas quando a requisição vem de um serviço AWS específico — como um crachá válido somente pela entrada principal. Ao adicionar na Key Policy, apenas o S3 naquela região pode usar a chave; chamadas diretas à API KMS são bloqueadas.
A condição kms:EncryptionContext valida o contexto de criptografia. Dados criptografados com não podem ser descriptografados sem o mesmo contexto. Isso cria um vínculo criptográfico que impede dados de produção de serem descriptografados em ambientes de staging.
O Grant é ideal para delegar permissões temporárias sem modificar a Key Policy. O AWS usa Grants internamente quando um volume EBS é anexado a uma instância EC2. Para controle de acesso de longa duração, Key Policy ou IAM Policy são mais adequados.
---
Acesso Cross-Account e Padrões com Multi-Region Key
O ponto central do acesso KMS entre contas (Cross-Account) é que a autorização deve existir em ambos os lados. A Key Policy da conta A precisa permitir o Principal da conta B, e a IAM Policy da conta B precisa permitir que a role correspondente execute operações como kms:Decrypt. Mesmo que a Key Policy da conta A autorize a conta B, sem a IAM Policy na conta B o acesso será negado.
Ao copiar um snapshot do EBS entre contas, para eliminar a dependência da CMK da conta de origem, o snapshot deve ser re-criptografado com uma CMK da conta de destino durante a cópia. Dessa forma, mesmo que a conta de origem seja comprometida, o snapshot de backup permanece gerenciado de forma independente pela CMK da conta de destino.
A condition key aws:PrincipalOrgID permite conceder acesso a todas as contas membro de uma organização com um único ID de organização. Novas contas adicionadas à organização recebem acesso automaticamente, sem necessidade de atualizar a Key Policy.
O Multi-Region Key replica uma chave primária para múltiplas regiões. As réplicas compartilham o mesmo ID de chave e o mesmo material da chave, o que permite descriptografar na região B dados que foram criptografados na região A com a mesma chave. Combinado com a replicação multirregional do Secrets Manager, isso elimina a sobrecarga de gerenciar chaves separadas por região.
O Imported Key Material permite trazer para o KMS o material de chave gerado externamente — por exemplo, em um HSM local. Como a rotação automática não é suportada, para cumprir políticas de rotação anual é necessário criar um novo CMK e reatribuir o Alias manualmente. Apagar o Imported Key Material imediatamente torna todos os dados criptografados com essa chave irrecuperáveis de forma instantânea — ideal para requisitos de bloqueio imediato, como "dentro de 24 horas".
---
Serviços que se Integram ao KMS
O KMS se integra a praticamente todos os serviços de armazenamento, banco de dados e computação da AWS. No S3, a criptografia no lado do servidor tem três modalidades. O SSE-S3 delega toda a geração e o gerenciamento de chaves ao S3, usando uma chave AES-256 exclusiva por objeto. O SSE-KMS usa um CMK indicado pelo cliente e registra cada operação no CloudTrail para rastreabilidade completa. O SSE-C exige que o cliente forneça a chave a cada requisição — a AWS não armazena a chave em nenhum momento.
No EBS, ativar a criptografia no momento da criação do volume permite que o KMS CMK seja usado de forma transparente. Volumes já existentes não podem ser criptografados diretamente; é preciso criar um snapshot e aplicar a opção de criptografia na cópia. No RDS, a criptografia só pode ser ativada na criação da instância; para criptografar uma instância não criptografada, crie um snapshot e restaure com a opção de criptografia habilitada.
O Secrets Manager criptografa os segredos com um CMK do KMS. A referência dinâmica d