ポリシーの評価論理 - AWS Identity and Access Management

ポリシーの評価論理

プリンシパルが AWS Management Console、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 でのポリシーとアクセス許可」をご参照ください。AWS がクロスアカウントアクセスのポリシーを評価する方法については、「クロスアカウントポリシーの評価論理」を参照してください。

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

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

  3. IAM アクセス許可の境界 – アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティ (ユーザーまたはロール) に付与できるアクセス許可の上限を設定する高度な機能です。エンティティのアクセス許可の境界を設定した場合、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクセス許可のみ実行できます。アクセス許可の境界で暗黙的に拒否しても、リソースベースのポリシーによって付与されるアクセス許可は制限される場合もあります。詳細については、このトピックの後半の「アカウント内でのリクエストの許可または拒否の決定」を参照してください。

  4. AWS Organizations サービスコントロールポリシー (SCP) – Organizations 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 エンティティに対する organizations:DescribeOrganization アクションのアクセス許可が必要です。Organizations コンソールでオペレーションを実行するには、追加のアクセス許可が必要です。SCP が特定のリクエストへのアクセスを拒否しているかどうかを確認する、または有効なアクセス権限を変更するには、AWS Organizations 管理者に連絡してください。

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

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

  • デフォルトでは、フルアクセスを持つ AWS アカウントのルートユーザー 以外は、すべてのリクエストが暗示的に拒否されます。

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

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

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

