AWS KMS: Chave Gerenciada pela AWS ou CMK? Guia Prático para Criptografia no S3

Você acabou de habilitar a criptografia no seu bucket S3 e se deparou com a escolha entre AWS Managed Key e Customer Managed Key (CMK) — e a diferença não é apenas de nomenclatura. A decisão impacta diretamente controle operacional, custos de API e capacidade de auditoria. Este guia sobre AWS KMS resolve essa escolha com critérios objetivos.

TL;DR — AWS KMS: Chave Gerenciada pela AWS vs. CMK

Critério AWS Managed Key Customer Managed Key (CMK)
Custo de armazenamento Gratuito ~$1/mês por chave
Custo por chamada de API Cobrado normalmente Cobrado normalmente
Controle de política de chave Não Sim (total)
Rotação automática A cada 1 ano Opcional (configurável)
Compartilhamento entre contas Não Sim
Auditoria granular via CloudTrail Parcial Completa
Caso de uso típico Workloads internos sem requisitos de compliance rígidos Dados regulados, multi-conta, acesso condicional

Como o AWS KMS Funciona na Prática

O KMS não armazena seus dados — ele protege as chaves de dados que o S3 usa para criptografar objetos. O S3 usa envelope encryption: gera uma chave de dados simétrica (AES-256), criptografa o objeto com ela, depois chama o KMS para criptografar a própria chave de dados. O objeto no bucket carrega a chave de dados criptografada junto com o conteúdo.

Na leitura, o S3 chama kms:Decrypt para recuperar a chave de dados em texto claro, descriptografa o objeto em memória e entrega ao cliente. Cada operação de leitura ou escrita gera uma chamada ao KMS — isso é o que aparece na sua fatura.

sequenceDiagram participant App as Aplicação participant S3 as Amazon S3 participant KMS as AWS KMS (CMK) App->>S3: PutObject (dado em texto claro) S3->>KMS: GenerateDataKey (usando CMK) KMS-->>S3: Chave de dados plaintext + versão criptografada S3->>S3: Criptografa objeto com chave plaintext S3->>S3: Descarta chave plaintext S3->>S3: Armazena objeto + chave de dados criptografada S3-->>App: 200 OK App->>S3: GetObject S3->>KMS: Decrypt (chave de dados criptografada) KMS-->>S3: Chave de dados em texto claro S3->>S3: Descriptografa objeto em memória S3-->>App: Objeto descriptografado
  1. PUT Object: S3 solicita ao KMS uma nova chave de dados via GenerateDataKey.
  2. KMS responde com a chave em texto claro e a versão criptografada pela CMK.
  3. S3 criptografa o objeto com a chave em texto claro, descarta a versão plaintext e armazena o objeto junto com a chave de dados criptografada.
  4. GET Object: S3 chama Decrypt no KMS para recuperar a chave de dados e descriptografar o objeto.

AWS Managed Key vs. CMK — Quando Cada Uma Faz Sentido

A AWS Managed Key (aws/s3) é criada automaticamente quando você habilita SSE-KMS sem especificar uma chave. Você não paga pelo armazenamento dela, mas também não controla sua política. Não é possível conceder acesso a outras contas, adicionar condições de contexto de criptografia ou revogar acesso granularmente. Para a maioria dos workloads internos sem requisitos de compliance externos, ela é suficiente.

A CMK entra em cena quando você precisa de controle real. Casos concretos: bucket compartilhado entre contas AWS diferentes, necessidade de revogar acesso de uma aplicação específica sem afetar outras, auditoria de qual role chamou Decrypt e quando, ou conformidade com normas que exigem gestão explícita de chaves (PCI-DSS, HIPAA, LGPD em contextos regulados).

Pense na AWS Managed Key como a fechadura padrão do prédio — funciona, mas o síndico (AWS) guarda a cópia. A CMK é a fechadura que você instalou: você controla quem tem cópia, quando troca e quem entrou no registro.

