IAM JSON ポリシー要素: 条件演算子 - AWS Identity and Access Management
文字列条件演算子数値条件演算子日付条件演算子ブール条件演算子バイナリ条件演算子 IP アドレス条件演算子Amazon リソースネーム (ARN) の条件演算子IfExists 条件演算子条件キーの有無をチェックする条件演算子

IAM JSON ポリシー要素: 条件演算子

Condition 要素で条件演算子を使用して、ポリシーの条件キーバリューをリクエストコンテキストの値と一致させます。Condition 要素の詳細については、「IAM JSON ポリシー要素Condition」を参照してください。

ポリシーで使用できる条件演算子は、選択する条件キーによって異なります。グローバル条件キーまたはサービス固有の条件キーを選択できます。グローバル条件キーに使用できる条件演算子については、「AWS グローバル条件コンテキストキー」を参照してください。サービスのサービス固有の条件キーを表示するには、「AWS サービスのアクション、リソース、および条件キー」を参照し、キーを表示するサービスを選択します。

重要

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致せず条件は false になります。StringNotLike または ArnNotLike などのように、キーの一致を必要としないポリシー条件であり、かつ正しいキーが存在していない場合、条件は true となります。このロジックは、...IfExists および Null check を除くすべての条件演算子に適用されます。これらの演算子は、キーがリクエストコンテキストにある（存在する）かどうかをテストします。

条件演算子は次のカテゴリに分類できます。

文字列条件演算子

文字列条件演算子では、キーと文字列値の比較に基づいてアクセスを制限する Condition 要素を構築できます。

条件演算子 説明

StringEquals

完全一致、大文字と小文字の区別あり。

StringNotEquals

符号反転の一致

StringEqualsIgnoreCase

完全一致、大文字と小文字の区別なし。

StringNotEqualsIgnoreCase

符号反転の一致、大文字と小文字の区別なし。

StringLike

大文字と小文字の区別がある一致。値には、複数文字一致のワイルドカード (*) および 1 文字一致のワイルドカード (?) を文字列のどこにでも含めることができます。文字列の部分一致検索を行うには、ワイルドカードを指定する必要があります。

注記

キーに複数の値が含まれる場合、設定演算子 (StringLike および ForAllValues:StringLike) を使用して ForAnyValue:StringLike を修飾できます。詳細については、「複数値のコンテキストキー」を参照してください。

StringNotLike

符号反転の一致には、大文字と小文字の区別があります。値には、複数文字一致のワイルドカード (*) または 1 文字一致のワイルドカード (?) を文字列のどこにでも含めることができます。

たとえば、次のステートメントに含まれている Condition 要素では、aws:PrincipalTag キーの使用により、リクエストを行うプリンシパルに iamuser-admin ジョブカテゴリのタグ付けが必要であることを指定しています。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:*AccessKey*",
    "Resource": "arn:aws:iam::account-id:user/*",
    "Condition": {"StringEquals": {"aws:PrincipalTag/job-category": "iamuser-admin"}}
  }
}

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。この例では、タグがアタッチされた IAM ユーザーをプリンシパルが使用している場合、aws:PrincipalTag/job-category キーがリクエストコンテキストに存在します。これは、タグまたはセッションタグがアタッチされた IAM ロールを使用するプリンシパルのために含まれます。タグがないユーザーがアクセスキーを表示または編集しようとすると、条件により false が返され、リクエストはこのステートメントによって暗黙的に拒否されます。

次を使用できます。ポリシー変数とString条件演算子を使用します。

以下の例では、StringLike 条件演算子を使用してポリシー変数による文字列一致を実行して、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:::BUCKET-NAME",
      "Condition": {"StringLike": {"s3:prefix": [
        "",
        "home/",
        "home/${aws:username}/"
      ]}}
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::BUCKET-NAME/home/${aws:username}",
        "arn:aws:s3:::BUCKET-NAME/home/${aws:username}/*"
      ]
    }
  ]
}

