Checklist de segurança AWS: pontos críticos para revisar em produção
Um ponto de partida prático para revisar a postura de uma conta AWS, organizado por área e por impacto.
Toda conta AWS em produção acumula configurações ao longo do tempo, e revisar a postura periodicamente é uma das atividades de maior retorno em segurança de nuvem. Este checklist reúne os pontos críticos que mais aparecem em revisões de ambiente, organizados por área. Ele não substitui uma avaliação aprofundada, mas serve como um ponto de partida concreto para encontrar exposições óbvias e priorizar correções.
Use este guia como um mapa: cada item aponta para um tema que tem um guia dedicado nesta área de conteúdo, com mais profundidade. A ideia é começar pelos itens de maior impacto, identidade e exposição, e avançar para detecção, criptografia e resiliência.
Conta, identidade e acesso
A base da segurança na AWS é a identidade. A conta root deve ter MFA, não deve ter access keys e só deve ser usada para tarefas que a exigem. No IAM, o objetivo é menor privilégio: evitar AdministratorAccess no dia a dia, fazer aplicações assumirem roles em vez de carregar access keys e exigir MFA para acesso humano privilegiado.
- MFA habilitado na conta root e access keys de root removidas
- MFA exigido para acesso humano com privilégio
- Sem uso cotidiano de AdministratorAccess
- Aplicações usando roles, não access keys embutidas
- Permissões revisadas com last accessed e Access Analyzer
Exposição, detecção e dados
Em seguida, olhe para exposição e visibilidade. Security Groups não devem expor portas administrativas e de banco para a internet. Buckets S3 devem ter o Block Public Access ativo. CloudTrail precisa estar habilitado em multi-region, com logs protegidos, e GuardDuty e Security Hub devem estar ativos e com findings sendo tratados, não acumulados.
- Security Groups sem portas sensíveis abertas para a internet
- S3 com Block Public Access ativo e criptografia
- CloudTrail multi-region com logs protegidos e validados
- GuardDuty e Security Hub ativos com findings tratados
- WAF na frente de aplicações expostas, com origem protegida
Criptografia, resiliência e cargas
Por fim, cubra criptografia, backups e as cargas específicas. Dados sensíveis devem usar criptografia, com KMS controlando quem descriptografa. Backups precisam existir, ser testados e estar protegidos contra exclusão. Cargas como EC2, RDS, EKS e imagens no ECR têm seus próprios pontos de hardening e de gestão de vulnerabilidades.
- Criptografia de dados sensíveis com KMS e controle de chaves
- Backups existentes, testados e protegidos contra exclusão
- Hardening de EC2 e RDS e atualização regular
- Imagens do ECR com scan de vulnerabilidades
- EKS com IRSA, RBAC e network policies
Governança multi-conta e guardrails
Muitas exposições nascem não de uma conta isolada, mas da falta de um limite comum a todas elas. Em ambientes com várias contas, o AWS Organizations permite aplicar barreiras que valem para toda a estrutura, independentemente de quem administra cada conta. As Service Control Policies definem o teto de permissões: elas não concedem acesso, mas vedam ações que ninguém deveria poder executar, como desativar a trilha de auditoria, sair da organização ou operar em regiões não aprovadas.
- Contas organizadas por finalidade, com produção separada de desenvolvimento
- SCPs vedando ações perigosas, como desativar CloudTrail e GuardDuty
- Conta de log e de segurança separadas do ambiente de produção
- Baseline de configuração aplicado a novas contas desde a criação
- Regiões não utilizadas restritas por política, reduzindo pontos cegos
Guardrails valem mais quando nascem com a conta
Um guardrail aplicado só depois que a conta cresceu tende a esbarrar em exceções e acabar afrouxado. O ganho maior vem de padronizar a criação de novas contas com o baseline de segurança já embutido: trilha de auditoria ligada, detecção ativa, contatos de segurança preenchidos e as SCPs herdadas da estrutura. Assim, cada conta nova começa dentro da política, em vez de precisar ser corrigida uma a uma depois.
Prontidão para resposta a incidente
Postura preventiva reduz a chance de um incidente, mas não elimina. A pergunta que separa uma conta preparada de uma exposta é simples: se uma credencial vazar agora, você consegue detectar, conter e investigar? Prontidão de resposta é a parte do checklist que só se testa antes de precisar, e a mais negligenciada porque não aparece enquanto está tudo bem.
- Trilha de auditoria protegida contra exclusão, com evidência preservada
- Alertas para uso de root, criação de chaves e mudança de política de IAM
- Caminho definido para revogar credenciais e isolar um recurso comprometido
- Contatos de segurança e responsáveis de plantão conhecidos de antemão
- Backups imutáveis que permitam recuperação sem depender do atacante
Ter a capacidade de conter é tão importante quanto detectar. Saber de antemão como revogar sessões, girar chaves, isolar uma instância por security group e restringir uma role reduz o tempo entre perceber o problema e estancá-lo. Um exercício simples, simulando o vazamento de uma credencial e percorrendo os passos de resposta, revela lacunas que nenhum painel de postura mostra.
Checklist prático
- MFA na conta root e sem access keys de root
- MFA para acesso humano com privilégio
- Sem AdministratorAccess no dia a dia
- Aplicações usando roles, não access keys
- Security Groups sem portas sensíveis abertas à internet
- S3 com Block Public Access e criptografia
- CloudTrail multi-region com logs protegidos
- GuardDuty e Security Hub ativos e com findings tratados
- WAF protegendo aplicações expostas, com origem restrita
- Criptografia com KMS para dados sensíveis
- Backups testados, imutáveis e protegidos contra exclusão
- Hardening e atualização de EC2, RDS, EKS e ECR
- SCPs vedando ações perigosas em toda a organização
- Conta de log e de segurança separadas da produção
- Novas contas criadas com baseline de segurança embutido
- Alertas para uso de root, criação de chaves e mudança de IAM
- Caminho de contenção definido: revogar credenciais e isolar recursos
- Exercício de resposta a vazamento de credencial já realizado
Boas práticas
- Comece pelos itens de identidade e exposição, de maior impacto
- Trate findings de GuardDuty e Security Hub com rotina e dono
- Proteja logs e backups contra exclusão por quem compromete a conta
- Aplique guardrails na organização, não conta por conta
- Padronize novas contas já dentro da política de segurança
- Teste a resposta a incidente antes de precisar dela
- Revise a postura periodicamente, não apenas uma vez
- Aprofunde cada tema nos guias dedicados desta área
- Documente exceções com justificativa e prazo
Erros comuns
Conta root sem MFA ou com access keys
Expõe o nível mais alto de privilégio da conta inteira.
Portas administrativas abertas à internet
Caminho direto de varredura, força bruta e comprometimento.
CloudTrail desabilitado ou desprotegido
Investigação fica sem evidência e a trilha pode ser apagada.
Findings acumulados sem tratamento
Alertas graves se perdem no ruído e o tempo de resposta cresce.
Nenhum guardrail na organização
Cada conta depende da disciplina individual e desvia com o tempo.
Regiões não usadas sem restrição nem monitoramento
Viram ponto cego onde a atividade maliciosa passa despercebida.
Backups inexistentes ou nunca testados
Recuperação falha justamente quando mais se precisa dela.
Resposta a incidente nunca ensaiada
A contenção improvisada estende o tempo de exposição no pior momento.
Quando procurar apoio especializado
Uma revisão aprofundada, que cruze identidade, exposição, detecção e dados com o contexto do seu negócio, é o foco do serviço de Segurança AWS e Cloud Security da GUARDIASEC, com achados priorizados por risco e apoio ao hardening.
Perguntas frequentes
Este checklist substitui uma avaliação de segurança?
Não. Ele é um ponto de partida prático para encontrar exposições óbvias e priorizar correções, mas não cobre o contexto específico do seu ambiente nem caminhos de ataque encadeados. Uma avaliação aprofundada cruza identidade, exposição, detecção e dados com a criticidade do negócio, indo além de uma lista genérica.
Por onde começo se a lista parece grande demais?
Comece pelos itens de identidade e exposição, que têm o maior impacto: MFA na conta root, eliminar acesso administrativo amplo, fechar portas sensíveis e ativar o CloudTrail. Esses pontos reduzem rapidamente os caminhos de ataque mais prováveis. Depois avance para detecção, criptografia e resiliência.
Com que frequência devo revisar a postura da conta?
A postura muda conforme novos recursos e configurações são adicionados, então a revisão deve ser periódica, não única. Muitas equipes fazem revisões regulares e também após mudanças significativas de arquitetura. Ferramentas de postura, como o Security Hub, ajudam a acompanhar desvios de forma contínua entre as revisões.
Os itens deste checklist têm mais detalhes em algum lugar?
Sim. Cada tema deste checklist tem um guia dedicado nesta área de conteúdo, com mais profundidade: IAM, Security Groups, S3, CloudTrail, GuardDuty com Security Hub, hardening e outros. O checklist serve como mapa, e os guias específicos aprofundam cada ponto com boas práticas e erros comuns.
O checklist muda quando tenho várias contas AWS?
Muda no sentido de ganhar uma camada. Em uma conta única, você revisa identidade, exposição, detecção e dados dentro dela. Com várias contas, some a isso a governança da organização: SCPs que vedam ações perigosas em toda a estrutura, contas de log e de segurança separadas da produção e um baseline aplicado a novas contas desde a criação. O objetivo é que a postura não dependa da disciplina individual de cada conta, e sim de limites comuns que valem para todas.
Para que servem as SCPs no contexto deste checklist?
As Service Control Policies definem o teto de permissões para as contas de uma organização. Elas não concedem acesso, apenas impedem ações que ninguém deveria poder executar, como desativar o CloudTrail, encerrar o GuardDuty, sair da organização ou operar em regiões não aprovadas. No checklist, são o mecanismo que transforma boas intenções em barreiras efetivas: mesmo que uma política de IAM conceda algo por engano, a SCP veda a ação no nível da organização.
Como sei se a conta está preparada para um incidente?
Faça a pergunta prática: se uma credencial vazar agora, você consegue detectar, conter e investigar? Preparo significa ter a trilha de auditoria protegida e preservada, alertas para os eventos que sinalizam comprometimento, um caminho conhecido para revogar credenciais e isolar recursos, contatos de plantão definidos e backups imutáveis. A forma mais honesta de validar isso é um exercício simples, simulando o vazamento de uma credencial e percorrendo os passos de resposta, que costuma revelar lacunas que nenhum painel de postura mostra.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.