IAMの基本をCloud Practitioner向けに整理する

IAM（AWS Identity and Access Management）は、AWSで「誰が、どのAWSリソースに、何をしてよいか」を決めるためのサービスです。Cloud PractitionerではJSONの細かな書き方よりも、IAMユーザー・グループ・ロール・ポリシーを使い分ける目的を説明できることが大切です。

この記事では、試験で混同しやすい「本人を表すもの」と「許可を表すもの」の境界から整理します。公式の全体像はAWS Identity and Access Management とはも参照してください。

結論: IDと権限は別のもの

IAMを理解する近道は、IDと権限を分けて考えることです。IAMユーザーとIAMロールは、AWSにアクセスする主体、つまり「誰として操作するか」を表します。一方、IAMポリシーは「その主体に何を許可または拒否するか」を定義する文書です。IAMグループは、複数のIAMユーザーをまとめて同じ権限を管理しやすくする入れ物です。

この区別をすると、設問の選択肢を整理できます。現在の実運用で人がAWSへアクセスする場合は、IAM Identity CenterなどのIDプロバイダーでフェデレーションし、一時的な認証情報でロールを引き受ける構成を優先します。IAMユーザーはAWSアカウント内に作る長期的なID、IAMロールは一時的に権限を引き受けるID、IAMポリシーは許可内容、IAMグループは複数のIAMユーザーへ共通権限を配る入れ物として整理します。

IAMユーザー: 長期認証情報を持つID

IAMユーザーは、AWSアカウントの中で個人や特定の用途を識別するためのIDです。パスワードやアクセスキーのような長期認証情報を持てるため、不要になったアクセスを止めたり、操作の主体を追跡したりできます。ただし、現在のAWSの推奨では、人間の通常アクセスはIAMユーザーではなくフェデレーションと一時的な認証情報を優先します。

IAMユーザーは、フェデレーションでは対応できない特定用途や、学習・検証で仕組みを理解する場面に限定して考えるのが安全です。使う場合も、パスワードやアクセスキーを共有せず、MFA、最小権限、不要なアクセスキーの削除を徹底します。現在の推奨事項はAWS IAM のセキュリティベストプラクティスとAWS IAM Identity Centerとはで確認し、試験では「rootユーザーの日常利用を避ける」「MFAを有効化する」「長期認証情報より一時認証情報を優先する」という基本を押さえます。

IAMグループ: IAMユーザーをまとめる入れ物

IAMグループは、複数のIAMユーザーに共通するポリシーをまとめて適用するための仕組みです。たとえば開発チーム用のグループに必要な閲覧権限を付与し、新しく参加した人をそのグループへ追加します。個々のユーザーへ同じポリシーを何度も直接付けるより、変更漏れを減らせます。

重要なのは、グループそのものは人でもアプリケーションでもないことです。また、AWSサービスがグループを引き受けて処理することもありません。「Lambdaにグループを割り当てる」は不適切で、LambdaにはIAMロールを関連付けます。グループはIAMユーザーの管理を助ける境界だと覚えると混乱しません。

IAMロール: 一時的に引き受けるID

IAMロールは、必要な場面で一時的な認証情報とともに権限を引き受けるためのIDです。ロールには永続的なパスワードやアクセスキーを埋め込まず、誰が引き受けられるかを信頼ポリシーで定め、引き受けた後に何ができるかを権限ポリシーで定めます。

典型例はLambda実行ロールです。Lambda関数がDynamoDBへ項目を書き込む必要があるなら、関数コードにアクセスキーを保存するのではなく、DynamoDBへの必要な操作だけを許可した実行ロールをLambdaに関連付けます。Lambdaは実行時にそのロールを引き受けます。これは「アプリケーションにAWSアクセスキーを配る」より安全に権限を渡す考え方です。

