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

プリンシパルが AWS にリクエストを行うと、AWS はリクエスト情報をリクエストコンテキストに収集します。JSON ポリシーの Condition 要素を使用して、リクエストコンテキストのキーを、ポリシーで指定したキー値と比較できます。リクエスト情報は、リクエストを行うプリンシパル、リクエストの対象となるリソース、リクエスト自体に関するメタデータなど、さまざまなソースから提供されます。

グローバル条件キーは、すべての AWS サービスで使用できます。これらの条件キーはすべてのポリシーで使用できますが、キーはすべてのリクエストコンテキストで使用できるわけではありません。例えば、aws:SourceAccount 条件キーは、リソースへの呼び出しが AWS サービスプリンシパル によって直接行われた場合にのみ使用できます。グローバルキーがリクエストコンテキストに含まれる状況の詳細については、各キーの可用性情報を参照してください。

個別のサービスの中には、他のサービスのリクエストコンテキストで使用できる独自の条件キーを作成するものもあります。クロスサービス条件キーは、ec2: や lambda: など、サービスの名前と一致するプレフィックスを含むグローバル条件キーの一種ですが、他のサービスで使用できます。

サービス固有の条件キーは、個々の AWS サービスで使用するように定義されています。例えば、Amazon S3 では、s3:VersionId 条件キーを使用してポリシーを作成し、Amazon S3 オブジェクトの特定のバージョンへのアクセスを制限できます。この条件キーはサービス固有です。つまり、Amazon S3 サービスへのリクエストでのみ機能します。サービス固有の条件キーについては、「AWS サービスのアクション、リソース、および条件キー」を参照し、キーを表示するサービスを選択してください。

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

プリンシパルのプロパティ

次の条件キーを使用して、リクエストを行うプリンシパルの詳細を、ポリシーで指定したプリンシパルのプロパティと比較します。リクエストを実行できるプリンシパルのリストについては、「プリンシパルの指定」を参照してください。

aws:PrincipalArn

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

AWS Organizations サービスコントロールポリシー (SCP) の条件キー aws:PrincipalArn の値としてルートユーザー ARN を指定することができます。SCP は、組織のアクセス許可の管理に使用される組織ポリシーの一種で、組織内のメンバーアカウントにのみ影響します。SCP は、メンバーアカウントのルートユーザーを含む、メンバーアカウントの IAM ユーザーとロールのアクセス許可を制限します。SCP がアクセス許可に与える影響については、「Organizations ユーザーガイド」の「アクセス許可における SCP 効果」を参照してください。

aws:PrincipalAccount

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

次の例では、アカウント番号が 123456789012 のプリンシパル以外に対するアクセスは拒否されます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessFromPrincipalNotInSpecificAccount",
      "Action": "service:*",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:service:region:accountID:resource"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalAccount": [
            "123456789012"
          ]
        }
      }
    }
  ]
}
        

aws:PrincipalOrgPaths

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

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

"Condition" : { "ForAnyValue:StringEquals" : {
     "aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/"]
}}

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

"Condition" : { "ForAnyValue:StringLike" : {
     "aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/*"]
}}

次の条件は、OU またはその子の OU に直接アタッチされているアカウントのプリンシパルに対して true を返します。以前の条件は、OU または任意の子を対象としています。以下の条件は、子のみ (およびそれらの子のすべての子) を対象としています 。

"Condition" : { "ForAnyValue:StringLike" : {
     "aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/ou-*"]
}}

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

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

aws:PrincipalOrgPaths は複数の値を持つ条件キーです。複数値のキーは、リクエストコンテキストに複数の値を持つことができます。ForAnyValue 条件演算子で複数の値を使用する場合、プリンシパルのパスはポリシーに一覧表示されているパスの 1 つと一致する必要があります。複数値を持つ条件キーの詳細については、「複数値のコンテキストキー」を参照してください。

    "Condition": {
        "ForAnyValue:StringLike": {
            "aws:PrincipalOrgPaths": [
                "o-a1b2c3d4e5/r-ab12/ou-ab12-33333333/*",
                "o-a1b2c3d4e5/r-ab12/ou-ab12-22222222/*"
            ]
        }
    }

