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

IAM ポリシーエレメントの参照

このセクションでは、IAM ポリシーで使用できるエレメントについて説明します。エレメントは、ポリシーで使用する一般的な順番で記載されています。エレメントの順番は重要ではありません(たとえば、Resource エレメントを Action エレメントの前にもってくることなどが可能です)。ポリシーで、あらゆる Condition エレメントも特定する必要はありません。

注記

ポリシーに取り入れる詳細は各サービスによって異なり、サービスで利用可能なアクションやリソースの種類などにより異なります。特定のサービスのポリシーを記述している場合、そのサービスに関するポリシーの例を参照することが役に立ちます。IAM をサポートするすべてのサービスが記載されたリストおよびそれらのサービスの IAM とポリシーについて説明しているドキュメントのリンクについては、「IAM と連携する AWS サービス」を参照してください。

バージョン

Version エレメントはポリシー言語のバージョンを指定します。Version エレメントを含める場合は、必ず Statement エレメントの前に表示する必要があります。許可される値は下記のみとなります。

  • 2012-10-17. これはポリシー言語の最新バージョンであり、すべてのポリシーに対してこのバージョン番号を使用する必要があります。

  • 2008-10-17. これはポリシー言語の旧バージョンです。既存のポリシーでは、このバージョンが表示される場合があります。新規ポリシーを作成するときや既存ポリシーを更新するときは、この旧バージョンを使用しないでください。

Versionエレメントを含めない場合、値は既定の2008-10-17となります。しかし、常に Version エレメントを含め、2012-10-17 に設定することを推奨します。

注記

ポリシーにポリシー変数が含まれる場合、必ず Version エレメントを含め、2012-10-17 に設定するようにします。2012-10-17 に設定された Version エレメントを含めないと、${aws:username} といった変数は変数として認識されず、代わりにポリシー内のリテラル文字列として扱われます。

Copy
"Version":"2012-10-17"

ID

Id エレメントは、ポリシーで使用する任意の識別子を特定します。ID の使用方法は、サービスによって異なります。

ID エレメントを設定するサービスの場合、UUID(GUID)を値に使用する、または UUID を唯一性を確認するための ID の一部として統合することを推奨します。

Copy
"Id":"cd3ad3d9-2776-4ef1-a904-4c229d1642ee"

注記

AWS のサービス(たとえば、Amazon SQS や Amazon SNS など)には、このエレメントを要求し、唯一条件を与えるものもあります。ポリシーの記述に関するサービス固有の情報は、お取り扱いのサービス用のドキュメントを参照してください。

Statement

Statement エレメントは、ポリシーの主要エレメントです。このエレメントは必須です。それは、複数のエレメントを含むことができます(このページの次のセクションを参照)。Statement エレメントは、個々のステートメントの配列を含みます。個々のステートメントは括弧 { } で囲まれた JSON 形式のブロックです。

Copy
"Statement":[{...},{...},{...}]

以下の例は、1 つの Statement エレメントの中に 3 つのステートメントの配列を含むポリシーを示しています。(このポリシーにより、Amazon S3 コンソール内の自分の "ホームフォルダー" にアクセスできます)。ポリシーには aws:username 変数が含まれ、変数はポリシーの評価時にリクエストからのユーザー名に置き換えられます。詳細については、「はじめに」を参照してください。

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

ステートメント識別子

Sid(ステートメント ID)は、お客様がポリシードキュメントに与える任意の識別子です。Sid値は、ステートメント配列内の各ステートメントに割り当てることができます。SQS や SNS などの ID エレメントを特定するサービスでは、Sid 値はポリシードキュメント ID の副 ID に過ぎません。IAM では、Sid 値はポリシー内で固有のものでなければいけません。

Copy
"Sid":"1"

IAM では、Sid は IAM API に公開されません。この ID に基づいて、特定のステートメントを復元することはできません。

注記

AWS のサービス(例えば Amazon SQS や Amazon SNS など)には、このエレメントを要求し、唯一条件を与えるものもあります。ポリシーの記述に関するサービス固有の情報は、お取り扱いのサービス用のドキュメントを参照してください。

Effect

Effect エレメントは必須であり、ステートメントの結果を許可または明示的な拒否のどちらにするかを指定します。Effect の有効値は、AllowDeny です。

Copy
"Effect":"Allow"

デフォルト設定では、リソースへのアクセスは拒否されます。リソースへのアクセスを許可するには、Effect エレメントを Allow に設定する必要があります。許可を無効にするには(たとえば、本来有効となる許可を無効にするなど)、Effect エレメントを Deny に設定します。詳細については、「IAM ポリシーの評価論理」を参照してください。

Principal

リソースへのアクセスが許可または拒否されるユーザー(IAM ユーザー、フェデレーションユーザー、または引き受けたロールユーザー)、AWS アカウント、AWS サービス、またはその他のプリンシパルエンティティを指定するには、Principal エレメントを使用します。使用するのは、IAM ロールの信頼ポリシーおよびリソースベースのポリシー、つまりリソースに直接組み込むポリシーに含まれている Principal エレメントです。たとえば、このようなポリシーは、Amazon S3 バケット、Amazon Glacier ボールト、Amazon SNS トピック、Amazon SQS キュー、または AWS KMS カスタマーマスターキー (CMK) に組み込むことができます。

Principal エレメントは次のように使用します。

  • IAM ロールでは、ロールの信頼ポリシー内の Principal エレメントを使用して、だれがこのロールを引き受けることができるかを指定します。クロスアカウントアクセスとして、通常は信頼されたアカウントの ID を指定します。

    注記

    クロスアカウントロールを作成する際は、12 桁のアカウント ID 以外は何も指定できません。ただし、ロールを作成した後で、ポリシーエディターで「*」に変更することはできます。これを行う場合は、アクセスを特定の IP アドレスのみに制限する Condition 要素など、他の方法でロールへのアクセスを制限することを強くお勧めします。誰でもロールにアクセスできる状態のままにしないでください。

  • リソースベースのポリシーでは、Principal エレメントを使用して、リソースへのアクセスが許可されるアカウントまたはユーザーを指定します。

IAM ユーザーおよびグループにアタッチするポリシー内の Principal エレメントは使用しないでください。同様に、IAM ロールのアクセスポリシー内ではプリンシパルを指定しないでください。このような場合、プリンシパルは、暗黙的に、ポリシーがアタッチされたユーザーとなるか(IAM ユーザーの場合)、ロールを引き受けるユーザーとなります(ロールアクセスポリシーの場合)。ポリシーが IAM グループにアタッチされている場合、そのグループ内のリクエスト元 IAM ユーザーがプリンシパルです。

