# IAM JSON ポリシー要素のリファレンス
JSON ポリシードキュメントは要素で構成されます。要素は、ポリシーで使用する一般的な順番で記載されています。要素の順番は重要ではありません (たとえば、`Resource` 要素を `Action` 要素の前にもってくることなどが可能です)。ポリシーで、あらゆる `Condition` 要素も特定する必要はありません。JSON ポリシードキュメントの全体構造と目的については「[JSON ポリシー概要](access_policies.md#access_policies-json)」をご覧ください。
一部の JSON ポリシーの要素は相互排他的です。つまり、両方を使用するポリシーを作成することはできません。たとえば、`Action` と `NotAction` を同じポリシーステートメントで使用することはできません。相互排他的な他のペアには `Principal`/`NotPrincipal` や `Resource`/`NotResource` があります。
ポリシーに取り入れる詳細は各サービスによって異なり、サービスで利用可能なアクションやリソースの種類などにより異なります。特定のサービスのポリシーを記述している場合、そのサービスに関するポリシーの例を参照することが役に立ちます。IAM をサポートするすべてのサービスのリスト、およびそれらのサービスの IAM とポリシーについて説明しているドキュメントへのリンクについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。
JSON ポリシーを作成または編集するときに、IAM はポリシー検証を実行し、効果的なポリシーを作成するのに役立ちます。IAM は JSON 構文エラーを識別します。一方、IAM Access Analyzer は、ポリシーをさらに絞り込むのに役立つ推奨事項を含む追加のポリシーチェックを提供します。ポリシーの検証の詳細については、「[IAM ポリシーの検証](access_policies_policy-validator.md)」を参照してください。。IAM Access Analyzer のポリシーチェックと実用的な推奨事項の詳細については、「[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)」IAM Access Analyzer ポリシーの検証を参照してください。
**Topics**
+ [Version](reference_policies_elements_version.md)
+ [Id](reference_policies_elements_id.md)
+ [Statement](reference_policies_elements_statement.md)
+ [Sid](reference_policies_elements_sid.md)
+ [Effect](reference_policies_elements_effect.md)
+ [Principal](reference_policies_elements_principal.md)
+ [NotPrincipal](reference_policies_elements_notprincipal.md)
+ [Action](reference_policies_elements_action.md)
+ [NotAction](reference_policies_elements_notaction.md)
+ [Resource](reference_policies_elements_resource.md)
+ [NotResource](reference_policies_elements_notresource.md)
+ [Condition](reference_policies_elements_condition.md)
+ [変数とタグ](reference_policies_variables.md)
+ [サポートされているデータ型](reference_policies_elements_datatypes.md)
# IAM JSON ポリシー要素Version
**あいまいさに関する注意**
この `Version` JSON ポリシー要素は*ポリシーバージョン*とは異なります。`Version` ポリシー要素は、ポリシー内で使用され、ポリシー言語のバージョンを定義します。一方で、ポリシーバージョンは、IAM でカスタマー管理ポリシーを変更すると作成されます。変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。管理ポリシーに対する複数のバージョンのサポートに関する情報を探している場合は、「[IAM ポリシーのバージョニング](access_policies_managed-versioning.md)」を参照してください。
`Version` ポリシー要素は、このポリシーを処理するために使用される言語構文ルールを指定します。使用可能なポリシーの機能をすべて使用するには、すべてのポリシーの `Statement` 要素の**外部**にある以下の `Version` 要素を含めます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
IAM は以下の `Version` 要素値をサポートしています。
+ `2012-10-17`. これはポリシー言語の現行バージョンであり、常に `Version` 要素を含め、`2012-10-17` に設定する必要があります。このようにしない場合、このバージョンで導入された[ポリシー変数](reference_policies_variables.md)などの機能は使用できません。
+ `2008-10-17`. これはポリシー言語の旧バージョンです。既存のポリシーで古めのものでは、このバージョンが表示される場合があります。新規ポリシーを作成するときや既存ポリシーを更新するときは、この旧バージョンを使用しないでください。ポリシー変数などの新しい機能は、ポリシーでは機能しません。たとえば、`${aws:username}` などの変数は変数として認識されず、代わりにポリシー内のリテラル文字列として扱われます。
# IAM JSON ポリシー要素Id
`Id` 要素は、ポリシーで使用する任意の識別子を特定します。ID の使用方法は、サービスによって異なります。ID は、リソースベースのポリシーでは使用できますが、アイデンティティベースのポリシーでは使用できません。
`ID` 要素を設定するサービスの場合、UUID (GUID) を値に使用する、または UUID を唯一性を確認するための ID の一部として統合することを推奨します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "cd3ad3d9-2776-4ef1-a904-4c229d1642ee",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
**注記**
AWS のサービス (たとえば、Amazon SQS や Amazon SNS など) には、この要素を要求し、唯一条件を与えるものもあります。ポリシーの記述に関するサービス固有の情報は、お取り扱いのサービス用のドキュメントを参照してください。
# IAM JSON ポリシー要素Statement
`Statement` 要素は、ポリシーの主要要素です。この要素は必須です。`Statement` 要素には、単一のステートメントまたは個々のステートメントの配列を含めることができます。個々のステートメントブロックは、中括弧 \$1 \$1 で囲む必要があります。複数のステートメントの場合、配列は角括弧 [ ] で囲む必要があります。
```
"Statement": [{...},{...},{...}]
```
以下の例は、1 つの `Statement` 要素の中に 3 つのステートメントの配列を含むポリシーを示しています。(このポリシーにより、Amazon S3 コンソール内の自分の "ホームフォルダー" にアクセスできます)。ポリシーには `aws:username` 変数が含まれ、変数はポリシーの評価時にリクエストからのユーザー名に置き換えられます。詳細については、「[序章](reference_policies_variables.md#policy-vars-intro)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {"StringLike": {"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]}}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
]
}
]
}
```
------
# IAM JSON ポリシー要素Sid
ポリシーステートメントのオプションの識別子として、`Sid` (ステートメントID) を指定することができます。`Sid` 値は、ステートメント配列内の各ステートメントに割り当てることができます。`Sid` の値は、ポリシーステートメントの説明として使用できます。SQS や SNS などの `ID` 要素を特定するサービスでは、`Sid` 値はポリシードキュメント ID の副 ID に過ぎません。IAM では、`Sid` 値は JSON ポリシー内で固有のものでなければいけません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleStatementID",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
-`Sid`要素は、ASCII 大文字 (A〜Z)、小文字 (A〜Z)、および数字 (0〜9) をサポートします。
IAM は、IAM API で`Sid`を公開しません。この ID に基づいて、特定のステートメントを復元することはできません。
**注記**
AWS のサービス (例えば、Amazon SQS や Amazon SNS など) には、この要素を要求し、唯一条件を与えるものもあります。ポリシーの記述に関するサービス固有の情報は、お取り扱いのサービス用のドキュメントを参照してください。
# IAM JSON ポリシー要素Effect
`Effect` 要素は必須であり、ステートメントの結果を許可または明示的な拒否のどちらにするかを指定します。`Effect` の有効値は、`Allow` と `Deny` です。`Effect` 値では、大文字と小文字が区別されます。
```
"Effect":"Allow"
```
デフォルト設定では、リソースへのアクセスは拒否されます。リソースへのアクセスを許可するには、`Effect` 要素を `Allow` に設定する必要があります。許可を無効にするには (たとえば、本来有効となる許可を無効にするなど)、`Effect` 要素を `Deny` に設定します。詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
# AWS JSON ポリシーの要素: Principal
リソースベースの JSON ポリシーの `Principal` 要素を使用して、リソースへのアクセスを許可または拒否するプリンシパルを指定します。
[リソースベースポリシー](access_policies_identity-vs-resource.md) の `Principal` 要素を使用する必要があります。IAM など、いくつかのサービスが、リソースベースのポリシーをサポートしています。IAM リソースベースのポリシーのタイプは、ロールの信頼ポリシーです。IAM ロールでは、ロールの信頼ポリシー内の `Principal` 要素を使用して、だれがこのロールを引き受けることができるかを指定します。クロスアカウントアクセスとして、信頼されたアカウントの 12 桁の ID を指定する必要があります｡ 信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
**注記**
ロールを作成した後、アカウントを「\$1」に変更すると、誰もがそのロールを引き受けることができます。これを行う場合は、アクセスを特定の IP アドレスのみに制限する `Condition` 要素など、他の方法でロールへのアクセスを制限することを強くお勧めします。誰でもロールにアクセスできる状態のままにしないでください。
サポートベースのポリシーをサポートする他のサービスの例としては、Amazon S3 バケットや AWS KMS key が挙げられます。
`Principal` エレメントを ID ベースのポリシーで使用することはできません。ID ベースのポリシーは、IAM の ID (ユーザー、グループ、ロール) にアタッチするアクセス許可ポリシーです。これらの場合、プリンシパルは、ポリシーがアタッチされた ID によって暗示されます。
**Topics**
+ [プリンシパルを指定する方法](#Principal_specifying)
+ [AWS アカウント プリンシパル](#principal-accounts)
+ [IAM ロールプリンシパル](#principal-roles)
+ [ロールセッションプリンシパル](#principal-role-session)
+ [OIDC フェデレーテッドプリンシパル](#principal-federated-web-identity)
+ [SAML フェデレーテッドプリンシパル](#principal-saml)
+ [IAM ユーザープリンシパル](#principal-users)
+ [IAM Identity Center のプリンシパル](#principal-identity-users)
+ [AWS STS フェデレーションユーザープリンシパル](#sts-session-principals)
+ [AWS サービスプリンシパル](#principal-services)
+ [オプトインリージョンの AWS サービスプリンシパル](#principal-services-in-opt-in-regions)
+ [すべてのプリンシパル](#principal-anonymous)
+ [詳細情報](#Principal_more-info)
## プリンシパルを指定する方法
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーでプリンシパルを指定します。
ポリシーでは、次のいずれかのプリンシパルを指定できます。
+ AWS アカウント およびルートユーザー
+ IAM ロール
+ ロールセッション
+ IAM ユーザー
+ フェデレーションユーザープリンシパル
+ AWS のサービス
+ すべてのプリンシパル
ユーザーグループをポリシー (リソースベースのポリシーなど) のプリンシパルとして識別することはできません。これは、グループは 認証ではなくアクセス権限に関連しており、プリンシパルは認証済みの IAM エンティティであるためです。
配列を使用して、以降のセクションの各プリンシパル型に対して複数のプリンシパルを指定できます。配列では 1 つまたは複数の値を使用できます。要素で複数のプリンシパルを指定する場合は、各プリンシパルにアクセス許可を付与します。これは論理 `OR` であり論理 `AND` ではありません。一度に 1 つのプリンシパルを認証するためです。複数の値を含める場合は、角括弧 (`[` と `]`) を使用し、配列の各エントリをカンマで区切ります。次のポリシーの例では、123456789012 アカウントまたは 555555555555 アカウントのアクセス許可を定義します。
```
"Principal" : {
"AWS": [
"123456789012",
"555555555555"
]
}
```
**注記**
ワイルドカードとして使用して、プリンシパルの名前または ARN の一部に一致させることはできません。
## AWS アカウント プリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、AWS アカウント の識別子を指定できます。これにより、権限がアカウントに委譲されます。別のアカウントへのアクセスを許可する場合、そのアカウントの管理者が、そのアカウントの ID (IAM ユーザーまたはロール) へのアクセス許可を付与する必要があります。AWS アカウント を指定するときは、アカウント ARN (aarn:aws:iam::*account-ID*:root、または `"AWS":` プレフィックスの後に ID を付けた短縮形を使用できます。
例えば、割り当てられた アカウント ID (`123456789012`) から、次のいずれかのメソッドを使用して、`Principal` 要素でそのアカウントを指定できます。
```
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
```
```
"Principal": { "AWS": "123456789012" }
```
アカウント ARN と短縮アカウント ID は、同じように動作します。どちらも、アカウントにアクセス許可を委譲します。`Principal` 要素で アカウント ARN を使用しても、アカウントのルートユーザーだけはアクセス許可を制限しません。
**注記**
短縮アカウント ID を含むリソースベースのポリシーを保存すると、それをサービスがプリンシパル ARN に変換することがあります。これはポリシーの機能は変更しません。
一部の AWS サービスでは、アカウントプリンシパルを指定するための追加オプションがサポートされています。例えば、Amazon S3 では、次の形式を使用して[正規ユーザー ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) を指定できます。
```
"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }
```
配列を使用すると、プリンシパルとして AWS アカウント (または正規ユーザー ID) を 1 つ以上指定できます。例えば、3 つのメソッドすべてを使用して、バケットポリシーでプリンシパルを指定できます。
```
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root",
"999999999999"
],
"CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}
```
## IAM ロールプリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、IAM ロールプリンシパル ARNを指定できます。IAM ロールは ID です。IAM では、ID はアクセス許可を割り当てることができるリソースです。ロールは、別の認証済みの ID を信頼して、そのロールを引き受けます。これには、AWS のプリンシパルか、外部 ID プロバイダー (IdP) からのユーザーが含まれます。プリンシパルまたは ID がロールを引き受けると、引き受けたロールのアクセス許可を持った、一時的なセキュリティ認証情報を受け取ります。AWS でこれらのセッション認証情報を使用して操作を実行すると、これらは*ロールセッションプリンシパル*になります。
リソースベースのポリシーでロールプリンシパルを指定すると、ロールのアクセス許可を制限するポリシータイプによって、プリンシパルの有効なアクセス許可が制限されます。これには、セッションポリシーとアクセス許可の境界が含まれます。ロールセッションの有効なアクセス許可の評価方法については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
`Principal` 要素でロール ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
```
**重要**
ロール信頼ポリシーの `Principal` 要素に、特定の IAM ロールを指し示す ARN が含まれている場合、その ARN はポリシーを保存するときにロールの一意のプリンシパル ID に変換されます。これにより、ロールを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、IAM が ロール ARN への逆変換を行うためです。ただし、ロールを削除すると、関係が壊れます。ロールを再作成した場合でも、ポリシーは適用されません。これは、新しいロールは信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID を持っているためです。この場合、プリンシパル ID はリソースベースポリシーに表示されます。これは AWS が有効な ARN に戻って ID をマッピングできなくなるためです。その結果、信頼ポリシーの `Principal` 要素で参照されているロールを削除して再作成する場合は、ポリシーのロールを編集してプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、ARN は再びロールの新しいプリンシパル ID に変換されます。詳細については、[「Understanding AWS's Handling of Deleted IAM roles in Policies」](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies)を参照してください。
または、ロールプリンシパルをリソースベースのポリシーのプリンシパルとして指定するか、[幅広くアクセスを許可するポリシーを作成](#principal-anonymous)して `aws:PrincipalArn` 条件キーを使用します。このキーを使用すると、ロールセッションプリンシパルには、セッションの結果として得られる ARN ではなく、引き受けたロールの ARN に基づくアクセス許可が付与されます。なぜなら、AWS は条件キー ARN を ID に変換せず、ロールを削除してから同じ名前で新しくロールを作成すると、ロール ARN に付与されたアクセス許可は保持されるからです。アクセス許可の境界やセッションポリシーなどの ID ベースのポリシータイプは、アイデンティティベースのポリシーに明示的な拒否が含まれていない限り、`Principal` 要素で、ワイルドカード (\$1) を含む `aws:PrincipalArn` 条件キーを使用して付与されたアクセス許可を制限することはありません。
## ロールセッションプリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、ロールセッションを指定できます。プリンシパルまたは ID がロールを引き受けると、引き受けたロールのアクセス許可を持った、一時的なセキュリティ認証情報を受け取ります。AWS でこれらのセッション認証情報を使用して操作を実行すると、これらは*ロールセッションプリンシパル*になります。
ロールセッションプリンシパルに使用する形式は、ロールの引き受けに使用する AWS STS のオペレーションによります。
**重要**
AWS では、可能な限りロールセッションプリンシパルの代わりに[ IAM ロールプリンシパル](#principal-roles)をポリシーで使用することをお勧めします。`Condition` ステートメントと条件キーを使用して、必要に応じてアクセス範囲をさらに絞り込みます。
`Principal` 要素のロールセッションプリンシパル ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
```
さらに管理者は、ロールセッションの発行方法を制御するプロセスを設計できます。例えば、ユーザーがワンクリックするだけで、予測可能なセッション名を作成するソリューションを提供できます。これを管理者が行う場合、ポリシーまたは条件キーで、ロールセッションプリンシパルを使用できます。それ以外の場合は、ロール ARN を `aws:PrincipalArn` 条件キーのプリンシパルとして指定することができます。ロールをどのようにプリンシパルとして指定するかによって、セッション完了後の有効なアクセス許可が変わります。詳細については、「[IAM ロールプリンシパル](#principal-roles)」を参照してください。
## OIDC フェデレーテッドプリンシパル
OIDC フェデレーテッドプリンシパルは、OpenID プロバイダー (OP) とも呼ばれる OIDC 準拠 IDP から JSON ウェブトークン (JWT) を使用して AWS STS `AssumeRoleWithWebIdentity` API を呼び出し、一時的な AWS 認証情報をリクエストするときに使用されるプリンシパルです。OIDC フェデレーテッドプリンシパルは、AWS アカウントの OIDC IDP、または 4 つの組み込み ID プロバイダー (Login with Amazon、Google、Facebook、[Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)) を表すことができます。
OIDC IDP から JWT が発行されたユーザー、ワークロード、またはシステムは、JWT を使用して `AssumeRoleWithWebIdentity` を呼び出し、JWT を発行した OIDC IDP を信頼するように設定された IAM ロールの一時的な AWS セキュリティ認証情報をリクエストできます。JWT は、ID トークン、アクセストークン、またはその他の方法で配信される JWT トークン ([AWS STS による要件](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites)を満たしている場合) です。詳細については、「[一般的なシナリオ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html)」と「[OIDC プロバイダーを通じた認証情報のリクエスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity)」を参照してください。
このプリンシパルタイプをロール信頼ポリシーで使用し、AWS アカウントに存在する OIDC IDP、または 4 つの組み込み IDP のいずれかを使用して `AssumeRoleWIthWebIdentity` を呼び出すアクセス許可を許可または拒否します。ロール信頼ポリシーの `Principal` 要素で OIDC フェデレーテッドプリンシパル ARN を指定するには、組み込みの OIDC IDP に対して次の 4 つの形式のいずれかを使用します。
```
"Principal": { "Federated": "cognito-identity.amazonaws.com" }
```
```
"Principal": { "Federated": "www.amazon.com" }
```
```
"Principal": { "Federated": "graph.facebook.com" }
```
```
"Principal": { "Federated": "accounts.google.com" }
```
アカウントに追加する OIDC プロバイダー (GitHub など) を使用する場合は、ロールの信頼ポリシーでプロバイダーの ARN を指定します。この設定により、カスタム ID プロバイダーを介して認証されたユーザーのアクセスを制御する IAM ポリシーを作成できます。
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" }
```
例えば、GitHub が信頼されたウェブ ID プロバイダーである場合、ロール信頼ポリシーの `Principal` 要素の OIDC ロールセッション ARN は次の形式を使用します。
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" }
```
詳細については、「[Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」を参照してください。
OIDC フェデレーテッドプリンシパルは、ロール信頼ポリシー以外のポリシータイプではサポートされていません。
## SAML フェデレーテッドプリンシパル
*SAML フェデレーテッドプリンシパル*は、SAML アサーションを使用して AWS STS `AssumeRoleWithSAML` API を呼び出して一時的な AWS 認証情報をリクエストするときに使用されるプリンシパルです。SAML ID プロバイダー (IDP) を使用してサインインし、この操作を使用して IAM ロールを引き受けることができます。`AssumeRoleWithWebIdentity` と同様に、 `AssumeRoleWithSAML` は認証に AWS 認証情報を必要としません。代わりに、ユーザーはまず SAML ID プロバイダーで認証し、次に SAML アサーションを使用して `AssumeRoleWithSAML` API コールを行うか、AWS マネジメントコンソールにサインインする AWS サインイン/SAML ページにリダイレクトされます。このオペレーションを使用してロールを引き受けることができるプリンシパルについては、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。
このプリンシパルタイプをロール信頼ポリシーで使用して、信頼済みの SAML ID プロバイダーに基づき、アクセス許可を許可または拒否します。ロール信頼ポリシーの `Principal` 要素で SAML ID ロールセッション ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }
```
## IAM ユーザープリンシパル
リソースベースのポリシーの `Principal` 要素、またはプリンシパルをサポートする条件キーで、IAM ユーザーを指定できます。
**注記**
`Principal` 要素にある [*Amazon リソースネーム*(ARN)](reference_identifiers.md#identifiers-arns)のユーザー名の部分では、大文字と小文字を区別します。
```
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }
```
```
"Principal": {
"AWS": [
"arn:aws:iam::AWS-account-ID:user/user-name-1",
"arn:aws:iam::AWS-account-ID:user/user-name-2"
]
}
```
`Principal` 要素内でユーザーを指定する際に、"すべてのユーザー" の意味でワイルドカード (`*`) を使用することはできません。プリンシパルには、常に複数の特定ユーザーを指定する必要があります。
**重要**
ロールの信頼ポリシーの `Principal` 要素に、特定の IAM ユーザーを指し示す ARN が含まれている場合、その ARN をポリシーに保存するときに、IAM がユーザーの一意のプリンシパル ID に変換されます。これにより、ユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ユーザーの ARN への逆変換が行われるためです。ただし、ユーザーを削除すると、関係が壊れます。ユーザーを再作成しても、ポリシーが適用されることはありません。これは、新しいユーザーには、信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID が付与されるためです。この場合、プリンシパル ID はリソースベースポリシーに表示されます。これは AWS が有効な ARN に戻って ID をマッピングできなくなるためです。その結果、信頼ポリシーの `Principal` 要素で参照されているユーザーを削除して再作成する場合は、ロールを編集して、正しくなくなったプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、IAM が再び、ARN をユーザーの新しいプリンシパル ID に変換します。
## IAM Identity Center のプリンシパル
IAM Identity Center では、リソースベースのポリシーのプリンシパルが AWS アカウント プリンシパルとして定義されている必要があります。アクセスを指定するには、条件ブロック内のアクセス許可セットのロール ARN を参照してください。詳細については、*「IAM Identity Center ユーザーガイド*」の「[リソースポリシー、Amazon EKS、および AWS KMS のアクセス許可セットの参照](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html)」を参照してください。
## AWS STS フェデレーションユーザープリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、*フェデレーションユーザーセッション*を指定できます。
**重要**
AWS では、AWS STS フェデレーションユーザーセッションの使用を制限することをお勧めします。代わりに、[IAM ロール](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)を使用します。
AWS STS フェデレーションユーザープリンシパルは、長期的な IAM 認証情報を使用して呼び出される `GetFederationToken` オペレーションによって作成されます。フェデレーションユーザーのアクセス許可は、`GetFederationToken` を呼び出したプリンシパルとパラメータとして `GetFederationToken` API に渡されるセッションポリシーの交差です。
AWS では、IAM ユーザーまたは AWS アカウントのルートユーザー は、長期的なアクセスキーを使用して認証を行うことができます。このオペレーションで、どのプリンシパルがフェデレーションを行えるかについては、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。
+ **IAM フェデレーションユーザー** – `GetFederationToken` オペレーションを使用して IAM ユーザーがフェデレーションを行った結果、IAM ユーザーのフェデレーションユーザーのセッションができます。
+ **フェデレーションルートユーザー** – `GetFederationToken` オペレーションを使用してルートユーザーがフェデレーションを行った結果、IAM ユーザーのフェデレーションユーザーのセッションができます。
この操作を使用して、IAM ユーザーまたはルートユーザーが AWS STS から一時的な認証情報をリクエストした場合、一時的なフェデレーションユーザーセッションを開始します。このセッションの ARN は、フェデレーション元の ID に基づいています。
`Principal` 要素でフェデレーションユーザーセッション ARN を指定する場合は、次の形式を使用します。
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }
```
## AWS サービスプリンシパル
リソースベースのポリシーにある `Principal` 要素か、プリンシパルをサポートする条件キーで、AWS サービスを指定できます。*サービスプリンシパル*は、サービスの識別子です。
AWS のサービスが引き受けることのできる IAM ロールは、*[サービスロール](id_roles.md#iam-term-service-role)*と呼ばれます。サービスロールには信頼ポリシーを含める必要があります。*信頼ポリシー* は、どのプリンシパルがそのロールを果たすことができるかを定義するロールにアタッチされるリソースベースのポリシーです。一部のサービスロールには事前定義済みの信頼ポリシーがあります。ただし、状況によっては、信頼ポリシーでプリンシパルサービスを指定する必要があります。IAM ポリシーのサービスプリンシパルを `"Service": "*"` にすることはできません。
**重要**
サービスプリンシパルの識別子にはサービス名が含まれ、通常は次の形式になります。
`service-name.amazonaws.com`
サービスプリンシパルはサービスによって定義されます。一部のサービスのサービスプリンシパルを検索するには [IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md) を開き、サービスの **[Service-linked role]** (サービスにリンクされたロール) 列が **[Yes]** (はい) になっているかどうかを確認し、**[Yes]** (はい) リンクを開いてそのサービスのサービスにリンクされたロールのドキュメントを表示します。**サービスプリンシパル**を表示するには、そのサービスの [Service-Linked Role Permissions] (サービスにリンクされたロールのアクセス許可) のセクションを探します。
次の例では、サービスロールにアタッチできるポリシーを示します。ポリシーは、Amazon ECS および Elastic Load Balancing の 2 つのサービスを有効にして、ロールを引き受けます。これらのサービスは、ロールに割り当てられた権限ポリシー (表示されていない) によって付与されたタスクを実行できます。複数のサービスプリンシパルを指定する場合に、2 つの `Service` 要素は指定できません。1 つのみ指定できます。代わりに、1 つの `Service` 要素の値として複数のサービスのプリンシパルのアレイを使用します。
```
"Principal": {
"Service": [
"ecs.amazonaws.com",
"elasticloadbalancing.amazonaws.com"
]
}
```
## オプトインリージョンの AWS サービスプリンシパル
リソースは複数の AWS リージョンで起動できますが、一部のリージョンはオプトインする必要があります。オプトインする必要があるリージョンの一覧については、「*AWS 全般のリファレンス* ガイド」の「[AWS リージョンの管理](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)」を参照してください。
オプトインリージョンの AWS サービスが同じリージョン内でリクエストを行うと、サービスプリンシパル名の形式は、サービスプリンシパル名がリージョン化されないバージョンとして識別されます。
`service-name.amazonaws.com`
オプトインリージョンの AWS サービスが別のリージョンにクロスリージョンリクエストを行うと、サービスプリンシパル名の形式は、サービスプリンシパル名のリージョン化バージョンとして識別されます。
`service-name.{region}.amazonaws.com`
例えば、Amazon SNS トピックが `ap-southeast-1` リージョンにあり、Amazon S3 バケットがオプトインリージョン `ap-east-1` にあるとします。メッセージを SNS トピックに公開するように、S3 バケット通知を設定する必要があります。S3 サービスが SNS トピックにメッセージを投稿できるようにするには、トピックのリソースベースのアクセスポリシーを使用して S3 サービスのプリンシパル `sns:Publish` 権限を付与する必要があります。
トピックアクセスポリシーで S3 サービスプリンシパルのリージョン化されないバージョンである `s3.amazonaws.com` を指定すると、バケットからトピックへの `sns:Publish` リクエストは失敗します。次の例では、SNS トピックアクセスポリシーの `Principal` ポリシー要素に、リージョン化されない S3 サービスプリンシパルを指定しています。
```
"Principal": { "Service": "s3.amazonaws.com" }
```
バケットはオプトインリージョンにあり、リクエストは同じリージョン外で行われるため、S3 サービスプリンシパルはリージョン化されたサービスプリンシパル名 `s3.ap-east-1.amazonaws.com` として表示されます。オプトインリージョンの AWS サービスが別のリージョンにリクエストを行う場合は、リージョン化されたサービスプリンシパル名を使用する必要があります。リージョン化されたサービスプリンシパル名を指定した後に、バケットが別のリージョンにある SNS トピックに `sns:Publish` リクエストを行うと、リクエストは成功します。次の例では、SNS トピックアクセスポリシーの `Principal` ポリシー要素に、リージョン化された S3 サービスプリンシパルを指定しています。
```
"Principal": { "Service": "s3.ap-east-1.amazonaws.com" }
```
オプトインリージョンから別のリージョンへのクロスリージョンリクエストに対するリソースポリシーまたはサービスプリンシパルベースの許可リストは、リージョン化されたサービスプリンシパル名を指定した場合にのみ成功します。
**注記**
IAM ロールの信頼ポリシーには、リージョン化されないサービスプリンシパル名を使用することをお勧めします。IAM リソースはグローバルであるため、どのリージョンでも同じロールを使用することができます。
## すべてのプリンシパル
ワイルドカード (\$1) を使用して `Principal` リソースベースのポリシーの要素またはプリンシパルをサポートする条件キーにあるすべてのプリンシパルを指定できます。*[リソースベースのポリシー](access_policies.md#policies_resource-based)*許可のアクセス権および[条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)はポリシーステートメントの条件を制限するために使用されます。
**重要**
パブリックまたは匿名アクセスを許可する意図がない限り、`Allow` の影響を伴うリソースベースのポリシーの `Principal` 要素にワイルドカード (\$1) を使用しないことを強くお勧めします。それ以外の場合は、`Principal` 要素で目的のプリンシパル、サービス、または AWS アカウントを指定して、`Condition` 要素でさらにアクセスを制限します。これは、他のプリンシパルがアカウントのプリンシパルになることを許可することから、特にIAM ロールの信頼ポリシーに当てはまります。
リソースベースポリシーでは、`Allow` 効果でワイルドカード (\$1) を使用することで、匿名ユーザー (パブリックアクセス) を含むすべてのユーザーへのアクセスが許可されます。アカウント内の IAM ユーザーおよびロールプリンシパルの場合、他のアクセス権は必要ありません。他のアカウントのプリンシパルの場合、アカウント内にリソースへのアクセスを許可する ID ベースのアクセス許可がある必要があります。これは[クロスアカウントアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)と呼ばれます。
匿名ユーザーの場合、次の要素は同等です。
```
"Principal": "*"
```
```
"Principal" : { "AWS" : "*" }
```
ワイルドカードとして使用して、プリンシパルの名前または ARN の一部に一致させることはできません。
次の例は、`Condition` 要素で指定されたものを*除いた*すべてのプリンシパルを明確に拒否する [AWS JSON ポリシーの要素: NotPrincipal](reference_policies_elements_notprincipal.md) の代わりに使用できるリソースベースのポリシーを示しています。このポリシーは [ Amazon S3 バケットに追加](https://docs.aws.amazon.com//AmazonS3/latest/userguide/add-bucket-policy.html)する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
"Effect": "Deny",
"Action": "s3:*",
"Principal": "*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:s3:::amzn-s3-demo-bucket"
],
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
}
}
}
]
}
```
------
## 詳細情報
詳細については次を参照してください:
+ 「*Amazon Simple Storage Service ユーザーガイド*」にある[バケットポリシーの例](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html)
+ [Amazon Simple Notification Service 開発者ガイド](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS)の「*Amazon SNS のポリシーの例*」
+ 「*Amazon Simple Queue Service 開発者ガイド*」にある [Amazon SQS ポリシーの例](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html)
+ 「*AWS Key Management Service 開発者ガイド*」にある[主要ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)
+ 「*AWS 全般のリファレンス*」 の「[アカウント ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html)」
+ [OIDC フェデレーション](id_roles_providers_oidc.md)
# AWS JSON ポリシーの要素: NotPrincipal
`NotPrincipal` 要素は `"Effect":"Deny"` を使用して、`NotPrincipal` 要素で指定されたプリンシパル***を除く***すべてのプリンシパルへのアクセスを拒否します。プリンシパルには、IAM ユーザー、AWS STS フェデレーションユーザーのプリンシパル、IAM ロール、引き受けたロールセッション、AWS アカウント、AWS サービス、その他のプリンシパルタイプを選択することができます。プリンシパルの詳細については、「[AWS JSON ポリシーの要素: Principal](reference_policies_elements_principal.md)」を参照してください。
`NotPrincipal` は `"Effect":"Deny"` とともに使用する必要があります。`"Effect":"Allow"` とともに使用することはサポートされていません。
**重要**
セキュリティおよび認可戦略の一環として、新しいリソースベースのポリシーに `NotPrincipal` を使用することはお勧めしません。`NotPrincipal` を使用すると、複数のポリシータイプの影響をトラブルシューティングすることが難しい場合があります。代わりに ARN 条件演算子で `aws:PrincipalArn` コンテキストキーを使用することをおすすめします。
## 重要ポイント
+ `NotPrincipal` 要素は、VPC エンドポイントを含む一部の AWS サービスのリソースベースのポリシーでサポートされています。リソースベースのポリシーは、リソースに直接埋め込むポリシーです。IAM のアイデンティティベースのポリシーでも IAM ロールの信頼ポリシーでも `NotPrincipal` 要素は使用できません。
+ アクセス許可の境界ポリシーがアタッチされている IAM ユーザーまたはロールに対する `Deny` 効果を持つ `NotPrincipal` ポリシー要素を含むリソースベースのポリシーステートメントは使用しないでください。`Deny` 効果のある `NotPrincipal` 要素は、`NotPrincipal` 要素で指定されている値に関係なく、アクセス許可の境界ポリシーがアタッチされている IAM プリンシパルを常に拒否します。これにより、本来であればリソースにアクセスできたはずの IAM ユーザーまたはロールの一部がアクセスを失うことになります。リソースベースのポリシーステートメントを変更して、`NotPrincipal` 要素ではなく [`aws:PrincipalArn`](reference_policies_condition-keys.md#condition-keys-principalarn) コンテキストキーで条件演算子 [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) を使用してアクセスを制限することをおすすめします。アクセス許可の境界の詳細については、「[IAM エンティティのアクセス許可境界](access_policies_boundaries.md)」を参照してください。
+ `NotPrincipal` を使用する場合は、拒否されていないプリンシパルのアカウントの ARN も設定する必要があります。それ以外の場合、ポリシーでは、そのプリンシパルを含むアカウント全体へのアクセスが拒否されます。ポリシーに含めるサービスに応じて、AWS は最初にアカウントを確認し、次にユーザーを確認する場合があります。引き受けたロールのユーザー (ロールを使用しているユーザー) を評価する場合、AWS は最初にアカウントを確認し、次にロール、最後にロールを引き受けたユーザーを確認する場合があります。ロールを引き受けたユーザーは、ユーザーがロールを引き受けたときに指定されたロールセッション名で識別されます。したがって、ユーザーのアカウントの ARN、またはロールの ARN とそのロールを含むアカウントの ARN の両方を、明示的に含めることを強くお勧めします。
+ `NotPrincipal` 要素は、サービスコントロールポリシー (SCP) およびリソースコントロールポリシー (RCP) ではサポートされていません。
## `NotPrincipal` 要素の代替方法
AWS でアクセスコントロールを管理する場合、指定した 1 つまたは複数のプリンシパルは例外とし、リソースへのすべてのプリンシパルアクセスを明示的に拒否する必要があるシナリオがあります。AWS では、より正確な制御とトラブルシューティングを容易にするために、グローバル条件コンテキストキーを持つ Deny ステートメントを使用することをお勧めします。次の例は、 `StringNotEquals` や `ArnNotEquals` などの条件演算子を使用して、Condition 要素で指定されたものを除くすべてのプリンシパルへのアクセスを拒否する代替アプローチを示しています。
## IAM ロールを使用したシナリオ例
Deny ステートメントを含むリソースベースのポリシーを使用すると、すべての IAM ロール (Condition 要素で指定されたロールを除く) がリソースにアクセスしたり操作したりすることを防ぐことができます。このアプローチは、明示的な拒否が常に許可ステートメントよりも優先されるという AWS セキュリティ原則に従い、AWS インフラストラクチャ全体で最小特権の原則を維持するのに役立ちます。
`NotPrincipal` を使用する代わりに、グローバル条件コンテキストキーと [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) のような条件演算子を含む Deny ステートメントを使用して、IAMロールがリソースにアクセスできるように明示的に許可することをお勧めします。次の例では、[aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) を使用して、ロール `Bucket_Account_Audit` が `read-only-role` フォルダ内の Amazon S3 バケットにアクセスすることを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyCrossAuditAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::Bucket_Account_Audit",
"arn:aws:s3:::Bucket_Account_Audit/*"
],
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::444455556666:role/read-only-role"
}
}
}
]
}
```
------
## サービスプリンシパルを使用するシナリオ例
Deny ステートメントを使用して、 `Condition` 要素で指定されたものを除くすべてのサービスプリンシパルがリソースにアクセスまたは操作できないようにすることができます。このアプローチは、きめ細かなアクセスコントロールを実装する必要がある場合や、AWS 環境内のさまざまなサービスとアプリケーション間のセキュリティ境界を確立する必要がある場合に特に役立ちます。
`NotPrincipal` を使用する代わりに、グローバル条件コンテキストキーと条件演算子 [`StringNotEquals`](reference_policies_elements_condition_operators.md#Conditions_String) を含む Deny ステートメントを使用して、サービスプリンシパルにリソースへのアクセスを明示的に許可することをお勧めします。次の例では、`aws:PrincipalServiceName` を使用して、AWS CodeBuild サービスプリンシパルが `BUCKETNAME` フォルダ内の Amazon S3 バケットにアクセスすることを明示的に許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyNotCodeBuildAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BUCKETNAME",
"arn:aws:s3:::BUCKETNAME/*"
],
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalServiceName": "codebuild.amazonaws.com"
}
}
}
]
}
```
------
# IAM JSON ポリシー要素Action
`Action` 要素は、許可または拒否される特定のアクションについて説明します。ステートメントには、`Action` または `NotAction` 要素を含める必要があります。各 AWS 製品には、そのサービスで行うことができるタスクを記述する独自のアクションセットがあります。例えば、Amazon S3のアクションのリストは、[Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html)の*ポリシーでのアクセス許可の指定*にあり、Amazon EC2 のアクションのリストは、[Amazon EC2 APIリファレンス](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-apis.html)にあり、AWS Identity and Access Management のアクションのリストは、[IAM API リファレンス](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html)に記載されています。他のサービスのアクションのリストについては、そのサービスの API リファレンス[ドキュメント](https://aws.amazon.com/documentation)を参照してください。
AWS は、ポリシー管理ワークフローの自動化を合理化するために、JSON 形式のサービス参照情報も提供します。サービスリファレンス情報を使用すると、マシンが読み取り可能なファイルから AWS のサービス 全体の使用可能なアクション、リソース、条件にアクセスできます。詳細については、「[サービス認可リファレンス」の「プログラムによるアクセスの簡素化された AWS のサービス 情報](https://docs.aws.amazon.com/service-authorization/latest/reference/service-reference.html)」を参照してください。
値は、サービス名前空間をアクションプレフィックス（`iam`、`ec2` `sqs`、`sns`、`s3` など）として使用し、許可または拒否するアクションの名前を付けて特定します。この名前は、サービスでサポートされているアクションと一致しなければいけません。プレフィックスとアクション名には、大文字と小文字の区別がありません。例えば、`iam:ListAccessKeys` は `IAM:listaccesskeys` と同じです。下記の例は、様々サービスに対する`Action`要素の例を示します。
**Amazon SQS アクション**
```
"Action": "sqs:SendMessage"
```
**Amazon EC2 アクション**
```
"Action": "ec2:StartInstances"
```
**IAM アクション**
```
"Action": "iam:ChangePassword"
```
**Amazon S3 のアクション**
```
"Action": "s3:GetObject"
```
`Action`要素には複数の値を指定することができます。
```
"Action": [ "sqs:SendMessage", "sqs:ReceiveMessage", "ec2:StartInstances", "iam:ChangePassword", "s3:GetObject" ]
```
複数文字一致ワイルドカード (`*`) と 1 文字一致ワイルドカード (`?`) を使用して、特定の AWS の製品が提供するすべてのアクションへのアクセスを許可できます。たとえば、以下の `Action` 要素はすべての S3 アクションに適用します。
```
"Action": "s3:*"
```
また、アクション名の一部にワイルドカード（`*` または `?`）を使用できます。たとえば、以下の `Action` 要素は、`AccessKey`、`CreateAccessKey`、`DeleteAccessKey`、`ListAccessKeys` などの文字列 `UpdateAccessKey` を含むすべての IAM アクションに適用されます。
```
"Action": "iam:*AccessKey*"
```
サービスの中には、使用可能なアクションに制限があるものがあります。たとえば、Amazon SQS では、使用可能なすべての Amazon SQS アクションのサブセットだけを使用することができます。この場合、`*` ワイルドカードはキューの完全なコントロールを許可せず、共有しているアクションのサブセットだけが許可されます。詳細については、[Amazon Simple Queue Service デベロッパーガイド](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/acp-overview.html#PermissionTypes)の「*アクセス許可を理解する*」を参照してください。
# IAM JSON ポリシー要素NotAction
`NotAction` は、指定されたアクションリスト*以外*のすべてを明示的に照合する高度なポリシー要素です。`NotAction` を使うと、一致するアクションの長いリストではなく、いくつかの一致しないアクションのリストが含まれるため、ポリシーが短くなります。`NotAction` で指定したアクションは、ポリシーステートメントの `Allow` または `Deny` 効果の影響を受けません。これは、`Allow` 効果を使用する場合、リストされていない該当するすべてのアクションまたはサービスが許可されることを意味します。また、`Deny` 効果を使用する場合は、リストされていないそのようなアクションやサービスは定義されません。`NotAction` を `Resource` 要素と共に使用することで、ポリシーの範囲を指定します。これにより、AWS は該当するアクションまたはサービスを決定します。詳細については、次のポリシー例を参照してください。
**Allow での NotAction の使用**
`"Effect": "Allow"` のステートメントで `NotAction` 要素を使用して、AWS サービス内で、`NotAction` で指定したアクションを除くすべてのアクションへのアクセスを許可できます。これを `Resource` 要素と共に使用してポリシーの範囲を提供し、許可されるアクションを、指定されたリソースで実行できるアクションに制限します。
次の例では、任意の S3 リソースで実行できる、バケットの削除*以外*のすべての Amazon S3 アクションにユーザーがアクセスすることを許可します。また、このポリシーでは、他のサービスのアクションも許可されません。他のサービスのアクションは S3 リソースには適用されないためです。
```
"Effect": "Allow",
"NotAction": "s3:DeleteBucket",
"Resource": "arn:aws:s3:::*",
```
多数のアクションへのアクセスを許可することが必要になる場合があります。`NotAction` 要素を使用してそのステートメントを効果的に反転させることで、アクションのリストを短くすることができます。たとえば、AWS には多数のサービスがあるため、IAM へのアクセスを除くすべてのアクションの実行をユーザーに許可するポリシーを作成することが必要になる場合があります。
以下の例では、IAM を除くすべての AWS サービスですべてのアクションへのアクセスをユーザーに許可します。
```
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
```
`NotAction` 要素と `"Effect": "Allow"` をポリシー内の同じステートメントで使用したり、別のステートメントで使用したりすることに注意してください。`NotAction` は、指定したリソースに対して明示的に列挙または適用されないすべてのサービスおよびアクションと一致するため、意図した以上のアクセス許可をユーザーに付与する結果になる場合があります。
**Deny での NotAction の使用**
`NotAction` のステートメントで`"Effect": "Deny"` 要素を使用すると、`NotAction` 要素で指定されているアクションを除いて、リストされたすべてのリソースへのアクセスを拒否できます。この組み合わせでは、リストされた項目は許可されませんが、リストされていないアクションは明示的に拒否されます。許可したいアクションを許可する必要があります。
次の条件付きの例では、ユーザーが MFA の使用にサインインしていない場合、非 IAM アクションへのアクセスを拒否しています。ユーザーが MFA でサインインした場合は、`"Condition"` テストは失敗し、最終的な `"Deny"` ステートメントは無効になります。ただし、これにより、ユーザーがアクションにアクセスすることは許可されないため、IAM アクションを除くアクションはすべて明示的に拒否されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyAllUsersNotUsingMFA",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}]
}
```
------
特定のサービスからのアクションを除き、特定のリージョン以外のアクションへのアクセスを拒否するポリシーの例については、「[AWS: リクエストされたリージョンに基づいて、AWS へのアクセスを拒否する](reference_policies_examples_aws_deny-requested-region.md)」を参照してください。
# IAM JSON ポリシー要素Resource
IAM ポリシーステートメントの `Resource` 要素では、そのステートメントが適用されるオブジェクトを 1 つ以上定義します。ステートメントには`Resource` または `NotResource` 要素を含める必要があります。
Amazon リソースネーム (ARN) を使用してリソースを指定します。ARN の形式は、AWS のサービスおよび参照先の特定のリソースによって異なります。ARN 形式はさまざまに異なっても、常に ARN を使用してリソースを識別します。ARN の形式についての詳細は、[IAM ARN](reference_identifiers.md#identifiers-arns)を参照してください。リソースの指定方法についての情報は、お客様が記述しているステートメントを適用するリソースのサービスに関するドキュメントを参照してください。
**注記**
AWS のサービスによっては、個々のリソースに対してアクションを指定できるものもあります。こうしたサービスでは、`Action` 要素または `NotAction` 要素にアクションを指定すると、アクションがそのサービスのすべてのリソースに適用されます。この場合、`Resource` 要素にはワイルドカード文字 (`*`) を使用します。
以下の例は、特定の Amazon SQS キューを示しています。
```
"Resource": "arn:aws:sqs:us-east-2:account-ID-without-hyphens:queue1"
```
以下の例は、AWS アカウント内の `Bob` という IAM ユーザーを示しています。
**注記**
`Resource` 要素では、IAM ユーザー名の大文字と小文字が区別されます。
```
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/Bob"
```
## リソース ARN でのワイルドカードの使用
ARN の個々のセグメント (コロンで区切られている部分) 内にワイルドカード文字 (`*` と `?`) を使用して、以下のものを表すことができます。
+ 文字を任意に組み合わせたもの (`*`)
+ 任意の 1 文字 (`?`)
各セグメントで複数の `*` または `?` 文字を使用できます。`*` ワイルドカードがリソース ARN セグメントの最後の文字である場合は、コロンの境界を越えて一致するように拡張できます。コロンで区切られた ARN セグメント内ではワイルドカード (`*` と `?`) を使用することをお勧めします。
**注記**
AWS 製品を識別するためにサービスセグメントでワイルドカードを使用することはできません。ARN セグメントの詳細については、「[Amazon リソースネーム (ARN) で AWS リソースを識別する](reference-arns.md)」を参照してください。
以下の例は、`/accounting` というパスを持つすべての IAM ユーザーを示しています。
```
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/accounting/*"
```
以下の例は、特定の Amazon S3 バケット内のすべての項目を示しています。
```
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
```
アスタリスク (`*`) 文字を展開して、セグメント内のすべてを置き換えることができます。サービス名前空間によっては、スラッシュ (`/`) などの文字は区切り文字として機能します。たとえば、次のような Amazon S3 ARN を考えてみます。同じワイルドカード拡張ロジックがすべてのサービスに適用されるためです。
```
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*/test/*"
```
ARN のワイルドカードは、リストされた最初のオブジェクトだけでなく、バケット内の次のすべてのオブジェクトに適用されます。
```
amzn-s3-demo-bucket/1/test/object.jpg
amzn-s3-demo-bucket/1/2/test/object.jpg
amzn-s3-demo-bucket/1/2/test/3/object.jpg
amzn-s3-demo-bucket/1/2/3/test/4/object.jpg
amzn-s3-demo-bucket/1///test///object.jpg
amzn-s3-demo-bucket/1/test/.jpg
amzn-s3-demo-bucket//test/object.jpg
amzn-s3-demo-bucket/1/test/
```
前のリストの最後の 2 つのオブジェクトを考えてみましょう。Amazon S3 オブジェクト名は、従来の区切り文字であるスラッシュ (`/`) で開始または終了できます。`/` は区切り文字として機能しますが、リソース ARN 内で使用した場合には特に意味を持ちません。これは、他の有効な文字と同じように扱われます。ARN は次のオブジェクトと一致しません。
```
amzn-s3-demo-bucket/1-test/object.jpg
amzn-s3-demo-bucket/test/object.jpg
amzn-s3-demo-bucket/1/2/test.jpg
```
## 複数のリソースの指定
ARN の配列を使用することで、`Resource` 要素に複数のリソースを指定できます。以下の例は、2 つの DynamoDB テーブルを示しています。
```
"Resource": [
"arn:aws:dynamodb:us-east-2:account-ID-without-hyphens:table/books_table",
"arn:aws:dynamodb:us-east-2:account-ID-without-hyphens:table/magazines_table"
]
```
## リソース ARN でのポリシー変数の使用
`Resource` 要素では、特定のリソースを示す ARN の一部 (つまり、ARN の末尾部分) で JSON [ポリシー変数](reference_policies_variables.md)を使用できます。たとえば、リソース ARN の一部としてキー `{aws:username}` を使用することで、現在のユーザー名をリソースの名前の一部として含める必要があることを示すことができます。以下の例は、`{aws:username}` 要素内での `Resource` キーの使用方法を示します。ポリシーは、現在のユーザー名に一致する Amazon DynamoDB テーブルへのアクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:111122223333:table/${aws:username}"
}
}
```
------
JSON ポリシー変数の詳細については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。
# IAM JSON ポリシー要素NotResource
`NotResource` は、指定されたリソースを除くすべてのリソースを明示的に照合する高度なポリシー要素です。`NotResource` を使うと、一致する予定のリソースのリストを含めるのではなく、一致する必要がないアクションがいくつかリストアップされ、リソースが短くなります。これは、単一の AWS のサービス内で適用されるポリシーで特に便利です。
たとえば、`HRPayroll`という名前のグループがあるとしましょう。`HRPayroll` のメンバーは、`Payroll` バケット内の `HRBucket` フォルダ以外のすべての Amazon S3 リソースにアクセスできません。次のポリシーは、リストされたリソース以外のすべての Amazon S3 リソースへのアクセスを明示的に拒否します。ただし、このポリシーは、すべてのリソースにユーザーのアクセス権を与えるものではないことに注意してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "s3:*",
"NotResource": [
"arn:aws:s3:::HRBucket/Payroll",
"arn:aws:s3:::HRBucket/Payroll/*"
]
}
}
```
------
通常、リソースへのアクセスを明示的に拒否するには、`"Effect":"Deny"` を使用し、各フォルダを個別にリストする`Resource` 要素を含むポリシーを作成します。ただし、その場合には、`HRBucket` にフォルダを追加するたび、またはアクセスすべきでない Amazon S3 にリソースを追加するたびに、`Resource` 要素内のリストにその名前を追加する必要があります。代わりに `NotResource` 要素を使用すると、ユーザーはフォルダ名を `NotResource` 要素に追加しない限り、新しいフォルダへのアクセスは自動的に拒否されます。
`NotResource` を使用する場合は、この要素に指定されているリソースは制限されていないリソース*のみ*であることに注意してください。これにより、アクションに適用されるすべてのリソースが制限されます。上記の例では、ポリシーは Amazon S3 アクションにのみ影響し、そのため、Amazon S3 リソースにのみ影響します。`Action` 要素に Amazon EC2 アクションも含まれている場合、`NotResource` 要素で指定されていない EC2 リソースへのアクセスはポリシーによって拒否されます。サービス内のどのアクションでリソースの ARN を指定できるかについては、「[AWS のサービスのアクション、リソース、および条件キー](reference_policies_actions-resources-contextkeys.html)」を参照してください。
## NotResource とその他の要素
`"Effect": "Allow"`、`"Action": "*"`、および `"NotResource": "arn:aws:s3:::HRBucket"` **要素を一緒に使用しないでください**。このステートメントは、`HRBucket` S3 バケットを除くすべてのリソースで AWS のすべてのアクションを許可するため、非常に危険です。これにより、ユーザーは自身に `HRBucket` へのアクセスを許可するポリシーを追加することもできます。この操作はしないでください。
`NotResource` 要素と `"Effect": "Allow"` をポリシー内の同じステートメントで使用したり、別のステートメントで使用したりすることに注意してください。`NotResource` は、明示的に列挙されないすべてのサービスおよびリソースを許可するため、意図した以上のアクセス許可をユーザーに付与する結果になる場合があります。同じステートメントで `NotResource` 要素と `"Effect": "Deny"` を使用すると、明示的にリストされていないサービスとリソースが拒否されます。
# IAM JSON ポリシー要素Condition
`Condition` 要素 (または`Condition` *block*) は、ポリシーを実行するタイミングの条件を指定することができます。`Condition` 要素はオプションです。`Condition` 要素に、[条件演算子](reference_policies_elements_condition_operators.md) (等しい、より小さい、など) を使用して、ポリシーのコンテキストキーバリューをリクエストコンテキストのキーバリューに一致させる式を構築します。リクエストコンテキストの詳細については、「[リクエストのコンポーネント](intro-structure.md#intro-structure-request)」を参照してください。
```
"Condition" : { "{condition-operator}" : { "{condition-key}" : "{condition-value}" }}
```
ポリシー条件で指定できるコンテキストキーは、[グローバル条件コンテキストキー](reference_policies_condition-keys.md)またはサービス固有のコンテキストキーです。グローバル条件コンテキストキーには、`aws:` というプレフィックスが付いています。サービス固有のコンテキストキーには、サービスのプレフィックスがあります。例えば Amazon EC2 では、`ec2:InstanceType` コンテキストキーを使用して、そのサービスに固有の条件を記述できます。`iam:` プレフィックスが付いたサービス固有の IAM コンテキストキーを表示するには、「[IAM および AWS STS の条件コンテキストキー](reference_policies_iam-condition-keys.md)」を参照してください。
コンテキストキーでは、名前の大文字と小文字が区別されません。例えば、`aws:SourceIP` コンテキストキーを含めることは、`AWS:SourceIp` をテストすることと同じです。コンテキストキーの値の大文字と小文字の区別は、使用する[条件演算子](reference_policies_elements_condition_operators.md)によって異なります。例えば、次の条件には、`john` によって行われたリクエストのみが一致するようにする `StringEquals` 演算子が含まれています。`John` という名前のユーザーはアクセスを拒否されます。
```
"Condition" : { "StringEquals" : { "aws:username" : "john" }}
```
次の条件では、[`StringEqualsIgnoreCase`](reference_policies_elements_condition_operators.md#Conditions_String) 演算子を使用して、`john` または `John` という名前のユーザーに一致させます。
```
"Condition" : { "StringEqualsIgnoreCase" : { "aws:username" : "john" }}
```
一部のコンテキストキーでは、キー名の一部を指定することができるキーバリューのペアをサポートしています。この例には、[`aws:RequestTag/tag-key`](reference_policies_condition-keys.md#condition-keys-requesttag) コンテキストキー、AWS KMS [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context)、および複数のサービスでサポートされている [`ResourceTag/tag-key`](reference_policies_condition-keys.md#condition-keys-resourcetag) コンテキストキーが含まれます。
+ [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policy-structure.html#amazon-ec2-keys) などのサービスに `ResourceTag/tag-key` コンテキストキーを使用する場合は、`tag-key` のキー名を指定する必要があります。
+ **キー名では大文字と小文字が区別されません。**つまり、ポリシーの条件要素で `"aws:ResourceTag/TagKey1": "Value1"` で指定した場合、その条件は `TagKey1` または `tagkey1` という名前のリソースタグキーに一致しますが、その両方には一致しません。
+ これらの属性をサポートする AWS サービスでは、大文字と小文字だけが異なる複数のキー名を作成することができる場合があります。例えば、`ec2=test1` および `EC2=test2` を使用して Amazon EC2 インスタンスにタグ付けします。`"aws:ResourceTag/EC2": "test1"` などの条件を使用して、そのリソースへのアクセスを許可すると、キー名は両方のタグと一致しますが、1 つの値のみが一致します。これにより、予期しない障害が発生することがあります。
**重要**
ベストプラクティスとして、キーバリューのペア属性に名前を付けるときは、アカウントのメンバーが一貫した命名規則に従うようにします。例としては、AWS KMS タグや暗号化コンテキストなどがあります。これを強制するには、タグ付けに [`aws:TagKeys`](reference_policies_condition-keys.md#condition-keys-tagkeys) コンテキストキーを使用するか、AWS KMS 暗号化コンテキストに [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context-keys](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context-keys) を使用します。
+ 条件演算子の一覧と演算子の動作の説明については、「[条件演算子](reference_policies_elements_condition_operators.md)」を参照してください。
+ 他に特定のない限り、すべてのコンテキストキーには複数の値を含むことができます。複数の値を持つコンテキストキーを処理する方法の説明については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。
+ グローバルに利用できるコンテキストキーのすべてのリストについては、[AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md) を参照してください。
+ 各サービスで定義されるコンテキストキーについては、「[AWS のサービスのアクション、リソース、および条件キー](reference_policies_actions-resources-contextkeys.html)」を参照してください。
## リクエストのコンテキスト
[プリンシパル](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal)が AWS に[リクエスト](intro-structure.md#intro-structure-request)を行うと、AWS はリクエスト情報をリクエストコンテキストに収集します。リクエストコンテキストには、プリンシパル、リソース、アクション、およびその他の環境プロパティに関する情報が含まれます。ポリシー評価は、ポリシーのプロパティを、AWS で実行できるアクションを評価および承認するためにリクエストで送信されたプロパティと照合します。
JSON ポリシーの `Condition` 要素を使用して、リクエストコンテキストに対して特定のコンテキストキーをテストできます。例えば、[aws:CurrentTime](reference_policies_condition-keys.md#condition-keys-currenttime) コンテキストキーを使用するポリシーを作成して、[特定の日付範囲内でのみアクションの実行をユーザーに許可できます](reference_policies_examples_aws-dates.md)。
以下の例は、Martha Rivera が MFA デバイスを非アクティブ化するリクエストを送信したときのリクエストコンテキストを示しています。
```
Principal: AROA123456789EXAMPLE
Action: iam:DeactivateMFADevice
Resource: arn:aws:iam::user/martha
Context:
– aws:UserId=AROA123456789EXAMPLE:martha
– aws:PrincipalAccount=1123456789012
– aws:PrincipalOrgId=o-example
– aws:PrincipalARN=arn:aws:iam::1123456789012:assumed-role/TestAR
– aws:MultiFactorAuthPresent=true
– aws:MultiFactorAuthAge=2800
– aws:CurrentTime=...
– aws:EpochTime=...
– aws:SourceIp=...
```
リクエストコンテキストは、過去 1 時間 (3,600 秒) に MFA を使用してサインインした場合にのみ、ユーザーが自分の多要素認証 (MFA) デバイスを削除することを許可するポリシーに対して照合されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AllowRemoveMfaOnlyIfRecentMfa",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}",
"Condition": {
"NumericLessThanEquals": {"aws:MultiFactorAuthAge": "3600"}
}
}
}
```
------
この例では、ポリシーはリクエストコンテキストに一致します。アクションは同じで、リソースは「\$1」ワイルドカードに一致し、`aws:MultiFactorAuthAge` の値は 3600 未満の 2800 であるため、ポリシーはこの認可リクエストを許可します。
AWS はポリシー内の各コンテキストキーを評価し、*true* または *false* の値を返します。リクエストに存在しないコンテキストキーは、不一致と見なされます。
リクエストコンテキストは次の値を返すことができます。
+ **True** – リクエスタが過去 1 時間以内に MFA を使用してサインインした場合、条件は *true* を返します。
+ **False** – リクエスタが MFA を使用して 1 時間以上前にサインインした場合、条件は *false* を返します。
+ **Not present** – AWS CLI リクエスタがまたは AWS API の IAM ユーザーアクセスキーを使用してリクエストを行った場合、キーは存在しません。この場合、キーは存在せず、一致しません。
**注記**
場合によっては、条件キー値が存在しないときでも true が返されることがあります。例えば、`ForAllValues` 修飾子を追加すると、コンテキストキーがリクエストに存在しない場合、リクエストは true を返します。欠落しているコンテキストキーや空の値を持つコンテキストキーが True と評価されないようにするには、コンテキストキーが存在し、その値が null でないかどうかをチェックするために `false` 値を使用する [Null 条件演算子](reference_policies_elements_condition_operators.md#Conditions_Null) をポリシーに含めることができます。
## 条件ブロック
以下の例は、`Condition`要素の基本フォーマットを示します。
```
"Condition": {"StringLike": {"s3:prefix": ["jane/*"]}}
```
リクエストからの値は、コンテキストキーによって表現されます。この場合は `s3:prefix` です。コンテキストキーバリューは、`jane/*` などのリテラル値として指定した値と比較されます。比較の種類は、[条件演算子](reference_policies_elements_condition_operators.md)によって指定されます (ここでは `StringLike`)。等号、大なり記号、小なり記号といった一般的なブール演算子を使用して、文字列、日付、数値などを比較する条件を作成できます。[文字列演算子](reference_policies_elements_condition_operators.md#Conditions_String)または [ARN 演算子](reference_policies_elements_condition_operators.md#Conditions_ARN)を使用する場合は、コンテキストキーの値に[ポリシー変数](reference_policies_variables.md)を使用することもできます。次の例では、`aws:username` 変数が含まれています。
```
"Condition": {"StringLike": {"s3:prefix": ["${aws:username}/*"]}}
```
一部の環境では、コンテキストキーに複数の値が含まれる可能性があります。たとえば、Amazon DynamoDB へのリクエストによって、テーブルの複数の属性を返すまたは更新することが要求される場合があります。DynamoDB テーブルへのアクセスのポリシーには、リクエスト内のすべての属性を含む `dynamodb:Attributes` コンテキストキーを追加できます。`Condition` 要素で設定演算子を使用することで、リクエスト内のすべての属性を、ポリシー内の許可された属性のリストと照合できます。詳細については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。
リクエスト中にポリシーが評価される際、AWS はキーをリクエストからの対応する値に置き換えます。（この例では、AWS はリクエストの日時を使用します。) 条件が評価された上で「true（真）」または「false（偽）」が返され、それを考慮に入れてポリシー全体がリクエストを許可または拒否します。
### 条件内の複数の値
`Condition` 要素は複数の条件演算子を含むことができ、各条件演算子は複数のキーと値のペアを含むことができます。以下の図が解説したものです。
![\[2 つの条件演算子のブロック図。最初のブロックには 2 つのコンテキストキープレースホルダーが含まれていて、それぞれに複数の値があります。2 番目の条件ブロックには、複数の値を持つ 1 つのコンテキストキーが含まれます。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block.diagram.png)
詳細については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。
# IAM JSON ポリシー要素: 条件演算子
`Condition` 要素で条件演算子を使用して、ポリシーの条件キーバリューをリクエストコンテキストの値と一致させます。`Condition` 要素の詳細については、「[IAM JSON ポリシー要素Condition](reference_policies_elements_condition.md)」を参照してください。
ポリシーで使用できる条件演算子は、選択する条件キーによって異なります。グローバル条件キーまたはサービス固有の条件キーを選択できます。グローバル条件キーに使用できる条件演算子については、「[AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md)」を参照してください。サービスのサービス固有の条件キーを表示するには、「[AWS サービスのアクション、リソース、および条件キー](reference_policies_actions-resources-contextkeys.html)」を参照し、キーを表示するサービスを選択します。
**重要**
ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致せず条件は false になります。`StringNotLike` または `ArnNotLike` などのように、キーの一致を必要としないポリシー条件であり、かつ正しいキーが存在していない場合、条件は *true* となります。このロジックは、[...IfExists](#Conditions_IfExists) および [Null check](#Conditions_Null) を除くすべての条件演算子に適用されます。これらの演算子は、キーがリクエストコンテキストにある（存在する）かどうかをテストします。
条件演算子は次のカテゴリに分類できます。
+ [文字列](#Conditions_String)
+ [数値](#Conditions_Numeric)
+ [日付および時間](#Conditions_Date)
+ [ブール値](#Conditions_Boolean)
+ [バイナリ](#Conditions_BinaryEquals)
+ [IP アドレス](#Conditions_IPAddress)
+ [Amazon リソースネーム (ARN)](#Conditions_ARN) (一部のサービスでのみ使用可能)
+ [...IfExists](#Conditions_IfExists) (別のチェックの一部としてキーバリューが存在するかを確認)
+ [Null check](#Conditions_Null) (スタンドアロンチェックとしてキーが存在するかを確認)
## 文字列条件演算子
文字列条件演算子では、キーと文字列値の比較に基づいてアクセスを制限する `Condition` 要素を構築できます。
+ **ポリシー変数** - [サポート](reference_policies_variables.md)
+ **ワイルドカード** – [サポート](#Conditions_String-wildcard)
****
| 条件演算子 | 説明 |
| --- | --- |
| `StringEquals` | 完全一致、大文字と小文字の区別あり。 |
| `StringNotEquals` | 符号反転の一致 |
| `StringEqualsIgnoreCase` | 完全一致、大文字と小文字の区別なし。 |
| `StringNotEqualsIgnoreCase` | 符号反転の一致、大文字と小文字の区別なし。 |
| `StringLike` | 大文字と小文字の区別がある一致。値には、複数文字一致のワイルドカード (\$1) および 1 文字一致のワイルドカード (?) を文字列のどこにでも含めることができます。文字列の部分一致検索を行うには、ワイルドカードを指定する必要があります。 キーに複数の値が含まれる場合、設定演算子 (`StringLike` および `ForAllValues:StringLike`) を使用して `ForAnyValue:StringLike` を修飾できます。詳細については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。 |
| `StringNotLike` | 符号反転の一致には、大文字と小文字の区別があります。値には、複数文字一致のワイルドカード (\$1) または 1 文字一致のワイルドカード (?) を文字列のどこにでも含めることができます。 |
**Example 文字列条件演算子**
たとえば、次のステートメントに含まれている `Condition` 要素では、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag) キーの使用により、リクエストを行うプリンシパルに `iamuser-admin` ジョブカテゴリのタグ付けが必要であることを指定しています。
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
}
}
}
}
```
ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。この例では、タグがアタッチされた IAM ユーザーをプリンシパルが使用している場合、`aws:PrincipalTag/job-category` キーがリクエストコンテキストに存在します。これは、タグまたはセッションタグがアタッチされた IAM ロールを使用するプリンシパルのために含まれます。タグがないユーザーがアクセスキーを表示または編集しようとすると、条件により `false` が返され、リクエストはこのステートメントによって暗黙的に拒否されます。
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | aws:PrincipalTag/job-category:
– iamuser-admin
| 一致 |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | aws:PrincipalTag/job-category:
– dev-ops
| 一致なし |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | リクエストコンテキストに `aws:PrincipalTag/job-category` はありません。 | 一致なし |
**Example 文字列条件演算子を含むポリシー変数の使用**
以下の例では、`StringLike` 条件演算子を使用して[ポリシー変数](reference_policies_variables.md)による文字列一致を実行して、IAM ユーザーが Amazon S3 コンソールを使用して Amazon S3 バケット内の自らの「ホームディレクトリ」を管理できるようにするポリシーを作成します。このポリシーは、`s3:prefix` が指定されたパターンのいずれかに一致する限り、指定されたアクションを S3 バケットに対して実行することを許可します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]
}
}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
]
}
]
}
```
次の表は、AWS がリクエストコンテキストの [aws:username](reference_policies_condition-keys.md#condition-keys-username) 値に基づいて、さまざまなユーザーに対してこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | aws:username:
– martha_rivera
| "StringLike": {
"s3:prefix": [
"home/",
"home/martha_rivera/"
]
} |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | aws:username:
– nikki_wolf
| "StringLike": {
"s3:prefix": [
"home/",
"home/nikki_wolf/"
]
} |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | リクエストコンテキストに `aws:username` はありません。 | 一致なし |
OIDC フェデレーションによるアプリケーション ID とユーザー ID に基づいてリソースへのアクセスを制限する `Condition` 要素の使用方法を示すポリシーの例については、「[Amazon S3: Amazon Cognito ユーザーにバケット内のオブジェクトへのアクセスを許可する](reference_policies_examples_s3_cognito-bucket.md)」を参照してください。
### 複数値の文字列条件演算子
リクエストのキーに複数の値が含まれる場合、文字列演算子は集合演算子 (`ForAllValues` および `ForAnyValue`) で修飾できます。複数のコンテキストキーまたは値の評価ロジックの詳細については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。
| 条件演算子 | 説明 |
| --- | --- |
| `ForAllValues:StringEquals` `ForAllValues:StringEqualsIgnoreCase` | リクエストの条件キーのすべての値は、ポリシーの値の少なくとも 1 つと一致する必要があります。 |
| `ForAnyValue:StringEquals` `ForAnyValue:StringEqualsIgnoreCase` | リクエストの少なくとも 1 つの条件キー値が、ポリシーの値のいずれかと一致する必要があります。 |
| `ForAllValues:StringNotEquals` `ForAllValues:StringNotEqualsIgnoreCase` | 符号反転の一致。 リクエストのコンテキストキーの値が、ポリシーのコンテキストキー値のいずれにも一致しません。 |
| `ForAnyValue:StringNotEquals` `ForAnyValue:StringNotEqualsIgnoreCase` | 符号反転の一致。 リクエストの少なくとも 1 つのコンテキストキーの値が、ポリシーのコンテキストキーの値のいずれにも一致しない必要があります。 |
| `ForAllValues:StringLike` | リクエストの条件キーのすべての値は、ポリシーの値の少なくとも 1 つと一致する必要があります。 |
| `ForAnyValue:StringLike` | リクエストの少なくとも 1 つの条件キー値が、ポリシーの値のいずれかと一致する必要があります。 |
| `ForAllValues:StringNotLike` | 符号反転の一致。 リクエストのコンテキストキーの値が、ポリシーのコンテキストキー値のいずれにも一致しません。 |
| `ForAnyValue:StringNotLike` | 符号反転の一致。 リクエストの少なくとも 1 つのコンテキストキーの値が、ポリシーのコンテキストキーの値のいずれにも一致しない必要があります。 |
**Example 文字列条件演算子を含む `ForAnyValue` の使用**
この例では、Amazon EC2 `CreateTags` アクションを使用してタグをインスタンスにアタッチできるようにする、ID ベースのポリシーを作成する方法を示しています。`StringEqualsIgnoreCase` を使用するとき、タグをアタッチできるのは、タグに `environment` キーとともに、`preprod` または `storage` の値が含まれている場合だけです。演算子に `IgnoreCase` を追加すると、`preprod`、`Preprod`、`PreProd` など True に解決されるよう既存のタグ値の大文字化を許可します。
[aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) 条件キーで `ForAnyValue` 修飾子を追加するとき、リクエストの少なくとも 1 つのタグキー値が値 `environment` と一致する必要があります。`ForAnyValue` の比較では大文字と小文字が区別されるため、`environment` の代わりに `Environment` を使用するなど、ユーザーはタグキーに大文字と小文字が同じでない文字を使用できなくなります。
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
}
}
}
}
```
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
aws:RequestTag/environment:
– preprod
| 一致 |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
– costcenter
aws:RequestTag/environment:
– PreProd
| 一致 |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– Environment
aws:RequestTag/Environment:
– preprod
| 一致なし |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– costcenter
aws:RequestTag/environment:
– preprod
| 一致なし |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | リクエストコンテキストに `aws:TagKeys` はありません。 aws:RequestTag/environment:
– storage
| 一致なし |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
リクエストコンテキストに `aws:RequestTag/environment` はありません。 | 一致なし |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | リクエストコンテキストに `aws:TagKeys` はありません。 リクエストコンテキストに `aws:RequestTag/environment` はありません。 | 一致なし |
### ワイルドカードによる一致
文字列条件演算子は、事前に定義された形式を適用しないパターンレスマッチングを実行します。ARN 条件演算子と日付条件演算子は、条件キー値に構造体を適用する文字列演算子のサブセットです。
キーを比較する値に対応する条件演算子の使用をお勧めします。例えば、キーと文字列値を比較するときは [文字列条件演算子](#Conditions_String) を使用してください。同様に、キーと ARN 値を比較するときは [Amazon リソースネーム (ARN) の条件演算子](#Conditions_ARN) を使用してください。
**Example**
この例では、組織内のリソースの境界を作成する方法を示します。このポリシーの条件は、アクセスされるリソースが AWS Organizations の組織単位 (OUs) の特定のセットにある場合を除き、Amazon S3 アクションへのアクセスを拒否します。AWS Organizations パスは、組織エンティティの構造をテキストで表記したものです。
条件では、`aws:ResourceOrgPaths` にリストされた OU パスのいずれかが含まれている必要があります。`aws:ResourceOrgPaths` は複数値条件であるため、ポリシーは `ForAllValues:StringNotLike` 演算子を使用して `aws:ResourceOrgPaths` の値をポリシーに含まれる OU のリストと比較します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyS3AccessOutsideMyBoundary",
"Effect": "Deny",
"Action": [
"s3:*"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
}
}
}
]
}
```
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | aws:ResourceOrgPaths:
– o-acorg/r-acroot/ou-acroot-sportsou/costcenter/
| 一致 |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | aws:ResourceOrgPaths:
– o-acorg/r-acroot/ou-acroot-mediaou/costcenter/
| 一致なし |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | リクエストに `aws:ResourceOrgPaths:` はありません。 | 一致なし |
## 数値条件演算子
数値条件演算子では、キーと整数または 10 進値の比較に基づいてアクセスを制限する `Condition` 要素を構築できます。
+ **ポリシー変数** – サポート外
+ **ワイルドカード** - サポート外
****
| 条件演算子 | 説明 |
| --- | --- |
| `NumericEquals` | 一致 |
| `NumericNotEquals` | 符号反転の一致 |
| `NumericLessThan` | 「未満」の部分一致 |
| `NumericLessThanEquals` | 「未満と等しい」の部分一致 |
| `NumericGreaterThan` | 「上回る」の部分一致 |
| `NumericGreaterThanEquals` | 「上回るまたは等しい」の部分一致 |
たとえば、以下のステートメントに含まれる `Condition` 要素は、`NumericLessThanEquals` 条件演算子を `s3:max-keys` キーと合わせて使用して、リクエスタが * の中で一度に*最大`amzn-s3-demo-bucket` 10 個のオブジェクトを列挙できることを指定しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {"NumericLessThanEquals": {"s3:max-keys": "10"}}
}
}
```
------
ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。この例では、`ListBucket` オペレーションを実行すると、`s3:max-keys` キーは常にリクエストに存在します。このポリシーですべての Amazon S3 オペレーションが許可されている場合、10 以下の値を持つ `max-keys` コンテキストキーを含むオペレーションのみが許可されます。
## 日付条件演算子
日付条件演算子では、キーと日付/時刻値の比較に基づいてアクセスを制限する `Condition` 要素を構築できます。これらの条件演算子は、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-currenttime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-currenttime) キーまたは [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-epochtime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-epochtime) キーと合わせて使用します。日付/時間値と共に、[W3C implementations of the ISO 8601 date formats](http://www.w3.org/TR/NOTE-datetime) またはエポック (UNIX) 時間のどれか 1 つを特定しなければいけません。
+ **ポリシー変数** – サポート外
+ **ワイルドカード** - サポート外
****
| 条件演算子 | 説明 |
| --- | --- |
| `DateEquals` | 特定の日付との一致 |
| `DateNotEquals` | 符号反転の一致 |
| `DateLessThan` | 特定の日時よりも前の日時との一致 |
| `DateLessThanEquals` | 特定の日時またはそれよりも前の日時との一致 |
| `DateGreaterThan` | 特定の日時よりも後の日時との一致 |
| `DateGreaterThanEquals` | 特定の日時またはそれよりも後の日時との一致 |
例えば、次のステートメントには、`DateGreaterThan` 条件演算子を [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tokenissuetime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tokenissuetime) キーとともに使用する `Condition` 要素が含まれています。この条件は、リクエストの作成に使用された一時的なセキュリティ認証情報が 2020 年に発行されたことを示します。このポリシーは、毎日プログラムによって更新され、アカウントメンバーが最新の資格情報を使用するようにできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"DateGreaterThan": {
"aws:TokenIssueTime": "2020-01-01T00:00:01Z"
}
}
}
}
```
------
ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。プリンシパルがリクエストを行うために一時的な認証情報を使用する場合に限り、リクエストコンテキストで `aws:TokenIssueTime` キーが表示されます。このキーは、アクセスキーを使用して行われたAWS CLI、AWS API、または AWS SDK リクエストには存在しません。この例では、IAM ユーザーがアクセスキーを表示または編集しようとすると、リクエストは拒否されます。
## ブール条件演算子
ブール条件演算子では、キーと `true` または `false` の比較に基づいてアクセスを制限する `Condition` 要素を構築できます。
キーに複数の値が含まれる場合、ブール型演算子は集合演算子 `ForAllValues` および `ForAnyValue` で修飾できます。複数のコンテキストキーまたは値の評価ロジックの詳細については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。
+ **ポリシー変数** - [サポート](reference_policies_variables.md)
+ **ワイルドカード** - サポート外
****
| 条件演算子 | 説明 |
| --- | --- |
| `Bool` | ブールの一致 |
| `ForAllValues:Bool` | Bool データ型の配列で使用します。コンテキストキー値のすべてのブール値は、ポリシーのブール値と一致する必要があります。 `ForAllValues` 演算子が欠落しているコンテキストキーまたは空の値のコンテキストキーを Allowed と評価しないように、ポリシーに [Null 条件演算子](#Conditions_Null)を含めることができます。 |
| `ForAnyValue:Bool` | Bool データ型の配列とともに使用します。コンテキストキー値の少なくとも 1 つのブール値は、ポリシーのブール値と一致する必要があります。 |
**Example ブール条件演算子**
次の ID ベースのポリシーでは [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-securetransport](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-securetransport) キーを持つ `Bool` 条件演算子が使用されるため、リクエストが SSL 経由でない場合に、オブジェクトとオブジェクトタグを送信先バケットとそのコンテンツに複製することを拒否できます。
このポリシーでは、アクションを許可しません。特定のアクションを許可する他のポリシーと組み合わせてこのポリシーを使用します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "BooleanExample",
"Action": "s3:ReplicateObject",
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "Bool": {
"aws:SecureTransport": "false"
} | aws:SecureTransport:
– false
| 一致 |
| "Bool": {
"aws:SecureTransport": "false"
} | aws:SecureTransport:
– true
| 一致なし |
| "Bool": {
"aws:SecureTransport": "false"
} | リクエストコンテキストに `aws:SecureTransport` はありません。 | 一致なし |
## バイナリ条件演算子
`BinaryEquals` 条件演算子では、バイナリ形式のキーバリューをテストする `Condition` 要素を構築できます。これは、指定されたキーの値を、ポリシー内の値を [base-64](https://en.wikipedia.org/wiki/Base64) エンコードした表現に対してバイト単位で比較します。ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。
+ **ポリシー変数** – サポート外
+ **ワイルドカード** - サポート外
```
"Condition" : {
"BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
}
}
```
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | key:
– QmluYXJ5VmFsdWVJbkJhc2U2NA==
| 一致 |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | key:
– ASIAIOSFODNN7EXAMPLE
| 一致なし |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | リクエストコンテキストに `key` はありません。 | 一致なし |
## IP アドレス条件演算子
IP アドレス条件演算子では、キーと IPv4 または IPv6 アドレスまたは IP アドレス範囲の比較に基づいてアクセスを制限する `Condition` 要素を構築できます。これらを [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip) キーと合わせて使用します。値は、標準的な CIDR 形式でなければいけません (例 : 203.0.113.0/24 または 2001:DB8:1234:5678::/64)。IP アドレスの指定時に関連付けられたルーティングプレフィックスを使用しないと、IAM ではデフォルトのプレフィックス値 `/32` を使用します。
IPv6 をサポートしている AWS のサービスでは、0 の範囲を :: で表します。サービスで IPv6 がサポートされているかどうかは、そのサービスのドキュメントを参照してください。
+ **ポリシー変数** – サポート外
+ **ワイルドカード** - サポート外
****
| 条件演算子 | 説明 |
| --- | --- |
| `IpAddress` | 所定の IP アドレスまたは範囲 |
| `NotIpAddress` | 所定の IP アドレスまたは範囲以外のすべての IP アドレス |
**Example IP アドレス条件演算子**
次のステートメントでは、`IpAddress` 条件を `aws:SourceIp` キーと合わせて使用して、リクエストが 203.0.113.0 から 203.0.113.255 までの IP 範囲から送られてこなければいけないことを指定しています。
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
}
```
`aws:SourceIp` 条件キーは、リクエストの送信元である IP アドレスに解決します。リクエストが Amazon EC2 インスタンスから発信された場合、`aws:SourceIp` はインスタンスのパブリックIPアドレスに評価されます。
ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。`aws:SourceIp` キーは、リクエスタが VPC エンドポイントを使用してリクエストを行う場合を除き、リクエストコンテキストに常に表示されます。この場合、条件は `false` を返し、リクエストはこのステートメントによって暗黙的に拒否されます。
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
} | aws:SourceIp:
– 203.0.113.1
| 一致 |
| "IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
} | aws:SourceIp:
– 198.51.100.1
| 一致なし |
次の例では、組織内の有効な IP アドレスすべてを含めるために、IPv4 と IPv6 アドレスを混在させる方法を示しています。IPv6 への移行に合わせてポリシーが引き続き機能することを確認するため、すでにある IPv4 の範囲に追加する IPv6 アドレスの範囲の組織のポリシーを更新することをお勧めします。
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "someservice:*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"203.0.113.0/24",
"2001:DB8:1234:5678::/64"
]
}
}
}
}
```
`aws:SourceIp` 条件キーは、テストされた API をユーザーとして直接呼び出す場合に JSON ポリシーでのみ機能します。代わりにサービスを使用してターゲットサービスを呼び出した場合、ターゲットサービスは元のユーザーの IP アドレスではなく呼び出し元サービスの IP アドレスを認識します。これは、AWS CloudFormation を使用して Amazon EC2 を呼び出すことでインスタンスを自動的に作成した場合などに生じることがあります。現在のところ、JSON ポリシーで評価を行うために、発信元サービスを通じて元の IP アドレスをターゲットサービスに渡す方法はありません。これらのタイプのサービス API 呼び出しでは、`aws:SourceIp` 条件キーを使用しないでください。
## Amazon リソースネーム (ARN) の条件演算子
Amazon Resource Name (ARN) 条件演算子では、キーと ARN の比較に基づいてアクセスを制限する `Condition` 要素を構築できます。ARN は文字列として見なされます。
+ **ポリシー変数** - [サポート](reference_policies_variables.md)
+ **ワイルドカード** – [サポート](reference_policies_elements_resource.md#reference_policies_elements_resource_wildcards)
****
| 条件演算子 | 説明 |
| --- | --- |
| `ArnEquals`, `ArnLike` | ARN の大文字と小文字を区別した一致。ARN のコロンで分割された 6 個の各構成要素は個別に確認され、それぞれ複数文字一致のワイルドカード (\$1) または 1 文字一致のワイルドカード (?) を含むことができます。`ArnEquals` および `ArnLike` 条件演算子は、同じように動作します。 |
| `ArnNotEquals`, `ArnNotLike` | ARN の符号反転の一致。`ArnNotEquals` および `ArnNotLike` 条件演算子は、同じように動作します。 |
**Example ARN 条件演算子**
次のリソースベースのポリシーの例は、SNS メッセージの送信先となる Amazon SQS キューにアタッチされたポリシーを示しています。この例では、サービスが 1 つまたは複数の特定の Amazon SNS トピックのためにメッセージを送る場合に限り、1 つまたは複数のキューにメッセージを送る Amazon SNS 許可を付与しています。`Resource` フィールドのキューを指定し、`SourceArn` キーの値として Amazon SNS トピックを指定します。
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:123456789012:QUEUE-ID",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-east-1:123456789012:TOPIC-ID"
}
}
}
}
```
[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) キーは、リソース所有者に代わって別のサービスを呼び出すようにリソースがトリガーした場合にのみ、リクエストコンテキストに表示されます。IAM ユーザーがこのオペレーションを直接実行しようとすると、条件によ `false` が返され、リクエストはこのステートメントによって暗黙的に拒否されます。
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | aws:SourceArn:
– arn:aws:sns:us-west-2:123456789012:TOPIC-ID
| 一致 |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | aws:SourceArn:
– arn:aws:sns:us-west-2:777788889999:TOPIC-ID
| 一致なし |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | リクエストコンテキストに `aws:SourceArn` はありません。 | 一致なし |
### 複数値 ARN 条件演算子
リクエストのキーに複数の値が含まれる場合、ARB 演算子は集合演算子 (`ForAllValues` および `ForAnyValue`) で修飾できます。複数のコンテキストキーまたは値の評価ロジックの詳細については、「[複数値のコンテキストキーの演算子を設定する](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)」を参照してください。
| 条件演算子 | 説明 |
| --- | --- |
| `ForAllValues:ArnEquals` `ForAllValues:ArnLike` | リクエストコンテキストのすべての ARN は、ポリシーの ARN パターンの少なくとも 1 つと一致する必要があります。 |
| `ForAnyValue:ArnEquals` `ForAnyValue:ArnLike` | リクエストコンテキストの少なくとも 1 つの ARN は、ポリシーの ARN パターンのいずれかと一致する必要があります。 |
| `ForAllValues:ArnNotEquals` `ForAllValues:ArnNotLike` | 符号反転の一致。 リクエストコンテキストの ARN のいずれも、ポリシー内の文字列 ARN パターンと一致してはいけません。 |
| `ForAnyValue:ArnNotEquals` `ForAnyValue:ArnNotLike` | 符号反転の一致。 リクエストコンテキストの少なくとも 1 つの ARN は、ポリシーのどの ARN パターンとも一致してはいけません。 |
**Example ARN 条件演算子で `ForAllValues` を使用する**
以下の例では、`ForAllValues:ArnLike` を使用して Amazon CloudWatch Logs ログの論理配信ソースを作成または更新します。条件ブロックには、リクエストで渡されたログ生成リソース ARN をフィルタリングする条件キー [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchlogs.html#amazoncloudwatchlogs-policy-keys](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchlogs.html#amazoncloudwatchlogs-policy-keys) が含まれています。この条件演算子を使用する場合、リクエストのすべての ARN がポリシーの少なくとも 1 つの ARN と一致する必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutDeliverySource",
"Resource": "arn:aws:logs:us-east-1:123456789012:delivery-source:*",
"Condition": {
"ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws:cloudfront::123456789012:distribution/*",
"arn:aws:cloudfront::123456789012:distribution/support*"
]
}
}
}
]
}
```
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
| 一致 |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
– arn:aws::cloudfront:123456789012:distribution/support2025
| 一致 |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
– arn:aws::cloudfront:123456789012:distribution/admin
| 一致なし |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:777788889999:distribution/costcenter
| 一致なし |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | リクエストコンテキストに `logs:LogGeneratingResourceArns` はありません。 | 一致 |
`ForAllValues` 修飾子は、リクエストにコンテキストキーがない場合、またはコンテキストキーの値が null データセット (空の文字列など) に解決される場合、True を返します。欠落しているコンテキストキーや空の値を持つコンテキストキーが True と評価されないようにするには、コンテキストキーが存在し、その値が null でないかどうかをチェックするために `false` 値を使用する [Null 条件演算子](#Conditions_Null) をポリシーに含めることができます。
## IfExists 条件演算子
`Null` 条件 (`StringLikeIfExists` など) を除く任意の条件演算子名の末尾に `IfExists` を追加できます。「条件キーがリクエストのコンテキストで存在する場合、ポリシーで指定されたとおりにキーを処理します。キーが存在しない場合、条件要素は true と評価されます。」 `...IfExists` でチェックすると、ステートメント内の別の Condition 要素は一致なしの結果となることもありますが、キーが見つからないことはありません。`StringNotEqualsIfExists` のような否定条件演算子を持つ `"Effect": "Deny"` 要素を使用している場合は、条件キーがなくてもリクエストが拒否されます。
**`IfExists` の使用例**
多くの条件キーは特定のタイプのリソースに関する情報を示し、そのタイプのリソースにアクセスしている場合にのみ存在します。これらの条件キーはその他のタイプのリソースにはありません。ポリシーステートメントが 1 種類のリソースのみに適用される場合には、これで問題はありません。ところが、ポリシーステートメントが複数のサービスからアクションを参照する場合や、サービス内の特定のアクションが同じサービス内の異なるタイプのリソースにアクセスする場合などのように、1 つのステートメントが複数のタイプのリソースに適用される場合があります。このような場合、ポリシーステートメント内の 1 つのリソースのみに適用される条件キーを含めると、ポリシーステートメントの `Condition` 要素が失敗し、ステートメントの `"Effect"` は適用されません。
たとえば、次のポリシーの例を考えてみます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "THISPOLICYDOESNOTWORK",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {"StringLike": {"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]}}
}
}
```
------
前述のポリシーの*目的*は、ユーザーが `t1`、`t2`および `m3` タイプのインスタンスを起動できるようにすることです。ところが、インスタンスを起動する場合には、インスタンス自体に加えて、イメージ、キーペア、セキュリティグループおよびそれ以上のさまざまなリソースにアクセスする必要があります。ステートメント全体が、インスタンスを起動するために必要なすべてのリソースに対して評価されます。これらの追加のリソースには `ec2:InstanceType` 条件キーがないため、`StringLike` のチェックは失敗し、ユーザーは*いずれの*タイプのインスタンスも起動できません。
これに対応するには、`StringLikeIfExists` 条件演算子を代わりに使用します。そうすれば、条件キーが存在する場合のみにテストが行われます。以下のコードは次のように解釈できます。「チェックされるリソースには 「`ec2:InstanceType`」条件キーがあり、キーバリューが `t1.`、`t2.`、または `m3.` で始まる場合にのみ、アクションを許可します。チェックされるリソースにこの条件キーがなくても問題ありません。」 条件キー値のアスタリスク (\$1) を `StringLikeIfExists` 条件演算子と併用すると、ワイルドカードとして解釈され、文字列の一部が一致します。この `DescribeActions` 文には、コンソールでインスタンスを表示するために必要なアクションが含まれます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunInstance",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
}
}
},
{
"Sid": "DescribeActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeVpcs",
"ec2:DescribeKeyPairs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
]
}
```
------
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | ec2:InstanceType:
– t1.micro
| 一致 |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | ec2:InstanceType:
– m2.micro
| 一致なし |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | リクエストコンテキストに `ec2:InstanceType` はありません。 | 一致 |
## 条件キーの有無をチェックする条件演算子
`Null` 条件演算子を使用して、認可時に条件キーが存在していないかどうかを確認します。ポリシーステートメントで、`true`（キーは存在しません-nullです）または `false`（キーが存在し、その値はnullではありません）を使用します。
`Null` 条件演算子で[ポリシー変数](reference_policies_variables.md)を使用することはできません。
例えば、ユーザーが一時的な認証情報または独自の認証情報を使用してリクエストを行っているか判断するため、この条件演算子を使用することができます。ユーザーが一時的な認証情報を使用している場合、キー `aws:TokenIssueTime` が存在し、このキーには値があります。以下の例では、ユーザーが Amazon EC2 API を使用するために一時的な認証情報 (キーは欠落してはならない) を使用する必要があることを表記する条件が示されています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":{
"Action":"ec2:*",
"Effect":"Allow",
"Resource":"*",
"Condition":{"Null":{"aws:TokenIssueTime":"false"}}
}
}
```
------
# 複数のコンテキストキーまたは値による条件
ポリシーの `Condition` 要素を使用して、リクエスト内の 1 つのコンテキストキーに対して複数のコンテキストキーまたは値をテストできます。プログラムまたは AWS を通じて AWS マネジメントコンソール にリクエストを行うと、リクエストにはプリンシパル、オペレーション、タグなどに関する情報が含まれます。コンテキストキーを使用すると、ポリシー条件で指定したコンテキストキーで、リクエスト内の一致するコンテキストキーの値をテストできます。リクエストに含まれる情報とデータについては、「[リクエストのコンテキスト](reference_policies_elements_condition.md#AccessPolicyLanguage_RequestContext)」を参照してください。
**Topics**
+ [複数のキーまたは値の評価ロジック](#reference_policies_multiple-conditions-eval)
+ [否定された一致条件演算子の評価ロジック](#reference_policies_multiple-conditions-negated-matching-eval)
## 複数のキーまたは値の評価ロジック
`Condition` 要素は複数の条件演算子を含むことができ、各条件演算子は複数のキーと値のペアを含むことができます。特に指定のない限り、ほとんどのコンテキストキーで複数の値を使用できます。
+ ポリシーステートメントに複数の[条件演算子](reference_policies_elements_condition_operators.md)がある場合、条件演算子は論理 `AND` を使用して評価されます。
+ 1 つの条件演算子にアタッチされている複数のコンテキストキーがポリシーステートメントにある場合、コンテキストキーは論理 `AND` を使用して評価されます。
+ 1 つの条件演算子に 1 つのコンテキストキーの値が複数含まれる場合、それらの値は論理 `OR` を使用して評価されます。
+ 1 つの否定された一致条件演算子に 1 つのコンテキストキーの値が複数含まれる場合、それらの値は論理 `NOR` を使用して評価されます。
Condition 要素のブロックのすべてのコンテキストキーを true に変換して、目的の `Allow` または `Deny` 効果を呼び出す必要があります。次の図は、複数の条件演算子およびコンテキストのキーと値のペアを含む条件の評価ロジックを示しています。
![\[AND および OR がどのように複数のコンテキストキーおよび値に適用されるかを示した条件ブロック\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block_AND_2.diagram.png)
例えば、次の S3 バケットポリシーは、上記の図がポリシーでどのように表されるかを示しています。条件ブロックは、条件演算子 `StringEquals` および `ArnLike`、コンテキストキー `aws:PrincipalTag` および `aws:PrincipalArn` を含んでいます。目的の `Allow` または `Deny` 効果を呼び出すには、条件ブロックのすべてのコンテキストキーが true に変換される必要があります。リクエストを行うユーザーには、ポリシーで指定されているタグキー値のいずれかを含む、department と role の両方のプリンシパルタグキーが必要です。また、リクエストを行うユーザーのプリンシパル ARN は、true と評価されるポリシーで指定される `aws:PrincipalArn` の値のいずれかに一致する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
}
}
}
]
}
```
------
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: legal
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **一致** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: payroll
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | リクエストコンテキストに `aws:PrincipalTag/role` はありません。 aws:PrincipalTag/department: hr
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | リクエストコンテキストに `aws:PrincipalTag` はありません。 aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **一致なし** |
## 否定された一致条件演算子の評価ロジック
`StringNotEquals` や `ArnNotLike` などの一部の[条件演算子](reference_policies_elements_condition_operators.md)は、否定された一致を使用して、ポリシー内のコンテキストのキーと値のペアをリクエスト内のそれと比較します。否定された一致条件演算子を使用するポリシーで、1 つのコンテキストキーに複数の値が指定されている場合、有効なアクセス許可は論理 `NOR` であるかのように機能します。否定された一致では、論理 `NOR` または `NOT OR` はすべての値が false と評価された場合のみ true を返します。
次の図は、複数の条件演算子およびコンテキストのキーと値のペアを含む条件の評価ロジックを示しています。この図には、コンテキストキー 3 用の否定された一致条件演算子が含まれています。
![\[否定された一致条件演算子を使用する際に、AND および OR が複数のコンテキストキーと値にどのように適用されるかを示した条件ブロック\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block_AND_Negated_NOR_2.diagram.png)
例えば、次の S3 バケットポリシーは、上記の図がポリシーでどのように表されるかを示しています。条件ブロックは、条件演算子 `StringEquals` および `ArnNotLike`、コンテキストキー `aws:PrincipalTag` および `aws:PrincipalArn` を含んでいます。目的の `Allow` または `Deny` 効果を呼び出すには、条件ブロックのすべてのコンテキストキーが true に変換される必要があります。リクエストを行うユーザーには、ポリシーで指定されているタグキー値のいずれかを含む、department と role の両方のプリンシパルタグキーが必要です。`ArnNotLike` 条件演算子で否定された一致を使用するため、リクエストを行うユーザーのプリンシパル ARN は true と評価されるポリシーで指定される `aws:PrincipalArn` の値のいずれとも一致してはいけません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
}
}
}
]
}
```
------
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: legal
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **一致** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: payroll
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | >リクエストコンテキストに `aws:PrincipalTag/role` はありません。 aws:PrincipalTag/department: hr
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **一致なし** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | リクエストコンテキストに `aws:PrincipalTag` はありません。 aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **一致なし** |
# 単一値と複数値のコンテキストキー
単一値のコンテキストキーと複数値のコンテキストキーの違いは、ポリシー条件の値の数ではなく、[リクエストコンテキスト](intro-structure.md#intro-structure-request)の値の数にあります。
+ 単一値の条件コンテキストキーはリクエストコンテキストに、最大で 1 つの値を持ちます。例えば、AWS でリソースにタグを付けると、各リソースタグは key-value ペアとして保存されます。リソースタグキーは単一のタグ値しか持つことができないため、[aws:ResourceTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-resourcetag) は単一値のコンテキストキーです。単一値のコンテキストキーで条件集合演算子を使用しないでください。
+ 複数値の条件コンテキストキーは、リクエストコンテキストに複数の値を持つことができます。例えば、AWS でリソースにタグを付ける場合、1 つのリクエストに複数のタグの key-value ペアを含めることができます。したがって、[aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) は複数の値を持つコンテキストキーです。複数値のコンテキストキーには条件集合演算子が必要です。
例えば、リクエストは最大でも 1 つの VPC エンドポイントから発信されるため、[aws:SourceVpce](reference_policies_condition-keys.md#condition-keys-sourcevpce) は単一値のコンテキストキーです。サービスには、そのサービスに属するサービスプリンシパル名を複数持つことができるため、[aws:PrincipalServiceNamesList](reference_policies_condition-keys.md#condition-keys-principalservicenameslist) は複数値のコンテキストキーです。
**重要**
単一値と複数値のコンテキストキーの違いは、ポリシー条件の値の数ではなく、リクエストコンテキストの値の数によります。
## 重要ポイント
+ 単一値と複数値の分類については、条件コンテキストキーの値の種類として、[AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md) トピックでそれぞれ説明されています。
+ 「[サービス認証リファレンス](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)」にある複数値のコンテキストキーは、`ArrayOfString` や `ArrayOfARN` などの条件演算子カテゴリタイプが付加された `ArrayOf` プレフィックスを使用します。これらは、リクエスト内に条件コンテキストキーの複数の値が含まれる可能性があることを示します。
+ 使用可能な単一値のコンテキストキーはポリシー変数として使用できますが、複数値のコンテキストキーをポリシー変数として使用することはできません。ポリシー変数の詳細については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。
+ key-value ペアを含むコンテキストキーを使用する場合は、複数の tag-key 値があっても、各 `tag-key` は 1 つの値しか持てないことに留意してください。
+ [aws:PrincipalTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-principaltag)、[aws:RequestTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-requesttag)、[aws:ResourceTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-resourcetag) は単一値のコンテキストキーです。
+ [aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) はリクエストで許可されるタグキーを定義しますが、タグキー値は含まれません。1 つのリクエストにタグのキーバリューペアを複数含めることができるため、`aws:TagKeys` は複数値のコンテキストキーです。
+ 複数値のコンテキストキーには条件集合演算子が必要です。単一値のコンテキストキーで、条件集合演算子の `ForAllValues` または `ForAnyValue` を使用しないでください。単一値のコンテキストキーで条件集合演算子を使用すると、過度にポリシーが許容される可能性があります。
## 複数値のコンテキストキーの演算子を設定する
条件コンテキストキーを、複数の値を持つ[リクエストコンテキスト](intro-structure.md#intro-structure-request)キーと比較するには、`ForAllValues` または `ForAnyValue` 集合演算子を使用する必要があります。これらの集合演算子は、リクエストにあるタグのセットと、ポリシー条件にあるタグのセットなど、2 つの値のセットを比較する場合に使われます。
`ForAllValues` および `ForAnyValue` の修飾子によって条件演算子にセット演算機能が追加されるため、リクエストコンテキストキーを、ポリシー条件内の複数のコンテキストキーの値に照らしてテストできます。さらに、ワイルドカードまたは変数を使用してポリシーに複数値の文字列コンテキストキーを含める場合は、`StringLike` [条件演算子](reference_policies_elements_condition_operators.md#Conditions_String)も使用する必要があります。複数の条件キーの値は、[配列](reference_policies_grammar.md#policies-grammar-json)のように括弧で囲む必要があります (例: `"Key2":["Value2A", "Value2B"]`)。
### ForAllValues
`ForAllValues` 修飾子は、リクエストコンテキストのすべてのメンバーの値が、修飾子の後に続く条件演算子と一致するかどうかをテストします。条件は、リクエスト内のすべてのコンテキストキーの値がポリシー内のコンテキストキーの値に一致する場合に `true` を返します。また、リクエストにコンテキストキーがない場合も、`true` を返します。
**重要**
`ForAllValues` を `Allow` 効果で使用するときは、リクエストコンテキストでのコンテキストキーの欠落が予想外である場合に許容範囲が広くなりすぎる可能性があるため、注意が必要です。ポリシーには [`Null`](reference_policies_elements_condition_operators.md#Conditions_Null) 条件演算子と `false` 値を常に含めて、コンテキストキーが存在するかどうか、その値が null でないかどうかをチェックする必要があります。例については、[タグキーに基づいたアクセスの制御](access_tags.md#access_tags_control-tag-keys)を参照してください。
#### ForAllValues 集合演算子の例
次の例では、ユーザーが EC2 インスタンスに割り当てられた特定のタグを削除できるようにするために、ForAllValues が aws:TagKeys とともに使用されています。このポリシーは、ユーザーが `environment` タグと `cost-center` タグのみを削除できるようにします。これらのタグは、個別に削除することも、一緒に削除することも可能です。リクエスト内のタグキーは、ポリシーで指定されたキーと完全に一致する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
}
}
}
]
}
```
------
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
| **一致** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– cost-center
| **一致** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
– cost-center
| **一致** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
– dept
| **一致なし** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | リクエストコンテキストに `aws:TagKeys` はありません。 | **一致なし** |
最後の例では、Null 条件チェックがコンテキストキーが欠落している場合の一致を防ぐため、結果が「一致なし」になることに留意してください。これは、許容範囲が過度に広範なポリシーを回避するためのベストプラクティスです。
### ForAnyValue
`ForAnyValue` 修飾子は、リクエストにあるコンテキストキーの値セットの少なくとも 1 メンバーが、ポリシー条件にあるコンテキストキーの値セットの少なくとも 1 メンバーに一致するかどうかをテストします。リクエストにあるコンテキストキーの値のいずれかが、ポリシーにあるコンテキストキーの値のいずれかに一致すると、条件が `true` を返します。一致するコンテキストキーがない、またはキーが存在しない場合、条件は `false` を返します。
**重要**
`ForAnyValue` を `Deny` 効果で使用していて、リクエストにコンテキストキーが存在しないという場合、ポリシーは**一致なし**として評価します。一貫した動作のため、ポリシーに明示的な [`Null`](reference_policies_elements_condition_operators.md#Conditions_Null) 条件チェックを追加して、コンテキストキーが存在するかどうかを確認します。詳細については、「[条件キーの有無をチェックする条件演算子](reference_policies_elements_condition_operators.md#Conditions_Null)」を参照してください。
#### ForAnyValue 集合演算子の例
次の例では、ユーザーが EC2 インスタンスに割り当てられた特定のタグを削除できるようにするために、ForAnyValue が aws:TagKeys とともに使用されています。このポリシーは、リクエストで指定されたタグキーに `environment` または `cost-center` が含まれている場合に、ユーザーがインスタンスのタグを削除できるようにします。リクエストには、ポリシーで指定されたタグキー以外の追加のタグキーを含めることができますが、条件に一致させるには、指定されたキーの少なくとも 1 つを含める必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
}
}
}
]
}
```
------
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
| **一致** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– cost-center
| **一致** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
– cost-center
| **一致** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
– dept
| **一致** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– dept
| **一致なし** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | リクエストコンテキストに `aws:TagKeys` はありません。 | **一致なし** |
# 条件ポリシーの例
IAM ポリシーでは、単一値のコンテキストキーと複数値のコンテキストキー、その両方に複数の値を指定して、リクエストコンテキストと比較できます。次の一連のポリシーの例では、複数のコンテキストキーと値を使用しているポリシー条件を示しています。
**注記**
このリファレンスガイドに含めるポリシーを送信する場合は、このページの下部にある [**フィードバック**] ボタンを使用します。IAM ID ベースのポリシーの例については、「[IAM アイデンティティベースのポリシーの例](access_policies_examples.md)」を参照してください。
## 条件ポリシーの例：単一値のコンテキストキー
+ 単一値のコンテキストキーを持つ、複数の条件ブロック。([例を表示します](reference_policies_condition_examples-single-valued-context-keys.md#reference_policies_condition_examples-single-valued-context-keys-1)。)
+ 単一値のコンテキストキーバリューを複数持つ、1 つの条件ブロック。([例を表示します](reference_policies_condition_examples-single-valued-context-keys.md#reference_policies_condition_examples-single-valued-context-keys-2)。)
## 条件ポリシーの例：複数値のコンテキストキー
+ 条件集合演算子の `ForAllValues` を使用している拒否ポリシー。([例を表示します](reference_policies_condition_examples-multi-valued-context-keys.md#reference_policies_condition_examples-multi-valued-context-keys-1)。)
+ 条件集合演算子の `ForAnyValue` を使用している拒否ポリシー。([例を表示します](reference_policies_condition_examples-multi-valued-context-keys.md#reference_policies_condition_examples-multi-valued-context-keys-2)。)
# 複数値のコンテキストキーの主な例
次の一連のポリシーの例では、複数値のコンテキストキーを使用してポリシー条件を作成する方法を示しています。
## 例：条件集合演算子の ForAllValues を使用している拒否ポリシー
次の例では、特定のタグキープレフィックスがリクエストに含まれている場合に、ID ベースのポリシーが IAM タグ付けアクションの使用を拒否する仕組みを示します。[`aws:TagKeys`](reference_policies_condition-keys.md#condition-keys-tagkeys) の値には、文字列の部分一致を目的としたワイルドカード (\$1) が含まれています。リクエストコンテキストキーには複数の値を含められるため、コンテキストキー `aws:TagKeys` を使用しているセット演算子 `ForAllValues` がポリシーに含まれています。コンテキストキー `aws:TagKeys` が一致するには、リクエストコンテキストのすべての値がポリシーの 1 つ以上の値と一致する必要があります。
`ForAllValues` 集合演算子は、リクエストにコンテキストキーがない場合にも true を返します。
`Null` 条件演算子を `false` の値でポリシーに含め、リクエストにコンテキストキーが存在することとその値が null でないことをチェックすることによって、欠落したコンテキストキーや、空の値を含むコンテキストキーが true と評価されることを防止できます。詳細については、「[条件キーの有無をチェックする条件演算子](reference_policies_elements_condition_operators.md#Conditions_Null)」を参照してください。
**重要**
このポリシーでは、アクションを許可しません。特定のアクションを許可する他のポリシーと組み合わせてこのポリシーを使用します。
**Example 複数の値を持つコンテキストキーの単一のポリシー条件値を拒否する**
次の例では、ポリシーは、リクエスト内の `aws:TagKeys` の値にプレフィックス **key1** が含まれていないリクエストを拒否します。リクエストコンテキストには複数の値を含めることができますが、`ForAllValues` 条件集合演算子の要件を満たすために、リクエストコンテキスト内のすべてのタグキー値はプレフィックス **key1** で始まる必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRestrictedTags",
"Effect": "Deny",
"Action": [
"iam:Tag*",
"iam:UnTag*"
],
"Resource": [
"*"
],
"Condition": {
"ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
}
}
}
]
}
```
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。Deny ステートメントの場合、「一致」は拒否され、「一致なし」は拒否されないため、別のステートメントで許可される場合があります。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key1:legal
| **一致なし** 別のステートメントで許可される場合があります。 |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key1:hr
– key1:personnel
| **一致なし** 別のステートメントで許可される場合があります。 |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key2:audit
| **一致** |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | リクエストコンテキストに `aws:TagKeys` はありません。 | **一致** |
**Example 複数の値を含むコンテキストキーの複数のポリシー条件値を拒否する**
次の例では、ポリシーは、リクエスト内の `aws:TagKeys` の値に **key 1** または **key 2** というプレフィックスが含まれていないリクエストを拒否します。リクエストコンテキストには複数の値を含めることができますが、条件集合演算子 `ForAllValues` の要件を満たすために、リクエストコンテキスト内のすべてのタグキー値は、プレフィックス **key1** または **key2** で始まる必要があります。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRestrictedTags",
"Effect": "Deny",
"Action": [
"iam:Tag*",
"iam:UnTag*"
],
"Resource": [
"*"
],
"Condition": {
"ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
}
}
}
]
}
```
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。Deny ステートメントの場合、「一致」は拒否され、「一致なし」は拒否されないため、別のステートメントで許可される場合があります。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:legal
| **一致なし** 別のステートメントで許可される場合があります。 |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:hr
– key1:personnel
| **一致なし** 別のステートメントで許可される場合があります。 |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:hr
– key2:audit
| **一致なし** 別のステートメントで許可される場合があります。 |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key3:legal
| **一致** |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | リクエストコンテキストに `aws:TagKeys` はありません。 | **一致** |
## 例：条件集合演算子の ForAnyValue を使用している拒否ポリシー
次の ID ベースのポリシーの例では、ポリシー、`environment` または `webserver` で指定されているタグキーのいずれかでタグ付けされたスナップショットがある場合、EC2 インスタンスボリュームのスナップショットの作成を拒否します。リクエストコンテキストキーには複数の値を含められるため、コンテキストキー `aws:TagKeys` を使用しているセット演算子 `ForAnyValue` がポリシーに含まれています。ポリシーで指定されたタグキーの値が、タグ付けリクエストに 1 つでも含まれている場合、`aws:TagKeys` コンテキストキーは true を返し、拒否ポリシーの効果をもたらします。
**重要**
このポリシーでは、アクションを許可しません。特定のアクションを許可する他のポリシーと組み合わせてこのポリシーを使用します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateSnapshots"
],
"Resource": "arn:aws:ec2:us-west-2::snapshot/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
}
}
}
]
}
```
------
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。Deny ステートメントの場合、「一致」は拒否され、「一致なし」は拒否されないため、別のステートメントで許可される場合があります。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– webserver
| **一致** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– environment
– webserver
– test
| **一致** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– environment
– test
| **一致なし** 別のステートメントで許可される場合があります。 |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | リクエストコンテキストに `aws:TagKeys` はありません。 | **一致なし** 別のステートメントで許可される場合があります。 |
# 単一値のコンテキストキーポリシーの例
次の一連のポリシーの例では、単一値のコンテキストキーを使用してポリシー条件を作成する方法を示しています。
## 例：単一値のコンテキストキーを持つ、複数の条件ブロック
条件ブロックに複数の条件があり、それぞれにコンテキストキーが 1 つしかない場合、目的の `Allow` または `Deny` 効果を呼び出すには、すべてのコンテキストキーが true になる必要があります。否定一致条件演算子を使用すると、条件の値を評価するロジックが反転します。
次の例では、ユーザーが EC2 ボリュームを作成し、ボリューム作成時にボリュームにタグを適用しています。リクエストコンテキストには、コンテキストキー `aws:RequestTag/project` の値を含める必要があり、本稼働環境以外ならば、コンテキストキー `aws:ResourceTag/environment` の値はどの値でもかまいません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateVolume",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*",
"Condition": {
"StringLike": {
"aws:RequestTag/project": "*"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:us-east-1:123456789012:*/*",
"Condition": {
"StringNotEquals": {
"aws:ResourceTag/environment": "production"
}
}
}
]
}
```
------
リクエストコンテキストには、プロジェクトのタグ値が含まれている必要があり、本稼働環境のリソース用にリクエストコンテキストを作成して `Allow` 効果を呼び出すことはできません。プロジェクト名に `QA` リソースタグがついて `Feature3` となっているため、次の EC2 ボリュームは正常に作成されました。
```
aws ec2 create-volume \
--availability-zone us-east-1a \
--volume-type gp2 \
--size 80 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=project,Value=Feature3},{Key=environment,Value=QA}]'
```
## 例：単一値のコンテキストキーと値が複数ある、1 つの条件ブロック
条件ブロックに複数のコンテキストキーが含まれていて、それぞれのコンテキストキーに複数の値がある場合、目的の `Allow` または `Deny` 効果を呼び出すには、少なくとも 1 つのキーバリューが true になる必要があります。否定一致条件演算子を使用すると、コンテキストキーの値を評価するロジックが反転します。
次の例では、ユーザーが Amazon Elastic Container Service クラスターで、タスクを開始して実行できるようにします。
+ リクエストコンテキストには、**AND** `aws:RequestTag/environment` コンテキストキー用に、`production` **または** `prod-backup` を含める必要があります。
+ `ecs:cluster` コンテキストキーにより、`default1` **または** `default2` の ARN ECS クラスターでタスクが実行されたことが確実になります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:RunTask",
"ecs:StartTask"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
}
}
}
]
}
```
------
次の表は、AWS がリクエストの条件キー値に基づいてこのポリシーを評価する方法を示しています。
| ポリシー条件 | リクエストコンテキスト | 結果 |
| --- | --- | --- |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: environment:production
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default1
| 一致 |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: environment:prod-backup
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| 一致 |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: webserver:production
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| 一致なし |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | リクエストコンテキストに `aws:RequestTag` はありません。 ecs:cluster
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| 一致なし |
# IAM ポリシーの要素: 変数とタグ
ポリシーを記述するときにリソースや条件キーの正確な値がわからない場合、AWS Identity and Access Management (IAM) のポリシー変数をプレースホルダーとして使用します。
**注記**
AWS が変数を解決できない場合は、これによってステートメント全体が無効になる可能性があります。たとえば、`aws:TokenIssueTime` 変数を使用する場合は、リクエスタが一時的な認証情報 (IAM ロール) を使用して認証した場合にのみ、変数は値に解決されます。変数が無効なステートメントを発生させないようにするには、[...IfExists 条件演算子を使用します。](reference_policies_elements_condition_operators.md#Conditions_IfExists)
**Topics**
+ [序章](#policy-vars-intro)
+ [ポリシーでの変数の使用](#policy-vars-using-variables)
+ [ポリシー変数としてのタグ](#policy-vars-tags)
+ [ポリシー変数を使用する場所](#policy-vars-wheretouse)
+ [値のないポリシー変数](#policy-vars-no-value)
+ [ポリシー変数に使用可能なリクエスト情報](#policy-vars-infotouse)
+ [デフォルト値の指定](#policy-vars-default-values)
+ [詳細情報](#policy-vars-formoreinfo)
## 序章
IAM ポリシーでは、アクセスを制御する特定のリソースに対して名前を指定することが多くのアクセションで許可されています。例えば、以下のポリシーでは、ユーザーは、`marketing` プロジェクトの S3 バケット `amzn-s3-demo-bucket` 内のオブジェクトの一覧表示、読み取り、および書き込みができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"],
"Condition": {"StringLike": {"s3:prefix": ["marketing/*"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/marketing/*"]
}
]
}
```
------
場合によっては、ポリシーを書く際に対象リソースの正確な名前が分からないときがあります。ポリシーを汎用化して多くのユーザーが共用できるようにすると、ユーザーごとにポリシーの一意なコピーを作成する必要がなくなります。ユーザーごとの個別のポリシーを作成するのではなく、そのグループに属するすべてのユーザーに対して機能する単一のグループポリシーを作成することをお勧めします。
## ポリシーでの変数の使用
ポリシーにプレースホルダーを設定する*ポリシー変数*を使用して、ポリシー内で動的な値を定義できます。
変数は、**`$`** プレフィックスを使用してマークされ、その後に、リクエストに値がある変数名が、中括弧 (**`{ }`**) で囲まれて続きます。
ポリシーの評価時に、ポリシー変数はリクエスト自体の条件コンテキストから取得された値に置き換えられます。変数は、[ID ベースのポリシー、リソースポリシー、サービスコントロールポリシー、セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)、[VPC エンドポイントポリシーで使用できます](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)。アクセス許可の境界として使用される ID ベースのポリシーは、ポリシー変数もサポートします。
グローバル条件コンテキストキーは、AWS サービス間のリクエストの変数として使用できます。サービス固有の条件キーは、AWS リソースを操作するときの変数としても使用できますが、それらをサポートするリソースに対してリクエストが行われた場合にのみ使用できます。各 AWS サービスとリソースで使用可能なコンテキストキーのリストについては、「[https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html)」をご覧ください。特定の状況では、グローバル条件コンテキストキーに値を設定できません。詳細については、「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
**重要**
キー名では大文字と小文字は区別されません。例えば、`aws:CurrentTime` と `AWS:currenttime` は同じです。
単一値の条件キーは、変数として使用できます。複数値の条件キーは、変数としては使用できません。
次の例は、特定のリソース名をポリシー変数に置き換える IAM ロールまたはユーザー用のポリシーを示しています。このポリシーは、`aws:PrincipalTag` 条件キーを利用して再利用できます。このポリシーが評価されると、`${aws:PrincipalTag/team}` では、バケット名が `team` プリンシパルタグのチーム名で終わる場合にのみアクションが許可されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"],
"Condition": {"StringLike": {"s3:prefix": ["${aws:PrincipalTag/team}/*"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/team}/*"]
}
]
}
```
------
変数は、`$` プレフィックスの後に波かっこ (`{ }`) を付けることでマークできます。`${ }` 文字の内部には、ポリシーで使用する値の名前をリクエストから取得して含めることができます。使用できる値については、このページの後半で説明します。
このグローバル条件キーの詳細については、グローバル条件キーのリストの「[aws:PrincipalTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-principaltag)」を参照してください。
**注記**
ポリシー変数を使用するには、ステートメントに `Version` 要素を含めて、ポリシー変数をサポートするバージョンに設定する必要があります。変数はバージョン `2012-10-17` から導入されました。旧バージョンでのポリシー言語では、ポリシー変数をサポートしていません。`Version` 要素を含めず、適切なバージョンの日付に設定しない場合、`${aws:username}` などの変数はポリシー内のリテラル文字列として扱われます。
`Version` ポリシー要素は、ポリシーバージョンとは異なります。`Version` ポリシー要素は、ポリシー内で使用され、ポリシー言語のバージョンを定義します。一方で、ポリシーバージョンは、IAM でカスタマー管理ポリシーを変更すると作成されます。変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。`Version` ポリシー要素の詳細については、「[IAM JSON ポリシー要素Version](reference_policies_elements_version.md)」を参照してください。ポリシーのバージョンの詳細については、「[IAM ポリシーのバージョニング](access_policies_managed-versioning.md)」を参照してください。
プリンシパルが S3 バケットの /David パスからオブジェクトを取得することを許可するポリシーは次のようになります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/David/*"
]
}
]
}
```
------
このポリシーがユーザー `David` にアタッチされている場合、そのユーザーは自身の S3 バケットからオブジェクトを取得しますが、このユーザー名を含む各ユーザーには別のポリシーを作成する必要があります。その後、各ポリシーを個々のユーザーに関連付ける必要があります。
ポリシー変数を使用することで、再利用できるポリシーを作成できます。次のポリシーでは、`aws:PrincipalTag` のタグキー値がリクエストで渡されたタグキーの `owner` 値と一致する場合、ユーザーは Amazon S3 バケットからオブジェクトを取得できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowUnlessOwnedBySomeoneElse",
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["*"],
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/owner": "${aws:PrincipalTag/owner}"
}
}
}
]
}
```
------
このようにユーザーのところにポリシー変数を使用することで、ユーザーごとに別々のポリシーを作成する必要がなくなります。次の例では、プロダクトマネージャーが一時的なセキュリティ認証情報を使用して引き受ける IAM ロールにポリシーをアタッチしています。ユーザーが Amazon S3 オブジェクトへのアクセスをリクエストした場合、IAM では `${aws:PrincipalTag}` 変数を現在のリクエストから取得した `dept` タグ値に置き換えてポリシーを評価します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowOnlyDeptS3Prefix",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/dept}/*"
]
}
]
}
```
------
## ポリシー変数としてのタグ
一部の AWS サービスでは、それらのサービスによって作成されたリソースに独自のカスタム属性をアタッチできます。例えば、Amazon S3 バケットや IAM ユーザーにタグを適用できます。これらのタグはキーバリューのペアです。タグキー名と、そのキー名に関連付けられた値とを定義します。たとえば、**department** キーと **Human Resources** 値を持つタグを作成します。IAM エンティティのタグ付けの詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。他の AWS サービスによって作成されるリソースのタグ付けについては、そのサービスのドキュメントを参照してください。タグエディタの使用については、「AWS マネジメントコンソール ユーザーガイド」の「[タグエディタの使用](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html)」を参照してください。
IAM リソースにタグ付けすることで、IAM リソースの検出、整理、および追跡を簡単に行うことができます。また、IAM アイデンティティにタグ付けして、リソースまたはタグ付け自体へのアクセスを制御することもできます。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。
## ポリシー変数を使用する場所
`Resource` 要素のポリシー変数、および `Condition` 要素の文字列比較を活用できます。
### リソースの要素
ポリシー変数は `Resource` 要素で使用できますが、ARN のリソース部分でのみ使用できます。ARN のこの部分は、5 番目のコロン (:) の後に表示されます。サービスやアカウントなど 5 番目のコロンよりも前の ARN の部分は、変数を使用して置き換えることはできません。ARN 形式の詳細については、[IAM ARN](reference_identifiers.md#identifiers-arns)を参照してください。
ARN の一部をタグ値で置き換えるには、プレフィックスとキー名を `${ }` で囲みます。例えば、次のリソース要素は、リクエストしているユーザーの部門タグの値と同じ名前のバケットのみを参照します。
`"Resource": ["arn:aws::s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/department}"]`
多くの AWS リソースは、ユーザーが作成した名前を含む ARN を使用します。以下の IAM ポリシーでは、アクセスプロジェクト、アクセスアプリケーション、アクセス環境のタグ値が一致する対象ユーザーのみがリソースを変更できるようにしています。さらに、[\$1 ワイルドカードマッチ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html)を使用すると、カスタムリソース名のサフィックスを指定できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessBasedOnArnMatching",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:DeleteTopic"],
"Resource": ["arn:aws:sns:*:*:${aws:PrincipalTag/access-project}-${aws:PrincipalTag/access-application}-${aws:PrincipalTag/access-environment}-*"
]
}
]
}
```
------
### 条件の要素
ポリシー変数は、文字列演算子または ARN 演算子を含む任意の条件の `Condition` の値に使用できます。文字列演算子には `StringEquals`、`StringLike`、`StringNotLike` などが含まれます。ARN 演算子には `ArnEquals` と `ArnLike` が含まれます。ポリシー変数は `Numeric`、`Date`、`Boolean`、`Binary`、`IP Address`、または `Null` など、他の演算子では使用できません。条件演算子の詳細については、「[IAM JSON ポリシー要素: 条件演算子](reference_policies_elements_condition_operators.md)」を参照してください。
`Condition` 要素式のタグを参照するときは、関連する接頭辞とキー名を条件キーとして使用します。次に、条件値でテストする値を使用します。
例えば、次のポリシー例では、ユーザーにフルアクセスが許可されていますが、タグ `costCenter` がユーザーにアタッチされている場合に限ります。タグの値は、`12345` または `67890` である必要があります。タグ値が設定されていない場合、またはそれ以外の値の場合、リクエストは失敗します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:*user*"
],
"Resource": "*",
"Condition": {
"StringLike": {
"iam:ResourceTag/costCenter": [ "12345", "67890" ]
}
}
}
]
}
```
------
## 値のないポリシー変数
ポリシー変数が、値のない、またはリクエストの承認コンテキストに存在しない条件コンテキストキーを参照する場合、その値は事実上 null になります。同等または同等の価値はありません。以下の場合、条件コンテキストキーが認可コンテキストに存在しない可能性があります。
+ その条件キーをサポートしていないリソースへのリクエストで、サービス固有の条件コンテキストキーを使用しています。
+ IAM プリンシパル、セッション、リソース、またはリクエストのタグは存在しません。
+ [AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md) 内の各グローバル条件コンテキストキーにリストされているその他の状況。
IAM ポリシーの条件要素に値のない変数を使用すると（「[IAM JSON ポリシー要素: 条件演算子](reference_policies_elements_condition_operators.md)いいね」`StringEquals` または「`StringLike`一致しない」）、ポリシーステートメントが有効になりません。
`StringNotEquals` または `StringNotLike` などの逆条件演算子は、テスト対象の条件キーの値が実際の NULL 値と等しくないか、等しくないため、null 値とマッチします。
例えば、アクセスを許可するには `aws:principaltag/Team` が `s3:ExistingObjectTag/Team` と等しい必要があります。`aws:principaltag/Team` が設定されていない場合、アクセスは明示的に拒否されます。承認コンテキストに値のない変数をポリシーの `Resource` または `NotResource` 要素の一部として使用すると、値のないポリシー変数を含むリソースはどのリソースとも一致しません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:ExistingObjectTag/Team": "${aws:PrincipalTag/Team}"
}
}
}
]
}
```
------
## ポリシー変数に使用可能なリクエスト情報
JSON ポリシーの `Condition` 要素を使用して、[リクエストコンテキスト](reference_policies_evaluation-logic_policy-eval-reqcontext.md)のキーを、ポリシーで指定したキーバリューと比較できます。ポリシー変数を使用する場合、AWS は、ポリシー内の変数の代わりにリクエストコンテキストキーの値を置換します。
### プリンシパルキーの値
`aws:username`、`aws:userid`、および `aws:PrincipalType` の値は、リクエストを開始したプリンシパルの値によって異なります。例えば、IAM ユーザー、IAM ロール、または AWS アカウントのルートユーザー の認証情報を使用してリクエストを行うことができます。以下の表は、様々な種類のプリンシパルに対するキーの値を示しています。
****
| Principal | `aws:username` | `aws:userid` | `aws:PrincipalType` |
| --- | --- | --- | --- |
| AWS アカウントのルートユーザー | （なし） | AWS アカウント ID | Account |
| IAM ユーザー | IAM-user-name | [一意の ID](reference_identifiers.md#identifiers-unique-ids) | User |
| AWS STS フェデレーションユーザーのプリンシパル | （なし） | account:caller-specified-name | FederatedUser |
| OIDC フェデレーテッドプリンシパル ウェブ ID フェデレーションを使用するときに利用可能なポリシーキーの詳細については、「[OIDC AWS フェデレーションで使用できるキー](reference_policies_iam-condition-keys.md#condition-keys-wif)」を参照してください。 | （なし） | *role-id*:*caller-specified-role-name* ここで、`role-id` は[ロールの一意の ID](reference_identifiers.md#identifiers-unique-ids) であり、caller-specified-role-name は AssumeRoleWithWebIdentity リクエストに渡される [RoleSessionName パラメータ](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AssumeRole.html#API_AssumeRoleWithWebIdentity_RequestParameters)によって指定されます。 | AssumedRole |
| SAML フェデレーテッドプリンシパル SAML フェデレーションを使用するときに利用可能なポリシーキーの詳細については、「[SAML ベースのフェデレーションでユーザーを一意に識別する](id_roles_providers_saml.md#CreatingSAML-userid)」を参照してください。 | （なし） | *role-id*:*caller-specified-role-name* ここで、r`role-id` は[ロールの一意の ID](reference_identifiers.md#identifiers-unique-ids) です。caller-specified-role-name は Attribute 要素によって指定され、[Name 属性](id_roles_providers_create_saml_assertions.md)は https://aws.amazon.com/SAML/attributes/RoleSessionName に設定されています。 | AssumedRole |
| 委任されたロール | （なし） | *role-id*:*caller-specified-role-name* ここで、`role-id` は[ロールの一意の ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) であり、caller-specified-role-name は AssumeRole リクエストに渡される [RoleSessionName パラメータ](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters)です。 | AssumedRole |
| Amazon EC2 インスタンスに割り当てられたロール | （なし） | *role-id*:*ec2-instance-id* ここで、`role-id` は[ロールの一意の ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) であり、ec2-instance-id は [EC2 インスタンスの一意の識別子](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html)です。 | AssumedRole |
| 匿名呼び出し元 (Amazon SQS、Amazon SNS、および Amazon S3 のみ) | （なし） | anonymous | Anonymous |
この テーブルの については、次の点に注意してください。
+ *なし*である場合、値が現在のリクエスト情報内に存在しないために値を一致させる試みが失敗し、ステートメントが無効になることを意味します。
+ *role-id* は、作成時に各ロールに割り当てられる一意の識別子です。次の AWS CLI コマンドでロール ID を表示できます: `aws iam get-role --role-name rolename`
+ *caller-specified-name* および *caller-specified-role-name* は、一時的認証情報を取得するための呼び出し元プロセス (アプリケーションまたはサービスなど) によって渡された名前です。
+ *ec2-instance-id* は、インスタンスにその起動時に割り当てられ、Amazon EC2 コンソールの [**Instances (インスタンス)**] ページに表示される値です。インスタンス ID を表示するには、次の AWS CLI コマンドを実行します: `aws ec2 describe-instances`
### フェデレーティッドプリンシパル用にリクエストで利用可能な情報
フェデレーティッドプリンシパルとは、IAM 以外のシステムの使用が認証されたユーザーを指します。たとえば、ある企業が AWS に発信する社内用のアプリケーションを使用しているとします。このアプリケーションを使用する社内すべてのユーザーに IAM ID を発行することは実際的ではありません。代わりに、単一の IAM ID を持つプロキシ (中間層) アプリケーションを使用するか、SAML ID プロバイダー (IdP) を使用することができます。プロキシアプリケーションまたは SAML IdP は、企業ネットワークを使用して個々のユーザーを認証します。プロキシアプリケーションは、その IAM ID を使用して、個々のユーザーの一時的セキュリティ認証情報を取得できます。SAML IdP は、実際には AWS 一時的セキュリティ認証情報の ID に置き換えることができます。次に、一時的な認証情報を使用して、AWS リソースにアクセスできます。
同様に、AWS リソースへのアクセスが必要なモバイルデバイス用アプリを作成することもできます。この場合、「OIDC フェデレーション」を使用すると、アプリケーションで、Login with Amazon、Amazon Cognito、Facebook、Google などのよく知られた ID プロバイダーを使用するユーザーを認証できます。その後、アプリはこれらのプロバイダーから取得したユーザーの認証情報を用いて、AWS リソースにアクセスするための一時認証情報を取得します。
OIDC フェデレーションを使用する場合は、Amazon Cognito と AWS Mobile SDK を利用することをお勧めします。詳細については次を参照してください:
+ [Amazon Cognito ユーザーガイド](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)
+ [一時的な認証情報の一般的なシナリオ](id_credentials_temp.md#sts-introduction)
### 特殊文字
それ以外の場合は特別な意味を持つ文字を表すことのできる、固定値を持つ事前定義された特殊なポリシー変数がいくつかあります。これらの特殊文字が、一致を試みている文字列、またリテラルに挿入した文字列の一部である場合、これらは誤って解釈されます。たとえば、文字列に挿入されたアスタリスク (\$1) は、リテラルな \$1 としてではなく、任意の文字列を指定するワイルドカードとして解釈されます。この場合、事前定義した次のポリシー変数を使用できます。
+ **\$1\$1\$1\$1** - \$1 (アスタリスク) が必要な場合に使用します。
+ **\$1\$1?\$1** - ? (疑問符) が必要な場合に使用します。
+ **\$1\$1\$1\$1** - \$1 (ドル記号) が必要な場合に使用します。
これらの事前定義されたポリシー変数は、正規のポリシー変数を使用できるすべての文字列で使用できます。
## デフォルト値の指定
変数にデフォルト値を追加するには、デフォルト値を一重引用符 (`' '`) で囲み、変数テキストとデフォルト値をコンマとスペース (`, `) で区切ります。
例えば、プリンシパルが `team=yellow` でタグ付けされている場合、`amzn-s3-demo-bucket-yellow` という名前で `ExampleCorp's` のAmazon S3 バケットにアクセスできます。このリソースを使用するポリシーでは、チームメンバーがチームのバケットにアクセスすることは許可されますが、他のチームのリソースにアクセスすることはできません。チームタグのないユーザーの場合、`company-wide` のデフォルト値をバケットの名前として設定します。これらのユーザーは `amzn-s3-demo-bucket-company-wide` バケットにのみアクセスでき、チームへの参加方法などの一般的な情報を確認できます。
```
"Resource":"arn:aws:s3:::amzn-s3-demo-bucket-${aws:PrincipalTag/team, 'company-wide'}"
```
## 詳細情報
ポリシーの詳細については、以下を参照してください。
+ [AWS Identity and Access Management でのポリシーとアクセス許可](access_policies.md)
+ [IAM アイデンティティベースのポリシーの例](access_policies_examples.md)
+ [IAM JSON ポリシー要素のリファレンス](reference_policies_elements.md)
+ [ポリシーの評価論理](reference_policies_evaluation-logic.md)
+ [OIDC フェデレーション](id_roles_providers_oidc.md)
# IAM JSON ポリシー要素: サポートされているデータ型
このセクションでは、JSON ポリシーで値を指定するときにサポートされているデータの種類の一覧を掲載します。ポリシー言語では、各ポリシー要素のすべての種類がサポートされているわけではありません。各要素の詳細については、前のセクションを参照してください。
+ 文字列
+ 数字（整数および浮動小数点数）
+ ブール値
+ Null
+ Lists
+ マップ
+ 構造体（入れ子形式のマップ）
以下の表は、各データの種類をシリアル化してまとめたものです。すべてのポリシーは UTF-8 形式でなければいけないことに注意してください。JSON データの種類については、[RFC 4627](https://datatracker.ietf.org/doc/html/rfc4627) を参照してください。
****
| タイプ | JSON |
| --- | --- |
| String | String |
| 整数 | Number |
| 浮動小数点数 | Number |
| ブール値 | true または false |
| Null | null |
| 日付 | [ISO 8601 の W3C プロファイル](http://www.w3.org/TR/NOTE-datetime)に準拠する文字列 |
| IpAddress | [RFC 4632](https://datatracker.ietf.org/doc/html/rfc4632) に準拠する文字列 |
| リスト | 配列 |
| オブジェクト | オブジェクト |