IAMポリシー評価ロジックを理解する

許可の付与と上限を分け、資源ポリシーのPrincipalによる例外も含めてIAM評価を読み解きます。

この単元で学ぶこと

  • 許可と制限ポリシーの役割を区別する
  • 明示した前提で操作可否を計算する
  • 資源側付与と委任の境界を確認する

本文解説

1. 要求を特定する IAM評価では、誰のセッションがどのActionをどのResourceへ実行し、条件が何かを先に確認します。同じユーザーでも対象資源や要求経路が変われば結果は変わり得ます。AccessDeniedという表示だけで原因を一つに決めません。

2. 付与するポリシー IDベースのポリシーはユーザーやロール等に付け、資源ベースのポリシーはバケット等に付けます。後者はPrincipalも確認します。他の制限を除いた複数IDポリシーのAllowは合わせて評価でき、一つの狭いAllowが別の広いAllowを消すわけではありません。

3. 境界は上限 Permissions boundaryはIDベースの付与の最大範囲を制限し、単独では許可しません。資源側Allowがない例でIDがGetObjectとPutObject、境界がGetObjectのみなら、許されるのはGetObjectだけです。和集合で広げてはいけません。

4. セッションと組織 セッションポリシーはロールのIDベース許可をさらに制限します。SCPは対象メンバー主体の組織側の上限です。これらの単純な共通部分を考える例では、資源側の直接付与や他の制限がないことを明示します。

5. 明示的拒否 適用される明示的DenyはAllowに優先します。条件がある文は条件まで一致するかを確認します。条件に合わないAllowが一つ存在するだけでは、実際の要求を許可する根拠になりません。

6. 資源側の直接付与 同一アカウントの資源ポリシーでIAMユーザーARNへ直接与える許可は、IDポリシーや境界の暗黙的拒否に制限されません。ロールARNへの付与は境界やセッションの暗黙的拒否に制限されます。ロールセッションARNへの直接付与はまた異なり、三つを同じ式に押し込めません。

7. セッションARNの注意 同一アカウントでロールセッションARNへ直接与えた許可は、ID・境界・セッションの暗黙的拒否には制限されません。しかし適用される明示的Denyや組織側制限を無視できる意味ではありません。ARNの種類とポリシー配置を具体的に読みます。

8. 委任を設計する 開発者へロール作成を任せるなら指定境界の装着を強制し、境界の除去・変更や非承認ロールへのPassRole等も点検します。境界が付いているという事実だけで全経路の権限昇格防止を保証せず、資源側付与も含む反証テストを行います。

図解

単純化したID付与の例
この共通部分の図を、資源ポリシーの全てのPrincipal種別へ一律には適用しません。

重要ポイント

  • 付与と上限を区別する。
  • 共通部分の例は資源側Allowなし等の前提を読む。
  • PrincipalのARN種別で暗黙的拒否の作用が異なる。

間違えやすい点

  • boundaryだけで操作が許可されると思う。
  • 全資源ポリシーを一律に境界との共通部分へする。
  • 暗黙的拒否の例外で明示的Denyも迂回できると思う。

用語解説

Permissions boundary
IAM IDへのIDベース許可の最大範囲を定める境界。
暗黙的拒否
適用される許可が不足していることによる拒否。
ロールセッションARN
引受け後の特定セッションを識別するARNで、ロール自体のARNとは異なる。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。