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

IAM ポリシーエレメントのリファレンス

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

注記

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

Version

Version ポリシー要素は、 ポリシーバージョンとは異なります。Version ポリシー要素は、ポリシー内で使用され、ポリシー言語のバージョンを定義します。一方で、ポリシーバージョンは、IAM でカスタマー管理ポリシーを変更すると作成されます。変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。Version ポリシー要素の詳細については、「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 の一部として統合することを推奨します。

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

注記

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

Statement

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

"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 値はポリシー内で固有のものでなければいけません。

"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 を使用する場合、そのアカウントに含まれるすべての ID に、ポリシーステートメント内でアクセス許可を付与できます。そのアカウントには、IAM ユーザーおよびロールが含まれます。以下の例は、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 では以下のような形式で正規ユーザーを使用することができます。

"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", "ec2:StartInstances", "iam:ChangePassword", "s3:GetObject" ]

特定の 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 を使うと、一致する予定のアクションのリストを含めるのではなく、一致する必要がないアクションがいくつかリストアップされ、ポリシーが短くなります。NotAction を使用する場合は、この要素に指定されているアクションは制限されているだけの アクションであることに注意してください。これは、Allow 効果を使用する場合、または Deny 効果を使用すると拒否された場合、リストされていないすべてのアクションまたはサービスが許可されることを意味します。

許可の NotAction

NotAction で指定されたアクションを除いて、"Effect": "Allow" のステートメントで NotAction 要素を使用して、AWS サービス内のすべてのアクションへのアクセスできます。NotAction 要素で指定されたアクションを除いて、Resource 要素と共に使用して、1 つ以上のリソースへのアクセスを提供することもできます。

次の例では、バケットの削除以外のすべての Amazon S3 リソースのすべてのアクションにユーザーがアクセスできます。

Copy
"Effect": "Allow", "NotAction": "s3:DeleteBucket", "Resource": "arn:aws:s3:::*",

多数のアクションへアクセスを許可する場合があります。NotAction要素を使用することにより、そのステートメントを効果的に反転させることで、より短いアクションリストを得ることができます。たとえば、多くの AWS サービスがあるため、ユーザーは、アクセス IAM アクション以外のすべてを実行できるポリシーを作成することができます。

次の例では、IAM を除くすべての AWS サービスのすべてのアクションにユーザーはアクセスできます。

Copy
"Effect": "Allow", "NotAction": "iam:*", "Resource": "*"

NotAction 要素と "Effect": "Allow" を同じステートメントで使用したり、ポリシー内の別のステートメントで使用することに注意してください。NotAction は、明示的にリストされていないすべてのサービスおよびアクションと一致し、意図した以上の権限をユーザーに付与する可能性があります。

拒否のNotAction

"Effect": "Deny" のステートメントでNotAction 要素を使用すると、NotAction 要素で指定されているアクションを除いて、リストされたすべてのリソースへのアクセスを拒否できます。この組み合わせでは、リストされた項目は許可されませんが、リストされていないアクションは明示的に拒否されます。許可したいアクションを許可する必要があります。

次の条件付きの例では、ユーザーが MFA の使用にサインインしていない場合、非 IAM アクションへのアクセスを拒否しています。ユーザーが MFA でサインインすると、"Condition" テストはできなく、最終的な "Deny" ステートメントは無効になります。ただし、これにより、ユーザーがアクションにアクセスすることは許可されず、IAM アクション以外のすべてのアクションが明示的に拒否されることに注意してください。

Copy
"Effect": "Deny", "NotAction": "iam:*", "Resource": "*", "Condition":{ "BoolIfExists":{ "aws:MultiFactorAuthPresent": "false"}}

リソース

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

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

注記

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

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

Copy
"Resource": "arn:aws:sqs:us-east-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-east-2:account-ID-without-hyphens:table/books_table", "arn:aws:dynamodb:us-east-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 は、指定されたリソースリスト以外のすべてを明示的に照合する高度なポリシー要素です。NotResource を使うと、一致する予定のリソースのリストを含めるのではなく、一致する必要がないアクションがいくつかリストアップされ、リソースが短くなります。NotResource を使用する場合は、この要素に指定されているリソースは制限されている だけの リソースであることに注意してください。 これは、リストされていない他のすべてのサービスのリソースを含むすべてのリソースが、Allow 効果を使用する場合は許可され、Deny 効果を使用する場合は拒否されることを意味します。ステートメントには、ARN を使用してリソースを指定する ResourceまたはNotResource 要素を含める必要があります。ARN のフォーマットの詳細については、「Amazon リソースネーム(ARN)と AWS サービスの名前空間」を参照してください。

NotResource 要素と "Effect": "Allow" を同じステートメントで使用したり、ポリシー内の別のステートメントで使用することに注意してください。NotResource は、明示的にリストされていないすべてのサービスおよびリソースを可能にし、意図した以上の権限をユーザーに付与する可能性があります。同じステートメントで NotResource 要素と "Effect": "Deny" を使用すると、明示的にリストされていないサービスとリソースが拒否されます。

たとえば、HRPayrollという名前のグループがあるとしましょう。HRPayrollのメンバーは、HRBucket バケット内の Payroll フォルダ以外のすべての Amazon S3 リソースにアクセスできません。次のポリシーは、リストされたリソース以外のすべての Amazon S3 リソースへのアクセスを明示的に拒否します。ただし、このポリシーは、すべてのリソースにユーザーのアクセス権を与えるものではないことに注意してください。

Copy
{ "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "s3:*", "NotResource": [ "arn:aws:s3:::HRBucket/Payroll", "arn:aws:s3:::HRBucket/Payroll/*" ] } }

通常、リソースへのアクセスを明示的に拒否するには、"Effect":"Deny" を使用し、各フォルダを個別にリストするResource 要素を含むポリシーを作成します。ただし、その場合には、HRBucket にフォルダを追加したり、アクセスすべきでない Amazon S3 にリソースを追加するたびに、Resource のリストにその名前を追加する必要があります。代わりに NotResource 要素を使用すると、ユーザーはフォルダ名を NotResource 要素に追加しない限り、新しいフォルダへのアクセスは自動的に拒否されます。

条件

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

グローバルに利用できる条件キーのすべてのリストについては、使用できるグローバル条件キー を参照してください。サービスごとに定義した条件キーは、IAM ポリシーで使用できる AWS サービスアクションと条件コンテキストキー を参照してください。

条件ブロック

以下の例は、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 つ以上の値と照合できます。詳細については、「複数のキー値をテストする条件を作成する(オペレーションの設定)」を参照してください。

条件演算子

条件演算子は条件の "動詞" であり、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 S3: Amazon Cognito ユーザーにバケット内のオブジェクトへのアクセスを許可する」を参照してください。

数値条件演算子

数値条件演算子では、キーと整数または 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 アドレスに評価されます。

次の例では、組織内の有効な 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 として比較できるリクエスト値をすべてのサービスがサポートするとは限りません。

条件演算子 説明

ArnEqualsArnLike

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

ArnNotEquals, ArnNotLike

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

以下の例は、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" は適用されません。

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

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

  • 文字列

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

  • Boolean

  • Null

  • リスト

  • マップ

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

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

タイプ JSON

文字列

文字列

整数

数値

浮動小数点

数値

Boolean

true または false

Null

null

日付

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

IP アドレス

RFC 4632 に準拠する文字列

リスト

配列

オブジェクト

オブジェクト