Segurança

Segurança na nuvem: guia completo de compliance e boas práticas

Atualizado em Março 2026

Seguranç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
iam-policy-exemplo.json
// 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
terminal
# 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-rotated com maxAccessKeyAge de 90.
terminal
# 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.

Fale Conosco
Assessment gratuito do seu ambiente AWS