Amazon SCS-C02: Criptografia, KMS e Segredos — Guia de estudos

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Faz parte do AWS Security Specialty SCS-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Tipos de Chave, Políticas e Controle de Acesso do AWS KMS

O AWS KMS suporta três categorias gerais de chaves, e a escolha da chave certa dita quem controla o material da chave, onde ele reside e como pode ser rotacionado. As chaves de propriedade da AWS (AWS-owned keys) são invisíveis para você, não têm custo e são usadas por serviços como o S3 quando você habilita o SSE-S3. As chaves gerenciadas pela AWS (AWS-managed keys), com o alias aws/<service>, permitem que um serviço criptografe em seu nome, mas você não pode modificar a política de chave delas, motivo pelo qual são inadequadas para acesso entre contas (cross-account) ou governança refinada (fine-grained). As chaves gerenciadas pelo cliente (CMKs) são o carro-chefe: você controla a política da chave, a rotação (automática anual ou sob demanda), as concessões (grants), os aliases e a janela de exclusão.

Duas variantes especializadas são importantes. O material de chave importado é usado quando requisitos regulatórios ou de BYOK (Bring Your Own Key) forçam você a gerar o material da chave fora da AWS e importá-lo para uma chave do KMS. O material importado é a única maneira de configurar uma expiração explícita para o material da chave — CMKs geradas pela AWS nunca expiram. Você não pode habilitar a rotação anual automática da AWS em chaves importadas; você mesmo deve reimportar o material. As chaves Multi-Region compartilham o mesmo ID de chave e material entre Regiões por meio de chaves de réplica, de modo que um texto cifrado (ciphertext) produzido em us-east-1 pode ser descriptografado em us-west-1 sem recriptografia. Cada réplica tem sua própria política de chave e aliases independentes, mas o material criptográfico é sincronizado.

O controle mais incompreendido é a política de chave do KMS (key policy). Diferentemente da maioria dos recursos da AWS, onde as políticas do IAM por si só concedem acesso, as chaves do KMS usam sua política de chave como a autorização raiz. Uma política do IAM que concede kms:Decrypt em uma chave é inerte, a menos que a política da chave também delegue o acesso ao IAM (através de um Principal da raiz da conta mais uma declaração apropriada, ou nomeando o principal diretamente). É por isso que um engenheiro com AdministratorAccess ainda pode receber AccessDenied ao chamar Decrypt em uma CMK cuja política não confia na conta. A declaração de delegação canônica se parece com isto:

{
  "Sid": "EnableIAMPermissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Concessões (Grants) e condições ViaService adicionam restrições em camadas — por exemplo, forçando que uma chave seja usada apenas através do S3 em uma Região específica com kms:ViaService: s3.us-east-1.amazonaws.com.

Criptografia no Lado do Servidor (Server-Side) e no Lado do Cliente (Client-Side)

Para o S3, as duas opções comuns de criptografia no lado do servidor diferem principalmente em controle e auditabilidade:

• SSE-S3 (AES-256): O S3 gerencia as chaves inteiramente; não há política de chave visível para o cliente, nem eventos de descriptografia por chave no CloudTrail, e nenhuma governança entre contas. Adequado para criptografia em repouso (at rest) básica, mas insuficiente quando a conformidade (compliance) exige provar quem descriptografou os dados.
• SSE-KMS: Usa uma CMK que você controla; cada chamada de descriptografia é registrada, a política da chave impõe o acesso e você pode restringir pelo contexto de criptografia (encryption context). Custa mais por solicitação e consome cotas de TPS do KMS, então as chaves de bucket (bucket keys) (BucketKeyEnabled: true) devem ser habilitadas para reduzir drasticamente as chamadas ao KMS.

A criptografia no lado do cliente usando o AWS Encryption SDK é apropriada quando os dados devem ser criptografados antes de saírem da aplicação, ou quando o serviço de armazenamento nunca deve ver o texto plano (plaintext). Cargas de trabalho de alta vazão (high-throughput) devem envolver o SDK com o gerenciador de materiais criptográficos com cache (CachingCryptoMaterialsManager), que reutiliza chaves de dados (data keys) em muitas mensagens dentro de limites configuráveis de bytes, mensagens e TTL. Sem o cache, cada chamada encrypt aciona uma solicitação GenerateDataKey, saturando rapidamente as cotas de solicitação do KMS e inflando o custo.

from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
    master_key_provider=mkp, cache=cache,
    max_age=600.0, max_messages_encrypted=10000)

