IAMユーザー・グループ・ロール・ポリシーのシナリオ判断

監査担当の異動、EC2への権限付与、キーの廃止という独立した事例からIAMの使い分けを判断します。

この単元で学ぶこと

  • 主体と認証方式を事例から選ぶ
  • 必要なポリシーの種類を特定する
  • 権限が残る原因を調べる

本文解説

1. 開発者の異動 AさんをDevelopersからAuditへ移したのに更新APIが成功したとします。Auditへの所属だけでReadOnlyになったとは断定できません。直接付けたポリシーや別グループに残る許可を調べ、不要な経路を整理します。

2. 共通権限の更新 十人分の同じインライン文書を個別編集しているなら、共通規則をカスタマー管理ポリシーで再利用する方法を考えます。ポリシーの変更がどのグループやロールへ反映されるかも確認します。中央更新は影響範囲の把握とセットです。

3. EC2の秘密値 EC2上のアプリがソースコードに長期キーを持っていたら、ロールの一時的認証情報を利用する設計を検討します。アプリに必要なのがreports/読取りだけなら、その範囲へ絞ります。秘密値を別ファイルへ移すだけでは長期キー配布の問題は残ります。

4. 引受け成功と読取り失敗 ロールを引き受けることは成功したがS3の読取りが拒否された場合、操作権限側を調べます。信頼ポリシーだけを広くする変更は不要な引受け主体を増やすおそれがあります。まず失敗した操作と対象を特定します。

5. 期限切れ 一時的認証情報を固定設定にコピーしたアプリが後で失敗した場合、期限と更新経路を確認します。管理者ポリシーを付けることは、期限切れ認証情報の更新の代わりにはなりません。認証の失敗と認可の失敗を分けます。

6. 従業員の開始 複数アカウントへ入る新入社員には、一元管理とフェデレーションを検討します。各アカウントへ別々の長期ユーザーを必ず作るという設計に固定しません。業務権限は本人確認の仕組みとは別に限定します。

7. 廃止漏れ 退職者のコンソールパスワードだけ止めた場合、API用キーや別アクセス経路も確認します。ユーザー名が一覧に残るかだけでは判断できません。利用状況を調べ、停止してよい認証情報と業務への影響を整理します。

8. 判断結果を試す 想定した主体が必要な資料を読めて、更新や削除は拒否されることを確かめます。適用される明示的Denyが原因ならAllowを増やすだけでは解決しません。実際の主体、認証情報、操作、資源を記録して切り分けます。

図解

AccessDeniedの切分け
認証、引受け、実際の資源操作のどこで失敗したかを区別します。

重要ポイント

  • 事例の主体と失敗段階を特定する。
  • 信頼と操作権限のどちらを直すかを区別する。
  • 異動・退職では全ての許可と認証経路を確認する。

間違えやすい点

  • 期限切れを管理者権限追加で直そうとする。
  • S3拒否を信頼ポリシーの全開放で直す。
  • パスワード停止だけで全アクセス廃止済みと考える。

用語解説

認証経路
コンソールやAPI等、どの認証情報で接続するかの経路。
残存許可
一つの設定変更後も他のポリシー等から残る許可。
影響範囲
共通ポリシーの変更等が作用する主体や業務の範囲。

関連教材

参考資料

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

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