AWS グローバル条件コンテキストキー - AWS Identity and Access Management

AWS グローバル条件コンテキストキー

プリンシパルが AWS にリクエストを行うと、AWS はリクエスト情報をリクエストコンテキストに収集します。JSON ポリシーの Condition 要素を使用して、リクエストコンテキストのキーを、ポリシーで指定したキー値と比較できます。グローバルキーがリクエストコンテキストに含まれる状況の詳細については、各グローバル条件キーの可用性情報を参照してください。JSON ポリシーで Condition 要素を使用する方法の詳細については、「IAM JSON ポリシーの要素: Condition」を参照してください。

注記

いくつかの状況でのみ利用可能な条件キーを使用する場合は、条件演算子の IfExists バージョンを使用できます。リクエストコンテキストに条件キーがない場合、ポリシーは評価に失敗する可能性があります。たとえば、...IfExists 演算子を使用する以下の条件ブロックでは、リクエストの送信元が特定の IP 範囲または VPC である場合、この条件に一致となります。いずれかまたは両方のキーがリクエストコンテキストに含まれていない場合でも、条件は引き続き true を返します。これらの値は、指定したキーがリクエストコンテキスト内に含まれる場合にのみ確認されます。

"Condition": { "IpAddressIfExists": {"aws:SourceIp" : ["xxx"] }, "StringEqualsIfExists" : {"aws:SourceVpc" : ["yyy"]} }

グローバル条件キーは、aws: プレフィックスが付いた条件キーです。AWS のサービスは、グローバル条件キーをサポートするか、サービスプレフィックスを含むサービス固有のキーを提供できます。たとえば、IAM 条件キーには iam: プレフィックスが含まれます。詳細については、「AWS のサービスのアクション、リソース、および条件キー」を参照し、表示するキーを持つサービスを選択します。

aws:CalledVia

文字列演算子で動作します。

このキーを使用して、ポリシー内のサービスと、IAM プリンシパル (ユーザーまたはロール) に代わってリクエストを実行したサービスを比較します。プリンシパルが AWS サービスに対してリクエストを実行すると、そのサービスはプリンシパルの認証情報を使用して、後続のリクエストを他のサービスに対して実行することがあります。aws:CalledVia キーには、プリンシパルの代わりにリクエストを実行したチェーン内の各サービスの順序付きリストが含まれます。

たとえば、AWS CloudFormation を使用して、Amazon DynamoDB テーブルの読み書きを行うことができます。次に、DynamoDB は AWS Key Management Service (AWS KMS) によって提供された暗号化を使用します。

  • 可用性– このキーは、aws:CalledVia をサポートするサービスが IAM プリンシパルの認証情報を使用して別のサービスにリクエストを実行する場合に、リクエスト内に存在します。サービスがサービスロールまたはサービスリンクロールを使用してプリンシパルに代わって呼び出しを行う場合、このキーは存在しません。また、プリンシパルが直接呼び出しを行う場合にも存在しません。

ポリシーで aws:CalledVia 条件キーを使用するには、AWS サービスリクエストを許可または拒否するサービスプリンシパルを提供する必要があります。AWS は、aws:CalledVia で次のサービスの使用をサポートしています。

CalledVia サービス
AWS サービス サービスプリンシパル
Amazon Athena athena.amazonaws.com
AWS CloudFormation cloudformation.amazonaws.com
Amazon DynamoDB dynamodb.amazonaws.com
AWS Key Management Service (AWS KMS) kms.amazonaws.com

いずれかのサービスがプリンシパルの認証情報を使用してリクエストを実行したときにアクセスを許可または拒否するには、aws:ViaAWSService 条件キーを使用します。この条件キーは、すべての AWS サービスをサポートします。

aws:CalledVia キーは複数値を持つキーです。ただし、条件でこのキーを使用して順序を強制することはできません。上記の例を使用すると、ユーザー 1は、AWS CloudFormation に対してリクエストを実行し、それにより DynamoDB が呼び出され、AWS KMS が呼び出されます。これらは 3 つの個別のリクエストです。AWS KMS への最後の呼び出しは、AWS CloudFormation を介し、次に DynamoDB を介して、ユーザー 1 によって実行されます。


        aws:CalledVia の使用例

この場合、リクエストコンテキストの aws:CalledVia キーには、cloudformation.amazonaws.comdynamodb.amazonaws.com がこの順序で含まれます。呼び出しがリクエストのチェーン内のどこかで、DynamoDB を介して行われたことだけが重要である場合は、ポリシーでこの条件キーを使用できます。

