Segundo post do Nível Especialista da série AWS IAM. Quando você tem dezenas de contas, controlar cada uma individualmente é inviável e arriscado. É aqui que entram as Service Control Policies (SCPs) e o AWS Organizations — os guardrails que garantem que nenhuma conta saia da linha, nem mesmo por engano.
📚 O que você vai aprender neste post:
- O que é o AWS Organizations e as OUs;
- Como as SCPs funcionam como guardrails de conta;
- Um exemplo prático de restrição de região;
- Um roteiro de implantação segura de SCPs;
- Estratégias e boas práticas.
O que é o AWS Organizations?
O AWS Organizations permite gerenciar várias contas AWS de forma centralizada, agrupando-as em uma hierarquia de Organizational Units (OUs). Com ele você aplica políticas de governança, consolida o faturamento e padroniza a segurança em toda a empresa. As OUs costumam refletir a estrutura organizacional ou de ambientes — por exemplo, uma OU “Produção”, uma “Desenvolvimento” e uma “Sandbox”, cada uma com regras diferentes.
SCPs: guardrails para contas inteiras
Uma Service Control Policy define o teto máximo de permissões para uma conta ou OU inteira. Assim como as permission boundaries limitam identidades, as SCPs limitam contas. Elas seguem a herança da hierarquia: uma SCP aplicada a uma OU vale para todas as contas abaixo dela.
Ponto crucial: SCP não concede permissão. Ela apenas define o que é permitido no máximo. Uma ação só ocorre se for permitida tanto pela SCP quanto pelas políticas IAM da identidade. E mais: nem o usuário root de uma conta-membro escapa de uma SCP — é isso que as torna um guardrail tão forte.
🛠️ Mão na massa: restringir regiões
Um uso muito comum é impedir que recursos sejam criados fora das regiões aprovadas — por conformidade, soberania de dados ou controle de custos. Esta SCP nega tudo fora de us-east-1 e sa-east-1:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "NotAction": [ "iam:*", "sts:*", "cloudfront:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "us-east-1", "sa-east-1" ] } } } ] }
Repare no NotAction: serviços globais (como IAM, STS e CloudFront) ficam de fora da restrição de região, pois não pertencem a uma região específica — bloqueá-los quebraria a conta. Aplique esta SCP a uma OU de teste primeiro, valide que nada legítimo quebrou, e só então propague para produção.
Estratégias comuns com SCPs
- Bloquear serviços não aprovados em toda a organização.
- Proteger recursos críticos — impedir a desativação de CloudTrail, GuardDuty ou Config.
- Impor limites de região por conformidade.
- Criar OUs de “sandbox” com mais liberdade e OUs de “produção” mais restritas.
- Exigir tags ou negar a criação de recursos sem criptografia.
✅ Boas práticas
- Comece pela SCP padrão
FullAWSAccesse vá restringindo com Deny, em vez de tentar listar todos os Allow. - Teste em uma OU de baixo risco antes de aplicar amplamente — uma SCP mal calibrada pode travar operações legítimas.
- Nunca aplique SCPs restritivas diretamente na conta de gerenciamento (management account) — ela é imune a SCPs, o que pode gerar falsa sensação de teste.
- Combine SCPs (nível de conta) com permission boundaries (nível de identidade) para defesa em profundidade.
💡 Resumo dos pontos-chave
SCPs são guardrails de conta/OU: definem o teto, não concedem. Nem o root escapa delas. Construa restringindo com Deny, teste em OUs de baixo risco e combine com boundaries para defesa em profundidade.
SCPs x boundaries: camadas complementares
É comum confundir SCPs com permission boundaries, já que ambas “limitam sem conceder”. A diferença está no alcance: a SCP atua sobre contas e OUs inteiras e é gerenciada centralmente pela organização; a boundary atua sobre uma identidade específica e costuma ser aplicada pelas equipes ao criar usuários e roles. Elas não competem — se complementam, formando camadas: a SCP define o teto da conta, e a boundary refina o teto de cada identidade dentro dela.
Na prática de governança, times de plataforma/segurança cuidam das SCPs (guardrails amplos e estáveis), enquanto os times de aplicação usam boundaries para delegar a criação de roles com segurança. Essa divisão de responsabilidades escala bem em organizações grandes.
Deny-list x allow-list: qual estratégia?
Há duas filosofias para desenhar SCPs. A abordagem deny-list parte do FullAWSAccess e nega comportamentos específicos (mais simples de adotar, menos propensa a quebrar coisas). A abordagem allow-list parte do zero e permite explicitamente apenas os serviços aprovados (muito mais restritiva, porém exige manutenção constante à medida que novos serviços são adotados). A maioria das organizações começa com deny-list e evolui para allow-list em OUs de alta criticidade.
Seja qual for a escolha, versione suas SCPs em repositório (policy as code) e submeta mudanças a revisão. Guardrails que valem para contas inteiras merecem o mesmo rigor de um deploy de produção.
Monitorando o efeito das SCPs
Depois de aplicar uma SCP, acompanhe o impacto real. O CloudTrail registra as negações, e vale criar alertas para picos de “Access Denied” logo após uma mudança — muitas vezes é o sinal de que a SCP barrou algo legítimo que passou despercebido no teste. Lembre-se também de que há um limite para o número de SCPs anexadas por conta/OU; por isso, prefira poucas políticas bem estruturadas a dezenas de regras avulsas, que ficam difíceis de manter e auditar.
No próximo post
Encerramos a série com o IAM Access Analyzer: como detectar automaticamente privilégios excessivos e acessos externos não intencionais. O grand finale! 🏁
Informações sobre o autor
Dennis Silva atua com Segurança da Informação e Cibersegurança há +18 anos e iniciou sua carreira em uma das Big Four em auditoria de sistemas.
Atualmente, atua como Consultor de Cibersegurança no time de Professional Services da AWS na América Latina (Brasil), função que exerce há mais de 4 anos, com foco no atendimento a instituições financeiras.
Trabalhou como Coordenador de Segurança da Informação na maior empresa de desenvolvimento de software na América Latina. Anteriormente, atuou como consultor de Segurança da Informação, com foco em identificar e avaliar os riscos inerentes ao negócio e validar os controles existentes por meio de testes de invasão em infraestrutura interna/externa, aplicações Web e ERPs como SAP e TOTVS.
Foi responsável pela implementação da certificação ISO/IEC 27001:2013 na maior empresa de desenvolvimento de software da América Latina, potencializando a principal oferta de comercialização de software como serviço (SaaS) em datacenter próprio.