以下のフローチャートは、決定が下されるまでの詳細な流れを示しています。このフローチャートでは、リソースベースのポリシーと他のタイプのポリシーでの暗黙的な拒否による影響はカバーしていません。

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

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

  3. リソースベースのポリシー - 同じアカウント内でも、リソースにアクセスするプリンシパルのタイプと、リソースベースのポリシーで許可されるプリンシパルに応じて、リソースベースのポリシーはポリシーの評価に異なる影響を与えます。リソースベースのポリシーの Allow は、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーに潜在的な拒否があったとしても、プリンシパルのタイプに応じて最終的には Allow に決定されます。

    ほとんどのリソースでは、ID ベースのポリシーまたはリソースベースのポリシーのいずれかでプリンシパルを明示的に許可するだけで、アクセス権を付与できます。IAM ロール信頼ポリシーKMS キーポリシーは、プリンシパルへのアクセスを明示的に許可する必要があるため、このロジックの例外です。

    指定されたプリンシパルが IAM ユーザー、IAM ロール、またはセッションプリンシパルである場合、リソースベースのポリシーのロジックは他のポリシータイプとは異なります。セッションプリンシパルには、IAM ロールセッションまたはIAM フェデレーティッドユーザーセッションが含まれます。リソースベースのポリシーが、リクエストを作成している IAM ユーザーまたはセッションプリンシパルに直接アクセス許可を付与する場合、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーで暗黙的な拒否が最終的な決定に影響を与えることはありません。

    次の表は、ID ベースのポリシー、アクセス許可の境界、セッションポリシーで暗黙的な拒否が存在する場合に、さまざまなプリンシパルタイプに対する、リソースベースのポリシーの影響を理解するのに役立ちます。

    リソースベースのポリシーと他のポリシータイプでの暗黙的な拒否 (同じアカウント)
    リクエストを実行するプリンシパル リソースベースのポリシー ID ベースのポリシー アクセス許可の境界 セッションポリシー 結果 理由
    IAM ロール 該当しない 該当しない 該当しない 該当しない 該当しない ロール自体がリクエストを行うことはできません。リクエストは、ロールを引き受けた後に、ロールセッションで行われます。
    IAM ロールセッション ロール ARN を許可する 暗黙的な拒否 暗黙的な拒否 暗黙的な拒否 DENY アクセス許可の境界とセッションポリシーは、最終決定の一部として評価されます。いずれかのポリシーで暗黙的な拒否があると、DENY と決定されます。
    ロールセッション ARN を許可する 暗黙的な拒否 暗黙的な拒否 暗黙的な拒否 許可 アクセス許可は、セッションに直接付与されます。他のポリシータイプは、決定に影響しません。
    IAM ユーザー IAM ユーザーの ARN を許可する 暗黙的な拒否 暗黙的な拒否 該当しない 許可 アクセス許可は、ユーザーに直接付与されます。他のポリシータイプは、決定に影響しません。
    IAM フェデレーティッドユーザー (GetFederationToken) IAM ユーザーの ARN を許可する 暗黙的な拒否 暗黙的な拒否 暗黙的な拒否 DENY アクセス許可の境界またはセッションポリシーで暗黙的な拒否があると、DENY と決定されます。
    IAM フェデレーティッドユーザーセッション ARN を許可する 暗黙的な拒否 暗黙的な拒否 暗黙的な拒否 許可 アクセス許可は、セッションに直接付与されます。他のポリシータイプは、決定に影響しません。
    ルートユーザー ルートユーザーの ARN を許可する 該当しない 該当しない 該当しない 許可 ルートユーザーは、AWS アカウント のすべてのリソースに完全かつ無制限にアクセスできます。AWS Organizations のアカウントのルートユーザーへのアクセスを制御する方法については、「Organizations ユーザーガイド」の「サービスコントロールポリシー (SCP)」を参照してください。
    AWS サービスプリンシパル AWS サービスプリンシパルを許可する 該当しない 該当しない 該当しない 許可 リソースベースのポリシーが、AWS サービスプリンシパルにアクセス許可を直接付与する場合、他のポリシータイプは決定に影響しません。
    • IAM ロール— IAM ロール ARN にアクセス許可を与えるリソースベースのポリシーは、アクセス許可の境界またはセッションポリシーの暗黙的な拒否によって制限されます。ロール ARN はプリンシパル要素または aws:PrincipalArn 条件キーで指定できます。どちらの場合も、リクエストを行うプリンシパルは IAM ロールセッションです。

      アイデンティティベースのポリシーに明示的な拒否が含まれている場合を除き、アクセス許可の境界とセッションポリシーは、プリンシパル要素で、ワイルドカード (*) を含む aws:PrincipalArn 条件キーを使用して付与されたアクセス許可を制限することはありません。詳細については、「IAM ロールプリンシパル」を参照してください。

      ロール ARN の例

      arn:aws:iam::111122223333:role/examplerole
    • IAM ロールセッション — 同じアカウント内で、IAM ロールセッション ARN にアクセス許可を与えるリソースベースのポリシーは、引き受けたロールセッションに、直接アクセス許可を与えます。セッションに直接付与されるアクセス許可は、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーの暗黙的な拒否によって制限されません。ロールを引き受けてリクエストを行う場合、リクエストを行うプリンシパルは IAM ロールセッション ARN であり、ロールそれ自体の ARN ではありません。詳細については、「ロールセッションプリンシパル」を参照してください。

      ロールセッション ARN の例

      arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
    • IAM ユーザー — 同じアカウント内では、IAM ユーザー ARN (フェデレーティッドユーザーセッションではない) へのアクセス許可を与えているリソースベースのポリシーは、ID ベースのポリシーまたはアクセス許可の境界による、暗黙的な拒否によって制限されません。

      IAM ユーザー ARNの例

      arn:aws:iam::111122223333:user/exampleuser
    • IAM フェデレーティッドユーザーセッション — IAM フェデレーティッドユーザーセッションは、GetFederationToken を呼び出して作成されたセッションです。フェデレーティッドユーザーがリクエストを行う場合、リクエストを行うプリンシパルはフェデレーティッドユーザー ARN であり、フェデレーションした IAM ユーザーの ARN ではありません。同じアカウント内で、フェデレーティッドユーザー ARN にアクセス許可を与えるリソースベースのポリシーは、セッションに直接アクセス許可を与えます。セッションに直接付与されるアクセス許可は、ID ベースのポリシー、アクセス許可の境界、またはセッションポリシーの暗黙的な拒否によって制限されません。

      ただし、リソースベースのポリシーがフェデレーションした IAM ユーザーの ARN にアクセス許可を与える場合、セッション中にフェデレーティッドユーザーによって行われたリクエストは、アクセス許可の境界またはセッションポリシーの、暗黙的な拒否によって制限されます。

      IAM フェデレーティッドユーザーセッション ARN の例

      arn:aws:sts::111122223333:federated-user/exampleuser
  4. アイデンティティベースのポリシー – コードを使用して、プリンシパルのアイデンティティベースのポリシーを確認します。IAM ユーザーの場合は、ユーザーポリシーや、ユーザーが属するグループのポリシーが含まれます。ID ベースのポリシーが無いか、ID ベースのポリシーにリクエストされたアクションを許可するステートメントがない場合、そのリクエストは暗黙的に拒否され、拒否の最終決定がコードで返ります。該当する ID ベースのポリシーのステートメントで、リクエストされたアクションが許可されている場合は、コードが継続します。

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

  6. セッションポリシー — その後、コードは、プリンシパルがセッションプリンシパルかどうかをチェックします。セッションプリンシパルには、IAM ロールセッションか IAM フェデレーティッドユーザーセッションが含まれます。プリンシパルがセッションプリンシパルでない場合、エンフォースメントコードは最終決定で許可を返します。

    セッションプリンシパルの場合、コードは、セッションポリシーがリクエストによって渡されたかどうかをチェックします。セッションポリシーは、AWS CLI または AWS API を使用して、ロールまたは IAM フェデレーティッドユーザーの一時認証情報を取得する場合に渡すことができます。

    • セッションポリシーが存在し、リクエストされたアクションが許可されていない場合、そのリクエストは暗示的に拒否されます。この場合、拒否の最終決定が返ります。

    • セッションポリシーがない場合、プリンシパルがロールセッションかどうかをコードがチェックします。プリンシパルがロールセッションだった場合、リクエストは許可になります。それ以外の場合は、リクエストは暗黙的に拒否され、コードは最終決定で拒否を返します。

    • セッションポリシーが存在し、リクエストされたアクションが許可されている場合は、エンフォースメントコードは最終決定で許可を返します。

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

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