OIDC フェデレーションによるアプリケーション ID とユーザー ID に基づいてリソースへのアクセスを制限する Condition 要素の使用方法を示すポリシーの例については、「Amazon S3: Amazon Cognito ユーザーにバケット内のオブジェクトへのアクセスを許可する」を参照してください。

ワイルドカードによる一致

文字列条件演算子は、事前に定義された形式を適用しないパターンレスマッチングを実行します。ARN 条件演算子と日付条件演算子は、条件キー値に構造体を適用する文字列演算子のサブセットです。ARN または日付の文字列の部分一致に StringLike または StringNotLike 演算子を使用すると、マッチングではワイルドカードで指定されている構造体の部分が無視されます。

例えば、次の条件では、さまざまな条件演算子を使用して ARN の部分一致を検索します。

ArnLike を使用する場合、ARN のパーティション、サービス、アカウント ID、リソースタイプ、および部分的なリソース ID 部分が、リクエストコンテキストの ARN と完全に一致する必要があります。部分一致が許可されるのは、リージョンとリソースパスのみです。

"Condition": {"ArnLike": {"aws:SourceArn": "arn:aws:cloudtrail:*:111122223333:trail/*"}}

ArnLike の代わりに StringLike を使用すると、マッチングでは ARN 構造が無視され、ワイルドカードで指定された部分に関係なく部分一致が可能になります。

"Condition": {"StringLike": {"aws:SourceArn": "arn:aws:cloudtrail:*:111122223333:trail/*"}}
ARN ArnLike StringLike

arn:aws:cloudtrail:us-west-2:111122223333:trail/finance

一致

一致

arn:aws:cloudtrail:us-east-2:111122223333:trail/finance/archive

一致

一致

arn:aws:cloudtrail:us-east-2:444455556666:user/111122223333:trail/finance

一致なし

一致

数値条件演算子

数値条件演算子では、キーと整数または 10 進値の比較に基づいてアクセスを制限する Condition 要素を構築できます。

条件演算子 説明

NumericEquals

一致

NumericNotEquals

符号反転の一致

NumericLessThan

「未満」の部分一致

NumericLessThanEquals

「未満と等しい」の部分一致

NumericGreaterThan

「上回る」の部分一致

NumericGreaterThanEquals

「上回るまたは等しい」の部分一致

たとえば、以下のステートメントに含まれる Condition 要素は、NumericLessThanEquals 条件演算子を s3:max-keys キーと合わせて使用して、リクエスタが の中で一度に最大example_bucket 10 個のオブジェクトを列挙できることを指定しています。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket",
    "Condition": {"NumericLessThanEquals": {"s3:max-keys": "10"}}
  }
}

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。この例では、ListBucket オペレーションを実行すると、s3:max-keys キーは常にリクエストに存在します。このポリシーですべての Amazon S3 オペレーションが許可されている場合、10 以下の値を持つ max-keys コンテキストキーを含むオペレーションのみが許可されます。

ポリシー変数とNumeric条件演算子を使用することはできません。

日付条件演算子

日付条件演算子では、キーと日付/時刻値の比較に基づいてアクセスを制限する Condition 要素を構築できます。これらの条件演算子は、aws:CurrentTime キーまたは aws:EpochTime キーと合わせて使用します。日付/時間値と共に、W3C implementations of the ISO 8601 date formats またはエポック (UNIX) 時間のどれか 1 つを特定しなければいけません。

注記

ワイルドカードは日付条件演算子では使用できません。

条件演算子 説明

DateEquals

特定の日付との一致

DateNotEquals

符号反転の一致

DateLessThan

特定の日時よりも前の日時との一致

DateLessThanEquals

特定の日時またはそれよりも前の日時との一致

DateGreaterThan

特定の日時よりも後の日時との一致

DateGreaterThanEquals

特定の日時またはそれよりも後の日時との一致

