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.
Logique d'évaluation des politiques entre comptes
Vous pouvez autoriser un principal d'un compte à accéder aux ressources d'un second compte. C'est ce que l'on appelle l'accès entre comptes. Lorsque vous autorisez un accès entre comptes, le compte dans lequel se trouve le principal est appelé compte approuvé. Le compte dans lequel se trouve la ressource est le compte d'approbation.
Pour autoriser l'accès entre comptes, vous associez une politique basée sur les ressources à la ressource que vous souhaitez partager. Vous devez également attacher une politique basée sur l'identité à l'identité qui fait office de principal dans la demande. La politique basée sur les ressources dans le compte d'approbation doit spécifier le principal du compte approuvé qui aura accès à la ressource. Vous pouvez spécifier l'intégralité du compte ou ses utilisateurs IAM, les utilisateurs fédérés, les rôles IAM ou les sessions à rôles endossés. Vous pouvez également spécifier un service AWS en tant que principal. Pour plus d’informations, veuillez consulter Spécification d'un principal.
La politique basée sur l'identité du principal doit permettre l'accès demandé à la ressource dans le service d'approbation. Vous pouvez aboutir à cela en spécifiant l'ARN de la ressource ou en autorisant l'accès à toutes les ressources (*).
Dans IAM, vous pouvez associer une politique basée sur les ressources à un rôle IAM pour permettre aux principaux d'autres comptes d'endosser ce rôle. La politique basée sur les ressources du rôle est appelée politique d'approbation de rôle. Une fois qu'ils endossent ce rôle, les principaux autorisés peuvent utiliser les informations d'identification temporaires résultantes pour accéder à plusieurs ressources de votre compte. Cet accès est défini dans la politique d'autorisations basée sur l'identité du rôle. Pour connaître les différences entre l'autorisation d'accès entre comptes à l'aide de rôles et l'autorisation d'accès entre comptes à l'aide d'autres politiques basées sur les ressources, veuillez consulter Accès intercompte aux ressources dans IAM.
Important
D'autres services peuvent influer sur la logique d'évaluation des politiques. Par exemple, AWS Organizations prend en charge les politiques de contrôle des services qui peuvent être appliquées aux principaux d'un ou plusieurs comptes. AWS Resource Access Manager prend en charge les fragments de politique qui contrôlent les actions que les principaux sont autorisés à effectuer sur les ressources partagées avec eux.
Comment déterminer si une demande d'accès entre comptes est autorisée
Pour les demandes entre comptes, le demandeur du compte approuvé AccountA doit avoir une politique basée sur l'identité. Cette politique doit lui permettre de faire une demande à la ressource du compte d'approbation AccountB. En outre, la politique basée sur les ressources du compte AccountB doit autoriser le demandeur du compte AccountA à accéder à la ressource.
Lorsque vous effectuez une demande d'accès entre comptes, AWS effectue deux évaluations. AWS évalue la demande dans le compte d'approbation et dans le compte approuvé. Pour de plus amples informations sur la façon dont une demande est évaluée au sein d'un seul compte, veuillez consulter Identification d'une demande autorisée ou refusée dans un compte. La demande n'est autorisée que si les deux évaluations renvoient une décision Allow.
-
Lorsqu'un principal d'un compte fait une demande d'accès à une ressource d'un autre compte, il s'agit d'une demande entre comptes.
-
Le principal demandeur se trouve dans le compte approuvé (
AccountA). Lorsque AWS évalue ce compte, il vérifie la politique basée sur l'identité et toutes les politiques pouvant limiter une politique basée sur l'identité. Pour plus d’informations, veuillez consulter Évaluation des politiques dans un compte unique. -
La ressource demandée se trouve dans le compte d'approbation (
AccountB). Lorsque AWS évalue ce compte, il vérifie la politique basée sur les ressources qui est associée à la ressource demandée et toutes les politiques pouvant limiter une politique basée sur les ressources. Pour plus d’informations, veuillez consulter Évaluation des politiques dans un compte unique. -
AWS n'autorise la demande que si les deux évaluations de politique de compte autorisent la demande.
Exemple d'évaluation de politique entre comptes
L'exemple suivant illustre un scénario dans lequel un utilisateur d'un compte se voit accorder des autorisations par une politique basée sur les ressources dans un second compte.
Supposons que Carlos est un développeur dont le nom d'utilisateur IAM est carlossalazar dans le compte 111111111111. Il veut enregistrer un fichier dans le compartiment Amazon S3 Production-logs du compte 222222222222.
Supposons également que la politique suivante soit attachée à l'utilisateur IAM carlossalazar.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "AllowS3ProductionObjectActions", "Effect": "Allow", "Action": "s3:*Object*", "Resource": "arn:aws:s3:::Production/*" }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] }
L'instruction AllowS3ListRead de cette politique autorise Carlos à afficher une liste de tous les compartiments dans Amazon S3. L'instruction AllowS3ProductionObjectActions offre à Carlos un accès complet aux objets dans le compartiment Production. L'instruction DenyS3Logs refuse à Carlos l'accès à n'importe quel compartiment S3 comprenant log dans son nom. Elle refuse également l'accès à tous les objets de ces compartiments.
De plus, la politique basée sur les ressources suivante (appelée politique de compartiment) est attachée au compartiment Production dans le compte 222222222222.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject*", "s3:ReplicateObject", "s3:RestoreObject" ], "Principal": { "AWS": "arn:aws:iam::111111111111:user/carlossalazar" }, "Resource": "arn:aws:s3:::Production/*" } ] }
Cette politique permet à l'utilisateur carlossalazar d'accéder aux objets du compartiment Production. Il peut créer et éditer, mais pas supprimer les objets dans le compartiment. Il ne peut pas gérer le compartiment lui-même.
Lorsque Carlos effectue une demande d'enregistrement d'un fichier dans le compartiment Production-logs, AWS détermine les stratégies qui s'appliquent à la demande. Dans ce cas, la politique basée sur l'identité associée à l'utilisateur carlossalazar est la seule politique qui s'applique dans le compte 111111111111. Dans le compte 222222222222, il n'y a pas de politique basée sur les ressources associée au compartiment Production-logs. Lorsque AWS évalue le compte 111111111111, il renvoie une décision Deny. En effet, l'instruction DenyS3Logs de la politique basée sur l'identité refuse explicitement l'accès à tous les compartiments de journaux. Pour de plus amples informations sur la façon dont une demande est évaluée au sein d'un seul compte, veuillez consulter Identification d'une demande autorisée ou refusée dans un compte.
Étant donné que la demande est explicitement refusée dans l'un des comptes, la décision finale est de refuser la demande.
Supposons que Carlos réalise alors son erreur et essaie d'enregistrer le fichier dans le compartiment Production. AWS vérifie d'abord le compte 111111111111 pour déterminer si la demande est autorisée. Seule la politique basée sur l'identité s'applique et elle autorise la demande. AWS vérifie ensuite le compte 222222222222. Seule la politique basée sur les ressources associée au compartiment Production s'applique et elle autorise la demande. Étant donné que les deux comptes autorisent la demande, la décision finale est d'autoriser la demande.