aws:PrincipalOrgID

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

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

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

 {
  "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 Organizations の詳細については、AWS Organizationsユーザーガイドの「AWS Organizations とは」を参照してください。

aws:PrincipalTag/tag-key

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

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

この例では、department=hr タグを持つユーザーが IAM ユーザー、グループ、またはロールを管理できるようにするID ベースポリシーを作成する方法を示しています。このポリシーを使用するには、サンプルポリシーのイタリック体のプレースホルダーテキストを独自の情報に置き換えます。次に、「ポリシーの作成またはポリシーの編集」の手順に従います。

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

aws:PrincipalIsAWSService

このキーを使用して、リソースへの呼び出しが AWS サービスプリンシパルによって直接行われているかどうかを確認します。たとえば、AWS CloudTrail はサービスプリンシパル cloudtrail.amazonaws.com を使用して、Amazon S3 バケットにログを書き込みます。サービスがサービスプリンシパルを使用してリソースに対して直接アクションを実行する場合、リクエストコンテキストキーは true に設定されます。サービスが IAM プリンシパルの認証情報を使用し、プリンシパルに代わってリクエストを行う場合、コンテキストキーは false に設定されます。また、サービスがサービスロールまたはサービスリンクロールを使用してプリンシパルに代わって呼び出しを行う場合も、false に設定されます。

この条件キーを使用して、AWS サービスへのアクセスを安全に許可しながら、信頼できる ID と予想されるネットワークの場所へのアクセスを制限できます。

次の Amazon S3 バケットポリシーの例では、リクエストが vpc-111bbb22 から発信されているか、CloudTrail などのサービスプリンシパルから発信されていない限り、バケットへのアクセスが制限されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Expected-network+service-principal",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/AWSLogs/AccountNumber/*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceVpc": "vpc-111bbb22"
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

次のビデオでは、ポリシーで aws:PrincipalIsAWSService 条件キーを使用する方法について詳しく説明します。

aws:PrincipalServiceName

このキーを使用して、サービスプリンシパルの名前を、リソースにリクエストするサービスプリンシパルとともに設定します。このキーを使用して、この呼び出しが特定のサービスプリンシパルによって行われたかどうかを確認できます。サービスプリンシパルがリソースに直接リクエストする場合、aws:PrincipalServiceName キーには、サービスプリンシパルの名前が含まれます。たとえば、AWS CloudTrail のサービスプリンシパル名は cloudtrail.amazonaws.com です。

この条件キーを使用して、AWS サービスへのアクセスを安全に許可しながら、信頼できる ID と予想されるネットワークの場所へのアクセスを制限できます。

次の Amazon S3 バケットポリシーの例では、リクエストが vpc-111bbb22 から発信されているか、CloudTrail などのサービスプリンシパルから発信されていない限り、バケットへのアクセスが制限されています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "expected-network+service-principal",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/AWSLogs/AccountNumber/*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceVpc": "vpc-111bbb22",
          "aws:PrincipalServiceName": "cloudtrail.amazonaws.com"
        }
      }
    }
  ]
}
        

aws:PrincipalServiceNamesList

このキーは、サービスに属するすべてのサービスプリンシパル名のリストを提供します。これは高度な条件キーです。これを使用して、サービスが特定のリージョンからのみリソースにアクセスすることを制限できます。一部のサービスでは、特定のリージョン内のサービスの特定のインスタンスを示すために、リージョナルサービスプリンシパルを作成できます。リソースへのアクセスをサービスの特定のインスタンスに制限できます。サービスプリンシパルがリソースに直接リクエストを行うと、aws:PrincipalServiceNamesList には、サービスのリージョナルインスタンスに関連付けられているすべてのサービスプリンシパル名の順序付けられていないリストが含まれます。

aws:PrincipalServiceNamesList は複数の値を持つ条件キーです。複数値のキーは、リクエストコンテキストに複数の値を持つことができます。このキーを使用する場合は、文字列条件演算子とともに ForAnyValue または ForAllValues の集合演算子を使用する必要があります。複数値を持つ条件キーの詳細については、「複数値のコンテキストキー」を参照してください。

aws:PrincipalType

このキーを使用して、リクエストを行うプリンシパルと、ポリシーで指定したプリンシパルのタイプを比較します。詳細については、「プリンシパルの指定」を参照してください。principal キーの値の具体的な例については、「プリンシパルキーの値」を参照してください。

aws:userid

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

aws:username

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

ロールセッションのプロパティ

次の条件キーを使用して、セッション生成時のロールセッションのプロパティを比較します。これらの条件キーは、ロールセッションまたはフェデレーションユーザー認証情報を持つプリンシパルによってリクエストが行われた場合にのみ使用できます。これらの条件キーの値は、ロールのセッショントークンに埋め込まれます。

ロールはプリンシパルの一種です。プリンシパルのプロパティ セクションの条件キーを使用して、ロールのリクエスト実行中にロールのプロパティを評価することもできます。

aws:FederatedProvider

このキーを使用して、プリンシパルが発行した ID プロバイダー (IdP) とポリシーで指定した識別子とを比較します。つまり IAM ロールは、AssumeRoleWithWebIdentity AWS STS オペレーションを使用して引き受けられたということです。結果のロールセッションの一時認証情報を使用してリクエストを作成する場合、リクエストコンテキストは、元のフェデレーティッド ID を認証した IdP を識別します。

例えば、ユーザーが Amazon Cognito を使用して認証された場合、リクエストコンテキストには cognito-identity.amazonaws.com という値が含まれます。同様に、ユーザーが Login with Amazon を使用して認証された場合、リクエストコンテキストには www.amazon.com という値が含まれます。

単一値の条件キーは、変数として使用できます。次のリソースベースのポリシーの例では、リソースの ARN において aws:FederatedProvider キーをポリシー変数として使用しています。このポリシーでは、IdP を使用して認証されたプリンシパルが、発行元の ID プロバイダーに特有のパスを使用して、Amazon S3 からオブジェクトを取得できます。

aws:TokenIssueTime

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

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

aws:MultiFactorAuthAge

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

aws:MultiFactorAuthPresent

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

一時的な認証情報は、AssumeRole または GetSessionToken の一時トークンを持つ IAM ロールと IAM ユーザー、および AWS Management Consoleのユーザーを認証するために使用されます。

IAM ユーザーアクセスキーは、長期的な認証情報ですが、場合によっては AWS は、IAM ユーザーの代わりに一時的な認証情報を作成し、操作を実行します。このような場合、aws:MultiFactorAuthPresent キーはリクエストに存在し、false の値に設定されます。これが起こる一般的なケースは、次の 2 つです。

一時的認証情報の使用がサポートされているサービスについては、「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" } }

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

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

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

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

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

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

#####   WARNING: USE WITH CAUTION   #####

"Effect" : "Allow",
"Condition" : { "Null" : { "aws:MultiFactorAuthPresent" : "false" } }

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

aws: Ec2InstanceSourceVpc

このキーは、Amazon EC2 IAM ロール認証情報が配信された VPC を識別します。aws:SourceVPCグローバルキーを含むポリシーでこのキーを使用すると、認証情報が配信された VPC (aws:SourceVPC) と一致する VPC から呼び出しが行われたかどうかを確認できます (aws:Ec2InstanceSourceVpc)。

このキーは VPC 識別子の値と共に使用できますが、aws:SourceVpc コンテキストキーと組み合わせた変数として使用すると最も便利です。この aws:SourceVpc コンテキストキーは、リクエスタが VPC エンドポイントを使用してリクエストを行う場合にのみリクエストコンテキストに含まれます。aws:Ec2InstanceSourceVpc とaws:SourceVpc を使用すると、通常は一緒に変化する値を比較できるため、aws:Ec2InstanceSourceVpc をより幅広く使用できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireSameVPC",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
            "aws:SourceVpc": "${aws:Ec2InstanceSourceVpc}"
        },
        "Null": {
          "ec2:SourceInstanceARN": "false"
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

上記の例では、aws:SourceVpc 値が aws:Ec2InstanceSourceVpc 値と等しくない場合、アクセスは拒否されます。ポリシーステートメントは、ec2:SourceInstanceARN 条件キーの有無をテストして Amazon EC2 インスタンスのロールとして使用されるロールのみに限定されます。

このポリシーでは、Amazon EC2 インスタンスロールに代わってリクエストが行われた場合に、aws:ViaAWSService が AWS リクエストを許可するようにしています。たとえば、Amazon EC2 インスタンスから暗号化された Amazon S3 バケットにリクエストを行うと、Amazon S3 がお客様に代わって AWS KMS を呼び出します。リクエストが AWS KMS に行われたときに、一部のキーが表示されません。

aws:Ec2InstanceSourcePrivateIPv4

このキーは、Amazon EC2 IAM ロール認証情報が配信されたプライマリ elastic network interface プライベート IPv4 アドレスを識別します。VPC ID とソースプライベート IP をグローバルに一意に組み合わせるには、この条件キーをコンパニオンキー aws:Ec2InstanceSourceVpc と一緒に使用する必要があります。このキー aws:Ec2InstanceSourceVpc を使用して、認証情報が配信されたのと同じプライベート IP アドレスからリクエストが行われたことを確認します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action":  "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:Ec2InstanceSourceVpc": "${aws:SourceVpc}"
                },                
                "Null": {
                    "ec2:SourceInstanceARN": "false"
                },
                "BoolIfExists": {
                    "aws:ViaAWSService": "false"
                }
            }
        },
        {
            "Effect": "Deny",
            "Action":  "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:Ec2InstanceSourcePrivateIPv4": "${aws:VpcSourceIp}"
                },                               
                "Null": {
                    "ec2:SourceInstanceARN": "false"
                },
                "BoolIfExists": {
                    "aws:ViaAWSService": "false"
                }
            }
        }
    ]
}

aws:SourceIdentity

プリンシパルによって設定されたソース ID と、ポリシーで指定したソース ID を比較するには、このキーを使用します。

ポリシーでこのキーを使用して、ロールを引き受けるときにソースIDを設定したプリンシパルによる AWS でのアクションを許可できます。ロールの指定されたソースIDのアクティビティが AWS CloudTrail に表示されます。これにより、管理者は AWS のロールで誰または何がアクションを実行したかを簡単に判断できます。

sts:RoleSessionName とは異なり、ソースIDを設定した後は、値を変更できません。これは、ロールが実行するすべてのアクションのリクエストコンテキストに存在します。この値は、セッション認証情報を使用して別のロールを引き受けるときに、後続のロールセッションに保持されます。別のロールからあるロールを引き受けると、ロールの連鎖と呼ばれます。

sts:SourceIdentity キーは、プリンシパルが、AWS STS assume-role CLI コマンドまたは AWS STS AssumeRole API オペレーションを使用してロールを引き受けるときに、最初にソース ID を設定するときに、リクエストに存在します。aws:SourceIdentity キーは、ソースIDが設定されているロールセッションで実行されるすべてのアクションの要求に存在します。

アカウント CriticalRole の 111122223333 の次のロール信頼ポリシーには、Saanvi または Diego に設定されているソース ID を持たないプリンシパルがロールを引き受けることを防ぐ aws:SourceIdentity のための条件が含まれています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AssumeRoleIfSourceIdentity",
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:role/CriticalRole"},
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity"
            ],
            "Condition": {
                "StringLike": {
                    "aws:SourceIdentity": ["Saanvi","Diego"]
                }
            }
        }
    ]
}

ソース ID 情報の使用の詳細については、「引き受けたロールで実行されるアクションのモニタリングと制御」を参照してください。

ec2:RoleDelivery

このキーを使用して、署名付きリクエストのインスタンスメタデータサービスのバージョンを、Amazon EC2 の IAM ロール認証情報と比較します。インスタンスメタデータサービスは、所定のリクエストについて、IMDSv2 に固有の PUT または GET ヘッダーがそのリクエストに存在するかどうかによって、IMDSv1 と IMDSv2 リクエストを区別します。

ローカルコードまたはユーザーに IMDSv2 を使用させるように、各インスタンスのインスタンスメタデータサービス (IMDS) を設定することができます。IMDSv2を使用しなければならないように指定すると、IMDSv1はもう機能しなくなります。

IMDSv2 を使用するようにインスタンスを設定する方法については、「インスタンスメタデータオプションの設定」を参照してください。

次の例では、リクエストコンテキストの ec2:RoleDelivery の値が 1.0 (IMDSv1) の場合、アクセスが拒否されます。このポリシーステートメントは、リクエストが Amazon EC2 ロールの認証情報によって署名されていない場合は無効となるため、一般的に適用できます。

{
    "Version": "2012-10-17",
    "Statement": [
               {
            "Sid": "RequireAllEc2RolesToUseV2",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "NumericLessThan": {
                    "ec2:RoleDelivery": "2.0"
                }
            }
        }
    ]
}

詳細については、「インスタンスメタデータを使用する際のサンプルポリシー」を参照してください。

ec2:SourceInstanceArn

このキーを使用して、ロールのセッション生成元インスタンスの ARN を比較します。

ポリシーの例については、「特定のインスタンスが他の AWS サービスでリソースを表示できるようにする」を参照してください。

glue:RoleAssumedBy

AWS Glue サービスは、AWS Glue がお客様に変わってサービスロールを使用してリクエストを実行する AWS API リクエストごとに条件キーを設定します (ジョブまたは開発者のエンドポイントではなく、AWS Glue サービスによる直接のリクエスト)。このキーを使用して、AWS リソースへの呼び出しが AWS Glue サービスからのものであるかどうかを確認します。

次の例では、AWS Glue サービスが Amazon S3 バケットからオブジェクトを取得できるようにする条件を追加します。

{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::confidential-bucket/*",
    "Condition": {
        "StringEquals": {
            "glue:RoleAssumedBy": "glue.amazonaws.com"
        }
    }
}

glue:CredentialIssuingService

AWS Glue サービスは、ジョブまたは開発者エンドポイントから取得したサービスロールを使用して、AWS API リクエストごとにこのキーを設定します。このキーを使用して、AWS リソースへの呼び出しが AWS Glue ジョブまたは開発者エンドポイントからのものであるかどうかを確認します。

次の例では、AWS Glue ジョブで使用される IAM ロールにアタッチされる条件を追加します。これで、特定のアクションが、ロールセッションが AWS Glue ジョブランタイム環境で使用されているかどうかに基づいて、許可/拒否されます。

{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::confidential-bucket/*",
    "Condition": {
        "StringEquals": {
            "glue:CredentialIssuingService": "glue.amazonaws.com"
        }
    }
}

lambda:SourceFunctionArn

このキーを使用して、IAM ロール認証情報が配信された Lambda 関数 ARN を識別します。Lambda サービスは、関数の実行環境から送信される AWS API リクエストごとにこのキーを設定します。このキーを使用して、AWS リソースへの呼び出しが特定の Lambda 関数のコードからのものであるかどうかを確認します。Lambda は、CloudWatch へのログの書き込みや X-Ray へのトレース送信など、実行環境外から送信される一部のリクエストにもこのキーを設定します。

次の例では、1 つの特定の Lambda 関数に、指定されたバケットへの s3:PutObject アクセスを許可します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ExampleSourceFunctionArn",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
            "Condition": {
                "ArnEquals": {
                    "lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
                }
            }
        }
    ]
}

詳細については、「AWS Lambda デベロッパーガイド」の「Lambda 実行環境での認証情報の使用」を参照してください。

ssm:SourceInstanceArn

このキーを使用して、IAM ロール認証情報が配信された AWS Systems Manager マネージドインスタンス ARN を識別します。この条件キーは、リクエストが Amazon EC2 インスタンスプロファイルに関連付けられている IAM ロールを使用してマネージドインスタンスから実行された場合は存在しません。

identitystore:UserId

このキーを使用して、署名付きリクエストの IAM アイデンティティセンターワークフォース ID を、ポリシーで指定された ID と比較します。

AWS CLI、AWS API、AWS SDK を使用して GetUserId API にリクエストを実行することで、IAM アイデンティティセンターのユーザーの UserId を見つけることができます。

ネットワークのプロパティ

次の条件キーを使用して、リクエストの発信元ネットワークまたは経由するネットワークの詳細を、ポリシーで指定したプリンシパルのプロパティと比較します。

aws:SourceIp

このキーを使用して、リクエスタの IP アドレスをポリシーで指定した IP アドレスと比較します。aws:SourceIp 条件キーは、パブリック IP アドレス範囲にのみ使用できます。

aws:SourceIp 条件キーをポリシーで使用して、プリンシパルが指定された IP 範囲内からのみリクエストを行うことを許可できます。

例えば、次の ID ベースのポリシーを IAM ロールにアタッチできます。このポリシーは、指定された IPv4 アドレス範囲から呼び出しを実行する場合に、ユーザーがオブジェクトを DOC-EXAMPLE-BUCKET3 Amazon S3 バケットに格納することを許可します。このポリシーでは、転送アクセスセッション がユーザーに代わってこの操作を実行する AWS サービスも許可されます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PrincipalPutObjectIfIpAddress",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET3/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        }
    ]
}

IPv4 と IPv6 の両方のアドレス指定をサポートするネットワークからのアクセスを制限する必要がある場合は、IAM ポリシー条件に IPv4 と IPv6 のアドレス、または IP アドレスの範囲を含めることができます。次の ID ベースのポリシーは、ユーザーが指定された IPv4 または IPv6 のいずれかのアドレス範囲から呼び出しを実行した場合に、オブジェクトを DOC-EXAMPLE-BUCKET3 Amazon S3 バケットに格納することを許可します。IAM ポリシーに IPv6 アドレス範囲を含める前に、使用している AWS のサービス が IPv6 をサポートしていることを確認してください。IPv6 をサポートする AWS のサービス のリストについては、「Amazon VPC ユーザーガイド」の「IPv6 をサポートする AWS のサービス」を参照してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PrincipalPutObjectIfIpAddress",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET3/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "203.0.113.0/24",
                        "2001:DB8:1234:5678::/64"
                    ]
                }
            }
        }
    ]
}

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

aws:SourceVpc

このキーを使用して、リクエストが VPC エンドポイントのアタッチされている VPC を通過するかどうかを確認します。ポリシーでは、このキーを使用して、特定の VPC にのみアクセスを許可できます。詳細については、Amazon Simple Storage Service ユーザーガイドの「特定の VPC へのアクセスの制限」を参照してください。

aws:SourceVpce

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

aws:VpcSourceIp

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

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

リソースのプロパティ

次の条件キーを使用して、リクエストの送信先リソースの詳細を、ポリシーで指定したリソースのプロパティと比較します。

aws:ResourceAccount

このキーを使用して、ポリシーのリソースアカウントと要求されたリソース所有者の AWS アカウント ID を比較します。その後、リソースを所有するアカウントに応じて、そのリソースへのアクセスを許可または拒否することができます。

このキーはリクエストで評価されたリソースを持つアカウントの AWS アカウント ID に相当します。

アカウントのリソースのほとんどで、ARN にそのリソースの所有者アカウント ID が含まれています。Amazon S3 バケットなどの特定のリソースでは、リソース ARN にアカウント ID は含まれていません。次の 2 つの例は、ARN にアカウント ID を持つリソースと、アカウント ID を持たない Amazon S3 ARN の違いを示しています。

AWS コンソールや API、または CLI を使用して、すべてのリソースおよび対応する ARN を検索します。

リソース所有者のアカウント ID に応じて、リソースへのアクセス権を拒否するポリシーを記述します。例えば、リソースが指定されたアカウントに属さない場合に、以下の ID ベースポリシーでは指定されたリソースへのアクセスを拒否します。

このポリシーを使用するには、イタリック体のプレースホルダーテキストをお客様のアカウント情報と置き換えます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInteractionWithResourcesNotInSpecificAccount",
      "Action": "service:*",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:service:region:account:*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceAccount": [
            "account"
          ]
        }
      }
    }
  ]
}

このポリシーでは、特定の AWS アカウント でリソースを所有する場合を除き、特定の AWS サービスのすべてのリソースへのアクセスを拒否します。

AWS Data Exchange などの特定の AWS サービスでは、通常のオペレーションで AWS アカウント の外部のリソースへのアクセスに依存しています。ポリシーに aws:ResourceAccount 要素を使う場合、それらのサービスの免除を指定するために追加のステートメントを含めます。ポリシー AWS: AWS Data Exchange を除くアカウント外の Amazon S3 リソースへのアクセスを拒否する の例では、サービスが所有するリソースの例外を定義しながら、リソースアカウントに応じてアクセスを拒否する方法を示しています。

独自のカスタムポリシーを作成する場合に、このポリシーの例をテンプレートとして使用します。詳細については、サービスのドキュメントを参照してください。

aws:ResourceOrgPaths

このキーを使用してアクセス済みリソースの AWS Organizations パスをポリシー内のパスと比較します。ポリシーでは、この条件キーによって、このリソースが AWS Organizations の指定した組織ルートまたは組織単位 (OU) 内のアカウントメンバーに属していることを保証します。AWS Organizations パスは、Organizations エンティティの構造をテキストで表記したものです。パスの使用と理解の詳細については、「AWS Organizations エンティティパスを理解する」を参照してください。

aws:ResourceOrgPaths は複数の値を持つ条件キーです。複数値のキーは、リクエストコンテキストに複数の値を持つことができます。このキーを使用する場合は、文字列条件演算子とともに ForAnyValue または ForAllValues の集合演算子を使用する必要があります。複数値を持つ条件キーの詳細については、「複数値のコンテキストキー」を参照してください。

例えば次の条件では、その組織 o-a1b2c3d4e5 に属するリソースに True を返します。ワイルドカードを含める場合は、条件演算子 StringLike を使用する必要があります。

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

次の条件では、OU ID ou-ab12-11111111 を持つリソースには True が返されます。OU ou-ab12-11111111、または子 OU のいずれかにアタッチするアカウントが所有するリソースと一致することになります。

"Condition": { "ForAnyValue:StringLike" : {
     "aws:ResourceOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/*"]
}}

次の条件が OU ID ou-ab12-22222222 に直接アタッチしたアカウントが所有するリソースに True が返されますが、子 OU には返されません。次の例では StringEquals 条件演算子を使用して、ワイルドカード一致ではなく OU ID の完全一致要件を指定します。

"Condition": { "ForAnyValue:StringEquals" : {
     "aws:ResourceOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/"]
}}

AWS Data Exchange などの特定の AWS サービスでは、通常のオペレーションで AWS アカウント の外部のリソースへのアクセスに依存しています。ポリシーに aws:ResourceOrgPaths キーを使う場合、それらのサービスの免除を指定するために追加のステートメントを含めます。ポリシー AWS: AWS Data Exchange を除くアカウント外の Amazon S3 リソースへのアクセスを拒否する の例では、サービスが所有するリソースの例外を定義しながら、リソースアカウントに応じてアクセスを拒否する方法を示しています。類似ポリシーを作成して、サービス所有のリソースを考慮しながら、aws:ResourceOrgPaths キーを使用して組織単位 (OU) 内のリソースへのアクセスを制限できます。

独自のカスタムポリシーを作成する場合に、このポリシーの例をテンプレートとして使用します。詳細については、サービスのドキュメントを参照してください。

aws:ResourceOrgID

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

このグローバルキーは、与えられたリクエストのリソース組織 ID を返します。これにより、ID ベースポリシーの Resource 要素で指定した組織のすべてのリソースに適用されるルールが作成できます。組織 ID は、条件要素で指定できます。アカウントを追加および削除する場合、aws:ResourceOrgID のキーを含むポリシーには正しいアカウントが自動的に組み込まれ、手動で更新する必要はありません。

例えば、以下のポリシーでは、Amazon S3 リソースがリクエストを行うプリンシパルと同じ組織に属している場合を除き、プリンシパルは policy-genius-dev リソースにオブジェクトを追加できません。

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "DenyPutObjectToS3ResourcesOutsideMyOrganization",
    "Effect": "Deny",
    "Action": "s3:PutObject",
    "Resource": "arn:partition:s3:::policy-genius-dev/*",
    "Condition": {
      "StringNotEquals": {
        "aws:ResourceOrgID": "${aws:PrincipalOrgID}"
      }
    }
  }
}

AWS Data Exchange などの特定の AWS サービスでは、通常のオペレーションで AWS アカウント の外部のリソースへのアクセスに依存しています。ポリシーに aws:ResourceOrgID キーを使う場合、それらのサービスの免除を指定するために追加のステートメントを含めます。ポリシー AWS: AWS Data Exchange を除くアカウント外の Amazon S3 リソースへのアクセスを拒否する の例では、サービスが所有するリソースの例外を定義しながら、リソースアカウントに応じてアクセスを拒否する方法を示しています。類似ポリシーを作成して、サービス所有のリソースを考慮しながら、aws:ResourceOrgID キーを使用して組織内のリソースへのアクセスを制限できます。

独自のカスタムポリシーを作成する場合に、このポリシーの例をテンプレートとして使用します。詳細については、サービスのドキュメントを参照してください。

次のビデオでは、ポリシーで aws:ResourceOrgID 条件キーを使用する方法について詳しく説明します。

aws:ResourceTag/tag-key

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

このコンテキストキーは "aws:ResourceTag/tag-key":"tag-value" という形式です。ここで tag-key および tag-value はタグキーバリューのペアです。タグのキーと値は大文字と小文字が区別されません。つまり、ポリシーの条件要素で "aws:ResourceTag/TagKey1": "Value1" で指定した場合、その条件は TagKey1 または tagkey1 という名前のリソースタグキーに一致しますが、その両方には一致しません。

aws:ResourceTag キーを使用して IAM リソースへのアクセスを制御する例については、「AWS のリソースへのアクセスの制御」を参照してください。

aws:ResourceTag キーを使用して他の AWS リソースへのアクセスを制御する例については、「タグを使用した AWS リソースへのアクセスの制御」をご参照ください。

属性ベースのアクセス制御 (ABAC) の aws:ResourceTag 条件キーの使用に関するチュートリアルについては、「IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する」をご参照ください。

リクエストのプロパティ

次の条件キーを使用して、リクエスト自体とリクエストの内容の詳細を、ポリシーで指定したリクエストのプロパティと比較します。

aws:CalledVia

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

例えば、AWS CloudFormation を使用して Amazon DynamoDB テーブルからの読み取りと書き込みを行うことができます。次に、DynamoDB は AWS Key Management Service（AWS KMS）によって提供される暗号化を使用します。

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

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

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

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

たとえば、次のポリシーでは、AWS KMS という名前の my-example-key キーを管理できますが、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 への最後の呼び出しは、User 1 を介して AWS CloudFormation、DynamoDBの順に X Service によって実行されます。これは、最初に AWS CloudFormation を介して呼び出され、最後に DynamoDB を介して呼び出されました。

aws:CalledViaFirst

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

aws:CalledViaLast

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

aws:ViaAWSService

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

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

この条件キーを使用して、リクエストがサービスによって行われたかどうかに基づいてアクセスを許可または拒否できます。

aws:CurrentTime

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

aws:EpochTime

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

aws:referer

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

例えば、URL または直接 API 呼び出しを使用して、Amazon S3 オブジェクトに直接アクセスできます。詳細については、「ウェブブラウザを使用して Amazon S3 API オペレーションを直接呼び出す」をご参照ください。ウェブページに存在する URL から Amazon S3 オブジェクトにアクセスすると、ソースウェブページの URL が aws:referer で使用されます。ブラウザに URL を入力して Amazon S3 オブジェクトにアクセスすると、aws:referer は存在しません。API を直接呼び出すと、aws:referer も存在していません。ポリシーで aws:referer 条件キーを使用して、会社のドメイン内のウェブページ上のリンクなど、特定のリファラーからのリクエストを許可できます。

aws:RequestedRegion

このキーを使用して、リクエストで呼び出された AWS リージョンとポリシーで指定したリージョンを比較します。このグローバル条件キーを使用して、リクエストできるリージョンを制御できます。各サービスの AWS リージョンを表示するには、「Amazon Web Services 全般のリファレンス」の「サービスエンドポイントとクォータ」を参照してください。

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

このコンテキストキーを使用して、指定された一連のリージョン内の AWS サービスへのアクセスを制限できます。たとえば、以下のポリシーでは、AWS Management Console でのすべての 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 リクエスト時のアクセスの制御」を参照してください。

このコンテキストキーは "aws:RequestTag/tag-key":"tag-value" という形式です。ここで tag-key および tag-value はタグキーバリューのペアです。タグのキーと値は大文字と小文字が区別されません。つまり、ポリシーの条件要素で "aws:RequestTag/TagKey1": "Value1" で指定した場合、その条件は TagKey1 または tagkey1 という名前のリクエストタグキーに一致しますが、その両方には一致しません。

この例では、キーが単一値であっても、キーが異なる場合でもリクエストで複数のキー/値のペアが使用できることを示しています。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "ec2:CreateTags",
    "Resource": "arn:aws:ec2:::instance/*",
    "Condition": {
      "StringEquals": {
        "aws:RequestTag/environment": [
          "preprod",
          "production"
        ],
        "aws:RequestTag/team": [
          "engineering"
        ]
      }
    }
  }
}

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 を使用するこのシナリオのポリシーを表示するには、「Amazon EC2 ユーザーガイド」のタグ付きのスナップショットの作成に関するページを参照してください。

aws:SecureTransport

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

aws:SourceArn

このキーを使用して、サービス間リクエストを行っているリソースの Amazon リソースネーム (ARN) を、ポリシーで指定した ARN と比較します。ただし、このリクエストが AWS サービスプリンシパルによって実行された場合に限定されます。ソースの ARN にアカウント ID が含まれている場合は、aws:SourceArn で aws:SourceAccount を使用する必要はありません。

このキーは、リクエストを行うプリンシパルの ARN では機能しません。代わりに aws:PrincipalArn を使用してください。

この条件キーを使用して、サービス間のトランザクション中に AWS サービスが混乱した代理として使用されるのを防ぐことができます。このキーは、Principal が AWS のサービス プリンシパルであるリソースベースのポリシーでのみ使用してください。この条件キーの値を、リクエスト内のリソースの ARN に設定します。例えば、Amazon S3 バケットの更新によって Amazon SNS トピックの公開がトリガーされると、Amazon S3 サービスは sns:Publish API 操作を呼び出します。sns:Publish 操作を許可するトピックポリシーで、条件キーの値を Amazon S3 バケットの ARN に設定します。この条件キーが推奨される方法とタイミングについては、使用している AWS サービスのドキュメントを参照してください。

aws:SourceAccount

このキーを使用して、サービス間リクエストを行っているリソースのアカウント ID を、ポリシーで指定したアカウント ID と比較します。ただし、このリクエストが AWS サービスプリンシパルによって実行された場合に限定されます。

この条件キーを使用して、サービス間のトランザクション中に AWS サービスが混乱した代理として使用されるのを防ぐことができます。このキーは、Principal が AWS のサービス プリンシパルであるリソースベースのポリシーでのみ使用してください。この条件キーの値を、リクエスト内のリソースのアカウント ID に設定します。例えば、Amazon S3 バケットの更新によって Amazon SNS トピックの公開がトリガーされると、Amazon S3 サービスは sns:Publish API 操作を呼び出します。sns:Publish 操作を許可するトピックポリシーで、条件キーの値を Amazon S3 バケットのアカウント ID に設定します。この条件キーが推奨される方法とタイミングについては、使用している AWS サービスのドキュメントを参照してください。

aws:SourceOrgPaths

このキーを使用して、サービス間リクエストを行っているリソースの AWS Organizations パスを、ポリシーで指定した組織パスと比較します。ただし、このリクエストが AWS サービスプリンシパルによって実行された場合に限定されます。 Organizations パスは、Organizations エンティティの構造をテキストで表記したものです。パスの使用と理解の詳細については、「AWS Organizations エンティティパスを理解する」を参照してください。

この条件キーを使用して、サービス間のトランザクション中に AWS サービスが混乱した代理として使用されるのを防ぐことができます。このキーは、Principal が AWS のサービス プリンシパルであるリソースベースのポリシーでのみ使用してください。この条件キーの値を、リクエスト内のリソースの組織パスに設定します。例えば、Amazon S3 バケットの更新によって Amazon SNS トピックの公開がトリガーされると、Amazon S3 サービスは sns:Publish API 操作を呼び出します。sns:Publish 操作を許可するトピックポリシーで、条件キーの値を Amazon S3 バケットの組織パスに設定します。この条件キーが推奨される方法とタイミングについては、使用している AWS サービスのドキュメントを参照してください。

aws:SourceOrgPaths は複数の値を持つ条件キーです。複数値のキーは、リクエストコンテキストに複数の値を持つことができます。このキーを使用する場合は、文字列条件演算子とともに ForAnyValue または ForAllValues の集合演算子を使用する必要があります。複数値を持つ条件キーの詳細については、「複数値のコンテキストキー」を参照してください。

aws:SourceOrgID

このキーを使用して、サービス間リクエストを行っているリソースの組織 ID を、ポリシーで指定した組織 ID と比較します。ただし、このリクエストが AWS サービスプリンシパルによって実行された場合に限定されます。AWS Organizations の組織にアカウントを追加する、または組織からアカウントを削除する場合、aws:SourceOrgID のキーを含むポリシーには正しいアカウントが自動的に組み込まれるため、手動で更新する必要はありません。

この条件キーを使用して、サービス間のトランザクション中に AWS サービスが混乱した代理として使用されるのを防ぐことができます。このキーは、Principal が AWS のサービス プリンシパルであるリソースベースのポリシーでのみ使用してください。この条件キーの値を、リクエスト内のリソースの組織 ID に設定します。例えば、Amazon S3 バケットの更新によって Amazon SNS トピックの公開がトリガーされると、Amazon S3 サービスは sns:Publish API 操作を呼び出します。sns:Publish 操作を許可するトピックポリシーで、条件キーの値を Amazon S3 バケットの組織 ID に設定します。この条件キーが推奨される方法とタイミングについては、使用している AWS サービスのドキュメントを参照してください。

aws:UserAgent

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

その他のクロスサービス条件キー

AWS STS は、SAML ベースのフェデレーション条件キーと OIDC フェデレーションのクロスサービス条件キーをサポートします。これらのキーは、SAML を使用してフェデレーションされたユーザーが他のサービスで AWS オペレーションを実行するときに使用できます。