Perímetro de dados na AWS: SCPs e RCPs contra acesso externo

Contas AWS espalhadas por várias equipes não podem depender da disciplina individual de cada desenvolvedor para manter o acesso sob controle. As SCPs (service control policies) e as RCPs (resource control policies) do AWS Organizations formam o perímetro de dados da organização: limitam o que identidades internas conseguem fazer e bloqueiam o que identidades de fora tentam acessar nos recursos da empresa. A ação prioritária é habilitar os dois tipos de política na organização, validar o impacto em uma OU de preparo e só depois escalar para a raiz.

O que cada política controla

SCP e RCP são controles preventivos independentes que atuam em lados opostos da avaliação de permissões. A SCP vale para os principals das contas-membro — usuários IAM e roles — e as SCPs não concedem permissões: definem apenas o teto de permissões disponíveis para cada principal, limitando o máximo que uma política de identidade ou de recurso consegue permitir. A permissão efetiva é a interseção lógica entre o que a SCP permite e o que as políticas anexadas ao principal concedem, como detalha a documentação oficial do AWS Organizations sobre SCPs: nenhum acesso é concedido por uma SCP.

A RCP opera no lado dos recursos. Ela é avaliada sempre que um principal chama um recurso autorizado de uma conta-membro, não importa de qual conta a chamada partiu — inclusive o root user de outra organização. Se um desenvolvedor anexar uma política de bucket que libere acesso amplo para uma conta desconhecida, a RCP entra na avaliação de autorização e a chamada externa é negada mesmo com a política permissiva no lugar. É esse casamento entre SCP e RCP que sustenta o perímetro de dados descrito pelo time de segurança da AWS.

SCPs e a hierarquia de contas

Toda SCP anexada a uma OU é herdada pelas OUs filhas e pelas contas abaixo dela. Um Deny em qualquer nível da hierarquia — raiz, OU intermediária ou conta — vence qualquer Allow que venha depois, e a SCP afeta até o root user da conta-membro. Por isso a ordem de implantação importa mais que a pressa: a própria AWS recomenda não anexar SCP à raiz sem testar antes, movendo contas em pequenos grupos para uma OU de preparo e observando o efeito com o simulador de políticas do IAM.

Existe uma exceção estrutural que toda equipe precisa conhecer: SCPs não afetam a conta de gerenciamento da organização. Essa conta fica fora do alcance dos guardrails de principals e, por isso, não deveria hospedar cargas de trabalho — ela serve para criar a organização, gerenciar OUs e políticas, e nada além disso. Nas contas-membro, o acesso root também merece tratamento centralizado: a AWS permite desabilitar o login root das contas-membro e executar as ações privilegiadas de root de forma central, eliminando credenciais root espalhadas pela organização. Quem já trabalha com identidade federada encontra a mesma lógica nos níveis FAL do NIST aplicados à federação de identidade.

Para afinar as políticas sem quebrar nada, o service last accessed data do IAM mostra quais serviços permitidos nunca foram usados em cada conta — insumo direto para transformar uma deny-list genérica em uma lista que reflete o uso real. Cruzar esse dado com o CloudTrail em nível de API revela permissões mortas e reduz a superfície antes de qualquer allow-list entrar em vigor.

RCPs fecham o perímetro externo

Quando as RCPs são habilitadas na organização, a política gerenciada RCPFullAWSAccess é anexada automaticamente à raiz, a cada OU e a cada conta — e não pode ser desanexada. Ela não concede nada: apenas permite que toda a avaliação passe até que você crie suas próprias RCPs com statements Deny. O modelo mental é o mesmo das SCPs, só que aplicado a recursos. Na prática, a RCP existe para restringir identidades externas à organização — principals de outras contas, de parceiros ou de atacantes — que tentam acessar recursos das contas-membro, conforme a documentação de RCPs do AWS Organizations.

O caso de uso clássico é o perímetro de identidade em S3: uma RCP com um Deny sobre s3:* que só libera chamadas cujo aws:PrincipalOrgID corresponda ao ID da organização, com exceção para serviços da AWS agindo em nome da empresa. Um segundo statement, com aws:SourceOrgID, protege contra o cenário de confused deputy, em que um serviço configurado por terceiros tenta alcançar seus dados. O guia do blog de segurança da AWS sobre estabelecer perímetro de dados traz as políticas de exemplo prontas para adaptar.

Antes de ligar a RCP na raiz, o caminho de menor risco é medir: revisar os achados de acesso externo do IAM Access Analyzer e consultar o CloudTrail central — com Athena, dá para listar as chamadas STS feitas contra seus roles por identidades de fora e comparar com a lista de parceiros conhecidos, com a mesma disciplina de sessões e credenciais que endurece tokens de acesso na nuvem no guia do NIST. Esse passo evita quebrar integração legítima de terceiros no dia do corte.

Estratégia deny-list na prática

A configuração padrão do AWS Organizations trabalha com SCPs como deny-list: tudo é permitido até que um Deny explícito bloqueie. Statements de negação exigem menos manutenção porque não precisam de atualização quando a AWS lança serviços novos, e costumam ser mais curtos — o que ajuda no limite de tamanho da política. O allow-list, em que se troca a FullAWSAccess por uma política que só permite serviços aprovados, é mais restritivo e cabe em cargas reguladas, mas exige permitir explicitamente cada ação no caminho da conta até a OU. A orientação da arquitetura de referência de segurança da AWS é combinar os dois: allow-list na raiz definindo os serviços aprovados e deny-list por OU para os guardrails corporativos, como impedir o desligamento de CloudTrail, GuardDuty e AWS Config, impedir alteração do block public access e negar regiões fora das aprovadas.

Além das políticas de autorização, o Organizations oferece políticas declarativas que definem a configuração desejada de um serviço em escala — como bloquear acesso público à internet em recursos de VPC — impostas no plano de controle do serviço, e não na camada de autorização de API. Elas completam o kit sem substituir SCP ou RCP.

Plano de implantação P1 e P2

Com as peças explicadas, a implantação segue uma ordem que minimiza risco de indisponibilidade: primeiro os controles que fecham o perímetro e protegem a telemetria, depois os refinamentos de superfície. A tabela consolida as ações em duas ondas.

Exceções fazem parte do desenho. Parceiros de negócio podem entrar na RCP com aws:PrincipalAccount listando contas confiáveis, e contas com requisitos especiais podem morar em uma OU de exceções com SCPs próprias — o padrão recomendado pela AWS para casos de auditoria customizada. Documentar cada exceção com dono e prazo evita que o perímetro vire uma peneira silenciosa.

Para quem precisa de uma lista de verificação independente do fabricante, o benchmark de fundamentos da AWS mantido pelo CIS está na versão 7.1.0 e reúne diretrizes consensuais de configuração segura, disponíveis na página dos CIS Amazon Web Services Benchmarks — ponto de partida útil para auditorias de conta antes e depois do perímetro entrar no ar.

Os sinais de que o perímetro funciona aparecem nos logs: chamadas negadas por SCP e RCP registradas no CloudTrail, ausência de achados de acesso externo não justificado no Access Analyzer e nenhuma conta fora da organização. Sem esses três indicadores, o controle existe no papel, mas não na operação.

Fontes

• AWS Organizations — Service control policies
• AWS Organizations — Resource control policies
• AWS Prescriptive Guidance — Using AWS Organizations for security
• AWS Security Blog — Establishing a data perimeter on AWS
• CIS — Amazon Web Services Benchmarks