AWS Organizations e SCPs: governança de segurança em múltiplas contas
SCPs definem o teto de permissões de toda a estrutura. Veja como criar guardrails sem travar a operação.
À medida que a organização cresce na AWS, separar cargas em várias contas vira a melhor prática de isolamento. O AWS Organizations gerencia esse conjunto de contas, e as Service Control Policies, ou SCPs, são o mecanismo que define o teto de permissões para cada conta dentro da estrutura. SCPs não concedem acesso; elas vedam, criando guardrails que nenhuma identidade da conta pode ultrapassar.
Este guia mostra como usar Organizations e SCPs para governança de segurança de forma defensiva: organizar contas em OUs, criar guardrails sensatos, restringir regiões e proteger serviços críticos, sem cair na armadilha de uma SCP mal planejada que quebra a operação inteira.
Contas, OUs e estratégia
Organize as contas em unidades organizacionais, ou OUs, que reflitam ambientes e funções: produção, homologação, segurança, log e sandbox, por exemplo. As SCPs se aplicam por OU, então uma boa estrutura de OUs permite aplicar guardrails diferentes a contextos diferentes. Produção pode ter restrições mais rígidas, enquanto a sandbox tolera mais liberdade.
Mantenha contas dedicadas para funções de segurança, como uma conta de log centralizado e uma conta de auditoria. Isolar essas funções evita que o comprometimento de uma conta de produção alcance os logs e a trilha de auditoria.
Guardrails e restrição de região
Guardrails comuns incluem impedir a desabilitação de serviços de segurança, como CloudTrail e GuardDuty, vedar a alteração de roles de auditoria e bloquear ações perigosas em toda a estrutura. Restringir as regiões permitidas é um guardrail de alto valor: ele reduz a superfície ao impedir que recursos sejam criados em regiões que você não usa nem monitora, onde atacantes costumam operar.
- Impedir desabilitar CloudTrail, GuardDuty e Config
- Proteger roles e recursos de auditoria contra alteração
- Restringir as regiões permitidas para uso
- Vedar ações perigosas amplas em toda a organização
- Aplicar guardrails diferentes por OU conforme o ambiente
Lembre que SCP é um teto, não uma concessão. Uma conta ainda precisa de políticas de IAM para conceder permissões dentro do que a SCP permite. Os dois mecanismos trabalham juntos: SCP veda, IAM concede.
Riscos de uma SCP mal planejada
O maior risco das SCPs é o impacto amplo: uma política mal escrita pode bloquear ações legítimas em dezenas de contas de uma vez. Teste mudanças primeiro em uma OU de teste, evite negar ações sem entender as dependências e tenha cuidado especial com a conta de gerenciamento, que tem regras próprias. Documente cada guardrail e o motivo de existir.
Checklist prático
- Organizar contas em OUs por ambiente e função
- Manter contas dedicadas para log e auditoria
- Impedir desabilitar serviços de segurança via SCP
- Proteger recursos de auditoria contra alteração
- Restringir as regiões permitidas
- Aplicar guardrails diferenciados por OU
- Testar SCPs em OU de teste antes de produção
- Documentar cada guardrail e sua justificativa
- Revisar SCPs ao adicionar novos serviços
- Tratar a conta de gerenciamento com cuidado especial
Boas práticas
- Use SCPs como guardrails amplos, não como controle de acesso fino
- Estruture OUs para aplicar políticas por contexto
- Isole funções de segurança em contas dedicadas
- Restrinja regiões para reduzir superfície não monitorada
- Teste mudanças de SCP antes de aplicar em produção
- Documente a intenção de cada guardrail
Erros comuns
SCP de negação ampla sem entender dependências
Bloqueia ações legítimas em muitas contas de uma só vez.
Não restringir regiões
Recursos podem surgir em regiões não monitoradas, onde atacantes operam.
Logs e auditoria na mesma conta de produção
Um comprometimento de produção alcança a trilha de auditoria.
Tratar SCP como concessão de acesso
Confusão de modelo: a conta segue sem permissões sem o IAM adequado.
Aplicar SCP direto em produção sem teste
Risco de interromper operações críticas em escala.
Quando procurar apoio especializado
Desenhar uma estrutura de contas e guardrails que equilibre segurança e operação é trabalho de arquitetura de governança. A GUARDIASEC apoia isso nos serviços de Consultoria em Segurança e de Segurança AWS, definindo OUs, SCPs e separação de ambientes.
Perguntas frequentes
SCP concede permissões?
Não. SCP define apenas o teto de permissões para as contas de uma organização; ela veda, mas não concede. As permissões reais continuam vindo das políticas de IAM dentro de cada conta, limitadas pelo que a SCP permite. Os dois mecanismos trabalham juntos: a SCP estabelece o limite e o IAM concede dentro dele.
Por que restringir regiões com SCP?
Restringir as regiões permitidas reduz a superfície de ataque, porque impede a criação de recursos em regiões que você não usa nem monitora. Atacantes frequentemente operam em regiões esquecidas justamente porque ninguém olha para elas. Limitar regiões também facilita a auditoria e a detecção, concentrando a atividade onde há visibilidade.
SCP pode quebrar minha operação?
Sim, se for mal planejada. Uma negação ampla pode bloquear ações legítimas em muitas contas ao mesmo tempo. Por isso o recomendado é testar mudanças em uma OU de teste, entender as dependências antes de negar ações e documentar cada guardrail. Mudanças de SCP devem ser tratadas como alterações críticas e monitoradas.
Preciso de Organizations mesmo com poucas contas?
Mesmo com poucas contas, o Organizations facilita a gestão centralizada, a consolidação de faturamento e a aplicação de guardrails. O valor cresce com o número de contas, mas estruturar cedo, com contas separadas para produção, segurança e log, evita ter que reorganizar tudo depois, quando a complexidade já aumentou.
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.