たとえば、次のポリシーでは、my-example-key という名前の AWS KMS キーを管理できますが、DynamoDB がリクエスト元のサービスの 1 つである場合に限ります。ForAnyValue:StringEquals 条件演算子により、DynamoDB が呼び出し元サービスの 1 つであることが保証されます。プリンシパルが AWS KMS を直接呼び出す場合、条件は false を返し、リクエストはこのポリシーで許可されません。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "KmsActionsIfCalledViaDynamodb", "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey", "kms:DescribeKey" ], "Resource": "arn:aws:kms:region:111122223333:key/my-example-key", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": ["dynamodb.amazonaws.com"] } } } ] }

チェーン内の最初または最後の呼び出しを行うサービスを強制する場合は、aws:CalledViaLast キー aws:CalledViaFirst とキーを使用できます。たとえば、次のポリシーでは、my-example-key という名前のキーを AWS KMS で管理できます。これらの AWS KMS オペレーションは、複数のリクエストがチェーンに含まれている場合にのみ許可されます。最初のリクエストは AWS CloudFormation を介して、最後のリクエストは DynamoDB を介して実行される必要があります。他のサービスがチェーンの途中でリクエストを実行しても、オペレーションは許可されます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "KmsActionsIfCalledViaChain", "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey", "kms:DescribeKey" ], "Resource": "arn:aws:kms:region:111122223333:key/my-example-key", "Condition": { "StringEquals": { "aws:CalledViaFirst": "cloudformation.amazonaws.com", "aws:CalledViaLast": "dynamodb.amazonaws.com" } } } ] }

サービスで IAM プリンシパルの認証情報を使用して別のサービスを呼び出す場合、aws:CalledViaFirst キー aws:CalledViaLast とキーはリクエスト内に存在します。これらは、リクエストのチェーンで呼び出しを行った最初と最後のサービスを示します。たとえば、AWS CloudFormation が X Service という名前の別のサービスを呼び出し、それにより DynamoDB が呼び出され、AWS KMS が呼び出されるとします。AWS KMS への最後の呼び出しは、順に AWS CloudFormation、X Service、DynamoDB を介してUser 1 によって実行されます。これは、最初に AWS CloudFormation を介して呼び出され、最後に DynamoDB を介して呼び出されました。


        aws:CalledViaFirst および aws:CalledViaLast の使用例

aws:CalledViaFirst

文字列演算子で動作します。

このキーを使用して、ポリシー内のサービスと、IAM プリンシパル (ユーザーまたはロール) に代わってリクエストを実行した最初のサービスを比較します。詳細については、「aws:CalledVia」を参照してください。

  • 可用性 – このキーは、サービスが IAM プリンシパルの認証情報を使用して、別のサービスに対して少なくとも 1 つの他のリクエストを実行する場合に、リクエスト内に存在します。サービスがサービスロールまたはサービスリンクロールを使用してプリンシパルに代わって呼び出しを行う場合、このキーは存在しません。また、プリンシパルが直接呼び出しを行う場合にも存在しません。

aws:CalledViaLast

文字列演算子で動作します。

このキーを使用して、ポリシー内のサービスと、IAM プリンシパル (ユーザーまたはロール) に代わってリクエストを実行した最後のサービスを比較します。詳細については、「aws:CalledVia」を参照してください。

  • 可用性 – このキーは、サービスが IAM プリンシパルの認証情報を使用して、別のサービスに対して少なくとも 1 つの他のリクエストを実行する場合に、リクエスト内に存在します。サービスがサービスロールまたはサービスリンクロールを使用してプリンシパルに代わって呼び出しを行う場合、このキーは存在しません。また、プリンシパルが直接呼び出しを行う場合にも存在しません。

aws:CurrentTime

日付演算子で動作します。

このキーを使用して、リクエストの日時と、ポリシーで指定した日時を比較します。この条件キーを使用するポリシーの例を表示するには、「AWS: 特定の日付内でアクセスを許可する」を参照してください。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

aws:EpochTime

日付演算子または数値演算子で動作します。

このキーを使用して、リクエストの日時(epoch または Unix 時間)をポリシーで指定した値と比較します。このキーは、1970 年 1 月 1 日からの秒数も受け付けます。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

aws:MultiFactorAuthAge

桁演算子で動作します。

このキーを使用して、リクエスト元のプリンシパルが MFA を使用して承認されてからの秒数と、ポリシーで指定した数値を比較します。MFA の詳細については、「AWS での多エレメント認証 (MFA) の使用」を参照してください。

  • 可用性 – このキーは、プリンシパルが MFA を使用して認証された場合にのみリクエストコンテキストに含まれます。MFA が使用されていなかった場合、このキーは存在しません。

aws:MultiFactorAuthPresent

ブール演算子で動作します。

このキーを使用して、リクエストを行った一時的なセキュリティ認証情報を検証するために多要素認証 (MFA) を使用したか確認します。

  • 可用性 – このキーは、プリンシパルが一時的な認証情報を使用してリクエストを行う場合にのみ、リクエストコンテキストに含まれます。このキーは、長期的な認証情報を使用して行われた AWS CLI、AWS API、または AWS SDK リクエストには存在しません。

