Ambientes em nuvem oferecem velocidade, escalabilidade e flexibilidade, mas também exigem atenção constante à postura de segurança. Na prática, muitos incidentes não acontecem por falhas complexas ou ataques altamente sofisticados, e sim por configurações incorretas que permanecem ativas por tempo demais.
Na AWS, esse cenário é mais comum do que muitas equipes imaginam. Buckets públicos, permissões excessivas no IAM, ausência de MFA na conta raiz, trilhas de auditoria incompletas e regras de segurança abertas para a internet são alguns exemplos de situações que continuam aparecendo em diferentes ambientes.
O ponto mais importante é que esses problemas existem, são reais e continuam expondo empresas a riscos operacionais, financeiros e reputacionais. A boa notícia é que a maior parte deles pode ser detectada com ferramentas nativas da própria AWS e corrigida com ações objetivas.
Neste artigo, você vai conhecer 10 erros de configuração de segurança na AWS, entender por que eles são críticos e ver caminhos práticos para identificação e correção.
Por que a segurança AWS exige monitoramento contínuo?
Ao contrário de vulnerabilidades de software, que normalmente dependem de correções e atualizações, os erros de configuração geralmente surgem de:
- permissões concedidas além do necessário
- recursos criados com configurações padrão inseguras
- exceções temporárias que se tornam definitivas
- falta de monitoramento contínuo
O risco aumenta porque essas falhas muitas vezes não interrompem o ambiente. Ou seja: tudo parece funcionar normalmente, enquanto a superfície de ataque continua aberta.
Uma postura forte de segurança em cloud depende menos de ações isoladas e mais de governança contínua, visibilidade e correção recorrente.
[Inserir imagem 1 aqui — sugestão: diagrama/print do Security Hub ou visão geral de postura de segurança AWS]
Alt text sugerido: Painel de segurança AWS mostrando achados e postura de conformidade
Os 10 erros mais comuns de segurança AWS
| Erro de configuração | Gravidade | Ferramenta principal de detecção |
|---|---|---|
| Buckets S3 públicos | Crítica | Security Hub / IAM Access Analyzer |
| Políticas IAM excessivamente permissivas | Crítica | Security Hub / IAM Access Analyzer |
| Ausência de MFA na conta raiz | Crítica | Security Hub / IAM |
| Volumes EBS sem criptografia | Alta | Security Hub / AWS Config |
| Security Groups com 0.0.0.0/0 | Alta | Security Hub / EC2 |
| Ausência de trilha no CloudTrail | Alta | Security Hub / CloudTrail |
| Credenciais IAM não utilizadas | Média | IAM Credential Report / Access Analyzer |
| Uso de VPC padrão | Média | EC2 / AWS Config |
| Falta de criptografia em trânsito | Média | ALB / CloudFront / S3 |
| Nenhuma regra do AWS Config | Média | AWS Config |
1. Buckets S3 públicos
Gravidade: Crítica
A exposição pública indevida de buckets S3 continua sendo uma das falhas mais conhecidas e, ainda assim, uma das mais recorrentes. Mesmo com melhorias da AWS no bloqueio de acesso público por padrão para novos buckets, ambientes legados e exceções mal controladas seguem causando exposição de dados.
Por que isso é perigoso?
Um bucket público pode permitir leitura, listagem ou até gravação por usuários externos, dependendo da ACL ou da policy aplicada. Em muitos casos, basta uma policy mal definida para comprometer dados sensíveis.
Como detectar
aws s3control get-public-access-block --account-id <account-id>
aws s3api get-public-access-block --bucket <bucket-name>
aws s3api get-bucket-acl --bucket <bucket-name>Como corrigir
Ative o bloqueio de acesso público no nível da conta e do bucket:
aws s3control put-public-access-block \
--account-id <account-id> \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
Boa prática
Quando houver necessidade legítima de distribuição pública de conteúdo, prefira usar CloudFront com controles apropriados, URLs pré-assinadas ou estratégias privadas de acesso.
2. Políticas de IAM excessivamente permissivas
Gravidade: Crítica
Permissões além do necessário continuam sendo uma das maiores fontes de risco em AWS. O problema normalmente aparece em políticas com coringas, privilégios administrativos amplos ou permissões concedidas diretamente a usuários.
Erros comuns
*:*em políticas administrativas- uso de
s3:*,ec2:*e outros curingas desnecessários - políticas associadas diretamente a usuários
- ausência de conditions como MFA, IP de origem ou organização
Como detectar
- AWS Security Hub
- IAM Access Analyzer
- AWS Config
aws accessanalyzer validate-policy \
--policy-document file://policy.json \
--policy-type IDENTITY_POLICY
Como corrigir
Adote o princípio do menor privilégio, utilizando permissões específicas por ação, recurso e contexto.
Exemplo:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::meu-bucket/meu-prefixo/*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Boa prática
Revise permissões periodicamente e evite crescimento descontrolado do acesso ao longo do tempo.
3. Ausência de MFA na conta raiz
Gravidade: Crítica
A conta root possui privilégios totais na conta AWS. Se esse acesso for comprometido sem MFA, o impacto pode ser extremo: alteração de billing, remoção de recursos, exclusão de registros e perda de controle do ambiente.
Como detectar
aws iam get-account-summary
aws iam list-mfa-devices
Como corrigir
Habilite MFA para a conta root e, sempre que possível, utilize métodos mais fortes, como chaves FIDO.
Boa prática
- usar e-mail de grupo para a conta root
- registrar mais de um dispositivo MFA
- documentar o processo de recuperação
- restringir ao máximo o uso do root no dia a dia
4. Volumes EBS sem criptografia
Gravidade: Alta
A ausência de criptografia em volumes EBS pode expor dados em repouso, especialmente em cenários de compartilhamento de snapshots, acesso indevido ou movimentação de volumes entre contextos operacionais.
Como detectar
aws ec2 get-ebs-encryption-by-default --region <region>
aws ec2 describe-volumes \
--filters Name=encrypted,Values=false \
--query 'Volumes[*].[VolumeId,State,Size]' \
--output table
Como corrigir
Ative a criptografia por padrão em todas as regiões utilizadas:
aws ec2 enable-ebs-encryption-by-default --region <region-name>
Boa prática
Padronize o uso de criptografia com KMS e trate volumes não criptografados existentes com plano de migração controlado.
5. Security Groups com 0.0.0.0/0
Gravidade: Alta
Abrir portas para qualquer origem na internet é um risco conhecido, especialmente quando envolve portas administrativas ou de banco de dados.
Portas críticas que merecem atenção
- 22 (SSH)
- 3389 (RDP)
- 3306 (MySQL)
- 5432 (PostgreSQL)
- 6379 (Redis)
- 27017 (MongoDB)
Como detectar
aws ec2 describe-security-groups \
--query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].{GroupId:GroupId,GroupName:GroupName,VpcId:VpcId}' \
--output table
Como corrigir
- restringir por IP confiável
- usar VPN
- usar Security Group referenciando outro Security Group
- preferir AWS Systems Manager Session Manager para acesso administrativo
6. Ausência de registro no CloudTrail
Gravidade: Alta
Sem CloudTrail, a equipe perde rastreabilidade sobre ações administrativas e operacionais no ambiente. Isso compromete auditoria, investigação de incidentes e governança.
Como detectar
aws cloudtrail list-trails
aws cloudtrail get-trail-status --name my-trail
aws cloudtrail describe-trails --query 'trailList[?IsMultiRegionTrail==`false`]'
Como corrigir
Crie uma trilha multi-region, com validação de logs e armazenamento seguro.
aws cloudtrail create-trail \
--name organization-trail \
--s3-bucket-name cloudtrail-logs-bucket \
--is-multi-region-trail \
--enable-log-file-validation
Boa prática
- habilitar integração com CloudWatch Logs
- usar criptografia
- centralizar trilhas organizacionais quando aplicável
- revisar retenção e integridade dos logs
7. Credenciais IAM não utilizadas
Gravidade: Média
Credenciais esquecidas continuam sendo vetores de risco silenciosos. Chaves ativas sem uso recente, usuários inativos e acessos antigos ampliam a exposição sem necessidade operacional.
Como detectar
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 --decode > credential-report.csv
Como corrigir
- desativar antes de excluir
- rotacionar chaves periodicamente
- remover credenciais que não fazem mais sentido
- substituir credenciais de longa duração por roles sempre que possível
Boa prática
Crie um processo recorrente de revisão de identidade e credenciais.
8. Uso de VPC padrão
Gravidade: Média
A VPC padrão facilita o início rápido, mas não foi desenhada para atender padrões robustos de segmentação, governança e segurança em produção.
Como detectar
aws ec2 describe-vpcs \
--filters Name=isDefault,Values=true \
--query 'Vpcs[*].[VpcId,CidrBlock]' \
--output table
Como corrigir
Construa VPCs personalizadas com:
- sub-redes públicas e privadas
- segmentação por camada
- NAT Gateway
- VPC Flow Logs
- endpoints privados quando necessário
Boa prática
Evite que workloads críticos permaneçam em VPC padrão por conveniência.
9. Falta de criptografia em trânsito
Gravidade: Média
A criptografia em trânsito protege a comunicação entre clientes, aplicações e serviços AWS. Sem HTTPS/TLS adequado, dados podem ser interceptados ou modificados no caminho.
Como detectar
aws elbv2 describe-listeners \
--load-balancer-arn <alb-arn> \
--query 'Listeners[?Protocol==`HTTPS`].[ListenerArn,SslPolicy]'
Como corrigir
- redirecionar HTTP para HTTPS
- usar políticas modernas de TLS no ALB
- exigir
aws:SecureTransportno S3 - configurar CloudFront com política de viewer segura
Boa prática
Padronize TLS 1.2 ou superior em todos os pontos expostos.
10. Nenhuma regra do AWS Config habilitada
Gravidade: Média
Sem AWS Config, não existe verificação contínua da conformidade do ambiente. Isso significa que muitos dos erros anteriores podem continuar acontecendo sem qualquer alerta automático.
Como detectar
aws configservice describe-configuration-recorders
aws configservice describe-configuration-recorder-status
aws configservice describe-config-rules
Como corrigir
Ative o recorder e implemente regras gerenciadas críticas:
aws configservice start-configuration-recorder \
--configuration-recorder-name default
Regras essenciais para começar
root-account-mfa-enabledencrypted-volumesrestricted-sshcloud-trail-enableds3-bucket-public-read-prohibitedvpc-default-security-group-closed
Boa prática
Use o AWS Config como mecanismo permanente de detecção de desvio.
Como detectar vários desses problemas de uma só vez
Você não precisa tratar cada checagem manualmente de forma isolada. A própria AWS oferece serviços que consolidam achados de segurança e conformidade.
Ferramentas recomendadas
- AWS Security Hub
- IAM Access Analyzer
- AWS Config
- Amazon GuardDuty
- Amazon Inspector
- Trusted Advisor
O Security Hub costuma ser o melhor ponto de partida porque centraliza controles e findings de múltiplas fontes.
Como fortalecer a segurança AWS no dia a dia
Os erros de configuração de segurança na AWS continuam sendo uma das causas mais relevantes de exposição em nuvem. E isso acontece porque são falhas fáceis de introduzir, difíceis de acompanhar manualmente e, muitas vezes, invisíveis até que gerem impacto.
Entre todos os pontos, alguns merecem atenção imediata:
- bloquear acesso público indevido ao S3
- revisar políticas de IAM excessivamente permissivas
- garantir MFA na conta root
- restringir regras abertas em Security Groups
- ativar trilhas confiáveis no CloudTrail
- implementar monitoramento contínuo com AWS Config e Security Hub
