🔐 STEP 4: IAM（権限管理）の基礎
AWSの権限管理システムを理解し、セキュアな運用方法を習得します
📋 このステップで学ぶこと
- IAMとは何か、なぜ重要なのか
- ユーザー、グループ、ロールの違い
- ポリシーの作成と適用
- 最小権限の原則
- アクセスキーの管理
- 実践演習：IAMユーザー作成とS3アクセス権限設定
🔑 1. IAMとは何か
IAMの基本
IAM（Identity and Access Management、アイアムと読む）とは、「誰が、何を、どこまでできるか」を管理するサービスです。
AWSには200以上のサービスがあり、それぞれに「データを読む」「インスタンスを起動する」「設定を変更する」などの操作があります。IAMを使うと、各ユーザーやサービスに対して、どの操作を許可するかを細かく制御できます。
📝 例え話：会社の社員証とカードキー
会社のセキュリティシステムを思い浮かべてください。
社員証とカードキーで「誰がどの部屋に入れるか」を管理しますよね：
- 社長：全ての部屋に入れる（最強の権限）
- 経理担当：経理部の部屋と共用スペースだけ入れる
- 新入社員：自分のデスクと会議室だけ（最小限の権限）
- 清掃業者：夜間の共用スペースだけ（一時的な権限）
IAMも同じ考え方で、各ユーザーに必要最小限の権限だけを与えることで、セキュリティを高めます。
なぜIAMがこんなに重要なのか？
STEP 3で作成した「ルートユーザー」は、AWSアカウントの最高権限を持っています。これは便利なようで、実は非常に危険です。
⚠️ ルートユーザーだけを使い続ける危険性
ルートユーザーは何でもできる最強の権限を持っています。もし、ルートユーザーのパスワードが漏れたら…
- 全てのデータが削除される可能性
- 全てのサービスが停止される可能性
- 高額なリソースが勝手に作られる（仮想通貨マイニングなど）
- 機密情報が流出する可能性
- 最悪の場合、会社が倒産する事態も…
実際に、アクセスキー漏洩で数百万円の請求が来た事例があります。だから、普段はIAMユーザーを使うのがベストプラクティスなのです。
IAMを使うメリット
✅ セキュリティの向上
必要最小限の権限だけを与えることで、万が一アカウントが漏洩しても被害を最小限に抑えられます。
✅ 監査が可能
「誰が、いつ、何をしたか」をCloudTrailで記録できるので、問題が起きた時に追跡できます。
✅ チーム管理が楽
複数人でAWSを使う場合、役割ごとに権限を設定できるので、安全に運用できます。
✅ 完全無料
IAMの利用は完全に無料です。何人ユーザーを作っても、何個ポリシーを作っても費用はかかりません。
IAMの4つの主要概念
IAMには4つの重要な概念があります。これを理解すれば、IAMの8割はマスターしたも同然です。
🎯 IAMの4つの主要概念
- ユーザー（User）：個人を識別するアカウント（田中さん用、佐藤さん用など）
- グループ（Group）：複数のユーザーをまとめる仕組み（開発者グループ、分析者グループなど）
- ロール（Role）：AWSサービスに権限を付与する仕組み（EC2がS3にアクセスできるようにするなど）
- ポリシー（Policy）：「何ができるか」を定義した文書（S3を読める、EC2を起動できるなど）
次のセクションで、それぞれを詳しく解説します。
👥 2. ユーザー、グループ、ロールの違い
IAMユーザーとは
IAMユーザーとは、個人を識別するためのアカウントです。人間が1人1つ持つものだと考えてください。
📝 IAMユーザーの特徴
- 1人1ユーザー：田中さん用、佐藤さん用のように、個人ごとにユーザーを作成
- 認証情報を持つ：パスワード（コンソール用）やアクセスキー（プログラム用）で本人確認
- 権限を付与できる：「S3を読めるユーザー」「EC2を操作できるユーザー」など
- ログインできる：マネジメントコンソールにログインして操作可能
💡 例：田中さん用のIAMユーザー
IAMグループとは
IAMグループとは、複数のユーザーをまとめて管理する仕組みです。同じ権限が必要なユーザーを1つのグループにまとめることで、管理を効率化できます。
📝 IAMグループの特徴
- 権限の一括管理：グループに権限を付与すると、所属ユーザー全員に自動適用
- 追加・削除が簡単：新入社員をグループに追加するだけで、必要な権限が付く
- 複数グループに所属可能：1人のユーザーが複数のグループに所属できる
💡 例：開発者グループの構成
メリット：100人の開発者がいても、グループ1つに権限を設定するだけで全員に適用できます。
IAMロールとは
IAMロールとは、AWSサービス（EC2、Lambdaなど）に権限を付与する仕組みです。人間ではなく、「サービス」に権限を与える点がユーザーと異なります。
📝 IAMロールの特徴
- 人ではなくサービス用：「EC2からS3にアクセスしたい」時などに使う
- 一時的な認証：パスワードやアクセスキーは不要、自動的に認証される
- 安全：認証情報がコードに含まれないため、漏洩リスクが低い
💡 なぜロールが必要？
EC2インスタンス上で動くアプリがS3のデータを読みたいとします。
❌ 悪い方法（アクセスキーを使う）：
✅ 良い方法（IAMロールを使う）：
3つの違いを比較
ユーザー、グループ、ロールの違いを表にまとめました。
| 項目 | ユーザー | グループ | ロール |
|---|---|---|---|
| 対象 | 個人（人間） | 複数のユーザー | AWSサービス |
| 認証方法 | パスワード / アクセスキー | なし（ユーザーが持つ） | 自動（一時的トークン） |
| 主な用途 | 人がAWSを操作 | 権限の一括管理 | サービス間連携 |
| 具体例 | 田中さん用アカウント | 開発者グループ | EC2→S3アクセス |
| 権限の付与 | 直接付与 or グループ経由 | グループに付与 | ロールに付与 |
💡 覚え方
- ユーザー：「誰？」→ 個人を識別
- グループ：「どのチーム？」→ 複数人をまとめる
- ロール：「どのサービス？」→ AWSサービスに権限を与える
📜 3. ポリシーとは
ポリシーの基本
ポリシー（Policy）とは、「何ができるか」を定義したJSON形式の文書です。
ユーザー、グループ、ロールに「ポリシーを付与する」ことで、権限が設定されます。ポリシーがないと、何もできません。
💡 例え話：入館証のカードキー
会社の入館証で考えると…
- ユーザー = 社員証（誰かを識別する）
- ポリシー = カードキーの設定（どの部屋に入れるか）
社員証を持っていても、カードキーの設定がなければ部屋に入れないように、IAMユーザーもポリシーがなければAWSリソースにアクセスできません。
ポリシーの例を見てみよう
実際のポリシーはJSON形式で書かれています。以下は「S3バケットの読み取り専用」ポリシーの例です。
このポリシーの意味：
- 「my-bucket」というS3バケットの一覧を見ることを許可
- 「my-bucket」内のオブジェクト（ファイル）を取得することを許可
- 削除や書き込みはできない（記載がないため）
ポリシーの構造を理解する
ポリシーは4つの要素で構成されています。
1. Effect（効果）
許可するか、拒否するかを指定します。
- Allow：許可する
- Deny：拒否する（Allowより優先）
2. Action（アクション）
何をするかを指定します。
s3:GetObject：S3オブジェクト取得ec2:StartInstances：EC2起動*：全てのアクション
3. Resource（リソース）
どのリソースに対してかを指定します。
- ARN形式で指定
arn:aws:s3:::my-bucket/**：全てのリソース
4. Condition（条件）※オプション
いつ適用するかを指定します。
- 特定のIPアドレスからのみ
- MFA認証済みの場合のみ
- 特定の時間帯のみ
ポリシーの種類
ポリシーには3つの種類があります。
| 種類 | 説明 | 使いどころ |
|---|---|---|
| AWSマネージドポリシー | AWSが用意した定義済みポリシー 例：AdministratorAccess、ReadOnlyAccess |
初心者におすすめ。すぐ使える |
| カスタマーマネージドポリシー | 自分で作成するポリシー 例：「特定のS3バケットだけ読み書き可能」 |
細かい権限設定が必要な時 |
| インラインポリシー | ユーザーやロールに直接埋め込むポリシー | あまり推奨されない（管理が大変） |
💡 初心者へのおすすめ
最初はAWSマネージドポリシーを使うのがおすすめです。AWSが用意した「よく使う権限セット」なので、JSONを書かなくても設定できます。
よく使うAWSマネージドポリシー：
AdministratorAccess：全権限（管理者用）ReadOnlyAccess：読み取り専用（閲覧者用）AmazonS3FullAccess：S3の全権限AmazonS3ReadOnlyAccess：S3の読み取り専用AmazonEC2FullAccess：EC2の全権限
🔒 4. 最小権限の原則
最小権限の原則とは？
最小権限の原則（Principle of Least Privilege）とは、「必要最小限の権限だけを与える」というセキュリティの基本原則です。
「多めに権限を与えておけば困らないだろう」という考えは絶対にNGです。不要な権限は、セキュリティリスクを高めるだけです。
⚠️ 悪い例：全員に管理者権限
「管理が面倒だから、全員にAdministratorAccessを付与しよう」
たった1回のミスで、会社に大きな損害が発生する可能性があります。
✅ 良い例：必要な権限だけ
役割ごとに必要な権限だけを付与します。
これなら、誤操作があっても被害を最小限に抑えられます。
役割ごとの権限設計例
実際の現場でよく使われる権限設計の例を紹介します。
| 役割 | 必要な操作 | 推奨ポリシー |
|---|---|---|
| データアナリスト | S3データ閲覧 Redshiftクエリ実行 QuickSightダッシュボード |
AmazonS3ReadOnlyAccess AmazonRedshiftQueryEditor |
| データエンジニア | S3読み書き Glue、Athena操作 Redshift管理 |
AmazonS3FullAccess AWSGlueConsoleFullAccess AmazonRedshiftFullAccess |
| 開発者 | EC2操作 RDS操作 CloudWatch監視 |
AmazonEC2FullAccess AmazonRDSFullAccess CloudWatchReadOnlyAccess |
| 管理者 | 全権限 | AdministratorAccess |
💡 権限設計のベストプラクティス
- 最初は制限的に：少ない権限から始めて、必要に応じて追加する
- グループで管理：役割ごとにグループを作り、グループに権限を付与する
- 定期的に見直し：不要になった権限は削除する
- MFA（多要素認証）：重要な操作には追加の認証を要求する
- 本番と開発を分離：本番環境へのアクセスは厳しく制限する
🔑 5. アクセスキーの管理
アクセスキーとは？
アクセスキーとは、プログラムからAWSにアクセスするための認証情報です。
マネジメントコンソールにログインする時は「パスワード」を使いますが、プログラム（Python、AWS CLIなど）からAWSを操作する時は「アクセスキー」を使います。
アクセスキーを使う場面
✅ 使う場面
- AWS CLI：コマンドラインからAWS操作
- SDK：PythonやJavaからAWS操作
- CI/CD：GitHub Actionsなどの自動デプロイ
- サードパーティツール：Terraformなど
❌ 危険な使い方
- GitHubに公開：即座に悪用される（ボットが監視）
- メールで送信：途中で盗まれる可能性
- コードに直接書く：漏洩リスク大
- 複数人で共有：誰が使ったか不明
⚠️ 実際にあった事件
GitHubに誤ってアクセスキーをプッシュした結果、数時間で数百万円の請求が来た事例があります。
悪意のあるボットがGitHubを常時監視しており、公開されたアクセスキーを見つけると即座に悪用します。仮想通貨のマイニングなどに使われ、高額な請求が発生します。
アクセスキーを安全に管理する方法
🔒 セキュリティのベストプラクティス
- 定期的にローテーション：90日ごとに新しいキーに変更する
- 環境変数に保存：コードに直接書かず、環境変数やAWS Secrets Managerに保存
- 最小権限：アクセスキーを持つユーザーには、必要な権限だけを付与
- 使わないキーは削除：古いキーは無効化または削除
- 1ユーザー1キー：複数のキーを作らない
- 可能ならIAMロールを使う：EC2やLambdaではロールを使えばキー不要
アクセスキーの作成方法
アクセスキーの作成手順を説明します。実際の演習は後のセクションで行います。
📝 作成手順（概要）
- IAMコンソールで対象ユーザーを選択
- 「セキュリティ認証情報」タブをクリック
- 「アクセスキーを作成」をクリック
- 用途を選択（CLI、SDKなど）
- シークレットキーをダウンロード（この時しか見られない！）
- 安全な場所に保存（パスワード管理ツールなど）
⚠️ 超重要
シークレットアクセスキーは、作成時に1度しか表示されません。
必ずダウンロードして、安全な場所（パスワード管理ツール、暗号化されたファイルなど）に保存してください。
紛失した場合は、新しいキーを作り直す必要があります。
🧪 6. 実践演習：IAMユーザー作成とS3アクセス権限設定
演習の目標
この演習では、新しいIAMユーザーを作成し、S3への読み取り専用権限を付与します。これにより、「最小権限の原則」を実践で体験できます。
🎯 この演習で作成するもの
- IAMユーザー名：data-analyst
- 権限：S3読み取り専用（AmazonS3ReadOnlyAccess）
- できること：S3のバケット一覧を見る、ファイルをダウンロード
- できないこと：バケットの作成、ファイルの削除、他サービスへのアクセス
演習手順
ステップ1: IAMコンソールにアクセス
- マネジメントコンソールにログイン（ルートユーザー）
- 上部の検索ボックスで「IAM」と入力
- 「IAM」サービスをクリック
- IAMダッシュボードが表示される
ステップ2: ユーザー作成を開始
- 左メニューから「ユーザー」をクリック
- 「ユーザーを作成」ボタンをクリック
ステップ3: ユーザーの詳細を設定
- ユーザー名：「data-analyst」と入力
- 「AWS マネジメントコンソールへのユーザーアクセスを提供する」にチェック
- 「IAMユーザーを作成します」を選択
- コンソールパスワード：「カスタムパスワード」を選択し、任意のパスワードを入力
- 「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります」のチェックを外す（学習用）
- 「次へ」をクリック
※パスワードは後で使うので、メモしておいてください。
ステップ4: 権限を設定
- 許可のオプション：「ポリシーを直接アタッチ」を選択
- 検索ボックスで「S3ReadOnly」と入力
- 「AmazonS3ReadOnlyAccess」にチェックを入れる
- 「次へ」をクリック
これで、S3の読み取り権限だけを持つユーザーが作成されます。
ステップ5: 確認と作成
- 設定内容を確認（ユーザー名、権限）
- 「ユーザーの作成」をクリック
- 「.csvファイルをダウンロード」をクリック（ログイン情報が記載）
- 「ユーザーリストに戻る」をクリック
CSVファイルは必ずダウンロードしてください。アカウントIDやログインURLが記載されています。
ステップ6: 作成したユーザーでログイン
- ブラウザで新しいプライベートウィンドウ（シークレットウィンドウ）を開く
https://console.aws.amazon.com/にアクセス- 「IAMユーザー」を選択
- アカウントID：12桁の数字を入力（ダウンロードしたCSVに記載、またはルートユーザーでログインして確認）
- ユーザー名：data-analyst
- パスワード：ステップ3で設定したパスワード
- 「サインイン」をクリック
ステップ7: 権限を確認してみよう
S3にアクセスしてみる（成功するはず）：
- 上部の検索ボックスで「S3」と入力
- S3サービスページに移動
- バケット一覧が見られる ✅（読み取り権限あり）
バケットを作成してみる（失敗するはず）：
- 「バケットを作成」ボタンをクリック
- バケット名を入力して「作成」
- エラーが出る ❌（書き込み権限なし）
EC2にアクセスしてみる（失敗するはず）：
- 上部の検索ボックスで「EC2」と入力
- EC2サービスページに移動
- 「API error」や「権限がありません」と表示される ❌
🎉 演習完了！
これで、S3を読むだけのユーザーを作成できました！
このユーザーはS3のデータを見ることはできますが、削除や変更はできません。また、EC2やRDSなど他のサービスにもアクセスできません。
これが「最小権限の原則」の実践例です。データアナリストには、必要なS3の閲覧権限だけを与え、それ以外は制限しています。
💡 今後のおすすめ
今後、AWSを使う際は、IAMユーザーでログインすることをおすすめします。
ルートユーザーは、以下の場合だけ使いましょう：
- IAMユーザーの管理（追加・削除）
- 請求情報の確認・変更
- アカウント設定の変更
- サポートプランの変更
📝 STEP 4 のまとめ
✅ このステップで学んだこと
1. IAMとは
- 「誰が、何を、どこまでできるか」を管理するサービス
- ルートユーザーだけを使うのは危険
- IAMは完全無料
2. ユーザー、グループ、ロールの違い
- ユーザー：個人を識別するアカウント
- グループ：複数ユーザーをまとめて管理
- ロール：AWSサービスに権限を付与
3. ポリシー
- 「何ができるか」を定義したJSON文書
- Effect（許可/拒否）、Action（何を）、Resource（どこに）で構成
- AWSマネージドポリシーが便利
4. 最小権限の原則
- 必要最小限の権限だけを与える
- 被害を最小限に抑えるため
5. アクセスキー
- プログラムからAWSにアクセスする認証情報
- GitHubへの公開は絶対NG
- 定期的にローテーション
💡 次のステップへ
IAMはAWSセキュリティの基礎です。正しく設定することで、安全にAWSを運用できます。
次のSTEP 5では、GCPアカウントの作成を行い、GCPのIAMについても学びます。AWSとGCPのIAMの違いを理解することで、マルチクラウドのスキルが身につきます。
📝 理解度チェック
IAMユーザー、IAMグループ、IAMロールの違いを簡単に説明してください。
【解答】
- IAMユーザー：個人を識別するアカウント。パスワードやアクセスキーを持ち、人間がAWSを操作する時に使う。
- IAMグループ：複数のユーザーをまとめて管理する仕組み。グループに権限を付与すると、所属ユーザー全員に適用される。
- IAMロール：AWSサービス（EC2、Lambdaなど）に権限を付与する仕組み。一時的な認証で、パスワード不要。
覚え方：ユーザー＝誰、グループ＝どのチーム、ロール＝どのサービス
最小権限の原則とは何ですか？なぜ重要ですか？
【解答】
最小権限の原則（Principle of Least Privilege）：
ユーザーやサービスに対して、必要最小限の権限だけを与えるというセキュリティの基本原則。
重要な理由：
- セキュリティ向上：万が一アカウントが乗っ取られても、被害を最小限に抑えられる
- 誤操作防止：必要のない操作（例：本番環境の削除）ができないようにする
- 監査しやすい：誰が何をできるか明確になり、問題発生時に追跡しやすい
アクセスキーを安全に管理するためのベストプラクティスを3つ挙げてください。
【解答例】（以下から3つ）
- 定期的にローテーション：90日ごとに新しいアクセスキーに変更し、古いキーは削除する
- 環境変数に保存：コードに直接書かず、環境変数やAWS Secrets Managerに保存する
- 最小権限を付与：アクセスキーを持つユーザーには、必要最小限の権限だけを付与する
- GitHubに公開しない：リポジトリにプッシュしないよう、.gitignoreに追加する
- 使わないキーは削除：古いキーや不要になったキーは無効化または削除する
- 可能ならIAMロールを使う：EC2やLambdaではロールを使えばキー不要
次のケースで、どのような権限設計が適切か考えてください。
「データアナリストが、S3のログデータを読んで、Redshiftでクエリを実行したい。ただし、データの削除はできないようにしたい。」
【解答】
権限設計の方針：
- IAMユーザー：「data-analyst」ユーザーを作成
- S3権限：
AmazonS3ReadOnlyAccessポリシーを付与（読み取り専用） - Redshift権限：
AmazonRedshiftQueryEditorポリシーを付与（クエリ実行のみ）
カスタムポリシーを作成する場合：
これにより、データアナリストはS3のログを読んでRedshiftでクエリできるが、削除はできない状態になります。
❓ よくある質問
いいえ、特定の場面では使う必要があります。
ルートユーザーは、以下の場合に使います：
- IAMユーザーの初回作成
- 請求情報の確認・変更
- アカウント設定の変更
- サポートプランの変更
それ以外の日常的な操作は、IAMユーザーを使いましょう。
デフォルトで5,000ユーザーまで作成できます。
それ以上必要な場合は、AWSに申請すれば上限を増やせます。個人学習や中小企業なら、5,000ユーザーで十分です。
新しいアクセスキーを作成してください。
紛失したアクセスキーは復元できません。IAMコンソールで、該当ユーザーの「セキュリティ認証情報」から、古いキーを「無効化」または「削除」し、新しいキーを作成しましょう。
また、紛失したキーが漏洩している可能性もあるので、すぐに古いキーを無効化してください。
最初はAWSマネージドポリシーを使いましょう。
AWSが用意した定義済みポリシー（AdministratorAccess、ReadOnlyAccessなど）を使えば、JSONを書かなくても権限を設定できます。
慣れてきたら、IAMポリシージェネレーターやAIツールを使って、カスタムポリシーを作成してみましょう。
AWSサービス同士を連携させる時に使います。
例えば：
- EC2からS3にアクセスしたい
- LambdaからDynamoDBを読みたい
- GlueからRedshiftにデータをロードしたい
このコースの後半で、実際にIAMロールを作成する演習があります。
学習メモ
クラウドデータ基盤（AWS・GCP） - Step 4