# AWS Identity and Access Management でのポリシーとアクセス許可
AWS でのアクセスを管理するには、ポリシーを作成し、IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) または AWS リソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、IAM プリンシパル (ユーザーまたはロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。ほとんどのポリシーは JSON ドキュメントとして AWS に保存されます。 AWS は、ID ベースのポリシー、リソースベースのポリシー、アクセス許可の境界、AWS Organizations のサービスコントロールポリシー (SCP)、AWS Organizations リソースコントロールポリシー (RCP)、アクセスコントロールリスト (ACL)、セッションポリシーのポリシータイプをサポートします。
IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、[GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html) アクションを許可するポリシーを適用されたユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からユーザー情報を取得できます。IAM ユーザーを作成したら、コンソールまたはプログラムによるアクセスを許可するように選択できます。コンソールへのアクセスが許可されている場合、IAM ユーザーは、サインイン認証情報を使用してコンソールにサインインできます。プログラムによるアクセスが許可されている場合、ユーザーは、アクセスキーで CLI または API を使用します。
## ポリシータイプ
AWS では、使用頻度の高いものから低いものの順にリストされた次のポリシータイプを使用できます。詳細については、以下のポリシータイプ別のセクションを参照してください。
+ **[ID ベースのポリシー](#policies_id-based)** – [管理](#managedpolicy)ポリシーと[インライン](#inline)ポリシーを IAM ID (ユーザー、ユーザーが所属するグループ、またはロール) に添付することができます。アイデンティティベースのポリシーでは、アクセス許可はアイデンティティに付与されます。
+ **[リソースベースのポリシー](#policies_resource-based)** – インラインポリシーをリソースにアタッチします。リソースベースのポリシーとして最も一般的な例は、Amazon S3 バケットポリシーと IAM ロールの信頼ポリシーです。リソースベースのポリシーでは、アクセス許可は、ポリシーで指定されているプリンシパルに付与されます。プリンシパルは、リソースと同じアカウントか、別のアカウントになります。
+ **[アクセス許可の境界](#policies_bound)** – IAM エンティティ (ユーザーまたはロール) のアクセス許可の境界として、管理ポリシーを使用します。このポリシーでは、アイデンティティベースのポリシーでエンティティに付与できるアクセス許可の上限を定義しますが、アクセス許可は付与されません。アクセス許可の境界では、リソースベースのポリシーでエンティティに付与できるアクセス許可の上限は定義されません。
+ **[AWS Organizations SCP](#policies_scp)** – AWS Organizations サービスコントロールポリシー (SCP) を使用して、組織または組織単位 (OU) のアカウント内の IAM ユーザーと IAM ロールの最大の許可を定義します。SCP は、ID ベースのポリシーまたはリソースベースのポリシーがアカウント内の IAM ユーザーまたは IAM ロールに付与する許可を制限します。SCP は許可を付与するものではありません。
+ **[AWS Organizations RCP](#policies_rcp)** – AWS Organizations リソースコントロールポリシー (RCP) を使用して、組織または組織単位 (OU) のアカウント内のリソースの最大の許可を定義します。RCP は、ID ベースのポリシーおよびリソースベースのポリシーが組織内のアカウントのリソースに付与できる許可を制限します。RCP は許可を付与するものではありません。
+ **[アクセスコントロールリスト (ACL)](#policies_acl)** – ACL を使用して、ACL がアタッチされているリソースにアクセスすることができる他のアカウントのプリンシパルを制御します。ACL は、リソースベースのポリシーと似ていますが、JSON ポリシードキュメント構造を使用しない唯一のポリシータイプです。ACL は、指定されたプリンシパルにアクセス許可を付与するクロスアカウントのアクセス許可ポリシーです。ACL では、同じアカウント内のエンティティにアクセス許可を付与することはできません。
+ **[セッションポリシー](#policies_session)** – AWS CLI または AWS API を使用して、ロールまたはフェデレーティッドユーザーを引き受ける場合に高度なセッションポリシーを渡します。セッションポリシーでは、ロールまたはユーザーのアイデンティティベースのポリシーでセッションに付与するアクセス許可を制限します。セッションポリシーでは、作成したセッションのアクセス許可が制限されますが、アクセス許可は付与されません。詳細については、「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、ユーザーのグループ、ロール) が実行できるアクション、リソース、および条件を制御する JSON アクセス許可ポリシードキュメントです。アイデンティティベースのポリシーはさらに次のように分類できます。
+ **管理ポリシー** - AWS アカウント 内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンのアイデンティティベースのポリシーです。管理ポリシーには 2 種類あります。
+ **AWS 管理ポリシー** – AWS が作成および管理する管理ポリシー。
+ **カスタマー管理ポリシー** - AWS アカウント で作成および管理する管理ポリシー。カスタマー管理ポリシーでは、AWS 管理ポリシーに比べて、より正確にポリシーを管理できます。
+ **インラインポリシー** - 単一のユーザー、グループ、ロールに直接追加するポリシー。インラインポリシーは、ポリシーとIDの間の厳密な1対1の関係を維持します。これらは、ID を削除すると削除されます。
管理ポリシーとインラインポリシーを使い分ける方法については、「[管理ポリシーとインラインポリシーのいずれかを選択する](access_policies-choosing-managed-or-inline.md)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、Amazon S3 バケットなどのリソースにアタッチする JSON ポリシードキュメントです。これらのポリシーでは、そのリソースに対して特定のアクションを実行するために指定されたプリンシパルのアクセス許可を付与するとともに、このアクセス許可が適用される条件を定義します。リソースベースのポリシーはインラインポリシーです。マネージド型のリソースベースのポリシーはありません。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルおよびリソースが別の AWS アカウント である場合は、アイデンティティベースのポリシーを使用して、リソースへのアクセス権をプリンシパルに付与する必要があります。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、アイデンティティベースのポリシーをさらに付与する必要はありません。クロスサービスアクセスを許可する手順については、[IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)。
IAM サービスは、ロールの*信頼ポリシー*と呼ばれるリソースベースのポリシーのタイプを 1 つのみサポートします。これが、IAM ロールにアタッチされています。IAM ロールは、リソースベースのポリシーをサポートするアイデンティティかつリソースです。そのため、信頼ポリシーとアイデンティティベースのポリシーのいずれも IAM ロールにアタッチする必要があります。信頼ポリシーでは、ロールを引き受けることができるプリンシパルエンティティ (アカウント、ユーザー、ロール、フェデレーティッドユーザー) を定義します。IAM ロールと、他のリソースベースのポリシーとの違いについては、「[IAM でのクロスアカウントのリソースへのアクセス](access_policies-cross-account-resource-access.md)」を参照してください。
リソースベースのポリシーをサポートするその他のサービスを確認するには､「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください｡ リソースベースのポリシーの詳細については、「[アイデンティティベースおよびリソースベースのポリシー](access_policies_identity-vs-resource.md)」を参照してください。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
### IAM アクセス許可の境界
アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界を設定した場合、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクセス許可のみ実行できます。リソースベースのポリシーのプリンシパル要素でロールセッションまたはユーザーを指定する場合、アクセス許可の境界における明示的な許可は必要ありません。ただし、リソースベースのポリシーのプリンシパル要素でロール ARN を指定する場合は、アクセス許可の境界における明示的な許可が必要です。いずれの場合も、アクセス許可の境界における明示的な拒否は有効です。これらのポリシーのいずれかを明示的に拒否した場合、許可は無効になります。アクセス許可の境界の詳細については、「[IAM エンティティのアクセス許可境界](access_policies_boundaries.md)」を参照してください
### AWS Organizations サービスコントロールポリシー (SCP)
組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP は、組織または組織単位 (OU) のアカウント内の IAM ユーザーと IAM ロールの最大の許可を指定する JSON ポリシーです。SCP はメンバーアカウントのプリンシパルに対する許可を制限します (各 AWS アカウントのルートユーザー など)。これらのポリシーのいずれかにおける明示的な拒否は、他のポリシーにおける許可をオーバーライドします。
AWS Organizations および SCP の詳細については、 「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
### AWS Organizations リソースコントロールポリシー (RCP)
組織内のすべての機能を有効にすると、リソースコントロールポリシー (RCP) を使用して、複数の AWS アカウント におけるリソースに対して、アクセスコントロールを一元的に適用できます。RCP は、所有する各リソースにアタッチされた IAM ポリシーを更新することなく、アカウント内のリソースのために使用できる最大の許可を設定するために使用できる JSON ポリシーです。RCP は、メンバーアカウントのリソースの許可を制限し、組織に属するかどうかにかかわらず、AWS アカウントのルートユーザー を含む ID のための有効な許可に影響を及ぼす可能性があります。該当する RCP の明示的な拒否は、個々の ID またはリソースにアタッチされる可能性のある他のポリシーの許可をオーバーライドします。
RCP をサポートする AWS のサービス のリストを含む AWS Organizations と RCP の詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
### アクセスコントロールリスト (ACL)
アクセスコントロールポリシー (ACL) は、リソースにアクセスできる別のアカウントのプリンシパルを制御できるサービスポリシーです。ACL を使用して、同じアカウント内のプリンシパルのアクセス権を制御することはできません。ACL は、リソースベースのポリシーと似ていますが、JSON ポリシードキュメント形式を使用しない唯一のポリシータイプです。Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、「Amazon Simple Storage Service デベロッパーガイド」の「[アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)」を参照してください。
### セッションポリシー
セッションポリシーは、ロールまたは AWS STS フェデレーションユーザーのプリンシパルに一時セッションをプログラムで作成する際、パラメータとして渡す高度なポリシーです。セッションのアクセス許可は、セッションの作成に使用する IAM エンティティ (ユーザーまたはロール) のアイデンティティベースのポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、許可は無効になります。
API の `AssumeRole`、`AssumeRoleWithSAML`、または `AssumeRoleWithWebIdentity` オペレーションを使用して、ロールセッションを作成し、プログラムでセッションポリシーを渡すことができます。`Policy` パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。`PolicyArns` パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。ロールセッションに関する詳細については、「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください。
AWS STS フェデレーションユーザーのプリンシパルセッションを作成する際、IAM ユーザーのアクセスキーを使用して `GetFederationToken` API オペレーションをプログラムで呼び出します。また、セッションポリシーも渡す必要があります。結果として得られるセッションのアクセス許可は、ID ベースのポリシーとセッションポリシーの共通部分です。フェデレーティッドユーザーセッションの作成に関する詳細については、「[カスタム ID ブローカーを通じた認証情報のリクエスト](id_credentials_temp_request.md#api_getfederationtoken)」を参照してください。
リソースベースのポリシーでは、プリンシパルとしてユーザーまたはロールの ARN を指定できます。その場合、セッションが作成される前に、リソースベースのポリシーのアクセス許可がロールまたはユーザーのアイデンティティベースのポリシーに追加されます。このセッションポリシーでは、リソースベースのポリシーおよびアイデンティティベースのポリシーによって付与されるアクセス許可の合計を制限します。結果として得られるセッションのアクセス許可は、セッションポリシーとリソースベースのポリシーの共通部分に加えて、セッションポリシーと ID ベースのポリシーの共通部分です。
![\[エンティティ ARN を指定するリソースベースのポリシーを含むセッションポリシーの評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/EffectivePermissions-session-rbp-id.png)
リソースベースのポリシーでは、プリンシパルとしてセッションの ARN を指定できます。その場合、リソースベースのポリシーのアクセス権限がセッションの作成後に追加されます。リソースベースのポリシーのアクセス許可は、セッションポリシーで制限されません。結果として得られるセッションには、リソースベースのポリシーのすべてのアクセス許可*に加えて*、アイデンティティベースのポリシーとセッションポリシーの共通部分があります。
![\[セッション ARN を指定するリソースベースのポリシーを含むセッションポリシーの評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/EffectivePermissions-session-rbpsession-id.png)
アクセス許可の境界で、セッションの作成に使用するユーザーまたはロールのアクセス許可の上限が設定されます。その場合、結果として得られるセッションのアクセス許可は、セッションポリシー、アクセス許可の境界、およびアイデンティティベースのポリシーの共通部分です。ただし、アクセス許可の境界では、結果として得られるセッションの ARN を指定するリソースベースのポリシーによって付与されたアクセス許可は制限されません。
![\[アクセス許可の境界を含むセッションポリシーの評価\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/EffectivePermissions-session-boundary-id.png)
## ポリシーとルートユーザー
AWS アカウントのルートユーザー に影響するポリシータイプは限定されます。ルートユーザーにはアイデンティティベースのポリシーをアタッチできません。また、ルートユーザーにはアクセス許可の境界を設定できません。ただし、ルートユーザーはリソースベースのポリシーまたは ACL でプリンシパルとして指定できます。ルートユーザーは引き続きアカウントのメンバーです。そのアカウントが AWS Organizations の組織のメンバーの場合、ルートユーザーからアカウントの SCP および RCP の影響を受けます。
## JSON ポリシー概要
大半のポリシーは JSON ドキュメントとして AWS に保存されます。アイデンティティベースのポリシーおよび境界のアクセス許可設定に使用されるポリシーは、ユーザーまたはロールにアタッチする JSON ポリシードキュメントです。リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。SCP と RCP は、AWS Organizations 組織ルート、組織単位 (OU)、またはアカウントにアタッチする、制限された構文を持つ JSON ポリシードキュメントです。ACL もリソースにアタッチしますが、別の構文を使用する必要があります。セッションポリシーは、ロールまたはフェデレーティッドユーザーセッションを引き受けるときに指定した JSON ポリシーです。
JSON 構文を理解する必要はありません。AWS マネジメントコンソール でビジュアルエディタを使用すると、JSON を一切使用することなく、カスタマー管理ポリシーを作成および編集できます。ただし、グループあるいは複雑なポリシーに対してインラインポリシーを使用する場合は、コンソールで JSON エディタを使用してポリシーを作成および編集する必要があります。ビジュアルエディタの詳細については、「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](access_policies_create.md)」および「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
JSON ポリシーを作成または編集するときに、IAM はポリシー検証を実行し、効果的なポリシーを作成するのに役立ちます。IAM は JSON 構文エラーを識別します。一方、IAM Access Analyzer は、ポリシーをさらに絞り込むのに役立つ推奨事項を含む追加のポリシーチェックを提供します。ポリシーの検証の詳細については、「[IAM ポリシーの検証](access_policies_policy-validator.md)」を参照してください。。IAM Access Analyzer のポリシーチェックと実用的な推奨事項の詳細については、「[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)」IAM Access Analyzer ポリシーの検証を参照してください。
### JSON ポリシードキュメント構造
次の図に示すように、JSON ポリシードキュメントは以下の要素で構成されます。
+ ドキュメントの最上部に記載されるポリシー全体の情報 (任意)
+ 1 つ以上の個別のステートメント**
各ステートメントには、1 つのアクセス許可に関する情報が含まれています。ポリシーに複数のステートメントが含まれている場合、AWS は評価時にステートメント全体に論理 `OR` を適用します。複数のポリシーが 1 つのリクエストに適用される場合、AWS は評価時にすべてのポリシーに論理 `OR` を適用します。
![\[JSON ポリシードキュメント構造\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/AccessPolicyLanguage_General_Policy_Structure.diagram.png)
ステートメントの情報は、一連の要素の中に含まれています。
+ **Version** – 使用するポリシー言語のバージョンを指定します。最新 `2012-10-17 ` バージョンの使用をお勧めします。詳細については、[IAM JSON ポリシー要素Version](reference_policies_elements_version.md)を参照してください。
+ **Statement** – このポリシーのメイン要素であり、以下の要素のコンテナになります。ポリシーには、複数のステートメントを含めることができます。
+ **Sid** (オプション) – 複数のステートメントを区別するための任意のステートメント ID が含まれます。
+ **Effect** – `Allow` または `Deny` を使用してポリシーで付与または拒否するアクセス許可を指定します。
+ **Principal** (一部の状況で必須) – リソースベースのポリシーを作成する場合、アクセスを許可または拒否するアカウント、ユーザー、ロール、AWS STS フェデレーションユーザーのプリンシパルを指定する必要があります。ユーザーまたはロールにアタッチする IAM アクセス許可ポリシーを作成する場合は、この要素を含めることはできません。プリンシパルは、そのユーザーまたはロールを暗黙に示しています。
+ **Action** – ポリシーで許可または拒否するアクションのリストが含まれます。
+ **Resource** (一部の状況で必須) IAM アクセス許可ポリシーを作成する場合は、アクションが適用されるリソースのリストを指定する必要があります。リソースベースのポリシーを作成する場合、この要素が必要かどうかについて、使用しているリソースによって異なります。
+ **Condition** (オプション) ポリシーでアクセス許可を付与する状況を指定します。
上記およびさらに詳細なポリシー要素の詳細については、「[IAM JSON ポリシー要素のリファレンス](reference_policies_elements.md)」を参照してください。
### 複数のステートメントと複数のポリシー
エンティティ (ユーザーまたはロール) に対して複数のアクセス許可を定義する場合は、1 つのポリシーで複数のステートメントを使用することができます。また、複数のポリシーをアタッチすることもできます。1 つのステートメントで複数のアクセス許可を定義すると、ポリシーから期待するアクセス許可が付与されない場合があります。ポリシーをリソースタイプ別に分割することをお勧めします。
[ポリシーのサイズが制限されている](reference_iam-quotas.md)ために、複雑なアクセス許可には複数のポリシーが必要になる場合があります。機能別にアクセス許可をグループ化して別個のカスタマー管理ポリシーを作成することも有効です。たとえば、IAM ユーザー管理用、自己管理用、S3 バケット管理用に 3 つのポリシーを作成するとします。AWS では、複数のステートメントや複数のポリシーの組み合わせにかかわらず、ポリシーを同じ方法で[評価](reference_policies_evaluation-logic.md)します。
たとえば、次のポリシーには 3 つのステートメントがあります。ステートメント別に異なるアクセス許可セットが 1 つのアカウント内に定義されます。各ステートメントでは以下が定義されます。
+ 最初のステートメントは、`Sid` (ステートメント ID) が `FirstStatement` であり、ポリシーがアタッチされたユーザーに対して各自のパスワードを変更することを許可します。このステートメントの `Resource` 要素は「すべてのリソース」を意味する「`*`」です。しかし、実際に API オペレーション `ChangePassword` (CLI コマンド `change-password` に対応) が影響するのはリクエストを行うユーザーのパスワードのみです。
+ 2 つ目のステートメントでは、ユーザーは AWS アカウント のすべての Amazon S3 バケットを一覧表示できます。このステートメントの `Resource` 要素は「すべてのリソース」を意味する `"*"` です。ただし、ポリシーでは他のアカウントのリソースへのアクセスが許可されていないため、ユーザーは自分の AWS アカウント のバケットのみ一覧表示できます。
+ 3 番目のステートメントでは、`amzn-s3-demo-bucket-confidential-data` というバケット内の任意のオブジェクトを表示および取得することをユーザーに許可しますが、ユーザーが多要素認証 (MFA) で認証することが条件です。このポリシーの `Condition` 要素で MFA 認証が強制されます。
ポリシーステートメントに `Condition` 要素が含まれている場合、このステートメントは `Condition` 要素が true に評価されたときにのみ有効になります。この例では、ユーザーが MFA 認証された場合に限り、`Condition` 要素が true に評価されます。ユーザーが MFA 認証されていない場合、この `Condition` は false に評価されます。この場合、このポリシーの 3 番目のステートメントは適用されず、ユーザーは `amzn-s3-demo-bucket-confidential-data` バケットにアクセスできません。
------
#### [ JSON ]
****
```
{
"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:::amzn-s3-demo-bucket-confidential-data",
"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}
```
------
### JSON ポリシー構文の例
次のIDベースのポリシーにより、暗黙のプリンシパルは `amzn-s3-demo-bucket` という名前の単一の Amazon S3 バケットをリストできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
}
}
```
------
次のリソースベースのポリシーは Amazon S3 バケットにアタッチできます。このポリシーでは、バケット `amzn-s3-demo-bucket` に対して Amazon S3 のすべてのアクションを実行することを、特定の AWS アカウント のメンバーに許可します。バケットやバケット内のオブジェクトに対して任意のアクションを実行できます。(このポリシーではアカウントに対してのみ信頼が付与されているため、指定された Amazon S3 アクションを実行するには、アクションへのアクセス許可をアカウント内の個々のユーザーに付与する必要があります。)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}
```
------
一般的なシナリオのポリシー例については、「[IAM アイデンティティベースのポリシーの例](access_policies_examples.md)」を参照してください。
## 最小特権アクセス許可を適用する
IAM ポリシーを作成する場合、*最小限のアクセス権*を付与するという標準的なセキュリティアドバイスに従うか、タスクの実行に必要なアクセス許可のみ付与します。ユーザー (およびロール) が何をする必要があるのかを決定してから、それらのタスクのみの実行を許可するポリシーを作成します。
最小限の許可からスタートし、必要に応じて追加の許可を付与します。この方法は、寛容過ぎる許可から始めて、後から厳しくしようとするよりも安全です。
最小限のアクセス許可の代わりに、[AWS 管理対象ポリシー](access_policies_managed-vs-inline.md#aws-managed-policies)またはワイルドカード `*` アクセス許可を持つポリシーを使用して、ポリシーの使用を開始できます。プリンシパルにジョブに必要な以上のアクセス許可を付与すると、セキュリティ上のリスクを考慮してください。これらのプリンシパルをモニタリングして、使用しているアクセス許可を確認します。次に、最小限の特権ポリシーを記述します。
IAM には、付与するアクセス許可を絞り込むのに役立つオプションがいくつか用意されています。
+ **アクセスレベルのグループ化** – ポリシーが付与するアクセスレベルを把握できます。[ポリシーアクション](reference_policies_elements_action.md)は、`List`、`Read`、`Write`、`Permissions management`、または `Tagging` として分類されています。たとえば、`List` や `Read` アクセスレベルからアクションを選択し、ユーザーに読み取り専用のアクセスレベルを付与することができます。アクセスレベルの権限を理解するためにポリシーの概要を使用するには「[ポリシー概要のアクセスレベル](access_policies_understand-policy-summary-access-level-summaries.md)」をご覧ください。
+ **ポリシーの検証**— JSON ポリシーを作成および編集するときに、IAM Access Analyzer を使用してポリシーの検証を実行できます。既存のすべてのポリシーを確認および検証することをお勧めします。IAM Access Analyzer では、ポリシーを検証するために 100 を超えるポリシーチェックが提供されます。ポリシー内のステートメントで、過度に許容されるアクセスを許可すると、セキュリティ警告が生成されます。最小限の特権の付与に向けて作業するときに、セキュリティ警告によって提供される実用的な推奨事項を使用できます。IAM Access Analyzer で提供されるポリシーチェックの詳細については、「[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)」を参照してください。。
+ **アクセスアクティビティに基づくポリシーの生成**— 付与するアクセス権限を調整するために、IAM エンティティ (ユーザーまたはロール) のアクセスアクティビティに基づく IAM ポリシーを生成できます。IAM Access Analyzer は AWS CloudTrail ログを確認し、指定した日付範囲内のロールが使用したアクセス許可を含むポリシーテンプレートを生成します。テンプレートを使用して、きめ細かなアクセス権限で管理ポリシーを作成し、それを IAM エンティティにアタッチできます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス権限のみを付与します。詳細については、「[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)」を参照してください。
+ **最終アクセス情報を使用** — 最低限のアクセス許可で役立つもう 1 つの機能は、*最終アクセス情報*です。IAM ユーザー、グループ、ロール、ポリシーのこの情報は、IAM コンソールの詳細ページの [**アクセスアドバイザー**] に表示されます。最終アクセス情報には、Amazon EC2、IAM、Lambda、Amazon S3 など、一部のサービスで最後にアクセスされたアクションに関する情報も含まれます。AWS Organizations 管理アカウントの認証情報を使用してサインインすると、IAM コンソールの [**AWS Organizations**] セクションでサービスの最終アクセス情報を表示できます。AWS CLI または AWS API を使用して、IAM または AWS Organizations のエンティティまたはポリシーの最終アクセス時間情報のレポートを取得するために使用することもできます。この情報を使用して不要なアクセス許可を識別し、最小権限の原則により良く準拠するよう IAM または AWS Organizations ポリシーを改善することができます。詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。
+ **AWS CloudTrail のアカウントイベントを確認** - アクセス許可をさらに削減するには、AWS CloudTrail の**イベント履歴**でアカウントのイベントを表示できます。CloudTrail のイベントログには、ポリシーのアクセス許可を減らすために使用できる詳細なイベント情報が含まれます。ログには、IAM エンティティが必要とするアクションとリソースのみが含まれます。詳細については、*AWS CloudTrail ユーザーガイド*の [CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html)を参照してください。
詳細については、以下の各サービスのポリシートピックを参照してください。サービス固有のリソースに対するポリシーの書き方の例を挙げています。
+ 「*Amazon DynamoDB デベロッパーガイド*」の「[DynamoDB のリソースベースのポリシーの使用](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-resource-based.html)」
+ 「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 のバケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)」
+ 『*Amazon Simple Storage Service ユーザーガイド*』の「[アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)」