プリンシパルの指定

プリンシパルは、AWS アカウント、IAM ユーザー、IAM ロール、フェデレーションユーザー、または引き受けたロールユーザーの Amazon リソースネーム(ARN)を使用して指定します。IAM グループをプリンシパルとして指定することはできません。AWS アカウントを指定する際には、アカウントの完全な ARN を使用する代わりに、アカウント ID の前に AWS: プレフィックスを付けた短縮形を使用できます。

以下の例は、プリンシパルを指定する際に使用できるいくつかの方法を示しています。

すべてのユーザー(匿名ユーザー)

以下が同等 :

Copy
"Principal": "*"

Copy
"Principal" : { "AWS" : "*" }

注記

これらの例では、アスタリスク (*) はすべてのユーザー/匿名ユーザーのプレースホルダーとして使用されます。これをワイルドカードとして使用して、名前または ARN の一部に一致させることはできません。また、ポリシー内で Condition 要素を使用してアクセスを制限する場合を除き、ロールの信頼ポリシーの Principal 要素にワイルドカードを使用しないことを強くお勧めします。そうしないと、すべてのアカウントの IAM ユーザーがロールにアクセスできてしまいます。

特定の AWS アカウント

ポリシー内のプリンシパルとして AWS アカウント ID を使用する場合、そのアカウントの IAM ユーザーとロールを含めて、そのアカウントに含まれるすべての ID に、ポリシーステートメント内でアクセス許可を付与できます。以下の例は、AWS アカウントをプリンシパルとして指定するさまざまな方法を示しています。

Copy
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:root" }
Copy
"Principal": { "AWS": "AWS-account-ID" }

次の例に示されているように、複数の AWS アカウントをプリンシパルとして指定することができます。

Copy
"Principal": { "AWS": [ "arn:aws:iam::AWS-account-ID:root", "arn:aws:iam::AWS-account-ID:root" ] }

個別の IAM ユーザー

次の例に示されているように、個別の IAM ユーザー(または一連のユーザー)をプリンシパルとして指定することができます。

注記

Principal エレメントでは、ユーザー名の大文字と小文字が区別されます。

Copy
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }
Copy
"Principal": { "AWS": [ "arn:aws:iam::AWS-account-ID:user/user-name-1", "arn:aws:iam::AWS-account-ID:user/UserName2" ] }

Principal エレメント内でユーザーを指定する際に、"すべてのユーザー" の意味でワイルドカード(*)を使用することはできません。プリンシパルには、常に特定のユーザー(または複数の特定ユーザー)を指定する必要があります。

重要

ロールの信頼ポリシーの Principal 要素に、特定の IAM ユーザーを指し示す ARN が含まれている場合、その ARN はポリシーを保存するときにユーザーの一意のプリンシパル ID に変換されます。これにより、ユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ユーザーの ARN への逆変換が行われるためです。ただし、ユーザーを削除すると、関係が壊れます。ユーザーを再作成した場合でも、ポリシーは適用されません。これは、新しいユーザーは信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID を持っているためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が有効な ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの Principal 要素で参照されているユーザーを削除して再作成する場合は、ロールを編集して、正しくなくなったプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、ARN は再びユーザーの新しいプリンシパル ID に変換されます。

フェデレーションユーザー(ウェブ ID フェデレーションを使用)

Copy
"Principal": { "Federated": "cognito-identity.amazonaws.com" }
Copy
"Principal": { "Federated": "www.amazon.com" }
Copy
"Principal": { "Federated": "graph.facebook.com" }
Copy
"Principal": { "Federated": "accounts.google.com" }

フェデレーションユーザー(SAML ID プロバイダーを使用)

Copy
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

IAM ロール

Copy
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

重要

ロールの Principal 要素に、特定の IAM ロールを指し示す ARN が含まれている場合、その ARN はポリシーを保存するときにロールの一意のプリンシパル ID に変換されます。これにより、ロールを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ロールの ARN への逆変換が行われるためです。ただし、ロールを削除すると、関係が壊れます。ロールを再作成した場合でも、ポリシーは適用されません。これは、新しいロールは信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID を持っているためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が有効な ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの Principal 要素で参照されているロールを削除して再作成する場合は、ロールを編集して正しくなくなったプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、ARN は再びロールの新しいプリンシパル ID に変換されます。

特定の引き受けたロールユーザー

Copy
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

AWS サービス

次の例に示されているように、AWS サービスで引き受ける IAM ロールの信頼ポリシーを作成する場合は通常、そのサービスのフレンドリ名を使用してプリンシパルを指定します。

Copy
"Principal": { "Service": [ "ec2.amazonaws.com", "datapipeline.amazonaws.com" ] }

一部の AWS サービスでは、プリンシパルを指定するための追加オプションがサポートされています。たとえば、Amazon S3 では次のような形式で正規ユーザーを使用できます。

Copy
"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }

詳細情報

詳細については、以下を参照してください。

非プリンシパル

NotPrincipal エレメントは、プリンシパルのリストに対して例外を指定する場合に使用します。たとえば、NotPrincipal エレメント内で指定されているプリンシパルを除くすべてのプリンシパルによるアクセスを拒否することもできますNotPrincipal を指定する場合の構文は、Principal を指定する場合と同じです。

NotPrincipal を使用して、NotPrincipal エレメント内で指定されているものを除くすべてのプリンシパルを許可することもできますが、この指定方法はお勧めできません。

警告

"Effect": "Allow" と同じポリシーステートメント内で NotPrincipal を使用すると、指定のプリンシパルを除き、匿名の(承認されていない)ユーザーを含めたすべてのプリンシパルに、このポリシーステートメントで指定されているアクセス許可が付与されます。NotPrincipal は、"Effect": "Allow" と同じポリシーステートメント内で使用しないことを強くお勧めします。

"Effect": "Deny" と同じポリシーステートメント内で NotPrincipal を使用すると、指定のプリンシパルを除くすべてのプリンシパルに、このポリシーステートメントで指定されているアクセス許可が明示的に拒否されます。これにより、一種の "ホワイトリスト" を実装できます。AWS アカウントによるアクセスを明示的に拒否すると、そのアカウントに含まれるすべてのユーザーのアクセスが拒否されます。

リソースベースのポリシーで、AWS アカウントのプリンシパルのみを指定する NotPrincipal エレメントと "Effect": "Deny" を組み合わせて使用すると、そのプリンシパルを含むアカウントに対するアクセスはポリシーによって拒否される可能性があり、その結果、指定したプリンシパルからリソースにアクセスできない場合があります。この状況がどのように発生するかを理解するには、次のセクションの例を参照してください。

