KMS, ACM e padrões de criptografia

A criptografia é um controle de segurança fundamental que protege a confidencialidade dos dados mesmo quando a mídia de armazenamento é comprometida ou o acesso é obtido por outros meios. A AWS fornece criptografia para dados em repouso (armazenados em bancos de dados, S3 e EBS) e em trânsito (em movimento pelas redes). Serviços principais: o AWS Key Management Service (KMS) gerencia chaves de criptografia para criptografia em repouso. O AWS Certificate Manager (ACM) provisiona e gerencia certificados TLS para criptografia em trânsito. Entender quando e como aplicar cada um é essencial para o domínio de Arquitetura de Segurança do SAA-C03.

O AWS KMS é um serviço totalmente gerenciado para criar e controlar chaves de criptografia. O KMS usa Hardware Security Modules (HSMs) para proteger as chaves — o material da chave nunca deixa o HSM sem criptografia. O KMS integra-se à maioria dos serviços da AWS para criptografia no servidor. Tipos de chave: AWS Managed Keys (gratuitas, rotacionadas automaticamente todos os anos; você não pode controlá-las diretamente), Customer Managed Keys (CMK) (US$ 1/mês cada; você controla a rotação, a política da chave e a exclusão). O Custom Key Store usa seu próprio cluster do CloudHSM para requisitos de conformidade que exigem HSMs dedicados.

Toda chave do KMS tem uma política de chave — uma política baseada em recurso que controla quem pode usar e gerenciar a chave. Ao contrário das políticas do IAM, que são baseadas em identidade, as políticas de chave são obrigatórias: a política de chave deve conceder explicitamente o acesso para que as políticas do IAM entrem em vigor. Prática recomendada: separar a administração da chave (quem pode gerenciá-la) do uso da chave (quais serviços e funções podem criptografar/descriptografar). Use concessões de chave para acesso delegado temporário — por exemplo, conceda a um cluster do EMR o uso temporário de uma chave do KMS para um trabalho sem modificar a política da chave.

O KMS usa criptografia envelope para proteger grandes volumes de dados com eficiência. Você não pode criptografar diretamente mais de 4 KB com uma chave do KMS. Em vez disso: o KMS gera uma Data Encryption Key (DEK) — uma chave aleatória usada para criptografar seus dados reais localmente. A DEK é então criptografada pela sua chave do KMS (a Key Encryption Key). Você armazena a DEK criptografada junto com os dados criptografados. Para descriptografar, primeiro chama o KMS para descriptografar a DEK e, em seguida, usa localmente a DEK em texto simples para descriptografar os dados. É assim que funcionam internamente a criptografia do S3, do EBS e do RDS.

A rotação de chaves é uma prática recomendada de segurança que substitui periodicamente o material criptográfico da chave, limitando a janela de exposição caso uma chave seja comprometida. Para Customer Managed Keys, você pode habilitar a rotação automática anual — o KMS gera um novo material de chave e o utiliza em novas operações de criptografia, mantendo o material antigo para descriptografar dados existentes. As AWS Managed Keys são rotacionadas automaticamente todos os anos. O material de chave importado NÃO oferece suporte à rotação automática (você deve rotacioná-lo manualmente). Após a rotação, novas operações do KMS usam automaticamente o novo material de chave, sem alterações na aplicação.

O S3 oferece três opções de criptografia no servidor: SSE-S3 — o S3 gerencia as chaves usando AES-256, gratuitamente, com controle mínimo. SSE-KMS — usa uma chave do KMS (gerenciada pela AWS ou CMK), fornece trilha de auditoria da chave no CloudTrail, oferece suporte a políticas de chave e gera um custo por chamada de API do KMS. SSE-C — você fornece e gerencia o material da chave em cada solicitação; o S3 nunca armazena a chave. Use SSE-KMS quando precisar auditar quem usou a chave e quando. Use SSE-S3 para dados de baixa sensibilidade nos quais simplicidade e custo sejam importantes. Imponha a criptografia com uma política de bucket que negue PutObject sem criptografia.