一時的な認証情報は、IAM ロール、フェデレーティッドユーザー、sts:GetSessionToken の一時トークンを持つ IAM ユーザー、および AWS マネジメントコンソール のユーザーを認証するために使用されます。AWS マネジメントコンソール の IAM ユーザーは知らないうちに一時的な認証情報を使用します。ユーザーは、長期的な認証情報であるユーザー名とパスワードを使用してコンソールにサインインします。ただし、バックグラウンドでは、コンソールがユーザーに代わって一時的な認証情報を生成します。一時的認証情報の使用がサポートされているサービスについては、「IAM と連携する AWS のサービス」を参照してください。

aws:MultiFactorAuthPresent キーは、API または CLI コマンドがアクセスキーペアなど長期的な認証情報で呼び出された場合には表示されません。したがって、このキーを確認する場合は ...IfExists バージョンの条件演算子の使用をお勧めします。

以下の Condition 要素は、MFA を使用してリクエストが認証されるかどうかを確認する信頼性の高い方法ではない点に注意してください。

##### WARNING: NOT RECOMMENDED ##### "Effect" : "Deny", "Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : "false" } }

Deny 効果、Bool 要素、false 値のこの組み合わせは、MFA を使用して認証できるが認証されなかったリクエストを拒否します。このステートメントは、MFA の使用をサポートする一時的認証情報にのみ適用されます。このステートメントは、長期的認証情報を使用して行われるリクエスト、または MFA を使用して認証されるリクエストへのアクセスを拒否しません。ロジックが複雑で MFA 認証が実際に使用されたかどうかをテストしないため、この例は慎重に使用してください。

また、Deny 効果、Null 要素、true の組み合わせは使用しないでください。この組み合わせも同様に、ロジックはさらに複雑になるためです。

推奨される組み合わせ

BoolIfExists 演算子を使用して、リクエストが MFA を使用して認証されたかどうかを確認することをお勧めします。

"Effect" : "Deny", "Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false" } }

DenyBoolIfExistsfalse のこの組み合わせは、MFA を使用して認証されないリクエストを拒否します。具体的には、MFA を使用しないで一時的認証情報を使用して行われたリクエストを拒否します。また、AWS CLI などの長期的な認証情報またはアクセスキーを使用して行われる AWS API オペレーションを使用して行われるリクエストも拒否されます。*IfExists 演算子は、aws:MultiFactorAuthPresent キーが存在するかどうか、MFA が使用されているかどうかを確認します。これは、MFA を使用して認証されないリクエストを拒否する場合に使用します。これはより安全ですが、AWS CLI または AWS API にアクセスするためにアクセスキーを使用するコードやスクリプトを破損する可能性があります。

代替の組み合わせ

また、BoolIfExists 演算子を使用して、長期的認証情報を使用して行われる MFA 認証リクエストおよび AWS CLI または AWS API リクエストを許可することもできます。

"Effect" : "Allow", "Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "true" } }

キーが存在して MFA が使用されている場合またはキーが存在しない場合、この条件に一致となります。AllowBoolIfExiststrue のこの組み合わせは、MFA を使用して認証されたリクエスト、または MFA を使用して認証できないリクエストを許可します。つまり、リクエスタが長期的なアクセスキーを使用する場合、AWS CLI、AWS API、および AWS SDK オペレーションが許可されます。この組み合わせでは、MFA を含むことはできるが含んでいない、一時的な認証情報からのリクエストが許可されません。

IAM コンソールのビジュアルエディタを使用してポリシーを作成し、[MFA required (MFA 必須)] を選択すると、この組み合わせが適用されます。この設定では、コンソールアクセスに MFA が必要ですが、MFA なしでプログラムによるアクセスを許可します。

または、Bool 演算子を使用して、MFA を使用して認証された場合にのみ、プログラムによるリクエストとコンソールによるリクエストを許可できます。

"Effect" : "Allow", "Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : "true" } }

AllowBooltrue のこの組み合わせは、MFA 認証リクエストのみを許可します。このステートメントは、MFA の使用をサポートする一時的認証情報にのみ適用されます。このステートメントは、長期的アクセスキーを使用して行われたリクエスト、または MFA を使用しないで一時的認証情報を使用して行われたリクエストへのアクセスを許可しません。

MFA キーが存在するかを確認する場合、以下のようなポリシーは使用しないでください。

##### WARNING: USE WITH CAUTION ##### "Effect" : "Allow", "Condition" : { "Null" : { "aws:MultiFactorAuthPresent" : "false" } }

Allow 効果、Null 要素、false 値のこの組み合わせは、リクエストが実際に認証されたかどうかにかかわらず、MFA を使用して認証できるリクエストのみを許可します。これにより、一時的認証情報を使用して行われるすべてのリクエストが許可され、長期的認証情報を使用して行われたリクエストは拒否されます。MFA 認証が実際に使用されたかどうかをテストしないため、この例は慎重に使用してください。