最も一般的なポリシータイプは、アイデンティティベースのポリシーとリソースベースのポリシーです。リソースへのアクセスがリクエストされると、同じアカウント内の少なくとも 1 つの許可について、AWS はポリシーによって付与されたすべてのアクセス許可を評価します。これらのポリシーのいずれかが明示的に拒否された場合、許可は無効になります。

重要

同じアカウント内の ID ベースのポリシーまたはリソースベースのポリシーの一方がリクエストを許可し、他方が許可しない場合でも、リクエストは許可されます。

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

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

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "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*" } ] }

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

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

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

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

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

評価フローチャート

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

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

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

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

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

承認戦略を設計する場合、プリンシパルのリクエストを成功させるには、作成するポリシーに Allow ステートメントを含める必要があります。ただし、明示的な拒否と暗黙的な拒否の任意の組み合わせを選択できます。

例えば、許可されたアクション、暗黙的に拒否されたアクション、および明示的に拒否されたアクションを含む、次のポリシーを作成できます。AllowGetList ステートメントは、Get または List プレフィックスで始まる IAM アクションに対して、読み取り専用のアクセスを許可します。iam:CreatePolicy など、IAM の他のすべてのアクションは、暗黙的に拒否されます。DenyReports ステートメントは、iam:GetOrganizationsAccessReport などのReport サフィックスを含むアクションへのアクセスを拒否することで、IAM レポートへのアクセスを明示的に拒否します。誰かがこのプリンシパルに別のポリシーを追加して、iam:GenerateCredentialReport などのIAM レポートへのアクセス許可を付与した場合は、この明示的拒否のために、レポート関連のリクエストは引き続き拒否されます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowGetList", "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": "*" }, { "Sid": "DenyReports", "Effect": "Deny", "Action": "iam:*Report", "Resource": "*" } ] }