Intermediário

Automatizar controles padrão

Lição 12 · Módulo 3 — Operar com segurança

Well-Architected: SEC01-BP06

Controles como código

Com várias contas (lição 5), aplicar controles à mão vira divergência: cada conta fica um pouco diferente e ninguém sabe qual é a correta. A boa prática SEC01-BP06 pede práticas de DevOps para os controles padrão: defini-los em infraestrutura como código (IaC), versionar, testar no pipeline de CI/CD e implantar de forma automática.

Exemplos de controles que costumam ser padrão em toda a organização:

  • integração com o provedor de identidade central;
  • redes e firewalls de base;
  • locais padrão para guardar e analisar logs;
  • regras do AWS Config e padrões do Security Hub CSPM habilitados.

As ferramentas

EtapaFerramentasPapel
DefinirAWS CloudFormation, AWS CDK (gera templates CloudFormation), TerraformDescrever o controle de forma declarativa.
Versionar e revisarGit, pull request com aprovação obrigatóriaHistórico, comparação entre versões e quatro olhos em cada mudança.
Validar no pipelinecfn-lint, AWS CloudFormation Guard, CheckovBarrar erro de sintaxe, propriedade inválida ou configuração fora do padrão antes do deploy.
Implantar em escalaCloudFormation StackSets, Service Catalog, Account Factory do Control TowerLevar o mesmo template a várias contas e regiões, ou oferecê-lo em autosserviço.
Detectar desvioAWS Config, detecção de drift do CloudFormationPerceber quando o que está implantado deixou de bater com o código.
CorrigirRemediação do AWS Config com documentos de Automation do Systems ManagerVoltar o recurso ao estado esperado, manual ou automaticamente.

O cfn-lint valida templates contra os esquemas dos recursos e boas práticas. O Guard avalia dados JSON ou YAML contra regras de política como código. O Checkov é uma ferramenta de código aberto que procura configurações incorretas em Terraform, CloudFormation, CDK, Kubernetes e outros formatos.

Exemplo: template com controle e regra Guard

Um bucket de logs que já nasce com bloqueio de acesso público, criptografia e versionamento (exemplo a adaptar):

yaml — template.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
AWSTemplateFormatVersion: '2010-09-09'
Description: Exemplo a adaptar - bucket de logs com controles padrao
Resources:
LogsBucket:
Type: AWS::S3::Bucket
Properties:
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: aws:kms
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled

E a regra Guard que o pipeline usa para recusar qualquer bucket que não siga o padrão:

guard — s3.guard
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Exemplo a adaptar: buckets S3 precisam bloquear acesso público e ter criptografia padrão
let s3_buckets = Resources.*[ Type == 'AWS::S3::Bucket' ]
 
rule s3_bloqueio_acesso_publico when %s3_buckets !empty {
%s3_buckets.Properties.PublicAccessBlockConfiguration exists
%s3_buckets.Properties.PublicAccessBlockConfiguration {
BlockPublicAcls == true
BlockPublicPolicy == true
IgnorePublicAcls == true
RestrictPublicBuckets == true
}
}
 
rule s3_criptografia_padrao when %s3_buckets !empty {
%s3_buckets.Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
ServerSideEncryptionByDefault.SSEAlgorithm IN ['aws:kms', 'AES256']
<<Bucket S3 precisa de criptografia padrão (SSE-KMS ou SSE-S3)>>
}
}

No pipeline, as etapas de validação podem ser estas; qualquer falha devolve código de saída diferente de zero e interrompe o deploy:

bash
1
2
3
cfn-lint template.yaml
cfn-guard validate --rules s3.guard --data template.yaml
checkov -f template.yaml

Implantar em todas as contas e manter

O CloudFormation StackSets cria, atualiza ou remove stacks em várias contas e regiões com uma única operação. Com permissões gerenciadas pelo serviço no AWS Organizations, dá para ativar implantação automática: contas novas que entram em uma OU recebem o baseline sem ninguém pedir.

Depois do deploy, alguém pode mudar algo pelo console. O AWS Config avalia as regras e marca o recurso como não conforme; a remediação associada à regra usa documentos de Automation do Systems Manager, prontos ou próprios, aplicados manualmente ou de forma automática. Para o stack em si, a detecção de drift do CloudFormation mostra o que divergiu do template.

Armadilhas comuns

  • Mudar controles pelo console ou CLI: a mudança não fica no histórico e será desfeita, ou pior, copiada, no próximo deploy.
  • Esperar que cada time aplique à mão o que o time central definiu.
  • Time central aplicando controles de workload a pedido: vira gargalo; ofereça autosserviço.
  • Sem separação de funções: a mesma pessoa escreve, testa e implanta a automação de controles sem revisão.
  • Esquecer o backup: o Well-Architected pede estratégia de backup e recuperação para as configurações e scripts dos controles.

Teste rápido

Em que momento uma regra do AWS CloudFormation Guard no pipeline barra um bucket sem bloqueio de acesso público?

Qual recurso faz um baseline de CloudFormation chegar automaticamente a toda conta nova adicionada a uma OU?

Resumo

Controles padrão vivem como código: definidos em CloudFormation, CDK ou Terraform, revisados em pull request, validados com cfn-lint, Guard e Checkov, implantados com StackSets ou autosserviço, vigiados pelo AWS Config e corrigidos por remediação. Assim toda conta nasce e permanece no padrão.

Referência Well-Architected

SEC01-BP06 Automate deployment of standard security controls — risco exposto se não for estabelecida: médio.

Referências

Terminou esta lição?

Seu progresso fica salvo apenas neste navegador.