注意

NotPrincipal の使用が必要になるシナリオは非常に少ないため、NotPrincipal の使用を決定する前に、他の承認オプションを検討するようお勧めします。

"Effect": "Deny" と同じポリシーステートメント内で NotPrincipal を指定する

NotPrincipal エレメント内にプリンシパルを指定する場合は、Principal エレメント内にプリンシパルを指定する場合と同じ構文を使用します。ただし、特に複数の AWS アカウントを扱っている場合に同じポリシーステートメント内で NotPrincipal"Effect": "Deny" を組み合わせると、意図した効果を得ることが難しい場合があります。

重要

DenyNotPrincipal の結合は、AWS がプリンシパルを評価する順序によって違いが発生する唯一の時間です。AWS は "トップダウン" でプリンシパルを内部的に評価します。つまり、AWS はアカウントを最初に確認してから、ユーザーを確認します。引き受けたロールのユーザー (IAM ユーザーではなくロールを使用しているユーザー) を評価する場合、AWS は最初にアカウント、次にロール、最後にロールを引き受けたユーザーを確認します。ロールを引き受けたユーザーは、ユーザーがロールを引き受けたときに指定されたロールセッション名で識別されます。

通常、この順序によってポリシーの評価結果に影響はありません。ただし、Deny および NotPrincipal の両方とも使用する場合、評価順序では指定されたプリンシパルに関連付けられたエンティティの ARN を含めるよう明示的に要求されます。たとえば、ユーザーを指定するには、ユーザーのアカウントの ARN を明示的に含める必要があります。ロールを引き受けたユーザーを指定するには、ロールの ARN と、ロールを含むアカウントの ARN の両方を含める必要があります。

以下の例では、同じポリシーステートメント内で NotPrincipal"Effect": "Deny" を効果的に使用する方法を示しています。

例 1: 同じまたは異なるアカウントの IAM ユーザー

次の例では、444455556666 という AWS アカウントに含まれる Bob という名前のユーザーを除いて、すべてのプリンシパルによるリソースへのアクセスが明示的に拒否されています。意図した効果を得るために、NotPrincipal エレメントには、Bob というユーザーと、Bob が属する AWS アカウント(arn:aws:iam::444455556666:root)の ARN が両方含まれています。NotPrincipal エレメントに含まれているのが Bob の ARN のみであれば、このポリシーの結果として、ユーザー Bob を含む AWS アカウントに対するアクセスはを明示的に拒否されることになります。ユーザーは、親アカウントを超えるアクセス許可を得ることができないため、Bob のアカウントが明示的にアクセスを拒否されると、Bob もリソースにアクセスできません。

この例は、同じまたは異なる AWS アカウント (444455556666 ではなく) のリソースにアタッチされているリソースベースのポリシー内でポリシーステートメントに含まれている場合、意図したとおりに動作します。この例自体は Bob にアクセス許可を付与しておらず、明示的に拒否するプリンシパルのリストから Bob を除外しているだけです。リソースへのアクセス許可を Bob に付与するには、別のポリシーステートメントで "Effect": "Allow" を使用して明示的にアクセスを許可する必要があります。

Copy
"Effect": "Deny", "NotPrincipal": { "AWS": [ "arn:aws:iam::444455556666:user/Bob", "arn:aws:iam::444455556666:root" ] }

例 2: 同じまたは異なるアカウントの IAM ロール

次の例では、444455556666 という AWS アカウントに含まれる cross-account-audit-app という名前の引き受けたロールユーザーを除いて、すべてのプリンシパルによるリソースへのアクセスが明示的に拒否されています。意図した効果を得るために、NotPrincipal エレメントには、引き受けたロールユーザー(cross-account-audit-app)、ロール(cross-account-read-only-role)、ロールが属する AWS アカウント(444455556666)の ARN が含まれています。ロールの ARN が NotPrincipal エレメントに含まれていなければ、このポリシーの効果としては、このロールに対して、アクセスを明示的に拒否することになります。同様に、ロールが属する AWS アカウントの ARN が NotPrincipal エレメントに含まれていなければ、このポリシーの結果として、AWS アカウントとそのアカウントに属するすべてのエンティティに対するアクセスは明示的に拒否されることになります。引き受けたロールユーザーは、親ロールを超えるアクセス許可を得ることができず、ロールは、親である AWS アカウントを超えるアクセス許可を得ることができないため、ロールまたはアカウントが明示的にアクセスを拒否された場合、引き受けたロールユーザーはリソースにアクセスできません。

この例は、444455556666 ではなく別の AWS アカウントのリソースにアタッチされているリソースベースのポリシー内でポリシーステートメントに含まれている場合、意図したとおりに動作します。この例自体は引き受けたロールユーザー(cross-account-audit-app)にアクセス許可を付与しておらず、明示的に拒否するプリンシパルのリストから cross-account-audit-app を除外しているだけです。リソースへのアクセス許可を cross-account-audit-app に付与するには、別のポリシーステートメントで "Effect": "Allow" を使用して明示的にアクセスを許可する必要があります。

Copy
"Effect": "Deny", "NotPrincipal": { "AWS": [ "arn:aws:sts::444455556666:assumed-role/cross-account-read-only-role/cross-account-audit-app", "arn:aws:iam::444455556666:role/cross-account-read-only-role", "arn:aws:iam::444455556666:root" ] }

アクション

Action エレメントは、許可または拒否される特定のアクションについて説明します。ステートメントには、Action または NotAction エレメントを含める必要があります。各 AWS 製品には、そのサービスで行うことができるタスクを記述する独自のアクションセットがあります。たとえば、Amazon S3 のアクションの一覧は、『Amazon Simple Storage Service 開発者ガイド』の「ポリシーでのアクセス許可の指定」に記載されていて、Amazon EC2 のアクションの一覧は『Amazon EC2 API Reference』に記載されています。また、AWS Identity and Access Management のアクションの一覧は『IAM API リファレンス』に記載されています。他のサービスのアクションのリストについては、そのサービスの API リファレンスドキュメントを参照してください。

値は、サービス(iamec2 sqssnss3 など)を識別する名前空間に、許可または拒否するアクションの名前を付けて特定します。この名前は、サービスでサポートされているアクションと一致しなければいけません。プレフィックスとアクション名には、大文字と小文字の区別がありません。たとえば、iam:ListAccessKeysIAM:listaccesskeys と同じです。下記の例は、様々サービスに対するActionエレメントの例を示します。

