Segurança em AWS para startups: as configurações que mais causam incidente e como corrigir

O modelo de responsabilidade compartilhada e o que ele significa na prática

A AWS opera sob o modelo de responsabilidade compartilhada (Shared Responsibility Model): a Amazon é responsável pela segurança **da** nuvem — física, hipervisor, rede global, hardware dos data centers —, enquanto o cliente é responsável pela segurança **na** nuvem. Isso inclui configuração de serviços, controle de acesso, criptografia dos dados, patches do sistema operacional em instâncias EC2 e proteção das aplicações.

Para startups, esse modelo frequentemente passa despercebido nos primeiros meses. A equipe se concentra em lançar o produto e assume, implicitamente, que 'a AWS cuida da segurança'. O resultado é uma conta com dezenas de recursos provisionados rapidamente, sem políticas de acesso, sem logs e sem criptografia — um ambiente que um atacante oportunista consegue comprometer em horas.

O AWS Well-Architected Framework define o pilar de Segurança como um dos seis pilares fundamentais, com controles em cinco áreas: gestão de identidade e acesso, detecção, proteção de infraestrutura, proteção de dados e resposta a incidentes. Startups que ignoram qualquer uma dessas áreas acumulam dívida técnica de segurança que se converte em incidente.

As misconfigurações que mais causam incidente: tabela completa

A análise de incidentes reais em startups que rodam na AWS, combinada com os achados do CIS AWS Foundations Benchmark v3.0 e dos relatórios de threat intelligence da Decripte, revela um conjunto recorrente de configurações incorretas. A tabela abaixo consolida as principais, o risco associado e a correção objetiva.

Nenhuma dessas configurações exige investimento financeiro adicional relevante. A maioria é ativada em minutos via console AWS ou Infrastructure as Code. O custo de não implementá-las é exponencialmente maior: o vazamento médio de dados em PMEs custa, segundo o relatório IBM Cost of a Data Breach 2024, USD 3,31 milhões — e startups raramente sobrevivem ao impacto reputacional.

Baseline de segurança para startups: o que ativar desde o primeiro dia

O baseline mínimo de segurança para uma startup na AWS não é um projeto de seis meses — é um conjunto de controles que pode ser implementado em um único sprint de dois dias. O CIS AWS Foundations Benchmark nível 1 cobre exatamente esse conjunto inicial e serve como referência auditável.

**Identidade e acesso:** Ative MFA na conta root imediatamente e remova ou nunca crie chaves de acesso programático para ela. Crie usuários IAM individuais para cada membro da equipe ou, preferencialmente, integre ao AWS IAM Identity Center (SSO) para gerenciar acesso via provedor de identidade corporativo (Google Workspace, Okta, Azure AD). Aplique o princípio de privilégio mínimo em todas as políticas — comece negando tudo e libere apenas o necessário.

**Observabilidade:** Ative CloudTrail com cobertura multi-região e armazenamento dos logs em bucket S3 dedicado com validação de integridade habilitada. Ative GuardDuty em todas as regiões onde você opera — o custo inicial para contas menores é de menos de USD 5 por mês. Considere o AWS Security Hub para agregar os achados de GuardDuty, Inspector, Config e Macie em uma visão unificada.

**Proteção de dados:** Habilite criptografia em repouso por padrão em todos os serviços com suporte: EBS, S3 (SSE-S3 ou SSE-KMS), RDS, Secrets Manager. Ative o S3 Block Public Access no nível organizacional — isso impede que qualquer bucket seja acidentalmente tornado público. Para segredos de aplicação, use AWS Secrets Manager com rotação automática.

**Rede:** Revise todos os security groups e remova regras com origem 0.0.0.0/0 para portas administrativas. Utilize VPC com subnets públicas e privadas — bancos de dados, serviços internos e instâncias de backend devem ficar exclusivamente em subnets privadas. Use NAT Gateway para tráfego de saída das instâncias privadas.

**Monitoramento financeiro:** Crie um billing alarm no CloudWatch com threshold conservador e ative o AWS Cost Anomaly Detection. Comprometimentos por cryptomining são detectados primeiro pelo spike de custo, não pelo SIEM.

CSPM: visibilidade contínua sobre postura de segurança

Cloud Security Posture Management (CSPM) é a prática — e a categoria de ferramentas — que monitora continuamente a configuração dos recursos em nuvem em busca de desvios das políticas de segurança definidas. Para startups, o CSPM substitui auditorias manuais pontuais por verificação contínua e alertas em tempo real.

