AWS Identity and Access Management
ユーザーガイド

ポリシーとアクセス許可

AWS でのアクセスを管理するには、ポリシーを作成し、IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) または AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、プリンシパルエンティティ (ユーザーまたはロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。通常、ポリシーは JSON ドキュメントとして AWS に保存されます。AWS では、6 つのポリシータイプ (アイデンティティベースのポリシー、リソースベースのポリシー、アクセス許可の境界、組織 SCP、ACL、セッションポリシー) をサポートしています。

IAM ポリシーは、オペレーションの実行方法を問わず、アクションのアクセス許可を定義します。たとえば、GetUser アクションを許可するポリシーを適用されたユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からユーザー情報を取得できます。IAM ユーザーを作成したら、コンソールまたはプログラムによるアクセスを許可するように選択できます。コンソールへのアクセスが許可されている場合、IAM ユーザーは、ユーザー名とパスワードを使用してコンソールにサインインできます。または、プログラムによるアクセスが許可されている場合、ユーザーは、アクセスキーで CLI または API を使用します。

ポリシータイプ

AWS では、以下のポリシータイプ (使用頻度の高い順に表示) を使用できます。詳細については、以下のポリシータイプ別のセクションを参照してください。

  • アイデンティティベースのポリシー – 管理ポリシーとインラインポリシーを IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) にアタッチします。アイデンティティベースのポリシーでは、アクセス許可はアイデンティティに付与されます。

  • リソースベースのポリシー – インラインポリシーをリソースにアタッチします。リソースベースのポリシーとして最も一般的な例は、Amazon S3 バケットポリシーと IAM ロールの信頼ポリシーです。リソースベースのポリシーでは、アクセス許可は、ポリシーで指定されているプリンシパルエンティティに付与されます。プリンシパルは、リソースと同じアカウントか、別のアカウントになります。

  • アクセス許可の境界 – IAM エンティティ (ユーザーまたはロール) のアクセス許可の境界として、管理ポリシーを使用します。このポリシーでは、アイデンティティベースのポリシーでエンティティに付与できるアクセス許可の上限を定義しますが、アクセス許可は付与されません。アクセス許可の境界では、リソースベースのポリシーでエンティティに付与できるアクセス許可の上限は定義されません。

  • 組織 SCP – AWS Organizations サービスコントロールポリシー (SCP) を使用して、組織または組織単位 (OU) のメンバーアカウントのアクセス許可の上限を定義します。SCP では、アイデンティティベースのポリシーまたはリソースベースのポリシーで、アカウント内のエンティティ (ユーザーまたはロール) に付与するアクセス許可が制限されますが、アクセス許可は付与されません。

  • アクセスコントロール (ACL) – ACL を使用して、ACL がアタッチされているリソースにアクセスすることができる他のアカウントのプリンシパルを制御します。ACL は、リソースベースのポリシーと似ていますが、JSON ポリシードキュメント構造を使用しない唯一のポリシータイプです。ACL は、指定されたプリンシパルエンティティにアクセス許可を付与するクロスアカウントのアクセス許可ポリシーです。ACL では、同じアカウント内のエンティティにアクセス許可を付与することはできません。

  • セッションポリシー – AWS CLI または AWS API を使用して、ロールまたはフェデレーティッドユーザーを引き受ける場合に高度なセッションポリシーを渡します。セッションポリシーでは、ロールまたはユーザーのアイデンティティベースのポリシーでセッションに付与するアクセス許可を制限します。セッションポリシーでは、作成したセッションのアクセス許可が制限されますが、アクセス許可は付与されません。詳細については、「セッションポリシー」を参照してください。

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

