IAMユーザー・グループ・ロール・ポリシーの違いと使い分け

同じIAMという名前の中で、ユーザー・グループ・ロール・ポリシーを要件から使い分けます。

この単元で学ぶこと

  • 人・集合・引受け・規則を区別する
  • 認証情報とポリシー管理方式を比較する
  • 複数の許可が残る事例を評価する

本文解説

1. 四つの役割 ユーザーは個別ID、グループはIAMユーザーの集合、ロールは引受けるID、ポリシーは規則です。四つを同じ種類の代替製品として選ぶのではなく、役割が異なる部品として組み合わせます。

2. 共通の閲覧業務 既存IAMユーザー十人へ共通権限を付けるならグループで整理できます。共通文書はカスタマー管理ポリシーとして再利用できます。グループがポリシーに置き換わるわけではなく、集合に規則を関連付ける構造です。

3. アプリのアクセス EC2アプリがS3を使う場合、IAMロールに必要なポリシーを付け、一時的認証情報を使わせます。グループはロールをメンバーとして受け入れる集合ではありません。アプリ用グループのキーを作るという案は成立しません。

4. 人のアクセス 新しい従業員アクセスではフェデレーションを検討します。既存ツールが対応しない用途のIAMユーザーとは条件が違います。一時的認証情報を使える人へ、管理しやすそうという理由で長期キーを配る必要はありません。

5. 信頼と操作 ロールを引き受けられる主体は信頼ポリシー、ロール利用後の操作は権限ポリシーです。例えば監査会社を信頼しても、監査ロールへ必要な参照権限を付ける作業は別です。両者の設定を互いの代用にしません。

6. 文書の管理方式 共通の規則を中央更新するならカスタマー管理ポリシー、特定IDへ結び付けるならインラインを比較します。AWS管理ポリシーはAWSが内容を管理します。便利さだけでなく、変更時にどこへ影響するかを確認します。

7. 認証の強さと操作範囲 MFAは本人確認を強め、最小権限は操作範囲を狭めます。パスワード・APIキー・セッショントークンも同じ物ではありません。ログイン成功、必要なAPI成功、不要なAPI拒否を分けて確認すると混同を防げます。

8. 更新後も全体を見る あるグループを外しても直接ポリシーが残ることがあります。逆に広いAllowを付けても、適用される明示的Denyは打ち消せません。一つの設定だけを根拠に成功・失敗を予測せず、実際の主体と許可元を確認します。

図解

共通閲覧とアプリを比較
同じ閲覧権限でも、利用する主体によって渡し方は異なります。

重要ポイント

  • 集合とIDと規則を区別して組み合わせる。
  • 信頼と操作権限は別。
  • 一つの許可変更だけで全権限を判断しない。

間違えやすい点

  • グループがアプリへキーを発行すると思う。
  • 管理ポリシーとロールを同じ種類のIDと扱う。
  • MFAで権限も最小になると思う。

用語解説

個別ID
誰として要求するかを識別する対象。
権限の再利用
同じ管理ポリシーを複数のIAM IDへ関連付ける運用。
長期認証情報
一時セッションと異なり、無効化や削除等まで管理する認証情報。

関連教材

参考資料

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

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