As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Exemplos de herança
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 conta raiz OUs, duas e várias contas.\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/org-structure-inheritance.png)
**Topics**
+ [Exemplo 1: permitir que políticas filho substituam *apenas* valores de tag](#example-assign-operator)
+ [Exemplo 2: anexar novos valores a tags herdadas](#example-append-operator)
+ [Exemplo 3: remover valores de tags herdadas](#example-remove-operator)
+ [Exemplo 4: restringir alterações às políticas filho](#example-restrict-child)
+ [Exemplo 5: conflitos com operadores de controle filho](#multiple-same-node-operators)
+ [Exemplo 6: conflitos com a anexação de valores no mesmo nível de hierarquia](#multiple-same-node-values)
## 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"
]
}
}
}
}
```
Suponha que você queira que os usuários usem OU1 um valor de tag diferente para uma chave e imponha a política de tags para 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 `@@assign` operador e criar uma política de tag como a seguinte para anexar OU1.
**Política B — política de OU1 tags**
```
{
"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.
Conforme mostrado no diagrama, OU1 inclui duas contas: 111111111111 e 2222222222.
**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"
]
}
}
}
}
```
Neste exemplo, anexe a política C OU2 a. 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 OU2 tags para anexar valores**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@append": [
"Marketing"
]
},
"enforced_for": {
"@@append": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
Anexar a política C à OU2 tem os seguintes efeitos quando a política A e a política C se fundem 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.
Conforme mostrado no diagrama, OU2 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ê tenha executado todos os exemplos anteriores, as políticas B, C e C são políticas secundárias de A. A política B está apenas vinculada OU1, 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 você adicionar mais contas posteriormente OU2, suas políticas de tags 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"
]
}
}
}
```