Secrets Manager e Parameter Store

O Secrets Manager armazena credenciais criptografadas com uma CMK do KMS e suporta rotação automática através de uma função Lambda — a AWS fornece modelos para RDS, Redshift e DocumentDB, e Lambdas personalizadas lidam com qualquer outra coisa. A rotação executa uma máquina de estados de quatro passos (createSecret, setSecret, testSecret, finishSecret) que prepara as novas credenciais sob o rótulo AWSPENDING antes de promovê-las para AWSCURRENT. As aplicações devem capturar falhas de autenticação, atualizar o segredo e tentar novamente — esse padrão elimina o tempo de inatividade (downtime) porque a credencial anterior permanece válida via AWSPREVIOUS por um breve período.

Quando a Lambda de rotação é executada dentro de uma VPC (típico para alcançar uma instância RDS privada), ela precisa de acesso de rede de saída (outbound) para o ponto de extremidade (endpoint) do serviço Secrets Manager. Em uma VPC privada sem NAT, você deve implantar um ponto de extremidade de VPC de interface (com.amazonaws.<region>.secretsmanager) e permitir que o security group da Lambda alcance o endpoint na porta 443. Esquecer isso é uma falha clássica: a rotação parece configurada, mas toda invocação expira (times out).

Para resiliência entre Regiões, use uma chave KMS Multi-Region e o recurso de segredo de réplica (replica-secret) do Secrets Manager. O segredo primário em us-east-1 é criptografado com a CMK primária; a réplica em us-west-1 descriptografa usando a CMK de réplica. Aliases como alias/prod-db podem ser apontados para um novo ID de chave sob demanda para uma rotação rápida de chaves sem alterar o código da aplicação.

O tipo SecureString do Parameter Store é uma alternativa mais leve quando você não precisa de rotação. Ambos os serviços expõem referências dinâmicas no CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}) para que os modelos de stack nunca incorporem texto plano.

Criptografia de EBS, RDS, Aurora e Snapshots

A criptografia em repouso é habilitada por volume ou por instância no momento da criação e não pode ser modificada em um recurso existente. O padrão de remediação para um recurso não criptografado e fora de conformidade (noncompliant) é uma cópia de snapshot com criptografia:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region us-east-1 --encrypted \
  --kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...

Para RDS e Aurora, restaure o snapshot criptografado em uma nova instância e faça a transição (cut over). A recuperação entre contas (cross-account) exige o compartilhamento do snapshot e a concessão à conta de destino das permissões kms:CreateGrant e kms:Decrypt na CMK por meio da política da chave — compartilhar apenas o snapshot falhará porque o destino não consegue descriptografar a chave de dados (data key). A criptografia padrão do EBS no nível da conta deve ser habilitada para que os volumes recém-criados sejam sempre criptografados, independentemente do comportamento do chamador (caller).

TLS: ACM e Políticas do ALB

O ACM emite e renova automaticamente certificados públicos sem custo quando vinculados a serviços integrados (ALB, CloudFront, API Gateway). Os certificados não podem ser exportados, então a terminação de TLS no EC2 exige o ACM Private CA (para certificados privados que você pode exportar) ou um certificado importado. Um padrão pragmático: terminar o TLS público no ALB com um certificado do ACM e usar um certificado autoassinado ou de uma CA privada para o salto (hop) do ALB para o EC2 se a criptografia de ponta a ponta for necessária. Force os clientes a usarem cifras modernas com uma política de segurança como ELBSecurityPolicy-TLS13-1-2-2021-06, que desativa o TLS 1.0/1.1 e conjuntos de cifras fracos.

Armadilhas Comuns

IAM sem política de chave. Conceder kms:Decrypt em uma política do IAM enquanto a política de chave da CMK omite o principal da conta resulta em AccessDenied. O KMS trata a política de chave como autoritativa; as permissões do IAM podem apenas restringir ainda mais o que a política de chave permite.

Lambda de rotação sem endpoint de VPC. Se o Lambda executa em sub-redes privadas e a VPC não tem NAT nem endpoint de interface do secretsmanager, a chamada de rotação para secretsmanager.<region>.amazonaws.com não consegue resolver ou se conectar. O security group no endpoint também deve permitir a porta 443 a partir do SG do Lambda.