たとえば、次のステートメントには、DateGreaterThan 条件演算子を aws:TokenIssueTime キーとともに使用する Condition 要素が含まれています。この条件は、リクエストの作成に使用された一時的なセキュリティ認証情報が 2020 年に発行されたことを示します。このポリシーは、毎日プログラムによって更新され、アカウントメンバーが最新の資格情報を使用するようにできます。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "iam:*AccessKey*",
    "Resource": "arn:aws:iam::account-id:user/*",
    "Condition": {"DateGreaterThan": {"aws:TokenIssueTime": "2020-01-01T00:00:01Z"}}
  }
}

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。プリンシパルがリクエストを行うために一時的な認証情報を使用する場合に限り、リクエストコンテキストで aws:TokenIssueTime キーが表示されます。このキーは、アクセスキーを使用して行われたAWS CLI、AWS API、または AWS SDK リクエストには存在しません。この例では、IAM ユーザーがアクセスキーを表示または編集しようとすると、リクエストは拒否されます。

Date 条件演算子でポリシー変数を使用することはできません。

ブール条件演算子

ブール条件演算子では、キーと "true (真)" または "false (偽)" の比較に基づいてアクセスを制限する Condition 要素を構築できます。

条件演算子 説明

Bool

ブールの一致

例えば、この ID ベースのポリシーでは aws:SecureTransport キーを持つ Bool 条件演算子が使用されるため、リクエストが SSL 経由でない場合に、オブジェクトとオブジェクトタグを送信先バケットとそのコンテンツに複製することを拒否できます。

重要

このポリシーでは、アクションを許可しません。特定のアクションを許可する他のポリシーと組み合わせてこのポリシーを使用します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BooleanExample",
      "Action": "s3:ReplicateObject",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。aws:SecureTransport リクエストコンテキストは true または false を返します。

次を使用できます。ポリシー変数とBoolean条件演算子を使用します。

バイナリ条件演算子

BinaryEquals 条件演算子では、バイナリ形式のキーバリューをテストする Condition 要素を構築できます。これは、指定されたキーの値を、ポリシー内の値を base-64 エンコードした表現に対してバイト単位で比較します。

"Condition" : {
  "BinaryEquals": {
    "key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
  }
}

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。

条件演算子で Binary ポリシー変数を使用することはできません。

IP アドレス条件演算子

IP アドレス条件演算子では、キーと IPv4 または IPv6 アドレスまたは IP アドレス範囲の比較に基づいてアクセスを制限する Condition 要素を構築できます。これらを aws:SourceIp キーと合わせて使用します。値は、標準的な CIDR 形式でなければいけません (例 : 203.0.113.0/24 または 2001:DB8:1234:5678::/64)。IP アドレスの指定時に関連付けられたルーティングプレフィックスを使用しないと、IAM ではデフォルトのプレフィックス値 /32 を使用します。

IPv6 をサポートしている AWS のサービスでは、0 の範囲を :: で表します。サービスで IPv6 がサポートされているかどうかは、そのサービスのドキュメントを参照してください。

条件演算子 説明

IpAddress

所定の IP アドレスまたは範囲

NotIpAddress

