【AWS初学者向け】IAMポリシーの評価ロジックを逃げずに理解する

AWS認定試験の合格に必要な知識を確認します。

目次

結論

IAMポリシーの評価ロジックは,同一アカウントとクロスアカウントで異なります。

同一アカウントのIAM評価ロジック
クロスアカウントのIAM評価ロジック

IAMポリシーとは何か

IAMポリシーは,IAMにおける認可のフェーズにおいて具体的なアクセス許可を定義するJSONのことを指します。IAMポリシーの評価ロジックを理解するためには,IAMポリシーを理解していなければなりません。I

AWSのドキュメントでは,「アクセス許可」という用語と「権限」という用語が混用されています。両者には明確な定義の違いがある訳ではないため,差し当たりは同じ概念を指すと捉えて問題ありません。権限という用語はアクセス許可という用語を内包しているとも考えられますが,権限には許可と拒否しかないことを踏まえると,許可が拒否の裏返しであると捉えればアクセス許可という用語で権限自体を表現できてしまっているのです。

IAMポリシーはJSONで記述されますが,一つのJSONは複数のStatementから構成され,一つのStatementには複数のフィールドが定義されます。

IAMポリシーの詳細

Statementで定義されるフィールドを可視化すると,下図のようになります。

Statementで定義されるフィールドの関係性

Statementで定義されるフィールドをもう少し詳しく説明しておきます。

  • SID:IAMポリシーの名前(省略可)
  • Effect:許可(Allow)か拒否(Deny)
  • Principal:Actionの主体(省略可)
  • Action:制御する操作
  • Resource:Actionの作用先
  • Condition:さらなる条件での絞り込み

IAMポリシーの種類

IAMポリシーには,下記のような種類があります。

  1. アイデンティティベースのポリシー
    • 管理ポリシー(AWS/カスタマー)
    • インラインポリシー
  2. リソースベースのポリシー
  3. アクセス許可の境界
  4. サービスコントロールポリシー(SCP)
  5. アクセスコントロールポリシー(ACL)
  6. セッションポリシー

アクセスコントロールポリシーは,唯一JSONで記述されません。

これらを一緒くたにして理解するのは難しいので,下記のように構造化して捉えましょう。

IAMの大まかな分類

「アクセス許可の境界かSCPでガードレールを設定し,アイデンティティベースのポリシーかリソースベースのポリシーで実際のアクセス許可を制御する。オプションとして,ACLやセッションポリシーを使うことがある。」と理解しておけば十分です。アイデンティティベースのポリシーかリソースベースのポリシーで許可しても,ガードレールで許可していないとアクセスは許可されない点がポイントです。

ACLはS3やVPCに用途が限られています。セッションポリシーは,アイデンティティベースのポリシーとリソースベースのポリシーだけでは実現できない細やかな制御のために利用されます。これらはオマケと捉えましょう。また,リソースベースポリシーに含まれるVPCエンドポイントポリシーもガードレールとして機能します。

それぞれのポリシーの詳しい解説は,以下の記事をご覧ください。

評価ロジック

前提として,IAMポリシーはデフォルトでアクセスを拒否します。これを「暗黙的なDeny」といいます。対して,IAMポリシー内でAllowすることを「明示的なAllow」といい,IAMポリシー内でDenyすることを「明示的なDeny」といいます。これら三者の優先順位は,

暗黙的なDeny < 明示的なAllow < 明示的なDeny

となります。この前提のもと,各種IAMポリシーが順番に評価されていきます。これ以降,オプションとして捉えられるACLとセッションポリシーは除外して考えていきます。

IAM評価ロジックの全体像

全体像が見えたところで,詳細に踏み込んでいきましょう。IAMの評価ロジックでは,まずSCPによってOU単位でアクセス許可の上限を定めます。

SCPによるガードレール

実際にアクセス許可を定めるのは,リソースベースのポリシーとアイデンティティベースのポリシーでした。この際,SCPはアクセス許可の上限を定めるガードレールとして機能するため,SCPとリソースベースのポリシー・アイデンティティベースのポリシーはAND条件を用いて評価されます。つまり,SCPで許可されているアクセス権限のみがリソースベースのポリシーとアイデンティティベースのポリシーで許可されるということです。

アクセス許可を与えるリソースベースのポリシーとアイデンティティベースのポリシー

アイデンティティベースのポリシーは,管理ポリシーとインラインポリシーに分けられます。これらはあくまでも管理方法が異なるだけで,アクセス許可を定めるという目的は同じですので,OR条件で評価されます。

管理ポリシーとインラインポリシー

アクセス許可の境界は,アイデンティティベースのポリシーのガードレールとして機能します。SCPと同様に,アイデンティティベースのポリシーとのAND条件で評価されます。

ガードレールとしてのアクセス許可の境界

残りの観点としては,リソースベースのポリシーとアイデンティティベースのポリシーがどのように組み合わせて評価されるかですが,これは同一アカウント内でのアクセス制御とクロスアカウントでのアクセス制御で異なります。

同一アカウントの場合

同一アカウントの場合,基本思想は「単方向のアクセス許可で十分」となります。これをIAMポリシーの種類を用いて実現すると,アイデンティティベースのポリシーもしくはリソースベースのポリシーでAllowされていれば,アクセス許可が実現されることになります。

同一アカウントのIAM評価ロジック

クロスアカウントの場合

クロスアカウントの場合,基本思想は「双方向のアクセス許可が必要」となります。これをIAMポリシーの種類を用いて実現すると,アイデンティティベースのポリシーかつリソースベースのポリシーでAllowされていれば,アクセス許可が実現されることになります。

クロスアカウントのIAM評価ロジック

補足

IAMについては,下記の記事で詳しく解説しています。

シェアはこちらからお願いします!

コメント

コメントする

※ Please enter your comments in Japanese to distinguish from spam.

目次