# ポリシーの評価論理
プリンシパルが AWS マネジメントコンソール、AWS API、または AWS CLI を使用しようとすると、プリンシパルは AWS に*リクエスト*を送信します。AWS サービスが、リクエストを受け取ると、AWS は、いくつかのステップを実行してリクエストの許可または拒否を決定します。
1. **認証** – AWS は、必要に応じて、最初にリクエストを行ったプリンシパルを認証します。このステップは、匿名ユーザーからの一部のリクエストを許可するいくつかのサービス (Amazon S3 など) では不要です。
1. **[リクエストコンテキストの処理](reference_policies_evaluation-logic_policy-eval-reqcontext.md)** – AWS は、リクエスト内で収集した情報を処理し、リクエストに適用するポリシーを決定します。
1. **[AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法](reference_policies_evaluation-logic_policy-eval-denyallow.md)** – AWS はすべてのポリシータイプを評価し、ポリシーの順序はそれらの評価方法に影響します。 AWS は次に、リクエストコンテキストに対してポリシーを処理して、リクエストが許可または拒否されたかどうかを判断します。
## リソースベースのポリシーを使用したアイデンティティベースのポリシーの評価
アイデンティティのポリシーとリソースベースのポリシーは、それらが関連付けられているアイデンティティまたはリソースにアクセス許可を付与します。IAM エンティティ (ユーザーまたはロール) が同じアカウントのリソースへのアクセスをリクエストした場合、AWS は、アイデンティティのポリシーおよびリソースベースのポリシーによって付与されているすべてのアクセス許可を評価します。結果として得られる許可は、2 つのタイプの許可を結合したものになります。アクションがアイデンティティのポリシーかリソースベースのポリシー、または両方で許可されている場合、AWS はそのアクションを許可します。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。
![\[アイデンティティベースのポリシーおよびリソースベースのポリシーの評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/permissions_policies_effective.png)
## アクセス許可の境界を使用したアイデンティティベースのポリシーの評価
AWS でユーザーのアイデンティティベースのポリシーとアクセス許可の境界を評価する場合は、2 つのカテゴリーの共通部分に基づいてアクセス許可が決定されます。つまり、既存のアイデンティティベースのポリシーを使用してアクセス許可の境界をユーザーに追加すると、ユーザーが実行できるアクションが制限される場合があります。逆に、ユーザーからアクセス許可の境界を削除すると、ユーザーが実行できるアクションが増える場合があります。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。他のポリシータイプがアクセス許可の境界で評価される方法について確認するには、「[境界を設定した場合の有効なアクセス許可の評価](access_policies_boundaries.md#access_policies_boundaries-eval-logic)」を参照してください。
![\[アイデンティティベースのポリシーとアクセス許可の境界の評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/permissions_boundary.png)
## AWS Organizations SCPまたはRCP を使用したアイデンティティベースのポリシーの評価
ユーザーが組織のメンバーであるアカウントに属しており、リソースベースのポリシーが設定されていないリソースにアクセスする場合、結果として得られる許可は、ユーザーのポリシー、サービスコントロールポリシー (SCP)、およびリソースコントロールポリシー (SCP) すべての適用を受けます。これは、3 つすべてのポリシータイプによってアクションが許可されなければならないことを意味します。ID ベースのポリシー、SCP、または RCP での明示的な拒否は、許可をオーバーライドします。
![\[ID ベースのポリシーと SCP または RCP の評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/permissions_scp-idp.png)
[自分のアカウントが AWS Organizations の組織のメンバーであるかどうか](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account)を確認できます。組織のメンバーは、SCP または RCP による影響を受ける可能性があります。AWS CLI コマンドまたは AWS API オペレーションを使用してこのデータを表示するには、AWS Organizations エンティティに対する `organizations:DescribeOrganization` アクションのアクセス許可が必要です。AWS Organizations コンソールでオペレーションを実行するには、追加のアクセス許可が必要です。SCP または RCP が特定のリクエストへのアクセスを拒否しているかどうかを確認する、または有効な許可を変更するには、AWS Organizations 管理者に連絡してください。
# リクエストコンテキストの処理
AWS がリクエストを評価して承認すると、リクエスト情報を*リクエストコンテキスト*にアセンブルします。リクエストコンテキストには、ポリシー評価で使用できる情報が含まれています。
+ **プリンシパル** – リクエストを送信したユーザー、ロール、フェデレーションユーザーのプリンシパル。プリンシパルに関する情報には、そのプリンシパルに関連付けられたポリシーが含まれます。
+ **アクション** – プリンシパルが実行する 1 つ、または複数のアクション。
+ **リソース** – アクションまたは操作が実行される 1 つ、または複数の AWS リソースオブジェクト。
+ **リソースデータ** – リクエストされているリソースに関連するデータ。これには、DynamoDB テーブル名、Amazon EC2 インスタンスのタグなどの情報が含まれる場合があります。
+ **環境データ** – IP アドレス、ユーザーエージェント、SSL 有効化ステータス、または時刻に関する情報。
この情報は、リクエストを許可するか拒否するかを判断するために該当するポリシーと比較されます。AWS ポリシーの評価方法をよりよく理解するため、このプロパティ情報は **[Principal]**、**[Action]**、**[Resource]**、および **[Condition]** (PARC) モデルを使用して整理することができます。
## PARC モデルを理解する
PARC モデルは、ポリシー言語の 4 つの JSON 要素に基づいてリクエストコンテキストを表します。
+ [Principal](reference_policies_elements_principal.md) – リクエストを行うエンティティ。プリンシパルは、認証後に AWS アカウントでアクションを実行する権限を付与できる人間のユーザー、またはプログラム的なワークロードを表します。
+ [Action](reference_policies_elements_action.md) – 実行されている操作。多くの場合、アクションは API アクションにマッピングされます。
+ [Resource](reference_policies_elements_resource.md) – アクションが実行されている AWS リソース。
+ [Condition](reference_policies_elements_condition.md) – リクエストが許可されるために満たす必要がある追加の制約。
以下は、PARC モデルがリクエストコンテキストを表す方法の例です。
```
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:UserId=AIDA123456789EXAMPLE:BobsSession
- aws:PrincipalAccount=123456789012
- aws:PrincipalOrgId=o-example
- aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR
- aws:MultiFactorAuthPresent=true
- aws:CurrentTime=...
- aws:EpochTime=...
- aws:SourceIp=...
- aws:PrincipalTag/dept=123
- aws:PrincipalTag/project=blue
- aws:RequestTag/dept=123
```
## リクエストコンテキストの重要性
リクエストコンテキストと、リクエストコンテキストがポリシー評価と連携する方法を理解することは、以下を行う上で重要です。
+ アクセス問題のトラブルシューティング
+ 効果的でセキュアなポリシーの設計
+ ポリシーが付与する許可の全範囲の把握
+ さまざまなシナリオでのポリシー評価結果の予測
PARC モデルを使用してリクエストコンテキストを視覚化することで、AWS が承認判断を行う方法をより簡単に理解し、ポリシーをより効果的に設計することができます。
## AWS がリクエストコンテキストを使用する方法
AWS がポリシーを評価するときは、リクエストコンテキスト内の情報を、該当するすべてのポリシーで指定されている情報と比較します。これには、ID ベースのポリシー、リソースベースのポリシー、IAM アクセス許可の境界、Organizations SCP、Organizations RCP、セッションポリシーが含まれます。
各ポリシータイプについて、AWS はリクエストコンテキストを使用して以下を確認します。
+ プリンシパルに基づくリクエストにポリシーが適用されるかどうか。
+ リクエストされたアクションが指定されたリソースで許可されているかどうか。
+ リクエストコンテキストがポリシーで指定された条件を満たしているかどうか。
AWS によるポリシーの評価方法は、リクエストコンテキストに適用するポリシーのタイプによって異なります。これらのポリシータイプは、単一の AWS アカウント内での利用が可能です。これらのポリシータイプの詳細については、「[AWS Identity and Access Management でのポリシーとアクセス許可](access_policies.md)」をご参照ください。AWS がクロスアカウントアクセスのポリシーを評価する方法については、「[クロスアカウントポリシーの評価論理](reference_policies_evaluation-logic-cross-account.md)」を参照してください。
+ **AWS Organizations リソース制御ポリシー（RCP）** – AWS Organizations RCPは、組織または組織単位 (OU) のアカウント内のリソースについて使用できる最大の許可を指定します。RCP はメンバーアカウントのリソースに適用され、プリンシパルが組織に属しているかどうかにかかわらず、AWS アカウントのルートユーザー を含むプリンシパルの有効な許可に影響を及ぼします。RCP は、組織管理アカウントのリソースや、サービスにリンクされたロールによって実行された呼び出しには適用されません。RCP が存在する場合、ID ベースのポリシーおよびリソースベースのポリシーによってメンバーアカウント内のリソースに付与された許可は、RCP がアクションを許可する場合にのみ有効です。
+ **AWS Organizations サービスコントロールポリシー (SCP)** – AWS Organizations SCP は、組織または組織単位 (OU) のアカウント内のプリンシパルのために使用可能な最大の許可を指定します。SCP は、各 AWS アカウントのルートユーザー を含むメンバーアカウントのプリンシパルに適用されます。SCP が存在する場合、ID ベースのポリシーおよびリソースベースのポリシーによってメンバーアカウントのプリンシパルに付与された許可は、SCP がアクションを許可する場合にのみ有効です。唯一の例外は、組織管理アカウントとサービスにリンクされたロールのプリンシパルです。
+ **リソースベースのポリシー** – リソースベースのポリシーは、ポリシーで指定されたプリンシパルの許可を付与します。このアクセス許可では、ポリシーがアタッチされているリソースに対してプリンシパルが実行できる操作を定義します。
+ **アクセス許可の境界** – アクセス許可の境界は、ID ベースのポリシーが IAM エンティティ (ユーザーまたはロール) に付与できる許可の上限を設定する機能です。エンティティのアクセス許可の境界を設定した場合、エンティティは、ID ベースのポリシーとそのアクセス許可の境界の両方で許可されている許可のみ実行できます。アクセス許可の境界で暗黙的に拒否しても、リソースベースのポリシーによって付与されるアクセス許可は制限される場合もあります。詳細については、「[AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法](reference_policies_evaluation-logic_policy-eval-denyallow.md)」を参照してください。
+ **ID ベースのポリシー** — アイデンティティベースのポリシーは IAM ID (ユーザー、ユーザーのグループ、またはロール) にアタッチされており、アクセス許可を IAM エンティティ (ユーザーおよびロール) にアタッチします。リクエストにアイデンティティベースのポリシーのみ、リクエストに適用された場合、AWS では、それらのすべてのポリシーに少なくとも 1 つ `Allow` がないか確認します。
+ **セッションポリシー** – セッションポリシーは、ロールまたはフェデレーションユーザーのセッションに一時的なセッションをプログラムで作成する際、パラメータとして渡すポリシーです。ロールセッションをプログラムで作成するには、`AssumeRole*` API オペレーションのいずれかを使用します。これを行い、セッションポリシーに合格すると、結果として得られるセッションのアクセス許可は、IAM エンティティの ID ベースのポリシーとセッションポリシーの共通部分です。フェデレーションユーザーのセッションを作成するには、IAM ユーザーのアクセスキーを使用して、API の `GetFederationToken` オペレーションをプログラムで呼び出します。詳細については、「[セッションポリシー](access_policies.md#policies_session)」を参照してください。
これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になる点に注意してください。
**注記**
**AWS Organizations 宣言型ポリシー**を使用すると、組織全体で特定の AWS のサービス に必要な設定を一元的に宣言して適用できます。宣言型ポリシーはサービスレベルで直接適用されるため、ポリシー評価リクエストに直接影響を与えず、リクエストコンテキストには含まれません。詳細については、「AWS Organizations IAM ユーザーガイド」の「[ 管理されたポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html)」を参照してください。
## PARC モデルを使用したポリシー評価の例
リクエストコンテキストがポリシー評価とどのように連携するかを説明するために、ポリシー例を検討しましょう。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/dept": "123"
}
}
}
]
}
```
------
この例では、リクエストコンテキストに「123」の `aws:PrincipalTag/dept` 値が含まれ、リソースが `amzn-s3-demo-bucket1` バケット名と一致する場合にのみ、ポリシーが `CreateBucket` アクションを許可します。以下の表は、AWS がリクエストコンテキストを使用してこのポリシーを評価し、承認判断を行う方法を示しています。
| ポリシー | リクエストコンテキスト | 評価結果 |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **一致** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=321
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
リクエストに `aws:PrincipalTag` はありません。 | **一致なし** |
# 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)
# 明示的な拒否と暗黙的な拒否の違い
該当するポリシーに `Deny` ステートメントが含まれている場合、リクエストは明示的に拒否されます。リクエストに適用されるポリシーに `Allow` ステートメントと `Deny` ステートメントが含まれている場合は、`Deny` ステートメントが `Allow` ステートメントより優先されます。リクエストは明示的に拒否されます。
該当する `Deny` ステートメントがなく、該当する `Allow` ステートメントもない場合は、暗黙的な拒否が発生します。IAM プリンシパルは、デフォルトでアクセスが拒否されされるため、アクションを実行するには明示的に許可を受ける必要があります。そうでない場合は、アクセスは暗黙的に拒否されます。
承認戦略を設計する場合、プリンシパルのリクエストを成功させるには、作成するポリシーに `Allow` ステートメントを含める必要があります。ただし、明示的な拒否と暗黙的な拒否の任意の組み合わせを選択できます。
例えば、許可されたアクション、暗黙的に拒否されたアクション、および明示的に拒否されたアクションを含む、次のポリシーを作成できます。`AllowGetList` ステートメントは、`Get` または `List` プレフィックスで始まる IAM アクションに対して、読み取り専用のアクセスを**許可**します。`iam:CreatePolicy` など、IAM の他のすべてのアクションは、**暗黙的に拒否**されます。`DenyReports` ステートメントは、`iam:GetOrganizationsAccessReport` などの`Report` サフィックスを含むアクションへのアクセスを拒否することで、IAM レポートへのアクセスを**明示的に拒否**します。誰かがこのプリンシパルに別のポリシーを追加して、`iam:GenerateCredentialReport` などのIAM レポートへのアクセス許可を付与した場合は、この明示的拒否のために、レポート関連のリクエストは引き続き拒否されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGetList",
"Effect": "Allow",
"Action": [
"iam:Get*",
"iam:List*"
],
"Resource": "*"
},
{
"Sid": "DenyReports",
"Effect": "Deny",
"Action": "iam:*Report",
"Resource": "*"
}
]
}
```
------