Fluxo de Decisão da Avaliação de Políticas

Quando qualquer requisição chega à AWS, o mecanismo do IAM executa um fluxo de avaliação preciso para decidir entre Allow e Deny. Memorizar essa ordem é uma das coisas mais valiosas que você pode fazer para a prova SCS-C02, pois questões complexas baseadas em cenários dependem de qual tipo de política prevalece quando várias estão em vigor.

O ponto de partida é sempre uma negação implícita. Se nada na avaliação conceder acesso, a solicitação será negada. Essa postura de negar por padrão significa que é necessário permitir explicitamente uma ação em algum lugar para que ela seja bem-sucedida; o silêncio equivale à negação.

A regra mais importante: uma negação explícita em qualquer política aplicável prevalece sobre toda permissão. Não importa quantas instruções concedam a ação: uma única negação correspondente a bloqueia. É assim que as barreiras de proteção e as SCPs impõem limites rígidos que as políticas de nível inferior não podem substituir.

AWS avalia nesta ordem conceitual: 1) verifica se há uma negação explícita em qualquer política (SCPs, limites, identidade, recurso, sessão) — se encontrar, nega. 2) Se uma SCP se aplicar e não permitir a ação, nega. 3) Verifica os limites de permissões, as políticas de sessão e as políticas de identidade/recurso em busca de uma permissão. Qualquer lacuna resulta em uma negação implícita.

As políticas de controle de serviço (SCPs) no AWS Organizations definem o máximo de permissões de uma conta. Uma ação precisa ser permitida pela SCP e por uma política do IAM para ser bem-sucedida. As SCPs nunca concedem acesso por conta própria; elas apenas limitam ou negam. Se a SCP não permitir uma ação, nenhuma permissão do IAM poderá compensar isso.

Um limite de permissões é uma política avançada que limita o máximo de permissões de um usuário ou função específico. As permissões efetivas são a interseção entre o limite e a política de identidade. Assim como as SCPs, um limite só pode restringir; ele nunca amplia o que uma política baseada em identidade concede.

Quando uma função é assumida com uma política de sessão, essa política restringe ainda mais as permissões apenas para essa sessão. O resultado é novamente uma interseção: a sessão não pode fazer mais do que o permitido tanto pelas políticas da função quanto pela política de sessão. As políticas de sessão são usadas para reduzir o escopo no momento da assunção.

Em solicitações na mesma conta, uma permissão baseada em recurso pode conceder acesso mesmo sem uma permissão de identidade (união). Entre contas diferentes, ambas são necessárias. Além disso, uma negação explícita em qualquer uma delas sempre prevalece. A política de recurso participa do mesmo fluxo geral.

Suponha que uma política de identidade permita s3:DeleteObject, mas uma SCP negue todo s3:Delete* em produção. Resultado: negado, porque a negação explícita da SCP prevalece sobre a permissão da identidade. Invertendo a situação, se a SCP permitir, mas nenhuma política de identidade conceder a ação, ela também será negada por negação implícita. As duas camadas precisam concordar em permitir.

As questões de prova combinam SCPs, limites, políticas de identidade e de recursos e, em seguida, perguntam qual é o resultado. O método confiável é procurar primeiro qualquer negação explícita, confirmar que a SCP permite, confirmar que o limite e a sessão permitem e confirmar que existe uma permissão de identidade ou recurso. Se tudo estiver alinhado e não houver negação, a resposta é permitir.

Tenha esta lista em mente: (1) Há alguma negação explícita? Negue. (2) A SCP permite? Se não, negue. (3) O limite/a sessão permitem? Se não, negue. (4) Há uma permissão de identidade ou recurso? Se sim e não houver negação, permita; caso contrário, ocorre uma negação implícita. Aplique isso mecanicamente e até as questões com várias políticas se tornam diretas.

A avaliação do IAM começa com uma negação implícita, e uma negação explícita sempre prevalece. Para permitir uma ação: não pode haver negação explícita em nenhum lugar, a SCP precisa permiti-la, os limites de permissões e as políticas de sessão (interseções) precisam permiti-la, e deve existir uma permissão de identidade ou recurso. SCPs e limites apenas restringem; eles nunca concedem.