【脱・初心者】なぜAWSのプロは「IAMユーザー」を使わないのか？ 9割が知らない「AssumeRole」の正体
※本ページはプロモーションが含まれています
【この記事でわかること】
- IAMユーザーは「永続的な社員証」。漏洩したら終わる。
- IAMロールは「貸し出し用の帽子」。被っている間だけ権限を持てる。
- AssumeRoleとは、帽子を「被る（変身する）」アクションのこと。
- プロは社員証を使わず、必要な時だけ「帽子」を被る運用をしている。
はじめに：Access Denied という絶望
AWSを触っていて、最も頻繁に目にするエラー。 それが User: xxx is not authorized to perform: s3:ListBuckets です。
「管理者権限（Admin）のはずなのに！」 「言われた通りJSONを貼り付けたのに！」
多くのエンジニアが、この「権限パズル」の前で時間を溶かします。 今日は、AWSセキュリティの要である IAM（Identity and Access Management） を、難しい用語を一切使わず、「変身ごっこ」に例えて攻略します。
【追記】
この記事の「図解」が分かりやすい！と反響をいただいています。
「もっと他のサービスも図解で見たい」という方は、AWSの主要サービスを図解した以下の本もあわせてどうぞ！
（現在、一部無料試し読み公開中です👇）
1. 登場人物は4人だけ
IAMがややこしいのは、似たような言葉が多いからです。 まずはこれを「普通の会社」に置き換えてみましょう。
| AWS用語 | 会社の例え | 特徴 |
|---|---|---|
| IAM User | 社員（個人） | IDとパスワードを持つ「生身の人間」。田中さん、鈴木さん。 |
| IAM Group | 部署（課） | 営業部、開発部。まとめて権限を管理するための箱。 |
| IAM Policy | 業務マニュアル | 「S3を見てよし」「EC2を消してよし」と書かれた許可証。 |
| IAM Role | 役職帽子 | （最重要）誰でも被れる「ヘルメット」や「腕章」。 |
初心者の間違い：全部「社員（User）」でやろうとする
「EC2からS3にアクセスしたい」という時、EC2の中に「アクセスキー（社員証）」を埋め込んでいませんか？ それは、社員証をサーバー室に置きっぱなしにするのと同じで、非常に危険です。
そこで登場するのが、「IAMロール（帽子）」です。
2. IAMロールは「魔法の帽子」である
IAMロールは、特定の「人」ではありません。 「その帽子を被っている間だけ、権限を行使できるアイテム」です。
- IAMユーザー: 「私は田中です」（証明書はずっと持っている）
- IAMロール: 「私は今、管理者です」（帽子を被っている間だけ有効）
この「帽子を被る」というアクションのことを、AWS用語で AssumeRole（アシューム・ロール） と呼びます。
▼ 【図解】IAMユーザーとIAMロールの違い
プロの現場では、EC2やLambdaなどの「機械」には、絶対にIAMユーザー（固定キー）を持たせません。 代わりに「このEC2は、この帽子（ロール）を被っていいよ」という設定だけをします。 これが、セキュアな設計の第一歩です。
📚 「セキュリティ」を基礎から学びたい方へ
「IAMの概念はわかったけど、実際にスイッチロールの設定をどうやるのか画面で見たい」 「VPCとIAMを組み合わせた、安全なネットワーク構築を学びたい」
そんな方には、こちらの書籍がおすすめです。
▼ AWS認定 セキュリティ - 専門知識 (SCS-C02) 対応テキスト
【実践編】この「帽子」をブラウザで体験しよう
このAssumeRoleの仕組みを、マネジメントコンソール上でボタン1つで実現するのがスイッチロールです。
「Chromeのタブが多すぎて大変」という方は、以下の記事で設定方法を図解しているので、ぜひ試してみてください。
3. AssumeRoleの真実：「鍵の交換」こそが本体
ここで少し技術的な話をします。 「帽子を被る（AssumeRole）」と言いましたが、システムの中では具体的に何が起きているのでしょうか？
実は、STS（Security Token Service） という「守衛室」で、鍵の交換が行われています。
- 申請: 「この帽子（ロール）を被らせてください！」とSTSに頼む。
- 審査: STSが信頼関係（Trust Policy）をチェック。
- 発行: OKなら、「3つの情報（一時的な鍵）」が発行されます。
この「一時的な鍵（Temporary Security Credentials）」をもらうこと。 これこそが AssumeRole の正体です。
▼ 【図解】AssumeRoleの実体（STSとのやり取り）
4. 恐怖のJSON（ポリシー）を解読せよ
「概念はわかった。でも、あのJSONを書くのが無理！」 わかります。でも、あれはプログラミング言語ではありません。ただの英語の構文（SVO）です。
IAMポリシーは、必ず以下の3つの要素で構成されています。
- Effect: Allow (許可) か Deny (拒否) か
- Action: s3:ListBucket (何を？)
- Resource: arn:aws:s3:::my-bucket (どの対象に？)
つまり、「誰が（Principal）」「何を（Resource）」「どうしていい（Action）」 を書いているだけです。
▼ 【図解】ポリシーの構造
💡 覚えなくていい
「s3の書き込み権限って、PutObjectだっけ？ WriteObjectだっけ？」 そんなことを暗記する必要はありません。 AWSには「ポリシーシミュレーター」や「ビジュアルエディタ」があります。 重要なのは、「誰に、どこで、何を許可するか」という意図を明確にすることです。
あわせて読みたい
この記事でIAMがわかったら、次は「ネットワーク」や「データベース」も図解で攻略しましょう。
- [ネットワーク編] https://zenn.dev/miyaco_log/articles/a193c6f54bae4f
- [S3編] https://zenn.dev/miyaco_log/articles/c1fa2a693c6a97
- [データベース編] https://zenn.dev/miyaco_log/articles/53181d1f06c7ae
5. 「信頼関係（Trust Relationship）」という名の握手
IAMロール（帽子）を作るとき、一番つまずくのが「信頼関係」タブです。 これは、「この帽子は、誰なら被っていいか？」を指定するルールです。
- EC2用のロール: 「EC2サービスくんだけ、被ってよし」
- 田中さん用の管理者ロール: 「田中さんだけ、被ってよし」
ここを設定し忘れると、「帽子はあるのに被れない（変身できない）」というエラーになります。
おわりに：権限管理は「愛」だ
IAMを厳しく設定するのは、意地悪ではありません。 万が一、アクセスキーが漏れた時に、被害を最小限に食い止めるための「未来の自分への優しさ（愛）」です。
- 人には「IAMユーザー（MFA必須）」
- 機械には「IAMロール」
この原則さえ守れば、IAMはもう怖くありません。 さあ、自信を持って「帽子」を使いこなしましょう！
📚 「セキュリティ」を基礎から学びたい方へ
「IAMの概念はわかったけど、実際にスイッチロールの設定をどうやるのか画面で見たい」 「VPCとIAMを組み合わせた、安全なネットワーク構築を学びたい」
そんな方には、こちらの書籍がおすすめです。 図解が多く、ハンズオン形式で「なぜこの設定が必要なのか」が体感できます。
▼ AWS認定 セキュリティ - 専門知識 (SCS-C02) 対応テキスト
次のステップ：ブラウザの「ログイン地獄」から脱出する
IAMユーザーを使わないメリットはわかりましたか？
次は、実際にブラウザ（マネジメントコンソール）の設定を変えてみましょう。
パスワード管理が「1個」になるだけで、世界が変わりますよ。
▼ 【図解】AWSアカウントを「スイッチロール」で瞬時に切り替える魔法
【追記】
この記事の「図解」が分かりやすい！と反響をいただいています。
「もっと他のサービスも図解で見たい」という方は、AWSの主要サービスを図解した以下の本もあわせてどうぞ！
（現在、一部無料試し読み公開中です👇）
Discussion