アイデンティティベースのポリシーは、アイデンティティ (ユーザー、ユーザーのグループ、ロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーでは、エンティティ (ユーザーまたはロール) が実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーはさらに次のように分類できます。

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

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

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

  • インラインポリシー – お客様が作成および管理するポリシーであり、単一のユーザー、グループ、またはロールに直接埋め込まれます。通常、インラインポリシーを使用することは推奨されていません。

管理ポリシーとインラインポリシーを使い分ける方法については、「管理ポリシーとインラインポリシー」を参照してください。

リソースベースのポリシー

リソースベースのポリシーは、Amazon S3 バケットなどのリソースにアタッチする JSON ポリシードキュメントです。これらのポリシーでは、そのリソースに対して特定のアクションを実行するために指定されたプリンシパルのアクセス許可を付与するとともに、このアクセス許可が適用される条件を定義します。リソースベースのポリシーはインラインポリシーです。リソースベースの管理ポリシーはありません。

クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルおよびリソースが別の AWS アカウントである場合は、アイデンティティベースのポリシーを使用して、リソースへのアクセス権をプリンシパルエンティティに付与する必要があります。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、アイデンティティベースのポリシーをさらに付与する必要はありません。

IAM サービスは、ロールの信頼ポリシーと呼ばれるリソースベースのポリシーのタイプを 1 つのみサポートします。これが、IAM ロールにアタッチされています。IAM ロールは、リソースベースのポリシーをサポートするアイデンティティかつリソースであるため、信頼ポリシーとアイデンティティベースのポリシーのいずれも IAM ロールにアタッチする必要があります。信頼ポリシーでは、ロールを引き受けることができるプリンシパルエンティティ (アカウント、ユーザー、ロール、フェデレーティッドユーザー) を定義します。IAM ロールと、他のリソースベースのポリシーとの違いについては、「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

リソースベースのポリシーをサポートするその他のサービスを確認するには、「IAM と連携する AWS のサービス」を参照してください。リソースベースのポリシーの詳細については、「アイデンティティベースおよびリソースベースのポリシー」を参照してください。

IAM アクセス許可の境界

アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界を設定した場合、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクセス許可のみ実行できます。プリンシパルとしてユーザーまたはロールを指定するリソースベースのポリシーは、アクセス許可の境界では制限されません。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。アクセス許可の境界の詳細については、「IAM エンティティのアクセス許可の境界」を参照してください。

サービスコントロールポリシー (SCP)

AWS Organizations は、ビジネスが所有する複数の AWS アカウントをグループ化して一元管理するためのサービスです。組織内のすべての機能を有効にすると、サービス制御ポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP は、組織または組織単位 (OU) のアクセス許可の上限を指定する JSON ポリシーです。SCP はメンバーアカウントのエンティティに対するアクセス許可を制限します (各 AWS アカウントのルートユーザー など)。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。

組織 および SCP の詳細については、『AWS Organizations ユーザーガイド』の「サービスコントロールポリシーについて」を参照してください。

アクセスコントロールポリシー (ACL)

アクセスコントロールポリシー (ACL) では、リソースにアクセスできる別のアカウントのプリンシパルを管理します。ACL を使用して、同じアカウント内のプリンシパルのアクセス権を制御することはできません。ACL は、リソースベースのポリシーと似ていますが、JSON ポリシードキュメント形式を使用しない唯一のポリシータイプです。ACL をサポートするサービスの例としては、Amazon S3、AWS WAF、 Amazon VPC などがあります。ACL の詳細については、『Amazon Simple Storage Service 開発者ガイド』の「アクセスコントロールリスト (ACL) の概要」を参照してください。

セッションポリシー

セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。セッションのアクセス許可は、セッションの作成に使用する IAM エンティティ (ユーザーまたはロール) のアイデンティティベースのポリシーと、セッションポリシーから派生します。また、リソースベースのポリシーからアクセス許可が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。

API の AssumeRoleAssumeRoleWithSAML、または AssumeRoleWithWebIdentity オペレーションを使用して、ロールセッションを作成し、プログラムでセッションポリシーを渡すことができます。結果として得られるセッションには、ロールのアイデンティティベースのポリシーおよびセッションポリシーの両方で付与されるアクセス許可のみが含まれます。ロールセッションに関する詳細については、「一時的なセキュリティ認証情報のリクエスト」を参照してください。

フェデレーティッドユーザーのセッションを作成する場合は、IAM ユーザーのアクセスキーを使用して、API の GetFederationToken オペレーションをプログラムで呼び出します。この方法で、セッションポリシーを渡した場合、結果として得られるセッションには、IAM ユーザーのアイデンティティベースのポリシーおよびセッションポリシーの両方で付与されるアクセス許可のみが含まれます。フェデレーティッドユーザーセッションの作成に関する詳細については、「GetFederationToken — カスタム ID ブローカーを経由したフェデレーション」を参照してください。

リソースベースのポリシーでユーザーまたはロールの ARN をプリンシパルとして指定すると、セッションが作成される前に、リソースベースのポリシーのアクセス許可がロールまたはユーザーのアイデンティティベースのポリシーに追加されます。このセッションポリシーでは、リソースベースのポリシーおよびアイデンティティベースのポリシーによって付与されるアクセス許可の合計を制限します。結果として得られるセッションには、セッションポリシーと、リソースベースのポリシーまたはアイデンティティベースのポリシーのアクセス許可が含まれます。


          エンティティ ARN を指定するリソースベースのポリシーを含むセッションポリシーの評価

リソースベースのポリシーでセッションの ARN をプリンシパルとして指定すると、セッション作成後に、リソースベースのポリシーのアクセス許可が追加されます。リソースベースのポリシーのアクセス許可は、セッションポリシーで制限されません。結果として得られるセッションには、リソースベースのポリシーのすべてのアクセス許可に加えて、アイデンティティベースのポリシーとセッションポリシーの両方によって付与されるアクセス許可が含まれます。


          セッション ARN を指定するリソースベースのポリシーを含むセッションポリシーの評価

アクセス許可の境界で、セッションの作成に使用するユーザーまたはロールのアクセス許可の上限を設定した場合、結果として得られるセッションには、セッションポリシー、アクセス許可の境界、およびアイデンティティベースのポリシーのアクセス許可のみ含まれます。


          アクセス許可の境界を含むセッションポリシーの評価

ポリシーとルートユーザー

AWS アカウントのルートユーザー に影響するポリシータイプは限定されます。ルートユーザー にはアイデンティティベースのポリシーをアタッチできません。また、ルートユーザー にはアクセス許可の境界を設定できません。ただし、ルートユーザー はリソースベースのポリシーまたは ACL でプリンシパルとして指定できます。ルートユーザー は、アカウントのメンバーとして、アカウントの SCP の影響を受けます。

JSON ポリシー概要

大半のポリシーは JSON ドキュメントとして AWS に保存されます。アイデンティティベースのポリシーおよび境界のアクセス許可設定に使用されるポリシーは、ユーザーまたはロールにアタッチする JSON ポリシードキュメントです。リソースベースのポリシーは、リソースにアタッチする JSON ポリシードキュメントです。SCP は、AWS Organizations 組織単位 (OU) にアタッチする (構文が制限された) JSON ポリシードキュメントです。ACL もリソースにアタッチしますが、別の構文を使用する必要があります。セッションポリシーは、ロールを引き受けるときに指定した JSON ポリシーです。

JSON 構文を理解する必要はありません。AWS マネジメントコンソール でビジュアルエディタを使用すると、JSON を一切使用することなく、カスタマー管理ポリシーを作成および編集できます。ただし、グループあるいは複雑なポリシーに対してインラインポリシーを使用する場合は、コンソールで JSON エディタを使用してポリシーを作成および編集する必要があります。ビジュアルエディタの詳細については、「IAM ポリシーの作成」および「IAM ポリシーの編集」を参照してください。

JSON ポリシードキュメント構造

次の図に示すように、JSON ポリシードキュメントは以下の要素で構成されます。

  • ドキュメント上部のポリシー概要 (オプション)

  • 1 つ以上の個別のステートメント

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


          JSON ポリシードキュメント構造

ステートメントの情報は、一連のエレメントの中に含まれています。

  • バージョン – 使用するポリシー言語のバージョンを指定します。ベストプラクティスとして、最新の 2012-10-17 バージョンを使用してください。

  • ステートメント – このポリシーのメイン要素であり、以下の要素のコンテナになります。ポリシーには、複数のステートメントを含めることができます。

  • Sid – 複数のステートメントを区別するためのステートメント ID (オプション) です。

  • 効果Allow または Deny を使用してポリシーで付与または拒否するアクセス許可を指定します。

  • プリンシパル – アクセス許可を付与または拒否するアカウント、ユーザー、ロール、またはフェデレーティッドユーザーを指定します。ユーザーまたはロールにアタッチするポリシーを作成する場合は、この要素を含めることはできません。プリンシパルは、そのユーザーまたはロールを暗黙に示しています。

  • アクション – ポリシーで許可または拒否するアクションのリストです。

  • リソース – アクションを適用するリソースのリストを指定します。

  • 条件 (オプション) – ポリシーでアクセス許可を付与する状況を指定します。

上記およびさらに詳細なポリシー要素の詳細については、「IAM JSON ポリシーエレメントのリファレンス」を参照してください。

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

エンティティ (ユーザー、グループ、またはロール) に対して複数のアクセス許可を定義する場合は、1 つのポリシーで複数のステートメントを使用するか、複数のポリシーをアタッチすることができます。1 つのステートメントで複数のアクセス許可を定義すると、ポリシーから期待するアクセス許可が付与されない場合があります。ベストプラクティスとしては、リソースタイプ別にポリシーを分けてください。

ポリシーのサイズが制限されているために、複雑なアクセス許可には複数のポリシーが必要になる場合があります。機能別にアクセス許可をグループ化して別個のカスタマー管理ポリシーを作成することも有効です。たとえば、IAM ユーザー管理用、自己管理用、S3 バケット管理用に 3 つのポリシーを作成するとします。AWS では、複数のステートメントや複数のポリシーの組み合わせにかかわらず、ポリシーを同じ方法で評価します。

たとえば、次のポリシーには 3 つのステートメントがあります。ステートメント別に異なるアクセス許可セットが 1 つのアカウント内に定義されます。各ステートメントでは以下が定義されます。

  • 最初のステートメントは、Sid (ステートメント ID) が FirstStatement であり、ポリシーがアタッチされたユーザーに対して各自のパスワードを変更することを許可します。このステートメントの Resource 要素は「すべてのリソース」を意味する「*」ですが、実際に API オペレーション ChangePassword (CLI コマンド change-password に対応) が影響するのはリクエストを行うユーザーのパスワードのみです。

  • 2 つ目のステートメントでは、ユーザーは AWS アカウントのすべての Amazon S3 バケットを一覧表示できます。このステートメントの Resource 要素は「すべてのリソース」を意味する "*" です。ただし、ポリシーでは他のアカウントのリソースへのアクセスが許可されていないため、ユーザーは自分の AWS アカウントのバケットのみ一覧表示できます。

  • 3 番目のステートメントでは、confidential-data というバケット内の任意のオブジェクトを表示および取得することをユーザーに許可しますが、ユーザーが多要素認証 (MFA) で認証することが条件です。このポリシーの Condition 要素で MFA 認証が強制されます。

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

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

JSON ポリシー構文の例

以下のアイデンティティベースのポリシーでは、1 つの Amazon S3 バケット example_bucket を表示することを暗黙のプリンシパルに許可します。

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

次のリソースベースのポリシーは Amazon S3 バケットにアタッチできます。このポリシーでは、バケット mybucket に対して Amazon S3 のすべてのアクションを実行することを、特定の AWS アカウントのメンバーに許可します。バケットやバケット内のオブジェクトに対して任意のアクションを実行できます。(このポリシーではアカウントに対してのみ信頼が付与されているため、指定された Amazon S3 アクションを実行するには、アクションへのアクセス許可をアカウント内の個々のユーザーに付与する必要があります。)

{ "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 アイデンティティベースのポリシーの例」を参照してください。