aws:PrincipalAccount

文字列演算子で動作します。

このキーを使用して、リクエスト元のプリンシパルが属するアカウントと、ポリシーで指定したアカウント識別子を比較します。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

aws:PrincipalArn

ARN 演算子文字列演算子とともに使用します。

このキーを使用して、リクエストを行ったプリンシパルの Amazon リソースネーム (ARN) をポリシーで指定した ARN と比較します。IAM ロールの場合、リクエストコンテキストは、ロールを引き受けたユーザーの ARN ではなく、ロールの ARN を返します。この条件キーで指定できるプリンシパルのタイプについては、「プリンシパルの指定」を参照してください。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

aws:PrincipalOrgID

文字列演算子で動作します。

このキーを使用して、リクエスト元のプリンシパルが属する AWS Organizations の組織の識別子と、ポリシーで指定された識別子を比較します。

  • 可用性 – このキーは、プリンシパルが組織のメンバーである場合にのみリクエストコンテキストに含まれます。

このグローバルキーは、組織内のすべての AWS アカウントのすべてのアカウント ID を一覧表示する代わりに使用できます。この条件キーを使用して、リソースベースのポリシーでの Principal 要素の指定を簡素化します。組織 ID は、条件要素で指定できます。アカウントを追加したり削除したりすると、aws:PrincipalOrgID を含むポリシーには正しいアカウントが自動的に組み込まれ、手動で更新する必要はありません。

たとえば、以下の Amazon S3 バケットポリシーでは、o-xxxxxxxxxxx 組織の任意のアカウントのメンバーに policy-ninja-dev バケットへのオブジェクトの追加を許可します。

