Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Fonctionnement de l'héritage des politiques de gestion
**Important**
Les informations de cette section ne s'appliquent ***pas*** aux politiques d'autorisation : politiques de contrôle des services (SCPs) et politiques de contrôle des ressources (RCPs). Pour plus d'informations sur le fonctionnement SCPs et le RCPs fonctionnement d'une AWS Organizations hiérarchie, reportez-vous [Évaluation du SCP](orgs_manage_policies_scps_evaluation.md) aux sections et[Évaluation du RCP](orgs_manage_policies_rcps_evaluation.md).
Vous pouvez attacher des politiques de gestion à n'importe quelle entité de votre organisation (racine, unité d'organisation [UO] ou compte) :
+ Lorsque vous attachez une stratégie de gestion à la racine de l'organisation, tous OUs les comptes de l'organisation héritent de cette politique.
+ Lorsque vous attachez une politique de gestion à une UO spécifique, les comptes sous-jacents à cette UO ou à une UO enfant héritent de cette politique.
+ Lorsque vous attachez une politique de gestion à un compte spécifique, elle affecte uniquement ce compte.
Étant donné que vous pouvez attacher des politiques de gestion à plusieurs niveaux de l'organisation, les comptes peuvent hériter de plusieurs politiques.
Les rubriques suivantes expliquent comment les politiques relatives aux parents et aux enfants sont intégrées à la politique effective d'un compte.
**Topics**
+ [Terminologie](inheritance-terminology.md)
+ [Types de politiques de gestion](syntax-inheritance.md)
+ [Opérateurs d'héritage](policy-operators.md)
+ [Exemples d'héritages](inheritance-examples.md)
# Terminologie de l'héritage
Cette rubrique utilise les termes suivants en ce qui concerne l'héritage des politiques de gestion.
**Héritage de politique**
Interaction des politiques à différents niveaux d'une organisation, allant de la racine supérieure de l'organisation, en passant par la hiérarchie des unités d'organisation (UO) jusqu'aux comptes individuels.
Vous pouvez associer des politiques à la racine de l'organisation OUs, à des comptes individuels et à n'importe quelle combinaison de ces entités d'organisation. L'héritage de politique désigne les politiques attachées à la racine de l'organisation ou à une UO. Tous les comptes membres de la racine de l'organisation ou de l'UO à laquelle une politique de gestion est attachée *héritent* de cette politique.
Par exemple, lorsque des politiques de gestion sont attachées à la racine de l'organisation, tous les comptes de l'organisation héritent de cette politique. En effet, tous les comptes d'une organisation se trouvent toujours sous la racine de l'organisation. Lorsque vous attachez une politique à une unité d'organisation spécifique, les comptes qui se trouvent directement sous cette unité d'organisation ou sous une unité d'organisation enfant héritent de cette politique. Étant donné que vous pouvez attacher des politiques à plusieurs niveaux de l'organisation, les comptes peuvent hériter de plusieurs documents de politique pour un même type de politique.
**Politiques parentes**
Politiques attachées plus haut dans l'arborescence de l'organisation que les politiques attachées à des entités plus bas dans l'arborescence.
Par exemple, si vous attachez la politique de gestion A à la racine de l'organisation, il s'agit simplement d'une politique. Si vous attachez également la politique B à une unité d'organisation sous cette racine, la politique A devient la politique parente de la politique B. La politique B est la politique enfant de la politique A. La politique A et la politique B fusionnent pour créer la politique effective pour les comptes de l'unité d'organisation.
**Politiques enfants**
Politiques attachées à un niveau plus bas dans l'arborescence de l'organisation que la politique parente.
**Politiques effectives**
Document de politique unique final qui spécifie les règles qui s'appliquent à un compte. La politique effective correspond à l'agrégation de toutes les politiques héritées par le compte, ainsi que des politiques directement attachées au compte. Pour de plus amples informations, veuillez consulter [Afficher les politiques de gestion efficaces](orgs_manage_policies_effective.md).
**Opérateurs d'héritage**
Opérateurs qui contrôlent la façon dont les politiques héritées fusionnent en une seule politique effective. Ces opérateurs sont considérés comme une fonction avancée. Les auteurs de politiques expérimentés peuvent les utiliser pour limiter les modifications qu'une politique enfant peut apporter et la manière dont les paramètres des politiques fusionnent. Pour de plus amples informations, veuillez consulter [Opérateurs d'héritage](policy-operators.md).
# Syntaxe des politiques et héritage pour les types de politiques de gestion
La manière exacte dont les politiques affectent les comptes OUs et qui en héritent dépend du type de stratégie de gestion que vous choisissez. Les types de politiques de gestion sont les suivants :
+ [Politiques déclaratives](orgs_manage_policies_declarative.md)
+ [Stratégies de sauvegarde](orgs_manage_policies_backup.md)
+ [Stratégies de balises](orgs_manage_policies_tag-policies.md)
+ [Politiques relatives aux applications de chat](orgs_manage_policies_chatbot.md)
+ [Politiques de désabonnement aux services d'IA](orgs_manage_policies_ai-opt-out.md)
+ [Politiques du Security Hub](orgs_manage_policies_security_hub.md)
+ [Politiques de Bedrock](orgs_manage_policies_bedrock.md)
+ [Politiques relatives aux inspecteurs](orgs_manage_policies_inspector.md)
+ [Mettre à niveau les politiques de déploiement](orgs_manage_policies_upgrade_rollout.md)
+ [Politiques S3](orgs_manage_policies_s3.md)
+ [AWS Shield Politiques du directeur de la sécurité réseau](orgs_manage_policies_network_security_director.md)
La syntaxe des types de politique de gestion inclut *[Opérateurs d'héritage](policy-operators.md)*les éléments suivants : ils vous permettent de spécifier avec une fine granularité quels éléments des politiques parentes sont appliqués et quels éléments peuvent être remplacés ou modifiés en cas d'héritage par un enfant OUs ou un compte.
La *politique efficace* est l'ensemble des règles héritées de la racine de l'organisation OUs et associées à celles directement associées au compte. La politique effective spécifie l'ensemble final des règles qui s'appliquent au compte. Vous pouvez afficher la politique effective pour un compte, qui inclut l'effet de tous les opérateurs d'héritage dans les politiques appliquées. Pour de plus amples informations, veuillez consulter [Afficher les politiques de gestion efficaces](orgs_manage_policies_effective.md).
# Opérateurs d'héritage
Les opérateurs d'héritage contrôlent la façon dont les politiques héritées et les politiques attachées à un compte fusionnent pour former la politique effective de ce compte. Ces opérateurs comprennent les opérateurs de définition de valeurs et les opérateurs de contrôle enfants.
Lorsque vous utilisez l'éditeur visuel de la AWS Organizations console, vous ne pouvez utiliser que l'`@@assign`opérateur. Les autres opérateurs sont considérés comme une fonction avancée. Pour utiliser les autres opérateurs, vous devez créer la politique JSON manuellement. Les auteurs de politiques expérimentés peuvent utiliser les opérateurs d'héritage pour contrôler les valeurs appliquées à la politique effective et limiter les modifications que les politiques enfants peuvent apporter.
Pour plus d'informations sur le fonctionnement de l'héritage des politiques dans une organisation, consultez[Exemples d'héritages](inheritance-examples.md).
## Opérateurs de définition de valeurs
Vous pouvez utiliser les opérateurs de définition de valeurs suivants pour contrôler la façon dont votre politique interagit avec ses politiques parentes :
+ `@@assign` : **remplace** tous les paramètres de politique hérités par les paramètres spécifiés. Si le paramètre spécifié n'est pas hérité, cet opérateur l'ajoute à la politique effective. Cet opérateur peut s'appliquer à n'importe quel paramètre de politique de n'importe quel type.
+ Pour les paramètres à valeur unique, cet opérateur remplace la valeur héritée par la valeur spécifiée.
+ Pour les paramètres à valeurs multiples (tableaux JSON), cet opérateur supprime toutes les valeurs héritées et les remplace par les valeurs spécifiées par cette politique.
+ `@@append` : **ajoute** les paramètres spécifiés (sans en supprimer) aux paramètres hérités. Si le paramètre spécifié n'est pas hérité, cet opérateur l'ajoute à la politique effective. Vous pouvez utiliser cet opérateur avec des paramètres à valeurs multiples uniquement.
+ Cet opérateur ajoute les valeurs spécifiées à toutes les valeurs du tableau hérité.
+ `@@remove` : **supprime** les paramètres hérités spécifiés de la politique effective, s'ils existent. Vous pouvez utiliser cet opérateur avec des paramètres à valeurs multiples uniquement.
+ Cet opérateur supprime uniquement les valeurs spécifiées du tableau de valeurs héritées des politiques parentes. D'autres valeurs peuvent continuer à exister dans le tableau et peuvent être héritées par les politiques enfants.
## Opérateurs de contrôle enfants
L'utilisation d'opérateurs de contrôle enfants est facultative. Vous pouvez utiliser l'opérateur `@@operators_allowed_for_child_policies` pour contrôler les opérateurs de définition de valeurs que les politiques enfants peuvent utiliser. Vous pouvez autoriser tous les opérateurs, certains opérateurs spécifiques, ou aucun opérateur. Par défaut, tous les opérateurs (`@@all`) sont autorisés.
+ `"@@operators_allowed_for_child_policies"`: `["@@all"]` — L'enfant OUs et les comptes peuvent utiliser n'importe quel opérateur dans les politiques. Par défaut, tous les opérateurs sont autorisés dans les politiques enfants.
+ `"@@operators_allowed_for_child_policies"`: `["@@assign", "@@append", "@@remove"]` — L'enfant OUs et les comptes ne peuvent utiliser que les opérateurs spécifiés dans les politiques relatives aux enfants. Vous pouvez spécifier un ou plusieurs opérateurs de définition de valeurs dans cet opérateur de contrôle enfant.
+ `"@@operators_allowed_for_child_policies"`: `["@@none"]` — L'enfant OUs et les comptes ne peuvent pas utiliser d'opérateurs dans les politiques. Vous pouvez utiliser cet opérateur pour verrouiller efficacement les valeurs définies dans une politique parente afin que les politiques enfants ne puissent pas ajouter, compléter ou supprimer ces valeurs.
**Note**
Si un opérateur de contrôle enfant hérité limite l'utilisation d'un opérateur, vous ne pouvez pas inverser cette règle dans une politique enfant. Si vous incluez des opérateurs de contrôle enfants dans une politique parente, ils limitent les opérateurs de définition de valeurs dans toutes les politiques enfants.
# Exemples d'héritages
Ces exemples illustrent le fonctionnement de l'héritage de politiques. Ils indiquent comment les politiques de balises parentes et enfants sont fusionnées en une politique de balises effective pour un compte.
Les exemples supposent que vous disposez de la structure d'organisation présentée dans le diagramme suivant.
![\[Une organisation dotée d'une racine, de deux OUs et de plusieurs comptes.\]](http://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/images/org-structure-inheritance.png)
**Topics**
+ [Exemple 1 : Autoriser les stratégies enfants à remplacer *uniquement* les valeurs de balise](#example-assign-operator)
+ [Exemple 2 : Ajouter de nouvelles valeurs aux balises héritées](#example-append-operator)
+ [Exemple 3 : Supprimer des valeurs de balises héritées](#example-remove-operator)
+ [Exemple 4 : Restreindre les modifications dans les politiques enfants](#example-restrict-child)
+ [Exemple 5 : Conflits avec les opérateurs de contrôle enfants](#multiple-same-node-operators)
+ [Exemple 6 : Conflits liés à l'ajout de valeurs au même niveau de hiérarchie](#multiple-same-node-values)
## Exemple 1 : Autoriser les stratégies enfants à remplacer *uniquement* les valeurs de balise
La politique de balises suivante définit la clé de balise `CostCenter` et deux valeurs admises : `Development` et `Support`. Si vous l'attachez à la racine de l'organisation, la politique de balises s'applique à tous les comptes de l'organisation.
**Politique A : politique d'identifications attachée à la racine de l'organisation**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Supposons que vous souhaitiez que les OU1 utilisateurs utilisent une valeur de balise différente pour une clé et que vous souhaitiez appliquer la politique de balise pour des types de ressources spécifiques. Étant donné que la politique A ne spécifie pas les opérateurs de contrôle enfants qui sont autorisés, tous les opérateurs sont autorisés. Vous pouvez utiliser l'`@@assign`opérateur et créer une politique de balises telle que la suivante à laquelle vous pouvez vous associer OU1.
**Stratégie B — politique des OU1 balises**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Sandbox"
]
},
"enforced_for": {
"@@assign": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
La spécification de l'opérateur `@@assign` pour la balise entraîne le résultat suivant lorsque la politique A et la politique B fusionnent pour constituer la *politique de balises effective* d'un compte :
+ La politique B remplace les deux valeurs de balise spécifiées dans la politique parente (la politique A). Le résultat est que `Sandbox` est la seule valeur conforme pour la clé de balise `CostCenter`.
+ L'ajout de `enforced_for` indique que la balise `CostCenter` *doit* être la valeur de balise spécifiée sur toutes les ressources Amazon Redshift et les tables Amazon DynamoDB.
Comme le montre le diagramme, OU1 inclut deux comptes : 111111111111 et 222222222222.
**Stratégie de balise effective obtenue pour les comptes 111111111111 et 222222222222**
**Note**
Vous ne pouvez pas utiliser directement le contenu d'une politique effective affichée comme contenu d'une nouvelle politique. La syntaxe n'inclut pas les opérateurs nécessaires pour contrôler la fusion avec d'autres politiques enfants et parentes. L'affichage d'une politique effective n'a pour but que de comprendre les résultats de la fusion.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Sandbox"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Exemple 2 : Ajouter de nouvelles valeurs aux balises héritées
Dans certains cas, vous souhaitez que tous les comptes de votre organisation spécifient une clé de balise avec une courte liste de valeurs admises. Pour les comptes d'une unité d'organisation, vous souhaiterez peut-être autoriser une valeur supplémentaire que seuls ces comptes peuvent spécifier lors de la création de ressources. Cet exemple spécifie la procédure à suivre à l'aide de l'opérateur `@@append`. L'opérateur `@@append` est une fonction avancée.
Comme pour l'exemple 1, cet exemple commence par la politique A comme politique de balises attachée à la racine de l'organisation.
**Politique A : politique d'identifications attachée à la racine de l'organisation**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Pour cet exemple, attachez la politique C à OU2. La différence dans cet exemple est que l'utilisation de l'opérateur `@@append` dans la politique C *ajoute* des valeurs à la liste des valeurs admises ainsi que la règle `enforced_for` plutôt que d'écraser la liste.
**Stratégie C — politique de OU2 balises pour l'ajout de valeurs**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@append": [
"Marketing"
]
},
"enforced_for": {
"@@append": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
L'association de la politique C à OU2 a les effets suivants lorsque la politique A et la politique C fusionnent pour former la politique de balises effective pour un compte :
+ Étant donné que la politique C inclut l'opérateur `@@append`, elle permet d'*ajouter* des valeurs à la liste des valeurs de balise admises spécifiées dans la politique A (plutôt que d'écraser la liste).
+ Comme dans la politique B, l'ajout de `enforced_for` indique que la balise `CostCenter` doit être utilisée comme valeur de balise spécifiée sur toutes les ressources Amazon Redshift et les tables Amazon DynamoDB. L'écrasement (`@@assign`) et l'ajout (`@@append`) ont le même effet si la politique parente n'inclut pas d'opérateur de contrôle enfant qui limite les valeurs qu'une politique enfant peut spécifier.
Comme le montre le schéma, OU2 inclut un compte : 999999999999. La politique A et la politique C fusionnent pour créer la politique de balises effective du compte 999999999999.
**Stratégie de balise effective pour le compte 999999999999**
**Note**
Vous ne pouvez pas utiliser directement le contenu d'une politique effective affichée comme contenu d'une nouvelle politique. La syntaxe n'inclut pas les opérateurs nécessaires pour contrôler la fusion avec d'autres politiques enfants et parentes. L'affichage d'une politique effective n'a pour but que de comprendre les résultats de la fusion.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Development",
"Support",
"Marketing"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Exemple 3 : Supprimer des valeurs de balises héritées
Dans certains cas, la politique de balises attachée à l'organisation peut définir plus de valeurs de balise que vous ne souhaitez qu'un compte en utilise. Cet exemple décrit comment réviser une politique de balise à l'aide de l'opérateur `@@remove`. `@@remove` est une fonction avancée.
Comme pour les autres exemples, cet exemple commence par la politique A comme politique de balises attachée à la racine de l'organisation.
**Politique A : politique d'identifications attachée à la racine de l'organisation**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Pour cet exemple, attachez la politique D au compte 999999999999.
**Politique D : politique d'identifications attachée au compte 999999999999 pour supprimer des valeurs**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@remove": [
"Development",
"Marketing"
],
"enforced_for": {
"@@remove": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
}
```
L'attachement de la politique D au compte 999999999999 a les effets suivants lorsque la politique A, la politique C et la politique D fusionnent pour constituer la politique de balises effective :
+ En supposant que vous ayez suivi tous les exemples précédents, les politiques B, C et C sont des politiques secondaires de A. La politique B est uniquement attachée à OU1, elle n'a donc aucun effet sur le compte 9999999999999.
+ Pour le compte 9999999999999, la seule valeur admise pour la clé de balise `CostCenter` est `Support`.
+ La conformité n'est pas appliquée pour la clé de balise `CostCenter`.
**Nouvelle stratégie de balise effective pour le compte 999999999999**
**Note**
Vous ne pouvez pas utiliser directement le contenu d'une politique effective affichée comme contenu d'une nouvelle politique. La syntaxe n'inclut pas les opérateurs nécessaires pour contrôler la fusion avec d'autres politiques enfants et parentes. L'affichage d'une politique effective n'a pour but que de comprendre les résultats de la fusion.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Support"
]
}
}
}
```
Si vous ajoutez ultérieurement d'autres comptes OU2, leurs politiques en matière de balises en vigueur seront différentes de celles du compte 999999999999. En effet, la politique D plus restrictive n'est attachée qu'au niveau du compte et pas à l'unité d'organisation.
## Exemple 4 : Restreindre les modifications dans les politiques enfants
Vous souhaiterez peut-être, dans certains cas, restreindre les modifications apportées dans les politiques enfants. Cet exemple décrit la procédure à suivre à l'aide d'opérateurs de contrôle enfants.
Cet exemple commence par une nouvelle politique de balises attachée à la racine de l'organisation et suppose que les politiques de balises ne sont pas encore attachées aux entités d'organisation.
**Politique E : politique de balises attachée à la racine de l'organisation pour restreindre les modifications apportées dans les politiques enfants**
```
{
"tags": {
"project": {
"tag_key": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "Project"
},
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance",
"Escalations"
]
}
}
}
}
```
Lorsque vous attachez la politique E à la racine de l'organisation, elle empêche les politiques enfants de modifier la clé de balise `Project`. Les politiques enfants peuvent cependant remplacer ou ajouter des valeurs de balise.
Supposons que vous attachez ensuite la politique F suivante à une unité d'organisation.
**Politique F : politique d'identifications attachée à une unité organisationnelle**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": [
"Escalations - research"
]
}
}
}
}
```
La fusion de la politique E et de la politique F a les effets suivants sur les comptes de l'unité d'organisation :
+ La politique F est une politique enfant de la politique E.
+ La politique F tente de modifier le traitement de la casse, mais elle ne le peut pas. En effet, la politique E inclut l'opérateur `"@@operators_allowed_for_child_policies": ["@@none"]` pour la clé de balise.
+ La politique F peut cependant ajouter des valeurs de balises pour la clé. En effet, la politique E inclut `"@@operators_allowed_for_child_policies": ["@@append"]` comme valeur de balise.
**Stratégie effective pour les comptes de l'unité organisationnelle**
**Note**
Vous ne pouvez pas utiliser directement le contenu d'une politique effective affichée comme contenu d'une nouvelle politique. La syntaxe n'inclut pas les opérateurs nécessaires pour contrôler la fusion avec d'autres politiques enfants et parentes. L'affichage d'une politique effective n'a pour but que de comprendre les résultats de la fusion.
```
{
"tags": {
"project": {
"tag_key": "Project",
"tag_value": [
"Maintenance",
"Escalations",
"Escalations - research"
]
}
}
}
```
## Exemple 5 : Conflits avec les opérateurs de contrôle enfants
Des opérateurs de contrôle enfants peuvent figurer dans des politiques de balises attachées au même niveau dans la hiérarchie de l'organisation. Dans ce cas, l'intersection des opérateurs autorisés est utilisée lorsque les politiques fusionnent pour constituer la politique effective des comptes.
Supposons que la politique G et la politique H sont attachées à la racine de l'organisation.
**Politique G : politique d'identifications 1 attachée à la racine de l'organisation**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance"
]
}
}
}
}
```
**Politique H : politique d'identifications 2 attachée à la racine de l'organisation**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
}
}
}
}
```
Dans cet exemple, une politique attachée à la racine de l'organisation définit que les valeurs de la clé de balise peuvent uniquement être complétées. L'autre politique attachée à la racine de l'organisation permet aux politiques enfants d'ajouter et de supprimer des valeurs. L'intersection de ces deux autorisations est utilisée pour les politiques enfants. Le résultat est que les politiques enfants peuvent ajouter des valeurs, mais pas les supprimer. Par conséquent, la politique enfant peut ajouter une valeur à la liste des valeurs de balise, mais ne peut pas supprimer la valeur `Maintenance`.
## Exemple 6 : Conflits liés à l'ajout de valeurs au même niveau de hiérarchie
Vous pouvez attacher plusieurs politiques de balises à chaque entité d'organisation. Lorsque vous effectuez cette opération, les politiques de balises attachées à la même entité d'organisation peuvent inclure des informations conflictuelles. Ces politiques sont évaluées en fonction de l'ordre dans lequel elles ont été attachées à l'entité d'organisation. Pour changer l'ordre d'évaluation des politiques, vous pouvez détacher une politique, puis la rattacher.
Supposons que la politique J est attachée à la racine de l'organisation en premier, puis que la politique K est attachée à la racine de l'organisation.
**PolitiqueJ : première politique d'identifications attachée à la racine de l'organisation**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": ["Maintenance"]
}
}
}
}
```
**Politique K : deuxième politique d'identifications attachée à la racine de l'organisation**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "project"
}
}
}
}
```
Dans cet exemple, la clé de balise `PROJECT` est utilisée dans la politique de balises effective car la politique qui l'a définie a été attachée à la racine de l'organisation en premier.
**Politique JK : politique d'identifications effective du compte**
La politique effective du compte est la suivante.
**Note**
Vous ne pouvez pas utiliser directement le contenu d'une politique effective affichée comme contenu d'une nouvelle politique. La syntaxe n'inclut pas les opérateurs nécessaires pour contrôler la fusion avec d'autres politiques enfants et parentes. L'affichage d'une politique effective n'a pour but que de comprendre les résultats de la fusion.
```
{
"tags": {
"project": {
"tag_key": "PROJECT",
"tag_value": [
"Maintenance"
]
}
}
}
```