Contrôle de l'accès aux AWS ressources à l'aide de politiques - 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.

Contrôle de l'accès aux AWS ressources à l'aide de politiques

Vous pouvez utiliser une politique pour contrôler l'accès aux ressources au sein d'IAM ou de la totalité d' AWS entre elles.

Pour utiliser une politique visant à contrôler l'accès AWS, vous devez comprendre comment AWS octroyer l'accès. AWS est composé de collections de ressources. Un utilisateur IAM est une ressource. Un compartiment Amazon S3 est une ressource. Lorsque vous utilisez l' AWS API, le AWS CLI, ou le AWS Management Console pour effectuer une opération (telle que la création d'un utilisateur), vous envoyez une demande pour cette opération. Votre demande spécifie une action, une ressource, une entité du principal (utilisateur ou rôle), un compte du principal et toutes les informations nécessaires relatives à la demande. Toutes ces informations fournissent le contexte.

AWS vérifie ensuite que vous (le principal) êtes authentifié (connecté) et autorisé (autorisé) à effectuer l'action spécifiée sur la ressource spécifiée. Lors de l'autorisation, AWS vérifie toutes les politiques qui s'appliquent au contexte de votre demande. La plupart des politiques sont stockées AWS sous forme de documents JSON et spécifient les autorisations pour les entités principales. Pour plus d'informations sur les types de politiques et les utilisations, veuillez consulter Politiques et autorisations dans IAM.

AWS autorise la demande uniquement si chaque partie de votre demande est autorisée par les politiques. Pour afficher un schéma de ce processus, reportez-vous à Fonctionnement de IAM. Pour plus de détails sur AWS la manière de déterminer si une demande est autorisée, consultezLogique d'évaluation de politiques.

