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

IAM ポリシーの概要

このセクションでは、IAM ポリシーの概要を説明します。ポリシーとは所定の書式に従って、1 つ以上のアクセス許可を記述したドキュメントです。

IAM ポリシーの構文と文法の完全なリファレンスについては、「AWS IAM ポリシーのリファレンス」を参照してください。

はじめに

ユーザやグループ、ロール、リソースにアクセス許可を割り当てるには、ポリシーを作成します。ポリシーはアクセス許可を明示的にリスト化したドキュメントです。基本的に、ポリシーによって以下を指定することができます。

  • Actions: 許可するアクション。各 AWS サービスには、それぞれ独自のアクションがあります。たとえば、ユーザーに対して Amazon S3 ListBucket アクションを使用することを許可できます。これはバケット内のアイテムに関する情報を返します。明示的に許可していないアクションはすべて禁止されます。

  • Resources: アクションの対象として許可するリソース。たとえば、ユーザが ListBucket アクションをどの Amazon S3 バケットに対して実行してよいかを指定します。ユーザは明示的にアクセス許可を与えられていないリソースにはアクセスできません。

  • Effect: ユーザーがアクセスを要求したときにどのような結果となるか(許可または拒否)。デフォルトでは、リソースに対するユーザーからのアクセスは拒否されるので、お客様はユーザーに対してリソースへのアクセスを許可することを明示的に指定する必要があります。

ポリシーとは、JSON を使用して作成されるドキュメントです。ポリシーは 1 つ以上のステートメントで構成され、各ステートメントが 1 セットのアクセス許可を記述します。以下に簡単なポリシーの例を挙げます。

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

このポリシーを IAM ユーザーまたはグループに関連付けることができます。それがユーザーまたはグループにとって唯一のポリシーである場合、ユーザーまたはグループは、その 1 つのアクション(ListBucket)のみを 1 つの Amazon S3 バケット(example_bucket)に対して実行できます。

リソースベースのアクセス権限を指定するには、Amazon SNS トピック、Amazon S3 バケット、または Amazon Glacier ボールトといったリソースにポリシーを関連付けます。その場合、ポリシーには誰がリソースにアクセスできるかについての情報(プリンシパルと呼ばれる)を含める必要があります。(ユーザーベースのポリシーの場合、プリンシパルは、ポリシーが関連付けられている IAM ユーザー、またはグループからポリシーを取得するユーザーとなります)。

以下の例は、Amazon S3 バケットにアタッチされる可能性のあるポリシーを示しています。このポリシーは、mybucket で Amazon S3 アクションを実行できるよう、特定の AWS アカウントにアクセス許可を付与します。このアクションには、バケットおよびバケット内のオブジェクトの使用が含まれます。(このポリシーではアカウントに対してのみ信頼が付与されているため、指定された Amazon S3 アクションを実行するには、アクションへのアクセス許可をアカウント内の個々のユーザーに付与する必要があります。)

