グループを理解する

この単元で学ぶこと

• グループのメンバーと用途を説明する
• 所属変更と権限の評価を区別する
• グループと他のIAM要素を比較する

本文解説

1. 共通権限の管理 監査担当のIAMユーザーが五人いる場合、同じ閲覧権限を個別に複製するよりAuditグループへまとめると管理しやすくなります。グループへポリシーを付けることで所属ユーザーがその許可の対象になります。

2. 入れられるもの IAMグループのメンバーはIAMユーザーです。別のグループを中に入れる入れ子構造や、IAMロールをメンバーにする構造は使えません。組織図のように階層化するOUと混同しないでください。

3. 複数所属 一人がDevelopersとReadOnlyの複数グループへ所属することはできます。ReadOnlyへ入れたから他グループの更新許可が消えるわけではありません。適用される許可と拒否を全体で評価します。

4. 明示的拒否 あるグループに操作のAllowがあり、別の適用ポリシーに同じ要求の明示的Denyがあれば拒否されます。許可を持つグループの数で多数決する仕組みではありません。狭いAllowの追加だけで広いAllowを取り消そうとしないでください。

5. グループはログインしない グループに共通のパスワードやアクセスキーは作りません。各ユーザーが自分の認証情報を使います。また、資源ポリシーのPrincipalでグループを認証主体として指定することもできません。

6. 異動時の処理 開発者が監査担当へ異動したら、旧グループから外し新しいグループへ追加します。ただし直接付けたポリシーや別グループの許可が残ることがあります。必要な操作が成功し不要操作が拒否されるかまで確認します。

7. 全員用の集合 全ユーザーが自動で入る既定グループはありません。全員向けグループを作っても、新しいユーザーを追加する運用が必要です。グループ名をAllUsersと付けただけで自動加入にはなりません。

8. 適用範囲 グループは既存IAMユーザーの整理に有効ですが、EC2アプリへ一時的認証情報を渡す役割ではありません。アプリにはロール、人の新しいアクセス管理にはIdentity Center等を検討します。IAMグループとIdentity Center側のグループも別の管理対象です。

図解

重要ポイント

• メンバーはIAMユーザーのみ。
• 複数所属できるが狭い許可は広い許可を消さない。
• グループはログイン主体ではない。

間違えやすい点

• グループを入れ子にする。
• ReadOnlyへの追加で既存の更新権限が消えると思う。
• 退会した一つのグループだけで全権限を判断する。

用語解説

グループメンバー

IAMグループへ所属させたIAMユーザー。

直接ポリシー

グループを経由せずユーザー等へ関連付けたポリシー。

Principal

資源ベースのポリシー等で対象となる主体を示す要素。

関連教材

• ロールを理解する
• IAMユーザーを理解する
• ポリシーを理解する
• IAMユーザー・グループ・ロール・ポリシーの全体像
• IAMユーザー・グループ・ロール・ポリシーの違いと使い分け