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

ポリシーの評価論理

プリンシパルが AWS マネジメントコンソール、AWS API、または AWS CLI を使用しようとすると、プリンシパルは AWS にリクエストを送信します。AWS サービスが、リクエストを受け取ると、AWS は、いくつかのステップを実行してリクエストの許可または拒否を決定します。

  1. 認証 – AWS は、必要に応じて、最初にリクエストを行ったプリンシパルを認証します。このステップは、匿名ユーザーからの一部のリクエストを許可するいくつかのサービス (Amazon S3 など) では不要です。

  2. リクエストコンテキストの処理 – AWS は、リクエスト内で収集した情報を処理し、リクエストに適用するポリシーを決定します。

  3. 単一アカウント内のポリシーを評価する – AWS は、すべてのポリシータイプを評価します。ポリシータイプは、ポリシーを評価する順序に影響を与えます。

  4. アカウント内でのリクエストの許可または拒否の決定 – 次に AWS はリクエストコンテキストに照らしてポリシーを処理し、リクエストの許可または拒否を決定します。

リクエストコンテキストの処理

AWS はリクエストを処理して、以下の情報をリクエストコンテキスト内に取り込みます。

  • アクション (またはオペレーション) – プリンシパルが実行するアクションまたはオペレーション。

  • リソース – アクションまたはオペレーションを実行する対象の AWS リソースオブジェクト。

  • プリンシパル – リクエストの送信元のユーザー、ロール、フェデレーティッドユーザー、またはアプリケーション。プリンシパルに関する情報には、そのプリンシパルに関連付けられたポリシーが含まれます。

  • 環境データ – IP アドレス、ユーザーエージェント、SSL 有効化ステータス、または時刻に関する情報。

  • リソースデータ – リクエストされているリソースに関連するデータ。これには、DynamoDB テーブル名、Amazon EC2 インスタンスのタグなどの情報が含まれる場合があります。

次に、AWS は以上の情報を使用してリクエストコンテキストに適用するポリシーを見つけます。

単一アカウント内のポリシーを評価する

AWS によるポリシーの評価方法は、リクエストコンテキストに適用するポリシーのタイプによって異なります。以下のポリシータイプ (使用頻度の高い順に表示) は、単一の AWS アカウントで使用することができます。これらのポリシータイプの詳細については、「ポリシーとアクセス許可」を参照してください。クロスアカウントの認可の詳細については、「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

  1. アイデンティティベースのポリシー – アイデンティティベースのポリシーは、IAM アイデンティティ (ユーザー、ユーザーのグループ、またはロール) にアタッチされており、アクセス許可を IAM エンティティ (ユーザーおよびロール) にアタッチします。リクエストにアイデンティティベースのポリシーのみ、リクエストに適用された場合、AWS では、それらのすべてのポリシーに少なくとも 1 つ Allow がないか確認します。

  2. リソースベースのポリシー – リソースベースのポリシーは、プリンシパルとして指定されたプリンシパルエンティティ (アカウント、ユーザー、ロール、またはフェデレーティッドユーザー) にアクセス許可を付与します。このアクセス許可では、ポリシーがアタッチされているリソースに対してプリンシパルが実行できる操作を定義します。リソースベースのポリシーとアイデンティティのポリシーの両方がリクエストに適用された場合、AWS では、それらのすべてのポリシーに少なくとも 1 つ Allow がないか確認します。

  3. IAM アクセス許可の境界 – アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティ (ユーザーまたはロール) に付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界を設定した場合、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクセス許可のみ実行できます。アクセス許可の境界は、リソースベースのポリシーで付与されるアクセス許可には影響しません。

  4. AWS Organizations サービスコントロールポリシー (SCP) – 組織 SCP は、組織または組織単位 (OU) のアクセス許可の上限を指定します。最大 SCP はメンバーアカウントのエンティティに適用されます (各 AWS アカウントのルートユーザー など)。SCP が存在する場合、アイデンティティのポリシーおよびリソースベースのポリシーは、それらのポリシーと SCP によってアクションが許可されている場合にのみ、エンティティにアクセス許可を付与します。アクセス許可の境界と SCP が両方存在する場合は、アクセス許可の境界、SCP、およびアイデンティティのポリシーによって、すべてのアクションが許可されます。

  5. セッションポリシー – セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。ロールセッションをプログラムで作成するには、AssumeRole* API オペレーションのいずれかを使用します。これを行い、セッションポリシーに合格すると、結果として得られるセッションのアクセス許可は、IAM エンティティの ID ベースのポリシーとセッションポリシーの共通部分です。フェデレーティッドユーザーのセッションを作成するには、IAM ユーザーのアクセスキーを使用して、API の GetFederationToken オペレーションをプログラムで呼び出します。リソースベースのポリシーは、セッションポリシーのアクセス許可ポリシーの評価に異なる影響を与えます。この違いは、ユーザーまたはロールの ARN またはセッションの ARN がリソースベースのポリシーでプリンシパルとして表示されているかどうかによって異なります。詳細については、「セッションポリシー」を参照してください。

これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になる点に注意してください。

リソースベースのポリシーを使用したアイデンティティベースのポリシーの評価

アイデンティティのポリシーとリソースベースのポリシーは、それらが関連付けられているアイデンティティまたはリソースにアクセス許可を付与します。IAM エンティティ (ユーザーまたはロール) が同じアカウントのリソースへのアクセスをリクエストした場合、AWS は、アイデンティティのポリシーおよびリソースベースのポリシーによって付与されているすべてのアクセス許可を評価します。結果として、合計 2 種類のアクセス許可が付与されます。アクションがアイデンティティのポリシーかリソースベースのポリシー、または両方で許可されている場合、AWS はそのアクションを許可します。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。


               アイデンティティベースのポリシーおよびリソースベースのポリシーの評価

アクセス許可の境界を使用したアイデンティティベースのポリシーの評価

AWS でユーザーのアイデンティティベースのポリシーとアクセス許可の境界を評価する場合は、2 つのカテゴリの共通部分に基づいてアクセス許可が決定されます。つまり、既存のアイデンティティベースのポリシーを使用してアクセス許可の境界をユーザーに追加すると、ユーザーが実行できるアクションが制限される場合があります。逆に、ユーザーからアクセス許可の境界を削除すると、ユーザーが実行できるアクションが増える場合があります。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。他のポリシータイプがアクセス許可の境界で評価される方法について確認するには、「境界を設定した場合の有効なアクセス許可の評価」を参照してください。


               アイデンティティベースのポリシーとアクセス許可の境界の評価

組織 SCP を使用したアイデンティティベースのポリシーの評価

ユーザーが組織のメンバーであるアカウントに所属している場合、結果として得られるアクセス許可はユーザーのポリシーと SCP の共通部分です。つまり、アクションは、アイデンティティベースのポリシーと SCP の両方で許可されます。これらのポリシーのいずれかを明示的に拒否した場合、その許可は無効になります。


               アイデンティティベースのポリシーと SCP の評価

自分のアカウントが AWS Organizations の組織のメンバーであるかどうかを確認できます。組織のメンバーは、SCP による影響を受ける可能性があります。AWS CLI コマンドまたは AWS API オペレーションを使用してこのデータを表示するには、組織 エンティティに対する organizations:DescribeOrganization アクションのアクセス許可が必要です。組織 コンソールでオペレーションを実行するには、追加のアクセス許可が必要です。SCP が特定のリクエストへのアクセスを拒否しているかどうかを確認する、または有効なアクセス権限を変更するには、AWS Organizations 管理者に連絡してください。

アカウント内でのリクエストの許可または拒否の決定

プリンシパルが、プリンシパルのエンティティと同じアカウントのリソースにアクセスするためのリクエストを AWS に送信するとします。AWS エンフォースメントコードは、リクエストを許可するか拒否するかどうかを決定します。AWS は、リクエストコンテキストに適用されるすべてのポリシーを収集します。単一アカウントでのポリシーの AWS 評価ロジックの概要を以下に示します。

  • デフォルトでは、すべてのリクエストが明示的に拒否されます。(または、AWS アカウントのルートユーザー には、デフォルトでフルアクセス権が付与されています)。

  • アイデンティティベースのポリシーまたはリソースベースのポリシーに明示的な許可が含まれている場合、このデフォルト設定は上書きされます。

  • アクセス許可の境界、組織 SCP、またはセッションポリシーがある場合、この許可は明示的な拒否で上書きされる場合があります。

  • ポリシー内の明示的な拒否は、すべての許可に優先します。