No ecossistema AWS, o ponto de entrada nativo para CSPM é o AWS Config com regras gerenciadas (managed rules) mapeadas ao CIS Benchmark. Regras como `root-account-mfa-enabled`, `s3-bucket-public-read-prohibited`, `cloudtrail-enabled` e `restricted-ssh` cobrem os controles mais críticos e podem ser habilitadas em minutos. O AWS Security Hub consolida os achados e fornece um score de segurança por conta e por região.

Ferramentas complementares open source — como Prowler, Scout Suite e Steampipe com o plugin AWS — permitem varreduras mais profundas e relatórios auditáveis. A Decripte utiliza essas ferramentas combinadas com análise manual especializada nos pentests e assessments de hardening cloud que realiza para startups brasileiras.

A principal vantagem do CSPM é a detecção de regressão: quando um desenvolvedor abre um security group para testes e esquece de fechar, o Config detecta a mudança e dispara o alerta antes que qualquer atacante a explore. Sem CSPM, essa janela pode durar semanas ou meses — tempo mais do que suficiente para um comprometimento completo.

O erro de 'deixar pra depois': por que o hardening nunca é retroativo

A narrativa mais comum em startups é: 'quando chegarmos a X clientes, contratamos alguém de segurança'. O problema é que a superfície de ataque não espera esse marco. Cada novo serviço provisionado sem controles adequados, cada desenvolvedor com AdministratorAccess, cada segredo commitado no repositório amplia o risco exponencialmente.

Statistically, o tempo médio para detecção de um comprometimento de credencial cloud é de 197 dias (IBM X-Force 2024). Durante esse período, o atacante pode ter exfiltrado dados, instalado backdoors, criado usuários IAM persistentes e escalado para outros serviços. Corrigir um ambiente comprometido é ordens de magnitude mais custoso, demorado e doloroso do que implementar controles preventivos desde o início.

Há também o fator de compliance: LGPD, PCI DSS, SOC 2, ISO 27001 — todos exigem controles que deveriam ter sido implementados desde a primeira linha de código em produção, não retrospectivamente. Startups que buscam clientes enterprise ou levantam rodadas de investimento frequentemente descobrem, durante due diligence, que a postura de segurança inadequada é um bloqueador de negócio.

A Decripte realiza pentests e hardening de ambientes AWS, Azure e GCP para startups de 1 a mais de 100.000 colaboradores. O serviço de Assessment de Segurança Cloud inclui varredura automatizada com CSPM, análise manual de configurações críticas, relatório executivo e técnico, e plano de remediação priorizado por risco. O plano de Resposta a Incidentes cobre desde contenção imediata até forense digital e recuperação. Para começar, acesse o plano gratuito de Gestão de Ameaças ou conheça os planos completos em decripte.com.br/planos.

Referências e padrões de mercado

O AWS Well-Architected Framework (pilar de Segurança) define os princípios de design de segurança recomendados pela própria AWS, incluindo a aplicação de segurança em todas as camadas, automação das melhores práticas, proteção dos dados em trânsito e em repouso, e preparação para eventos de segurança. A documentação completa está disponível em docs.aws.amazon.com/wellarchitected.

O CIS Amazon Web Services Foundations Benchmark (atualmente versão 3.0) é o padrão de referência mais utilizado para hardening de contas AWS. Desenvolvido pelo Center for Internet Security com contribuição da comunidade global, cobre controles de IAM, armazenamento, logging, monitoramento, rede e serviços adicionais. É a base dos checks do AWS Security Hub e de ferramentas como Prowler.

O NIST Cybersecurity Framework 2.0 e a ISO 27017 (controles de segurança para serviços em nuvem) complementam o baseline técnico com uma perspectiva de governança e gestão de risco, relevante para startups que buscam certificações ou contratos com o setor público e enterprise.

Termos importantes

IAM (Identity and Access Management)

Serviço da AWS que controla quem pode autenticar (sign in) e quem tem autorização para usar recursos AWS. Permite criar usuários, grupos, roles e políticas de permissão com granularidade por serviço, recurso e condição. O princípio fundamental é o privilégio mínimo: conceder apenas as permissões estritamente necessárias para cada entidade realizar sua função.

CSPM (Cloud Security Posture Management)

