なぜ整理しようと思ったのか
AWS の IAM 権限がぐちゃぐちゃになっていました。
- 過去に在籍していたエンジニアのアカウントが残ったまま
- グループを場当たり的に作っていて、どのグループが何のためのものか分からない
- 誰に何の権限が付いているのか、パッと見て分からない
今は人数が少ないので何とか回っていましたが、今後チームがスケールすることを考えると、セキュリティの意味でも今のうちに直しておかないといけないと思い、整理することにしました。
IAM とは
どのように整理したのかを話す前に、IAMの概念について整理します。
IAM（Identity and Access Management）は、AWS の中で「誰が」「何をできるか」を管理する仕組みです。アカウント（IAM ユーザー）を作り、そのアカウントが AWS で何をできるかを制限します。
認証と認可の違い
IAM を理解するうえで、まず「認証」と「認可」の違いを押さえておくと分かりやすいです。
| 意味 | 問い | |
|---|---|---|
| 認証（Authentication：オーソライゼーション） | 相手が誰なのかを確かめる | この人は誰？ |
| 認可（Authorization：オーセンティケーション） | 誰か分かったうえで、何をしてよいかを決める | この人は何ができる？ |
YouTube で例えると、
- ログインする → 認証（あなたは誰？）
- ログインした人のうち、YouTube Premium 会員にだけ広告なし再生などのプレミアム機能を提供する → 認可（あなたは何ができる？）
という関係です。IAM の「ポリシー」は、この認可の部分を担当します。
最小権限の原則が大切
IAM で一番大事なのは「最小権限の原則」です。できることは、その人の仕事に必要な最小限にします。
「気をつけて操作すれば大丈夫」という運用ではなく、そもそもできないようにしておくことが事故防止につながります。人は必ずミスをするので、ミスをしても壊せない状態にしておくのが一番安全です。
IAM グループ
IAM ユーザー一人ひとりに個別にポリシー（権限）を付けていくと、人が増えるほど管理が難しくなります。
- Aさんにはこのポリシーと、あのポリシー
- Bさんにはこのポリシーだけ、でも別のポリシーも個別に付いている…
という状態になると、誰に何ができるのかを把握できなくなります。
そこで使うのが IAM グループ です。グループにポリシーを付けて、ユーザーをグループに入れることで、「この人はどのグループに所属しているか」だけを見れば権限が分かるようになります。
ポリシーとロールの違い
最初は混乱しやすいところです。
| 何か | 誰に付ける | |
|---|---|---|
| ポリシー | 「何をしてよいか」を書いた JSON の文書 | IAM ユーザー・グループ・ロール |
| ロール | AWS のリソース（EC2・Lambda など）が一時的に借りる「身分」 | EC2・Lambda などの AWS リソース（他のサービスやアカウントが引き受けることもある） |
ざっくり言うと、
- **人（IAM ユーザー）**には、ポリシーを付ける
- AWS のリソース（EC2 や Lambda）には、ロールを割り当てる。ロールにもポリシーを付けて、そのリソースが何をできるかを決める
という使い分けです。たとえば「Lambda から S3 に画像を保存する」なら、Lambda に割り当てたロールに「S3 に書き込める」ポリシーを付けます。
やったこと
以下の順番で進めました。
- 不要な IAM アカウントの削除
- IAM グループの整理
- IAM ポリシーの整理
- IAM ロールの整理
1. 不要な IAM アカウントの削除
過去に在籍していたエンジニアのアカウントや、必要以上に Admin 権限が付いているアカウントを整理しました。
最近は AI の CLI（Claude Code など）を使って、非エンジニアでも AWS を操作できるようになっています。便利な反面、書き込み権限が付いたアカウントを AI 経由で誰でも使える状態は特に危ないので、ここはしっかり整理する必要がありました。
使われているかどうかは、次の情報で判断しました。
- 認証情報レポート（IAM → 認証情報レポート）: 各ユーザーのパスワード・アクセスキーの最終使用日が CSV で取れる
- アクセスキーの最終使用日: どのサービスで最後に使われたかも分かる
- CloudTrail: 直近 90 日の操作履歴
削除するときは、念のためユーザーに付いていたポリシーなどを JSON でバックアップしてから消しました。
また、残したユーザーには Type=human（人）/ Type=resource（システム用）のタグを付けました。IAM ユーザーには説明欄が無いので、タグで「人のアカウントなのか、システムが使うアカウントなのか」「誰のものか・何に使うのか」を書いておくと、後から見た人が迷いません。
2. IAM グループの整理
不要なグループは削除し、IAM ユーザーに個別にポリシーを付けるのではなく、グループに入れてポリシーを付けることに統一しました。これで、「どのグループに所属しているか」だけを気にすればよくなります。
| グループ名 | 役割 |
|---|---|
Admin |
すべての操作ができる管理者 |
developers |
開発者。開発環境に必要な操作だけできる |
analysts |
分析担当。分析用 DB に接続できる |
operators |
運用担当。すべてのリソースを読み取れる + 本番 DB を操作できる |
ポイントは、グループ名は役割で付けることです。サービス名やプロジェクト名を入れすぎると、具体的すぎて逆に分かりづらくなりますし、外から見たときにサービス構成を推測されやすくなります。
※サービスが多岐にわたる場合はこの限りではないです。
こうすることで、「この人は developers だから、開発環境だけ触れる」と一目で分かるようになりました。
3. IAM ポリシーの整理
IAM アカウントを消したことで、どこにも付いていない（使われていない）ポリシーが出てきたので、それも整理しました。
個人的に、ポリシーは多すぎると管理が難しいと感じています。ポリシーは JSON を開いて中身を見ないと、何ができるのかが分からないからです。なので、
- AWS 管理ポリシー（
ReadOnlyAccessなど）で足りるならそれを使う - 自分で作る（カスタマー管理ポリシー）のは本当に必要なものだけにする
という方針にしました。
4. IAM ロールの整理
ロールもポリシーと同じで、多すぎると管理できなくなるので、使われていないものを削除しました。
ロールは「最終使用日」が IAM のコンソールで確認できるので、それを目安にしました。ただし、最終使用日が古くても、Lambda などに紐付いていて今後使われるロールがあるので、消す前に「どのリソースが使っているか」を必ず確認しました。
まとめ
- 認証は「誰か」、認可は「何ができるか」。IAM のポリシーは認可を担当する
- 最小権限の原則: 気をつけるのではなく、そもそもできないようにする
- 人への権限はグループ経由で付ける。所属グループを見れば権限が分かる状態にする
- グループ名は役割で付ける
- ポリシー・ロールは本当に必要なものだけ残す。多いと JSON を読まないと分からなくなる
- 消す前に「使われているか」を最終使用日・CloudTrail・紐付いているリソースで確認する
感想
権限まわりはずっと気になっていましたが、プロダクトをとにかく前に進めるために開発していたら、おざなりになってしまっていました。AWS の設定を引き継いだこともあり、ぐちゃぐちゃな状態になっていました。
一度自分で整理してみると、自分たちの AWS の構造を理解しながら進められるので、理解するという意味でも整理するのが良いと思います。
コードで言うと、リファクタリングが整理にあたると思います。リファクタリングも AI に「リファクタして」と言うだけではなく、自分でちゃんと理解してやるのが大事ですね。
