Sintaxe de política e herança para tipos de política de gerenciamento - AWS Organizations

Sintaxe de política e herança para tipos de política de gerenciamento

Importante

As informações nesta seção não se aplicam às SCPs. Consulte a seção anterior Herança para políticas de controle de serviço.

Os tipos de políticas de gerenciamento incluem:

A herança se comporta de forma diferente para os tipos de política de gerenciamento em comparação às políticas de controle de serviço. A sintaxe de tipos de política de gerenciamento inclui operadores de herança, que permitem especificar com granularidade fina quais elementos das políticas superiores são aplicados e quais elementos podem ser substituídos ou modificados por UOs e contas subordinadas.

A política efetiva é o conjunto de regras que são herdadas da raiz da organização e das UOs, juntamente com as diretamente anexadas à conta. A política em vigor especifica as regras que se aplicam à conta. É possível visualizar a política efetiva para uma conta que inclui o efeito de todos os operadores de herança nas políticas aplicadas. Para mais informações, consulte Visualizar políticas de tag efetivas.

Esta seção explica como as políticas pai e as políticas filho são processadas na política efetiva de uma conta.

Terminologia

Este tópico usa os seguintes termos ao discutir herança de política.

Herança de política

A interação de políticas em diferentes níveis de uma organização se move da raiz de nível superior da organização passando pela hierarquia de unidade organizacional (UO) para contas individuais.

Você pode anexar políticas à raiz da organização, UOs, contas individuais e a qualquer combinação dessas entidades da organização. Herança de política refere-se a políticas anexadas à raiz da organização ou a uma UO. Todas as contas que são membros da raiz da organização ou UO em que uma política está anexada herdam essa política.

Por exemplo, quando as políticas são anexadas à raiz da organização, todas as contas na organização herdam essa política. Isso ocorre porque todas as contas em uma organização estão sempre sob a raiz da organização. Quando você anexa uma política a uma UO específica, as contas que estão diretamente sob essa UO ou qualquer UO filho herdam essa política. Como você pode anexar políticas a vários níveis na organização, as contas podem herdar vários documentos de política para um único tipo de política.

Políticas pai

As políticas anexadas em um nível superior na árvore organizacional em relação à políticas anexadas a entidades inferiores na árvore.

Por exemplo, se você anexar a política A à raiz da organização, ela será apenas uma política. Se também anexar a política B a uma UO nessa raiz, a política A será a política pai da política B. A política B será a política filho da política A. As políticas A e B serão mescladas para criar a política de tag efetiva para contas na UO.

Políticas filho

As políticas anexadas em um nível inferior na árvore organizacional em relação à política pai.

Políticas efetivas

Um documento de política único e definitivo que especifica as regras de atribuição que se aplicam a uma conta. A política efetiva é a agregação de todas as políticas herdadas pela conta, além de qualquer política diretamente anexada à conta. Por exemplo, as políticas de tag permitem que você exiba a política de tag efetiva que se aplica a qualquer uma de suas contas. Para mais informações, consulte Visualizar políticas de tag efetivas.

Operadores de herança

Operadores que controlam como as políticas herdadas se mesclam em uma única política efetiva. Esses operadores são considerados um recurso avançado. Os autores experientes de política podem usá-los para limitar as alterações que uma política filho pode fazer e como as configurações nas políticas são mescladas.

Operadores de herança

Operadores de herança controlam como as políticas herdadas e as políticas de conta se fundem na política efetiva da conta. Esses operadores incluem operadores de definição de valor e operadores de controle filho.

Quando você usa o editor visual no console do AWS Organizations, você pode usar apenas o operador @@assign. Outros operadores são considerados um recurso avançado. Para usar os outros operadores, você deve criar manualmente a política JSON. Os autores experientes de política podem usar os operadores de herança para controlar quais valores são aplicados à política efetiva e limitar as alterações que as políticas filho podem fazer.

Operadores de definição de valor

Você pode usar os seguintes operadores de definição de valor para controlar como a política interage com suas políticas pai:

  • @@assignSubstitui quaisquer configurações de política herdadas pelas configurações especificadas. Se a configuração especificada não for herdada, esse operador a adicionará à política efetiva. Esse operador pode se aplicar a qualquer configuração de política de qualquer tipo.

    • Para configurações de valor único, esse operador substitui o valor herdado pelo valor especificado.

    • Para configurações de valores múltiplos (matrizes JSON), esse operador remove quaisquer valores herdados e os substitui pelos valores especificados por esta política.

  • @@appendAdiciona as configurações especificadas às herdadas (sem remover nenhuma). Se a configuração especificada não for herdada, esse operador a adicionará à política efetiva. Você pode usar esse operador apenas com configurações de vários valores.

    • Este operador adiciona os valores especificados a quaisquer valores na matriz herdada.

  • @@removeRemove as configurações herdadas especificadas da política em vigor, se houver. Você pode usar esse operador apenas com configurações de vários valores.

    • Esse operador remove somente os valores especificados da matriz de valores herdados das políticas pai. Outros valores podem continuar a existir na matriz e podem ser herdados por políticas filho.