Categoria de práticas e ferramentas que monitoram continuamente a configuração de recursos em nuvem para identificar desvios de políticas de segurança, requisitos de compliance e benchmarks como CIS. Na AWS, o AWS Config com regras gerenciadas e o AWS Security Hub são as implementações nativas de CSPM. Ferramentas open source como Prowler e Scout Suite complementam com varreduras mais profundas.

CIS AWS Foundations Benchmark

Documento de referência desenvolvido pelo Center for Internet Security (CIS) que define controles prescritivos de segurança para contas AWS, organizados em dois níveis: nível 1 (controles essenciais com impacto mínimo nas operações) e nível 2 (controles avançados para ambientes com requisitos de segurança elevados). É a base dos padrões de segurança do AWS Security Hub e o ponto de partida recomendado para qualquer hardening de conta AWS.

GuardDuty

Serviço gerenciado de detecção de ameaças da AWS que usa machine learning, detecção de anomalias e inteligência de ameaças para monitorar continuamente atividades maliciosas e comportamentos não autorizados em contas AWS. Analisa eventos do CloudTrail, VPC Flow Logs e logs de DNS sem exigir agentes ou infraestrutura adicional. Gera findings categorizados por tipo de ameaça (Backdoor, CryptoCurrency, Recon, Stealth, Trojan, UnauthorizedAccess) e severidade.

Por onde começar

1. Proteja a conta root imediatamente: Acesse o console AWS com a conta root, vá em Security Credentials e ative um dispositivo MFA (preferencialmente hardware U2F ou TOTP via app autenticador). Certifique-se de que não existem chaves de acesso (Access Keys) associadas à root — se existirem, delete-as. A conta root nunca deve ser usada para operações do dia a dia.
2. Implante IAM Identity Center (SSO) e privilégio mínimo: No AWS Organizations, ative o IAM Identity Center e configure o provedor de identidade da sua empresa (Google Workspace, Okta ou Azure AD). Crie Permission Sets com escopo mínimo necessário para cada função. Use o IAM Access Analyzer para identificar permissões existentes não utilizadas e remova-as. Exclua usuários IAM com chaves de acesso de longa duração sempre que possível.
3. Ative CloudTrail em todas as regiões: No console CloudTrail, crie um trail multi-região cobrindo todos os eventos de gerenciamento (management events) com validação de integridade de log habilitada. Direcione os logs para um bucket S3 dedicado com Block Public Access ativo, política de bucket restritiva e retenção de pelo menos 365 dias. Considere replicar para outra conta AWS para proteção contra comprometimento da conta principal.
4. Habilite GuardDuty e Security Hub: No console GuardDuty, ative o serviço em cada região onde você opera — o processo leva menos de um minuto por região. Em seguida, ative o AWS Security Hub e habilite o CIS AWS Foundations Benchmark como padrão de segurança. Configure alertas via EventBridge para findings de severidade ALTA ou CRÍTICA direcionados ao Slack, PagerDuty ou e-mail da equipe.
5. Revise e corrija security groups e exposição de rede: Use o AWS Config com a regra `restricted-ssh` e `restricted-rdp` para identificar security groups com acesso irrestrito. Remova todas as regras com origem 0.0.0.0/0 para portas administrativas (22, 3389, 5432, 3306, 27017). Substitua acesso SSH direto pelo AWS Systems Manager Session Manager. Verifique se instâncias RDS e ElastiCache estão em subnets privadas sem acesso público habilitado.
6. Migre segredos para o Secrets Manager e ative criptografia: Varra o repositório de código com Trufflehog ou git-secrets para identificar credenciais expostas — qualquer achado deve ser rotacionado imediatamente, pois commits históricos são públicos. Migre todas as credenciais de banco de dados, chaves de API e tokens para o AWS Secrets Manager com rotação automática configurada. Habilite criptografia KMS em repouso para EBS, RDS, S3 e Secrets Manager.
7. Configure monitoramento de billing e anomalias: No console Billing, ative o AWS Cost Anomaly Detection com um monitor de serviço cobrindo toda a conta. Crie um billing alarm no CloudWatch para o gasto mensal estimado com threshold 20% acima do esperado. Comprometimentos por cryptomining são frequentemente detectados primeiro pelo spike anômalo de custo em EC2 ou Lambda — esse alarme pode ser a primeira evidência de um incidente.

Perguntas frequentes