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

アクセス管理の概要: アクセス許可とポリシー

AWS Identity and Access Management (IAM) のアクセス管理部分は、ユーザーまたは他のエンティティがアカウントで行うことが許可されているものを定義するのに役立ちます。これはしばしば承認と呼ばれます。アクセス許可はポリシーを使用して付与されます。ポリシー は、ID またはリソースにアタッチされたときに、そのアクセス権限を定義する AWS のエンティティです。AWS は、ユーザーなどのプリンシパルがリクエストを行ったときに、それらのポリシーを評価します。ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。ポリシーはアイデンティティベースのポリシーとしてプリンシパルにアタッチされるか、リソースベースのポリシーとしてリソースにアタッチされた JSON ドキュメントとして AWS に保存されます。

ポリシーとユーザー

デフォルトでは、IAM ユーザーはお客様のアカウントのいずれのリソースにもアクセスできません。アイデンティティベースのポリシーを作成することで、ユーザーにアクセス権限を付与します。これは、ユーザーにアタッチされるポリシーです。以下の例では、us-east-2 リージョン内のアカウント 123456789012 の Books テーブルで、すべての Amazon DynamoDB アクション (dynamodb:*) を実行するアクセス権限を付与するポリシーを示しています。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books" } }

このポリシーを IAM ユーザーにアタッチすると、そのユーザーは DynamoDB へのそれらのアクセス許可を持つことになります。通常、アカウントのユーザーが、そのユーザーのアクセス許可を表す複数のポリシーを持っています。

明示的に許可されていないアクションやリソースはすべて、デフォルトで拒否されます。たとえば、上述のポリシーがユーザーにアタッチされている唯一のポリシーである場合、そのユーザーは Books テーブルでのみ DynamoDB アクションを実行できます。他のすべてのテーブルでのアクションは禁止されます。同様に、そのユーザーは Amazon EC2、Amazon S3 などの AWS サービスでいずれのアクションも実行できません。これらのサービスで使用するアクセス許可がポリシーに含まれていないためです。

IAM コンソールには、ポリシー内の各サービスに対して許可または拒否されるアクセスレベル、リソース、条件を定義するポリシー概要テーブルが含まれます。ポリシーは、ポリシー概要サービス概要アクション概要の 3 つのテーブルにまとめられています。ポリシー概要テーブルには、サービスのリストが含まれます。そのリストからサービスを選択して、サービス概要を表示します。この概要テーブルには、選択したサービスに対して定義されているアクションとその関連するアクセス権限のリストが含まれます。そのテーブルからアクションを選択して、アクション概要を表示できます。このテーブルには、選択したアクションのリソースと条件のリストが含まれます。

 3 つのテーブルとそれらの関係を示すポリシー概要の図

そのユーザーにアタッチされているすべてのポリシー (管理およびインライン) について、[Users] ページでポリシー概要を表示できます。すべての管理ポリシーについて、[Policies] ページで概要を表示します。

たとえば、前のポリシーは AWS マネジメントコンソール で以下のように要約されます。

DynamoDB のサンプル概要

ポリシーの JSON ドキュメントも表示できます。概要や JSON ドキュメントの表示に関する詳細は、「ポリシーによって付与されるアクセス権限について」を参照してください。

ポリシーとグループ

IAM ユーザーを IAM グループにまとめ、そのグループにポリシーをアタッチできます。その場合、個々のユーザーは、まだ独自の認証情報を持っていますが、そのグループのすべてのユーザーは、グループにアタッチされているアクセス許可を持っています。アクセス許可の管理を簡素化するため、また「IAM のベストプラクティス」に従うために、グループを使用します。

 ユーザーをグループにまとめると、アクセス許可の管理を簡素化できます。ユーザーはグループに割り当てられたアクセス許可を持つようになるためです。

ユーザーまたはグループには、さまざまなアクセス許可を付与する複数のポリシーをアタッチできます。その場合、ユーザーのアクセス許可はポリシーの組み合わせに基づいて評価されます。この場合もやはり、基本的な原則が適用されます。ユーザーにアクションとリソースへの明示的にアクセス許可が付与されていない場合、そのユーザーにはそれらのアクセス許可はありません。

フェデレーションユーザーとロール

フェデレーションユーザーは、IAM ユーザーとは異なり、AWS アカウントに永続的な ID を持っていません。フェデレーションユーザーにアクセス許可を割り当てるには、ロールと呼ばれるエンティティを作成し、ロールのアクセス許可を定義できます。フェデレーションユーザーが AWS にサインインすると、そのユーザーはロールに関連付けられ、ロールで定義されているアクセス許可が付与されます。詳細については、「サードパーティの ID プロバイダー(フェデレーション)用のロールの作成」を参照してください。

