メニュー
AWS Identity and Access Management
ユーザーガイド

IAM ポリシーの評価論理

ポリシー評価の基本

AWS サービスがリクエストを受領すると、リクエストはまず、アクセスキー ID や署名に関する情報に基づいて認証されます(Amazon S3 のような一部のサービスは、匿名ユーザーからのリクエストを許可します)。リクエストが認証に合格すると、AWS は依頼者がリクエストで示されているアクションを実行する権限を持っているかどうかを判断します。

AWS アカウントのオーナーの認証情報(ルート認証情報)を使用したリクエストが、そのアカウント内のリソースを要求している場合、リクエストは許可されます。しかし、そのリクエストが IAM ユーザーの認証情報を使用したものであったり、AWS STS によって付与された一時認証情報を使用して署名されたものである場合、AWS は 1 つ以上の IAM ポリシーで定義されたアクセス許可に基づいて、ユーザーのリクエストが正当なものであるかどうかを判断します。

注記

Amazon S3 は、アクセスコントロールリスト(ACL)およびバケットやオブジェクトに対するリソースレベルのポリシーをサポートしています。ACL やバケットレベルのポリシーを用いて確立されたアクセス許可によって、バケットでどのアクションがルートオーナーによって許可されるかが決まります。詳細については、Amazon Simple Storage Service 開発者ガイド の「アクセスポリシーのオプションを使用するためのガイドライン」を参照してください。

IAM ポリシーの AWS Organizations の影響

AWS Organizations は、ビジネスが所有する AWS アカウントをグループ化して集中管理するためのサービスです。組織内のすべての機能を有効にすると、サービス制御ポリシー (SCP) を一部またはすべてのアカウントに適用できます。これらの SCP は、これらのアカウントの IAM ユーザー、グループ、役割がアクセスできる、サービスとアクションを制限する「フィルター」または「ガードレール」として機能します。アカウントに接続されている SCP が S3 などのサービスへのアクセスを拒否した場合、そのアカウントの管理者権限を持っているユーザーも、S3 API にアクセスできません。アカウントの root ユーザーも、S3 API へのアクセスを拒否されます。

つまり、組織内のアカウントの IAMユーザーは、組織 SCP と、アカウントの管理者がユーザーにアタッチした IAM アクセス許可ポリシーの両方で許可されているアクセス許可の交わる部分のみを使用できます。言い換えると、IAM と 組織 の両方により許可されたものです。

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

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

AWS がリクエストを許可するとき、リクエストに関する下記の情報がいくつかのソースから収集されます。

  • プリンシパル(依頼者): シークレットアクセスキーに基づいて識別されます。この情報は、ルートユーザー、IAM ユーザー、フェデレーションユーザー(STS を通じて)、または引き受けられたロールを表すほか、そのプリンシパルに関連付けられた権限の集合が含まれる場合があります。

  • 環境データ: IP アドレス、ユーザーエージェント、SSL 有効化、日時など。この情報はリクエストから特定されます。

  • リソースデータ: リクエスト対象であるリソースに関連する情報です。これには、DynamoDB テーブル名、Amazon EC2 インスタンスのタグといった情報が含まれる場合があります。

これらの情報は、リクエストに由来する情報の集合であるリクエストコンテキストに集積されます。評価中、AWS はリクエストコンテキストからの値に基づいて、リクエストの許可または拒否を決定します。たとえば、リクエストコンテキストのアクションが Action エレメントのアクションと一致するかどうかが確認され、一致しない場合、リクエストは拒否されます。同様に、リクエストコンテキスト内のリソースが Resource エレメント内のリソースのいずれかと一致するかどうかが確認され、一致しない場合、リクエストは拒否されます。

Condition エレメントで使用可能なキーもこのように機能します。たとえば、以下のようなポリシーフラグメントの場合、AWS は aws:CurrentTime キーに対する最新のリクエストコンテキストの日時に基づいて、DateGreaterThanDateLessThan の比較を実行します。

Copy
"Condition" : { "DateGreaterThan" : { "aws:CurrentTime" : "2013-08-16T12:00:00Z" }, "DateLessThan": { "aws:CurrentTime" : "2013-08-16T15:00:00Z" } }

${aws:username} といったポリシー変数もこのように機能します。以下のようなポリシーフラグメントの場合、AWS はリクエストコンテキストからユーザー名を取得し、それをポリシー内の ${aws:username} が登場する場所で使用します。

Copy
"Resource": [ "arn:aws:s3:::mybucket/${aws:username}/*" ]

リクエストの許可または拒否を決定する

リクエストが提出されると、AWS サービスはそのリクエストを許可すべきか拒否すべきかを決定します。評価論理は以下のルールに基づきます。

  • デフォルトでは、すべてのリクエストが拒否されます。(一般的に、アカウント認証情報を使用してアカウントのリソースへのアクセスをリクエストをした場合は常に許可されます)。

  • 明示的な許可はこのデフォルトに優先します。

  • 明示的な拒否はすべての許可に優先します。

ポリシーが評価される順番は、評価の結果に影響しません。すべてのポリシーが評価され、結果は常に、リクエストが許可されるか拒否されるかのいずれかとなります。

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