Copy
{ "Version": "2012-10-17", "Id": "S3-Account-Permissions", "Statement": [{ "Sid": "1", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*" ] }] }

IAM ポリシーによるアクセスコントロールは、インターフェイスとは関係ありません。たとえば、ユーザーが AWS マネジメントコンソール にアクセスできるように、ユーザーにパスワードを発行することができ、また AWS マネジメントコンソール 内におけるユーザーのアクションをユーザー(またはユーザーの属するグループ)ポリシーでコントロールすることができます。または、AWS への API 呼び出しを実行するための AWS アクセスキーをユーザーに提供し、ライブラリまたはそれらのアクセスキーを認証に使用するクライアントを通してユーザーが呼び出すことができるアクションをポリシーで制御することもできます。

一般的なシナリオをカバーするような基本的なポリシーの例については、「ポリシーの例」、「IAM と連携する AWS サービス」、および AWS ウェブサイトの「AWS サンプルコードとライブラリ」セクションの「AWS ポリシーの例」を参照してください。

AWS 管理ポリシーと Policy Generator は AWS マネジメントコンソール の IAM コンソールから入手できます。コンソールにあるポリシー作成ツールの詳細については、「ポリシーの使用」を参照してください。加えて AWS Policy Generator オンラインを使用すると、コンソールへアクセスしないで AWS 製品向けにポリシーを作成することができます。

重要

確立されたポリシー構文に準拠しないポリシーを保存することはできません。Policy Validator を使用して、無効なポリシーを検出し、修正することができます。1 回のクリックで、既存のポリシーと変更を提案するコピーの両方を表示するエディターに移動できます。変更をそのまま受け入れるか、さらに変更を加えることができます。詳細については、「Policy Validator の使用」を参照してください。

注記

カスタムポリシーを適用すると、IAM はその構文をチェックします。ただし、IAM は特定の要求コンテキスト(複数のポリシーが有効化されている場合もある)に基づいてランタイム時にポリシーを評価するため、カスタムポリシー内のすべてのリソース、アクション、およびアクセス許可の有効性を、ポリシーの適用時にチェックすることはできません。ポリシーの作成に関して支援が必要である場合は、AWS 管理ポリシーまたは Policy Generator を使用することをお勧めします。IAM Policy Simulator を使用した IAM ポリシーの効果のテストについては、「IAMPolicy Simulator を使用した IAM ポリシーのテスト」を参照してください。

複数のステートメントと複数のポリシー

特定のエンティティに複数のポリシーを関連付けることが可能です。1 つのエンティティに複数のアクセス許可を付与する場合、権限ごとに別々のポリシーを用意するか、あるいは 1 つのポリシーにすべての権限を含めることも可能です。

一般的に、ポリシー内の各ステートメントは、1 つの権限についての情報を含んでいます。ポリシーに複数のステートメントが含まれる場合、評価時においてステートメント全体に論理 OR が適用されます。同様に、1 つのリクエストに対して複数のポリシーを適用する場合、評価時においてポリシー全体に論理 OR が適用されます。

ユーザーに複数のポリシーが適用される場合もよくあります(必ずしもポリシーを関連付ける必要はありません)。たとえば、IAM ユーザーである Bob に複数のポリシーが関連付けられており、別のポリシーが彼の所属するグループに関連付けられているとします。その彼がバケットポリシー(リソースベースのポリシー)を持つ Amazon S3 バケットにアクセスする場合、関連するすべてのポリシーが評価され、結果は常に、アクセスが許可されるか拒否されるかのいずれかとなります。評価のロジックの詳細については、「IAM ポリシーの評価論理」を参照してください。

ポリシーの構造

各ポリシーは JSON ドキュメントです。以下の図が示しているように、ポリシーには以下の事項を含みます。

  • 広範な情報を含む任意のポリシー(ドキュメントの最上部に記載)

  • 1 つまたはそれ以上の個別のステートメント

各ステートメントには、1 回限りのアクセス許可についての核になる情報が含まれています。ポリシーが複数のステートメントを含んでいる場合、AWS は評価時にステートメント全体で論理 OR を適用します。複数のポリシーがリクエストに適合する場合、AWS は評価時にポリシー全体で論理 OR を適用します。

一般的なポリシーの構造

ステートメントの情報は、一連のエレメントの中に含まれています。これらのエレメントの詳細については、「IAM ポリシーエレメントのリファレンス」を参照してください。

例 複数のステートメントが含まれるポリシー

ポリシーには複数のステートメントが含まれることがよくあります。この場合、各ステートメントによってさまざまなリソースセットへのアクセス許可が付与されたり、特定の条件下でアクセス許可が付与されたりします。たとえば、次のポリシーには 3 つのステートメントがあり、各ステートメントによって別個のアクセス許可セットが付与されます。ポリシーがアタッチされたユーザーまたはグループが、AWS アカウント 123456789012 に属するものとします。(ポリシーは、他のアカウントのリソースを参照できません)。ステートメントによって、以下が実行されます。

  • 1 つ目のステートメントでは Sid(ステートメント ID)エレメントが FirstStatement に設定されており、ユーザーは自分のパスワードを管理できます。このステートメントの Resource エレメントは「すべてのリソース」を意味する * ですが、実際には、ChangePassword API(または同等の change-password CLI コマンド)はリクエストを行うユーザーのパスワードにのみ影響を与えます。

  • 2 つ目のステートメント("Sid": "SecondStatement")では、ユーザーは AWS アカウントのすべての Amazon S3 バケットを一覧表示できます。このステートメントの Resource エレメントは「すべてのリソース」を意味する "*" ですが、ポリシーでは他のアカウントのリソースへのアクセスが許可されていないため、ユーザーは自分の AWS アカウントのバケットのみ一覧表示できます(このアクセス許可は、ユーザーが AWS マネジメントコンソールからバケットにアクセスする際に必要です)。

  • 3 つ目のステートメント ("Sid": "ThirdStatement") では、ユーザーは confidential-data というバケット内にあるオブジェクトをリストしたり取得することができます。ただし、これはユーザーが多要素認証 (MFA) デバイスで短期的な認証情報を使用して検証した場合に限ります。ポリシーの Condition 要素によって、ユーザーが MFA 認証されているかどうかが確認されます。認証されている場合、ユーザーはバケット内のオブジェクトを一覧表示して取得できます

    ポリシーステートメントに Condition エレメントが含まれている場合、このステートメントは Condition エレメントが true に評価されるときのみ有効になります。この場合、ユーザーが MFA 認証されているときのみ Condition エレメントが true に評価されます。ユーザーが MFA 認証されていない場合、この Condition は false に評価されます。この場合、このポリシーの 3 つ目のステートメントが無効になり、ユーザーは confidential-data バケットにアクセスできません。

Copy
{ "Version": "2012-10-17", "Statement": [ { "Sid": "FirstStatement", "Effect": "Allow", "Action": ["iam:ChangePassword"], "Resource": "*" }, { "Sid": "SecondStatement", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "ThirdStatement", "Effect": "Allow", "Action": [ "s3:List*", "s3:Get*" ], "Resource": [ "arn:aws:s3:::confidential-data", "arn:aws:s3:::confidential-data/*" ], "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}} } ] }