Contrôlez l'accès aux AWS ressources à l'aide de politiques - AWS Identity and Access Management
Contrôle de l'accès pour les entités du principal Contrôle de l'accès aux identitésContrôle de l'accès aux politiquesContrôle de l'accès aux ressourcesContrôle de l'accès aux principaux dans un compte spécifique

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ôlez 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 IAM ou dans l'ensemble de AWS.

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 le AWS API AWS CLI, le ou 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 applicables au contexte de votre demande. La plupart des politiques sont stockées AWS sous forme de JSONdocuments 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 AWS Identity and Access Management.

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 à Comment IAM fonctionne. Pour plus de détails sur AWS la manière de déterminer si une demande est autorisée, consultezLogique d’évaluation de stratégies.

Lorsque vous créez une IAM politique, 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.

  • IAMIdentités : contrôlez quelles IAM identités (IAMgroupes, utilisateurs et rôles) sont accessibles et comment.

  • IAMPolitiques : contrôlez qui peut créer, modifier et supprimer des politiques gérées par le client, et qui peut joindre 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 IAM utilisateur commence sans aucune 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 IAM action sur l'une des Compte AWS ressources. Autre exemple : vous pouvez autoriser le groupe d'utilisateurs Managers à décrire les EC2 instances Amazon du Compte AWS.

Pour plus d'informations sur la façon de déléguer des autorisations de base à vos utilisateurs, IAM groupes et rôles, consultezAutorisations 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 à CloudWatch Amazon DynamoDB, EC2 Amazon 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 politique à l'IAMutilisateur 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 essaie de créer un nouvel IAM utilisateur, sa demande est refusée car il n'en a pas l'autorisation.

Vous pouvez utiliser une limite de permissions sur Zhang pour veiller à ce qu'il n'ait jamais accès au compartiment S3 amzn-s3-demo-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 amzn-s3-demo-bucket1 S3. Comme la limite des autorisations n'autorise aucune IAM action, elle empêche Zhang de supprimer sa limite (ou celle de quiconque).

{
    "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:::amzn-s3-demo-bucket1",
                "arn:aws:s3:::amzn-s3-demo-bucket1/*"
            ]
        }
    ]
}

Lorsque vous attribuez une telle politique à un utilisateur en tant que limite d'autorisations, n'oubliez pas qu'elle n'accorde aucune autorisation. Il définit les autorisations maximales qu'une politique basée sur l'identité peut accorder à une IAM entité. Pour plus d'informations sur les limites d'autorisations, consultez Limites d'autorisations pour des 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 IAM politiques pour contrôler ce que vos utilisateurs peuvent faire à une identité en créant une politique que vous associez à tous les utilisateurs par le biais d'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 IAM console 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. Choisissez Create Policy (Créer une politique).

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

  5. Dans Sélectionnez 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 ARNs. 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. Choisissez ensuite AjouterARNs.

    • 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 la consultez dans l'JSONéditeur, vous pouvez constater que cela crée IAM automatiquement un nouveau bloc d'autorisation octroyant l'autorisation à cette action sur toutes les ressources.

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

  9. Choisissez Sélectionner un service, puis choisissez 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 ARNs. Pour Ressource dans, sélectionnez l'option Tout compte. Pour Tout nom de groupe avec chemin, tapez le nom du groupe d'utilisateurs AllUsers. Choisissez ensuite AjouterARNs.

  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 entre les options Visual et celles de JSONl'éditeur à tout moment. Toutefois, si vous apportez des modifications ou si vous choisissez Suivant dans l'option de l'éditeur visuel, vous IAM pouvez restructurer votre politique afin de l'optimiser pour l'éditeur visuel. Pour de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter Ajouter et supprimer des autorisations IAM d'identité.

