View a markdown version of this page

Modèles de politique  - AWS Identity and Access Management

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.

Modèles de politique 

Les modèles de politique sont une nouvelle structure IAM conçue pour définir les autorisations temporaires que les partenaires demandent sur les comptes des clients. À l'instar des politiques IAM classiques, elles définissent les autorisations à l'aide d'instructions comportant des éléments Effect, Action, Resource et Condition. La principale différence réside dans le fait que les modèles de politique incluent des paramètres (tels que @ {bucketName}) qui sont remplacés par des valeurs réelles lorsque vous créez une demande de délégation.

Comment fonctionnent les modèles de politiques

Dans le cadre du processus d'intégration, vous enregistrez vos modèles de politiques auprès AWS de. AWS attribue à chaque modèle un ARN unique auquel vous faites référence lors de la création de demandes de délégation.

Lorsque vous créez une demande de délégation, vous spécifiez :

  • Le modèle de politique (ARN)

  • Valeurs de paramètres à substituer dans le modèle

AWS combine le modèle avec les valeurs de vos paramètres pour générer une politique IAM standard. Les clients examinent cette politique de rendu final lorsqu'ils approuvent votre demande de délégation, afin de savoir exactement quelles autorisations seront accordées.

Note

La politique de rendu final a une limite de taille maximale de 2 048 caractères.

Voici un exemple simple illustrant le fonctionnement de la substitution de modèles.

Modèle de politique :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] }

Paramètres fournis dans la demande de délégation :

{ "Name": "bucketName", "Values": ["customer-data-bucket"], "Type": "String" }

