Intermediário

AWS Organizations e estrutura de OUs

Lição 6 · Módulo 2 — Contas como fronteira

Well-Architected: SEC01-BP01

As peças do AWS Organizations

O AWS Organizations gerencia várias contas de forma central. Uma organização é uma árvore com estas peças:

PeçaO que é
RootO contêiner do topo da hierarquia (não confunda com o usuário root de uma conta). Só existe um.
Conta de gerenciamentoA conta que criou a organização. Cria e convida contas, anexa políticas, ativa integrações e paga a fatura de todas. Não pode ser trocada.
Contas-membroTodas as outras. Cada uma pertence a uma única organização por vez.
OUOrganizational unit: grupo de contas (e de outras OUs). Até cinco níveis de OUs abaixo do root.
PolíticasDocumentos anexados ao root, a OUs ou a contas, que valem para tudo abaixo do ponto onde foram anexados.

Para usar políticas, a organização precisa estar com all features habilitado (o padrão). O modo só de consolidated billing não permite políticas nem integrações com serviços.

A conta de gerenciamento fica mínima

A conta de gerenciamento é a dona final da organização, e as SCPs não restringem usuários nem roles dentro dela. Por isso a AWS recomenda:

  • Não colocar workloads nem dados nela; só o que precisa ser feito ali.
  • Limitar e revisar periodicamente quem tem acesso (e-mail, senha, MFA e telefone do root).
  • Delegar administração de serviços para contas-membro (administrador delegado), como as contas de segurança e de logs.

Herança de políticas

Políticas anexadas a uma OU valem para todas as contas e OUs abaixo dela, somadas às que estão anexadas diretamente nos níveis inferiores. Um bom desenho usa essa herança para ter poucas políticas, aplicadas no nível certo.

Estrutura
1
2
3
4
5
6
7
8
9
Root ← SCP: negar sair da organização
├── Security ← SCP: proteger trilhas e logs
│ ├── log-archive
│ └── security-tooling
└── Workloads
├── Prod ← SCP: negar regiões não aprovadas
│ └── pagamentos-prod (herda Root + Workloads + Prod)
└── Test
└── pagamentos-test (herda Root + Workloads + Test)

Nas SCPs, um Deny em qualquer nível acima alcança a conta; e uma ação só fica disponível se for permitida em todos os níveis do caminho. Detalhes de avaliação e exemplos estão na lição de guardrails com SCP e RCP da trilha de IAM.

Tipos de política da organização

A AWS divide as políticas do Organizations em duas categorias:

CategoriaTiposPara quêAfeta a conta de gerenciamento?
AutorizaçãoSCP, RCPDefinir o máximo de permissões: SCP para principais (users e roles), RCP para recursosNão
Declarativas / gestãoBackup, tag, AI services opt-out, chat applications, EC2 (declarativa), Security Hub, Amazon Inspector, Amazon GuardDuty, Amazon Bedrock, S3, upgrade rollout e outrasConfigurar serviços e recursos de forma central e consistenteSim

A lista de tipos cresce com frequência; confira a página Managing organization policies antes de planejar. Cada tipo precisa ser habilitado no root da organização antes do uso.

As OUs recomendadas

O whitepaper Organizing Your AWS Environment Using Multiple Accounts agrupa as OUs recomendadas em categorias:

CategoriaOUs
Fundamentais (foundational)Security (contas Log Archive e Security Tooling) e Infrastructure (rede, ferramentas de operação, backup)
AplicaçãoWorkloads, com produção e não produção, normalmente em OUs filhas
ExperimentaisSandbox
ProcedimentaisExceptions, Transitional, Suspended, Policy Staging
AvançadasIndividual Business Users, Deployments, Business Continuity

Você não precisa criar todas no primeiro dia. Para o propósito de cada uma e as políticas típicas, veja a referência Estrutura de OUs recomendada.

Teste rápido

Uma SCP que nega a desativação do CloudTrail foi anexada ao root da organização. Um administrador desativa uma trilha na conta de gerenciamento. O que acontece?

Você vai mudar uma SCP que afeta todas as contas de produção. Qual OU recomendada serve para validar a mudança antes?

Resumo

O AWS Organizations organiza contas em uma árvore: root, OUs e contas. Políticas anexadas em um nível são herdadas abaixo dele. SCPs e RCPs limitam permissões e não afetam a conta de gerenciamento, que deve ficar sem workloads. As OUs fundamentais são Security e Infrastructure; as demais entram conforme a necessidade.

Referência Well-Architected

SEC01-BP01 Separate workloads using accounts — o primeiro passo de implementação é desenhar a estrutura de OUs alinhada ao negócio, à sensibilidade dos dados e aos workloads.

Referências

Terminou esta lição?

Seu progresso fica salvo apenas neste navegador.