Lorsque vous créez une politique IAM, vous pouvez contrôler l'accès aux éléments suivants :

  • Entités du principal – Contrôler ce que l'individu à l'origine de la requête (le principal) est autorisé à faire.

  • IAM Identities (Identités IAM) : contrôlez à quelles identités IAM (groupes d'utilisateurs, utilisateurs et rôles) il est possible d'accéder et comment y accéder.

  • IAM Policies (Politiques IAM) : contrôlez qui peut créer, modifier et supprimer les politiques gérées par les clients, et qui peut attacher et détacher toutes les politiques gérées.

  • AWS Resources (Ressources AWS ) : contrôlez qui a accès aux ressources à l'aide d'une politique basée sur les identités ou sur les ressources.

  • AWS Accounts (Comptes) : contrôle si une requête est autorisée uniquement pour les membres d'un compte spécifique.

Les politiques vous permettent de spécifier qui a accès aux AWS ressources et quelles actions ils peuvent effectuer sur ces ressources. Chaque utilisateur IAM démarre sans autorisation. En d'autres termes, par défaut, les utilisateurs ne peuvent rien faire, pas même afficher leurs propres clés d'accès. Pour autoriser un utilisateur à effectuer une action, vous pouvez ajouter l'autorisation appropriée pour l'utilisateur (c'est-à-dire attacher une politique à celui-ci). Vous pouvez également ajouter l'utilisateur à un groupe d'utilisateurs disposant de l'autorisation prévue.

Par exemple, vous pourriez accorder à un utilisateur l'autorisation d'afficher ses propres clés d'accès. Vous pourriez également étendre cette autorisation et permettre également à chaque utilisateur de créer, mettre à jour et la supprimer ses propres clés.

Lorsque vous accordez des autorisations à un groupe d'utilisateurs, tous les utilisateurs de ce groupe obtiennent ces autorisations. Par exemple, vous pouvez autoriser le groupe d'utilisateurs Administrateurs à effectuer n'importe quelle action IAM sur n'importe quelle Compte AWS ressource. Un autre exemple : vous pouvez donner au groupe d'utilisateurs Managers (Gestionnaires) l'autorisation de décrire les instances Amazon EC2 de l' Compte AWS.

Pour de plus amples informations sur la façon de déléguer des autorisations de base à vos utilisateurs, groupes d'utilisateurs et rôles, veuillez consulter Autorisations requises pour accéder aux autres ressources IAM. Pour obtenir des exemples supplémentaires de politiques illustrant des autorisations de base, consultez Exemples de politiques de gestion de ressources IAM.

Contrôle de l'accès pour les entités du principal

Vous pouvez utiliser des politiques pour contrôler ce que la personne à l'origine de la demande (le principal) est autorisée à effectuer. Pour ce faire, vous devez attacher à l'identité de cette personne une politique basée sur l'identité (utilisateur, groupe d'utilisateurs ou rôle). Vous pouvez également utiliser une limite d'autorisations pour définir les autorisations maximales qu'une entité (utilisateur ou rôle) peut avoir.

Supposons, par exemple, que vous souhaitiez que l'utilisateur Zhang Wei ait un accès complet à Amazon DynamoDB CloudWatch, Amazon EC2 et Amazon S3. Vous pouvez créer deux politiques différentes pour pouvoir les diviser plus tard si vous avez besoin d'un ensemble d'autorisations pour un autre utilisateur. Vous pouvez également regrouper les deux autorisations dans une seule politique, puis associer cette dernière à l'utilisateur IAM nommé Zhang Wei. Vous pouvez aussi attacher une politique à un groupe d'utilisateurs auquel Zhang appartient, ou à un rôle que Zhang peut endosser. Ainsi, lorsque Zhang consulte le contenu d'un compartiment S3, ses demandes sont autorisées. S'il tente de créer un nouvel utilisateur IAM, sa demande est rejetée car il ne dispose pas de l'autorisation appropriée.

Vous pouvez utiliser une limite de permissions sur Zhang pour veiller à ce qu'il n'ait jamais accès au compartiment S3 DOC-EXAMPLE-BUCKET1. Pour ce faire, déterminez le nombre maximum d'autorisations dont vous souhaitez que Zhang dispose. Dans ce cas, vous pouvez contrôler ses actions à l'aide de ses politiques d'autorisations. Ici, vous veillez simplement à ce qu'il n'accède pas au compartiment confidentiel. Vous utilisez donc la politique suivante pour définir les limites de Zhang afin d'autoriser toutes les AWS actions pour Amazon S3 et quelques autres services, mais de refuser l'accès au compartiment DOC-EXAMPLE-BUCKET1 S3. Étant donné que la limite d'autorisations ne permet pas tous les actions IAM, elle empêche Zhang de supprimer sa limite (ou celle d'une autre personne).

{ "Version": "2012-10-17", "Statement": [ { "Sid": "PermissionsBoundarySomeServices", "Effect": "Allow", "Action": [ "cloudwatch:*", "dynamodb:*", "ec2:*", "s3:*" ], "Resource": "*" }, { "Sid": "PermissionsBoundaryNoConfidentialBucket", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET1", "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*" ] } ] }

Lorsque vous attribuez une telle politique à un utilisateur en tant que limite d'autorisations, n'oubliez pas qu'elle n'accorde aucune autorisation. Elle définit le nombre maximum d'autorisations qu'une politique basée sur l'identité peut accorder à une entité IAM. Pour plus d'informations sur les limites d'autorisations, consultez Limites d'autorisations pour les entités IAM.

Pour obtenir des informations détaillées sur les procédures mentionnées précédemment, reportez-vous aux ressources suivantes :

Contrôle de l'accès aux identités

Vous pouvez utiliser des politiques IAM pour contrôler ce que vos utilisateurs peuvent faire à une identité en créant une politique que vous attachez à tous les utilisateurs via un groupe d'utilisateurs. Pour cela, créez une politique qui limite les opérations susceptibles d'être effectuées sur une identité ou les autorisations d'accès.

Par exemple, vous pouvez créer un groupe d'utilisateurs nommé AllUsers, puis l'associer à tous les utilisateurs. Lorsque vous créez le groupe d'utilisateurs, vous pouvez donner à tous vos utilisateurs l'accès à la définition de leurs informations d'identification comme décrit dans la section précédente. Vous pouvez ensuite créer une politique qui interdit l'accès en modification du groupe d'utilisateurs, sauf si le nom d'utilisateur est inclus dans la condition de la politique. Mais cette partie de la politique interdit uniquement l'accès à tous, à l'exception des utilisateurs répertoriés. Vous devez également inclure les autorisations visant à permettre toutes les actions de gestion de groupe d'utilisateurs pour toutes les personnes du groupe. Enfin, vous attachez cette politique au groupe d'utilisateurs de façon à ce qu'elle soit appliquée à tous les utilisateurs. De cette façon, lorsqu'un utilisateur non spécifié dans la politique tente d'apporter des modifications au groupe d'utilisateurs, la demande est refusée.

Pour créer cette politique avec l'éditeur visuel
  1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/iam/.

  2. Dans le panneau de navigation de gauche, sélectionnez Policies (Politiques).

    Si vous sélectionnez Politiques pour la première fois, la page Bienvenue dans les politiques gérées s'affiche. Sélectionnez Get started (Mise en route).

  3. Sélectionnez Créer une politique.

  4. Dans la section Éditeur de politiques, choisissez l'option Visuel.

  5. Dans Sélectionner un service, choisissez IAM.

  6. Dans Actions autorisées, tapez group dans la zone de recherche. L'éditeur visuel affiche toutes les actions IAM qui contiennent le mot group. Activez toutes les cases à cocher.

  7. Choisissez Ressources pour spécifier les ressources de votre politique. En fonction des actions que vous avez choisies, vous devriez voir les types de ressources groupe et utilisateur.

    • groupe : choisissez Ajouter des ARN. Pour Ressource dans, sélectionnez l'option Tout compte. Cochez la case Tout nom de groupe avec chemin, puis tapez le nom du groupe d'utilisateurs AllUsers. Puis, choisissez Ajouter des ARN.

    • utilisateur : cochez la case en regard de Toute personne dans ce compte.

    Une des actions que vous avez choisies, ListGroups, ne prend pas en charge l'utilisation de ressources spécifiques. Vous n'avez pas besoin de choisir Toutes les ressources pour cette action. Lorsque vous enregistrez votre politique ou que vous l'affichez dans l'éditeur JSON, vous pouvez voir que IAM crée automatiquement un nouveau bloc d'autorisation qui accorde à cette action une autorisation sur toutes les ressources.

  8. Pour ajouter un autre bloc d'autorisation, choisissez Ajouter d'autres autorisations.

  9. Choisissez Sélectionner un service, puis IAM.

  10. Choisissez Actions autorisées, puis Basculer pour refuser les autorisations. Si vous procédez ainsi, l'ensemble du bloc est utilisé pour refuser des autorisations.

  11. Dans la zone de recherche, saisissez group. L'éditeur visuel affiche toutes les actions IAM qui contiennent le mot group. Activez les cases à cocher en regard des actions suivantes :

    • CreateGroup

    • DeleteGroup

    • RemoveUserFromGroup

    • AttachGroupPolicy

    • DeleteGroupPolicy

    • DetachGroupPolicy

    • PutGroupPolicy

    • UpdateGroup

  12. Choisissez Ressources pour spécifier les ressources de votre politique. En fonction des actions que vous avez choisies, vous devriez voir le type de ressource group. Choisissez Ajouter des ARN. Pour Ressource dans, sélectionnez l'option Tout compte. Pour Tout nom de groupe avec chemin, tapez le nom du groupe d'utilisateurs AllUsers. Puis, choisissez Ajouter des ARN.

  13. Choisissez Demander des conditions – facultatif, puis Ajouter une autre condition. Remplissez le formulaire avec les valeurs suivantes :

    • Clé de condition : choisissez aws:username

    • Qualifier (Qualificateur) : sélectionnez Default (Valeur par défaut)

    • Opérateur — Choisissez StringNotEquals

    • Valeur : tapez srodriguez, puis choisissez Ajouter pour ajouter une autre valeur. Tapez mjackson, puis choisissez Ajouter pour ajouter une autre valeur. Tapez adesai, puis choisissez Ajouter une condition.

    Grâce à cette condition, l'accès est refusé aux actions spécifiées de gestion du groupe d'utilisateurs lorsque l'utilisateur à l'origine de l'action n'est pas inclus dans la liste. Dans la mesure où cette option refuse explicitement l'autorisation, elle remplace le bloc précédent qui a autorisé les utilisateurs à demander les actions. Les utilisateurs de la liste ne se voient pas refuser l'accès et ils sont autorisés dans le premier bloc d'autorisation, afin qu'ils puissent entièrement gérer le groupe d'utilisateurs.

  14. Lorsque vous avez terminé, choisissez Next.

    Note

    Vous pouvez basculer à tout moment entre les options des éditeurs visuel et JSON. Toutefois, si vous apportez des modifications ou si vous choisissez Suivant dans l'option éditeur visuel, IAM peut restructurer votre politique afin de l'optimiser pour l'éditeur visuel. Pour plus d’informations, consultez Restructuration de politique.

  15. Sur la page Vérifier et créer, pour le Nom de la politique, tapez LimitAllUserGroupManagement. Pour la Description, saisissez Allows all users read-only access to a specific user group, and allows only specific users access to make changes to the user group. Vérifiez les Autorisations définies dans cette politique pour vous assurer que vous les avez accordées comme prévu. Ensuite, choisissez Créer une politique pour enregistrer votre nouvelle politique.

  16. Attachez la politique à votre groupe d'utilisateurs. Pour plus d'informations, veuillez consulter Ajout et suppression d'autorisations basées sur l'identité IAM.

Vous pouvez aussi créer la même politique à l'aide de cet exemple de document de politique JSON. Pour afficher cette politique JSON, veuillez consulter IAM : autorise des utilisateurs spécifiques à gérer un groupe par programmation et dans la console. Pour obtenir des instructions détaillées sur la création d'une politique à l'aide d'un document JSON, veuillez consulter Création de politiques à l'aide de l'éditeur JSON.

Contrôle de l'accès aux politiques

Vous pouvez contrôler la manière dont vos utilisateurs peuvent appliquer les politiques AWS gérées. Pour cela, attachez cette politique à tous vos utilisateurs. Idéalement, vous pouvez le faire en utilisant un groupe d'utilisateurs.

Par exemple, vous pouvez créer une politique qui permet aux utilisateurs d'associer uniquement l'IAM UserChangePassword et les politiques PowerUserAccess AWS gérées à un nouvel utilisateur, groupe d'utilisateurs ou rôle IAM.

Pour les politiques gérées par les clients, vous pouvez contrôler qui peut les créer, les mettre à jour et les supprimer. Vous pouvez contrôler qui peut attacher et détacher les politiques vers et depuis des entités du principal (groupes d'utilisateurs, utilisateurs et rôles). Vous pouvez également contrôler quelles politiques peuvent être attachées ou détachées de ces entités.

Par exemple, vous pouvez autoriser un administrateur de compte à créer, mettre à jour et supprimer des politiques. Ensuite, vous accordez des autorisations à un responsable d'équipe ou un autre administrateur disposant de droits limités afin de lui permettre d'attacher et de détacher ces politiques des entités du principal gérées par l'administrateur doté de droits limités.

Pour de plus amples informations, veuillez consulter les ressources suivantes :

Contrôle des autorisations pour la création, mise à jour et suppression de politiques gérées par le client

Vous pouvez utiliser des politiques IAM pour contrôler qui est autorisé à créer, mettre à jour et supprimer les politiques gérées par le client dans votre Compte AWS. La liste suivante répertorie les opérations d'API ayant un lien direct avec la création, la mise à jour, la suppression et la gestion des politiques ou versions de politiques :

Les opérations d'API ci-dessus correspondent à des actions que vous pouvez autoriser ou refuser autrement dit, des autorisations que vous pouvez accorder à l'aide d'une politique IAM.

Examinons l'exemple de politique suivant. Il autorise un utilisateur à créer, mettre à jour (autrement dit, créer une version de politique), supprimer et définir une version par défaut pour toutes les politiques gérées par le client dans l' Compte AWS. Cette politique permet également à l'utilisateur d'obtenir des politiques ou d'en afficher la liste. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez Création de politiques à l'aide de l'éditeur JSON.

Exemple de politique qui autorise la création, mise à jour, suppression, obtention et définition de la version par défaut pour toutes les politiques
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:CreatePolicy", "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:SetDefaultPolicyVersion" ], "Resource": "*" } }

Vous pouvez créer des politiques qui limitent l'utilisation de ces opérations d'API aux seules politiques gérées que vous spécifiez. Par exemple, il est possible d'autoriser un utilisateur à définir la version par défaut et supprimer des versions de politique, mais uniquement pour certaines politiques gérées par le client. Pour ce faire, vous spécifiez l'ARN de la politique dans l'élément Resource de la politique qui accorde les autorisations.

L'exemple suivant illustre une politique qui autorise un utilisateur à supprimer des versions de politique et à définir la version par défaut. Mais ces actions sont uniquement autorisées pour les politiques gérées par le client comportant le chemin/TEAM-A/. L'ARN de la politique gérée par le client est spécifié dans l'élément Resource de la politique. Dans cet exemple, l'ARN inclut un chemin d'accès et un caractère générique et, par conséquent, correspond à toutes les politiques gérées par le client qui incluent le chemin /TEAM-A/. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez Création de politiques à l'aide de l'éditeur JSON.

Pour de plus amples informations sur l'utilisation de chemins dans les noms de politiques gérées par le client, veuillez consulter Noms conviviaux et chemins.

Exemple de politique qui autorise la suppression de versions de politiques et la définition de la version par défaut pour des politiques spécifiques uniquement
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": "arn:aws:iam::account-id:policy/TEAM-A/*" } }

Contrôle des autorisations pour attacher et détacher des politiques gérées

Vous pouvez également utiliser des politiques IAM pour n'autoriser les utilisateurs qu'à utiliser des politiques gérées spécifiques. En effet, vous pouvez contrôler les autorisations qu'un utilisateur est autorisé à accorder à d'autres entités du principal.

La liste suivante répertorie les opérations d'API utilisées pour attacher et détacher des politiques gérées d'entités du principal :

Vous pouvez créer des politiques qui limitent l'utilisation de ces opérations d'API aux seules politiques gérées et/ou entités de principal que vous spécifiez. Par exemple, il est possible d'autoriser un utilisateur à attacher des politiques gérées, mais uniquement celles que vous spécifiez. Ou, il est possible d'autoriser un utilisateur à attacher des politiques gérées, mais uniquement aux entités du principal que vous spécifiez.

L'exemple suivant illustre une politique qui autorise un utilisateur à attacher des politiques gérées aux groupes d'utilisateurs et rôles comportant le chemin /TEAM-A/ uniquement. Les ARN de groupe d'utilisateurs et de rôle sont spécifiés dans l'élément de politique Resource. Dans cet exemple, les ARN incluent un chemin d'accès et un caractère générique et, par conséquent, correspondent à tous les groupes d'utilisateurs et rôles qui incluent le chemin /TEAM-A/. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez Création de politiques à l'aide de l'éditeur JSON.

Exemple de politique qui autorise l'utilisateur à attacher des politiques gérées à des groupes d'utilisateurs ou rôles spécifiques uniquement
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachGroupPolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::account-id:group/TEAM-A/*", "arn:aws:iam::account-id:role/TEAM-A/*" ] } }

Vous pouvez limiter encore davantage les actions de l'exemple précédent, de manière à n'affecter que des politiques spécifiques. En d'autres termes, vous pouvez contrôler les autorisations qu'un utilisateur est autorisé à attacher à d'autres entités du principal, en ajoutant une condition à la politique.

Dans l'exemple suivant, la condition garantit que les autorisations AttachGroupPolicy et AttachRolePolicy sont octroyées uniquement si la politique devant être attachée correspond à l'une des politiques spécifiées. La condition utilise la clé de condition iam:PolicyARN pour déterminer la ou les politiques qui peuvent être attachées. L'exemple de politique suivant développe l'exemple précédent. Il autorise un utilisateur à attacher uniquement les politiques gérées comportant le chemin /TEAM-A/ aux seuls groupes d'utilisateurs et rôles incluent le chemin /TEAM-A/. Pour apprendre à créer une politique à l'aide de cet exemple de document de politique JSON, consultez Création de politiques à l'aide de l'éditeur JSON.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachGroupPolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::account-id:group/TEAM-A/*", "arn:aws:iam::account-id:role/TEAM-A/*" ], "Condition": {"ArnLike": {"iam:PolicyARN": "arn:aws:iam::account-id:policy/TEAM-A/*"} } } }

Cette politique utilise l'opérateur de condition ArnLike, mais vous pouvez également utiliser l'opérateur de condition ArnEquals car ces deux opérateurs de condition se comportent de manière identique. Pour de plus amples informations sur ArnLike et ArnEquals, veuillez consulter Opérateurs de condition d'Amazon Resource Name (ARN) dans la section Types de conditions des Références des éléments de politique.

Par exemple, vous pouvez limiter l'utilisation de ces actions aux politiques gérées que vous spécifiez. Pour ce faire, vous spécifiez l'ARN de la politique dans l'élément Condition de la politique qui accorde les autorisations. Par exemple, pour spécifier l'ARN d'une politique gérée par le client :

"Condition": {"ArnEquals": {"iam:PolicyARN": "arn:aws:iam::123456789012:policy/POLICY-NAME"} }

Vous pouvez également spécifier l'ARN d'une stratégie AWS gérée dans l'Conditionélément d'une stratégie. L'ARN d'une politique AWS gérée utilise l'alias spécial contenu aws dans l'ARN de la politique au lieu d'un identifiant de compte, comme dans cet exemple :

"Condition": {"ArnEquals": {"iam:PolicyARN": "arn:aws:iam::aws:policy/AmazonEC2FullAccess"} }

Contrôle de l'accès aux ressources

Vous pouvez contrôler l'accès aux ressources à l'aide d'une politique basée sur les identités ou sur les ressources. Dans le cadre d'une politique basée sur les identités, vous attachez la politique à une identité et vous spécifiez à quelles ressources cette identité peut accéder. Dans le cadre d'une politique basée sur les ressources, vous attachez une politique à la ressource que vous souhaitez contrôler. Dans la politique, vous spécifiez quels principaux peuvent accéder à cette ressource. Pour de plus amples informations sur les deux types de stratégie, veuillez consulter Politiques basées sur l'identité et Politiques basées sur une ressource.

Pour de plus amples informations, veuillez consulter les ressources suivantes :

Des créateurs de ressource ne reçoivent pas automatiquement des autorisations

Si vous vous connectez à l'aide des Utilisateur racine d'un compte AWS informations d'identification, vous êtes autorisé à effectuer toute action sur les ressources appartenant au compte. Toutefois, ce n'est pas le cas pour les utilisateurs IAM. Un utilisateur IAM peut recevoir un accès pour créer une ressource, mais les autorisations de cet utilisateur, même pour cette ressource, se limitent à ce qui a été explicitement accordé. Cela signifie que si vous créez une ressource, par exemple un rôle IAM, vous n'avez pas automatiquement l'autorisation de modifier ou de supprimer ce rôle. De plus, votre autorisation peut être révoquée à tout moment par le propriétaire du compte ou par un autre utilisateur disposant d'un accès pour gérer vos autorisations.

Contrôle de l'accès aux principaux dans un compte spécifique

Vous pouvez accorder directement à des utilisateurs IAM de votre propre compte un accès à vos ressources. Si des utilisateurs d'un autre compte doivent accéder à vos ressources, vous pouvez créer un rôle IAM. Un rôle est une entité incluant des autorisations, mais qui n'est pas associée à un utilisateur spécifique. Les utilisateurs d'autres comptes peuvent ensuite endosser le rôle et accéder aux ressources en fonction des autorisations que vous avez attribuées à ce rôle. Pour plus d'informations, veuillez consulter Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS dont vous êtes le propriétaire.

Note

Certains services prennent en charge les politiques basées sur les ressources, comme décrit dansPolitiques basées sur l'identité et Politiques basées sur une ressource (Amazon S3, Amazon SNS et Amazon SQS, par ex.). Pour ces services, une alternative à l'utilisation de rôles consiste à attacher une politique à la ressource (compartiment, rubrique ou file d'attente) que vous voulez partager. La politique basée sur les ressources peut spécifier le AWS compte autorisé à accéder à la ressource.