# リクエストコンテキストの処理
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` はありません。 | **一致なし** |