IAM でのポリシーとアクセス許可

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

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

ポリシータイプ

AWS では、使用頻度の高いものから低いものの順にリストされた次のポリシータイプを使用できます。詳細については、以下のポリシータイプ別のセクションを参照してください。

• ID ベースのポリシー – 管理ポリシーとインラインポリシーを IAM ID (ユーザー、ユーザーが所属するグループ、またはロール) に添付することができます。アイデンティティベースのポリシーでは、アクセス許可はアイデンティティに付与されます。

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

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

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

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

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

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

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

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

  • AWS 管理ポリシー – AWS が作成および管理する管理ポリシー。

  • カスタマー管理ポリシー - AWS アカウント で作成および管理する管理ポリシー。カスタマー管理ポリシーでは、AWS 管理ポリシーに比べて、より正確にポリシーを管理できます。

• インラインポリシー - 単一のユーザー、グループ、ロールに直接追加するポリシー。インラインポリシーは、ポリシーとIDの間の厳密な1対1の関係を維持します。これらは、ID を削除すると削除されます。

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

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

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

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

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

リソースベースのポリシーをサポートするその他のサービスを確認するには､「IAM と連携する AWS のサービス」を参照してください｡ リソースベースのポリシーの詳細については、「アイデンティティベースおよびリソースベースのポリシー」を参照してください。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。

IAM アクセス許可の境界

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

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

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

Organizations と SCP の詳細については、AWS Organizations ユーザーガイドの「 SCP の仕組み」を参照してください。

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

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

セッションポリシー

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

API の AssumeRole、AssumeRoleWithSAML、または AssumeRoleWithWebIdentity オペレーションを使用して、ロールセッションを作成し、プログラムでセッションポリシーを渡すことができます。Policy パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。PolicyArns パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。ロールセッションに関する詳細については、「一時的なセキュリティ認証情報のリクエスト」を参照してください。

フェデレーションユーザーのセッションを作成する場合は、IAM ユーザーのアクセスキーを使用して、API の GetFederationToken オペレーションをプログラムで呼び出します。また、セッションポリシーも渡す必要があります。結果として得られるセッションのアクセス許可は、ID ベースのポリシーとセッションポリシーの共通部分です。フェデレーティッドユーザーセッションの作成に関する詳細については、「GetFederationToken — カスタム ID ブローカーを介したフェデレーション」を参照してください。

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

リソースベースのポリシーでは、プリンシパルとしてセッションの ARN を指定できます。その場合、リソースベースのポリシーのアクセス権限がセッションの作成後に追加されます。リソースベースのポリシーのアクセス許可は、セッションポリシーで制限されません。結果として得られるセッションには、リソースベースのポリシーのすべてのアクセス許可に加えて、アイデンティティベースのポリシーとセッションポリシーの共通部分があります。

アクセス許可の境界で、セッションの作成に使用するユーザーまたはロールのアクセス許可の上限が設定されます。その場合、結果として得られるセッションのアクセス許可は、セッションポリシー、アクセス許可の境界、およびアイデンティティベースのポリシーの共通部分です。ただし、アクセス許可の境界では、結果として得られるセッションの ARN を指定するリソースベースのポリシーによって付与されたアクセス許可は制限されません。

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

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

JSON ポリシー概要

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

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

JSON ポリシーを作成または編集するときに、IAM はポリシー検証を実行し、効果的なポリシーを作成するのに役立ちます。IAM は JSON 構文エラーを識別します。一方、IAM Access Analyzer は、ポリシーをさらに絞り込むのに役立つ推奨事項を含む追加のポリシーチェックを提供します。ポリシーの検証の詳細については、「IAM ポリシーの検証」を参照してください。。IAM Access Analyzer のポリシーチェックと実用的な推奨事項の詳細については、「IAM Access Analyzer ポリシーの検証」IAM Access Analyzer ポリシーの検証を参照してください。

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

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

• ドキュメントの最上部に記載されるポリシー全体の情報 (任意)

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

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

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

• Version – 使用するポリシー言語のバージョンを指定します。最新 2012-10-17 バージョンの使用をお勧めします。詳細については、「IAM JSON ポリシー要素: Version」を参照してください。

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

• Sid (オプション) – 複数のステートメントを区別するための任意のステートメント ID が含まれます。

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

• Principal (一部の状況でのみ必須) リソースベースのポリシーを作成する場合は、アクセスを許可または拒否するアカウント、ユーザー、ロール、またはフェデレーティッドユーザーを指定する必要があります。ユーザーまたはロールにアタッチする IAM アクセス許可ポリシーを作成する場合は、この要素を含めることはできません。プリンシパルは、そのユーザーまたはロールを暗黙に示しています。

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

• Resource (一部の状況でのみ必須) IAM アクセス許可ポリシーを作成する場合は、アクションが適用されるリソースのリストを指定する必要があります。リソースベースのポリシーを作成する場合は、この要素はオプションです。この要素を含めない場合、アクションが適用されるリソースは、ポリシーがアタッチされているリソースです。

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

上記およびさらに詳細なポリシー要素の詳細については、「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 ポリシー構文の例