別アカウントへのアクセス、EC2などのAWSサービスからのアクセス、外部IDプロバイダーを使った一時的なアクセスも、ロールの代表的な用途です。人間がコンソールやCLIを使う場合も、IAM Identity Centerや外部IdPからロールを引き受けることで、長期認証情報を配らずに済みます。Cloud Practitionerでは、ロールを「AWSサービスや外部の主体に、必要な期間だけ権限を渡す方法」と説明できれば十分です。

IAMポリシー: 許可内容を定義する文書

IAMポリシーは、許可または明示的な拒否をJSONで定義する文書です。たとえば、対象のS3バケットを読み取れること、あるDynamoDBテーブルに書き込めることなどを指定します。ポリシーはユーザー、グループ、ロールなどのIDに関連付けて使います。

ここでの試験上の境界は明確です。ポリシーは「誰か」ではなく「何ができるか」です。設問で「EC2にS3への読み取りを許可したい」とあれば、EC2に使わせるのはロールで、そのロールに関連付けて許可内容を定義するのがポリシーです。より詳しい比較はIAMユーザー・ロール・ポリシーの違いで確認できます。

最小権限: 必要な範囲だけを許可する

最小権限の原則とは、作業を完了するために必要な権限だけを与える考え方です。たとえばLambdaが特定テーブルへ書き込むだけなら、その用途に必要な操作と対象へ絞ります。最初から全サービス、全リソースへの権限を与えると、設定ミスや認証情報の漏えい時に影響範囲が広がります。

初学者は「権限が足りずエラーになるなら、とりあえず管理者権限を付ける」と考えがちです。これはよくある失敗です。必要な操作、対象リソース、条件を順に確認して許可を狭めるのが本来の進め方です。試験でも、最も少ない権限で要件を満たす選択肢を選びます。

rootユーザーとMFAの注意点

rootユーザーはAWSアカウントの作成時に使う強力な認証情報です。日常的な作業には使わず、通常はIAMまたは組織で採用している認証方法を使います。rootユーザーでしか行えない作業があるため完全に不要にはできませんが、利用を最小限にし、MFAで保護することが重要です。

MFAは、パスワードだけではなく追加の確認を要求する仕組みです。パスワードが漏えいした場合でも、不正なサインインを防ぐ層を増やせます。CLFの設問では、アカウント保護や特権アクセスの対策としてMFAが選択肢に現れます。アクセスキーを定期的に確認することと、MFAを有効にすることは、目的が異なる対策です。

試験で混同しやすい境界

• 「LambdaがDynamoDBを操作する」なら、Lambda実行ロールを使います。IAMユーザーのアクセスキーをコードへ置く選択肢は避けます。
• 「開発者全員に同じ権限を付ける」設問では、IAMユーザーを前提にするならIAMグループとポリシー、実運用の人間アクセスならIAM Identity Centerのグループや権限セットを検討します。
• 「何を許可するか」を決めるのはポリシーです。「一時的に誰としてアクセスするか」を決めるのはロールです。
• 「強力な権限を常に使う」より、最小権限と必要なときだけのロール利用が安全です。
• 「アクセスキーを作れば自動化できる」だけで終わらせず、AWSサービス内の処理ならロールで認証情報を渡せないかを考えます。

よくある誤解とつまずき

よくある誤解は、IAMロールとアクセスキーを同じものとして扱うことです。アクセスキーはプログラムから署名付きリクエストを送るための認証情報の一種であり、ロールは一時的な認証情報を発行して権限を引き受ける仕組みです。LambdaのようなAWSサービスでは、実行ロールを使うことでコードに長期認証情報を持たせずに済みます。

もう一つの失敗は、ポリシーを付けた時点で安全だと考えることです。ポリシーの範囲が広すぎれば、付与先がユーザーでもロールでもリスクは残ります。誰が引き受けられるか、何を許可するか、MFAなどで認証をどう保護するかを一緒に確認します。

次に学ぶこと

IAMの基本を押さえたら、責任共有モデルもつなげて学ぶと、AWSと利用者の担当範囲を説明しやすくなります。AWS責任共有モデルを初心者向けに整理するを読み、IAM設定や認証情報の管理が利用者側の責任である理由を確認してください。

