AWSアクセス管理とは、AWSアカウントへのサインイン者の決定、サインイン後に実行可能な操作の定義、そして身元の証明方法を担うAWSサービス・構成要素・実践の総体である。その中核サービスが**AWS Identity and Access Management（AWS IAM）**であり、最小権限の原則を実装するIAMユーザー、IAMグループ、IAMロール、IAMポリシーを作成できる。複数のAWSアカウントを持つ組織には、AWS IAM Identity Center（旧AWS SSO）がワークフォースアクセスを一元管理する手段として提供されている。AWS IAMとIAM Identity Centerはあわせて、AWS上のあらゆるAPIコールの認証・認可レイヤーを形成する。
CLF-C02試験のタスクステートメント2.3（「AWSアクセス管理機能の特定」）では、IAMユーザーとIAMロールの違い、IAMポリシーによる最小権限の適用、MFAの設定、rootユーザーの保護、そしてIAM Identity Centerを生のAWS IAMの代わりに使うべきタイミングの理解が求められる。本ガイドでは、すべての構成要素を平易な言葉で解説し、頻出の罠を整理したうえで、用語が定着する類比を提供する。
AWSアクセス管理（AWS IAM）とは何か？
AWSアクセス管理とは、あらゆるAWSサービスのリソースへのアクセスを制御するAWSネイティブのフレームワークである。主な実装手段はAWS IAMで、認証（本人確認）と認可（APIコールの可否判定）を担うグローバルかつ無料のAWSサービスだ。AWS IAMはアイデンティティ（IAMユーザー、IAMロール）、グループ（IAMグループ）、権限ドキュメント（IAMポリシー）を保管し、すべてのリクエストをリアルタイムでそれらのドキュメントと照合する。
AWSマネジメントコンソール、AWS CLI、AWS SDK、またはAWSマネジメントコンソールモバイルアプリを通じたあらゆるAWS APIリクエストは、実行前に必ずAWS IAMを経由する。AWS IAMが呼び出し元を識別できない場合、または呼び出し元のIAMポリシーに必要な権限が存在しない場合、リクエストは拒否される。だからこそAWSアクセス管理はAWS責任共有モデルの核心に位置する——アイデンティティとアクセス管理は常にお客様の責務であり、基盤サービスがどれほど管理されていても変わらない。
- AWS IAM：単一のAWSアカウント内でアイデンティティと権限を作成・管理するAWSサービス。
- IAM Identity Center：単一のサインオンポータルから複数のAWSアカウントにまたがってワークフォースアイデンティティをフェデレートするAWSサービス。
- IAMポリシー：特定のリソースに対する特定のAWS APIアクションを許可または拒否するJSONドキュメント。
- 最小権限（Least privilege）：ワークロードに絶対必要な権限のみを付与し、それ以上は与えないというセキュリティ原則。
- 参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html
CLF-C02においてAWSアクセス管理が重要な理由
CLF-C02のセキュリティおよびコンプライアンスドメインは試験全体の30%を占め、AWSアクセス管理（IAM、IAM Identity Center）はそのなかで最も頻繁に登場するサブトピックである。受験者が繰り返しつまずく問いは三つある。「IAMロールとIAMユーザーはいつ使い分けるか？」「アカウント作成直後にrootユーザーに対してすべきことは何か？」「フェデレーションされたワークフォースアクセス向けに認証情報を発行するAWSサービスはどれか？」——この三つを自信を持って答えられれば、CLF-C02のAWSアクセス管理問題でほとんどの受験者より有利に立てる。
やさしい解説: AWSアクセス管理
理論は具体的なものに対応づけると理解しやすい。CLF-C02に出るAWSアクセス管理の主要概念を網羅する三つの類比を紹介する。
類比1 — 新幹線の改札と自由席・指定席（入館証パターン）
大きな企業ビルを想像してほしい。IAMユーザーは社員証のようなもの——顔写真つきで特定の個人に紐づき、長期間有効なPINがあり、許可された扉だけを開けられる。IAMグループは部署ごとの共通ドアコード——「エンジニアリングチームは3・4・5番室に入れる」と一度設定すれば、全エンジニアの社員証がその権限を自動的に引き継ぐ。IAMロールはフロントに預けられた訪問者用ランヤード（一時バッジ）——誰でも（どのAWSサービスでも）警備員（AWS STS＝AWS Security Token Service）に申し出れば借りられ、用が済んだら返却する。誰もロールを恒久的に所持しない。rootユーザーは建物のオーナーが持つマスターキー——すべての錠を開けられるが、万が一紛失すれば壊滅的なため、金庫に厳重保管（rootの認証情報は保管、MFA有効化）し、唯一無二の作業にのみ使用する。
MFA（多要素認証）は社員証リーダーの後ろに設置された二つ目の改札——たとえ社員証が盗まれても、ハードウェアトークン・認証アプリ・パスキーを押せなければ入れない。IAMポリシーは各扉に貼られた規則書き（「エンジニアリングタグの社員証を持つ者のみ、8時から20時の間に入室可」）。IAM Identity Centerは企業の総合受付ロビー——訪問者が一度サインインするだけで、入場許可のある12棟のビル（AWSアカウント）に案内され、12回個別にバッジ認証しなくて済む。
類比2 — 模擬試験の監督ルール（試験官パターン）
持ち込み可能な参考書が制限された認定試験を受ける場面を想像してほしい。**試験監督（プロクター）がAWS IAMだ——本人確認（認証）をして、規則書（認可）でできることとできないことを照合する。規則書がIAMポリシーである。最小権限とは、規則書に「この三冊の参考書を使っていい」と書くことであり、「図書館のすべての本を使っていい」とは書かないこと——許可範囲が狭いほど、席が攻撃されたときの被害も小さい。IAMポリシーの明示的な拒否（Explicit Deny）**は監督の大きな赤い「禁止」サイン——他にどんな権限があっても、拒否が勝る。これがAWS IAMポリシー評価ロジックの核心だ：デフォルト拒否、許可の論理和、そして明示的な拒否はあらゆる許可を上書きする。
類比3 — ホテルのフロントデスクとルームキー（宿泊パターン）
ホテルはAWSアクセス管理を完璧に表現している。rootユーザーはホテルオーナー——万能マスターキーを持ち、ホテルの閉鎖、賃貸契約の名義変更、銀行口座の解約ができる唯一の存在だ。フロントデスク係がAWS IAM——ルームキー（IAMユーザー・IAMロール）を特定のアクセス権限（305号室のみ、プールのみ、ジムのみ）とともに発行する。チェックアウト時に失効するキーカードがIAMロール——一時的なアクセスを与え自動的に無効化されるため、置き忘れても長期的なリスクにならない。MFAはチェックイン時に書く署名と係員がスキャンした写真付きIDの組み合わせ——二つの要素が予約者本人であることを証明する。IAM Identity Centerはホテルチェーンのロイヤルティプログラム——一つのプロフィールとサインオンで、グループ傘下の200軒（AWSアカウント）のどこでもチェックインでき、毎回新規アカウントを作らなくて済む。
試験当日、問題に「IAMロール」が出てきたら、一時的な訪問者用ランヤードまたはチェックアウト時に失効するキーカードを頭に浮かべること——CLF-C02でIAMロールとIAMユーザーを混同するという第1位の罠を防げる。参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
基本動作原理 — アイデンティティ・認証・認可
あらゆるAWS IAMの判断は同じ三段階のパイプラインをたどる：識別、認証、認可。これをマスターすれば、あらゆるAWSアクセス管理問題が解析しやすくなる。
識別：誰がリクエストを行っているか？
リクエストがAWSに届くと、AWS IAMはプリンシパル——コールを行うIAMユーザー、IAMロール、AWSサービス、またはフェデレーションアイデンティティ——を抽出する。プリンシパルはリクエスト署名（AWS CLIやSDKのコール）に埋め込まれているか、アクティブなAWSマネジメントコンソールセッションから推論される。有効なプリンシパルがなければ評価するものが存在せず、リクエストは即座に拒否される。
認証：プリンシパルは本当に本人か？
認証はプリンシパルが有効な認証情報を保有していることを証明する。IAMユーザーの場合、ユーザー名とパスワード（AWSマネジメントコンソール）またはアクセスキーIDとシークレットアクセスキー（AWS CLI、SDK）を使う。IAMロールの場合、呼び出し元はAWS Security Token Service（AWS STS）が事前に発行した一時的な認証情報（アクセスキーID・シークレットアクセスキー・セッショントークン）を提示する。多要素認証（MFA）は、仮想MFAデバイスからの時間ベースのワンタイムパスワード（TOTP）、FIDO2ハードウェアキー、またはパスキーといった第二の要素をその上に重ねる。
認可：プリンシパルはこれを実行する権限を持つか？
認可はIAMポリシーの評価である。AWS IAMは、プリンシパルに紐づくアイデンティティベースポリシー、対象リソースに紐づくリソースベースポリシー、権限境界、AWS Organizationsサービスコントロールポリシー（SCP）、セッションポリシーを収集し、定義されたアルゴリズムで処理する。結果は常に二択だ：Allow（許可）またはDeny（拒否）。
- デフォルトでは、すべてのリクエストが暗黙的に拒否される。
- 適用されるIAMポリシーのいずれかにある明示的なAllowが判定をAllowに反転させる。
- 適用されるIAMポリシーのいずれかにある明示的なDenyがすべてのAllowを上書きする。
- AWS OrganizationsレベルのSCP（サービスコントロールポリシー）は、メンバーアカウントのIAMポリシーが付与できる内容を制限できるが、SCPだけでは権限を付与しない。
参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
IAMの構成要素：ユーザー・グループ・ロール・ポリシー
AWS IAMには四つのプリミティブがあり、CLF-C02のすべての問題はここから構成される。それぞれが何であるか——さらに重要なことに、それぞれが何でないか——を知ることが、AWSアクセス管理スコアに対する最大のレバーとなる。
IAMユーザー
IAMユーザーは一つのAWSアカウント内の単一アイデンティティを表し、一般的には人間または長期稼働する外部アプリケーションに対応する。IAMユーザーは一意の名前を持ち、コンソールパスワードを設定でき、最大2つのアクティブなアクセスキー（ダウンタイムなしでローテーションするため）を持てる。IAMユーザーの認証情報は設計上長期間有効であるため、AWSアクセス管理においてリスクが最も高い構成要素であり、できる限り使用を最小限にすべきだ。AWSのベストプラクティスでは、可能な限り新規IAMユーザーの代わりにIAMロールやIAM Identity Centerを優先することを推奨している。
IAMグループ
IAMグループはIAMユーザーをまとめるコンテナであり、IAMポリシーを一度アタッチするだけですべてのメンバーに適用できる。ユーザーは複数のIAMグループに所属できる。グループはアイデンティティではない——「グループとしてサインイン」したりグループに認証情報を埋め込んだりすることはできない——IAMポリシー管理をスケーラブルにするための純粋な構造体だ。
IAMロール
IAMロールはIAMポリシーがアタッチされたアイデンティティだが、長期的な認証情報を持たない。代わりに、プリンシパル（AWSサービス、AWSアカウント、フェデレーションユーザー、別のAWSアカウントのIAMユーザー）がロールを引き受け（assume）、AWS STSから一時的なセキュリティ認証情報を受け取る。一時的な認証情報は期限切れになり（デフォルト1時間、多くのワークフローで最大12時間まで設定可能）、永続的なシークレットを残さない。IAMロールが適切なAWS IAM構成要素となる場面は次のとおりだ：
- AMIにアクセスキーを埋め込まずに、Amazon EC2インスタンスにAmazon S3へのアクセスを付与する（EC2インスタンスプロファイル）。
- ハードコードされた認証情報なしに、AWS Lambda関数にAmazon DynamoDBへの書き込みを許可する。
- アカウントAのユーザーやサービスがアカウントBのリソースに時折アクセスするクロスアカウントアクセス。
- 企業のアイデンティティプロバイダー（SAML 2.0、OIDC、GoogleやFacebook、Amazon Cognitoなどのウェブアイデンティティプロバイダー）からのアイデンティティフェデレーション。
IAMポリシー（マネージドポリシーとインラインポリシー）
IAMポリシーは、特定のリソースに対する許可または拒否されたAWS APIアクションを列挙し、オプションで条件でフィルタリングするJSONドキュメントだ。配信形式は二種類ある：
- マネージドポリシーは、一度作成して多数のアイデンティティにアタッチできるスタンドアロンのIAMポリシーオブジェクトだ。AWSマネージドポリシーはAWSが事前に構築・維持している（例：
AmazonS3ReadOnlyAccess）。カスタマーマネージドポリシーはお客様が作成・バージョン管理するものだ。 - インラインポリシーは単一のIAMユーザー、IAMグループ、またはIAMロールに直接埋め込まれ、それとともに生存・消滅する。アイデンティティと権限の間に厳密な1対1の結びつきが必要な場合にインラインIAMポリシーを使用し、再利用性のために他の場合はすべてマネージドIAMポリシーを使用すること。
CLF-C02では、AWSがインラインIAMポリシーよりもマネージドIAMポリシーを推奨していることを覚えておくこと——マネージドポリシーは再利用可能で、バージョン管理でき、監査しやすい。インラインIAMポリシーは1対1の密結合が必要な場合には適しているが、スケールしない。参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
IAMユーザーとIAMロールの違い — 使い分けの鍵
これはCLF-C02のAWSアクセス管理問題で最も試験に出る区別だ。ここで間違えると、セキュリティドメイン全体にわたって問題を落とすことになる。
IAMユーザーが適切な場面
IAMユーザーは長期的な認証情報を持つ永続的なアイデンティティが必要な場合に適している。代表的な例：AWSアカウントの最初期にAWSマネジメントコンソールにサインインする少人数チームの人間、ロールの引き受けをサポートしないサードパーティの監視ツール、またはレガシーのオンプレミススクリプト。IAMユーザーはそれぞれが長期的な認証情報管理のオーバーヘッド（ローテーション、オフボーディング、MFA登録）を追加する。
IAMロールが適切な場面
IAMロールは、呼び出し元が何週間・何ヶ月にもわたって認証情報を保持する必要がない場合に常に適切だ。CLF-C02の主要シナリオは次のとおりだ：
- EC2サービスアクセス：インスタンスプロファイル経由でIAMロールをAmazon EC2インスタンスにアタッチする。Amazon EC2インスタンスメタデータサービスがローテーションされた短期認証情報をアプリケーションに公開する。ユーザーデータにもソースコントロールにもシークレットは不要。
- クロスアカウントアクセス：AWSアカウントAのユーザーまたはサービスが
sts:AssumeRoleでAWSアカウントBのIAMロールを引き受け、短期認証情報を取得し、作業を実行し、後始末なく終了する。 - フェデレーション：SAML 2.0のアイデンティティプロバイダー（Active Directory Federation Servicesなど）またはウェブアイデンティティプロバイダー（Amazon Cognitoユーザープールなど）がアサーションを発行し、AWS IAMがそのアサーションを信頼して、選択されたIAMロールに紐づく短期認証情報を返す。
CLF-C02で繰り返し登場する罠は、「一時的な権限を持つIAMユーザー」や「パスワードを持つIAMロール」を説明する選択肢だ。どちらも実在しない。IAMユーザーは常に長期認証情報を持ち、オプションでパスワードを持つ。IAMロールはパスワードを持たず、長期認証情報も持たず、引き受けられたときに常にAWS STSを通じて短期認証情報を発行する。シナリオに「Amazon EC2インスタンスにAmazon S3へのアクセスを与える」または「1時間だけアカウントAからアカウントBのワークロードにアクセスさせる」と書かれていれば——それはIAMロールであり、IAMユーザーではない。参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
比較表
| 観点 | IAMユーザー | IAMロール |
|---|---|---|
| 認証情報の有効期間 | 長期（コンソールパスワード＋アクセスキー） | 短期、引き受け時にAWS STSが発行 |
| パスワード？ | 任意 | 持たない |
| 誰が使うか？ | 特定の人物または外部システム | ロールの信頼ポリシーで許可された任意のプリンシパル |
| ベストプラクティス | 数を最小化しIAM Identity Centerを優先 | AWSサービス・クロスアカウント・フェデレーションに最適 |
| CLF-C02の典型的な手がかり | 「長期」「コンソールログイン」「個人エンジニア」 | 「EC2ロール」「クロスアカウント」「一時的」「フェデレーション」 |
最小権限の原則 — マネージドポリシーとインラインポリシー
最小権限はAWSアクセス管理の根本原則だ：各IAMユーザー、IAMグループ、またはIAMロールに対して、タスクを実行するために必要な権限だけを、必要な最短期間だけ付与する。これはAWS IAMユーザーガイドで最も強調されているベストプラクティスであり、CLF-C02のシナリオ問題に繰り返し登場する。
狭い権限から始める
すべてのIAMポリシーは最小限のAPIアクションセットと特定のリソースARNから始めること。"Action": "*"から始めて「削っていく」アプローチをとってはいけない——そのやり方では通常、ワークロードが実際に必要とする以上の権限が混入する。AWSマネージドポリシーが職務に近い場合はベースラインとして使用してもよいが、ワークロードが実際に実行するアクションに調整したカスタマーマネージドIAMポリシーを優先すること。
IAM Access Analyzer
AWS IAM Access AnalyzerはAWS IAM内のフィーチャーで、最小権限を自動的に達成するのに役立つ。CLF-C02で重要な二つの機能がある：
- 外部アクセス分析——リソースベースのIAMポリシー（Amazon S3バケットポリシー、IAMロール信頼ポリシー、AWS KMSキーポリシーなど）を継続的にスキャンし、信頼境界外のプリンシパルにアクセスを付与するものにフラグを立てる。
- 未使用アクセス分析とポリシー生成——ルックバックウィンドウ内のAWS CloudTrailアクティビティを検査し、アイデンティティが実際に使用したものだけを付与する洗練されたIAMポリシーを生成する。
「組織がIAMポリシーに必要な権限のみを付与していることをどのように確認できるか」と試験で問われたら、答えはほぼ常にAWS IAM Access Analyzerだ。最小権限を達成するためのAWSセキュリティベストプラクティスガイダンスで明示的に名指しされているAWS IAMフィーチャーである。参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
権限境界とセッションポリシー
最小権限をさらに厳格にする二つの高度なIAMポリシータイプがある：
- **権限境界（Permissions boundary）**は、アイデンティティベースのIAMポリシーがIAMユーザーまたはIAMロールに付与できる最大権限を設定する高度な機能だ。境界自体は権限を付与しない——他のIAMポリシーが付与できる内容を上限として制限するだけだ。
- セッションポリシーはAWS STSを通じてロールを引き受ける際に渡され、基盤となるIAMロールを変更せずにその特定のセッションの有効な権限を絞り込む。
どちらの構成要素も誤った過剰権限を防ぐために存在し、どちらもCLF-C02に気を散らすオプションとして時折登場する。
rootアカウントのセキュリティ — rootにのみ可能なことと保護方法
rootユーザーはAWSアカウントを最初に開設する際にメールアドレスで作成されるアカウントオーナーだ。そのAWSアカウント内のすべてのリソースとすべての請求設定に対して無条件・無制限のアクセス権を持つ。この強力さが、同時にrootユーザーがアカウント上の最大のリスクである理由でもある。
rootユーザーにのみ可能なこと
一握りのタスクはrootユーザーのみが実行でき、IAMポリシーがどれほど権限を持っていても、いかなるIAMユーザーまたはIAMロールにも委任できない：
- AWSアカウントのメールアドレスまたはrootパスワードの変更。
- AWSアカウント名の変更。
- AWSアカウントの閉鎖。
- AWSサポートプランの変更またはキャンセル。
- すべての管理者IAMユーザーがロックアウトされた場合のIAMユーザー権限の復元（アカウント回復）。
- AWS Marketplaceでの出品者登録。
- 一部のAWS請求および税情報の設定。
rootユーザーの保護方法
rootユーザーに関するAWS IAMのベストプラクティスは簡潔・具体的で、試験によく出る：
- rootユーザーは初回セットアップのみに使用し、直後に管理者権限を持つIAMユーザー（またはより望ましくはIAM Identity Centerユーザー）を作成して日常的な管理に使う。
- rootユーザーのMFAを有効化する。 CLF-C02では「新しいAWSアカウントを作成した後に最初にすべきことは何か？」という問いでよく表現され、答えは「rootユーザーのMFAを有効化する」だ。
- rootのアクセスキーを削除または無効化する。 rootのアクセスキーが存在する場合は、ローテーションまたは削除する。rootユーザーのプログラムによる使用は強く推奨されない。
- rootユーザーには強力でユニークなパスワードを使用し、認証情報を物理的に保管する。
- いかなる状況でもrootユーザーを共有しない。複数人が管理者アクセスを必要とする場合、各自に管理者IAMポリシーを持つ独自のアイデンティティを付与すること。
CLF-C02の典型的な罠：rootユーザーができることを制限するIAMポリシーをrootユーザーにアタッチすることはできない。AWS Organizationsの**サービスコントロールポリシー（SCP）**でさえ、メンバーアカウントに対するのと同じように管理アカウントのrootユーザーには明示的に適用されない。唯一効果的な保護は、初回セットアップとroot専用タスクのみにrootユーザーを使用し、rootの認証情報とMFAを厳重に保管することだ。参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
認証方法：MFA・アクセスキー・パスワードポリシー
AWS IAMは複数の認証要素をサポートしており、CLF-C02はそれらを区別できるかをテストする。
コンソールパスワードとパスワードポリシー
すべてのIAMユーザーはオプションでコンソールパスワードを持てる。アカウントごとのIAMパスワードポリシーは、最小文字数、文字種、ローテーション期間、再利用防止、ユーザー自身によるパスワード変更の可否を強制する。パスワードポリシーはAWSアカウント内のすべてのIAMユーザーに適用されるが、rootユーザーには適用されない（rootユーザーは独自の強力なパスワード要件を持つ）。
アクセスキー
アクセスキーはAWS CLI・AWS SDK・AWS PowerShellが使用する長期認証情報（アクセスキーID＋シークレットアクセスキー）だ。各IAMユーザーは最大2つのアクティブなアクセスキーを持てるため、古いキーを削除する前に新しいキーをプロビジョニングでき、ダウンタイムなしのローテーションが可能だ。非人間のワークロードには、長期シークレットを完全に回避するためにアクセスキーをIAMロール（EC2インスタンスプロファイル、Lambda実行ロール、ECSタスクロール）に置き換えることをAWSは強く推奨している。
MFA — 仮想・ハードウェア・パスキー
多要素認証はパスワードの上に第二の要素を追加する。AWS IAMは三種類をサポートする：
- 仮想MFAデバイス——スマートフォンの認証アプリ（Google Authenticator、Authy、1Passwordなど）が回転する6桁の時間ベースのワンタイムパスワード（TOTP）を生成する。最も安価で一般的。
- ハードウェアMFAデバイス——物理的なキーフォブ（AWSはGemalto/SafeNetデバイスを販売）またはFIDO2セキュリティキー（YubiKeyなど）。ハードウェアデバイスからシークレットをコピーできないため、仮想MFAよりも堅牢。
- パスキー／FIDOオーセンティケーター——AWSはiOS・Android・macOS・Windows Hello・ハードウェアセキュリティキーに内蔵されたパスキーをサポートする。パスキーはフィッシング耐性があり、IAMユーザーとrootユーザー双方に推奨される現代的な要素だ。
- MFAはrootユーザーに必須であり、高い権限を持つすべてのIAMユーザーにも有効化すべきだ。
- 仮想MFA＝認証アプリ。ハードウェアMFA＝物理トークン。パスキー＝FIDOベース、フィッシング耐性あり。
- MFAは無料——有効化するためにAWSの費用はかからない（物理ハードウェアトークンを購入する場合のみ費用が発生）。
- 参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html
IAM Identity Center（SSO）— フェデレーテッドアクセスとクロスアカウント管理
AWS IAM Identity Center（旧AWS Single Sign-On、今でもAWS SSOと呼ばれることがある）は、ワークフォースアイデンティティ——一つまたは複数のAWSアカウントにサインインする必要のある組織内の人間——のためのAWSアクセス管理サービスだ。2026年現在、AWSにおける人間のアクセス管理の推奨方法である。
IAM Identity Centerの機能
- シングルサインオンポータルを提供する。ユーザーが企業アイデンティティで一度ログインすると、権限のあるすべてのAWSアカウントとSaaSアプリケーションのタイルが表示される。
- SAML 2.0またはOIDCを通じて既存の企業アイデンティティプロバイダーとフェデレートする——一般的な統合にはMicrosoft Entra ID（旧Azure AD）、Okta、Ping Identity、Google Workspace、AWS Directory Service経由のオンプレミスActive Directoryが含まれる。
- 既存のIdPを持たない組織向けに独自のアイデンティティストア（内蔵ディレクトリ）として動作することもできる。
- AWS Organizations構造内のAWSアカウントに適用される権限セットを管理する——ユーザーは権限セットにマッピングされ、IAM Identity Centerが各ターゲットAWSアカウントに必要なIAMロールを自動的に実体化する。
- AWS CLI v2セッション向けに短期認証情報を発行するため、エンジニアはラップトップに長期アクセスキーを保存する必要がない。
IAM Identity Centerと生のAWS IAMの使い分け
| シナリオ | 推奨構成要素 |
|---|---|
| ワークフォースユーザー（従業員）が一つまたは複数のAWSアカウントにアクセスする | IAM Identity Center |
| 企業アイデンティティプロバイダーからのフェデレーテッドアクセス | IAM Identity Center（最も簡単）またはIAMロールへのSAMLフェデレーション |
| AWSサービス→AWSサービスアクセス（Amazon EC2→Amazon S3） | IAMロール |
| AWSアカウント間の一時的なクロスアカウントアクセス | IAMロール（sts:AssumeRoleで引き受け） |
| ロールを引き受けられない外部アプリ | IAMユーザー（最終手段、厳格な最小権限IAMポリシーつき） |
AWSの現在のベストプラクティスでは、各アカウントにIAMユーザーを作成する代わりに、マルチアカウントAWS環境のデフォルトのワークフォースアクセス機構としてIAM Identity Centerを推奨している。現在多くのCLF-C02問題がマルチアカウントのシナリオを示し、IAM Identity Centerを解答として期待する。シナリオに「従業員」「ワークフォース」「一度サインインする」「複数のAWSアカウント」「SAML 2.0/OIDCフェデレーション」と書かれていれば、最初の候補はIAM Identity Centerだ。参考: https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
アイデンティティフェデレーション — SAML 2.0・ウェブアイデンティティ・Cognito
アイデンティティフェデレーションにより、別の場所にすでにアイデンティティを持つユーザーに、IAMユーザーを新規作成せずにAWSアクセスを付与できる。
SAML 2.0フェデレーション
ワークフォースがSAML 2.0のアイデンティティプロバイダー（Microsoft Entra ID、Active Directory Federation Services、Okta、Ping）にすでに存在する場合、次の二つの方法がある：
- IAM Identity Centerを使用する（最も簡単。IAM Identity CenterがすべてのAWSアカウントに対してSAMLの関係を仲介する）、または
- AWS IAM内にSAML 2.0アイデンティティプロバイダーを設定し、SAMLアサーションをそのプロバイダーを信頼するIAMロールにマッピングする。
どちらの方法も最終結果は同じだ：ユーザーが企業のIdPでサインインし、SAMLアサーションを取得し、AWS STSを通じて交換し、短期認証情報を受け取る。
ウェブアイデンティティフェデレーションとAmazon Cognito
AWS APIを呼び出す必要があるカスタマー向けのモバイルおよびウェブアプリケーション（例えばユーザー写真をAmazon S3にアップロードするアプリ）には、Amazon CognitoユーザープールとアイデンティティプールAmazon Cognito user pools and identity poolsが推奨される統合方法だ。CognitoはGoogle、Apple、Facebook、Amazon、またはOIDC準拠プロバイダーでのサインインを処理し、ソーシャルログイントークンをIAMロールに紐づく短期AWS認証情報に交換する。
直接のウェブアイデンティティフェデレーション（OIDCからIAM）は引き続きサポートされているが、Amazon Cognitoはユーザーディレクトリ・MFA・ユーザー移行・属性マッピングを処理する高レベルのAWSサービスでラップしている。
フェデレーションでは永続的な認証情報が残らない
SAMLとウェブアイデンティティフェデレーションのどちらも、ユーザーのデバイスやIdPに長期的なAWS認証情報を残さない——ユーザーは自動的に期限切れになる一時的なSTS認証情報を受け取る。これはAWSセキュリティの核心的な利点であり、CLF-C02の一般的なシナリオだ（「長期的なAWS認証情報を回避するアプローチはどれか？」→IAMロールによるアイデンティティフェデレーション）。
AWS IAMはグローバルサービスであり、リージョンスコープではない
AWS IAMはグローバルなAWSサービスだ。IAMユーザー、IAMグループ、IAMロール、IAMポリシーはAWSアカウントごとに一度作成され、すべてのAWSリージョンで即座に利用可能になる。IAMユーザーを作成するときにリージョンを選択することはなく、ワークロードをデプロイするすべてのリージョンでIAMユーザーを再作成することもない。ワークフォースポータルのIAM Identity Centerのディレクトリと権限セットも同様だが、IAM Identity Centerインスタンス自体は一つのホームリージョンにプロビジョニングされる。
「us-east-1にIAMユーザーを作成する」や「リージョン間でIAMポリシーをレプリケートする」などを示す選択肢は誤りだ。AWS IAMはグローバルであり、IAMアイデンティティをリージョン間でレプリケートすることは決してない。これをAWS Identity and Access Management Roles AnywhereやAmazon Cognitoユーザープール（リージョンAWSサービス）と混同しないこと。参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html
AWS IAMとAWS Organizations — アカウントレベルとマルチアカウント制御
CLF-C02のAWSアクセス管理問題では、AWS IAMとAWS Organizationsおよびその**サービスコントロールポリシー（SCP）**が混在することがある。これらは補完的であり、競合するものではない。
- AWS IAMは単一のAWSアカウント内のアイデンティティができることを制御する。
- AWS OrganizationsはAWSアカウント全体（または組織単位）が、その中のすべてのアイデンティティを含めて何を許可されるかを制御する。
- サービスコントロールポリシー（SCP）はAWS Organizationsのガードレール——メンバーアカウント内の任意のIAMポリシーが付与できる最大権限を設定する。SCPは自体では決して権限を付与せず、制限するだけだ。
- AWS IAM Identity CenterはAWS Organizationsの上に位置し、メンバーAWSアカウント全体にわたってワークフォースアイデンティティを権限セットに割り当てる。
CLF-C02の一般的な罠：「IAMポリシーがs3:*を付与しているのに、ユーザーがAmazon S3に書き込めない——なぜか？」典型的な答えは、AWS Organizationsレベルのアカウント全体に対してアクションをブロックするSCPが存在することだ。SCPは外側の境界を定義し、IAMポリシーはその境界内を埋める。アクションが成功するには両方で許可される必要がある。参考: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
認証情報の保管：AWS Secrets ManagerとAWS Systems Manager Parameter Store
AWSアクセス管理はサインインする人だけに関するものではない——アプリケーションがデータベース・API・サードパーティサービスの認証情報をどのように保管するかもカバーする。二つのAWSサービスがCLF-C02の認識レベルでテストされる：
- AWS Secrets Manager——自動ローテーション（Amazon RDS・Amazon Redshift・Amazon DocumentDBで特に優れている）を内蔵した専用シークレット保管AWSサービス。シークレットごとの課金。ローテーション・クロスアカウント共有・きめ細かなアクセスが重要な場合に使用する。
- AWS Systems Manager Parameter Store——バージョン管理つきの平文および暗号化された設定パラメータの無料ティア。一般的な設定やローテーションが不要な軽量シークレット保管に適している。
どちらのAWSサービスもAWS IAMポリシーと統合されており、指定されたIAMユーザー・IAMロール・IAM Identity Center権限セットのみが特定のシークレットを読み取れる。これにより、データベースパスワードやサードパーティAPIキーがソースコントロールやAmazon EC2のユーザーデータスクリプトから除外される。
AWSアクセス管理の重要な数値と暗記事項
この短いリストを暗記すること。CLF-C02のIAMに関する数値的・分類的な罠の大部分をカバーしている。
- AWS IAMはグローバル——リージョンスコープではない。
- AWS IAMは無料——IAMユーザー・IAMロール・IAMポリシー・MFAに直接費用はかからない。
- IAMユーザーごとに最大2つのアクティブなアクセスキー（ローテーション用）。
- MFAの種類：仮想（認証アプリ）、ハードウェア（物理トークン、FIDO2）、パスキー。
- 引き受けられたIAMロールのデフォルトセッション期間：1時間（ほとんどのフローで最大12時間まで設定可能）。
- rootユーザー＝初回セットアップとroot専用アクションのみ；即時MFA有効化；認証情報の厳重保管。
- 最小権限の原則——最小限の権限を付与し、AWS IAM Access Analyzerで監査する。
- IAM Identity Center＝ワークフォースアイデンティティ、旧AWS SSO名の置き換え。
- SCPはメンバーアカウントのIAMポリシーが付与できるものを制限し、自体では決して付与しない。
- 参考: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
頻出の試験の罠 — AWSアクセス管理
CLF-C02の受験ごとに少なくとも一つ以上登場する。選択肢を読む前にパターンを見抜けるよう学ぼう。
罠1：IAMロールとIAMユーザー
「一時的な認証情報を持つIAMユーザー」や「長期アクセスキーを持つIAMロール」を説明する選択肢は罠だ。IAMユーザー＝長期認証情報。IAMロール＝AWS STSが発行する短期認証情報。シナリオにAmazon EC2インスタンス・AWS Lambda関数・クロスアカウントアクセスが含まれる場合、正しいAWSアクセス管理構成要素はIAMロールだ。
罠2：rootユーザーと管理者IAMユーザー
「管理者」とは「AdministratorAccess IAMポリシーがアタッチされている」を意味する。「rootユーザー」とは元のアカウントオーナーを意味する。両者は同一人物ではない。rootには管理者が持てない権限がある（AWSアカウントの閉鎖、rootメールの変更）。日常的な管理はrootユーザーではなく、IAMユーザーまたはIAM Identity Centerユーザーで行うべきだ。
罠3：AWS IAMとIAM Identity Center
AWS IAMはアカウント内のアイデンティティサービスだ。IAM Identity Centerはマルチアカウントのワークフォースポータルだ。「従業員」「シングルサインオン」「複数のAWSアカウント」「SAML」に言及する問題は通常IAM Identity Centerを求めている。「Amazon EC2インスタンスにAmazon S3へのアクセスを付与する」に言及する問題はAWS IAMロールを求めている。
罠4：AWS IAMはリージョンスコープではない
リージョンごとにIAMユーザーを作成する、リージョン間でIAMポリシーをレプリケートする、またはAWS IAMのリージョンを選択することを示す選択肢はすべて誤りだ。AWS IAMはグローバルだ。
罠5：SCPは付与せず、制限のみする
s3:DeleteBucketを拒否するSCPが存在する場合、そのメンバーアカウントのどのIAMポリシーもs3:DeleteBucketを付与できない——どれほど寛大であっても。しかしs3:DeleteBucketを許可するSCPはそれだけでは権限を付与しない——メンバーアカウントのIAMポリシーも付与する必要がある。
罠6：MFAはrootとIAMユーザーの両方に対して有効
MFAはrootユーザーのみに必要と示唆する問題がある。MFAはrootユーザーにかつ高い権限を持つすべてのIAMユーザーにも——特に管理者レベルのIAMポリシーを持つIAMユーザーに——有効化すべきだ。
AWSアクセス管理とAWSセキュリティガバナンスのスコープ境界
AWSアクセス管理（タスク2.3——AWS IAM、IAM Identity Center）は、誰がサインインし何ができるかに関するものだ。セキュリティガバナンスとコンプライアンス（タスク2.2——AWS Config・AWS Organizations・AWS Control Tower・AWS Artifact）は、アイデンティティレイヤーの上にある組織のガードレール・コンプライアンス証明・検出的/予防的コントロールに関するものだ。AWS Organizations（アクセス管理制限に使用されるSCPとガバナンスに使用されるガードレールの両方をホストする）とAWS IAM Access Analyzer（アクセス管理とガバナンスにまたがる）では両者が重複する。CLF-C02の問題が「誰が何をできるか」に関するものであればアクセス管理、「アカウントが準拠した形で設定されているか」に関するものであればガバナンスだ。
練習問題リンク — タスク2.3対応シナリオ
- 「長期認証情報なしにAmazon EC2インスタンスにAmazon S3へのアクセスを付与するAWSサービスはどれか？」→ IAMロール（インスタンスプロファイル経由でアタッチ）。
- 「新しいAWSアカウントを作成した直後に企業が行うべきことは何か？」→ rootユーザーのMFAを有効化し、日常的な管理用の管理者IAMユーザーまたはIAM Identity Centerユーザーを作成する。
- 「15のAWSアカウントを持つ企業がワークフォースのサインインをどのように管理すべきか？」→ 企業アイデンティティプロバイダーとフェデレートしたIAM Identity Center。
- 「必要以上の権限を付与しているIAMポリシーを特定するのに役立つAWSサービスはどれか？」→ AWS IAM Access Analyzer。
- 「一時的なクロスアカウントアクセスに最適なAWS IAM構成要素はどれか？」→ AWS STSで引き受けるIAMロール。
FAQ — AWSアクセス管理のよくある質問
Q1：AWS IAMとIAM Identity Centerの違いは何か？
AWS IAMは一つのAWSアカウント内でアイデンティティとIAMポリシーを管理する——IAMユーザー・IAMグループ・IAMロール・IAMポリシー。AWS IAM Identity Center（旧AWS SSO）はAWS Organizationsの上に位置し、シングルサインオンポータル、SAML/OIDCフェデレーション、そして多数のAWSアカウントにわたってIAMロールにマッピングされる権限セットを提供する。2026年現在、IAM Identity Centerはマルチアカウント環境でのワークフォースアクセスに推奨されるデフォルトであり、AWS IAMはAWSサービス・アプリケーション・クロスアカウントロール向けの低レベルのプリミティブAWSアクセス管理サービスとして残る。
Q2：IAMユーザーとIAMロールはいつ使い分けるべきか？
短期認証情報を発行し永続的なシークレットを残さないため、可能な限りIAMロールを使用すること。IAMロールはAmazon EC2サービスアクセス・AWS Lambda実行・クロスアカウントアクセス・フェデレーションに適切なAWS IAM構成要素だ。IAMユーザーは、長期的・永続的なアイデンティティが本当に必要な場合——例えばロールの引き受けができないサードパーティツール——のみに使用し、リスクを抑えるために最小権限＋MFA＋アクセスキーローテーションを適用すること。
Q3：AWSアカウント作成直後にrootユーザーに対してすべきことは何か？
即座にrootユーザーのMFAを有効化し（仮想MFAデバイス・ハードウェアMFAデバイス・またはパスキー）、rootのアクセスキーを削除し、強力でユニークなパスワードを設定し、その後の管理タスクのための別の管理者アイデンティティ——理想的にはIAM Identity Centerユーザー、またはAdministratorAccess IAMポリシーを持つIAMユーザー——を作成すること。rootの認証情報を保管し、AWSアカウントの閉鎖やrootメールの変更などのroot専用アクションのみ取り出す。
Q4：AWSは最小権限の原則をどのように実装するか？
最小限のIAMポリシーから始め、ワークロードが実証的に必要とする場合にのみ権限を追加する。AWS IAM Access Analyzerを使用して外部アクセスを検出し、AWS CloudTrailアクティビティから洗練されたIAMポリシーを生成する。再利用性のためにインラインポリシーよりもマネージドポリシーを優先し、他のIAMロールを作成するIAMロールには権限境界を使用し、最上位のガードレールとしてAWS OrganizationsのSCPを追加する。CLF-C02では「最小権限」と「IAM Access Analyzer」は強く結びついている。
Q5：AWS IAMは無料か？MFAは無料か？
はい。AWS IAMは無料のAWSサービスだ——IAMユーザー・IAMグループ・IAMロール・IAMポリシーに費用はかからない。MFAも無料で、物理ハードウェアMFAトークンを購入する場合のみ費用が発生し、パスキーや仮想MFAアプリは費用ゼロだ。もちろんIAMポリシーがアクセスを付与するAWSリソース（Amazon EC2・Amazon S3など）については課金されるが、AWS IAM自体への課金はない。
Q6：IAMポリシーやSCPでAWS rootユーザーができることを制限できるか？
いいえ。IAMポリシーでAWSアカウントのrootユーザーを意味のある形で制限することはできず、AWS Organizationsレベルのは同じようにメンバーアカウントに適用される方法で管理アカウントのrootユーザーには適用されない。rootユーザーに対する唯一の効果的な保護は、使用しないことだ——MFAを有効化し、アクセスキーを削除し、認証情報を保管し、日常業務をIAMユーザー・IAMロール・IAM Identity Center権限セットに委任すること。
Q7：SAMLフェデレーションとAmazon Cognitoの違いは何か？
SAML 2.0フェデレーションはワークフォースのパターンだ——企業アイデンティティプロバイダー（Microsoft Entra ID・Active Directory Federation Services・Okta・Ping）がSAMLアサーションを発行し、AWS IAMまたはIAM Identity Centerがそれを信頼し、ユーザーはIAMロールの短期認証情報を受け取る。Amazon Cognitoはカスタマー向けのパターンだ——ユーザープールがアプリケーションのエンドユーザーのサインアップとサインインを管理し、アイデンティティプールがサインイントークンをIAMロールに紐づく短期AWS認証情報に交換する。ワークフォース＝SAML＋IAM Identity Center；アプリのカスタマー＝Amazon Cognito。