以下のフローチャートは、決定が下されるまでの詳細な流れを示しています。


            評価フローチャート
  1. 拒否の評価 – デフォルトでは、すべてのリクエストが拒否されます。これは暗黙的な拒否と呼ばれます。AWS エンフォースメントコードでは、リクエストに適用されるアカウント内のすべてのポリシーを評価します。このポリシータイプには、AWS Organizations SCP、リソースベースのポリシー、IAM アクセス許可の境界、ロールセッションポリシー、およびアイデンティティベースのポリシーなどがあります。エンフォースメントコードでは、すべての該当するポリシーでリクエストに適用される Deny ステートメントを探します。このプロセスは明示的な拒否と呼ばれています。適用される明示的な拒否が 1 つでも見つかると、拒否の最終決定が返ります。明示的な拒否がない場合は、コードが続行されます。

  2. 組織 SCP – その後、コードは、リクエストに適用する AWS Organizations サービスコントロールポリシー (SCP) を評価します。SCP は、SCP がアタッチされているアカウントでリクエストされた場合に適用されます。エンフォースメントコードで SCP に Allow ステートメントが見つからなかった場合、リクエストは暗黙的に拒否されます。この場合、拒否の最終決定が返ります。SCP がない場合、または SCP により、リクエストされたアクションが許可された場合は、コードが続行されます。

  3. リソースベースのポリシー – リクエストされたリソースに、リクエストされたアクションを実行することをプリンシパルエンティティに許可するリソースベースのポリシーが含まれている場合は、コードで許可の最終決定が返ります。リソースベースのポリシーがない場合、またはポリシーに Allow ステートメントが含まれていない場合は、コードが続行されます。

    注記

    IAM ロールまたはユーザーの ARN をリソースベースのポリシーのプリンシパルとして指定した場合、このロジックは異なる動作をする可能性があります。他人がセッションポリシーを使用して、そのロールまたはフェデレーティッドユーザーの一時的な認証情報セッションを作成できます。その場合は、セッションに対する有効なアクセス許可は、ユーザーまたはロールのアイデンティティベースのポリシーで許可されているアクセス許可を超えない可能性があります。詳細については、「セッションポリシー」を参照してください。

  4. IAM アクセス許可の境界 – その後、エンフォースメントコードで、プリンシパルによって使用されている IAM エンティティにアクセス許可の境界があるかどうかが確認されます。アクセス許可の境界の設定に使用されているポリシーで、リクエストされたアクションが許可されていない場合、リクエストは明示的に拒否されます。この場合、拒否の最終決定が返ります。アクセス許可の境界がない場合、またはアクセス許可の境界で、リクエストされたアクションが許可されている場合、コードは続行されます。

  5. セッションポリシー – 次に、セッションポリシーを渡すことによって、プリンシパルエンティティが想定されたセッションを使用しているかどうかをコードで確認します。セッションポリシーは、AWS CLI または AWS API を使用して、ロールまたはフェデレーティッドユーザーの一時認証情報を取得する場合に渡すことができます。セッションポリシーが存在し、リクエストされたアクションが許可されていない場合、そのリクエストは明示的に拒否されます。この場合、拒否の最終決定が返ります。セッションポリシーがない場合、またはこのポリシーにより、リクエストされたアクションが許可されている場合は、コードが続行されます。

  6. アイデンティティベースのポリシー – コードを使用して、プリンシパルエンティティのアイデンティティベースのポリシーを確認します。IAM ユーザーの場合は、ユーザーポリシーや、ユーザーが属するグループのポリシーが含まれます。該当するアイデンティティベースのポリシーのステートメントで、リクエストされたアクションが許可されている場合は、エンフォースメントコードによって、許可の最終決定が返ります。リクエストされたアクションを許可するステートメントがない場合、そのリクエストは暗黙的に拒否され、拒否の最終決定がコードで返ります、

  7. エラー – 評価中に AWS エンフォースメントコードでエラーが発生すると、例外が生成され、終了します。

アイデンティティベースのポリシーおよびリソースベースのポリシーの評価の例

最も一般的なポリシータイプは、アイデンティティベースのポリシーとリソースベースのポリシーです。

Carlos のユーザー名が carlossalazar で、ファイルを Amazon S3 バケット carlossalazar-logs に保存するとします。

また、以下のポリシーを IAM ユーザー carlossalazar にアタッチするとします。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:HeadBucket" ], "Resource": "*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::carlossalazar/*", "arn:aws:s3:::carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] }

このポリシーの AllowS3ListRead ステートメントでは、アカウント内のすべてのバケットを一覧表示することを Carlos に許可します。AllowS3Self ステートメントでは、Carlos のユーザー名と同じ名前のバケットに対するフルアクセスを Carlos に許可します。DenyS3Logs ステートメントでは、名前に log が含まれている S3 バケットへのアクセスを Carlos に拒否します。

さらに、次のリソースベースのポリシー (バケットポリシー) を carlossalazar バケットにアタッチします。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Principal": { "AWS": "arn:aws:iam::111122223333:user/carlossalazar" }, "Resource": "*" } ] }

このポリシーでは、carlossalazar ユーザーのみが carlossalazar バケットにアクセスできることを指定します。

Carlos がファイルを carlossalazar-logs バケットに保存することをリクエストすると、AWS はこのリクエストに適用されるポリシーを決定します。この例では、アイデンティティベースのポリシーとリソースベースのポリシーのみが適用されます。これらは両方ともアクセス許可ポリシーです。アクセス許可の境界は適用されないため、評価ロジックは次のロジックに限定されます。


        評価フローチャート

AWS は、最初にリクエストのコンテキストに適用される Deny ステートメントの有無を確認します。アイデンティティベースのポリシーでは、Carlos に対してログ記録用の S3 バケットへのアクセスが明示的に拒否されるため、該当するステートメントが見つかります。Carlos はアクセスが拒否されます。

彼は間違いに気が付いて、ファイルを carlossalazar バケットに保存しようとします。AWS は Deny ステートメントを探しますが、1 つも見つかりません。次に、アクセス許可ポリシーを確認します。アイデンティティベースのポリシーで、このリクエストが許可されます。従って、AWS でリクエストが許可されます。どちらでもステートメントが明示的に拒否された場合、リクエストは拒否されます。

明示的な拒否と暗黙的な拒否の違い

該当するポリシーに Deny ステートメントが含まれている場合、リクエストは明示的に拒否されます。リクエストに適用されるポリシーに Allow ステートメントと Deny ステートメントが含まれている場合は、Deny ステートメントが Allow ステートメントより優先されます。リクエストは明示的に拒否されます。

該当する Deny ステートメントがなく、該当する Allow ステートメントもない場合は、暗黙的な拒否が発生します。IAM ユーザー、ロール、フェデレーティッドユーザーは、デフォルトでアクセスが拒否されされるため、アクションを実行するには明示的に許可を受ける必要があります。そうでない場合は、アクセスは暗黙的に拒否されます。

承認戦略を設計する場合、プリンシパルのリクエストを成功させるには、作成するポリシーに Allow ステートメントを含める必要があります。ただし、明示的な拒否と暗黙的な拒否の任意の組み合わせを選択できます。たとえば、次のポリシーを作成して、管理者に AWS のすべてのリソースに対するフルアクセスを許可し、請求へのアクセスを明示的に拒否することができます。別のユーザーが、この管理者に対して請求へのアクセスを許可する別のポリシーを追加しても、この明示的な拒否によってアクセスは拒否されます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] }

または、次のようなポリシーを作成し、ユーザーに対してユーザーの管理は許可するが、グループや IAM の他のリソースの管理は拒否することができます。これらのアクションは、他のサービスのアクションと同様に、暗黙的に拒否されます。ただし、これらの他のアクションを実行することを許可するポリシーを誰かがユーザーに追加した場合、アクションは許可されます。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateUser", "iam:DeleteUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:ListUsers", "iam:PutUserPolicy", "iam:UpdateUser" ], "Resource": "*" } }