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. # Comment la logique du code d' AWS application évalue les demandes d'autorisation ou de refus d'accès Le code d' AWS exécution décide si une demande envoyée AWS doit être autorisée ou refusée. AWS évalue toutes les politiques applicables au contexte de la demande. Voici un résumé de la logique d'évaluation des AWS politiques. + Par défaut, toutes les demandes sont implicitement rejetées à l'exception de l' Utilisateur racine d'un compte AWS, qui dispose d'un accès complet. + Les demandes doivent être explicitement autorisées par une politique ou un ensemble de politiques suivant la logique d’évaluation ci-dessous pour être autorisées. + Un refus explicite remplace une autorisation explicite. L’évaluation de la politique peut varier selon que la demande concerne un seul compte ou plusieurs comptes. Pour plus d’informations sur la manière dont une décision d’évaluation de politique est prise pour un rôle IAM ou un utilisateur au sein d’un seul compte, consultez [Évaluation des politiques pour les demandes au sein d’un même compte](reference_policies_evaluation-logic_policy-eval-basics.md). Pour plus de détails sur la manière dont une décision d’évaluation des politiques est prise pour les demandes entre comptes, consultez [Logique d’évaluation des politiques intercomptes](reference_policies_evaluation-logic-cross-account.md). + **Deny evaluation** (Refuser l'évaluation) : par défaut, toutes les demandes sont refusées. Il s'agit d'un [refus implicite](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). Le code d' AWS application évalue toutes les politiques du compte qui s'appliquent à la demande. Il s'agit notamment AWS Organizations SCPs des politiques basées sur les ressources RCPs, des politiques basées sur l'identité, des limites d'autorisations IAM et des politiques de session. Dans toutes ces politiques, le code d'application recherche une instruction `Deny` (Refuser) qui s'applique à la demande. Ceci est appelé un [refus explicite](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). Si le code d’application trouve un refus explicite qui s’applique, il retourne la décision finale **Refuser**. S'il n'y a pas de refus explicite, l'évaluation du code d'application se poursuit. + **AWS Organizations RCPs**— Le code d'application évalue les politiques de contrôle AWS Organizations des ressources (RCPs) qui s'appliquent à la demande. RCPs s'appliquent aux ressources du compte auquel RCPs elles sont rattachées. Si le code d'exécution ne trouve aucune `Allow` déclaration applicable dans le RCPs, le code d'exécution renvoie une décision finale de **refus**. Notez qu'une politique AWS gérée appelée `RCPFullAWSAccess` est automatiquement créée et attachée à chaque entité de votre organisation, y compris à la racine, à chaque unité d'organisation et à quel Compte AWS moment elles RCPs sont activées. `RCPFullAWSAccess`ne peut pas être détaché, il y aura donc toujours une `Allow` déclaration. S’il n’y a pas de RCP, ou si la RCP autorise l’action demandée, l’évaluation du code d’application se poursuit. + **AWS Organizations SCPs**— Le code d'application évalue les politiques AWS Organizations de contrôle des services (SCPs) qui s'appliquent à la demande. SCPs s'appliquent au principal du compte auquel SCPs ils sont rattachés. Si le code d'exécution ne trouve aucune `Allow` déclaration applicable dans le SCPs, le code d'exécution renvoie une décision finale de **refus**. S'il n'y a pas de SCP, ou si la SCP autorise l'action demandée, l'évaluation du code d'exécution se poursuit. + **Politiques basées sur les ressources** – Au sein d'un même compte, les politiques basées sur les ressources influencent l'évaluation des politiques différemment selon le type de principal accédant à la ressource et le principal autorisé dans la politique basée sur les ressources. Selon le type de principal, un `Allow` dans une politique basée sur les ressources peut aboutir à une décision finale de `Allow`, même si un rejet implicite dans une politique basée sur une identité, une limite d'autorisations ou une politique de séance est présente. Pour la plupart des ressources, vous n’avez besoin d’une `Allow` explicite pour le principal que dans une politique basée sur l’identité ou dans une politique basée sur les ressources pour accorder l’accès. Les [politiques de confiance des rôles IAM](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies) et [politiques de clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) sont des exceptions à cette logique, car ils doivent explicitement autoriser l'accès pour les [principaux](reference_policies_elements_principal.md). Les politiques basées sur les ressources pour les services autres qu’IAM et AWS KMS peuvent également nécessiter une instruction `Allow` explicite dans le même compte pour accorder l’accès. Pour plus d’informations, consultez la documentation service spécifique avec lequel vous travaillez. Pour les demandes d’évaluation de politiques à compte unique, la logique des politiques basées sur les ressources diffère des autres types de politiques si le principal spécifié est un utilisateur IAM, un rôle IAM ou un principal de session. Les principaux de session incluent les [sessions de rôle IAM](reference_policies_elements_principal.md#principal-role-session) ou des [principaux d’utilisateur fédéréAWS STS](reference_policies_elements_principal.md#sts-session-principals). Si une politique basée sur les ressources accorde des autorisations directement à l'utilisateur IAM ou au principal de séance qui fait la demande, un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance n'a pas d'incidence sur la décision finale. + **Rôle IAM** – Les politiques basées sur les ressources qui accordent des autorisations à un ARN de rôle IAM sont limitées par un rejet implicite dans une limite d'autorisations ou une politique de séance. Vous pouvez spécifier l’ARN du rôle dans l’élément Principal ou dans la clé de condition `aws:PrincipalArn`. Dans les deux cas, le principal qui fait la demande est la **session de rôle IAM**. Les limites de permissions et les politiques de session ne limitent pas les permissions accordées à l’aide de la clé de condition `aws:PrincipalArn` avec un caractère générique (\$1) dans l’élément Principal, sauf si les politiques basées sur l’identité contiennent un refus explicite. Pour de plus amples informations, veuillez consulter [Principaux de rôles IAM](reference_policies_elements_principal.md#principal-roles). **Exemple d'ARN de rôle** ``` arn:aws:iam::111122223333:role/examplerole ``` + **Rôle IAM** – Au sein du même compte, les politiques basées sur les ressources qui accordent des autorisations à un ARN de séance de rôle IAM accordent des autorisations directement à la séance de rôle supposée. Les autorisations accordées directement à une séance ne sont pas limitées par un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance. Lorsque vous endossez un rôle et faites une demande, le principal qui fait la demande est l'ARN de séance du rôle IAM et non l'ARN du rôle lui-même. Pour de plus amples informations, veuillez consulter [Principaux de séance de rôle](reference_policies_elements_principal.md#principal-role-session). **Exemple d'ARN de séance de rôle** ``` arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname ``` + **Utilisateur IAM** – Au sein du même compte, les politiques basées sur les ressources qui accordent des autorisations à un ARN d'utilisateur IAM (qui n'est pas une séance d'utilisateur fédérée) ne sont pas limitées par un rejet implicite d'une politique basée sur l'identité ou d'une limite d'autorisations. **Exemple d'ARN d'utilisateur IAM** ``` arn:aws:iam::111122223333:user/exampleuser ``` + **AWS STS utilisateur principal fédéré** — Une session utilisateur fédérée est une session créée par un appel. [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken) Lorsqu'un utilisateur fédéré fait une demande, le principal qui effectue la demande est l'ARN d'utilisateur fédéré et non l'ARN de l'utilisateur IAM qui a fédéré. Dans le même compte, les politiques basées sur les ressources accordant des autorisations à un ARN d'utilisateur fédéré accordent des autorisations directement à la séance. Les autorisations accordées directement à une séance ne sont pas limitées par un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance. Cependant, si une politique basée sur les ressources accorde une autorisation à l'ARN de l'utilisateur IAM qui s'est fédéré, les demandes faites par l'utilisateur fédéré pendant la séance sont limitées par un rejet implicite dans une limite d'autorisation ou une politique de séance. **Exemple d’ARN de session d’utilisateur fédérée** ``` arn:aws:sts::111122223333:federated-user/exampleuser ``` + **Politiques basées sur l’identité** : le code d’application vérifie les politiques basées sur l’identité pour le principal. Pour un utilisateur IAM, cela comprend notamment les politiques d'utilisateur et les politiques de groupes auxquels l'utilisateur appartient. Si aucune politique basée sur l’identité ou aucune instruction dans les politiques basées sur l’identité n’autorise l’action demandée, alors la demande est implicitement refusée et le code d’application renvoie une décision finale **Refuser**. Si une instruction dans n’importe quelle politique basée sur l’identité applicable autorise l’action demandée, le code d’évaluation continue. + **Limite des autorisations IAM** : le code d’application vérifie si l’entité IAM utilisée par le principal possède une limite d’autorisations. Si la politique qui est utilisée pour définir la limite d'autorisations n'autorise pas l'action demandée, la demande est implicitement refusée. Le code d'application retourne la décision finale **Deny** (Refuser). S’il n’y a pas de limite d’autorisations, ou si la limite d’autorisations autorise l’action demandée, le code d’évaluation continue. + **Politiques de session** : le code d’application vérifie si le principal est un principal de session. Les principes de session incluent une session de rôle IAM ou une session utilisateur AWS STS fédérée. Si le principal n'est pas un principal de séance, le code d'application renvoie une décision finale d'**autorisation**. Pour les principaux de séance, le code d’application vérifie si une politique de séance a été transmise dans la demande. Vous pouvez transmettre une politique de session lorsque vous utilisez l' AWS API AWS CLI or pour obtenir des informations d'identification temporaires pour un rôle ou un utilisateur principal AWS STS fédéré. Si vous n’avez pas adopté de politique de session, une politique de session par défaut est créée et le code d’application renvoie la décision finale **Autoriser**. + Si une politique de session est présente et n'autorise pas l'action demandée, la demande est implicitement refusée. Le code d'application retourne la décision finale **Deny** (Refuser). + Le code d’application vérifie si le principal est une session de rôle. Si le principal est une session de rôle, la demande est **autorisée**. Sinon, la demande est implicitement rejetée et le code d’application renvoie une décision finale **Refuser**. + Si une politique de séance est présente et autorise l'action demandée, le code d'exécution renvoie une décision finale **d'autorisation**. # Évaluation des politiques pour les demandes au sein d’un même compte ## Évaluation des politiques pour un rôle IAM Le diagramme suivant fournit des détails sur la manière dont une décision d’évaluation de politique est prise pour un rôle IAM au sein d’un compte unique. ![\[Organigramme d’évaluation d’un rôle IAM au sein d’un compte unique\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png) ## Évaluation des politiques pour un utilisateur IAM Le diagramme suivant fournit des détails sur la manière dont une décision d’évaluation de politique est prise pour un utilisateur IAM au sein d’un compte unique. ![\[Organigramme d’évaluation d’un utilisateur IAM au sein d’un compte unique\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png) ## Exemple d'évaluation de politique basée sur l'identité et sur les ressources Les types de politiques les plus courants sont celles basées sur l'identité et les ressources. Lorsque l'accès à une ressource est demandé, AWS évalue toutes les autorisations accordées par les politiques pour **au moins une autorisation au sein** du même compte. Un rejet explicite dans l'une de ces politiques remplace l'autorisation. **Important** Si la politique basée sur les identités ou celle basée sur les ressources dans le même compte autorise la demande et que l'autre ne l'autorise pas, la demande reste autorisée. Supposons que le nom d'utilisateur de Carlos soit `carlossalazar` et que ce dernier essaie d'enregistrer un fichier dans le compartiment Amazon S3 `amzn-s3-demo-bucket-carlossalazar-logs`. Supposons également que la politique suivante soit attachée à l'utilisateur IAM `carlossalazar`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*log*" } ] } ``` ------ L'instruction `AllowS3ListRead` de cette politique autorise Carlos à afficher une liste de tous les compartiments du compte. L'instruction `AllowS3Self` accorde à Carlos un accès total au compartiment du même nom que son nom d'utilisateur. L'instruction `DenyS3Logs` refuse à Carlos l'accès à n'importe quel compartiment S3 comprenant `log` dans son nom. De plus, la politique basée sur les ressources suivante (appelée politique de compartiment) est attachée au compartiment `amzn-s3-demo-bucket-carlossalazar`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/carlossalazar" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] } ] } ``` ------ Cette politique spécifie que seul l'utilisateur `carlossalazar` peut accéder au compartiment `amzn-s3-demo-bucket-carlossalazar`. Lorsque Carlos demande l'enregistrement d'un fichier dans le `amzn-s3-demo-bucket-carlossalazar-logs` bucket, il AWS détermine les politiques qui s'appliquent à la demande. Dans ce cas, seule les politiques basées sur l'identité et les ressources s'appliquent. Il s'agit de deux politiques d'autorisations. La logique d'évaluation est réduite à la logique suivante, car aucune limite d'autorisations ne s'applique. ![\[Diagramme d'évaluation\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/EffectivePermissionsShort.png) AWS vérifie d'abord si une `Deny` déclaration s'applique au contexte de la demande. Il en trouve une, car la politique basée sur l'identité refuse explicitement à Carlos l'accès à n'importe quel compartiment S3 utilisé pour la journalisation. Carlos se voit refuser l'accès. Supposons qu'il se rende compte de son erreur et essaie d'enregistrer le fichier dans le `amzn-s3-demo-bucket-carlossalazar` bucket. AWS recherche une `Deny` déclaration et n'en trouve aucune. Ensuite, il vérifie les politiques d'autorisations. La politique basée sur l'identité et celle basée sur les ressources autorisent la demande. AWS Autorise donc la demande. Si l'un d'entre eux refuse explicitement l'instruction, alors la demande est refusée. Si l'un des types de politique autorise la demande et que l'autre ne l'autorise pas, la demande reste autorisée. # Logique d’évaluation des politiques intercomptes 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, ses utilisateurs principaux AWS STS fédérés, ses rôles IAM ou ses sessions à rôles assumés. Vous pouvez également spécifier un AWS service en tant que principal. Pour de plus amples informations, veuillez consulter [Comment spécifier un principal](reference_policies_elements_principal.md#Principal_specifying). La politique basée sur l'identité du principal doit permettre l'accès demandé à la ressource dans le service d'approbation. Vous pouvez le faire en spécifiant l’ARN de la ressource. 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](access_policies-cross-account-resource-access.md). **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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) et [les politiques de contrôle des ressources](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) qui peuvent être appliquées aux principaux et aux ressources d'un ou de plusieurs comptes. AWS Resource Access Manager prend en charge les [fragments de politique](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html) 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 faites une demande entre comptes, AWS effectue deux évaluations. AWS évalue la demande dans le compte de confiance et le compte de confiance. Pour de plus amples informations sur la façon dont une demande est évaluée au sein d'un seul compte, veuillez consulter [Comment la logique du code d' AWS application évalue les demandes d'autorisation ou de refus d'accès](reference_policies_evaluation-logic_policy-eval-denyallow.md). La demande n'est autorisée que si les deux évaluations renvoient une décision `Allow`. ![\[Évaluation entre comptes\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png) 1. 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. 1. 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 de plus amples informations, veuillez consulter [Évaluation des politiques basées sur l'identité avec des limites d'autorisations](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound). 1. 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 de plus amples informations, veuillez consulter [Évaluation des politiques basées sur l'identité avec des politiques basées sur des ressources](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp). 1. AWS autorise la demande uniquement si les deux évaluations de la politique du compte autorisent la demande. Le diagramme suivant illustre plus en détail comment une décision d’évaluation de politique est prise pour une demande entre comptes. Encore une fois, AWS autorise la demande uniquement si les deux évaluations de la politique du compte l'autorisent. ![\[Évaluation détaillée de la politique entre comptes\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png) ## Exemple d'évaluation de politique entre comptes L’exemple suivant illustre un scénario dans lequel un rôle 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 du rôle IAM est `Demo` dans le compte 111111111111. Il veut enregistrer un fichier dans le compartiment Amazon S3 `amzn-s3-demo-bucket-production-logs` du compte 222222222222. Supposons également que la politique suivante soit attachée au rôle IAM `Demo`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "AllowS3ProductionObjectActions", "Effect": "Allow", "Action": "s3:*Object*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-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 `amzn-s3-demo-bucket-production`. De plus, la politique basée sur les ressources suivante (appelée politique de compartiment) est attachée au compartiment `amzn-s3-demo-bucket-production` dans le compte 222222222222. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject*", "s3:ReplicateObject", "s3:RestoreObject" ], "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" }, "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" } ] } ``` ------ Cette politique permet au rôle `Demo` d’accéder aux objets du compartiment `amzn-s3-demo-bucket-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 demande l'enregistrement d'un fichier dans le `amzn-s3-demo-bucket-production-logs` bucket, il AWS détermine les politiques qui s'appliquent à la demande. Dans ce cas, la politique basée sur l’identité associée au rôle `Demo` 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 `amzn-s3-demo-bucket-production-logs`. Lors de AWS l'évaluation du compte`111111111111`, il renvoie une décision de`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 [Comment la logique du code d' AWS application évalue les demandes d'autorisation ou de refus d'accès](reference_policies_evaluation-logic_policy-eval-denyallow.md). Étant donné que la demande est explicitement refusée dans l'un des comptes, la décision finale est de refuser la demande. ![\[Demande adressée au bucket amzn-s3- demo-bucket-production-logs\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png) Supposons que Carlos réalise alors son erreur et essaie d'enregistrer le fichier dans le `Production` bucket. AWS vérifie d'abord `111111111111` le compte pour déterminer si la demande est autorisée. Seule la politique basée sur l'identité s'applique et autorise la demande. AWS puis vérifie 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. ![\[Demande adressée au compartiment Production\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)