Operadores de controle filho

O uso de operadores de controle filho é opcional. Você pode usar o operador @@operators_allowed_for_child_policies para controlar quais operadores de definição de valor as políticas filho podem usar. Você pode permitir todos os operadores, alguns operadores específicos ou nenhum operador. Por padrão, todos os operadores (@@all) são permitidos.

  • "@@operators_allowed_for_child_policies":["@@all"] – UOs e contas subordinadas podem usar qualquer operador em políticas. Por padrão, todos os operadores são permitidos em políticas filho.

  • "@@operators_allowed_for_child_policies":["@@assign", "@@append", "@@remove"] – Contas e UOs subordinadas podem usar somente os operadores especificados em políticas subordinadas. Você pode especificar um ou mais operadores de definição de valor neste operador de controle filho.

  • "@@operators_allowed_for_child_policies":["@@none"] – UOs e contas subordinadas não podem usar operadores em políticas. Você pode usar este operador para bloquear efetivamente valores definidos em uma política pai de modo que as políticas filho não possam adicionar, acrescentar ou remover tais valores.

nota

Se um operador de controle filho herdado limitar o uso de um operador, você não poderá reverter essa regra em uma política filho. Se você incluir operadores de controle filho em uma política pai, eles limitarão os operadores de definição de valor em todas as políticas filho.

Exemplos de herança de política

Estes exemplos mostram como a herança de política funciona ao exibir como as políticas de tag pai e filho são mescladas em uma política de tag efetiva para uma conta.

Os exemplos assumem que você tem a estrutura de organização exibida no diagrama a seguir.


                Uma organização com uma raiz, duas UOs e várias contas.

Exemplo 1: permitir que políticas filho substituam apenas valores de tag

A política de tags a seguir define a chave de tag CostCenter e dois valores aceitáveis, Development e Support. Se você anexá-la à raiz da organização, a política de tag estará em vigor para todas as contas na organização.

Política A — Política de tag da raiz da organização

{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }

Vamos supor que você deseje que os usuários na UO1 usem um valor de tag diferente para uma chave. Além disso, você deseja aplicar a política de tag a tipos de recursos específicos. Como a política A não especifica quais operadores de controle filho são permitidos, todos os operadores são permitidos. Você pode usar o operador @@assign e criar uma política de tag como a seguinte para anexar à UO1.

Política B — Política de tag da UO1

{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Sandbox" ] }, "enforced_for": { "@@assign": [ "redshift:*", "dynamodb:table" ] } } } }

Isto é o que acontece ao especificar o operador @@assign para a tag quando a política A e a política B são mescladas para formar a política de tag efetiva para uma conta:

  • A política B substitui os dois valores de tag que foram especificados na política pai, a política A. O resultado é que Sandbox é apenas o valor compatível para a chave de tag CostCenter.

  • A adição de enforced_for especifica que a tag CostCenter deve ser o valor de tag especificado em todos os recursos do Amazon RedShift e tabelas do Amazon DynamoDB.

Como mostrado no diagrama, a UO1 inclui duas contas: 111111111111 e 222222222222.

Política de tags efetiva resultante para contas 111111111111 e 222222222222

nota

Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.

{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Sandbox" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } }

Exemplo 2: anexar novos valores a tags herdadas

Pode haver casos em que você deseja que todas as contas da organização especifiquem uma chave de tag com uma pequena lista de valores aceitáveis. Para contas em uma UO, convém permitir um valor adicional que somente essas contas possam especificar ao criar recursos. Este exemplo especifica como fazer isso usando o operador @@append. O operador @@append é um recurso avançado.

Como o exemplo 1, este exemplo começa com a política A para a política de tag da raiz da organização.

Política A — Política de tag da raiz da organização

{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }

Para este exemplo, anexe a política C à UO2. A diferença neste exemplo é que o uso do operador @@append na política C adiciona, em vez de substituir, a lista de valores aceitáveis e a regra enforced_for.

Política C — Política de tag da UO2 para valores anexos

{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@append": [ "Marketing" ] }, "enforced_for": { "@@append": [ "redshift:*", "dynamodb:table" ] } } } }

Anexar a política C à UO2 tem os seguintes efeitos quando a política A e a política C são mescladas para formar a política de tags efetiva para uma conta:

  • Como a política C inclui o operador @@append, ela permite adicionar, e não substituir, a lista de valores de tag aceitáveis especificados na Política A.

  • Como na política B, a adição de enforced_for especifica que a tag CostCenter deve ser usada como valor de tag especificado em todos os recursos do Amazon RedShift e tabelas do Amazon DynamoDB. Substituir (@@assign) e adicionar (@@append) terão o mesmo efeito se a política pai não incluir um operador de controle filho que restrinja o que uma política filho pode especificar.

Como mostrado no diagrama, a UO2 inclui uma conta: 999999999999. A política A e a política C são mescladas para criar a política de tag efetiva para a conta 999999999999.

Política de tag efetiva para a conta 999999999999

nota

Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.

{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Development", "Support", "Marketing" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } }

Exemplo 3: remover valores de tags herdadas

Pode haver casos em que a política de tag anexada à organização defina mais valores de tag do que aqueles você deseja que uma conta use. Este exemplo explica como revisar uma política de tag usando o operador @@remove. O @@remove é um recurso avançado.

Como os outros exemplos, este exemplo começa com a política A para a política de tag da raiz da organização.

Política A — Política de tag da raiz da organização

{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }

Para este exemplo, anexe a política D à conta 999999999999.

Política D — Política de tag da conta 999999999999 para remoção de valores

{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@remove": [ "Development", "Marketing" ], "enforced_for": { "@@remove": [ "redshift:*", "dynamodb:table" ] } } } } }

A anexação da política D à conta 999999999999 tem os efeitos a seguir quando as políticas A, C e D se mesclam para formar a política de tags efetiva:

  • Supondo que você executou todos os exemplos anteriores, as políticas B, C e C são políticas filho da A. A política B é anexada somente à UO1, portanto não tem efeito na conta 9999999999999.

  • Para a conta 9999999999999, o único valor aceitável para a chave de tag CostCenter é Support.

  • A conformidade não é imposta para a chave de tag CostCenter.

Nova política de tag eficaz para a conta 999999999999

nota

Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.

{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Support" ] } } }

Se posteriormente você adicionar mais contas à UO2, as políticas de tag efetivas serão diferentes das da conta 999999999999. Isso ocorre porque a política mais restritiva D é anexada apenas no nível da conta, e não à UO.

Exemplo 4: restringir alterações às políticas filho

Pode haver casos em que você queira restringir as alterações nas políticas filho. Este exemplo explica como fazer isso usando operadores de controle filho.

Este exemplo começa com uma nova política de tag da raiz da organização e assume que as políticas de tag ainda não estão anexadas a entidades da organização.

Política E: política de tag da raiz da organização para restringir alterações em políticas subordinadas

{ "tags": { "project": { "tag_key": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "Project" }, "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance", "Escalations" ] } } } }

Quando você anexa a política E à raiz da organização, ela impede que as políticas filho alterem a chave de tag Project. No entanto, as políticas filho podem substituir ou anexar valores de tag.

Vamos supor que depois você anexe a seguinte política F a uma UO.

Política F — Política de tag da UO

{ "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": [ "Escalations - research" ] } } } }