{ "Version": "2012-10-17", "Statement": { "Sid": "AllowPutObject", "Effect": "Allow", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::policy-ninja-dev/*", "Condition": {"StringEquals": {"aws:PrincipalOrgID":["o-xxxxxxxxxxx"]} } } }
注記

また、このグローバル条件は、AWS 組織のマスターアカウントにも適用されます。

AWS Organizations の詳細については、『AWS Organizations ユーザーガイド』の「AWS Organizations とは」を参照してください。

aws:PrincipalOrgPaths

文字列演算子で動作します。

このキーを使用して、リクエストを行っているプリンシパルの AWS Organizations パスをポリシー内のパスと比較します。プリンシパルは、IAM ユーザー、IAM ロール、フェデレーティッドユーザー、または AWS アカウントのルートユーザー です。ポリシーでは、この条件キーによって、リクエスタが AWS Organizations で指定された組織ルートまたは組織単位 (OU) 内のアカウントメンバーであることが保証されます。AWS Organizations パスは、組織 エンティティの構造をテキストで表記したものです。パスの使用と理解の詳細については、「AWS Organizations エンティティパスを理解する」を参照してください。

  • 可用性 – このキーは、プリンシパルが組織のメンバーである場合にのみリクエストコンテキストに含まれます。

注記

組織 ID はグローバルに一意ですが、OU ID とルート ID は組織内でのみ一意です。これは、2 つの組織が同じ組織 ID を共有しないことを意味します。ただし、別の組織が自分と同じ ID を持つ OU またはルートを持っている可能性があります。OU またはルートを指定するときは、必ず組織 ID を含めることをお勧めします。

たとえば、次の 条件は、ou-jkl0-awsddddd OU に直接アタッチされているが、子の OU にはアタッチされていないアカウントのプリンシパルに対して true を返します。

"Condition" : { "ForAnyValue:StringEquals" : { "aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-ghi0-awsccccc/ou-jkl0-awsddddd/"] }}

次の 条件は、OU またはその子の OU に直接アタッチされているアカウントのプリンシパルに対して true を返します。ワイルドカードを含める場合は、StringLike 条件演算子を使用する必要があります。

"Condition" : { "ForAnyValue:StringLike" : { "aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-ghi0-awsccccc/ou-jkl0-awsddddd*"] }}

次の 条件は、OU またはその子の OU に直接アタッチされているアカウントのプリンシパルに対して true を返します。

"Condition" : { "ForAnyValue:StringLike" : { "aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-ghi0-awsccccc/ou-jkl0-awsddddd/*"] }}

次の条件は、親 OU に関係なく、o-a1b2c3d4e5 組織内のすべてのプリンシパルへのアクセスを許可します。

"Condition" : { "ForAnyValue:StringLike" : { "aws:PrincipalOrgPaths":["o-a1b2c3d4e5/*"] }}

aws:PrincipalOrgPaths は複数の値を持つ条件キーです。複数の値を持つキーには、リスト形式の 1 つ以上の値が含まれます。結果は論理 OR です。ForAnyValue 条件演算子で複数の値を使用する場合、プリンシパルのパスはポリシーに一覧表示されているパスの 1 つと一致する必要があります。1 つのキーに複数の値が含まれるポリシーの場合、配列のように条件を角括弧で囲む必要があります ("Key":["Value1", "Value2"])。単一の値がある場合は、これらの括弧も含める必要があります。複数値を持つ条件キーの詳細については、「複数のキーまたは値による条件の作成」を参照してください。

"Condition": { "ForAnyValue:StringLike": { "aws:PrincipalOrgPaths": [ "o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-def0-awsbbbbb/*", "o-a1b2c3d4e5/r-f6g7h8i9j0example/ou-jkl0-awsddddd/*" ] } }

aws:PrincipalTag

文字列演算子で動作します。

このキーを使用して、リクエストを行うプリンシパルにアタッチされたタグと、ポリシーで指定したタグを比較します。プリンシパルに複数のタグがアタッチされている場合、リクエストコンテキストには、アタッチされたタグキーごとに 1 つの aws:PrincipalTag キーが含まれます。

  • 可用性 – このキーは、プリンシパルが、タグがアタッチされた IAM ユーザーである場合にリクエストコンテキストに含まれます。これは、タグまたはセッションタグがアタッチされた IAM ロールを使用するプリンシパルのために含まれます。

カスタム属性は、キーと値のペアの形式でユーザーまたはロールに追加できます。IAM タグの詳細については、「IAM ユーザーとロールのタグ付け」を参照してください。aws:PrincipalTag を使用して AWS プリンシパルのアクセスをコントロールできます。

次のようなポリシーを作成する方法を示します。この例では、 では、ユーザーは、tagManager=true タグを使用して、IAM ユーザー、グループ、ロールを管理することができます。このポリシーを使用するには、ポリシー例の斜体プレースホルダーテキストを自分の情報に置き換えます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:*", "Resource": "*", "Condition": {"StringEquals": {"aws:PrincipalTag/tagManager": "true"}} } ] }

aws:PrincipalType

文字列演算子で動作します。

このキーを使用して、リクエストを行うプリンシパルと、ポリシーで指定したプリンシパルのタイプを比較します。さまざまなプリンシパルのリクエストコンテキストに情報がどのように表示されるかについては、「プリンシパルの指定」を参照してください。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

aws:Referer

文字列演算子で動作します。

このキーを使用して、クライアントブラウザでリクエストを参照したユーザーとポリシーで指定したリファラーを比較します。aws:referer リクエストコンテキストの値は、HTTP ヘッダーで呼び出し元によって提供されます。

  • 可用性 – このキーは、リクエストがブラウザの URL を使用して呼び出された場合にのみリクエストコンテキストに含まれます。

たとえば、ウェブブラウザを使用して Amazon S3 API オペレーションを直接呼び出すことができます。つまり、イメージやドキュメントなどの S3 オブジェクトをウェブブラウザから直接表示できます。aws:referer 条件では、参照子のヘッダーの値に基づいて HTTP または HTTPS リクエストの特定の値へのアクセスを制限できます。

警告

このキーは慎重に使用する必要があります。一般に知られている参照子のヘッダー値を含めるのは危険です。不正な当事者は、変更されたブラウザまたはカスタムブラウザを使用して任意の aws:referer 値を提供することができます。そのため aws:referer は、不正な当事者から AWS にリクエストが直接行われることを防止するために使用しないでください。このキーは、Amazon S3 に保存されているデジタルコンテンツなど、不正なサードパーティサイトで参照されることから保護するためにのみ、お客様に提供されています。

aws:RequestedRegion

文字列演算子で動作します。

このキーを使用して、リクエストで呼び出された AWS リージョンとポリシーで指定したリージョンを比較します。このグローバル条件キーを使用して、リクエストできるリージョンを制御できます。各サービスの AWS リージョンを表示するには、『アマゾン ウェブ サービス全般のリファレンス』の「Service endpoints and quotas」を参照してください。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

IAM などのグローバルサービスには、単一のエンドポイントがあります。ただし、このエンドポイントが 米国東部(バージニア北部) リージョンに物理的に配置されているため、IAM 呼び出しは常に us-east-1 リージョンに対して実行されます。たとえば、リクエストされたリージョンが us-west-2 でない場合にすべてのサービスへのアクセスを拒否するポリシーを作成すると、IAM 呼び出しは必ず失敗します。これを回避する方法の例を表示するには、「Deny での NotAction の使用」を参照してください。

注記

aws:RequestedRegion 条件キーを使用すると、呼び出されるサービスのエンドポイントを制御できますが、オペレーションの影響を制御することはできません。一部のサービスではリージョン間の影響があります。たとえば、Amazon S3 にはリージョン間レプリケーションを制御する API オペレーションがあります。1 つのリージョン(aws:RequestedRegion の条件キーの影響を受ける)で s3:PutBucketReplication を呼び出すことはできますが、他のリージョンはレプリケーションの構成設定に基づいて影響を受けます。

このコンテキストキーを使用して、指定された一連のリージョン内の AWS サービスへのアクセスを制限できます。たとえば、以下のポリシーでは、AWS マネジメントコンソール でのすべての Amazon EC2 インスタンスの表示をユーザーに許可します。ただし、変更できるインスタンスは、アイルランド (eu-west-1)、ロンドン (eu-west-2)、パリ (eu-west-3) のみです。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "InstanceConsoleReadOnly", "Effect": "Allow", "Action": [ "ec2:Describe*", "ec2:Export*", "ec2:Get*", "ec2:Search*" ], "Resource": "*" }, { "Sid": "InstanceWriteRegionRestricted", "Effect": "Allow", "Action": [ "ec2:Associate*", "ec2:Import*", "ec2:Modify*", "ec2:Monitor*", "ec2:Reset*", "ec2:Run*", "ec2:Start*", "ec2:Stop*", "ec2:Terminate*" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": [ "eu-west-1", "eu-west-2", "eu-west-3" ] } } } ] }

aws:RequestTag/tag-key

文字列演算子で動作します。

このキーを使用して、リクエストで渡されたタグキーと値のペアと、ポリシーで指定したタグペアを比較します。たとえば、リクエストに「"Dept"」タグキーが含まれ、「"Accounting"」という値が含まれているかどうかを確認できます。詳細については、「AWS リクエスト時のアクセスの制御」を参照してください。

  • 可用性 – このキーは、リクエストでタグが渡されたときにリクエストコンテキストに含まれます。複数のタグがリクエストで渡されると、タグキーと値のペアごとに 1 つのコンテキストキーがあります。

このコンテキストキーは "aws:RequestTag/tag-key":"tag-value" という形式です。ここで tag-key および tag-value はタグキーと値のペアです。

1 つのリクエストに複数のタグとキーと値のペアを含めることができるため、リクエストのコンテンツは複数の値を持つリクエストである場合があります。この場合、 ForAllValues または ForAnyValue 設定演算子の使用を検討する必要があります。詳細については、「複数のキーと値の使用」を参照してください。

aws:ResourceTag/tag-key

文字列演算子で動作します。

このキーを使用して、ポリシーで指定したタグキーと値のペアと、リソースにアタッチされているキーと値のペアを比較します。たとえば、リソースに値 "Marketing" の付いたタグキー "Dept" がアタッチされている場合にのみ、そのリソースへのアクセスを許可するように要求することができます。詳細については、「AWS リソースへのアクセスの制御」を参照してください。

  • 可用性 – このキーは、リクエストされたリソースにすでにタグがアタッチされている場合、リクエストコンテキストに含まれます。このキーは、タグに基づいて認証をサポートするリソースに対してのみ返されます。タグキーと値のペアごとに 1 つのコンテキストキーがあります。

このコンテキストキーは "aws:ResourceTag/tag-key":"tag-value" という形式です。ここで tag-key および tag-value はタグキーと値のペアです。

aws:SecureTransport

ブール演算子で動作します。

このキーを使用してリクエストが SSL を使用して送信されたかどうかを確認します。リクエストコンテキストは true または false を返します。ポリシーでは、リクエストが SSL を使用して送信された場合にのみ、特定のアクションを許可できます。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

aws:SourceAccount

文字列演算子で動作します。

このキーを使用して、サービス間リクエストを行っているリソースのアカウント IDを、ポリシーで指定したアカウント ID と比較します。

  • 可用性 – このキーは、リソース所有者に代わって別のサービスを呼び出すようリソースへのアクセスで AWS サービスをトリガーした場合にのみ、リクエストコンテキストに含まれます。呼び出し元のサービスは、ソースのリソース ARN を呼び出し先のサービスに渡す必要があります。この ARN には、ソースアカウント ID が含まれます。

この条件キーを使用して、 Amazon S3 が 混乱した代理として使用されていないことを確認できます。たとえば、Amazon S3 バケットの更新によって Amazon SNS トピック投稿がトリガーされると、Amazon S3 サービスは sns:Publish API オペレーションを呼び出します。このバケットは SNS リクエストのソースと見なされ、キーの値はバケットの ARN のアカウント ID です。

aws:SourceArn

ARN 演算子文字列演算子とともに使用します。

このキーを使用して、サービス間リクエストを行っているリソースの Amazon リソースネーム (ARN) を、ポリシーで指定した ARN と比較します。

このキーは、リクエストを行うプリンシパルの ARN では機能しません。代わりに aws:PrincipalArn を使用します。ソースの ARN にはアカウント ID が含まれているため、aws:SourceArnaws:SourceAccount を使用する必要はありません 。

  • 可用性 – このキーは、リソース所有者に代わって別のサービスを呼び出すようリソースへのアクセスで AWS サービスをトリガーした場合にのみ、リクエストコンテキストに含まれます。呼び出し元のサービスは、元のリソースの ARN を呼び出し先のサービスに渡す必要があります。

この条件キーを使用して、Amazon S3 が混乱した代理として使用されていないことを確認することができます。たとえば、Amazon S3 バケットの更新によって Amazon SNS トピック投稿がトリガーされると、Amazon S3 サービスは sns:Publish API オペレーションを呼び出します。このバケットは SNS リクエストのソースと見なされ、キーの値はバケットの ARN です。

aws:SourceIp

IP アドレス演算子で動作します。

このキーを使用して、リクエスタの IP アドレスをポリシーで指定した IP アドレスと比較します。

  • 可用性 – このキーは、リクエスタが VPC エンドポイントを使用してリクエストを行う場合を除き、リクエストコンテキストに含まれます。

aws:SourceIp 条件キーをポリシーで使用して、プリンシパルが指定された IP 範囲内からのみリクエストを行うことを許可できます。ただし、AWS サービスがプリンシパルの代わりに呼び出しを行う場合、このポリシーはアクセスを拒否します。この場合、aws:ViaAWSService キーと共に aws:SourceIp を使用して、プリンシパルによって直接行われたリクエストにのみソース IP 制限が適用されるようにできます。

たとえば、IAM ユーザーに次のポリシーをアタッチできます。このポリシーでは、指定された IP アドレスから呼び出しを行う場合に、ユーザーがオブジェクトを直接 my-service-bucket Amazon S3 バケットに入れることができます。ただし、ユーザーがサービスで Amazon S3 を呼び出す別のリクエストを実行する場合、IP アドレスの制限は適用されません。PrincipalPutObjectIfIpAddress ステートメントは、リクエストがサービスによって実行されない場合にのみ、IP アドレスを制限します。ServicePutObject ステートメントは、リクエストがサービスによって実行された場合、IP アドレスの制限なしでオペレーションを許可します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "PrincipalPutObjectIfIpAddress", "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-service-bucket/*", "Condition": { "Bool": {"aws:ViaAWSService": "false"}, "IpAddress": {"aws:SourceIp": "123.45.167.89"} } }, { "Sid": "ServicePutObject", "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-service-bucket/*", "Condition": { "Bool": {"aws:ViaAWSService": "true"} } } ] }

リクエスト実行元が Amazon VPC エンドポイントを使用するホストである場合、aws:SourceIp キーは使用できません。代わりに、aws:VpcSourceIpなどの VPC 固有のキーを使用する必要があります。VPC エンドポイントの使用の詳細については、Amazon VPC ユーザーガイド の「VPC エンドポイント - エンドポイントの使用の管理」を参照してください。

aws:SourceVpc

文字列演算子で動作します。

このキーを使用して、リクエストがポリシーで指定した VPC からのものであるかどうかを確認します。ポリシーでは、このキーを使用して、特定の VPC にのみアクセスを許可できます。詳細については、『Amazon Simple Storage Service 開発者ガイド』の「特定の VPC へのアクセスの制限」を参照してください。

  • 可用性 – このキーは、リクエスタが VPC エンドポイントを使用してリクエストを行う場合にのみリクエストコンテキストに含まれます。

aws:SourceVpce

文字列演算子で動作します。

このキーを使用して、リクエストの VPC エンドポイント識別子をポリシーで指定したエンドポイント ID と比較します。ポリシーでは、このキーを使用して、特定の VPC エンドポイントへのアクセスを制限できます。詳細については、『Amazon Simple Storage Service 開発者ガイド』の「特定の VPC へのアクセスの制限」を参照してください。

  • 可用性 – このキーは、リクエスタが VPC エンドポイントを使用してリクエストを行う場合にのみリクエストコンテキストに含まれます。

aws:TagKeys

文字列演算子で動作します。

このキーを使用して、リクエスト内のタグキーとポリシーで指定したキーを比較します。ベストプラクティスとして、ポリシーでタグを使用してアクセスを制御する場合は、aws:TagKeys 条件キーを使用して、許可されるタグキーを定義できます。ポリシー例と詳細については、「タグキーに基づいたアクセスの制御」を参照してください

  • 可用性 – このキーは、オペレーションがリソースへのタグのアタッチをサポートしている場合にのみリクエストコンテキストに含まれます。

このコンテキストキーは "aws:TagKeys":"tag-key" という形式であり、ここで tag-key は値 (["Dept","Cost-Center"] など) のないタグキーのリストです。

1 つのリクエストに複数のタグとキーと値のペアを含めることができるため、リクエストのコンテンツは複数の値を持つリクエストである場合があります。この場合、 ForAllValues または ForAnyValue 設定演算子の使用を検討する必要があります。詳細については、「複数のキーと値の使用」を参照してください。

一部のサービスでは、リソースの作成、変更、削除などのリソースオペレーションを使用したタグ付けをサポートしています。1 回の呼び出しでタグ付けとオペレーションを許可するには、タグ付けアクションとリソース変更アクションの両方を含むポリシーを作成する必要があります。次に、aws:TagKeys 条件キーを使用して、リクエストで特定のタグキーを使用して適用できます。たとえば、だれかが Amazon EC2 スナップショットを作成するときにタグを制限するには、ポリシーに ec2:CreateSnapshot の作成アクションおよび ec2:CreateTags のタグ付けアクションを含める必要があります。aws:TagKeys を使用するこのシナリオのポリシーを表示するには、Linux インスタンス用 Amazon EC2 ユーザーガイドの「タグ付きのスナップショットの作成」を参照してください。

aws:TokenIssueTime

日付演算子で動作します。

このキーを使用して、一時的なセキュリティ認証情報が発行された日時と、ポリシーで指定した日時を比較します。

  • 可用性 – このキーは、プリンシパルが一時的な認証情報を使用してリクエストを行う場合にのみ、リクエストコンテキストに含まれます。このキーは、アクセスキーを使用して行われたAWS CLI、AWS API、または AWS SDK リクエストには存在しません。

一時的認証情報の使用がサポートされているサービスについては、「IAM と連携する AWS のサービス」を参照してください。

aws:UserAgent

文字列演算子で動作します。

このキーを使用して、リクエスタのクライアントアプリケーションとポリシーで指定したアプリケーションを比較します。

  • 可用性 – このキーは常にリクエストコンテキストに含まれます。

警告

このキーは慎重に使用する必要があります。しかし、aws:UserAgent 値は HTTP ヘッダー内の発信者によって渡されるため、不正な当事者が改造またはカスタムブラウザを使用して任意の aws:UserAgent 値を渡すことができます。そのため aws:UserAgent は、不正な当事者から AWS にリクエストが直接行われることを防止するために使用しないでください。このステートメントを使用して、ポリシーをテストした後にのみ、特定のクライアントアプリケーションのみを許可できます。

aws:userid

文字列演算子で動作します。

このキーを使用して、リクエスタのプリンシパル識別子とポリシーで指定した識別子を比較します。IAM ユーザーの場合、リクエストコンテキスト値はユーザー ID です。IAM ロールの場合、この値の形式はさまざまです。さまざまなプリンシパルで情報がどのように表示されるかについては、「プリンシパルの指定」を参照してください。

  • 可用性 – このキーは、すべての署名付きリクエストのリクエストコンテキストに含まれます。匿名リクエストには、このキーは含まれません。

aws:username

文字列演算子で動作します。

このキーを使用して、リクエスタのユーザー名をポリシーで指定したユーザー名と比較します。さまざまなプリンシパルで情報がどのように表示されるかについては、「プリンシパルの指定」を参照してください。

  • 可用性 – このキーは常に IAM ユーザーのリクエストコンテキストに含まれます。匿名のリクエストと AWS アカウントのルートユーザー ロールまたは IAM ロールを使用して行われたリクエストには、このキーは含まれません。

aws:ViaAWSService

ブール演算子で動作します。

このキーを使用して、AWS サービスがユーザーに代わって別のサービスにリクエストを実行するかどうか確認します。

サービスが IAM プリンシパルの認証情報を使用し、プリンシパルに代わってリクエストを実行すると、リクエストコンテキストキーは true を返します。サービスがサービスロールまたはサービスリンクロールを使用してプリンシパルに代わって呼び出しを行う場合、コンテキストキーは false を返します。リクエストコンテキストキーは、プリンシパルが直接呼び出しを行ったときも false を返します。

  • 可用性 – このキーは常に多くのサービスのリクエストコンテキストに含まれます。

以下のサービスは、現在サポートされていません。aws:ViaAWSService

  • Amazon EC2

  • AWS Glue

  • AWS Lake Formation

  • AWS OpsWorks

この条件キーを使用して、リクエストがサービスによって行われたかどうかに基づいてアクセスを許可または拒否できます。ポリシーの例を表示するには、「AWS: 送信元 IP に基づいて AWS へのアクセスを拒否する」を参照してください。

aws:VpcSourceIp

IP アドレス演算子で動作します。

このキーを使用して、リクエストの作成元の IP アドレスと、ポリシーで指定した IP アドレスを比較します。ポリシーでは、リクエストが指定された IP アドレスから送信され、VPC エンドポイントを経由する場合にのみキーが一致します。

  • 可用性 – このキーは、リクエストが VPC エンドポイントを使用して行われた場合にのみリクエストコンテキストに含まれます。

詳細については、Amazon VPC ユーザーガイド の「VPC エンドポイントによるサービスのアクセスコントロール」を参照してください。