メニュー
AWS Identity and Access Management
ユーザーガイド

IAM JSON ポリシーエレメント: 条件演算子

条件演算子は条件の "動詞" であり、IAM が実行する比較のタイプを指定します。条件演算子は次のカテゴリに分類できます。

文字列条件演算子

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

条件演算子 説明

StringEquals

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

StringNotEquals

符号反転の一致

StringEqualsIgnoreCase

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

StringNotEqualsIgnoreCase

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

StringLike

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

注記

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

StringNotLike

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

たとえば、以下のステートメントに含まれる Condition 要素は、StringEquals 条件演算子を aws:UserAgent キーと共に使用して、リクエストでそのユーザーエージェントヘッダーに特定の値が含まれていなければいけないことを指定しています。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:*AccessKey*", "Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/*", "Condition": {"StringEquals": {"aws:UserAgent": "Example Corp Java Client"}} } }

次の例では、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}/*" ] } ] }

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

数値条件演算子

数値条件演算子では、キーと整数または 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"}} } }

日付条件演算子

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

注記

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

条件演算子 説明

DateEquals

特定の日付との一致

DateNotEquals

符号反転の一致

DateLessThan

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

DateLessThanEquals

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

DateGreaterThan

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

DateGreaterThanEquals

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

たとえば、以下のステートメントに含まれる Condition 要素は、DateLessThan 条件演算子を aws:CurrentTime キーと合わせて使用して、2013 年 6 月 30 日までにリクエストを受信する必要があることを指定しています。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:*AccessKey*", "Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/*", "Condition": {"DateLessThan": {"aws:CurrentTime": "2013-06-30T00:00:00Z"}} } }

ブール条件演算子

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

条件演算子 説明

Bool

ブールの一致

たとえば、以下のステートメントでは、Bool 条件演算子を aws:SecureTransport キーと合わせて使用して、リクエストで SSL を使用しなければいけないことを指定しています。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:*AccessKey*", "Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/*", "Condition": {"Bool": {"aws:SecureTransport": "true"}} } }

バイナリ条件演算子

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

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

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-WITHOUT-HYPHENS:user/*", "Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}} } }

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

次の例では、組織内の有効な 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 は文字列として見なされます。この値は一部のサービスでのみ使用できます。ARN として比較できるリクエスト値をすべてのサービスがサポートするとは限りません。

条件演算子 説明

ArnEqualsArnLike

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

ArnNotEquals, ArnNotLike

ARN の符号反転の一致. これらは同じように動作します。

以下の例は、SNS メッセージの送信先である Amazon SNS キューにアタッチする必要があるポリシーを示しています。この例では、サービスが 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"}} } }

IfExists 条件演算子

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

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.*" で始まる場合にのみアクションが許可されます。チェックされるリソースにこの条件キーがなくても問題ありません。」

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*", "Condition": {"StringLikeIfExists": {"ec2:InstanceType": [ "t1.*", "t2.*", "m3.*" ]}} } }

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

条件キーが承認時に存在するかどうかを確認するには、Null 条件演算子を使用します。このポリシーステートメントでは、true (キーは存在せず、null である) または false (キーは存在し、その値は null でない) のどちらかを使用します。

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

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