次のIDベースのポリシーにより、暗黙のプリンシパルは example_bucket という名前の単一の Amazon S3 バケットをリストできます。

{
  "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",
  "Statement": [{
    "Sid": "1",
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::account-id:root"]},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }]
}

一般的なシナリオのポリシー例については、「IAM アイデンティティベースのポリシーの例」を参照してください。

最小限の特権を認める。

IAM ポリシーを作成する場合、最小限のアクセス権を付与するという標準的なセキュリティアドバイスに従うか、タスクの実行に必要なアクセス許可のみ付与します。ユーザー (およびロール) が何をする必要があるのかを決定してから、それらのタスクのみの実行を許可するポリシーを作成します。

最小限の許可からスタートし、必要に応じて追加の許可を付与します。この方法は、寛容過ぎる許可から始めて、後から厳しくしようとするよりも安全です。

最小限のアクセス許可の代わりに、AWS 管理対象ポリシーまたはワイルドカード * アクセス許可を持つポリシーを使用して、ポリシーの使用を開始できます。プリンシパルにジョブに必要な以上のアクセス許可を付与すると、セキュリティ上のリスクを考慮してください。これらのプリンシパルをモニタリングして、使用しているアクセス許可を確認します。次に、最小限の特権ポリシーを記述します。

IAM には、付与するアクセス許可を絞り込むのに役立つオプションがいくつか用意されています。

• アクセスレベルのグループ化 – ポリシーが付与するアクセスレベルを把握できます。ポリシーアクションは、List、Read、Write、Permissions management、または Tagging として分類されています。たとえば、List や Read アクセスレベルからアクションを選択し、ユーザーに読み取り専用のアクセスレベルを付与することができます。アクセスレベルの権限を理解するためにポリシーの概要を使用するには「ポリシー概要内のアクセスレベルの概要について」をご覧ください。

• ポリシーの検証— JSON ポリシーを作成および編集するときに、IAM Access Analyzer を使用してポリシーの検証を実行できます。既存のすべてのポリシーを確認および検証することをお勧めします。IAM Access Analyzer では、ポリシーを検証するために 100 を超えるポリシーチェックが提供されます。ポリシー内のステートメントで、過度に許容されるアクセスを許可すると、セキュリティ警告が生成されます。最小限の特権の付与に向けて作業するときに、セキュリティ警告によって提供される実用的な推奨事項を使用できます。IAM Access Analyzer で提供されるポリシーチェックの詳細については、「IAM Access Analyzer ポリシーの検証」を参照してください。。

• アクセスアクティビティに基づくポリシーの生成— 付与するアクセス権限を調整するために、IAM エンティティ (ユーザーまたはロール) のアクセスアクティビティに基づく IAM ポリシーを生成できます。IAM Access Analyzer は AWS CloudTrail ログを確認し、指定した日付範囲内のロールが使用したアクセス許可を含むポリシーテンプレートを生成します。テンプレートを使用して、きめ細かなアクセス権限で管理ポリシーを作成し、それを IAM エンティティにアタッチできます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス権限のみを付与します。詳細については、「アクセスアクティビティに基づいてポリシーを生成する」を参照してください。

• 最終アクセス情報を使用 — 最低限のアクセス許可で役立つもう 1 つの機能は、最終アクセス情報です。IAM ユーザー、グループ、ロール、ポリシーのこの情報は、IAM コンソールの詳細ページの [アクセスアドバイザー] に表示されます。最終アクセス情報には、Amazon EC2、IAM、Lambda、Amazon S3 など、一部のサービスで最後にアクセスされたアクションに関する情報も含まれます。AWS Organizations 管理アカウントの認証情報を使用してサインインすると、IAM コンソールの [AWS Organizations] セクションでサービスの最終アクセス情報を表示できます。AWS CLI または AWS API を使用して、IAM または Organizations でエンティティまたはポリシーの最終アクセス情報のレポートを取得するために使用することもできます。この情報を使用して不要なアクセス許可を識別し、最小権限の原則により良く準拠するよう IAM または Organizations ポリシーを改善することができます。詳細については、「最終アクセス情報を使用した AWS のアクセス許可の調整」を参照してください。

• AWS CloudTrail のアカウントイベントを確認 - アクセス許可をさらに削減するには、AWS CloudTrail のイベント履歴でアカウントのイベントを表示できます。CloudTrail のイベントログには、ポリシーのアクセス許可を減らすために使用できる詳細なイベント情報が含まれます。ログには、IAM エンティティが必要とするアクションとリソースのみが含まれます。詳細については、AWS CloudTrail ユーザーガイドの CloudTrail イベント履歴でのイベントの表示を参照してください。

詳細については、以下の各サービスのポリシートピックを参照してください。サービス固有のリソースに対するポリシーの書き方の例を挙げています。

• Amazon DynamoDB 開発者ガイドのAmazon DynamoDB に対する認証とアクセスコントロール

• Amazon Simple Storage Service ユーザーガイドのバケットポリシーとユーザーポリシーの使用

• Amazon Simple Storage Service ユーザーガイドの「アクセスコントロールリスト (ACL) の概要」