先に結論
IAM は、AWSで 誰が 何に どこまで アクセスできるかを管理する仕組みです。
正式には Identity and Access Management の略で、AWSアカウント内の権限管理の土台になります。
IAMを理解するときは、まず次の4つを分けて考えるとかなり整理しやすいです。
| 要素 | 役割 |
|---|---|
| ユーザー | 人や特定用途の主体 |
| グループ | ユーザーへまとめて権限を配る単位 |
| ロール | 一時的に引き受ける権限 |
| ポリシー | 何を許可・拒否するかを書くルール |
初心者が混乱しやすいのは、ユーザーを作れば全部できる と考えてしまうことです。
でもAWS公式では、人間の利用者は長期認証情報を持つIAMユーザーではなく、IdP連携と一時的な認証情報を使う形を推奨しています。ワークロード側も、できるだけIAMロールで一時認証情報を使う方が安全です。
この記事では、2026年4月23日時点で AWS IAM User Guide の
What is IAM?、IAM users、IAM groups、IAM roles、Security best practices in IAMなどを確認しながら整理しています。
IAMとは何か
IAMは、AWSアカウントの中で認証と認可を管理する仕組みです。
ざっくり言うと、ログインやAPI利用の入口と、操作できる範囲を決める役目です。
たとえば、同じAWSアカウントの中でも、次のように分けたい場面があります。
- 開発者はEC2とCloudWatchだけ触れる
- 経理担当は請求情報だけ見られる
- アプリ本体はS3へ保存できるが、RDSは触れない
- Lambdaは特定のSQSキューだけ読める
- 他アカウントの監査担当だけ一時的に閲覧できる
こうした 誰にどこまで許すか を決めるのがIAMです。
4つの基本要素
1. IAMユーザー
IAMユーザーは、AWSアカウント内に作るIDです。
名前と認証情報を持ち、コンソールログインやAPIアクセスに使えます。
ただし、ここで大事なのは「IAMユーザーは作れる」と「人間にはIAMユーザーをどんどん作るべき」は別だということです。
AWS公式では、人間の利用者にはIdP連携や一時認証情報の利用を推奨しており、IAMユーザーはそれが使えない特定用途へ絞る方針です。
つまり、初心者向けにはこう理解すると分かりやすいです。
- IAMユーザー: 作れる
- でも人間の常用入口としては増やしすぎない
- やむを得ず使うなら権限を絞り、MFAも入れる
2. IAMグループ
IAMグループは、複数のIAMユーザーへまとめて権限を配るための単位です。
たとえば developers billing-readonly support のようなグループを作り、そのグループへポリシーを付けます。
個々のユーザーへ毎回同じポリシーを手作業で付けるより、グループでまとめた方が管理しやすいです。
ただし、グループは認証主体ではありません。
AWS公式でも、グループは Principal として扱えず、あくまで権限整理のための箱です。
3. IAMロール
IAMロールは、誰かが一時的に引き受ける権限です。
ここがIAMでいちばん大事なポイントです。
ロールはユーザーと似ていますが、長期のパスワードやアクセスキーを持たず、引き受けたときだけ一時的な認証情報を発行します。
AWS公式でも、ロールは assumable な存在として説明されています。
IAMロールがよく使われる場面は次の通りです。
- EC2 から S3 にアクセスする
- Lambda から DynamoDB を読む
- ECS タスクから SQS を使う
- 別AWSアカウントの権限を一時的に借りる
- 人間ユーザーが通常権限から管理者権限へ一時昇格する
AWSを実務で使うなら、何かに権限を与えたい ときにまずロールを考える癖を付けた方が安全です。
4. IAMポリシー
IAMポリシーは、何を許可・拒否するかを書くJSONドキュメントです。
たとえば、S3の特定バケットだけ読める EC2の起動はできるが削除はできない のような権限ルールを表します。
ポリシーは、ユーザー、グループ、ロールに付けられます。
つまり、誰に 権限を持たせるかと、何を 許すかは別で考える、ということです。
この分け方ができると、IAMはかなり見通しが良くなります。
どう使い分ければよいか
初心者向けのざっくりした判断基準は次の通りです。
| 場面 | まず考えるもの |
|---|---|
| 人間の利用者へ普段の権限を与えたい | IdP連携やIAM Identity Center、必要ならロール |
| 複数のIAMユーザーへ同じ権限を配りたい | グループ |
| アプリやAWSサービスへ権限を与えたい | ロール |
| 別アカウントへ一時的にアクセスさせたい | ロール |
| 何を許すか定義したい | ポリシー |
ここでありがちな失敗は、全部IAMユーザーで片付けようとすることです。
たとえば、EC2上のアプリへS3アクセス権を持たせるために、アクセスキー付きIAMユーザーを作ってサーバーへ置く運用は、あとで漏えいや棚卸しの負担が大きくなります。
その代わり、EC2インスタンスにロールを付ければ、一時認証情報でアクセスしやすくなります。
AWS公式も、長期のアクセスキーより一時認証情報を推奨しています。
アクセスキーをどう考えるか
IAMで事故りやすいのがアクセスキーです。
アクセスキーはCLIやSDKからのAPI呼び出しに使える長期認証情報ですが、AWS公式では 可能なら使わず、一時認証情報を使う ことが強く勧められています。
理由は単純で、長く生きる認証情報ほど漏えい時の被害が大きいからです。
たとえば、次のような運用は危ないです。
- 開発PCに管理者権限のアクセスキーを置きっぱなし
- EC2やWordPressプラグイン設定に長期アクセスキーを直書き
- 誰のキーか分からない古いアクセスキーが残る
- 退職者や外注先のキーが無効化されていない
やむを得ずIAMユーザーのアクセスキーを使う場合でも、最低限次を見ます。
- 本当にロールへ置き換えられないか
- 権限は最小限か
- 利用元IPや条件で縛れないか
- 最終使用日を追えているか
- 定期ローテーションと削除ができているか
最小権限の考え方
IAMでずっと大事なのは、最小権限です。
最小権限とは、必要な作業に必要な権限だけを与える考え方です。
最初から AdministratorAccess を広く配ると、構築は速いですが、事故や誤操作の被害も大きくなります。
AWS公式でも、まず管理ポリシーから始めても、最終的には利用実態に合わせて権限を絞ることが勧められています。
実務では、次の順番で考えると進めやすいです。
- その人やシステムが何をするか決める
- 触るサービスを絞る
- 読み取りだけで足りるか、更新が必要か分ける
- 対象リソースを絞る
- 条件でさらに制限できないか見る
さらに、IAM Access Analyzer を使って、使われた権限からポリシーを調整する方法もあります。
IAM Identity Centerとの違い
ここも混乱しやすい点です。
AWSの認証管理 = すべてIAMユーザー ではありません。
最近のAWS運用では、人間ユーザーの入口としては IAM Identity Center を使い、そこから必要な権限セットやロールへつなぐ構成がかなり自然です。
一方、IAM自体はその下でロール、ポリシー、サービス権限を管理する土台として残ります。
初心者向けに整理すると、こんなイメージです。
- IAM: AWS権限管理の基盤
- IAMユーザー: いまもあるが、人間の常用入口としては増やしすぎない
- IAM Identity Center: 人間の入口をまとめる候補
- IAMロール: 実務でかなり主役
よくある誤解
1. IAMユーザーを作ればそれで普通
昔の入門ではそう見えることがありますが、いまはそこを標準にしすぎない方が安全です。
人間は一時認証情報、ワークロードはロール、という方向へ寄せた方が事故りにくいです。
2. グループに入れれば十分
グループは便利ですが、IAM全体の一部です。
ロール、ポリシー、アクセスキー、MFA、監査ログ、アカウント分離まで見ないと、実務では足りません。
3. ポリシーは細かすぎるから管理者権限でいい
短期的には楽でも、長期的には危ないです。 特に本番系、請求、ネットワーク、データ削除が絡む権限は、雑に広げない方が安全です。
AWS IAMに関するよくある質問
Q. ユーザー、グループ、ロールはどう使い分けますか？
A. ユーザーは個人/個別アカウント、グループは権限の共通化、ロールは AWS リソース(EC2、Lambda)や外部 ID(SSO、フェデレーション)に付与。人間 = ユーザー + グループ、システム = ロール が定石。
Q. アクセスキーを使うべきタイミングは？
A. 最小限に。CI/CD 用、ローカル開発、SDK 経由でやむを得ない場合のみ。Identity Center(SSO)、Assume Role、EC2 Instance Profile で代替できる場合は使わないのが現代的。
Q. ルートアカウントはどう守る？
A. 平時は使わない、MFA 必須、長く強いパスワード、専用メアド、リカバリーコードの安全保管、緊急時のみ使用 のルール化、です。ルート侵害 = アカウント全消失の可能性。
Q. Policy の書き方の基本は？
A. 最小権限の原則 で Allow のみ書く、Deny で例外を厳しく、Resource を具体的なARNに絞る、Condition で IP/MFA/時間など細かく制限、です。* の使いすぎは危険信号。
Q. CloudTrail で何を監視する？
A. Root login、権限変更、IAM ユーザー作成、API キー作成、重要リソース削除、です。Security Hub や GuardDuty と連動して、異常時に即アラートが基本。
Q. AWS Identity Center(SSO)とは？
A. 複数の AWS アカウントへ単一サインオンできるサービス。ユーザーは Identity Center に一度ログイン → 各アカウントにロールで Assume、で運用負荷が大幅軽減。組織が複数アカウントになったら導入推奨。
Q. IAM の Permission Boundary とは？
A. ユーザーやロールが取得できる最大権限を制限する 天井 の役割。委任した管理者が、誤って強い権限を渡せないように制限 するのに使います。
まとめ
IAM は、AWSで 誰が 何に どこまで アクセスできるかを管理する仕組みです。
理解のコツは、ユーザー、グループ、ロール、ポリシーを分けて考えることです。
特に実務では、何でもIAMユーザーで運用するのではなく、ロールと一時認証情報を中心に考えた方が安全です。
アクセスキーは減らし、最小権限で絞り、必要に応じてMFAや監査も組み合わせる。このあたりを押さえると、AWSの権限設計がかなり崩れにくくなります。
参考リンク
- AWS Docs: What is IAM?
- AWS Docs: IAM users
- AWS Docs: IAM user groups
- AWS Docs: IAM roles
- AWS Docs: Security best practices in IAM
- AWS Docs: Manage access keys for IAM users