IAMポリシー評価ロジックのシナリオ判断

IDポリシー、境界、セッションの具体的な許可集合を読み、資源側付与がある場合は前提を切り替えて考えます。

この単元で学ぶこと

条件付きの許可集合を計算する
拒否の原因となる層を特定する
資源側付与と委任の例外を点検する

本文解説

1. 拒否の材料を集めるアプリからS3操作が拒否されたら、実際のロールセッション、API、オブジェクトARN、要求条件を記録します。開発者が自分のユーザーで試して成功しても、アプリと同じ評価条件とは限りません。

2. 和と共通部分資源側付与も他制限もないユーザーが、ポリシーAでGetObject、BでPutObjectを許可されている場合は両方が候補です。そこへGetObjectだけのboundaryを加えるとGetObjectだけになります。狭いID Allowとboundaryを同じ作用だと思わないことが重要です。

3. セッションで絞る IDがGetObjectとPutObject、boundaryが両方、セッションポリシーがPutObjectだけを許す例では、資源側付与や他制限がなければPutObjectだけです。セッション側でDeleteObjectを足してもIDにない操作を拡張できません。

4. 明示的Denyを読む GetObjectとPutObjectのAllowがあり、PutObjectへの明示的DenyがあればGetObjectだけが残ります。許可文を多数追加してもDenyは多数決で負けません。ただしDeny文に条件があればその条件の一致を調べます。

5. Conditionの不一致 Allowが特定の条件を要求していて実要求が満たさなければ、その文は許可根拠になりません。拒否原因が条件なのにResourceを広げる変更をしても、必要な要求を正しく許可することにはなりません。

6. 資源側付与を見つける共通部分の計算と結果が違う場合、同一アカウントの資源ポリシーにユーザーARNやセッションARNへの直接付与がないか確認します。暗黙的拒否の作用はPrincipal種別で異なるため、ID・境界だけを見て結論を出しません。

7. 境界の運用権限開発者に境界付きロールを作らせても、後で境界を外せる権限があれば設計意図を破る経路になります。より強い別ロールのPassRoleや資源側許可変更も含めて確認します。境界の装着を作成時に見るだけでは不十分です。

8. 成功と失敗を再現許可した参照と拒否すべき更新を同じ主体・対象条件で試します。実験の前提に資源側Allowなしと書いた場合は、その条件が実環境でも成立するか確認します。機械的な集合計算は明示した条件に対する答えであって、全AWS要求の万能式ではありません。

図解

セッションでさらに限定 — Get/Putはこの図でGetObject/PutObjectを示します。

重要ポイント

IDのAllowの和と境界の共通部分を区別する。
セッション制限でIDの権限は拡張できない。
計算前提と実際のPrincipalを照合する。

間違えやすい点

Denyを多くのAllowで覆せると思う。
条件不一致を資源範囲の拡大だけで解消する。
境界の除去権限を残したまま委任を完了とする。

用語解説

許可集合: 特定の前提の下で許容される操作群。
評価コンテキスト: 主体・操作・資源・条件等、要求判定に使う情報。
委任管理: 権限を制限した上で他の担当者にID作成等を任せる運用。

参考資料

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

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