AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法 - AWS Identity and Access Management

AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法

AWS エンフォースメントコードは、AWS に送信されるリクエストを許可するか拒否するかどうかを決定します。AWS は、リクエストコンテキストに適用されるすべてのポリシーを評価します。AWS ポリシー評価ロジックの概要を次に示します。

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

  • リクエストが許可されるには、以下の評価ロジックに従って、ポリシー、または一連のポリシーによって明示的に許可される必要があります。

  • 明示的な拒否は明示的な許可をオーバーライドします。

次のフローチャートは、単一アカウントアクセスとクロスアカウントアクセスの両方の決定方法の詳細を示しています。

評価フローチャート

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

  • Organizations RCP – エンフォースメントコードは、リクエストに適用される AWS Organizations リソースコントロールポリシー (RCP) を評価します。RCP は、RCP がアタッチされているアカウントのリソースに適用されます。エンフォースメントコードが RCP で該当する Allow ステートメントを見つけられない場合、エンフォースメントコードは Deny の最終決定を返します。RCP が有効化されると、RCPFullAWSAccess という AWS マネージドポリシーが自動的に作成され、ルート、各 OU、AWS アカウント を含む組織内のすべてのエンティティにアタッチされることに注意してください。 RCPFullAWSAccess はデタッチできないため、常に Allow ステートメントになります。RCP がない場合、または RCP により、リクエストされたアクションが許可された場合は、エンフォースメントコードの評価が続行されます。

  • Organizations SCP - エンフォースメントコードは、リクエストに適用する AWS Organizations サービスコントロールポリシー (SCP) を評価します。SCP は、SCP がアタッチされているアカウントのプリンシパルに適用されます。エンフォースメントコードが SCP で該当する Allow ステートメントを見つけられない場合、エンフォースメントコードは Deny の最終決定を返します。SCP がない場合、または SCP により、リクエストされたアクションが許可された場合は、エンフォースメントコードが続行されます。

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

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

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

    • 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

  • ID ベースのポリシー – エンフォースメントコードは、プリンシパルのID ベースのポリシーをチェックします。IAM ユーザーの場合は、ユーザーポリシーや、ユーザーが属するグループのポリシーが含まれます。ID ベースのポリシーが無いか、ID ベースのポリシーにリクエストされたアクションを許可するステートメントがない場合、そのリクエストは暗黙的に拒否され、エンフォースメントコードは Deny の最終決定を返します。該当する ID ベースのポリシーのステートメントで、リクエストされたアクションが許可されている場合、コードの評価は続行されます。

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

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

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

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

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

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