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.
Accès aux ressources entre comptes dans IAM
Pour certains AWS services, vous pouvez accorder un accès multicompte à vos ressources à l'aide IAM de. Pour cela, vous pouvez attacher une politique de ressources directement à la ressource que vous voulez partager, ou bien utiliser un rôle en tant que proxy.
Pour partager directement une ressource, la ressource que vous voulez partager doit prendre en charge les politiques basées sur les ressources. Contrairement à une politique basée sur l'identité pour un rôle, une politique basée sur une ressource spécifie qui (quel principal) peut accéder à cette ressource.
Utilisez un rôle en tant que proxy lorsque vous voulez accéder aux ressources d'un autre compte qui ne prend pas en charge les politiques basées sur les ressources.
Pour en savoir plus sur les différences entre ces types de politiques, consultez Politiques basées sur l'identité et Politiques basées sur une ressource.
Note
IAMles rôles et les politiques basées sur les ressources délèguent l'accès entre les comptes uniquement au sein d'une même partition. Par exemple, vous avez un compte dans la région USA Ouest (Californie du Nord) dans la partition aws standard. Vous avez également un compte dans la région Chine dans la partition aws-cn. Vous ne pouvez pas utiliser une politique basée sur les ressources dans votre compte en Chine pour autoriser l'accès aux utilisateurs de votre compte standard AWS .
Accès intercompte à l'aide de rôles
Tous les AWS services ne prennent pas en charge les politiques basées sur les ressources. Pour ces services, vous pouvez utiliser des IAM rôles entre comptes afin de centraliser la gestion des autorisations lorsque vous fournissez un accès entre comptes à plusieurs services. Un rôle entre comptes IAM est un IAM rôle qui inclut une politique de confiance qui permet IAM aux principaux d'un autre AWS compte d'assumer ce rôle. En termes simples, vous pouvez créer un rôle dans un AWS compte qui délègue des autorisations spécifiques à un autre AWS compte.
Pour plus d'informations sur l'association d'une politique à une IAM identité, consultezGérer les IAM politiques.
Note
Lorsqu'un principal passe à un rôle pour utiliser temporairement les autorisations de ce rôle, il abandonne ses autorisations d'origine et reprend les autorisations attribuées au rôle qu'il a assumé.
Examinons le processus global tel qu'il s'applique aux logiciels APN partenaires qui doivent accéder à un compte client.
-
Le client crée un IAM rôle dans son propre compte avec une politique qui permet d'accéder aux ressources Amazon S3 dont le APN partenaire a besoin. Dans cet exemple, le nom du rôle est
APNPartner.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name" ] } ] } -
Le client précise ensuite que le rôle peut être assumé par le AWS compte du partenaire en fournissant l' Compte AWS identifiant du APN partenaire dans la politique de confiance relative au
APNPartnerrôle.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name" }, "Action": "sts:AssumeRole" } ] } -
Le client donne le nom de ressource Amazon (ARN) du rôle au APN partenaire. ARNIl s'agit du nom complet du rôle.
arn:aws:iam::APN-ACCOUNT-ID:role/APNPartnerNote
Nous vous recommandons d'utiliser un ID externe dans les situations à locataires multiples. Pour plus de détails, consultez Accès à des Comptes AWS sites appartenant à des tiers.
-
Lorsque le logiciel du APN partenaire doit accéder au compte du client, le AssumeRoleAPIlogiciel appelle le AWS Security Token Service titulaire ARN du rôle dans le compte du client. STSrenvoie un AWS identifiant temporaire qui permet au logiciel de faire son travail.
Pour un autre exemple de l'octroi d'un accès intercompte à l'aide de rôles, consultez Accès pour un IAM utilisateur à un autre utilisateur Compte AWS que vous possédez. Vous pouvez également suivre le tutoriel IAMtutoriel : déléguer l'accès entre des AWS comptes à l'aide des IAM rôles IAM.
Accès intercompte à l'aide de politiques basées sur les ressources
Lorsqu'un compte accède à une ressource par le biais d'un autre compte à l'aide d'une politique basée sur les ressources, le principal continue d'utiliser le compte approuvé sans devoir renoncer à ses autorisations au profit des autorisations du rôle. Autrement dit, le principal continue d'avoir accès aux ressources du compte approuvé tout en ayant accès à la ressource du compte d'approbation. Cela est utile pour les tâches de copie d'informations de ou vers la ressources partagée de l'autre compte.
Les principes que vous pouvez spécifier dans une politique basée sur les ressources incluent les comptes, les IAM utilisateurs, les utilisateurs fédérés, les IAM rôles, les sessions de rôles assumés ou les services. AWS Pour plus d'informations, consultez Spécification d'un principal.
Pour savoir si les principaux des comptes situés en dehors de votre zone d'approbation (organisation ou compte d'approbation) peuvent accéder à vos rôles et les assumer, consultez Identification des ressources partagées avec une entité externe.
La liste suivante inclut certains des AWS services qui prennent en charge les politiques basées sur les ressources. Pour obtenir une liste complète du nombre croissant de AWS services qui permettent d'associer des politiques d'autorisation aux ressources plutôt qu'aux principaux, consultez AWS des services qui fonctionnent avec IAM et recherchez les services dont la valeur est Oui dans la colonne Basé sur les ressources.
-
Compartiments Amazon S3 : la politique est attachée au compartiment, mais la politique contrôle l'accès au compartiment et aux objets qu'il contient. Pour plus d'informations, consultez les politiques relatives aux compartiments pour Amazon S3 dans le guide de l'utilisateur d'Amazon Simple Storage Service. Dans certains cas, il peut être préférable d'utiliser des rôles pour l'accès entre comptes à Amazon S3. Pour plus d’informations, veuillez consulter les exemples de démonstration dans le guide de l'utilisateur du service de stockage simple Amazon.
-
Rubriques relatives à Amazon Simple Notification Service (AmazonSNS) — Pour plus d'informations, consultez la section Exemples de cas relatifs SNS au contrôle d'accès Amazon dans le guide du développeur Amazon Simple Notification Service.
-
Files d'attente Amazon Simple Queue Service (AmazonSQS) — Pour plus d'informations, consultez l'annexe : The Access Policy Language in the Amazon Simple Queue Service Developer Guide.
Politiques basées sur les ressources pour déléguer les autorisations AWS
Si une ressource accorde des autorisations aux principaux de votre compte, vous pouvez ensuite déléguer ces autorisations à des IAM identités spécifiques. Les identités sont des utilisateurs, des groupes d'utilisateurs ou des rôles de votre compte. Vous déléguez des autorisations en attachant une politique à l'identité. Vous pouvez accorder autant d'autorisations que le compte propriétaire de la ressource le permet.
Important
En cas d'accès intercompte, un principal a besoin d'une Allow dans la politique d'identité intégrée et d'une politique basée sur les ressources.
Supposons qu'une politique basée sur une ressource accorde à tous les principaux de votre compte un accès administratif complet à une ressource. Vous pouvez ensuite déléguer l'accès complet, l'accès en lecture seule ou tout autre accès partiel aux principaux de votre compte. AWS Sinon, si la politique basée sur la ressource autorise uniquement les autorisations d'affichage de liste, vous pouvez déléguer uniquement ce type d'accès. Si vous essayez de déléguer davantage d'autorisations que n'en possède votre compte, l'accès de vos principaux restera limité à l'affichage de liste.
Pour plus d'informations sur la façon dont ces décisions sont prises, consultez Identification d'une demande autorisée ou refusée dans un compte.
Note
IAMles rôles et les politiques basées sur les ressources délèguent l'accès entre les comptes uniquement au sein d'une même partition. Par exemple, vous ne pouvez pas ajouter d'accès entre comptes entre un compte dans la partition aws standard et un compte dans la partition aws-cn.
Par exemple, supposons que vous gériez AccountA et AccountB. Dans AccountA, vous avez un compartiment Amazon S3 nommé BucketA.
-
Vous attachez une politique basée sur les ressources à
BucketAqui permet à tous les principaux de AccountB d'avoir un accès complet aux objets de votre compartiment. Ils peuvent créer, lire ou supprimer les objets de ce compartiment.{ "Version": "2012-10-17", "Statement": [ { "Sid": "PrincipalAccess", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::AccountB:root"}, "Action": "s3:*", "Resource": "arn:aws:s3:::BucketA/*" } ] }AccountA accorde à AccountB un accès complet à BucketA en désignant AccountB comme principal dans la politique basée sur les ressources. Par conséquent, AccountB est autorisé à effectuer toute action sur BucketA, et l'administrateur de AccountB peut déléguer l'accès à ses utilisateurs dans AccountB.
L'utilisateur root de AccountB dispose de toutes les autorisations accordées au compte. Par conséquent, l'utilisateur root a un accès complet à BucketA.
-
Dans AccountB, attachez une politique à l'IAMutilisateur nommé User2. Cette politique permet à l'utilisateur d'accéder en lecture seule aux objets de BucketA. Cela signifie que User2 peut afficher les objets, mais ne peut pas les créer, les modifier ou les supprimer.
{ "Version": "2012-10-17", "Statement": [ { "Effect" : "Allow", "Action" : [ "s3:Get*", "s3:List*" ], "Resource" : "arn:aws:s3:::BucketA/*" } ] }Le niveau d'accès maximal que AccountB peut déléguer est le niveau d'accès accordé au compte. Dans ce cas, la politique basée sur les ressources a accordé un accès complet à AccountB, mais User2 ne dispose que d'un accès en lecture seule.
L'administrateur de AccountB n'accorde pas l'accès à User1. Par défaut, les utilisateurs n'ont pas d'autorisations, sauf celles qui sont accordées explicitement, et ainsi User1 n'a pas accès à BucketA.
IAMévalue les autorisations d'un directeur au moment où celui-ci fait une demande. Si vous utilisez des caractères génériques (*) pour donner aux utilisateurs un accès complet à vos ressources, les principaux peuvent accéder à toutes les ressources auxquelles votre AWS compte a accès. Cela est vrai même pour les ressources que vous ajoutez ou auxquelles vous accédez après la création de la politique de l'utilisateur.
Dans l'exemple précédent, si AccountB avait attaché à User2 une politique permettant un accès complet à toutes les ressources de tous les comptes, User2 aurait automatiquement eu accès à toutes les ressources auxquelles AccountB a accès. Cela inclut l'accès à BucketA et l'accès à toutes les autres ressources accordé par les politiques basées sur les ressources dans AccountA.
Pour plus d'informations sur l'utilisation des rôles de manière plus complexe, comme accorder l'accès à des applications et des services, consultez Scénarios courants pour les IAM rôles.
Important
N'accordez l'accès qu'aux entités auxquelles vous faites confiance et accordez l'accès minimal nécessaire. Chaque fois que l'entité de confiance est un autre AWS compte, n'importe quel IAM mandant peut avoir accès à votre ressource. Le AWS compte sécurisé ne peut déléguer l'accès que dans la mesure où l'accès lui a été accordé ; il ne peut pas déléguer un accès supérieur à celui accordé au compte lui-même.
Pour plus d'informations sur les autorisations, les politiques et le langage de politique d'autorisation que vous utilisez pour écrire des politiques, consultez Gestion de l'accès aux AWS ressources.