次に、マネジメントコンソールでIAMユーザー、グループ、ロール、ポリシーの関係を確認すると、用語が定着します。実運用では公式ドキュメントを基準にし、人間のアクセスはフェデレーション、ワークロードのアクセスはロールを優先しながら、必要な用途と権限を小さく切り分ける習慣を作ることが重要です。

設問を読む順番

IAMの問題では、最初に「操作する主体は人か、AWSサービスか、外部のシステムか」を確認します。人が日常的にコンソールを使う話なら、フェデレーションによる一時的な認証情報が現在の推奨です。設問がIAMユーザーを前提にしている場合だけ、個人を識別するIAMユーザーとグループを候補にします。Lambda、EC2、ECSなどのAWSサービスが他サービスへアクセスする話なら、実行時に引き受けるIAMロールを選びます。

次に「何を許可したいか」を読みます。S3の特定バケットを読む、DynamoDBの特定テーブルへ書き込む、といった操作の範囲を定義するのがポリシーです。複数の開発者に同じ権限を付与したいなら、グループへポリシーを関連付ける方法が管理しやすくなります。この順番で読むと、ユーザー、グループ、ロール、ポリシーが一つの選択肢に混ざっていても役割を分けられます。

最後に、設問が安全性を重視しているかを見ます。「認証情報をコードに保存しない」「長期的な強い権限を避ける」「rootユーザーを日常業務に使わない」「MFAを使う」といった条件があれば、最小権限と一時的な認証情報を優先する答えを探します。AWSサービス用のロールではなく、アクセスキーを設定ファイルへ直接書く選択肢は、この観点で除外できます。

小さな例で役割を確認する

社内の開発者三人が、検証用S3バケットの内容を確認する場面を考えます。実運用では、IAM Identity Centerなどで三人を管理し、対象AWSアカウントに読み取り用の権限セットを割り当てて、一時的な認証情報でアクセスする構成を優先します。IAMユーザーを使う前提の設問なら、三人をそれぞれIAMユーザーとして識別し、開発者用のIAMグループへ追加し、そのグループに対象バケットを読むためのポリシーを関連付けます。

同じバケットからLambda関数が設定ファイルを読む場面では、Lambdaにグループや開発者のアクセスキーは渡しません。Lambda実行ロールに必要な読み取り権限を持つポリシーを関連付けます。実行ロールは関数が処理中に引き受けるIDであり、開発者のIDとは別物です。人とワークロードで認証の経路を分けることが、試験の選択肢を見分ける手掛かりになります。

この例で、バケット全体の管理や他サービスへの変更まで許可する必要がなければ、その許可は追加しません。要件に書かれていない広い権限を与えないことが、最小権限の具体例です。実際のポリシーの細部は利用するサービスによって変わるため、導入時は公式ドキュメントとアクセス要件を確認します。

覚え方のまとめ

四つの用語を一文で区別すると、IAMユーザーは「長期認証情報を持てるAWSアカウント内のID」、IAMグループは「IAMユーザーをまとめる箱」、IAMロールは「一時的に引き受けるID」、IAMポリシーは「許可と拒否の内容」です。ロールとポリシーは常に一緒に語られやすいものの、ロールだけでは許可内容にならず、ポリシーだけでは操作主体になりません。

選択肢に「最小権限」「MFA」「rootユーザー」「アクセスキー」が現れたら、権限の広さと認証情報の扱いを分けて確認します。MFAはサインインの保護、最小権限は許可の範囲を絞る対策です。どちらか一方だけでなく、目的に応じて重ねて使います。CLFでは実装の構文より、この目的と効果の対応を確実に説明できる状態を目指しましょう。

迷ったときは、誰が操作し、何を許可し、認証情報をどこに置くかを順に問い直します。

関連用語

• IAM
• AWS Lambda
• Amazon DynamoDB