Herança para políticas de controle de serviço

Importante

As informações nesta seção não se aplicam a tipos de política de gerenciamento, incluindo políticas de exclusão dos serviços de IA, políticas de backup ou políticas de tag. Consulte a próxima seção Sintaxe de política e herança para tipos de política de gerenciamento.

Políticas de controle de serviço (SCPs)

A herança para políticas de controle de serviço se comporta como um filtro através do qual as permissões fluem para todas as partes da árvore abaixo. Imagine que a estrutura de árvore invertida da organização é feita de ramos que se conectam da raiz a todas as UOs e terminam nas contas. Todas as permissões da AWS fluem para a raiz da árvore. Essas permissões devem, então, passar pelas SCPs anexadas à raiz, às UOs e à conta para chegar ao principal (uma função ou usuário do IAM) que faz uma solicitação. Cada SCP pode filtrar as permissões que passam para os níveis abaixo dela. Se uma ação for bloqueada por uma instrução Deny, todas as UOs e contas afetadas por essa SCP terão acesso negado a essa ação. Uma SCP em nível inferior não pode adicionar uma permissão depois de ser bloqueada por uma SCP em nível mais elevado. As SCPs só podem filtrar, nunca adicionar, permissões.

As SCPs não oferecem suporte a operadores de herança que alteram a forma como os elementos da política são herdados por UOs e contas filhas.

A seguinte ilustração mostra como funcionam as SCPs.

Nesta ilustração, suponha que o oval à esquerda representa uma SCP anexada à raiz da organização. Ela permite as permissões A, B e C. A raiz contém uma unidade organizacional (UO) à qual está anexada uma segunda SCP representada pela oval à direita. Essa segunda SCP permite C, D e E. Como a SCP anexada à raiz não permite D nem E, nenhuma UO ou conta da organização pode usá-las. Mesmo que a SCP anexada à UO permita explicitamente D e E, elas acabam sendo bloqueados porque são bloqueadas pela raiz da organização. Além disso, como a SCP da UO não permite A nem B, essas permissões são bloqueadas para a UO e todas as suas UOs ou contas subordinadas. No entanto, outras UOs que existam na raiz ainda podem permitir A e B.

À medida que você percorre a hierarquia de UOs para a conta, o processo no parágrafo anterior é repetido em cada UO e, finalmente, com a conta. Em cada nível, o resultado da avaliação no nível superior torna-se a política à esquerda do diagrama e é comparado com as SCPs anexadas à UO subordinada.

Por exemplo, se você se mover para baixo na árvore até uma UO subordinada chamada X, imagine que o oval à esquerda represente as permissões herdadas em vigor, permitidas por todas as SCPs acima da UO X na hierarquia. O oval à direita representa a SCP anexada a uma UO ou a uma Conta da AWS contida na UO X. Novamente, a interseção dessas permissões é o que está disponível para ser usado a entidade à direita. Se essa entidade for uma Conta da AWS, a interseção será o conjunto de permissões que podem ser concedidas a usuários e funções nessa conta. Se a entidade for uma UO, a interseção é o conjunto de permissões que podem ser herdadas pelas entidades subordinadas dessa UO. Repita o processo para cada nível descendo na hierarquia da UO até alcançar a conta em si. Essa política final em vigor é a lista de permissões que foram permitidas por cada SCP acima dessa conta e anexadas a ela.

Isto significa que, para permitir uma API de serviço da AWS no nível de conta-membro, você deve permitir essa API em cada nível entre a conta-membro e a raiz da sua organização. Você deve anexar SCPs a todos os níveis, desde a raiz da sua organização até a conta-membro que permite a API de serviço da AWS (como ec2:RunInstances). Você pode usar uma das seguintes estratégias para fazer isso:

• A estratégia de lista de negação faz uso da SCP FullAWSAccess que é anexada por padrão a cada UO e conta. Essa SCP substitui a negação implícita padrão e permite explicitamente que todas as permissões fluam da raiz para cada conta, a menos que você negue explicitamente uma permissão com uma SCP adicional que você criar e anexar à UO ou conta apropriada. Esta estratégia funciona porque um deny explícito em uma política sempre substitui qualquer tipo de allow. Nenhuma conta abaixo do nível da UO com a política de negação pode usar a API negada e não há como readicionar a permissão em uma posição mais baixa na hierarquia. Para obter mais informações, consulte . Usar SCPs como uma lista de negações.