Vous pouvez également créer la même stratégie à l'aide de cet exemple de document JSON de stratégie. Pour consulter cette JSON politique, consultezIAM : 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 JSON document, consultezCréation de politiques à l'aide de l'JSONéditeur.

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 IAMUserChangePasswordles politiques PowerUserAccess AWS gérées à un nouvel IAM utilisateur, groupe d'utilisateurs ou rôle.

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 associer et détacher des politiques aux entités principales (IAMgroupes, 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 IAMpolitiques pour contrôler qui est autorisé à créer, mettre à jour et supprimer des politiques gérées par les clients dans votre Compte AWS. La liste suivante contient les API opérations directement liées à la création, à la mise à jour et à la suppression de politiques ou de versions de politiques :

Les API opérations de la liste précédente correspondent à des actions que vous pouvez autoriser ou refuser, c'est-à-dire 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 savoir comment créer une stratégie à l'aide de cet exemple JSON de document de stratégie, voirCréation de politiques à l'aide de l'JSONéditeur.

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 API opérations afin d'affecter uniquement les 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, spécifiez la politique ARN dans l'Resourceélément de la stratégie qui accorde ces 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 ne sont autorisées que pour les politiques gérées par le client qui incluent le chemin/TEAM-A/. La politique gérée par le client ARN est spécifiée dans l'Resourceélément de la politique. (Dans cet exemple, il ARN inclut un chemin et un caractère générique et correspond donc à toutes les politiques gérées par le client qui incluent le chemin/TEAM-A/). Pour savoir comment créer une stratégie à l'aide de cet exemple JSON de document de stratégie, voirCréation de politiques à l'aide de l'JSONéditeur.

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 IAM politiques pour permettre aux utilisateurs de travailler uniquement avec 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 API opérations qui concernent directement l'attachement et le détachement de politiques gérées aux entités principales et à leur détachement :

Vous pouvez créer des politiques qui limitent l'utilisation de ces API opérations afin d'affecter uniquement les politiques gérées spécifiques et/ou les entités principales 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 de politique suivant permet à un utilisateur d'associer des politiques gérées uniquement aux IAM groupes et aux rôles qui incluent le chemin/TEAM-A/. Le groupe d'utilisateurs et le rôle ARNs sont spécifiés dans l'Resourceélément de la politique. (Dans cet exemple, ils ARNs incluent un chemin et un caractère générique et correspondent ainsi à tous les IAM groupes et rôles qui incluent le chemin/TEAM-A/). Pour savoir comment créer une stratégie à l'aide de cet exemple JSON de document de stratégie, voirCréation de politiques à l'aide de l'JSONéditeur.

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 permet à un utilisateur d'associer uniquement les politiques gérées qui incluent le chemin/TEAM-A/ aux seuls IAM groupes et rôles qui incluent le chemin/-A/TEAM. Pour savoir comment créer une stratégie à l'aide de cet exemple JSON de document de stratégie, voirCréation de politiques à l'aide de l'JSONéditeur.

{
  "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 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, spécifiez la politique ARN dans l'Conditionélément de la stratégie qui accorde ces autorisations. Par exemple, pour spécifier une politique gérée par le client : ARN

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

Vous pouvez également spécifier le nom ARN d'une stratégie AWS gérée dans l'Conditionélément d'une stratégie. Le ARN d'une politique AWS gérée utilise l'alias aws spécial de la politique ARN 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. Cependant, cela n'est pas vrai pour IAM les utilisateurs. Un IAM utilisateur peut être autorisé à créer une ressource, mais ses autorisations, même pour cette ressource, sont limitées à celles qui ont été explicitement accordées. Cela signifie que ce n'est pas parce que vous créez une ressource, telle qu'un IAM rôle, que vous n'êtes pas automatiquement autorisé à modifier ou à 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 directement autoriser IAM les utilisateurs de votre propre compte à accéder à vos ressources. Si les utilisateurs d'un autre compte ont besoin d'accéder à vos ressources, vous pouvez créer un IAM rôle. 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 de plus amples informations, veuillez consulter Accès pour un IAM utilisateur à un autre utilisateur Compte AWS que vous possédez.

Note

Certains services prennent en charge les politiques basées sur les ressources décrites dans Politiques basées sur l'identité et Politiques basées sur une ressource (comme Amazon S3SNS, Amazon et AmazonSQS). 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.