IAM でのポリシーとアクセス許可 - AWS Identity and Access Management

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

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

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

ポリシータイプ

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

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

  • リソースベースのポリシー – インラインポリシーをリソースにアタッチします。リソースベースのポリシーとして最も一般的な例は、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 ロールとリソースベースのポリシーとの相違点」を参照してください。

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

IAM アクセス許可の境界

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

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

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

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

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

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

セッションポリシー

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

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

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

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


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

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


          セッション 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 を適用します。


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

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

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

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

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

  • EffectAllow または 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 バケットにアタッチできます。このポリシーでは、バケット AWS に対して Amazon S3 のすべてのアクションを実行することを、特定の mybucket アカウントのメンバーに許可します。バケットやバケット内のオブジェクトに対して任意のアクションを実行できます。(このポリシーではアカウントに対してのみ信頼が付与されているため、指定された 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/*" ] }] }

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