Como as SCPs se Combinam com as Permissões do IAM

O acesso em uma organização é regido por duas camadas: o limite de SCP definido pelo AWS Organizations e as permissões do IAM concedidas dentro da conta. Entender como elas se combinam é uma das ideias mais cobradas em testes no domínio de governança, pois o resultado depende da concordância entre as duas.

A regra é simples, mas rigorosa: uma ação só é permitida se for autorizada tanto pelas SCPs aplicáveis quanto pelas políticas do IAM da conta. A permissão efetiva é a interseção. Uma SCP sem uma permissão correspondente do IAM não concede nada; uma permissão do IAM bloqueada por uma SCP também não concede nada.

Se a SCP permitir uma ação, mas nenhuma política do IAM a conceder, o resultado será negado pela negação implícita do IAM. A SCP apenas tornou a ação possível; o IAM ainda precisa concedê-la efetivamente. Muitos alunos esquecem que a SCP é um limite, não uma concessão.

Por outro lado, se uma política do IAM permitir uma ação, mas uma SCP a negar, o resultado será negado. A negação da SCP limita a conta independentemente do quanto o IAM seja permissivo. É assim que uma organização impõe limites rígidos que os administradores locais não podem substituir.

Somente quando tanto a SCP quanto uma política do IAM permitirem a ação, e não existir nenhuma negação explícita em lugar algum, a solicitação será permitida. Essa lógica de interseção é semelhante ao funcionamento dos limites de permissões, e ambos podem ser aplicados ao mesmo tempo, restringindo ainda mais as permissões.

Em um ambiente totalmente governado, vários limites se acumulam: a SCP (no nível da conta), o limite de permissões (no nível da identidade), qualquer política de sessão (no nível da sessão) e a política de identidade (a concessão). A permissão efetiva é a interseção de todos os limites somada à concessão, menos qualquer negação explícita.

Imagine uma política do IAM que concede s3:* e ec2:*, um limite de permissões que permite apenas s3:* e uma SCP que permite somente s3:GetObject. A permissão efetiva é apenas s3:GetObject, a interseção das três camadas. Cada limite reduz ainda mais as permissões.

Em todas as camadas, uma negação explícita em qualquer política, SCP, limite, sessão, identidade ou recurso bloqueia imediatamente a ação. Nenhuma combinação de permissões pode substituí-la. Ao analisar um cenário, procure primeiro qualquer negação explícita; se encontrar uma, a resposta é negação.

As políticas baseadas em recursos podem conceder acesso na mesma conta independentemente da política de identidade, mas as SCPs ainda limitam a conta do principal. Para acesso entre contas, aplicam-se os controles das duas contas e as políticas de ambos os lados. A regra da interseção se amplia, mas a ideia central permanece: todo limite aplicável precisa permitir a ação.

Quando o acesso falhar inesperadamente em uma organização, avance de dentro para fora: confirme se a política de identidade concede a ação; depois verifique o limite de permissões, as SCPs da conta e de cada OU pai, qualquer política de sessão e, por fim, procure uma negação explícita em todas as camadas. O primeiro limite que não incluir a ação, ou qualquer negação, é a causa do problema.

As SCPs e o IAM se combinam por interseção: uma ação precisa de uma permissão de ambos, além de quaisquer limites de permissões e de sessão, sem nenhuma negação explícita em lugar algum. As SCPs e os limites apenas restringem; as políticas do IAM concedem. Para permitir uma ação, todo limite precisa autorizá-la e deve existir pelo menos uma concessão.

Teste a lógica da combinação.

As SCPs e o IAM se combinam por interseção: uma ação só é permitida se ambos a autorizarem, além dos limites de qualquer limite de permissões e política de sessão, sem nenhuma negação explícita em lugar algum. As SCPs e os limites apenas restringem; as políticas do IAM concedem. Uma negação explícita em qualquer camada sempre prevalece sobre qualquer permissão.