SSE-S3 equiparado ao SSE-KMS. O SSE-S3 usa uma chave de propriedade da AWS sem política editável pelo cliente, sem registro de descriptografia por objeto no CloudTrail e sem compartilhamento de chave entre contas. Ele atende aos requisitos básicos de “criptografia em repouso”, mas não pode impor quais principais descriptografam objetos específicos — apenas o SSE-KMS com uma CMK fornece essa governança.

Problema Prático: Cenário de Caso de Uso

Cenário: A Meridian Financial opera uma AWS Organization com várias contas, incluindo uma conta de Segurança, contas separadas de Prod/NonProd, microsserviços em ECS/EKS com um ALB na frente, clusters RDS/Aurora, instâncias EC2 com volumes EBS e data lakes no S3. Desenvolvedores e automações atualmente usam uma mistura de chaves gerenciadas pela AWS, parâmetros SSM em texto plano e compartilhamento manual ocasional de snapshots entre contas.

Desafio: Um engenheiro compartilhou acidentalmente um snapshot não criptografado do RDS com uma conta de terceiros e várias credenciais de API foram descobertas armazenadas como parâmetros SecureString em texto plano, criando risco de exfiltração de dados e acesso não autorizado para restauração.

Abordagem Recomendada:

1. Criar uma CMK simétrica gerenciada pelo cliente (customer-managed) do AWS KMS na conta de Segurança, com escopo de organização, com uma política de chave que concede uso via aws:PrincipalOrgID para as contas-membro e habilitar a rotação automática; usar grants para operações de curta duração entre contas.
2. Remediar artefatos existentes copiando o snapshot não criptografado do RDS e quaisquer snapshots do EBS, selecionando a nova CMK para produzir cópias criptografadas, e em seguida, excluir os snapshots originais não criptografados; definir os padrões da conta para que novos recursos RDS e EBS sejam criados criptografados por padrão.
3. Migrar segredos para o AWS Secrets Manager (ou SSM Parameter Store SecureString) criptografados com a CMK, habilitar a rotação automática do Secrets Manager para credenciais de banco de dados via Lambda e restringir o acesso usando políticas baseadas em recursos e perfis IAM de privilégio mínimo.
4. Impor a criptografia em trânsito provisionando certificados TLS gerenciados pelo ACM e anexando-os aos ALBs com uma política de TLS moderna (TLS 1.2/1.3), e configurar bancos de dados e clientes para exigir conexões TLS.
5. Prevenir a recorrência com guardrails: aplicar Service Control Policies para negar a criação/compartilhamento de snapshots não criptografados e puts não criptografados no S3, habilitar regras do AWS Config para recursos criptografados e monitorar o uso do KMS e do Secrets Manager via CloudTrail e CloudWatch Alarms.

Justificativa: CMKs centralizadas com políticas no nível da organização, recodificação automatizada, uso do Secrets Manager para o ciclo de vida dos segredos, imposição de TLS e guardrails preventivos seguem as melhores práticas da AWS de privilégio mínimo e defesa em profundidade para eliminar segredos em texto plano e acesso não autorizado a snapshots.

CMKs Gerenciadas pelo Cliente: Multirregião, Material Importado e Políticas de Chave

Uma CMK gerenciada pelo cliente é o plano de controle para cada operação criptográfica em dados que você possui na AWS. As três propriedades que mais frequentemente determinam se um design é bem-sucedido ou produz uma interrupção são a topologia de Região da chave, a origem de seu material de chave e a política anexada a ela.

Chaves multirregionais são um conjunto de chaves do KMS em diferentes Regiões que compartilham o mesmo ID de chave e, crucialmente, o mesmo material de chave subjacente. Elas não são replicadas automaticamente da mesma forma que as tabelas globais do DynamoDB — você cria réplicas explicitamente a partir de uma chave primária usando ReplicateKey. Como o material de chave é idêntico entre as réplicas, o texto cifrado produzido em us-east-1 pode ser descriptografado em us-west-1 sem chamadas entre Regiões para o KMS. Esta é exatamente a propriedade necessária ao replicar um segredo do Secrets Manager entre Regiões: o segredo de réplica na Região de failover deve ser descriptografável localmente, tanto para eliminar a latência entre Regiões em cada GetSecretValue quanto para sobreviver a uma interrupção regional da primária. Uma CMK de Região única não pode dar suporte a uma réplica do Secrets Manager em outra Região, então o padrão correto é criptografar o segredo primário com uma CMK multirregional, replicar a chave para a Região de destino e, em seguida, replicar o segredo apontando para a CMK de réplica.

aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
  --replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
  --secret-id prod/db \
  --add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123

Material de chave importado (origem externa, Origin=EXTERNAL) existe quando você gera o material bruto AES-256 fora da AWS e o importa para um invólucro de chave do KMS. A AWS nunca tem uma cópia desse material fora da memória protegida do HSM, e não há backup. Se você excluir o material de chave importado — seja via DeleteImportedKeyMaterial ou porque sua data de expiração passou — a chave se torna PendingImport e todo o texto cifrado produzido sob essa chave se torna irrecuperável, a menos que você reimporte exatamente os mesmos bytes. Este é o caminho de recuperação quando, por exemplo, um volume EBS falha ao ser anexado porque sua chave de dados criptografada não pode ser descriptografada: reimporte o material de chave idêntico do seu escrow offline, e o volume se torna utilizável novamente. Não há restauração do lado da AWS, nenhum truque de rotação e nenhum ticket de suporte que recupere material de chave importado excluído. Trate a cópia offline como infraestrutura de tier zero.

Políticas de chave são a raiz de confiança para cada chave do KMS. Diferente do IAM sozinho, o KMS exige uma permissão explícita na própria política de chave; uma política do IAM que concede kms:Decrypt é ineficaz a menos que a política de chave delegue ao IAM ("Principal": {"AWS": "arn:aws:iam::111122223333:root"} combinado com uma declaração de condição). Para uso entre contas, a política da chave deve nomear explicitamente a conta ou o principal externo, e a conta externa deve então conceder permissão aos seus próprios usuários via IAM. Esquecer o lado da política de chave é a causa mais comum de falhas do Secrets Manager entre contas — a política de recurso do Secrets Manager permite que o principal externo chame GetSecretValue, mas o Decrypt subjacente falha porque a CMK ainda recusa o chamador.

Padrões do Secrets Manager e do Parameter Store SecureString

Tanto o Secrets Manager quanto o SSM Parameter Store SecureStrings delegam a criptografia para o KMS, mas eles diferem em custo, semântica de rotação e comportamento entre Regiões. O Secrets Manager suporta replicação multirregional nativa, versionamento com rótulos de preparação (AWSCURRENT, AWSPENDING) e rotação baseada em Lambda. O Parameter Store SecureString é mais barato, integra-se com caminhos hierárquicos e funciona bem para segredos no estilo de configuração que rotacionam com pouca frequência.

Para acesso entre contas, você deve atualizar tanto a política de recurso no segredo (ou a política do IAM na conta consumidora do Parameter Store) quanto a política de chave do KMS na CMK de criptografia. Assumir que apenas as permissões do Secrets Manager são suficientes está errado, porque o fluxo de trabalho de recuperação sempre executa um kms:Decrypt implícito na CMK; sem uma permissão na política de chave para a conta externa, o chamador recebe AccessDeniedException na etapa de Decrypt, mesmo que a política do próprio segredo seja satisfeita.

• Secrets Manager: rotação gerenciada, estrutura JSON, ~$0,40/segredo/mês, replicação multirregional integrada
• Parameter Store SecureString (Advanced): mais barato para muitos valores, 8 KB por parâmetro, sem replicação entre Regiões integrada
• Parameter Store SecureString (Standard): nível gratuito para parâmetros criptografados com KMS de até 4 KB, sem framework de rotação

Criptografia de Envelope, Bucket Keys e Grant Tokens

Criptografia de envelope (envelope encryption) significa que o KMS nunca toca no volume principal dos seus dados. Você chama GenerateDataKey, que retorna tanto uma chave de dados em texto plano (usada localmente para criptografar sua carga com AES-GCM) quanto uma cópia criptografada dessa chave de dados (armazenada junto com o texto cifrado). Para descriptografar, você chama Decrypt na chave de dados encapsulada e deriva novamente a chave em texto plano localmente. Esse padrão é essencial porque o KMS tem cotas de requisição (por Região, por chave) e preço por chamada de API. Se você criptografar cada registro de 4 KB com uma chamada Encrypt direta, atingirá limites de throttling e custos exorbitantes; se você gerar uma chave de dados por lote ou por arquivo, a taxa de transferência escala linearmente com sua biblioteca de criptografia local.