アイデンティティベースのポリシーとリソースベースのポリシー

アイデンティティベースのポリシーは、IAM ユーザー、ロール、グループなど、プリンシパル (または ID) にアタッチできるアクセス権限ポリシーです。リソースベースのポリシーは、Amazon S3 バケットなどのリソースにアタッチする JSON ポリシードキュメントです。

アイデンティティベースのポリシーは、ID が実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーはさらに次のように分類できます。

  • 管理ポリシー – AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンのアイデンティティベースポリシーです。次の 2 種類の管理ポリシーを使用できます。

    • AWS 管理ポリシー – AWS が作成および管理する管理ポリシー。ポリシーを初めて利用する場合は、AWS 管理ポリシーから開始することをお勧めします。

    • カスタマー管理ポリシー – AWS アカウントで作成および管理する管理ポリシー。カスタマー管理ポリシーでは、AWS 管理ポリシーに比べて、より正確にポリシーを管理できます。ビジュアルエディタで IAM ポリシーを作成および編集することも、JSON ポリシードキュメントを直接作成することもできます。詳細については、「IAM ポリシーの作成」および「IAM ポリシーの編集」を参照してください。

  • インラインポリシー – 自身で作成および管理するポリシーで、単一のユーザー、グループ、またはロールに直接埋め込まれています

リソースベースのポリシーは、指定されたプリンシパルがそのリソースでどのような条件下でアクションを実行できるかを制御します。リソースベースのポリシーはインラインポリシーであり、管理リソースベースのポリシーはありません。

IAM ID は技術的には AWS リソースですが、IAM IDにリソースベースのポリシーをアタッチすることはできません。IAM でアイデンティティベースのポリシーを使用する必要があります。リソースベースのポリシーをサポートするサービスを確認するには、「IAM と連携する AWS サービス」を参照してください。リソースベースのポリシーの詳細については、「アイデンティティベースおよびリソースベースのポリシー」を参照してください。

信頼ポリシー は、どのプリンシパルがそのロールを果たすことができるかを定義するロールにアタッチされるリソースベースのポリシーです。IAM でロールを作成する場合、ロールには 2 つのものが必要です。最初はロールを担うことができる人物を示す信頼ポリシーです。2 つ目は、そのロールで何ができるかを示すアクセス権限ポリシーです。ロールの信頼ポリシーにアカウントを追加しても、信頼関係は半分しか確立されていない点に注意してください。デフォルトでは、アカウントの管理者がロールを引き受ける権限をユーザーに付与しない限り、信頼されたアカウントのユーザーはロールを引き受けることができません。詳細については、「ロールを切り替えるユーザーアクセス権限の付与」を参照してください。

重要

AWS のドキュメント全体で、上記の特定のカテゴリに言及せずに IAM ポリシーを参照する場合は、アイデンティティベースのカスタマー管理ポリシーを意味します。

ユーザーが AWS でオペレーションを実行しようとすると、IAM はユーザー、そのグループ、または影響を受けるリソースに存在するすべてのポリシーをチェックします。同じオペレーションに適用されるアイデンティティベースのポリシーおよびリソースベースのポリシーがある場合、両方でオペレーションを許可する必要があります。つまり、アイデンティティベースのポリシーは、リソースでのアクションを許可する必要があります。また、リソースベースのポリシーでも呼び出しを行うプリンシパルのアクションが許可されている必要があります。

たとえば、Amazon S3 では、バケットにリソースベースのポリシーをアタッチできます。これはバケットポリシーと呼ばれます。以下の例に示しているのは、AWS アカウント 777788889999 の bob という名前の IAM ユーザーが、ポリシーがアタッチされているバケットにオブジェクトを配置することを許可する、S3 バケットポリシーです。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"}, "Action": [ "s3:PutObject", "s3:PutObjectAcl" ] } }

リソースベースのポリシーには、アクセス許可が付与されているユーザーを指定する Principal エレメントが含まれています。前の例では、Principal 要素が、AWS アカウント 777788889999 の bob という IAM ユーザーの Amazon リソースネーム (ARN) に設定されています。これは、リソース (この場合は S3 バケット) にその IAM ユーザーはアクセスできるが、他のユーザーはアクセスできないことを示します。