Politique de rendu final (ce que voient les clients) :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::customer-data-bucket/*" } ] }

Syntaxe du modèle

Les modèles de politique utilisent deux fonctionnalités clés pour apporter de la flexibilité : la substitution de paramètres et les instructions conditionnelles. La substitution de paramètres vous permet de définir des espaces réservés dans votre modèle qui sont remplacés par des valeurs réelles lors de la création d'une demande de délégation. Les instructions conditionnelles vous permettent d'inclure ou d'exclure des déclarations de politique complètes en fonction des valeurs des paramètres.

Substitution de paramètres et types

Utilisez la syntaxe @ {parameterName} pour définir les paramètres de votre modèle de politique. Lorsque vous créez une demande de délégation, vous devez spécifier le type de chaque paramètre.

String

Une valeur unique qui est substituée directement dans le modèle.

Modèle :

"Resource": "arn:aws:s3:::@{bucketName}/*"

Paramètres :

{ "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }

Résultat rendu :

"Resource": "arn:aws:s3:::my-bucket/*"

StringList

Plusieurs valeurs qui génèrent plusieurs entrées de ressources. Lorsqu'un StringList paramètre est utilisé dans un ARN de ressource, il se développe pour créer des entrées de ressource distinctes pour chaque valeur.

Modèle :

"Resource": "arn:aws:s3:::@{bucketNames}/*"

Paramètres :

{ "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" }

Résultat rendu :

"Resource": [ "arn:aws:s3:::bucket-1/*", "arn:aws:s3:::bucket-2/*" ]

Comportement entre produits

Lorsque plusieurs paramètres sont utilisés dans le même ARN de ressource, StringList les paramètres créent un produit croisé de toutes les combinaisons.

Modèle :

"Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*"

Paramètres :

[ { "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" }, { "Name": "prefix", "Values": ["data"], "Type": "String" } ]

Résultat rendu :

"Resource": [ "arn:aws:s3:::bucket-1/data/*", "arn:aws:s3:::bucket-2/data/*" ]

Déclarations conditionnelles

Utilisez la directive @Enabled pour inclure ou exclure de manière conditionnelle des instructions complètes en fonction des valeurs des paramètres.

Syntaxe :

  • @Enabled : « ParameterName » - Inclut l'instruction lorsque la valeur du paramètre est « True »

  • @Enabled : « ! ParameterName » - Inclut l'instruction lorsque la valeur du paramètre n'est PAS « vraie » (négation)

Modèle :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "@Enabled": "ENABLE_S3_WRITE", "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] }

Paramètres (lorsque ENABLE_S3_WRITE est « True ») :

[ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["True"], "Type": "String" } ]

Résultat rendu :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*" } ] }

Paramètres (lorsque ENABLE_S3_WRITE est « False ») :

[ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["False"], "Type": "String" } ]

Résultat rendu :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" } ] }

Lorsque ENABLE_S3_WRITE est défini sur « True », l'instruction conditionnelle est incluse. Lorsqu'elle est définie sur « False », l'instruction est exclue de la politique rendue.

Exemples supplémentaires

Les exemples suivants illustrent les modèles courants d'utilisation des modèles de politique dans le cadre d'une délégation temporaire. Ils se concentrent sur la création de rôles IAM avec des limites d'autorisation pour un accès à long terme et présentent différentes stratégies pour définir les autorisations accordées à des ressources spécifiques. Ces exemples montrent comment trouver un équilibre entre flexibilité et sécurité en utilisant des techniques telles que les préfixes ARN, le balisage des ressources et les mises à jour des limites d'autorisation.

Exemple 1 : Octroi d'un accès à long terme à des ressources spécifiques

La limite d'autorisation suivante est soumise en tant que « SQSAccessor limite » pour « partner.com » :

{ "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } }
Note

Cela inclut une condition relative au même compte afin d'éviter d'accorder l'accès aux files d'attente d'autres comptes soumis à des politiques de ressources ouvertes. Une référence directe à l'identifiant de compte du client ne peut pas être incluse car la limite est partagée entre tous les clients et ne peut pas être modélisée.

Comme il s'agit de la première version de cette politique, son ARN est arn:aws:iam : :partner : _2025_01_15 policy/permissions-boundary/partner.com/SQSAccessorBoundary

Le modèle de politique suivant est soumis pour les autorisations d'accès temporaires :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:ListQueues" ], "Resource": "arn:aws:sqs:*:*:*" }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] }

Exemple 2 : Utilisation des préfixes ARN

La limite d'autorisation peut spécifier un préfixe ARN de ressource pour limiter l'accès :

"Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*"

Cela limite l'accès aux seules ressources portant ce préfixe, réduisant ainsi la portée des ressources accessibles.

Exemple 3 : Utilisation de balises pour le contrôle d'accès aux ressources

Vous pouvez étiqueter des ressources lors d'un accès délégué temporaire et vous fier à ces balises pour un contrôle d'accès à long terme.

Limite d'autorisation autorisant l'accès aux ressources étiquetées :

{ "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:ResourceTag/ManagedByPartnerDotCom": "false" }, "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } }

Modèle de politique pour étiqueter les nouvelles files d'attente lors de leur création :

{ "Effect": "Allow", "Action": [ "sqs:CreateQueue", "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:RequestTag/ManagedByPartnerDotCom": "false" } } }

Modèle de politique pour étiqueter les files d'attente préexistantes et créer le rôle :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}", "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": "ManagedByPartnerDotCom" } } }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] }

Cette approche permet aux clients de confirmer explicitement quelles ressources spécifiques sont accessibles à long terme.

Exemple 4 : mise à jour de la limite d'autorisation

Pour mettre à jour une limite d'autorisation, enregistrez une nouvelle version avec un nouveau suffixe de date et demandez l'autorisation de la remplacer.

Limite d'autorisation mise à jour avec autorisation supplémentaire :

{ "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:PurgeQueue", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } }

En tant que deuxième version, cette politique possède l'ARN : arn:aws:iam : :partner : _2025_01_20 policy/permissions-boundary/partner.com/SQSAccessorBoundary

Modèle de politique pour mettre à jour la limite d'autorisation pour le rôle existant :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PutRolePermissionsBoundary" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20" } } } ] }

Les clients doivent approuver cette demande de délégation pour mettre à jour la limite d'autorisation du rôle existant.