Amazon SQS アクション

Copy
"Action":"sqs:SendMessage"

Amazon EC2 アクション

Copy
"Action":"ec2:StartInstances"

IAM アクション

Copy
"Action":"iam:ChangePassword"

Amazon S3 アクション

Copy
"Action":"s3:GetObject"

Actionエレメントには複数の値を指定することができます。

Copy
"Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ]

特定の AWS 製品が提供するすべてのアクションへのアクセスを許可するには、ワイルドカード(*)を使用することができます。たとえば、以下の Action エレメントはすべての S3 アクションに適用します。

Copy
"Action": "s3:*"

また、アクション名の一部にワイルドカード(*)を使用できます。たとえば、以下の Action エレメントは、CreateAccessKeyDeleteAccessKeyListAccessKeysUpdateAccessKey などの文字列 AccessKey を含むすべての IAM アクションに適用されます。

Copy
"Action": "iam:*AccessKey*"

サービスの中には、使用可能なアクションに制限があるものがあります。たとえば、Amazon SQS では、使用可能なすべての Amazon SQS アクションのサブセットだけを使用することができます。この場合、* ワイルドカードはキューの完全なコントロールを許可せず、共有しているアクションのサブセットだけが許可されます。詳細については、Amazon Simple Queue Service 開発者ガイド の「Understanding Permissions」を参照してください。

NotAction

NotAction エレメントで、アクションリストに例外を特定することができます。たとえば、NotActionを使用すれば、ユーザーに実行を許可しないすべてのアクションをリストしなくても、Amazon SQS SendMessage アクションのみを使用するよう制限できます。NotActionを使用すると、Actionエレメントを使用したり多数のアクションをリストするよりもポリシーが短くなる場合があります。

以下の例は、Amazon SQS SendMessage 以外の他のすべてのアクションを示しています。このポリシーは "Effect":"Deny" を指定して使用し、SendMessage を除く他のアクションにユーザーがアクセスしないようにすることができます。ただし、これによりいずれのアクションへのユーザーアクセス許可も付与されません。SendMessage を除く他のすべてのアクションを明示的に拒否するのみです。

Copy
"NotAction": "sqs:SendMessage"

以下の例は、Publish 以外のあらゆるアクションに適合します。

Copy
"NotAction": "sns:Publish"

次の例は、Amazon S3 の GetObject を除くすべてのアクションを参照する場合を示しています。

Copy
"NotAction": "s3:GetObject"

Amazon S3 バケットへのアクセスを制御するポリシー内で NotAction エレメントを使用する方法については、Amazon Simple Storage Service 開発者ガイド の「Example Policies for Amazon S3」を参照してください。

リソース

Resource エレメントは、ステートメントで取り扱う一連のオブジェクトを指定します。ステートメントには、Resource または NotResource エレメントを含める必要があります。ARN を使用して、リソースを特定します。ARN のフォーマットの詳細については、「Amazon リソースネーム(ARN)と AWS サービスの名前空間」を参照してください。

各サービスには、それぞれ一連のリソースがあります。リソースを特定するためには必ず ARN を使用しますが、それぞれのリソースの ARN の詳細は、そのサービスおよびリソースによって異なります。リソースの指定方法についての情報は、お客様が記述しているステートメントを適用するリソースのサービスに関するドキュメントを参照してください。

注記

一部のサービスでは、個々のリソースに対してアクションを指定することができず、代わりにActionまたはNotActionエレメントでリストしたアクションがサービス内のすべてのリソースに適用されます。その場合、Resourceエレメント内でワイルドカード(*)を使用してください。

以下の例は、特定の Amazon SQS キューを示しています。

Copy
"Resource": "arn:aws:sqs:us-west-2:account-ID-without-hyphens:queue1"

以下の例は、AWS アカウント内のボブという名の IAM ユーザーを示しています。

Copy
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/Bob"

リソース ARN の一部にワイルドカードを使用することができます。ワイルドカード文字 (* と ?) を、任意の ARN セグメント (コロンで区切られている部分) 内で使用できます。アスタリスク (*) は文字の任意の組み合わせを、疑問符 (?) は任意の 1 文字を表します。各セグメント内で複数の * や ? を使用できますが、ワイルドカードはセグメントをまたぐことはできません。以下の例は、/accounting というパスを持つすべての IAM ユーザーを示しています。