Estrutura de Custos do AWS KMS

O custo tem duas dimensões independentes: armazenamento de chaves e chamadas de API. A confusão mais comum é achar que usar AWS Managed Key elimina todos os custos de KMS — não elimina. As chamadas de API são cobradas da mesma forma.

  • Armazenamento de chave: AWS Managed Keys são gratuitas. CMKs custam aproximadamente $1/mês por chave ativa. Verifique o valor atual na página de preços do KMS.
  • Chamadas de API: As primeiras 20.000 requisições por mês são gratuitas. Acima disso, há cobrança por requisição. Workloads com alto volume de leitura em S3 podem gerar custos significativos — cada GetObject com SSE-KMS resulta em uma chamada Decrypt.
  • Chaves de importação e HSM dedicado: Modelos com material de chave importado ou CloudHSM têm estrutura de custo diferente. Consulte a documentação oficial para esses cenários.

Se o volume de chamadas é uma preocupação, o S3 suporta cache de chaves de dados via S3 Bucket Keys — isso reduz o número de chamadas ao KMS agrupando operações sob uma única chave de dados por bucket, diminuindo o custo de API em workloads de alto throughput.

Criando e Configurando uma CMK para S3 via AWS CLI

O fluxo completo envolve criar a chave, definir sua política, habilitar rotação e configurar o bucket para usá-la. Cada etapa tem uma razão operacional — a política de chave é o que determina quem pode usar a CMK, e ela precisa incluir explicitamente o root da conta para evitar que você perca acesso à própria chave.

1. Criar a CMK com metadados descritivos

aws kms create-key \
  --description "CMK para bucket S3 de dados regulados" \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS \
  --region us-east-1

O comando retorna o KeyId e o ARN da chave. Anote o ARN — você vai precisar dele nas próximas etapas.

2. Criar um alias legível para a chave

aws kms create-alias \
  --alias-name alias/s3-dados-regulados \
  --target-key-id <KeyId-retornado-acima> \
  --region us-east-1

3. Habilitar rotação automática anual

aws kms enable-key-rotation \
  --key-id alias/s3-dados-regulados \
  --region us-east-1

4. Aplicar política de chave

A política abaixo concede acesso administrativo ao root da conta e permissão de uso criptográfico a uma role específica. O bloco do root é obrigatório — sem ele, você pode criar uma chave que nenhuma entidade consegue gerenciar.

🔽 Clique para expandir — Política de Chave KMS (JSON) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key by application role",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/MinhaAppRole"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}
aws kms put-key-policy \
  --key-id alias/s3-dados-regulados \
  --policy-name default \
  --policy file://kms-key-policy.json \
  --region us-east-1

5. Configurar o bucket S3 para usar a CMK

aws s3api put-bucket-encryption \
  --bucket meu-bucket-regulado \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/<seu-key-id>"
      },
      "BucketKeyEnabled": true
    }]
  }' \
  --region us-east-1

O parâmetro BucketKeyEnabled: true ativa o S3 Bucket Keys, que reduz chamadas ao KMS agrupando operações — especialmente relevante para buckets com alto volume de objetos.

IAM: Permissões Mínimas para Acesso ao Bucket com CMK

Um erro frequente em produção: a role da aplicação tem acesso ao S3, mas não tem permissão de kms:Decrypt. O resultado é um erro AccessDenied que aparece como falha no S3, não no KMS — o que leva o time a investigar bucket policy quando o problema está na chave.

🔽 Clique para expandir — Política IAM mínima para leitura/escrita com CMK 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3Access",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::meu-bucket-regulado/*"
    },
    {
      "Sid": "KMSAccess",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/<seu-key-id>"
    }
  ]
}

Diagnóstico: AccessDenied que Parece Ser do S3, Mas É do KMS

