View a markdown version of this page

Modèles de politique  - AWS Gestion de l’identité et des accès
Comment fonctionnent les modèles de politiquesSyntaxe du modèleExemples supplémentaires

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 politiques sont une nouvelle structure IAM conçue pour définir les autorisations temporaires que les partenaires demandent sur les comptes des clients. Comme les 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 politique auprès AWS de. AWS attribue à chaque modèle un ARN unique auquel vous faites référence lorsque vous créez des demandes de délégation.

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

  • L'ARN du modèle de politique

  • 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 finale lorsqu'ils approuvent votre demande de délégation, afin de savoir exactement quelles autorisations seront accordées.

Note

La taille maximale de la politique rendue finale est 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 finale (ce que les clients voient) :

{
    "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 politiques 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 stratégie complètes en fonction des valeurs des paramètres.

Substitution et types de paramètres

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 l'ARN d'une 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/*"
]

Cross-Product Comportement

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 entières 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 vaut « 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 des modèles courants d'utilisation de modèles de politiques dans le cadre de la 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 la portée des autorisations pour 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 la mise à jour des limites d'autorisation.

Exemple 1 : accorder l' Long-Term accès à des ressources spécifiques

La limite d'autorisation suivante est soumise sous la forme SQSAccessorBoundary « » 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 dotés de 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 par 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 : -. policy/permissions boundary/partner com/SQSAccessorBoundary_2025_01_15

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 de 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 baliser 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 balisé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 baliser 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 baliser 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 le 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 : -. policy/permissions boundary/partner com/SQSAccessorBoundary_2025_01_20

Modèle de politique pour mettre à jour la limite d'autorisation du 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.