S3 Bucket Keys aplicam o mesmo princípio dentro do S3 para SSE-KMS. Sem uma bucket key, cada PUT e GET de um objeto SSE-KMS gera uma chamada GenerateDataKey ou Decrypt. Em um bucket recebendo milhares de objetos por segundo, isso produz tanto throttling no KMS quanto uma fatura surpreendente do KMS. Habilitar uma bucket key faz com que o S3 gere uma chave de curta duração no nível do bucket e a reutilize para muitos objetos, reduzindo o volume de requisições ao KMS em ordens de magnitude:

aws s3api put-bucket-encryption --bucket app-data \
  --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
      "BucketKeyEnabled":true}]}'

Grants são uma alternativa às políticas de chave para delegação temporária e de granularidade fina. Eles são importantes operacionalmente por causa da consistência eventual: após o retorno de CreateGrant, o grant não fica imediatamente visível para todos os endpoints do KMS na Região. Se um cliente tentar uma operação Encrypt alguns milissegundos depois, ele pode receber uma AccessDeniedException. O corpo da resposta de CreateGrant inclui uma string GrantToken que, quando passada em chamadas subsequentes ao KMS através do parâmetro --grant-tokens, força o KMS a honrar o grant imediatamente, independentemente do estado de propagação.

TOKEN=$(aws kms create-grant --key-id $KEY \
  --grantee-principal arn:aws:iam::111122223333:role/worker \
  --operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
  --grant-tokens "$TOKEN"

Confiar em tentativas com recuo exponencial (retry-with-backoff) em vez do grant token é uma mitigação válida, mas inferior — desperdiça latência e ainda falha sob carga. A resposta canônica é sempre: retorne o grant token do serviço que cria o grant e exija que os chamadores o apresentem em sua primeira operação.

Problema Prático: Cenário de Caso de Uso

Cenário: A Meridian Financial opera um ambiente AWS multi-contas que hospeda PII de clientes no S3, bancos de dados transacionais no RDS e processamento serverless via Lambda. Eles usam CMKs gerenciadas pelo cliente com material de chave importado para atender às regras regionais de custódia de chaves e replicam chaves para uma segunda região para recuperação de desastres.

Desafio: Uma auditoria recente encontrou uma política de chave do KMS configurada incorretamente que permitia descriptografias entre contas (cross-account), e um auditor externo precisa de acesso temporário para descriptografar um subconjunto de objetos S3; a Meridian também precisa de rotação segura de segredos e criptografia eficiente para objetos grandes para controlar os custos de requisição do KMS.

Abordagem Recomendada:

1. Rotacionar a política da CMK mal configurada no AWS KMS para uma política de privilégio mínimo que conceda explicitamente permissões apenas aos principals e roles IAM necessários, e criar uma CMK de réplica multi-regional para DR usando chaves multi-regionais do KMS.
2. Reimportar ou agendar o gerenciamento do ciclo de vida para o material de chave importado conforme as janelas de conformidade e habilitar notificações automáticas de expiração/rotação do material de chave usando o AWS Config e o EventBridge.
3. Para o auditor, criar um grant do KMS com um TTL curto e usar o grant token imediatamente na sessão de assume-role do auditor para permitir operações de descriptografia temporárias sem alterar a política da chave.
4. Mover credenciais de longa duração para o AWS Secrets Manager com rotação baseada em Lambda vinculada ao serviço subjacente (RDS ou chaves de API) e armazenar parâmetros de infraestrutura como SecureString no Systems Manager Parameter Store para itens não rotacionados, impondo a criptografia com a CMK e políticas estritas baseadas em recursos.
5. Implementar criptografia de envelope para objetos S3 grandes chamando GenerateDataKey (Encrypt/Decrypt) do KMS no código da aplicação ou via SDK da AWS, e habilitar S3 Bucket Keys para reduzir as requisições e o custo do KMS para criptografia do lado do servidor de objetos grandes.
6. Habilitar o logging do CloudTrail e o logging de uso de chaves do KMS, e criar Alarmes no CloudWatch/regras no GuardDuty para alertar sobre descriptografias inesperadas ou criações de grants.

Justificativa: Esta abordagem impõe o acesso com privilégio mínimo às chaves, preserva a conformidade para o material importado e a continuidade multi-regional, usa grants temporários para acesso seguro de terceiros, centraliza segredos com rotação e otimiza o uso e o custo do KMS de acordo com as melhores práticas da AWS.

← Logging · Todos os domínios · Proteção de Dados e S3 →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →