こんにちは、かつコーチです。
前の記事でIAMユーザーを作成してMFAを設定しましたが、実はIAMには「ユーザー」以外にも「グループ」「ロール」「ポリシー」という重要な要素があります。
「用語がいくつも出てきて、それぞれの違いがよく分からない」という声を、これまで受講生の方からたくさんいただいてきました。
私自身も学び始めのころ、この4つの言葉を混同していて、EC2にS3へのアクセス権限を渡そうとして何時間も設定に苦しんだ経験があります。
この記事では、IAMを構成する4つの要素それぞれの役割と、それらがどう関係し合っているのかを整理して解説します。
この関係性さえ理解してしまえば、AWSの権限まわりのつまずきは大きく減らせます。
IAMを構成する4つの要素
ユーザー：個人に紐づく認証情報
IAMユーザー（AWSを操作する個人・システムに紐づく認証情報です）は、前回の記事で作成した通り、社員証に例えられる存在です。
1人の人間（または1つのアプリケーション）が1つのIAMユーザーを持ち、そのユーザーに対して「何ができるか」を設定していきます。
グループ：ユーザーをまとめる箱
IAMグループ（複数のIAMユーザーをまとめて権限を管理する箱のような仕組みです）は、同じ役割を持つユーザーをひとまとめにする仕組みです。
会社に例えるなら、「営業部」「開発部」のような部署にあたります。
部署ごとに「入れる部屋」が決まっているように、グループごとにアクセスできるAWSサービスの範囲を決めておけば、そのグループに所属するユーザー全員に、同じ権限が一括で適用されます。
新しいメンバーが増えたときも、個別に権限を設定する必要がなく、該当のグループに追加するだけで済みます。
ロール：人ではなくAWSリソースに与える権限
IAMロール（人ではなく、EC2などのAWSリソースやサービスに一時的に権限を貸し出す仕組みです）は、4つの要素の中で最も理解しにくい部分です。
ユーザーやグループが「人間用の社員証」だとすれば、ロールは「来客用の一時的な入館証」に近いイメージです。
ロールには固定のパスワードやアクセスキーは存在せず、必要なときだけ一時的な認証情報が発行される仕組みになっています。
ポリシー：権限の中身を定義する文書
IAMポリシー（「誰が」「どのサービスに」「どんな操作を」許可・拒否するかを定義したJSON文書です）は、ユーザー・グループ・ロールいずれにもアタッチできる、権限の中身そのものです。
社員証に例えるなら、「この社員証で開けられる部屋のリスト」を記した規則書に当たります。
ポリシーの具体的な書き方は次回の記事で扱いますが、今の段階では「権限のルールブックがポリシーである」という理解で十分です。
なぜロールが必要なのか
EC2にS3への権限を渡す場面で考える
ここで、なぜユーザーだけでなくロールが必要なのかを、具体例で考えてみましょう。
たとえば、EC2上で動かしているアプリケーションから、S3に画像をアップロードしたいとします。
このとき「ダメな例」としてやってしまいがちなのが、IAMユーザーのアクセスキー・シークレットキーを、EC2インスタンス内の設定ファイルに直接書き込んでしまう方法です。
# ❌ Before：EC2内の設定ファイルにアクセスキーを直書きする
AWS_ACCESS_KEY_ID=AKIAxxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
この方法には大きな問題があります。
万が一このEC2インスタンスに侵入されたり、設定ファイルが誤って公開リポジトリにコミットされたりすると、アクセスキーがそのまま流出してしまいます。
しかも、このアクセスキーには有効期限がないため、漏洩に気づかない限り悪用され続けるリスクがあります。
ロールを使えば固定のキーを持たずに済む
これに対してIAMロールを使う方法では、EC2インスタンスに直接ロールを割り当てます。
# ✅ After：EC2インスタンスにIAMロールをアタッチする
IAMロール名: ec2-s3-upload-role
アタッチするポリシー: AmazonS3FullAccess（学習用途。実務ではバケットを絞った独自ポリシーを推奨）
ロールをアタッチしたEC2インスタンスは、内部的に一時的な認証情報を自動で取得し、その期限が切れると自動的に更新されます。
開発者が固定のアクセスキーを扱う必要がなくなるため、キーの漏洩リスクを構造的に減らせます。
私が初めてこの仕組みを理解したときは「パスワードを持たずに認証できるなんて不思議だ」と感じましたが、AWSのセキュリティベストプラクティスとして、リソース間の権限付与には基本的にロールを使うことが強く推奨されています。
実装の全体像・4要素の関係整理
誰が何にアタッチできるかの整理
4つの要素の関係を整理すると、以下のようになります。
- ユーザー：個人やシステムに1対1で紐づく認証情報
- グループ：複数のユーザーをまとめる箱（ユーザーだけが所属できる）
- ロール：人ではなくAWSリソースやサービスに一時的な権限を貸し出す仕組み
- ポリシー：ユーザー・グループ・ロールのいずれにもアタッチできる「権限の中身」
つまりポリシーは、ユーザー・グループ・ロールという3つの入れ物すべてに共通してアタッチされる、権限のルールブックだとイメージしてください。
つまずきやすい設定・注意点
- グループには「グループ」は所属させられない（グループの入れ子構造は作れない）
- ロールはユーザーと違い、常に一時的な認証情報しか発行しない
- 1つのユーザー・グループ・ロールに、複数のポリシーをアタッチすることも可能
よくあるつまずきポイント・エラー対処
ユーザーとロールの違いが分からず設定に詰まる
❌ Before：EC2からS3にアクセスさせるためにIAMユーザーを作ろうとする
私が最初にこの構成を作ろうとしたとき、「EC2からS3にアクセスするから、EC2用のIAMユーザーを作ればいいのでは」と考えてしまいました。
実際にIAMユーザーを作成し、そのアクセスキーをEC2のコード内に設定してS3への PutObject（ファイルをアップロードする操作です）を試したところ、動作自体はしたものの、AWS Trusted Advisorから次のような趣旨のセキュリティ警告を受け取りました。
Exposed Access Keys
An access key for an IAM user may have been exposed or is not following best practices.
コードの中にアクセスキーが残っていたことが原因で、「ベストプラクティスに反している」という警告が表示されたのです。
✅ After：EC2にはIAMロールをアタッチし、ユーザーの作成自体をしない
このときの解決策は、そもそもEC2用にIAMユーザーを作らないことでした。
代わりにIAMロールを新規作成し、必要なポリシー（S3へのアップロード権限）をアタッチした上で、そのロールをEC2インスタンスの設定画面から直接割り当てました。
「人にはユーザー、リソースにはロール」という原則を意識するようになってから、この手の設計ミスはなくなりました。
応用・一歩先の使い方
最小権限の原則へのつなぎ
ここまでは学習用に AdministratorAccess や AmazonS3FullAccess のような広い権限を使ってきましたが、実務では最小権限の原則（必要最小限の操作・リソースだけにアクセスを絞る考え方です）に基づいたポリシー設計が求められます。
「どのバケットの」「どの操作だけを」許可するのか、JSON形式で細かく指定していく方法は、次回の記事で扱います。
クロスアカウントロールへの発展
ロールの応用として、別のAWSアカウントに権限を一時的に貸し出すクロスアカウントロールという仕組みもあります。
複数のAWSアカウントを使い分ける中〜上級者になると、この仕組みが重要になってきます。
まずは今回扱った「同一アカウント内でのロール」の考え方をしっかり押さえておきましょう。
まとめ
この記事のポイント
- IAMは「ユーザー」「グループ」「ロール」「ポリシー」の4要素で構成される
- ユーザーは個人、グループはユーザーの集合、ロールはAWSリソース向けの一時的な権限
- ポリシーはユーザー・グループ・ロールいずれにもアタッチできる権限のルールブック
- EC2などのAWSリソースに権限を渡すときは、アクセスキーの直書きではなくロールを使う
- ロールは一時的な認証情報を自動発行するため、キー漏洩のリスクを構造的に減らせる
次に読むべき記事
- IAMポリシーの書き方基本
- よくあるAccess Deniedエラーの原因と対処法
タグ: AWS, 初心者向け, IAM
