【AWS CLF 間違えやすい箇所を整理】第3回 IAMの混同ポイント総整理 ― ルートユーザー/IAMユーザー他

Posted at 2026-07-02

はじめに

本記事は、AWS 認定クラウドプラクティショナー（CLF-C02）の合格を目指す連載の 第3回 です。今回扱うのは試験ドメイン2「セキュリティとコンプライアンス」に属する IAM（AWS Identity and Access Management） です。

CLF-C02 の試験は4つのドメインで構成され、その出題比率は次のとおりです。

ドメイン	出題比率
第1分野：クラウドの概念	24%
第2分野：セキュリティとコンプライアンス	30%
第3分野：クラウドのテクノロジーとサービス	34%
第4分野：請求、料金、およびサポート	12%

セキュリティとコンプライアンスは全体の 30% を占める最重要ドメインで、その中でも IAM は毎回のように問われる頻出テーマです。ところが IAM は「ユーザー」「グループ」「ロール」「ポリシー」といった似た用語が密に絡み合っており、混同したまま暗記すると引っかけ問題で確実に失点します。

筆者自身も学習初期に「ロールとユーザーって何が違うの？」と何度もつまずきました。本記事では、間違えやすい箇所を 対比形式（混同しやすいポイント → 正しい理解 → ひっかけ例） で一つずつ潰していきます。

まず全体像をつかむ

IAM に登場する要素の関係を図にすると、頭の中が整理しやすくなります。

ポイントは「認証（誰か）」と「認可（何ができるか）」を分けて考えることです。ユーザー・グループ・ロールは「誰か（アイデンティティ）」、ポリシーは「何ができるか（権限）」を担います。それでは混同しやすい箇所を見ていきましょう。

混同ポイント1：ルートユーザー vs IAMユーザー（管理者）

混同しやすいポイント
「管理者権限を持つ IAM ユーザー＝ルートユーザー」だと思ってしまう。

正しい理解
AWS アカウントを新規作成すると、まず ルートユーザー という、そのアカウントのすべてのサービスとリソースに完全アクセスできる唯一のサインインIDが生まれます。サインインにはアカウント作成時のメールアドレスを使います。

一方 IAM ユーザー は、アカウントの中に作る「特定の権限を持つ個別のID」です。たとえ AdministratorAccess ポリシーをアタッチして管理者権限を与えても、ルートユーザーと IAM ユーザーは別物です。AWS は「ルートユーザーの認証情報が必須のタスク以外は、ルートユーザーを使わず、日常作業用の管理者ユーザーを作って使う」ことを強く推奨しています。

ひっかけ例

「日常的な管理作業を行う最も推奨される方法は？」
→ 正解は「管理者権限を持つ IAM ユーザー（または IAM Identity Center のユーザー）を使う」。「ルートユーザーを使う」は不正解です。

混同ポイント2：ルートユーザーでしかできないタスク

混同しやすいポイント
「IAM ユーザーに AdministratorAccess を付ければ何でもできる」と思い込む。

正しい理解
管理者権限の IAM ユーザーでもできない、ルートユーザーの認証情報が必須のタスクが存在します。代表例は次のとおりです。

アカウント設定の変更（アカウント名、メールアドレス、ルートユーザーのパスワード）
AWS サポートプランの変更・解約
唯一の管理者 IAM ユーザーが誤って自分の権限を剥奪した場合の権限復旧
請求（Billing and Cost Management）コンソールへの IAM アクセスの有効化
S3 バケットの MFA Delete の設定
Reserved Instance Marketplace への出品者登録
アカウントの解約（クローズ）

ひっかけ例

「AWS サポートプランをアップグレードしたい。誰が実行できる？」
→ 正解は「ルートユーザー」。「管理者権限の IAM ユーザー」は不正解になり得ます。

混同ポイント3：IAMユーザー vs IAMグループ

混同しやすいポイント
「グループにもログインできる」「グループに権限を継承させたユーザーは個別設定できない」と思ってしまう。

正しい理解
IAM グループは IAM ユーザーの集合（束）です。ユーザー一人ひとりに権限を付与する代わりに、グループにポリシーをアタッチすれば、所属ユーザー全員がその権限を継承します。「開発者グループ」「経理グループ」のように役割単位で権限を管理でき、運用がスケールします。

ただし注意点があります。

グループ自体はサインイン（認証）できません。 グループに認証情報（パスワードやアクセスキー）はありません。
グループはネスト（グループの中にグループ）できません。
1人のユーザーは複数グループに所属できます。

ひっかけ例

「IAM グループの認証情報を使ってサインインできる」
→ ✕。グループはあくまで権限管理のためのまとまりであり、サインインの主体にはなりません。

混同ポイント4：IAMユーザー vs IAMロール（最重要）

混同しやすいポイント
「ロールはユーザーの一種」「ロールにも固定のパスワードやアクセスキーがある」と思ってしまう。ここは CLF で最も狙われる論点です。

正しい理解
IAM ユーザーは特定の人やアプリに紐づく 長期的なID で、パスワードやアクセスキーといった永続的な認証情報を持ちます。

IAM ロールは特定の人に紐づかない 一時的なID です。ロールには固定の認証情報がなく、ユーザーやサービスがロールを「引き受ける（AssumeRole）」と、その都度 一時的な認証情報 が発行されます。

