A AWS é a infraestrutura de nuvem mais utilizada no mundo — e também um dos ambientes mais frequentemente mal configurados. Buckets S3 públicos, roles IAM com permissões excessivas, instâncias EC2 sem patches e grupos de segurança abertos para 0.0.0.0/0 são achados recorrentes em auditorias de segurança de ambientes AWS em qualquer setor.

Este artigo apresenta 10 práticas concretas de segurança de dados em AWS, com foco em implementação — não em teoria. Cada prática inclui o recurso AWS específico e o comando ou configuração relevante.

1. Habilitar MFA obrigatório para o usuário root e todos os IAM

O usuário root da conta AWS tem acesso irrestrito a todos os recursos. Expor suas credenciais sem MFA é um risco crítico. A prática é habilitar MFA de hardware (YubiKey ou chave de segurança FIDO2) para o root e MFA por app para todos os usuários IAM.

# Verificar quais usuários IAM não têm MFA habilitado
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | grep ",false,"

O relatório de credenciais IAM lista todos os usuários e seu status de MFA. Qualquer usuário com acesso ao console sem MFA habilitado é uma vulnerabilidade imediata.

2. Aplicar o princípio do menor privilégio em políticas IAM

Políticas IAM com Action: "*" ou Resource: "*" são o equivalente de dar chaves mestras a todos os funcionários. O IAM Access Analyzer da AWS identifica permissões não utilizadas e sugere políticas mínimas baseadas no uso real.

# Analisar acessos não utilizados com IAM Access Analyzer
aws accessanalyzer list-analyzers
aws accessanalyzer list-findings --analyzer-arn <ARN>

Implementar SCPs (Service Control Policies) no AWS Organizations para impedir que contas filhas criem usuários com AdministratorAccess é o controle preventivo mais eficaz em ambientes multi-conta.

3. Bloquear acesso público a buckets S3 por padrão

A configuração "Block Public Access" do S3 deve estar habilitada em nível de conta, não apenas bucket a bucket. Isso impede que qualquer bucket na conta seja tornado público — mesmo que uma policy individual permita.

# Habilitar bloqueio de acesso público em nível de conta
aws s3control put-public-access-block   --account-id <ACCOUNT_ID>   --public-access-block-configuration   "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Auditar todos os buckets existentes para identificar os que têm acesso público habilitado é o primeiro passo — o AWS Security Hub consolida esses achados automaticamente quando habilitado.

4. Habilitar criptografia em repouso em todos os serviços de dados

S3, RDS, EBS, DynamoDB, SQS, SNS e praticamente todos os serviços AWS suportam criptografia em repouso. A prática é habilitar por padrão usando chaves gerenciadas pela AWS (SSE-S3) ou, para dados sensíveis, chaves gerenciadas pelo cliente (SSE-KMS).

# Verificar buckets S3 sem criptografia padrão
aws s3api list-buckets --query 'Buckets[].Name' --output text |   xargs -I{} aws s3api get-bucket-encryption --bucket {} 2>&1 | grep -B1 "ServerSideEncryptionConfigurationNotFoundError"

Para RDS, habilitar criptografia é possível apenas na criação do banco — não depois. Migrar um banco RDS não-criptografado exige criar um snapshot, criptografar o snapshot e restaurar em nova instância.

5. Configurar CloudTrail em todas as regiões com integridade de logs

O CloudTrail registra todas as chamadas de API na conta AWS — quem fez o quê, quando e de onde. Sem CloudTrail habilitado, uma investigação de incidente perde o registro de ações do atacante.

# Criar trail multi-região com validação de integridade
aws cloudtrail create-trail   --name trilha-seguranca   --s3-bucket-name <BUCKET_LOGS>   --is-multi-region-trail   --enable-log-file-validation   --include-global-service-events

A validação de integridade de logs (--enable-log-file-validation) cria hashes encadeados dos arquivos de log — evidência auditável de que os logs não foram modificados após a captura. Essencial para investigações forenses e conformidade.

6. Usar AWS Secrets Manager para gerenciamento de credenciais

Credenciais hardcoded em código-fonte, variáveis de ambiente de EC2 e arquivos de configuração são um dos vetores de comprometimento mais comuns em ambientes AWS. O Secrets Manager armazena, rotaciona e distribui credenciais de forma segura.

A rotação automática de credenciais de banco de dados RDS via Secrets Manager elimina o risco de credenciais estáticas que nunca mudam — um achado recorrente em auditorias de ambientes de nuvem.

7. Habilitar o AWS Security Hub com padrões CIS

O Security Hub consolida achados de segurança de múltiplos serviços AWS (GuardDuty, Inspector, Macie, IAM Access Analyzer) em uma única interface e aplica verificações automáticas contra o CIS AWS Foundations Benchmark.

aws securityhub enable-security-hub   --enable-default-standards

O Security Hub gera um score de segurança por conta e por controle. Tratar o score como um KPI de segurança — com meta de manutenção acima de 80% — é uma prática adotada por equipes maduras de cloud security.

8. Restringir grupos de segurança — eliminar regras 0.0.0.0/0

Grupos de segurança com entrada liberada para 0.0.0.0/0 em qualquer porta expõem instâncias diretamente à internet. A prática correta: SSH (porta 22) e RDP (porta 3389) nunca devem estar abertos para a internet — use AWS Systems Manager Session Manager para acesso administrativo sem exposição de portas.

# Listar grupos de segurança com regras abertas para internet
aws ec2 describe-security-groups   --filters "Name=ip-permission.cidr,Values=0.0.0.0/0"   --query 'SecurityGroups[*].[GroupId,GroupName,IpPermissions]'

9. Habilitar o Amazon GuardDuty para detecção de ameaças

O GuardDuty analisa logs do CloudTrail, VPC Flow Logs e DNS logs para detectar comportamentos anômalos: acesso de IPs de reputação conhecida como maliciosa, padrões de reconhecimento, mineração de criptomoeda em instâncias EC2 e exfiltração de dados via DNS.

Tem custo baseado em volume de dados analisados — em contas de médio porte, o custo mensal é geralmente inferior ao custo de uma hora de resposta a incidente causado pela ausência de detecção. A habilitação via AWS Organizations aplica o GuardDuty a todas as contas filhas automaticamente.

10. Implementar backup e versionamento com proteção contra deleção

Ataques de ransomware em ambientes AWS frequentemente tentam deletar backups antes de criptografar dados. O S3 Object Lock com modo COMPLIANCE impede a deleção de objetos mesmo por administradores da conta durante o período de retenção configurado.

# Habilitar versionamento e Object Lock em bucket de backup
aws s3api put-bucket-versioning   --bucket <BUCKET_BACKUP>   --versioning-configuration Status=Enabled

aws s3api put-object-lock-configuration   --bucket <BUCKET_BACKUP>   --object-lock-configuration   '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Desenvolva competências em segurança de nuvem

A demanda por profissionais com conhecimento técnico em segurança de AWS supera a oferta no Brasil. A IBSEC oferece formação prática nessa área: