Segurança na nuvem: guia completo de compliance e boas práticas
Atualizado em Março 2026Segurança na nuvem é o conjunto de políticas, controles, tecnologias e boas práticas projetadas para proteger dados, aplicações e infraestrutura em ambientes de cloud computing. Na AWS, isso abrange o modelo de responsabilidade compartilhada, gerenciamento de identidades (IAM), criptografia, detecção de ameaças e conformidade com regulamentações como a LGPD.
A migração para a nuvem traz inúmeros benefícios, mas também introduz novos vetores de ataque e responsabilidades de segurança. Em 2026, com a LGPD em plena vigência e regulamentações setoriais cada vez mais rigorosas, garantir a segurança é a conformidade do seu ambiente cloud não é opcional, é uma exigência de negócio.
Neste guia completo, abordaremos os pilares fundamentais de segurança na AWS, desde o modelo de responsabilidade compartilhada até configurações práticas que você pode implementar imediatamente.
O modelo de responsabilidade compartilhada
O primeiro conceito que todo profissional de cloud precisa dominar é o Shared Responsibility Model da AWS. De forma simplificada: a AWS é responsável pela segurança da nuvem (infraestrutura física, hypervisors, rede global), enquanto o cliente é responsável pela segurança na nuvem (dados, configurações, identidades, aplicações).
Muitas violações de segurança na nuvem acontecem exatamente nessa fronteira: empresas assumem que a AWS cuida de tudo e negligenciam suas responsabilidades. Buckets S3 públicos, security groups permissivos e credenciais hardcoded são erros que continuam acontecendo com frequência alarmante.
Controle de acesso com IAM: a base da segurança na nuvem
O IAM é o serviço mais crítico da AWS. Para um aprofundamento em IAM com abordagem Zero Trust, veja nosso guia completo. Uma configuração inadequada de IAM pode comprometer todo o ambiente, independente de quão bem configurados estejam os demais serviços de segurança. Siga estas boas práticas fundamentais:
- Princípio do menor privilégio: conceda apenas as permissões estritamente necessárias para cada função
- MFA obrigatório: ative autenticação multifator para todos os usuários, especialmente o root
- Roles em vez de usuários: para aplicações e serviços, use IAM Roles com credenciais temporárias (STS)
- Políticas granulares: evite políticas com
*em Resource ou Action - Rotação de credenciais: implemente rotação automática de access keys e secrets
// Política IAM com menor privilégio para acesso a S3
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ReadSpecificBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::meu-bucket-produção",
"arn:aws:s3:::meu-bucket-produção/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "sa-east-1"
},
"Bool": {
"aws:SecureTransport": "true"
}
}
}
]
}
Note o uso de Conditions para restringir o acesso à região de São Paulo e exigir conexão HTTPS. Esse nível de granularidade é essencial para uma postura de segurança robusta.
2. Criptografia: em trânsito e em repouso
Toda informação sensível deve ser criptografada, tanto em trânsito quanto em repouso. A AWS oferece o KMS (Key Management Service) para gerenciamento centralizado de chaves de criptografia, é a maioria dos serviços suporta criptografia nativa.
Para compliance com LGPD, é fundamental garantir que dados pessoais estejam sempre criptografados. Configure criptografia padrão em:
- S3: ative SSE-KMS ou SSE-S3 como criptografia padrão para todos os buckets
- RDS: habilite criptografia at-rest na criação da instância (não pode ser ativada depois)
- EBS: configure criptografia padrão na conta para todos os volumes
- DynamoDB: use criptografia gerenciada pela AWS ou CMK (Customer Managed Key)
- CloudTrail: criptografe logs com KMS para garantir integridade
# Habilitar criptografia padrão para EBS em toda a conta
aws ec2 enable-ebs-encryption-by-default --region sa-east-1
# Configurar criptografia padrão em bucket S3
aws s3api put-bucket-encryption \
--bucket meu-bucket-produção \
--server-side-encryption-configuration '{
"Rules": [{
"ApplyServerSideEncryptionByDefault": {
"SSEAlgorithm": "aws:kms",
"KMSMasterKeyID": "arn:aws:kms:sa-east-1:123456789:key/key-id"
},
"BucketKeyEnabled": true
}]
}'
# Bloquear acesso público em todos os buckets S3 da conta
aws s3control put-public-access-block \
--account-id 123456789012 \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
3. Monitoramento e detecção de ameaças
Segurança reativa não é suficiente. Você precisa de monitoramento contínuo e detecção proativa de ameaças. A AWS oferece um conjunto robusto de serviços para isso:
- AWS CloudTrail: registra todas as chamadas de API na sua conta. Essencial para auditoria e forense. Ative em todas as regiões e envie logs para um bucket S3 centralizado com proteção contra exclusão.
- Amazon GuardDuty: serviço de detecção de ameaças baseado em machine learning. Analisa logs do CloudTrail, VPC Flow Logs e DNS Logs para identificar atividades suspeitas como mineração de criptomoedas, acesso de IPs maliciosos e comportamentos anômalos.
- AWS Security Hub: painel centralizado que agrega findings de GuardDuty, Inspector, Macie e outros serviços, oferecendo uma visão consolidada da postura de segurança. Inclui verificações automáticas contra frameworks como CIS AWS Foundations Benchmark.
- Amazon Inspector: realiza análises automatizadas de vulnerabilidades em instâncias EC2 e imagens de container no ECR.
- AWS Config: monitora e avalia continuamente a configuração dos seus recursos contra regras definidas. Ideal para detectar desvios de compliance.
4. Proteção de rede
A segurança de rede na AWS opera em múltiplas camadas. Uma arquitetura bem planejada deve incluir:
- VPC com subnets privadas: bancos de dados e serviços internos nunca devem ter IP público. Use subnets privadas com NAT Gateway para acesso à internet.
- Security Groups: funcionam como firewalls stateful no nível da instância. Aplique o princípio do menor privilégio: permita apenas as portas e IPs necessários.
- NACLs (Network ACLs): firewalls stateless no nível da subnet. Use como camada adicional de defesa em profundidade.
- AWS WAF: protege aplicações web contra ataques comuns como SQL injection, XSS e bots maliciosos. Integra-se com CloudFront, ALB e API Gateway.
- AWS Shield: proteção contra ataques DDoS. O Shield Standard é gratuito e protege contra os ataques mais comuns. O Shield Advanced oferece proteção adicional e suporte 24/7 do DDoS Response Team.
5. Compliance e LGPD na AWS
Para empresas brasileiras, a conformidade com a Lei Geral de Proteção de Dados (LGPD) é obrigatória. Na AWS, isso envolve:
- Residência de dados: mantenha dados pessoais de cidadãos brasileiros na região
sa-east-1(São Paulo) quando necessário - Inventário de dados: use o Amazon Macie para descobrir e classificar dados sensíveis automaticamente em buckets S3
- Controle de acesso: implemente segregação de funções para que apenas pessoal autorizado acesse dados pessoais
- Logs de auditoria: mantenha registros completos de quem acessou dados pessoais, quando e para que finalidade
- Resposta a incidentes: tenha um plano documentado e testado para responder a incidentes de segurança envolvendo dados pessoais
- DPA (Data Processing Agreement): a AWS oferece um adendo ao contrato que atende aos requisitos da LGPD
"Segurança na nuvem não é um destino, é uma jornada. As ameaças evoluem constantemente, e sua postura de segurança precisa acompanhar essa evolução."
6. Automação de segurança
Segurança manual não escala. Automatize o máximo possível:
- Use AWS Config Rules para detectar automaticamente configurações fora de compliance
- Configure remediação automática com SSM Automation para corrigir desvios
- Implemente Infrastructure as Code (Terraform/CloudFormation) para garantir que todos os recursos sejam criados com configurações seguras por padrão
- Use Service Control Policies (SCPs) no AWS Organizations para aplicar guardrails em toda a organização. Veja também como automatizar com Terraform
- Automatize a rotação de secrets com AWS Secrets Manager
Gotchas que só a experiencia ensina
Erros que encontramos repetidamente em auditorias de segurança:
- CloudTrail ativo apenas na região principal: atacantes frequentemente criam recursos em regiões incomuns (ex: ap-southeast-1) para escapar da detecção. Sempre habilite CloudTrail como Organization Trail em todas as regiões.
- Security Groups com regra 0.0.0.0/0 na porta 22/3389: parece óbvio, mas encontramos isso em mais de 60% das auditorias. Use o AWS Systems Manager Session Manager como alternativa ao SSH, eliminando a necessidade de portas abertas e bastion hosts.
- Conta root sem hardware MFA: use uma YubiKey ou dispositivo TOTP físico para o root. Nunca use MFA virtual (app) para a conta root de produção.
- IAM Access Keys sem rotação: keys com mais de 90 dias são um risco. Configure a Config Rule
access-keys-rotatedcom maxAccessKeyAge de 90.
# Habilitar GuardDuty em todas as regiões com um loop
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
echo "Habilitando GuardDuty em $region..."
aws guardduty create-detector --enable --region "$region" 2>/dev/null
done
# Verificar Security Groups com porta 22 aberta para 0.0.0.0/0
aws ec2 describe-security-groups \
--filters Name=ip-permission.from-port,Values=22 \
Name=ip-permission.to-port,Values=22 \
Name=ip-permission.cidr,Values=0.0.0.0/0 \
--query 'SecurityGroups[*].{ID:GroupId,Name:GroupName,VPC:VpcId}' \
--output table --region sa-east-1
# Listar IAM users com access keys mais antigas que 90 dias
aws iam generate-credential-report > /dev/null 2>&1
aws iam get-credential-report --query 'Content' --output text | \
base64 --decode | cut -d',' -f1,9,11,14,16
# Habilitar Security Hub com CIS Benchmark
aws securityhub enable-security-hub \
--enable-default-standards \
--region sa-east-1
# Criar uma Config Rule para detectar buckets S3 públicos
aws configservice put-config-rule --config-rule '{
"ConfigRuleName": "s3-bucket-public-read-prohibited",
"Source": {
"Owner": "AWS",
"SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
}
}' --region sa-east-1
Na Prática: hardening de ambiente AWS
Uma fintech brasileira com 15 desenvolvedores nos procurou após um alerta do Banco Central sobre requisitos de segurança em nuvem. O ambiente AWS tinha 3 contas (dev, staging, prod) sem nenhuma governança centralizada. Em 4 semanas, implementamos:
- AWS Organizations com SCPs: criamos guardrails que impedem desabilitar CloudTrail, criar IAM users com console access (somente SSO via Identity Center) e lançar recursos fora de sa-east-1.
- GuardDuty + Security Hub: habilitamos em todas as contas com delegated admin. Em 48h, o GuardDuty identificou 3 instâncias EC2 de dev fazendo chamadas para IPs de mineração de cripto (containers comprometidos).
- Criptografia em todos os layers: EBS encryption by default, S3 com SSE-KMS, RDS com encryption at-rest e certificados ACM para TLS em trânsito.
- Rotação automática de secrets: migramos 47 credenciais hardcoded em variáveis de ambiente para o AWS Secrets Manager com rotação automática a cada 30 dias.
Resultado: Security Hub score saiu de 23% para 91% em 30 dias. O MTTD (tempo médio para detectar ameaças) caiu de "desconhecido" para menos de 15 minutos com alertas automáticos no Slack via EventBridge + SNS.
KPIs para o Decisor
- Security Hub Score (%): pontuação consolidada de compliance. Target: acima de 90% para CIS AWS Foundations Benchmark.
- Mean Time to Detect - MTTD: tempo para identificar um incidente de segurança. Target: menos de 15 minutos com GuardDuty + alertas automatizados.
- Vulnerabilidades abertas > 30 dias: findings críticos do Inspector/Security Hub sem remediação. Target: zero findings críticos abertos por mais de 7 dias.
- MFA coverage (%): percentual de usuários IAM com MFA ativo. Target: 100%, sem exceções.
- Compliance score LGPD (%): percentual de controles LGPD implementados. Target: acima de 95% com evidencias documentadas.
- Access keys > 90 dias (count): número de keys sem rotação. Target: zero. Monitore com Config Rule
access-keys-rotated.
Checklist de segurança essencial
- MFA ativado em todas as contas, especialmente root
- CloudTrail ativo em todas as regiões
- GuardDuty habilitado em todas as contas
- Security Hub configurado com CIS Benchmark
- Criptografia padrão em S3, EBS e RDS
- Buckets S3 com bloqueio de acesso público
- VPC com subnets privadas para workloads internos
- Security Groups com menor privilégio
- AWS Config com regras de compliance
- Plano de resposta a incidentes documentado e testado
Como a RFX Tecnologia pode ajudar
Implementar segurança robusta na nuvem exige expertise e experiência. Confira nossos serviços de segurança avançada. Na RFX Tecnologia, realizamos assessments completos de segurança, implementamos arquiteturas seguras desde o zero e ajudamos empresas a alcançar e manter conformidade com LGPD, PCI-DSS, SOC 2 e outros frameworks.
Nosso serviço de Security Assessment avalia mais de 200 controles no seu ambiente AWS e entrega um relatório detalhado com priorização de riscos e plano de remediação. Entre em contato para agendar o seu.