O AWS Certificate Manager (ACM) provisiona, gerencia e renova automaticamente certificados SSL/TLS para serviços da AWS sem custo. Os certificados do ACM podem ser usados com ALB, NLB, CloudFront, API Gateway e AppSync. O ACM gerencia automaticamente o ciclo de vida dos certificados — renova os certificados 60 dias antes da expiração e implanta a renovação de forma transparente. Você pode solicitar certificados para domínios que possui (validados por DNS ou e-mail) ou importar certificados de terceiros. Os certificados do ACM NÃO podem ser baixados — eles ficam vinculados ao serviço da AWS ao qual estão associados.

ACM Private CA (Certificate Authority) permite criar uma hierarquia de CA privada e totalmente gerenciada para emitir certificados para recursos internos — instâncias EC2, contêineres, APIs internas e dispositivos de IoT. Diferentemente dos certificados públicos da ACM (usados com serviços acessíveis pela internet), os certificados de CA privada podem ser emitidos para qualquer nome de host ou endereço IP interno. Use a Private CA para: TLS mútuo (mTLS) entre microsserviços, autenticação baseada em certificados para VPN e requisitos de conformidade para PKI interna. A Private CA custa US$ 400 por mês pela CA, mais US$ 0,75 por certificado emitido.

Para a criptografia de volumes EBS, habilite-a no momento da criação do volume (ou copie um volume existente com a criptografia habilitada). Todos os dados do volume, incluindo snapshots, são criptografados usando a chave KMS especificada. A criptografia do EBS é transparente para o sistema operacional — não são necessárias alterações na aplicação. Para a criptografia do RDS, habilite-a ao criar a instância de banco de dados; não é possível criptografar diretamente uma instância RDS existente que não esteja criptografada. Alternativa: crie um snapshot criptografado a partir de uma instância não criptografada e restaure-o em uma nova instância criptografada. Os snapshots criptografados de EBS e RDS permanecem criptografados quando são copiados.

Entender a diferença entre criptografia no servidor e no cliente é importante para a prova SAA-C03. Criptografia no servidor: a AWS criptografa os dados depois de recebê-los e os descriptografa antes de entregá-los — os dados ficam em texto simples entre sua aplicação e a AWS. Criptografia no cliente: você criptografa os dados antes de enviá-los à AWS — a AWS armazena apenas o texto cifrado e nunca vê o texto simples. Use a criptografia no cliente para obter o mais alto nível de sensibilidade dos dados quando não for possível confiar no provedor de nuvem para lidar com texto simples, como em registros de saúde ou dados financeiros sujeitos a regulamentações rigorosas.

As chaves KMS podem ser compartilhadas entre contas da AWS em cenários de criptografia entre contas. Por exemplo, se a aplicação da Account A gravar dados criptografados em um bucket do S3 pertencente à Account B, a chave KMS da Account A deverá permitir que o principal da Account B a utilize. Configure a política de chave do KMS na Account A para conceder acesso entre contas e, em seguida, crie uma política do IAM na Account B para permitir que a função use a chave da Account A. Esse padrão é comum em arquiteturas de compartilhamento de dados e de várias contas, nas quais uma conta central gerencia as chaves de criptografia.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: o KMS gerencia chaves de criptografia com proteção HSM e oferece suporte a CMKs para controle de acesso detalhado e trilhas de auditoria, a ACM provisiona e renova automaticamente certificados TLS para serviços da AWS sem custo e a criptografia pode ser aplicada no servidor (KMS) ou no cliente, sendo a opção no servidor o padrão mais comum para cargas de trabalho nativas da AWS. Imponha a criptografia com políticas de bucket que neguem operações não criptografadas. A seguir, exploraremos GuardDuty, Inspector e Macie.