評価フローチャート
  1. 評価は、リクエストが拒否されるという前提からスタートします。

  2. エンフォースメントコードは、リクエストに適用可能なユーザーベースおよびリソースベースのポリシーすべてを、リソース、プリンシパル、アクション、および条件に基づいて評価します。

    エンフォースメントコードによるポリシー評価の順序は重要ではありません。

  3. 前述のすべてのポリシーにおいて、リクエストに適応する明示的な拒否のインストラクションがエンフォースメントコードによって検索されます。

    適用される明示的な拒否が 1 つでも見つかると、コードは「拒否」の結果を返してプロセスが終了します。

  4. 明示的な拒否が見つからなかった場合、リクエストに適用され得る「許可」のインストラクションがないか、エンフォースメントコードによって検索されます。

    明示的な許可が 1 つでも見つかると、コードは「許可」の結果を返し、サービスはリクエストの処理を続けます。

  5. 許可が見つからない場合、最終結果は「拒否」となります。

    評価中にコードにエラーが発生すると、例外を生成して終了します。

以下の例は、広範なリソースセットへのアクセスを許可する広範なポリシーを、明示的な拒否を使用して無効にする方法を解説したものです。たとえば、test という文字列で始まる名前の AWS アカウント内において、任意の Amazon SQS キューの使用を許可するアクセス許可を IAM グループに与えたとします。

以下の図は、キューのセットを示しています。

test
で始まる名前のキューのセット

test0 と呼ばれるキューに対するグループのアクセス許可を削除するとします。以下の図は、キューのセットを示しています。

test0
を除く、test から始まる名前のキューのセット

test0 キューへのグループのアクセスを明示的に拒否するよう、別のポリシーをグループに追加するか、別のステートメントを既存のポリシーに追加することができます。test という文字列で始まる名前のその他すべてのキューに対するグループのアクセス許可はそのまま残ります。以下の図は、ポリシーの 2 つのステートメントについて解説したものです。

 許可を優先する明示的な拒否のポリシー用例

グループ内のユーザーによってキュー test0 の使用が要求された場合、明示的な拒否が許可に優先し、ユーザーはキューへのアクセスを拒否されます。

デフォルトによる拒否と明示的な拒否の違い

ポリシーがリクエストへ直接適用されていない場合、ポリシーの結果は拒否となります。たとえば、ユーザーが Amazon SQS の使用をリクエストしましたが、ユーザーに適用されている唯一のポリシーは、ユーザーが Amazon S3 を使用できると規定しているとします。この場合、リクエストは拒否されます。

ステートメントの条件が満たされていない場合も、ポリシーの結果は拒否となります。ステートメントのすべての条件が満たされている場合、ポリシーの Effect エレメントの値に基づいて、ポリシーの結果は許可または明示的な拒否のどちらかとなります。条件が満たされていない場合の対応をポリシーが指定していない場合、結果として拒否となります。

たとえば、南極大陸から来るリクエストを防ぐとします。その場合、リクエストが南極大陸から来ていないときにのみ許可を与えるポリシー(ポリシー A1 とする)を記述します。以下の図はポリシーについて解説しています。

 リクエストが南極大陸からのものでない限り、ポリシーによってリクエストが許可されます。

リクエストがアメリカから送られてきた場合、条件を満たしています (リクエストが南極大陸からのものでないため)。従って、そのリクエストは許可されます。リクエストが南極大陸から送られてきた場合、条件を満たしていないため、ポリシーの結果は拒否となります。

下の図のように、異なるポリシー(ポリシー A2 とする)を作成して南極大陸からのアクセスを明示的に拒否することもできます。

 リクエストが南極大陸からのものである限り、ポリシーによってリクエストが拒否されます。

このポリシーが南極大陸からリクエストを送信したユーザーに適用され、条件を満たした場合、ポリシーの結果は拒否となります。

デフォルトでリクエストが拒否されることと、ポリシーで明示的に拒否されることの違いは重要です。デフォルトでは、リクエストは拒否されますが、許可することによってこの拒否は無効となります。対して、ポリシーによってリクエストを明示的に拒否すると、拒否は無効とはなりません。

たとえば、リクエストが 2010 年 6 月 1 日に到着すれば許可するという別のポリシーがあるとしましょう。このポリシーが、南極大陸からのアクセスを制限するポリシーと一緒に評価された場合、どのような結果となるでしょうか。日付ベースのポリシー(ポリシー B とする)が前述のポリシー A1 および A2 と併用されている場合の結果を比較してみましょう。シナリオ 1 は、ポリシー A1 がポリシー B とともに評価されている場合、シナリオ 2 は、ポリシー A2 がポリシー B とともに評価されている場合です。以下の図は、2010 年 6 月 1 日に南極大陸からリクエストが来た場合についての結果を示しています。

デフォルトによる拒否を無効化

シナリオ 1 において、リクエストは南極大陸から送付されていない場合のみ許可され、その他の条件(南極大陸から送付されたリクエスト)はデフォルトで拒否されるため、ポリシー A1 は拒否を返します。リクエストは 2010 年 6 月 1 日に到着しているため、ポリシー B は許可を返します。ポリシー B による許可は、ポリシー A1 のデフォルトで拒否に優先するため、結果としてリクエストは許可されます。

このセクションの最初に説明したとおり、シナリオ 2 においては、ポリシー A2 は明示的な拒否を返します。再度、ポリシー B は許可を返します。ただし、ポリシー A2 による明示的な拒否は、ポリシー B の許可に優先するため、結果としてリクエストは拒否されます。