• Uma estratégia de lista de negação exige que você remova a SCP FullAWSAccess que está anexada por padrão a cada UO e conta. Isso significa que nenhuma API é permitida em nenhum lugar, a menos que você a permita explicitamente. Para permitir que uma API de serviço opere em uma Conta da AWS, você deve criar suas próprias SCPs e anexá-las à conta e a cada UO acima, até e incluindo a raiz. Cada SCP na hierarquia, começando pela raiz, deve permitir explicitamente as APIs que você deseja que sejam utilizáveis nas UOs e nas contas abaixo dela. Esta estratégia funciona porque um allow explícito em uma SCP substitui um deny implícito. Para obter mais informações, consulte . Usar SCPs como uma lista de permissões.

Para analisar como as políticas são avaliadas em termos de permissões e negações implícitas em comparação com negações explícitas, e o quê substitui o quê, consulte Determinação de se uma solicitação será permitida ou negada em uma conta.

Os usuários e funções ainda precisam receber permissões usando as políticas de permissão do AWS Identity and Access Management (IAM) anexadas a eles ou aos grupos. As SCPs determinam apenas quais permissões estão disponíveis para serem concedidas por tais políticas. O usuário não pode realizar nenhum ação não permitida pelas SCPs aplicáveis. As ações permitidas pelas SCPs podem ser usadas se forem concedidas ao usuário ou função por uma ou mais políticas de permissão do IAM.

Quando você anexa SCPs à raiz da organização, às UOs ou diretamente às contas, todas as políticas que afetam uma determinada conta são avaliadas em conjunto usando as mesmas regras que controlam as políticas de permissões do IAM:

• Os usuários e as funções nas contas afetadas não podem executar nenhuma ação que esteja listada na instrução Deny da SCP. Uma instrução Deny explícita substitui qualquer Allow que possa ser concedida por outras SCPs.

• Qualquer ação que tiver um Allow explícita em uma SCP (como a SCP padrão "*" ou por qualquer outra SCP que chama um serviço ou ação específicos) poderá ser delegada a usuários e funções nas contas afetadas.

• Qualquer ação que não for explicitamente permitida por uma SCP será implicitamente negada e não poderá ser delegada a usuários ou funções nas contas afetadas.

Por padrão, uma SCP chamada FullAWSAccess é anexada a cada raiz, UO e conta. Essa SCP padrão permite todas as ações e todos os serviços. Portanto, em uma nova organização, até que você comece a criar ou manipular as SCPs, todas as permissões do IAM existentes continuarão a operar como sempre. Assim que uma SCP nova ou modificada é aplicada à raiz da organização ou a uma UO que contenha uma conta, as permissões que seus usuários têm nessa conta são filtradas pela SCP. As permissões que funcionavam podem agora ser negadas se não forem permitidas pela SCP em todos os níveis da hierarquia até a conta especificada.

Se você desativar o tipo de política SCP na raiz da organização, todas as SCPs serão automaticamente desanexadas de todas as entidades na raiz da organização. Se você ativar novamente SCPs nessa raiz, todos os anexos originais serão perdidos e todas as entidades serão redefinidas para serem anexadas somente à SCP FullAWSAccess padrão.

Para obter mais detalhes sobre a sintaxe das SCPs, consulte Sintaxe de SCP.

Você pode ver uma lista de todas as políticas aplicadas a uma conta e a origem dessa política. Para fazer isso, escolha uma conta no console do AWS Organizations. Na página de detalhes da conta, escolha Policies (Políticas) e Service Control Policies (Políticas de controle de serviço) no painel de detalhes à direita. A mesma política pode ser aplicada à conta várias vezes pois ela pode ser anexada a qualquer um ou a todos os contêineres pai da conta. A política efetiva que se aplica à conta é a interseção de permissões concedidas de todas as políticas aplicáveis.

Para obter mais informações sobre como usar as SCPs, consulte Políticas de controle de serviço (SCPs).