Impondo a Criptografia Padrão em Todos os Lugares

Confiar que as pessoas se lembrarão de ativar a criptografia inevitavelmente gera falhas. A abordagem robusta é tornar a criptografia o padrão e bloquear tudo que não estiver criptografado.

Isso muda a estratégia: em vez de esperar a conformidade, você passa a impô-la estruturalmente em toda a conta.

Agora, todo bucket do S3 aplica criptografia padrão; os objetos são criptografados no lado do servidor mesmo que o remetente não solicite isso.

Você pode definir o padrão como SSE-KMS usando uma chave específica, para que todos os objetos novos sejam protegidos e auditáveis sem esforço a cada envio.

Para ir além, uma política de bucket pode negar qualquer PutObject que não solicite a criptografia exigida.

Isso rejeita gravações que tentem contornar a criptografia, garantindo que nada seja armazenado sem proteção. Esse é um padrão comum para buckets que contêm dados sensíveis.

Você pode ativar a criptografia padrão do EBS por região.

Depois de ativada, todo novo volume e snapshot do EBS nessa região será criptografado automaticamente com a chave KMS escolhida. Isso elimina o risco de iniciar acidentalmente volumes sem criptografia.

As políticas de controle de serviço (SCPs) impõem a criptografia em uma organização inteira.

Uma SCP pode negar ações como criar uma instância ou um volume do RDS sem criptografia em qualquer conta-membro. Como as SCPs limitam as permissões, ninguém, nem mesmo um administrador, pode contorná-las.

As regras do AWS Config verificam continuamente se os recursos estão criptografados.

• As regras sinalizam volumes, buckets e bancos de dados sem criptografia.
• Combinadas com a correção automática, elas podem corrigir ou relatar desvios automaticamente.

Isso oferece uma garantia contínua, além das configurações verificadas em um único momento.

Os padrões podem exigir não apenas "qualquer criptografia", mas uma chave KMS específica.

As políticas usam condições para exigir um ARN de chave específico, garantindo que os dados sejam criptografados com uma chave controlada e auditada pela sua equipe, em vez de uma chave padrão gerenciada pela AWS.

A postura mais forte combina os dois tipos:

• Controles preventivos (SCPs, políticas de bucket e configurações padrão) impedem a criação de recursos sem criptografia.
• Controles de detecção (Config e Security Hub) identificam tudo que passar despercebido.

A defesa em profundidade também se aplica à criptografia.

Antecipe a imposição, deslocando-a para a esquerda, ao verificar os modelos de infraestrutura como código antes da implantação.

Ferramentas e verificações de políticas personalizadas confirmam que o CloudFormation ou o Terraform define a criptografia, para que recursos não conformes sejam bloqueados no fluxo de implantação, e não em produção.

A criptografia padrão geralmente significa criptografia em repouso, mas você também deve impor a criptografia em trânsito.

Uma política de bucket do S3 que usa a condição aws:SecureTransport nega qualquer solicitação que não seja feita por TLS. Combinar isso com a criptografia padrão em repouso garante que os dados estejam protegidos tanto onde ficam armazenados quanto enquanto se movimentam.

Uma estratégia completa: ative a criptografia padrão para S3 e EBS, negue a criação sem criptografia com SCPs e políticas de bucket e verifique tudo com Config e Security Hub.

A criptografia deixa de ser opcional e passa a ser garantida.

Escolha a imposição mais forte.

Você aprendeu a impor a criptografia padrão.

• A criptografia padrão no S3 e no EBS torna a proteção automática.
• SCPs e políticas de bucket negam a criação sem criptografia em toda a organização.
• Config e Security Hub detectam tudo que passar despercebido.