所定の IP アドレスまたは範囲以外のすべての 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::account-id:user/*",
    "Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}
  }
}

aws:SourceIp 条件キーは、リクエストの送信元である IP アドレスに解決します。リクエストが Amazon EC2 インスタンスから発信された場合、aws:SourceIp はインスタンスのパブリックIPアドレスに評価されます。

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。aws:SourceIp キーは、リクエスタが VPC エンドポイントを使用してリクエストを行う場合を除き、リクエストコンテキストに常に表示されます。この場合、条件は false を返し、リクエストはこのステートメントによって暗黙的に拒否されます。

IpAddress 条件演算子でポリシー変数を使用することはできません。

次の例では、組織内の有効な 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 は文字列として見なされます。

条件演算子 説明

ArnEquals, ArnLike

ARN の大文字と小文字を区別した一致。ARN のコロンで分割された 6 個の各構成要素は個別に確認され、それぞれ複数文字一致のワイルドカード (*) または 1 文字一致のワイルドカード (?) を含むことができます。ArnEquals および ArnLike 条件演算子は、同じように動作します。

ArnNotEquals, ArnNotLike

ARN の符号反転の一致。ArnNotEquals および ArnNotLike 条件演算子は、同じように動作します。

次を使用できます。ポリシー変数と ARN 条件演算子を使用します。

次のリソースベースのポリシーの例は、SNS メッセージの送信先となる Amazon SQS キューにアタッチされたポリシーを示しています。この例では、サービスが 1 つまたは複数の特定の Amazon SNS トピックのためにメッセージを送る場合に限り、1 つまたは複数のキューにメッセージを送る Amazon SNS 許可を付与しています。Resource フィールドのキューを指定し、SourceArn キーの値として Amazon SNS トピックを指定します。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "123456789012"},
    "Action": "SQS:SendMessage",
    "Resource": "arn:aws:sqs:REGION:123456789012:QUEUE-ID",
    "Condition": {"ArnEquals": {"aws:SourceArn": "arn:aws:sns:REGION:123456789012:TOPIC-ID"}}
  }
}

ポリシー条件で指定したキーがリクエストコンテキストに存在しない場合、値は一致しません。aws:SourceArn キーは、リソース所有者に代わって別のサービスを呼び出すようにリソースがトリガーした場合にのみ、リクエストコンテキストに表示されます。IAM ユーザーがこのオペレーションを直接実行しようとすると、条件によ false が返され、リクエストはこのステートメントによって暗黙的に拒否されます。

IfExists 条件演算子

Null 条件 (StringLikeIfExists など) を除く任意の条件演算子名の末尾に IfExists を追加できます。「ポリシーキーがリクエストのコンテキストで存在する場合、ポリシーで指定されたとおりにキーを処理します。キーが存在しない場合、条件要素は true と評価されます。」 ...IfExists でチェックすると、ステートメント内の別の Condition 要素は一致なしの結果となることもありますが、キーが見つからないことはありません。StringNotEqualsIfExists のような否定条件演算子を持つ "Effect": "Deny" 要素を使用している場合は、タグがなくても要求が拒否されます。

IfExists の使用例

多くの条件キーは特定のタイプのリソースに関する情報を示し、そのタイプのリソースにアクセスしている場合にのみ存在します。これらの条件キーはその他のタイプのリソースにはありません。ポリシーステートメントが 1 種類のリソースのみに適用される場合には、これで問題はありません。ところが、ポリシーステートメントが複数のサービスからアクションを参照する場合や、サービス内の特定のアクションが同じサービス内の異なるタイプのリソースにアクセスする場合などのように、1 つのステートメントが複数のタイプのリソースに適用される場合があります。このような場合、ポリシーステートメント内の 1 つのリソースのみに適用される条件キーを含めると、ポリシーステートメントの Condition 要素が失敗し、ステートメントの "Effect" は適用されません。

たとえば、次のポリシーの例を考えてみます。

{
  "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. で始まる場合にのみ、アクションを許可します。チェックされるリソースにこの条件キーがなくても問題ありません。」 条件キー値のアスタリスク (*) を StringLikeIfExists 条件演算子と併用すると、ワイルドカードとして解釈され、文字列の一部が一致します。この DescribeActions 文には、コンソールでインスタンスを表示するために必要なアクションが含まれます。

{
    "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": "*"
        }]
}

条件キーの有無をチェックする条件演算子

Null 条件演算子を使用して、認証時に条件キーが存在していないかどうかを確認します。ポリシーステートメントで、true（キーは存在しません-nullです）または false（キーが存在し、その値はnullではありません）を使用します。

Null 条件演算子でポリシー変数を使用することはできません。

たとえば、ユーザーが操作または一時的な認証情報に独自の認証情報を使用しているかどうかを判断するために、この条件演算子を使用することができます。ユーザーが一時的な認証情報を使用している場合、キー aws:TokenIssueTime が存在し、このキーには値があります。以下の例の場合、ユーザーが Amazon EC2 API を使うために一時的な認証情報を使用することはできない (キーは存在してはならない) という条件を示しています。

{
  "Version": "2012-10-17",
  "Statement":{
      "Action":"ec2:*",
      "Effect":"Allow",
      "Resource":"*",
      "Condition":{"Null":{"aws:TokenIssueTime":"true"}}
  }
}