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, escrever guardrails com Deny e condições, restringir regiões e proteger serviços críticos, entender onde as RCPs entram e evitar a 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.
Herança e a conta de gerenciamento
SCPs herdam pela hierarquia: uma conta é limitada pela interseção das políticas aplicadas à raiz, às OUs acima dela e a ela própria. Uma ação só é permitida se nenhuma SCP no caminho a vedar. A conta de gerenciamento é a exceção importante: SCPs não se aplicam a ela, então não conte com guardrails para conter essa conta. Trate-a como altamente privilegiada, use-a o mínimo possível e mantenha as cargas em contas membro.
Anatomia de um guardrail com Deny
A estratégia mais previsível é partir da política que permite tudo e adicionar SCPs de Deny para vetar o que nunca deve acontecer. Deny com condição é mais seguro do que montar listas de Allow, porque uma lista de permissão esquecida bloqueia serviços legítimos de forma silenciosa. Restringir as regiões permitidas é um guardrail de alto valor: ele reduz a superfície ao impedir que recursos surjam em regiões que você não usa nem monitora, onde atacantes costumam operar.
{
"Effect": "Deny",
"NotAction": [
"iam:*", "sts:*", "cloudfront:*",
"route53:*", "support:*", "organizations:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["sa-east-1", "us-east-1"]
}
}
}O NotAction preserva os serviços globais, como IAM, STS, CloudFront e Route 53, que operam em uma região de controle e quebrariam se fossem apanhados pela restrição de região. Ajuste a lista de exceções ao que você de fato usa e teste antes de aplicar em produção.
{
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"guardduty:DeleteDetector",
"config:DeleteConfigurationRecorder"
],
"Resource": "*"
}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.
Guardrails comuns e RCPs
Além da restrição de região e da proteção dos serviços de segurança, alguns guardrails aparecem em quase toda estrutura madura. Vale aplicá-los por OU conforme o ambiente, com produção mais rígida que a sandbox.
- Impedir desabilitar CloudTrail, GuardDuty e Config
- Proteger roles e recursos de auditoria contra alteração
- Restringir as regiões permitidas para uso
- Vedar exclusão de logs e alteração de bucket de auditoria
- Bloquear a saída de contas da organização e mudanças na estrutura
- Aplicar guardrails diferentes por OU conforme o ambiente
SCPs limitam o que os principals da conta podem fazer. As Resource Control Policies, ou RCPs, atuam pelo outro lado: elas limitam quem, mesmo de fora, pode acessar recursos das suas contas, como buckets S3 e filas. Uma RCP pode exigir, por exemplo, que só principals da sua organização acessem determinados recursos, fechando o acesso a identidades externas. SCP e RCP se complementam: uma governa as identidades de dentro, a outra protege os recursos contra acesso de fora.
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 não é limitada por SCP. Documente cada guardrail e o motivo de existir.
Cuidado com o efeito de serviços globais e de serviços que criam recursos em seu nome. Uma restrição de região mal calibrada pode quebrar a emissão de certificados, a distribuição de conteúdo ou a resolução de DNS, porque esses serviços operam em uma região de controle. Por isso o NotAction com as exceções certas e o teste prévio são parte do desenho, não um detalhe.
Checklist prático
- Organizar contas em OUs por ambiente e função
- Manter contas dedicadas para log e auditoria
- Preferir guardrails com Deny e condição a listas de Allow
- Impedir desabilitar serviços de segurança via SCP
- Proteger recursos de auditoria contra alteração e exclusão
- Restringir as regiões permitidas preservando serviços globais no NotAction
- Avaliar RCPs para limitar acesso externo aos recursos
- 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, pois SCP não a limita
Boas práticas
- Use SCPs como guardrails amplos, não como controle de acesso fino
- Prefira Deny com condição a montar listas de Allow frágeis
- 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.
Restringir região sem excluir serviços globais
Quebra IAM, CloudFront, Route 53 e emissão de certificados de forma difícil de diagnosticar.
Logs e auditoria na mesma conta de produção
Um comprometimento de produção alcança a trilha de auditoria.
Contar com SCP para conter a conta de gerenciamento
SCPs não se aplicam a ela, então o guardrail esperado não existe.
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, RCPs 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. O cuidado é preservar serviços globais no NotAction, para não quebrar IAM, CloudFront e emissão de certificados.
Qual a diferença entre SCP e RCP?
A SCP limita o que os principals das suas contas podem fazer, agindo sobre as identidades de dentro da organização. A RCP, ou Resource Control Policy, limita quem pode acessar os recursos das suas contas, inclusive identidades externas, agindo sobre o recurso. Uma governa quem pode agir a partir de dentro, a outra protege os recursos contra acesso vindo de fora. Em ambientes maduros, elas se usam juntas.
Devo usar Allow ou Deny nas SCPs?
Para a maioria dos casos, partir da permissão total e adicionar SCPs de Deny é mais previsível. Listas de Allow parecem mais restritivas, mas bloqueiam de forma silenciosa qualquer serviço que você esqueceu de incluir, o que costuma virar incidente operacional. Deny com condição expressa exatamente o que é proibido e deixa o resto funcionar.
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.