O cenário clássico: aplicação em produção começa a falhar com AccessDenied ao fazer GetObject. O time verifica bucket policy, ACLs, block public access — tudo parece correto. O erro persiste.

O que aconteceu de verdade: a role da aplicação foi recriada (ou a política foi atualizada) e perdeu a permissão kms:Decrypt. O S3 retorna AccessDenied porque não consegue descriptografar o objeto, mas a mensagem de erro não menciona KMS explicitamente na maioria dos SDKs.

A verificação correta começa no CloudTrail, não no S3:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --region us-east-1

Se você ver eventos Decrypt com errorCode: AccessDenied no CloudTrail, o problema está na política da CMK ou na política IAM da role — não no bucket. Verifique qual principal está tentando a chamada e compare com a política de chave atual:

aws kms get-key-policy \
  --key-id alias/s3-dados-regulados \
  --policy-name default \
  --region us-east-1

Esse padrão — sintoma no S3, causa no KMS — é o que mais consome tempo em diagnóstico de acesso. O CloudTrail com CMK é o que torna esse diagnóstico possível em minutos em vez de horas. Com AWS Managed Key, a visibilidade é mais limitada.

Verificando o Status da Chave e Rotação

Antes de confiar que uma chave está operacional, confirme seu estado e se a rotação está ativa. Uma chave no estado Disabled ou PendingDeletion causa falhas silenciosas em operações de escrita — novos objetos não são criptografados e o S3 retorna erro.

aws kms describe-key \
  --key-id alias/s3-dados-regulados \
  --region us-east-1
aws kms get-key-rotation-status \
  --key-id alias/s3-dados-regulados \
  --region us-east-1
stateDiagram-v2 [*] --> Enabled : Chave criada Enabled --> Disabled : DisableKey Disabled --> Enabled : EnableKey Enabled --> PendingDeletion : ScheduleKeyDeletion
(7-30 dias) Disabled --> PendingDeletion : ScheduleKeyDeletion PendingDeletion --> Enabled : CancelKeyDeletion PendingDeletion --> Deleted : Prazo expirado Deleted --> [*] : Irreversível
  1. Enabled: Estado operacional normal. Chave disponível para uso criptográfico.
  2. Disabled: Chave existe mas não pode ser usada. Objetos já criptografados não podem ser descriptografados até reabilitação.
  3. PendingDeletion: Período de espera configurável (7-30 dias). Reversível antes do prazo.
  4. Deleted: Irreversível. Dados criptografados exclusivamente por esta chave são permanentemente inacessíveis.

Conclusão e Próximos Passos com AWS KMS

Para a maioria dos buckets S3 sem requisitos de compliance externos, a AWS Managed Key com S3 Bucket Keys habilitado é o ponto de partida correto — sem custo de armazenamento de chave e com redução de chamadas de API. Quando você precisar de controle granular de acesso, compartilhamento entre contas ou auditoria completa via CloudTrail, migre para uma CMK.

A migração de SSE-S3 ou AWS Managed Key para CMK em um bucket existente é feita via put-bucket-encryption — novos objetos passam a usar a CMK, objetos existentes mantêm a criptografia anterior até serem reescritos.

Glossário — Termos Essenciais do AWS KMS

Termo Definição
CMK (Customer Managed Key) Chave KMS criada e gerenciada pelo cliente, com controle total de política, rotação e acesso.
AWS Managed Key Chave criada e gerenciada pela AWS em nome do serviço (ex: aws/s3). Sem controle de política pelo cliente.
Envelope Encryption Padrão onde uma chave de dados criptografa o conteúdo, e o KMS criptografa a chave de dados. Usado pelo S3 com SSE-KMS.
S3 Bucket Keys Funcionalidade que reduz chamadas ao KMS agrupando operações sob uma chave de dados por bucket.
Key Policy Documento de política JSON que define quem pode usar e gerenciar uma CMK. Tem precedência sobre políticas IAM.

Related Posts

Comentários

Postar um comentário