観点	IAMユーザー	IAMロール
紐づく対象	特定の人/アプリ	誰にも固定で紐づかない
認証情報	長期（パスワード/アクセスキー）	一時的（引き受け時に発行）
主な用途	継続的な個別アクセス	サービスや一時的アクセス
例	開発者個人	EC2 から S3 へアクセス

AWS は「人間のユーザーにも、長期認証情報を持つ IAM ユーザーを作るより、ロールを引き受けて一時的な認証情報を使う」ことをベストプラクティスとして推奨しています。たとえば EC2 インスタンスから S3 にアクセスさせたいとき、アクセスキーをコードに埋め込むのではなく、ロールを EC2 にアタッチするのが正解です。

ひっかけ例

「EC2 インスタンスから S3 にアクセスさせたい。最も安全な方法は？」
→ 正解は「IAM ロールを EC2 にアタッチする」。「アクセスキーをアプリにハードコードする」は最悪の選択肢です。

混同ポイント5：アイデンティティベースポリシー vs リソースベースポリシー

混同しやすいポイント
「ポリシーはユーザーに付けるものだけ」だと思い込む。

正しい理解
ポリシーは「何を許可／拒否するか」を定義した JSON のルールです。アタッチ先によって2タイプに分かれます。

アイデンティティベースポリシー：IAM ユーザー・グループ・ロールにアタッチし、「そのIDが何をできるか」を定義します。
リソースベースポリシー：リソース側にアタッチし、「そのリソースに誰がアクセスできるか」を定義します。代表例は S3 バケットポリシー と、ロールの 信頼ポリシー（trust policy） です。

ひっかけ例

「S3 バケットポリシーはどの種類のポリシー？」
→ 正解は「リソースベースポリシー」。アイデンティティベースと混同しやすいので注意します。

混同ポイント6：認証（Authentication）vs 認可（Authorization）と MFA

混同しやすいポイント
「MFA を有効にすれば権限が増える／制限される」と思ってしまう。

正しい理解

認証（Authentication）：「あなたが誰か」を確認すること。パスワードや MFA がこれにあたります。
認可（Authorization）：「何ができるか」を決めること。ポリシーがこれにあたります。

MFA（多要素認証） は認証を強化する仕組みで、パスワード（知識情報）に加えて、認証アプリのコードやセキュリティキー（所持情報）など2つ目の要素を要求します。MFA は 認証を強くするだけで、権限（認可）を増減させるものではありません。AWS は特に ルートユーザーには必ず MFA を設定する ことを推奨しています。なおルートユーザーにはアクセスキーを作らないことも重要なベストプラクティスです。

ひっかけ例

「MFA を有効化すると IAM ユーザーの権限はどうなる？」
→ 権限は変わりません。MFA はサインイン時の本人確認を強化するだけです。

混同ポイント7：最小権限（Least Privilege）の考え方

混同しやすいポイント
「とりあえず AdministratorAccess を付けておけば楽」が許容されると思ってしまう。

正しい理解
最小権限の原則（least privilege） とは、タスクの遂行に必要な権限「だけ」を与えるという考え方です。IAM ポリシーで権限を設定するときは、「どのアクションを・どのリソースに対して・どの条件で」許可するかを必要最小限に絞ります。広すぎる権限はセキュリティリスクであり、CLF でも「セキュリティのベストプラクティスは？」という文脈で頻出します。

ひっかけ例

「新しい開発者に、必要な S3 操作だけをさせたい。どうする？」
→ 正解は「必要なアクションだけを許可する最小権限のポリシーを作成してアタッチする」。「AdministratorAccess を付与する」は不正解です。

まとめ早見表

用語	一言でいうと	認証情報	サインイン	よくある誤解
ルートユーザー	アカウント作成時の最強ID	あり（メール＋PW）	可	管理者IAMユーザーと同じ→✕
IAMユーザー	個人/アプリ用の長期ID	あり（PW/アクセスキー）	可	ルートと同じ→✕
IAMグループ	ユーザーの束（権限管理用）	なし	不可	グループでログインできる→✕
IAMロール	一時的に引き受けるID	一時的（引き受け時に発行）	引き受けて利用	固定の認証情報を持つ→✕
ポリシー	許可/拒否のルール(JSON)	―	―	ユーザーにしか付かない→✕
MFA	認証の追加要素	―	―	権限が増減する→✕
最小権限	必要な権限だけ与える原則	―	―	Admin付与で十分→✕

判断に迷ったときの早見ルールです。

「誰か」を表すなら → ユーザー / グループ / ロール
「何ができるか」を表すなら → ポリシー
「一時的・サービス用」なら → ロール
「サインインの主体になれない」のは → グループ
「権限ではなく本人確認の強化」なら → MFA

次回予告

連載第4回は、同じく「セキュリティとコンプライアンス」ドメインから セキュリティ系サービス（Shield / WAF / GuardDuty / Inspector / Macie / KMS / CloudHSM / Artifact / Security Hub）の役割の取り違え を整理します。「DDoS 対策はどれ？」「暗号鍵の管理は？」「脅威検知は？」といった、サービス名と役割を結びつける問題を一気に攻略します。

参考（AWS公式の一次情報）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up