Copy
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/accounting/*"

以下の例は、特定の Amazon S3 バケット内のすべての項目を示しています。

Copy
"Resource": "arn:aws:s3:::my_corporate_bucket/*"

複数のリソースを特定することができます。以下の例は、2 つの DynamoDB テーブルを示しています。

Copy
"Resource": [ "arn:aws:dynamodb:us-west-2:account-ID-without-hyphens:table/books_table", "arn:aws:dynamodb:us-west-2:account-ID-without-hyphens:table/magazines_table" ]

Resource エレメントでは、特定のリソースを示す ARN の一部(すなわち、ARN の末尾部分)でポリシー変数を使用できます。たとえば、リソース ARN の一部としてキー {aws:username} を使用することで、現在のユーザー名をリソースの名前の一部として含める必要があることを示すことができます。以下の例は、Resource エレメント内での {aws:username} キーの使用方法を示します。ポリシーは、現在のユーザー名に一致する Amazon DynamoDB テーブルへのアクセスを許可します。

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-2:ACCOUNT-ID-WITHOUT-HYPHENS:table/${aws:username}" } }

ポリシー変数の詳細については、「IAM ポリシー変数の概要」を参照してください。

非リソース

NotResourceエレメントは、ポリシーを適用しないリソースのみを指定できるようにすることで、一部を除くすべてのリソースへのアクセスを許可したり、または拒否したりすることが可能です。

たとえば、Developersという名前のグループがあるとしましょう。Developersのメンバーは、mybucket バケット内の CompanySecretInfo フォルダ以外のすべての Amazon S3 リソースにアクセスする必要があります。以下の例は、これらの権限を確立するためのポリシーがどのようなものかを示します。

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:*", "NotResource": [ "arn:aws:s3:::mybucket/CompanySecretInfo", "arn:aws:s3:::mybucket/CompanySecretInfo/*" ] } }

通常、Developers グループがアクセス許可を持つ各フォルダを個々にリストした Resources エレメントを含む "Effect":"Allow" を使用してポリシーを書き込みます。しかしその場合、ユーザーがアクセス許可を持つ mybucket にフォルダを追加するたびに、その名前を Resource のリストに追加する必要があります。代わりに NotResource エレメントを使用すると、ユーザーはフォルダ名を NotResource エレメントに追加しなくても、新しいフォルダに自動的にアクセスできます。

条件

Condition エレメント(またはCondition block)は、ポリシーを実行するタイミングの条件を指定することができます。Conditionエレメントはオプションです。Condition 要素には、ブール条件演算子 (等しい、未満など) を使用してポリシー内の条件をリクエスト内の値に対して一致させる式を組み込みます。条件値には、日付、時間、リクエスタの IP アドレス、リクエストソースの ARN、ユーザー名、ユーザー ID、およびリクエスタのユーザーエージェントを含めることができます。一部のサービスでは、条件に追加的な値を指定できます。たとえば、Amazon S3 では s3:VersionId キーを使用してそのサービス固有の条件を書き込むことができます。(Amazon S3 のポリシーへの条件書き込みに関する詳細については、Amazon Simple Storage Service 開発者ガイド の「Using IAM Policies」を参照してください。)

条件ブロック

以下の例は、Conditionエレメントの基本フォーマットを示します。

Copy
"Condition": { "DateGreaterThan" : { "aws:CurrentTime" : "2013-12-15T12:00:00Z" } }

リクエストからの値は、キーによって表現されます。この場合は aws:CurrentTime です。キー値は、後で説明するとおり、リテラル値(2013-08-16T12:00:00Z)またはポリシー変数として指定した値と比較されます。比較の種類は、条件演算子によって指定されます (ここでは DateGreaterThan)。等号、大なり記号、小なり記号といった一般的なブール演算子を使用して、文字列、日付、数値などを比較する条件を作成できます。

一部の環境では、キーに複数の値が含まれる可能性があります。たとえば、DynamoDB へのリクエストによって、テーブルの複数の属性を返すまたは更新することが要求される場合があります。DynamoDB テーブルへのアクセス用のポリシーには、リクエストに含まれるすべての属性を含む dynamodb:Attributes キーが含まれる可能性があります。Condition 要素で設定演算子を使用することで、リクエスト内のすべての属性を、ポリシー内の許可された属性のリストと照合できます。詳細については、「複数のキー値をテストする条件を作成する(オペレーションの設定)」を参照してください。

リクエスト中にポリシーが評価される際、AWS はキーをリクエストからの対応する値に置き換えます。(この例では、AWS はリクエストの日時を使用します。)条件が評価された上で「true(真)」または「false(偽)」が返され、それを考慮に入れてポリシー全体がリクエストを許可または拒否します。

条件内の複数の値

Condition エレメントは複数の条件を含むことができ、各条件は複数のキー値ペアを含むことができます。以下の図が解説したものです。他に特定のない限り、すべてのキーには複数の値を含むことができます。

数値 foo が A または B と等しく、かつもう 1 つの数値 bar が C と等しいときに限り、リソースをジョンに使用させるとします。このような場合、次の図のような Condition ブロックを作成します。

2 つの NumericEquals 条件を含む条件ブロック

加えて、ジョンのアクセスを 2009 年 1 月 1 日以降に制限する場合を考えます。2009 年 1 月 1 日を含めた日付と共に、他の条件、DateGreaterThan、を追加することになります。このような条件が付いたブロックは、以下の図のようになります。

条件を超える日付を含む条件ブロック

複数の条件演算子がある場合、または 1 つの条件演算子に複数のキーがアタッチされている場合、条件は論理 AND を使用して評価されます。1 つの条件演算子に 1 つのキーのための複数の値が含まれる場合、条件演算子は論理 OR を使用して評価されます。許可または明示的な拒否の決定を返すためには、すべての条件演算子に一致する必要があります。いずれかの条件演算子が一致しない場合、結果は拒否となります。

AND および OR がどのように複数の値に適用されるかを示した条件ブロック

前述のように、AWS には所定の条件演算子およびキー (aws:CurrentTime など) があります。各 AWS のサービスもまた、サービス固有のキーを定義します。

たとえば、以下の条件でユーザーのジョンに Amazon SQS キューへのアクセスを許可するとします。

  • 日時は 2013/8/16 の正午を過ぎたところです。

  • 日時は 2013/8/16 の午後 3 時前です。

  • リクエスト(IAM または SQS)またはメッセージ(SNS)が、IP アドレスの 192.0.2.0 から 192.0.2.255 の範囲または 203.0.113.0 から 203.0.113.255 の範囲で入ってきます。

お客様の条件ブロックには 3 つの個別の条件演算子があり、ジョンはお客様のキュー、トピック、またはリソースにアクセスするためには、それら 3 つすべての条件演算子に一致しなければいけません。

お客様のポリシーにおいて、条件ブロックは以下のようなものになります。aws:SourceIp の 2 つの値は、OR を使用して評価されます。個別の 3 つの条件演算子が、AND を使用して、評価されます。

Copy
"Condition" : { "DateGreaterThan" : { "aws:CurrentTime" : "2013-08-16T12:00:00Z" }, "DateLessThan": { "aws:CurrentTime" : "2013-08-16T15:00:00Z" }, "IpAddress" : { "aws:SourceIp" : ["192.0.2.0/24", "203.0.113.0/24"] } }

最終的に、ある特定の条件では、ポリシー内の個々のキーに複数の値が含まれる可能性があります。条件設定演算子を使用して、これらの複数値のキーを、ポリシーに含まれる 1 つ以上の値と照合できます。詳細については、「複数のキー値をテストする条件を作成する(オペレーションの設定)」を参照してください。

条件に利用可能なキー

条件要素内の条件キーは、ユーザーによって送信されたリクエストの一部である値を示します。AWS では、AWS をサポートするすべての IAM サービス用に、以下に示すアクセス制御用の所定の条件キーが提供されています。

  • aws:CurrentTime – 現在の日付と時間が日付/時刻条件を確認します (日付条件演算子 をご覧ください)。

  • aws:EpochTime – epoch または UNIX の現在の日付と時間が日付/時刻条件を確認します (日付条件演算子 をご覧ください)。

  • aws:TokenIssueTime – 一時的セキュリティ認証情報が発行された日付/時刻を確認する(「日付条件演算子」を参照)。このキーは一時的セキュリティ認証情報を使用してサインインをしようとするリクエストにのみ存在します。一時的セキュリティ認証情報の詳細については、「一時的セキュリティ認証情報」を参照してください。

  • aws:MultiFactorAuthPresent – 現在のリクエストで一時的なセキュリティ認証情報を検証するために多要素認証 (MFA) を使用したか確認する (ブール条件演算子 をご覧ください)。ユーザーが API を呼び出す場合に一時的な認証情報を使用した場合に限り、リクエストコンテキストでこのキーが表示されます。こうした認証情報は sts:GetSessionToken からの認証情報を持つ IAM ロール、フェデレーティッドユーザー、IAM ユーザーや AWS マネジメントコンソール のユーザーが使用します。(ユーザーの代理としてバックグラウンドで生成したコンソールは一時的な認証情報を使用します。)aws:MultiFactorAuthPresent キーは、API または CLI コマンドが標準のアクセスキーペアなど長期的な認証情報で呼び出された場合には表示されません。したがって、このキーを確認する場合は ...IfExists バージョンの条件演算子の使用をお勧めします。

    次の Condition 要素は MFA の使用を確認する信頼性の高い方法ではない点にご注意ください。

    Copy
    "Sid": "THISPOLICYDOESNOTWORK", "Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : false } }

    長期的な認証情報を使用する場合、aws:MultiFactorAuthPresent キーはリクエスト内に存在せず、テストは常に失敗して不一致となるためです。代わりに BoolIfExists 演算子を使用して値を確認することをお勧めします。例::

    Copy
    "Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : false } }

    この演算子は値が存在し「false」の場合または値が存在しない場合でも、ステートメントがそのいずれかに一致することを示しています。...IfExists はリクエストのコンテキスト内にキーが存在しなくても、マッチングしないことはないので特に問題はないと述べています。

    MFA キーが存在するか確認する場合、次のように作成されたポリシーは使用しないでください。

    Copy
    "Sid": "THISPOLICYDOESNOTWORK", "Action" : "Deny", "Condition" : { "Null" : { "aws:MultiFactorAuthPresent" : true } }

    MFA を使用していない場合は過去の例のアクセス拒否を想定するかもしれません。長期的な認証情報 (アクセスキー) で API リクエストを作成すると、MFA 条件コンテキストキーが常に 見つからなくなります。そのため、この方法で MFA をテストすると常に長期的な認証情報へのアクセス拒否といった結果になります。

  • aws:MultiFactorAuthAge – リクエストを送信した MFA 認証済みのセキュリティ認証情報がどれぐらい前(秒)に発行されたのかを多要素認証(MFA)を使用して確認する。MFA を使用していなかった場合、このキーは存在しません (Numeric comparison operatorsAWS での多要素認証 (MFA) の使用 をご覧ください)。そのため、このキーでも ...IfExists バージョンの比較演算子を使用することをご検討ください。そうすることで、リクエストコンテキストにキーが存在しない場合でも、比較結果は予想通りになります。

  • aws:PrincipalType – 現在のリクエストに対するプリンシパルのタイプ(ユーザー、アカウント、フェデレーション ユーザーなど)を確認する(文字列条件演算子を参照してください)。

  • aws:Referer – だれがクライアントブラウザーでリクエスト送信先のアドレスを参照したかを確認する。ウェブブラウザーで直接アドレスを参照できる一部のサービス(Amazon S3 など)でのみサポートされています。値は AWS への HTTPS リクエスト内の Referer ヘッダーから取得されます。

    注意

    このキーは慎重に使用する必要があります。aws:referer を使用することで、Amazon S3 バケットの所有者は、その内容が不正なサードパーティサイトから標準的なウェブブラウザーに渡されないようにできます(詳細については上記のリンクを参照)。しかし、aws:referer 値は HTTP ヘッダー内の呼び出し元によって渡されるため、不正な当事者が改造またはカスタムブラウザーを使用して任意の aws:referer 値を渡すことができます。そのため aws:referer は、不正な当事者から AWS にリクエストが直接行われることを防止するために使用しないでください。このキーは、Amazon S3 に保存されているデジタルコンテンツが不正なサードパーティサイトで参照されることから保護するためにのみ、お客様に提供されています。

  • aws:SecureTransport – リクエストが SSL を使用して送信されたかどうかを確認する(「ブール条件演算子」を参照)。

  • aws:SourceArn – ソースの Amazon リソースネーム(ARN)を使用して、リクエストのソースを確認します。(この値は一部のサービスでのみ利用可能です。)

  • aws:SourceIp – リクエスタの IP アドレスを確認する(「IP アドレス条件演算子」を参照)。

    注記

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

  • aws:SourceVpc – 特定の VPC へのアクセスを制限します。 詳細については、『Amazon Simple Storage Service 開発者ガイド』にある「特定の VPC へのアクセスの制限」を参照してください。 (この値は一部のサービスでのみ利用可能です。)

  • aws:SourceVpce – 特定の VPC エンドポイントへのアクセスを制限する 詳細については、『Amazon Simple Storage Service 開発者ガイド』の「特定の VPC エンドポイントへのアクセスの制限」を参照してください。

  • aws:UserAgent – リクエスタのクライアントアプリケーションを確認する。 詳細については、「文字列条件演算子」を参照してください。

  • aws:userid – リクエスタのユーザー ID を確認する。 詳細については、「文字列条件演算子」を参照してください。

  • aws:username – リクエスタのユーザー名を確認する。 詳細については、「文字列条件演算子」を参照してください。

一部の AWS サービスは、サービス固有のキーも提供します。Amazon S3 リソース用ポリシーで使用できるキーについては、Amazon Simple Storage Service 開発者ガイド の「Amazon S3 Policy Keys」を参照してください。IAM リソースのポリシーで使用できるキーについては、次のセクションを参照してください。その他のサービスのポリシーで使用できるキーについては、個々のサービスに関するドキュメントを参照してください。

注記

場合によって利用可能な条件キーを使用している場合 (aws:SourceIp や aws:SourceVpc など) は必ず IfExists バージョンの比較演算子を使用してください。これは、コンテキストキーが常に存在するとは限らないためです。コンテキストキーがない (なおかつ IfExists を設定していない) 場合、ポリシーエンジンは評価に失敗する可能性があります。たとえば、特定の IP 範囲または特定の VPC からのアクセスを制限するポリシーを記述する場合、次のように条件を作成する必要があります。

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

この条件は (1) aws:SourceIp コンテキストキーの値 xxx があるまたは (2) aws:SourceVpc コンテキストキーに値 yyy がある場合のいずれかに該当します。

IAM に利用可能なキー

IAM リソースへのアクセスを制御するポリシーで以下の条件キーを使用できます。

ウェブ ID フェデレーションで利用可能なキー

Login with Amazon、Amazon Cognito、Google、Facebook などの ID プロバイダー(IdP)を使用して認証されたユーザーに、ウェブ ID フェデレーションを使用して一時的なセキュリティ認証情報を提供する場合、その一時的なセキュリティ認証情報を使用してリクエストを実行するときに追加の条件キーを使用できます。これらのキーを使用して、フェデレーションユーザーが特定のプロバイダー、アプリケーション、またはユーザーに関連付けられたリソースにのみアクセスできるようにするポリシーを作成できます。

フェデレーションプロバイダ

aws:FederatedProvider キーは、ユーザーの認証にどの IdP が使用されたかを示します。たとえば、ユーザーが Amazon Cognito を使用して認証された場合、キーには cognito-identity.amazonaws.com が含まれます。同様に、ユーザーが Login with Amazon を使用して認証された場合、キーには www.amazon.com という値が含まれます。リソースポリシーにおいて、キーは以下のように使用されます。この場合 aws:FederatedProvider キーはリソースの ARN においてポリシー変数として使用されます。ポリシーにより、IdP を使用して認証されたすべてのユーザーは、認証時に使用したプロバイダー固有の Amazon S3 バケット内にあるフォルダからオブジェクトを取得できます。

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::BUCKET-NAME/${aws:FederatedProvider}/*" } }

アプリケーション ID およびユーザー ID

さらに、ユーザーに対する一意の ID、ならびにユーザーが認証されるアプリケーションやサイトに対する ID を提供する 2 つのキーを使用できます。これらのキーは、次に示すとおり IdP 固有の名前を持っています。

  • Amazon Cognito ユーザーの場合、キーは cognito-identityamazonaws.com:aud(ID プール ID)と cognito-identity.amazonaws.com:sub(ユーザー ID)です。

  • Amazon ユーザーとしてログインする場合、キーは www.amazon.com:app_idwww.amazon.com:user_id です。

  • Facebook ユーザーの場合、キーは graph.facebook.com:app_idgraph.facebook.com:id です。

  • Google ユーザーの場合、キーは accounts.google.com:aud(アプリケーション ID)と accounts.google.com:sub(ユーザー ID)です。

Amazon Cognito の amr キー

ウェブ ID フェデレーションに Amazon Cognito を使用する場合、信頼ポリシーの cognito-identity.amazonaws.com:amr キー(Authenticated Methods Reference)にユーザーのログイン情報が含まれます。このキーには複数の値が含まれるので、条件セット演算子を使用してポリシーでキーをテストします。キーには、次の値が含まれている可能性があります。

  • ユーザーが認証されていない場合、キーには unauthenticated のみが含まれています。

  • ユーザーが認証されている場合、キーには authenticated という値と、呼び出しで使用されるログインプロバイダーの名前(graph.facebook.comaccounts.google.com、または www.amazon.com)が含まれています。

たとえば、Amazon Cognito ロールの信頼ポリシーの次の条件では、ユーザーが認証されていないかどうかをテストします。

Copy
"Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "us-east-2:identity-pool-id" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "unauthenticated" } }

ウェブ ID フェデレーションの詳細

ウェブ ID フェデレーションの詳細については、以下を参照してください。

SAML ベースのフェデレーションに利用可能なキー

SAML ベースのフェデレーションを使用する場合、追加の条件キーをポリシーに含めることができます。

信頼ポリシー

ロールの信頼ポリシーには、以下のキーを含めることができます。これらのキーは、ロールの引き受け許可を発信者に与えるかどうかを規定するのに役立ちます。saml:doc を除いて、すべての値が SAML アサーションから派生します。以下の一覧内でアスタリスク(*)が付いているアイテムをコンソールの UI で使用して、条件を作成できます。

  • saml:aud(URL)。SAML アサーションの提供先のエンドポイント。このキーの値は、[Audience] フィールドではなくアサーションの [SAML Recipient] フィールドからのものです。

  • saml:cn(リスト)。これは eduOrg 属性です。

  • saml:doc(文字列)。* これは、ロールの引き受けに使用されたプリンシパルを表します。形式は、account-ID/provider-friendly-name です (例: 123456789012/SAMLProviderName)。account-ID 値は、SAML プロバイダを所有するアカウントを参照します。

  • saml:edupersonaffiliation(リスト)。これは eduPerson 属性です。

  • saml:edupersonassurance(リスト)。これは eduPerson 属性です。

  • saml:edupersonentitlement(リスト)。* これは eduPerson 属性です。

  • saml:edupersonnickname(リスト)。これは eduPerson 属性です。

  • saml:edupersonorgdn(文字列)。* これは eduPerson 属性です。

  • saml:edupersonorgunitdn(リスト)。これは eduPerson 属性です。

  • saml:edupersonprimaryaffiliation(文字列)。これは eduPerson 属性です。

  • saml:edupersonprimaryorgunitdn(文字列)。これは eduPerson 属性です。

  • saml:edupersonprincipalname(文字列)。これは eduPerson 属性です。

  • saml:edupersonscopedaffiliation(リスト)。これは eduPerson 属性です。

  • saml:edupersontargetedid(リスト)。これは eduPerson 属性です。

  • saml:eduorghomepageuri(リスト)。これは eduOrg 属性です。

  • saml:eduorgidentityauthnpolicyuri(リスト)。これは eduOrg 属性です。

  • saml:eduorglegalname(リスト)。これは eduOrg 属性です。

  • saml:eduorgsuperioruri(リスト)。これは eduOrg 属性です。

  • saml:eduorgwhitepagesuri(リスト)。これは eduOrg 属性です。

  • saml:namequalifier(文字列)。* Issuer のレスポンス値 (saml:iss)、AWS アカウント ID および IAM の SAML プロバイダーのわかりやすい名前 (ARN の最後の部分) を「/」文字で区切った文字列を連結したハッシュ値。アカウント ID および SAML プロバイダーのわかりやすい名前の連結は saml:doc として、IAM のポリシーで使用できます。詳細については、「SAML ベースのフェデレーションでユーザーを一意に識別する」を参照してください。

  • saml:iss(文字列)。* 発行者。URN で表されます。

  • saml:sub(文字列)。* これはクレームの件名です。組織内の個々のユーザーを一意に識別する値が含まれます(例: _cbb88bf52c2510eabe00c1642d4643f41430fe25e3)。

  • saml:sub_type(文字列)。* このキーは、「persistent」、「transient」、または SAML アサーションで使用されている Subject および NameID エレメントの完全な Format URI とすることができます。「persistent」の値は、セッション間でユーザーの saml:sub 値が同じことを意味します。値が「transient」の場合、ユーザーの saml:sub 値はセッションごとに異なります。NameID エレメントの Format 属性の詳細については、「認証レスポンスの SAML アサーションを設定する」を参照してください。

eduPerson および eduOrg 属性に関する一般的な情報については、Internet2 のウェブサイトを参照してください。eduPerson 属性のリストについては、「eduPerson Object Class Specification (201203)」を参照してください。

リストタイプの条件キーには、複数の値を含めることができます。リスト値のポリシー内で条件を作成するには、設定演算子ForAllValuesForAnyValue)を使用できます。たとえば、所属先が「faculty」、「staff」、または「employee」である(ただし、「student」、「alum」など、他の可能な所属先ではない)すべてのユーザーを許可するには、 次のような条件を使用できます:

Copy
"Condition": { "ForAllValues:StringLike": { "saml:edupersonaffiliation":[ "faculty", "staff", "employee" ] } }

権限 (アクセス) ポリシー

ユーザーが AWS で許可されている操作を定義する SAML フェデレーションのアクセス権限ポリシーには、次のキーを追加することができます。

  • saml:namequalifier。これには、saml:doc 値と saml:iss 値の組み合わせを表すハッシュ値が含まれます。これは名前空間の限定子として使用されます。saml:namequalifiersaml:sub の組み合わせによってユーザーが識別されます。

  • saml:sub。前のリストを参照してください。

  • saml:sub_type。前のリストを参照してください。

これらのキーの使用の詳細については、「SAML 2.0 ベースのフェデレーションについて」を参照してください。

条件演算子

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

文字列条件演算子

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

条件演算子 説明

StringEquals

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

StringNotEquals

符号反転の一致

StringEqualsIgnoreCase

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

StringNotEqualsIgnoreCase

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

StringLike

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

注記

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

StringNotLike

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

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

Copy
{ "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 バケットに対して実行することを許可します。

Copy
{ "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 Cognito を使用してサインインしたユーザーに対し、自分の Amazon S3 フォルダにアクセスすることを許可する」を参照してください。

数値条件演算子

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

条件演算子 説明

NumericEquals

一致

NumericNotEquals

符号反転の一致

NumericLessThan

「未満」の部分一致

NumericLessThanEquals

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

NumericGreaterThan

「上回る」の部分一致

NumericGreaterThanEquals

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

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

Copy
{ "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 日までにリクエストを受信する必要があることを指定しています。

Copy
{ "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 を使用しなければいけないことを指定しています。

Copy
{ "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 エンコードした表現に対してバイト単位で比較します。

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

IP アドレス条件演算子

IP アドレス条件演算子では、キーと IPv4 または IPv6 アドレスまたは IP アドレス範囲の比較に基づいてアクセスを制限する Condition 要素を構築できます。 これらを aws:SourceIp キーと合わせて使用します。値は、標準的な CIDR 形式でなければいけません (例 : 203.0.113.0/24 または 2001:DB8:1234:5678::/64)。 IPv6 では、0s の範囲を表すための :: の使用がサポートされています。

注記

一部の AWS サービスは、まだ IPv6 をサポートしていません。 IPv6 がサポートされるかどうかについては、特定のサービスのドキュメントを参照してください。

条件演算子 説明

IpAddress

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

NotIpAddress

所定の IP アドレスまたは範囲以外のすべての IP アドレス

たとえば、以下のステートメントでは、IpAddress 条件を aws:SourceIp キーと合わせて使用して、リクエストが 203.0.113.0 から 203.0.113.255 までの IP 範囲から送られてこなければいけないことを指定しています。

Copy
{ "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 アドレスに評価されます。<para> 次の例では、組織内の有効な IP アドレスすべてを含めるために、IPv4 と IPv6 アドレスを混在させる方法を示しています。 IPv6 への移行に合わせてポリシーが引き続き機能することを確認するため、すでにある IPv4 の範囲に追加する IPv6 アドレスの範囲の組織のポリシーを補足することをお勧めします。

Copy
{ "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 をユーザーとして直接呼び出す場合に IAM ポリシーでのみ機能します。代わりにサービスを使用してターゲットサービスを呼び出した場合、ターゲットサービスは元のユーザーの IP アドレスではなく呼び出し元サービスの IP アドレスを認識します。これは、AWS CloudFormation を使用して Amazon EC2 を呼び出すことでインスタンスを自動的に作成した場合などに生じることがあります。現在のところ、IAM ポリシーで評価を行うために、発信元サービスを通じて元の IP アドレスをターゲットサービスに渡す方法はありません。これらのタイプのサービス API 呼び出しでは、aws:SourceIp 条件キーを使用しないでください。

Amazon リソースネーム (ARN) の条件演算子

Amazon Resource Name (ARN) 条件演算子では、キーと ARN の比較に基づいてアクセスを制限する Condition 要素を構築できます。ARN は文字列として見なされます。この値は一部のサービスでのみ使用できます。ARN として比較できるリクエスト値をすべてのサービスがサポートするとは限りません。

条件演算子 説明

ArnEquals

ARN の一致

ArnNotEquals

ARN の符号反転の一致

ArnLike

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

ArnNotLike

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

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

Copy
{ "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 など)。「ポリシーキーがリクエストのコンテキストで存在する場合、ポリシーで指定されたとおりにキーを処理します。キーが存在しない場合でも比較に失敗することはないので、これが問題とは考えていません。...IfExists でチェックすると、ステートメント内の別の Condition エレメントは一致なしの結果となることもありますが、キーが見つからないことはありません。

IfExists の使用例

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

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

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

Copy
{ "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 を使うために一時的な認証情報を使用することはできない(キーは存在してはならない)という条件を示しています。

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

サポートされているデータの種類

このセクションでは、IAM ポリシーで値を指定するときにサポートされているデータの種類の一覧を掲載します。ポリシー言語では、各ポリシーエレメントのすべての種類がサポートされているわけではありません。各エレメントの詳細については、前のセクションを参照してください。

  • 文字列

  • 数字(整数および浮動小数点数)

  • ブール

  • Null

  • リスト

  • マップ

  • 構造体(入れ子形式のマップ)

以下の表は、各データの種類をシリアル化してまとめたものです。すべてのポリシーは UTF-8 形式でなければいけないことに注意してください。JSON データに関する情報については、RFC 4627 を参照してください。

タイプ JSON

文字列

文字列

整数

数字

浮動小数点

数字

ブール

true または false

Null

null

日付

ISO 8601 の W3C プロファイルに準拠する文字列

IP アドレス

RFC 4632 に準拠する文字列

リスト

配列

オブジェクト

オブジェクト