Segurança Multi-Contas AWS: 4 Passos para Blindar a Conta Raiz

Se a sua empresa ainda roda produção, desenvolvimento e auditoria dentro de uma única conta da AWS, você está operando sobre um campo minado. Em arquiteturas modernas em nuvem, o isolamento é a principal linha de defesa. Se um invasor ou um script malicioso conseguir acesso de administrador nessa conta única, o dano será irreversível: dados apagados, backups destruídos e logs de auditoria apagados para cobrir os rastros.

A solução definitiva para esse pesadelo arquitetural é a segurança multi-contas AWS. Ao distribuir suas cargas de trabalho em contas diferentes gerenciadas centralmente, você limita o “raio de explosão” (blast radius) de qualquer incidente. Neste artigo, vamos mostrar 4 passos fundamentais para implementar uma governança robusta usando o AWS Organizations.

1. O Fim do Monolito: Adotando o AWS Organizations

O primeiro passo para uma verdadeira segurança multi-contas AWS é abandonar a gestão manual de credenciais e abraçar o AWS Organizations. Essa ferramenta permite criar e gerenciar múltiplas contas da AWS a partir de uma única “Conta Gerenciadora” (a antiga conta Raiz).

A regra de ouro aqui é drástica, mas necessária: absolutamente nenhuma carga de trabalho deve rodar na Conta Gerenciadora. Nenhuma instância EC2, nenhum banco de dados RDS, nenhum bucket S3 com dados de clientes. O único propósito dessa conta é ser o cofre que gerencia o faturamento centralizado e as políticas de segurança das contas “filhas”. As chaves de acesso (Access Keys) do usuário Root dessa conta devem ser destruídas, e o login protegido por MFA (Múltiplo Fator de Autenticação) rigoroso, com acesso restrito a poucos diretores de nível C.

2. Estruturando suas OUs (Organizational Units) para Isolamento

Com o AWS Organizations ativado, você não joga as contas de forma bagunçada. Você as agrupa em OUs (Organizational Units), que funcionam como pastas organizacionais. Essa estrutura reflete as necessidades de segurança do seu negócio.

Uma arquitetura recomendada pela própria AWS para isolamento inclui:

• OU de Infraestrutura / Segurança: Contém contas dedicadas para o time de SecOps (ferramentas de segurança, GuardDuty, Macie) e contas de Rede (onde ficam os Transit Gateways e firewalls centralizados).
• OU de Workloads (Cargas de Trabalho): Aqui ficam as aplicações. Você deve separar uma sub-OU para Produção (Prod) e outra para Não-Produção (Dev/QA).
• OU de Sandbox: Um parquinho isolado para desenvolvedores testarem novos serviços da AWS. Se um desenvolvedor fizer besteira ou vazar uma credencial na Sandbox, o ambiente de Produção permanece intacto e inacessível.

3. SCPs: O Escudo de Proteção Inviolável

Se o IAM (Identity and Access Management) dita o que um usuário pode fazer, as Service Control Policies (SCPs) ditam o que ninguém pode fazer, nem mesmo o administrador daquela conta.

Aplicar SCPs nas OUs é o coração da segurança multi-contas AWS. Elas atuam como grades de proteção obrigatórias. Alguns exemplos práticos de políticas vitais que você deve aplicar via SCP incluem:

• Bloqueio de Região: Impedir que qualquer recurso seja criado fora das regiões homologadas pela empresa (ex: us-east-1 e sa-east-1), evitando que invasores subam máquinas de mineração de criptomoedas na Ásia.
• Proteção do CloudTrail: Proibir qualquer usuário de desativar ou alterar a configuração do AWS CloudTrail (a caixa-preta da sua infraestrutura).
• Proibição de Acesso à Internet: Em uma OU de banco de dados restrito, você pode aplicar uma SCP que impeça a criação de Internet Gateways, garantindo que o banco de dados nunca seja exposto à web, não importa o que o administrador da conta tente fazer.

4. Centralização de Logs em um Cofre Imutável

De nada adianta ter a melhor proteção se, durante um ataque, o invasor conseguir apagar os rastros do que fez. Em uma arquitetura de múltiplas contas, os logs não devem ficar espalhados.

O quarto passo é criar uma conta AWS dedicada exclusivamente a Arquivos e Auditoria (Log Archive). Utilizando o AWS CloudTrail integrado ao Organizations, você configura a Conta Gerenciadora para enviar todos os logs de todas as contas filhas diretamente para um Bucket S3 nessa conta de Auditoria central.

O segredo de segurança final: utilize o S3 Object Lock nesse bucket. Isso garante que os arquivos de log se tornem imutáveis (modelo WORM – Write Once, Read Many). Mesmo que a conta principal seja completamente comprometida, o invasor não terá permissão matemática ou sistêmica para modificar ou excluir os logs de auditoria enviados para o cofre.

Conclusão

A jornada de migrar de uma conta única para uma estrutura baseada no AWS Organizations pode parecer trabalhosa no início, mas é o preço da maturidade tecnológica. Blindar a conta raiz, segmentar ambientes em OUs, impor limites rígidos com SCPs e criar um cofre de logs imutável são ações que separam uma infraestrutura frágil de uma operação de classe mundial, pronta para auditorias e resistente a ataques.

Comece a planejar sua estratégia de separação hoje. Na nuvem, o isolamento é o seu melhor aliado.