はじめる前に
- 必須AWS アカウントを持っていること
- 必須マネジメントコンソールにサインインできること
- あると良いIAM ユーザーを作成した経験（無くても進められます）
※ IAM はリージョンに関係なく使えるサービスです。コマンドラインや SSH などの操作は一切ありません。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
IAM ユーザーが 1 人や 2 人のうちは、それぞれに直接ポリシーを付けても大きな問題はありません。しかし人数が増えてくると、「この人にも同じ権限を」「あの人の権限を一括で見直したい」というとき、1 人ずつポリシーを付け外しするのは手間がかかり、付け忘れや見落としも起こりやすくなります。
そこで使うのが「IAM ユーザーグループ」です。権限（ポリシー）はグループにまとめて付けておき、ユーザーをそのグループに入れるだけで、同じ権限をまとめて渡せます。今回はこの「グループ経由で権限を渡す」という基本のかたちを体験します。
ユーザーに直接ポリシーを付けるのと何が違うの？
ユーザーが増えるたびに同じポリシーを繰り返し付ける必要がなくなります。グループに権限をまとめておけば、新しいユーザーをそのグループに入れるだけで、同じ権限をすぐに渡せます。退職や異動でその権限が不要になったときも、グループから外すだけで済みます。
1 人のユーザーが複数のグループに入ってもいいの？
はい。複数のグループに入ると、それぞれのグループに付いている権限が合算されます（足し算で広がっていくイメージです）。今回は 1 つのグループだけを扱いますが、実際の運用では役割ごとに複数のグループを使い分けることがよくあります。
IAM グループを 1 つ作成して管理ポリシーをアタッチし、その後 IAM ユーザーを 1 つ作成してこのグループに追加し、ユーザーがグループ経由で権限を持っていることをコンソール上で確認する。
つくる構成
「ユーザー」「グループ」「ポリシー」の 3 つの関係を確認します。ポリシーはグループに付き、ユーザーはそのグループに入ることで、間接的に権限を受け取ります。
要件
以下の順番で、「グループを作る → 権限を付ける → ユーザーを入れる」を行ってください。
| No | 要件 |
|---|---|
| 1 | IAM ユーザーグループを1 つ作成する（名前は自由、例：viewers）。 |
| 2 | そのグループに、閲覧のみ可能な管理ポリシー（例：ReadOnlyAccess）をアタッチする。 |
| 3 | IAM ユーザーを1 つ作成する（名前は自由、例：group-demo-user）。作成時、または作成後に手順 1 のグループへ追加する。 |
| 4 | 作成したユーザーの詳細画面で、「アクセス許可」タブにポリシーがグループ経由で表示されていることを確認する。 |
構築の進め方
「グループを先に用意してから、ユーザーをそこに入れる」という順番がポイントです。
-
マネジメントコンソールにサインインする
ブラウザで AWS マネジメントコンソールにサインインします。IAM はリージョンに関係なく使えるサービスのため、リージョンの確認は不要です。
-
IAM ユーザーグループを作成する
IAM コンソールを開き、左メニューの「ユーザーグループ」→「グループの作成」を選びます。グループ名を自由に決め（例：
viewers）、ポリシーの一覧からReadOnlyAccessを検索してチェックを入れ、グループを作成します。この時点ではユーザーはまだ入れないグループ作成時にユーザーを追加する画面も出てきますが、今回はまだユーザーを作っていないため、いったん何も選ばずに進めて構いません。次の手順でユーザーを作ってから追加します。
-
IAM ユーザーを作成する
左メニューの「ユーザー」→「ユーザーを作成」を選びます。ユーザー名を自由に決め（例：
group-demo-user）、権限の設定画面で「グループに追加」を選び、手順 2 で作ったviewersグループにチェックを入れて作成します。「ポリシーを直接アタッチする」は選ばない今回はポリシーをユーザーに直接付けず、グループ経由で渡すことが目的です。権限設定の選択肢では、必ず「グループに追加」を選んでください。
-
ユーザーの詳細画面で、グループとポリシーを確認する
作成したユーザーを開き、「グループ」タブに
viewersが表示されていることを確認します。続けて「アクセス許可」タブを開き、ReadOnlyAccessポリシーが表示されていることを確認します。ポリシーの「アタッチされたエンティティ」表示に注目「アクセス許可」タブでは、そのポリシーが「ユーザーに直接」付いているのか「グループ経由」で付いているのかが区別して表示されます。今回は「グループ経由」になっているはずです。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。
「グループに入れたはずなのに、権限がないと表示される」
グループ自体にポリシーがアタッチされているか見直しましょう。グループを作っただけでは権限は空っぽです。グループの詳細画面の「アクセス許可」タブに、ReadOnlyAccess などのポリシーが表示されているか確認してください。
「ユーザーを作ったのに、アクセス許可タブが空のまま」
ユーザー作成時に「グループに追加」を選び、対象のグループに正しくチェックを入れたか見直しましょう。ユーザーの「グループ」タブを開き、想定したグループ名が表示されているか確認してみてください。
完了チェック
要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。IAM コンソールを開いて、次を順に確かめましょう。
- 「ユーザーグループ」一覧に、作成したグループ（例：
viewers）が表示されている。 - そのグループの「アクセス許可」タブに、
ReadOnlyAccessポリシーが1 つアタッチされている。 - 「ユーザー」一覧に、作成したユーザー（例：
group-demo-user）が表示されている。 - そのユーザーの「グループ」タブに、作成したグループ名が表示されている。
- そのユーザーの「アクセス許可」タブに、ポリシーの出どころが「グループ経由」として表示されている。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- 組織に所属する人数が増えていくほど、グループ経由で権限を管理する利点はどう大きくなっていくでしょうか。
ヒント
人数が少なければ、1人ずつポリシーを付け直しても大きな手間にはなりません。しかし人数や、権限を変更する頻度が増えるとどうなるか、「個別対応の手間」と「まとめて管理する手間」を比べて考えてみましょう。 - 1 人のユーザーが複数のグループに入れることには、便利さとともにどんなリスクが考えられるでしょうか。
ヒント
複数のグループの権限は合算されるため、本人も気づかないうちに、想定より広い範囲の権限を持ってしまう可能性があります。「必要最小限の権限だけを渡す」という考え方と、どう関係してくるか考えてみましょう。 - 退職や部署異動でユーザーの役割が変わったとき、グループを使っている場合と使っていない場合で、対応の手間にどんな違いが出るでしょうか。
ヒント
グループを使っていれば、そのユーザーをグループから外す（または別のグループに入れ替える）だけで権限の見直しが完了します。直接ポリシーを付けていた場合は何が必要になるか、比較してみましょう。
後片づけ
作成したユーザーとグループを削除し、リソースを整理しましょう。
- ユーザーを削除する：IAM コンソールの「ユーザー」一覧から、作成したユーザー（例：
group-demo-user）を選び、削除します。 - グループを削除する：「ユーザーグループ」一覧から、作成したグループ（例：
viewers）を選び、削除します。
削除の順番は「ユーザー → グループ」が安全
グループの中にユーザーが残っていると、グループの削除がうまくいかないことがあります。先にユーザーを削除（またはグループから除外）してから、グループを削除する順番で進めましょう。他で使っている既存の IAM ユーザーやグループは、間違えて削除しないようにしてください。
コストに関する注意: IAM はユーザー・グループ・ポリシーの作成や利用そのものに料金はかかりません。今回の作業だけで課金が発生することはありませんが、後片づけとして不要なユーザーやグループは削除し、アカウントの中を整理しておくとよいでしょう。