Mesclar as políticas E e F tem os seguintes efeitos nas contas da UO:

  • A política F é uma política filho da Política E.

  • A política F tenta mudar o tratamento do caso, apesar de não ser possível. Isso ocorre porque a política E inclui o operador "@@operators_allowed_for_child_policies": ["@@none"] para a chave de tag.

  • No entanto, a política F pode anexar valores de tag para a chave. Isso ocorre porque a política E inclui "@@operators_allowed_for_child_policies": ["@@append"] para o valor da tag.

Política efetiva para contas na UO

nota

Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.

{ "tags": { "project": { "tag_key": "Project", "tag_value": [ "Maintenance", "Escalations", "Escalations - research" ] } } }

Exemplo 5: conflitos com operadores de controle filho

Os operadores de controle filho podem existir em políticas de tag anexadas no mesmo nível na hierarquia da organização. Quando isso acontece, a interseção dos operadores permitidos é usada quando as políticas se mesclam para formar a política efetiva das contas.

Suponha que as políticas G e H estão anexadas à raiz da organização.

Política G — Política de tag da raiz da organização 1

{ "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance" ] } } } }

Política H — Política de tag da raiz da organização 2

{ "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append", "@@remove"] } } } }

Neste exemplo, uma política na raiz da organização define que os valores da chave de tag só podem ser anexados. A outra política anexada à raiz da organização permite que as políticas filho anexem e removam valores. A interseção dessas duas permissões é usada para políticas filho. O resultado é que as políticas filho podem anexar valores, mas não remover valores. Portanto, a política filho pode anexar um valor à lista de valores de tag, mas não pode remover o valor Maintenance.

Exemplo 6: conflitos com a anexação de valores no mesmo nível de hierarquia

Você pode anexar várias políticas de tag a cada entidade da organização. Quando você fizer isso, as políticas de tag anexadas à mesma entidade da organização podem incluir informações conflitantes. As políticas são avaliadas com base na ordem em que foram anexadas à entidade da organização. Para alterar qual política é avaliada primeiro, você pode desanexar uma política e reanexá-la.

Suponha que a política J tenha sido a primeira a ser anexada à raiz da organização, e a política K tenha sido a segunda.

Política J — Primeira política de tag anexada à raiz da organização

{ "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": ["Maintenance"] } } } }

Política K — Segunda política de tag anexada à raiz da organização

{ "tags": { "project": { "tag_key": { "@@assign": "project" } } } }

Neste exemplo, a chave de tag PROJECT é usada na política de tag efetiva porque a política que a definiu foi anexada à raiz da organização primeiro.

Política JK — Política de tag em vigor para a conta

A política efetiva para a conta é a seguinte.

nota

Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.

{ "tags": { "project": { "tag_key": "PROJECT", "tag_value": [ "Maintenance" ] } } }