# AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法
AWS エンフォースメントコードは、AWS に送信されるリクエストを許可するか拒否するかどうかを決定します。AWS は、リクエストコンテキストに適用されるすべてのポリシーを評価します。AWS ポリシー評価ロジックの概要を次に示します。
+ デフォルトでは、フルアクセスを持つ AWS アカウントのルートユーザー 以外は、すべてのリクエストが暗示的に拒否されます。
+ リクエストが許可されるには、以下の評価ロジックに従って、ポリシー、または一連のポリシーによって明示的に許可される必要があります。
+ 明示的な拒否は明示的な許可をオーバーライドします。
ポリシーの評価は、リクエストが 1 つのアカウント内にあるか、クロスアカウントリクエスト内にあるかによって異なる場合があります。単一のアカウント内の IAM ロールまたはユーザーに対してポリシー評価の決定を行う方法の詳細については、「[単一のアカウント内のリクエストのポリシー評価](reference_policies_evaluation-logic_policy-eval-basics.md)」を参照してください。クロスアカウントリクエストのポリシー評価判定方法の詳細については、「[クロスアカウントポリシーの評価論理](reference_policies_evaluation-logic-cross-account.md)」を参照してください。
+ **拒否の評価** – デフォルトでは、すべてのリクエストが拒否されます。これは[暗黙的な拒否](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)と呼ばれます。AWS エンフォースメントコードでは、リクエストに適用されるアカウント内のすべてのポリシーを評価します。このポリシータイプには、AWS Organizations SCP および RCP、リソースベースのポリシー、ID ベースのポリシー、IAM アクセス許可の境界、セッションポリシーなどがあります。エンフォースメントコードでは、すべての該当するポリシーでリクエストに適用される `Deny` ステートメントを探します。このプロセスは[明示的な拒否](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)と呼ばれています。エンフォースメントコードは、適用される明示的な拒否が 1 つでも見つかると、**Deny** の最終決定を返します。明示的な拒否がない場合は、エンフォースメントコードの評価は続行されます。
+ **AWS Organizations RCP** – エンフォースメントコードは、リクエストに適用される AWS Organizations リソースコントロールポリシー (RCP) を評価します。RCP は、RCP がアタッチされているアカウントのリソースに適用されます。エンフォースメントコードが RCP で該当する `Allow` ステートメントを見つけられない場合、エンフォースメントコードは **Deny** の最終決定を返します。RCP が有効化されると、`RCPFullAWSAccess` という AWS マネージドポリシーが自動的に作成され、ルート、各 OU、AWS アカウント を含む組織内のすべてのエンティティにアタッチされることに注意してください。 `RCPFullAWSAccess` はデタッチできないため、常に `Allow` ステートメントになります。RCP がない場合、または RCP により、リクエストされたアクションが許可された場合は、エンフォースメントコードの評価が続行されます。
+ **AWS Organizations SCP** - エンフォースメントコードは、リクエストに適用する AWS Organizations サービスコントロールポリシー (SCP) を評価します。SCP は、SCP がアタッチされているアカウントのプリンシパルに適用されます。エンフォースメントコードが SCP で該当する `Allow` ステートメントを見つけられない場合、エンフォースメントコードは **Deny** の最終決定を返します。SCP がない場合、または SCP により、リクエストされたアクションが許可された場合は、エンフォースメントコードが続行されます。
+ **リソースベースのポリシー** - 同じアカウント内でも、リソースにアクセスするプリンシパルのタイプと、リソースベースのポリシーで許可されるプリンシパルに応じて、リソースベースのポリシーはポリシーの評価に異なる影響を与えます。リソースベースのポリシーの `Allow` は、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーに潜在的な拒否があったとしても、プリンシパルのタイプに応じて最終的には `Allow` に決定されます。
ほとんどのリソースの場合、アクセスを付与するために必要なのは、ID ベースのポリシーまたはリソースベースのポリシーのいずれかにおけるプリンシパルのための明示的な `Allow` のみです。[IAM ロール信頼ポリシー](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies)と [KMS キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)は、[プリンシパル](reference_policies_elements_principal.md)へのアクセスを明示的に許可する必要があるため、このロジックの例外です。IAM および AWS KMS 以外のサービスのリソースベースのポリシーでは、アクセスを許可するために同じアカウント内の明示的な `Allow` ステートメントが必要になる場合もあります。詳細については、ご使用している特定のサービスのドキュメントを参照してください。
単一アカウントポリシーの評価リクエストでは、指定されたプリンシパルが IAM ユーザー、IAM ロール、またはセッションプリンシパルである場合、リソースベースのポリシーのロジックは他のポリシータイプとは異なります。セッションプリンシパルには、[IAM ロールセッション](reference_policies_elements_principal.md#principal-role-session)または[AWS STS フェデレーションユーザーのプリンシパル](reference_policies_elements_principal.md#sts-session-principals)が含まれます。リソースベースのポリシーが、リクエストを作成している IAM ユーザーまたはセッションプリンシパルに直接アクセス許可を付与する場合、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーで暗黙的な拒否が最終的な決定に影響を与えることはありません。
+ **IAM ロール**— IAM ロール ARN にアクセス許可を与えるリソースベースのポリシーは、アクセス許可の境界またはセッションポリシーの暗黙的な拒否によって制限されます。ロール ARN はプリンシパル要素または `aws:PrincipalArn` 条件キーで指定できます。どちらの場合も、リクエストを行うプリンシパルは **IAM ロールセッション**です。
アイデンティティベースのポリシーに明示的な拒否が含まれている場合を除き、アクセス許可の境界とセッションポリシーは、プリンシパル要素で、ワイルドカード (\$1) を含む `aws:PrincipalArn` 条件キーを使用して付与されたアクセス許可を制限することはありません。詳細については、「[IAM ロールプリンシパル](reference_policies_elements_principal.md#principal-roles)」を参照してください。
**ロール ARN の例**
```
arn:aws:iam::111122223333:role/examplerole
```
+ **IAM ロールセッション** — 同じアカウント内で、IAM ロールセッション ARN にアクセス許可を与えるリソースベースのポリシーは、引き受けたロールセッションに、直接アクセス許可を与えます。セッションに直接付与されるアクセス許可は、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーの暗黙的な拒否によって制限されません。ロールを引き受けてリクエストを行う場合、リクエストを行うプリンシパルは IAM ロールセッション ARN であり、ロールそれ自体の ARN ではありません。詳細については、「[ロールセッションプリンシパル](reference_policies_elements_principal.md#principal-role-session)」を参照してください。
**ロールセッション ARN の例**
```
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
```
+ **IAM ユーザー** — 同じアカウント内では、IAM ユーザー ARN (フェデレーティッドユーザーセッションではない) へのアクセス許可を与えているリソースベースのポリシーは、ID ベースのポリシーまたはアクセス許可の境界による、暗黙的な拒否によって制限されません。
**IAM ユーザー ARNの例**
```
arn:aws:iam::111122223333:user/exampleuser
```
+ **AWS STS フェデレーションユーザーのプリンシパル** – フェデレーションユーザーのセッションは、[`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken) を呼び出すことで作成されるセッションです。フェデレーティッドユーザーがリクエストを行う場合、リクエストを行うプリンシパルはフェデレーティッドユーザー ARN であり、フェデレーションした IAM ユーザーの ARN ではありません。同じアカウント内で、フェデレーティッドユーザー ARN にアクセス許可を与えるリソースベースのポリシーは、セッションに直接アクセス許可を与えます。セッションに直接付与されるアクセス許可は、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーの暗黙的な拒否によって制限されません。
ただし、リソースベースのポリシーがフェデレーションした IAM ユーザーの ARN にアクセス許可を与える場合、セッション中にフェデレーティッドユーザーによって行われたリクエストは、アクセス許可の境界またはセッションポリシーの、暗黙的な拒否によって制限されます。
**フェデレーションユーザーのセッション ARN の例**
```
arn:aws:sts::111122223333:federated-user/exampleuser
```
+ **ID ベースのポリシー** – エンフォースメントコードは、プリンシパルのID ベースのポリシーをチェックします。IAM ユーザーの場合は、ユーザーポリシーや、ユーザーが属するグループのポリシーが含まれます。ID ベースのポリシーが無いか、ID ベースのポリシーにリクエストされたアクションを許可するステートメントがない場合、そのリクエストは暗黙的に拒否され、エンフォースメントコードは **Deny** の最終決定を返します。該当する ID ベースのポリシーのステートメントで、リクエストされたアクションが許可されている場合、コードの評価は続行されます。
+ **IAM アクセス許可の境界** – エンフォースメントコードは、プリンシパルによって使用されている IAM エンティティにアクセス許可の境界があるかどうかをチェックします。アクセス許可の境界の設定に使用されているポリシーで、リクエストされたアクションが許可されていない場合、リクエストは明示的に拒否されます。エンフォースメントコードにより、**拒否**の最終決定が返ります。アクセス許可の境界がない場合、またはアクセス許可の境界で、リクエストされたアクションが許可されている場合、コードの評価は続行されます。
+ **セッションポリシー** – エンフォースメントコードは、プリンシパルがセッションプリンシパルかどうかをチェックします。セッションプリンシパルには、IAM ロールセッションまたは AWS STS フェデレーションユーザーのセッションが含まれます。プリンシパルがセッションプリンシパルでない場合、エンフォースメントコードは最終決定で**許可**を返します。
セッションプリンシパルの場合、エンフォースメントコードは、セッションポリシーがリクエストによって渡されたかどうかをチェックします。AWS CLI または AWS API を使用してロールまたは AWS STS フェデレーションユーザーのプリンシパルに一時的な認証情報を取得しながら、セッションポリシーを渡すことができます。セッションポリシーを渡さなかった場合、デフォルトのセッションポリシーが作成され、エンフォースメントコードは**許可**の最終決定を返します。
+ セッションポリシーが存在し、リクエストされたアクションが許可されていない場合、そのリクエストは暗示的に拒否されます。エンフォースメントコードにより、**拒否**の最終決定が返ります。
+ エンフォースメントコードは、プリンシパルがロールセッションであるかどうかをチェックします。プリンシパルがロールセッションだった場合、リクエストは**許可**になります。それ以外の場合は、リクエストは暗黙的に拒否され、エンフォースメントコードは最終決定で **Deny** を返します。
+ セッションポリシーが存在し、リクエストされたアクションが許可されている場合は、エンフォースメントコードは最終決定で**許可**を返します。
# 単一のアカウント内のリクエストのポリシー評価
## IAM ロールのポリシー評価
次のフローチャートは、単一のアカウント内の IAM ロールに対してポリシー評価の判定がどのように行われるかに関する詳細を示しています。
![\[単一アカウント内の IAM ロールの評価フローチャート\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png)
## IAM ユーザーのポリシー評価
次のフローチャートは、1 つのアカウント内の IAM ユーザーに対してポリシー評価の判定がどのように行われるかの詳細を示しています。
![\[単一アカウント内の IAM ユーザーの評価フローチャート\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png)
## アイデンティティベースのポリシーおよびリソースベースのポリシーの評価の例
最も一般的なポリシータイプは、アイデンティティベースのポリシーとリソースベースのポリシーです。リソースへのアクセスがリクエストされると、同じアカウント内の**少なくとも 1 つの許可**について、AWS はポリシーによって付与されたすべてのアクセス許可を評価します。これらのポリシーのいずれかが明示的に拒否された場合、許可は無効になります。
**重要**
同じアカウント内の ID ベースのポリシーまたはリソースベースのポリシーの一方がリクエストを許可し、他方が許可しない場合でも、リクエストは許可されます。
Carlos のユーザー名が `carlossalazar` で、ファイルを Amazon S3 バケット `amzn-s3-demo-bucket-carlossalazar-logs` に保存するとします。
また、次のポリシーを 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*"
}
]
}
```
------
このポリシーの `AllowS3ListRead` ステートメントでは、アカウント内のすべてのバケットを一覧表示することを Carlos に許可します。`AllowS3Self` ステートメントでは、Carlos のユーザー名と同じ名前のバケットに対するフルアクセスを Carlos に許可します。`DenyS3Logs` ステートメントでは、名前に `log` が含まれている S3 バケットへのアクセスを Carlos に拒否します。
さらに、次のリソースベースのポリシー (バケットポリシー) を `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"
]
}
]
}
```
------
このポリシーでは、`carlossalazar` ユーザーのみが `amzn-s3-demo-bucket-carlossalazar` バケットにアクセスできることを指定します。
Carlos がファイルを `amzn-s3-demo-bucket-carlossalazar-logs` バケットに保存することをリクエストすると、AWS はこのリクエストに適用されるポリシーを決定します。この例では、アイデンティティベースのポリシーとリソースベースのポリシーのみが適用されます。これらは両方ともアクセス許可ポリシーです。アクセス許可の境界は適用されないため、評価ロジックは次のロジックに限定されます。
![\[評価フローチャート\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/EffectivePermissionsShort.png)
AWS は、最初にリクエストのコンテキストに適用される `Deny` ステートメントの有無を確認します。アイデンティティベースのポリシーでは、Carlos に対してログ記録用の S3 バケットへのアクセスが明示的に拒否されるため、該当するステートメントが見つかります。Carlos はアクセスが拒否されます。
彼は間違いに気が付いて、ファイルを `amzn-s3-demo-bucket-carlossalazar` バケットに保存しようとします。AWS は `Deny` ステートメントを探しますが、1 つも見つかりません。次に、アクセス許可ポリシーを確認します。ID ベースのポリシーとリソースベースのポリシーの両方で、リクエストが許可されます。従って、AWS でリクエストが許可されます。どちらでもステートメントが明示的に拒否された場合、リクエストは拒否されます。いずれかのポリシータイプでリクエストが許可され、もう一方では許可されない場合でも、リクエストは許可されます。
# クロスアカウントポリシーの評価論理
1 つのアカウントのプリンシパルが別のアカウントのリソースにアクセスすることを許可できます。これはクロスアカウントアクセスと呼ばれます。クロスアカウントアクセスを許可する場合、プリンシパルが存在するアカウントを*信頼された*アカウントと呼びます。リソースが存在するアカウントは、*信頼する*アカウントです。
クロスアカウントアクセスを許可するには、共有するリソースにリソースベースのポリシーをアタッチします。また、リクエストのプリンシパルとして機能する ID に ID ベースポリシーをアタッチする必要があります。信頼するアカウントのリソースベースのポリシーは、リソースにアクセスできる信頼されるアカウントのプリンシパルを指定する必要があります。アカウント全体またはその IAM ユーザー、AWS STS フェデレーションユーザーのプリンシパル、IAM ロール、引き受けたロールセッションを指定することができます。AWS サービスをプリンシパルとして指定することもできます。詳細については、「[プリンシパルを指定する方法](reference_policies_elements_principal.md#Principal_specifying)」を参照してください。
プリンシパルの ID ベースのポリシーは、信頼するサービスにあるリソースへのリクエストされたアクセスを許可する必要があります。これを実行するには、リソースの ARN を指定します。
IAM では、リソースベースのポリシーをロールにアタッチして、他のアカウントのプリンシパルがその IAM ロールを引き受けることを許可できます。ロールのリソースベースのポリシーは、ロールの信頼ポリシーと呼ばれます。そのロールを引き受けると、許可されたプリンシパルは結果として生じる一時的な認証情報を使用して、アカウント内の複数のリソースにアクセスできます。このアクセスは、ロールの ID ベースのアクセス許可ポリシーで定義されます。ロールを使用したクロスアカウントアクセスの許可と、他のリソースベースのポリシーを使用したクロスアカウントアクセスの許可の違いについては、「[IAM でのクロスアカウントのリソースへのアクセス](access_policies-cross-account-resource-access.md)」を参照してください。
**重要**
ポリシー評価ロジックに影響を与えるサービスもあります。例えば、AWS Organizations は、1 つ以上のアカウントのプリンシパルとリソースに適用できる[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)と[リソースコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)をサポートします。AWS Resource Access Manager は、共有されているリソースに対してプリンシパルが実行できるアクションを制御する[ポリシーフラグメント](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html)をサポートします。
## クロスアカウントリクエストが許可されているかどうかを確認
クロスアカウントリクエストの場合、信頼済み `AccountA` のリクエスタには ID ベースのポリシーが必要です。このポリシーでは、信頼する `AccountB` のリソースへのリクエストを許可する必要があります。また、`AccountB` のリソースベースのポリシーを使用して、`AccountA` のリクエスタによるリソースへのアクセスを許可する必要があります。
クロスアカウントリクエストを行うと、AWS は 2 つの評価を実行します。AWS は、信頼するアカウントのリクエストと信頼されるアカウントを評価します。1 つのアカウント内でリクエストが評価される方法の詳細については、「[AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法](reference_policies_evaluation-logic_policy-eval-denyallow.md)」を参照してください。リクエストは、両方の評価が `Allow` の決定を返す場合にのみ許可されます。
![\[クロスアカウント評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png)
1. あるアカウントのプリンシパルが別のアカウントのリソースにアクセスするためのリクエストを行う場合のリクエストが、クロスアカウントリクエストです。
1. リクエスト元のプリンシパルは、信頼されたアカウント (`AccountA`) に存在します。AWS がこのアカウントを評価すると、ID ベースのポリシー、および ID ベースのポリシーを制限できるすべてのポリシーがチェックされます。詳細については、「[アクセス許可の境界を使用したアイデンティティベースのポリシーの評価](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound)」を参照してください。
1. リクエストされたリソースは、信頼するアカウント (`AccountB`) に存在します。AWS は、このアカウントを評価するときに、リクエストされたリソースにアタッチされているリソースベースのポリシーと、リソースベースのポリシーを制限できるすべてのポリシーがチェックされます。詳細については、「[リソースベースのポリシーを使用したアイデンティティベースのポリシーの評価](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp)」を参照してください。
1. AWS は、両方のアカウントポリシー評価でリクエストが許可されている場合にのみリクエストを許可します。
次のフローチャートは、クロスアカウントリクエストのポリシー評価の判定がどのように行われるかをより詳細に示しています。繰り返しになりますが、AWS は両方のアカウントポリシー評価でリクエストが許可されている場合にのみリクエストを許可します。
![\[詳細なクロスアカウントポリシーの評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png)
## クロスアカウントポリシー評価の例
次の例は、あるアカウントのロールが、別のアカウントのリソースベースのポリシーによって許可が付与されるシナリオを示しています。
Carlos は、アカウント 111111111111 で `Demo` という名前の IAM ロールを持つデベロッパーであるとします。アカウント 222222222222 の `amzn-s3-demo-bucket-production-logs` Amazon S3 バケットにファイルを保存したいと考えています。
また、次のポリシーを 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*/*"
]
}
]
}
```
------
このポリシーの `AllowS3ListRead` ステートメントでは、Amazon S3 内のすべてのバケットを一覧表示することを Carlos に許可します。この `AllowS3ProductionObjectActions` ステートメントにより、Carlos に `amzn-s3-demo-bucket-production` バケットへのフルアクセスが許可されます。
さらに、次のリソースベースのポリシー（バケットポリシー）を 222222222222 アカウントの `amzn-s3-demo-bucket-production` バケットにアタッチします。
------
#### [ 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/*"
}
]
}
```
------
このポリシーにより、`Demo` ロールは `amzn-s3-demo-bucket-production` バケット内のオブジェクトにアクセスできます。このロールは、バケット内のオブジェクトを作成および編集することはできますが、削除することはできません。ロールはバケット自体を管理できません。
Carlos がファイルを `amzn-s3-demo-bucket-production-logs` バケットに保存することをリクエストすると、AWS はこのリクエストに適用されるポリシーを決定します。この場合、アカウント `111111111111` に適用される唯一のポリシーは、`Demo` ロールにアタッチされた ID ベースのポリシーです。アカウント `222222222222` には、`amzn-s3-demo-bucket-production-logs` バケットにアタッチされたリソースベースのポリシーはありません。AWS がアカウント `111111111111` を評価するとき、`Deny` の決定を返します。これは、ID ベースのポリシーの `DenyS3Logs` ステートメントが、ログバケットへのアクセスを明示的に拒否するためです。1 つのアカウント内でリクエストが評価される方法の詳細については、「[AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法](reference_policies_evaluation-logic_policy-eval-denyallow.md)」を参照してください。
リクエストはいずれかのアカウントで明示的に拒否されるため、最終的な決定はリクエストを拒否することです。
![\[amzn-s3-demo-bucket-production-logs バケットへのリクエスト\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png)
Carlos は、その後、間違いに気付き、`Production` バケットにファイルを保存しようとするとします。AWS は、最初にアカウント `111111111111` をチェックし、リクエストが許可されるかどうかを判断します。ID ベースのポリシーのみが適用され、リクエストが許可されます。次に、AWS はアカウント `222222222222` をチェックします。`Production` バケットにアタッチされたリソースベースのポリシーのみが適用され、リクエストが許可されます。両方のアカウントがリクエストを許可するため、最終的な決定はリクエストを許可することです。
![\[本稼働バケットへのリクエスト\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)