Accès intercompte aux ressources dans IAM

Pour certains services AWS, vous pouvez accorder un accès intercompte à vos ressources à l'aide d'IAM. 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

Les politiques IAM basées sur les ressources et les rôles ne délèguent l'accès entre les comptes qu'au sein d'une seule 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 dans la région Chine pour autoriser l'accès aux utilisateurs de votre compte AWS standard.

Accès intercompte à l'aide de rôles

Certains services AWS prennent en charge les politiques basées sur les ressources. Pour ces services, vous pouvez utiliser des rôles IAM intercomptes afin de centraliser la gestion des autorisations lorsque vous fournissez un accès intercompte à plusieurs services. Un rôle IAM intercompte est un rôle IAM qui inclut une politique d'approbation qui permet aux principaux IAM d'un autre compte AWS d'assumer ce rôle. En bref, vous pouvez créer un rôle dans un compte AWS qui délègue des autorisations spécifiques à un autre compte AWS.

Pour de plus amples informations sur l'attachement d'une politique à une identité IAM, veuillez consulter Gestion des politiques IAM.

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 au logiciel du partenaire APN qui doit accéder à un compte client.

1. Le client crée un rôle IAM dans son propre compte avec une politique qui autorise l'accès aux ressources Amazon S3 dont le partenaire APN 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"
               ]
           }
       ]
   }

2. Le client précise ensuite que le rôle peut être endossé par le compte AWS du partenaire en fournissant l'ID d'Compte AWS du partenaire APN dans la politique d'approbation du rôle APNPartner.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name"
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }

3. Le client donne l'Amazon Resource Name (ARN) du rôle au partenaire APN. L'ARN est le nom entièrement qualifié du rôle.

   arn:aws:iam::APN-ACCOUNT-ID:role/APNPartner

   Note

   Nous vous recommandons d'utiliser un ID externe dans les situations à locataires multiples. Pour plus de détails, veuillez consulter Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos ressources AWS à un tiers.

4. Lorsque le logiciel du partenaire APN doit accéder au compte du client, le logiciel appelle l'API AssumeRole dans AWS Security Token Service avec l'ARN du rôle dans le compte du client. STS renvoie des informations d'identification AWS temporaires qui permettent au logiciel de faire son travail.

Pour un autre exemple de l'octroi d'un accès intercompte à l'aide de rôles, consultez Octroyer l'accès à un utilisateur IAM dans un autre Compte AWS vous appartenant. Vous pouvez également suivre le tutoriel Didacticiel IAM : déléguer l'accès entre des comptes AWS à l'aide des 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 principaux que vous pouvez spécifier dans une politique basée sur une ressource comprennent les comptes, les utilisateurs IAM, les utilisateurs fédérés, les rôles IAM, les sessions de rôle endossé 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 services AWS prenant en charge les politiques basées sur une ressource. Pour obtenir une liste complète du nombre croissant de services AWS prenant en charge l'attachement de stratégie d'autorisations aux ressources au lieu des principaux, consultez AWS services qui fonctionnent avec IAM et recherchez les services pour lesquels Oui figure dans la colonne Resource Based (Basé sur une ressource).

• 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, veuillez consulter contrôle d'accès dans le guide de l'utilisateur du service de stockage simple Amazon. 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 Amazon Simple Notification Service (Amazon SNS) : pour plus d'informations, consultez Cas d'exemple pour le contrôle d'accès Amazon SNS dans le Guide du développeur Amazon Simple Notification Service.

• Files d'attente Amazon Simple Queue Service (Amazon SQS) : pour de plus amples informations, veuillez consulter Annexe : langage de la politique d'accès dans le Manuel du développeur Amazon Simple Queue Service.

Délégation d'autorisations AWS dans une politique basée sur les ressources

Si une ressource accorde des autorisations aux principaux de votre compte, vous pouvez alors déléguer ces autorisations à des identités IAM 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 un accès complet, un 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

Les politiques IAM basées sur les ressources et les rôles ne délèguent l'accès entre les comptes qu'au sein d'une seule 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.

1. Vous attachez une politique basée sur les ressources à BucketA qui 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.

2. Dans AccountB, attachez une politique à l'utilisateur IAM 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 principal au moment où il 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 compte AWS 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 rôles : utilisateurs, applications et services.

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é approuvée est un autre compte AWS, tout principal IAM peut se voir accorder l'accès à votre ressource. Le compte AWS approuvé peut déléguer uniquement l'accès dont il bénéficie. Il ne peut pas déléguer plus d'accès que le compte n'en a 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 pour les ressources AWS.