Guia Prático de Governança Multi-Conta com Organizations, SCP e Control Tower
_Category: Governance_
Quando o ambiente cloud amadurece, os limites de operar com uma única conta AWS começam a aparecer. Quando as equipes de desenvolvimento, operações e segurança compartilham a mesma conta, as fronteiras de permissão ficam nebulosas e um erro em um ambiente pode impactar toda a operação. A estratégia multi-conta não é uma opção — é um pré-requisito para operações cloud em nível empresarial. Neste guia, vamos mapear o panorama completo da governança multi-conta com foco em AWS Organizations, SCP, Control Tower e Resource Access Manager, sempre com a perspectiva de quem trabalha na prática.
---
Por Que Multi-Conta: A Conta AWS Como Fronteira de Isolamento
A conta AWS não é apenas uma unidade de faturamento. Ela é uma fronteira de isolamento robusta onde políticas IAM, security groups, VPCs e cotas de serviço (Service Quotas) se aplicam de forma completamente independente. Recursos de contas diferentes não podem se comunicar sem políticas explícitas de acesso entre contas.
A estratégia multi-conta se justifica por quatro razões principais. Primeiro, o isolamento de segurança: o comprometimento de uma conta não se propaga para as demais. Segundo, a delimitação de conformidade: workloads PCI-DSS ficam isolados em contas dedicadas. Terceiro, a visibilidade de custos: a imputação de despesas por equipe ou projeto torna-se muito mais clara. Quarto, a separação de cotas de serviço: o esgotamento de limites por uma equipe não afeta as outras.
Embora a estratégia multi-conta aumente a complexidade operacional, é exatamente para isso que existem AWS Organizations e Control Tower.
---
AWS Organizations e Padrões de Design de OU
AWS Organizations é o serviço que agrupa várias contas AWS em uma única organização gerenciada centralmente. Dentro da organização, as contas são organizadas em uma estrutura de árvore chamada OU (Organizational Unit). Pense nas OUs como a hierarquia departamental de uma empresa: abaixo da sede (root) ficam as divisões de negócio (OUs), e dentro de cada divisão ficam as contas das equipes.
O padrão de design de OU mais recomendado para ambientes empresariais é o seguinte:
| OU | Contas Incluídas | Finalidade | |---|---|---| | Security OU | Log Archive, Security Tooling | Coleta centralizada de logs, ferramentas de segurança (administrador delegado do Security Hub, etc.) | | Infrastructure OU | Shared Services, Network | VPC compartilhada, Transit Gateway, DNS | | Sandbox OU | Contas de experimentos de desenvolvedores | Ambiente experimental com políticas mais flexíveis | | Workloads OU | Dev, Staging, Prod | Cargas de trabalho de serviços reais | | Suspended OU | Contas inativas | Isolamento antes do encerramento |
A conta Log Archive é dedicada a coletar logs do CloudTrail e do Config de todas as contas, garantindo que logs não possam ser apagados ou adulterados por outras contas. A conta Security Tooling assume o papel de administrador delegado do Security Hub e do GuardDuty, centralizando os alertas de segurança de toda a organização.
---
O Significado Preciso do SCP: Limite Máximo, Não Concessão
O SCP (Service Control Policy) é o conceito mais frequentemente mal interpretado dentro do Organizations. O SCP não concede permissões. Ele define o limite máximo de permissões que podem ser permitidas em uma determinada conta ou OU. Pense nele como um código de conduta corporativo: as pessoas (políticas IAM) só podem agir dentro do que o código permite.
Entender com clareza a diferença entre SCP e política IAM é central para o exame.
| Aspecto | SCP | Política IAM | |---|---|---| | Alvo de aplicação | Conta ou OU inteira (incluindo root) | Usuários, funções ou grupos individuais | | Pode conceder permissões? | Não — define apenas o limite | Sim — concede permissões diretamente | | Pode ser revogado pelo admin da conta? | Não | Sim | | Escopo de aplicação | Todas as entidades IAM na conta membro | Apenas a entidade à qual está vinculado | | Aplicado à conta de gerenciamento? | Não | Sim |
A avaliação do SCP ocorre de forma encadeada: root → OU pai → OU filho → conta. Todas as camadas de SCP e a política IAM devem permitir a ação para que o acesso seja concedido. Uma negação explícita (Deny) em qualquer camada bloqueia a ação.
Os três padrões de SCP mais usados na prática são: restrição de região (usando a condição aws:RequestedRegion), proteção da conta root e prevenção de desativação de serviços de segurança. Na restrição de região, serviços globais como IAM, CloudFront, Route 53 e STS devem ser tratados como exceções usando NotAction.
---
Control Tower e Landing Zone: Automação da Governança
Control Tower funciona como um manual padronizado para abertura de novas filiais. Para equipes que estão construindo um ambiente multi-conta pela primeira vez, ele configura automaticamente uma estrutura base (Landing Zone) seguindo as melhores práticas, eliminando o trabalho repetitivo de criar OUs manualmente, vincular SCPs e provisionar contas.
Os principais componentes da Landing Zone configurados automaticamente pelo Control Tower são:
| Componente | Descrição | |---|---| | Root OU | Nível mais alto da organização, onde fica a conta de gerenciamento | | Security OU | Criação automática da conta Log Archive e da conta Audit | | Sandbox OU | Isolamento de contas de experimentação | | Guardrails (Controls) | Aplicação automática de regras de governança preventivas e detectivas | | Account Factory | Provisionamento automático de novas contas com configurações padronizadas | | Dashboard | Visão consolidada do status de conformidade de todas as contas |
Os Guardrails têm dois tipos. Os Guardrails preventivos são implementados via SCP e bloqueiam diretamente a criação de recursos que violam as regras. Os Guardrails detectivos são implementados via regras do AWS Config e identificam estados de não conformidade para disparar notificações.
O Account Factory opera com base no Service Catalog. Quando uma solicitação de nova conta chega, ele aplica automaticamente um template predefinido — configurações de VPC, funções IAM, tags, conexão de logs — e entrega uma conta padronizada. Com o Account Factory for Terraform (AFT), é possível gerenciar o ciclo de vida das contas como IaC usando Terraform.
Vale também conhecer os outros tipos de política do Organizations. Tag Policy força padrões de tags em nível organizacional. AI Services Opt-out Policy garante que serviços como Amazon Rekognition e Comprehend não usem dados dos usuários para treinamento de modelos — aplicável a toda a organização de uma só vez. Backup Policy impõe planos do AWS Backup de forma centralizada.
---
Serviços de Segurança em Toda a Organização: Security Hub, GuardDuty, Config e Macie
Em ambientes multi-conta, ativar serviços de segurança individualmente em cada conta representa uma carga operacional enorme. A AWS oferece integração com Organizations em cada um de seus serviços de segurança, permitindo ativar tudo com uma única configuração em todas as contas e gerenciar de forma centralizada em uma conta dedicada. Essa conta que assume o gerenciamento central é o Delegated Administrator.
A ordem correta de ativação dos serviços de segurança em toda a organização é importante. O AWS Config deve ser ativado primeiro. O Security Hub só funciona corretamente com o Config já ativo, pois seus padrões de segurança (CIS, AWS Foundational) dependem diretamente dos resultados de avaliação das regras do Config. Em seguida, configure o GuardDuty para ativação automática em toda a organização e, ao ativar o Security Hub, os findings do GuardDuty são automaticamente agregados sem necessidade de configuração adicional via EventBridge. O Macie segue o mesmo padrão, sendo ativado em lote pela conta do administrador delegado.
A conta de Delegated Administrator recomendada é a conta Security Tooling. Em vez de operar a segurança diretamente pela conta de gerenciamento, delegar para uma conta especializada minimiza a exposição de privilégios da conta de gerenciamento.
Resumo da integração organizacional por serviço de segurança:
| Serviço | Suporte a Delegated Administrator | Ativação Automática | Agregação Central | |---|---|---|---| | Security Hub | Sim | Sim | Todos os findings de todas as regiões agregados na Aggregation Region | | GuardDuty | Sim | Sim | Findings dos membros consultados pela conta gerenciadora | | AWS Config | Sim | Configuração separada necessária | Agregação multi-conta via Config Aggregator | | Amazon Macie | Sim | Sim | Findings dos membros consultados pela conta gerenciadora | | IAM Access Analyzer | Sim | Sim | Criação de analisador com escopo organizacional |
---
Resource Access Manager e Compartilhamento de Recursos entre Contas
O Resource Access Manager (RAM) é o serviço que permite compartilhar recursos AWS com outras contas ou com toda a organização. Quando criar o mesmo recurso em cada conta seria mais caro ou complexo do que centralizar e compartilhar, o RAM é a solução adequada.
Os principais recursos que podem ser compartilhados via RAM incluem sub-redes VPC, Transit Gateway, regras do Route 53 Resolver e licenças do License Manager. O padrão mais comum é o compartilhamento de sub-redes VPC. Uma conta central de networking cria a VPC compartilhada e compartilha as sub-redes com as contas de workload. Cada conta de workload mantém suas próprias fronteiras de IAM e segurança, mas todas utilizam a mesma infraestrutura de rede. Isso elimina a duplicação de VPCs e simplifica o gerenciamento de conectividade.
Quando o compartilhamento ocorre dentro da mesma organização via Organizations, o destinatário não precisa aceitar um convite — o compartilhamento é aplicado automaticamente. Já para compartilhar com contas externas à organização, é necessária uma aceitação explícita.
O outro eixo central do modelo de permissões entre contas é o IAM Identity Center (an