週1AWS基礎 ＋ IAM
2026-08-06（木）AWS基礎＋IAM（権限管理）
1. 【この範囲の全体像】
本範囲（第7章7-4・7-5）は、企業規模のマルチアカウント環境やオンプレミスとクラウドが混在するハイブリッド環境において、ユーザーの認証情報をいかに安全かつ効率的に一元管理（シングルサインオン等）するかを扱います [p.187, p.190]。
AWS Organizations内の複数アカウントやSaaSへのアクセス権限を一元統制する 「 AWS IAM アイデンティティセンター 」 [p.187] 、およびオンプレミスのActive Directory（AD）資産をAWS上に拡張・連携させる3つの選択肢を持つ 「 AWS Directory Service 」 の仕様を深く理解することは [p.190] 、試験で最も配点の高いセキュリティ設計分野を攻略する上で極めて重要な防衛ラインとなります [p.5]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| AWS IAM アイデンティティセンター（旧 AWS Single Sign-On） [p.187] | AWS Organizationsとネイティブに統合し、組織内の複数アカウントや外部SaaSアプリケーションへのログインを一元管理・制御するシングルサインオン（SSO）サービス [p.187]。 |
| AWS Directory Service [p.190] | AWS上でMicrosoft Active Directory（AD）を稼働させる、またはオンプレミスのADと認証をハイブリッド連携させるためのマネージドサービス群 [p.190]。 |
| AWS Managed Microsoft AD [p.190] | AWS上で実際のWindows Server Active Directoryを冗長構成（マルチAZ）で実行し、AWSがインフラ管理を担うフルマネージドなAD環境 [p.190]。 |
| AD Connector [p.190] | AWS上にユーザー情報やディレクトリデータを一切保持・複製せず、AWSへのログイン認証要求のみを既存のオンプレミスADへそのまま安全に転送（プロキシ中継）するコネクター機能 [p.190]。 |
| Simple AD [p.190] | Samba 4をベースとしてデプロイされる、安価で軽量なLinuxベースのActive Directory互換ディレクトリサービス [p.190]。 |
| 信頼関係（Trust Relationship） | 異なるActive Directoryドメイン間でユーザー認証情報をお互いに信頼し、一方のドメインのユーザーが他方のドメインのリソースへセキュアにアクセスできるようにする認証連携機能。 |
| SAML 2.0フェデレーション | 外部のアイデンティティプロバイダー（IdP）とAWS IAMの間で、パスワードを共有せずに信頼トークンをやり取りしてシングルサインオンを実現する標準的な業界規格。 |
3. 【試験で問われる比較ポイント】
① AWS Directory Serviceにおける「3大ディレクトリ」の決定的な使い分け [p.190]
「既存AD資産の有無」「ADとしての機能要件（信頼関係の要否など）」「コスト」の3点から、試験問題に潜むシグナルを読み取って選定します [p.190]。
| サービスタイプ | AWS上のデータの有無 [p.190] | 主なメリット・物理仕様 [p.190] | 試験における選択シナリオ（なぜ選ぶのか） |
|---|---|---|---|
| AWS Managed Microsoft AD | あり（AWS上にWindows ADの実体を構築・管理する） [p.190] | ・本物のWindows Server ADであるため、AD依存アプリやグループポリシー、スキーマ拡張をフルサポート。 ・オンプレADとの「信頼関係」を構築可能。 |
「オンプレミスにある既存ADドメインと信頼関係を構築してハイブリッド認証を実現したい」または「SQL Serverなどの高度なAD連携機能をAWS側でも100%保持したい」場合。 |
| AD Connector | なし（AWS側には認証情報を一切保持・レプリケーションしない） [p.190] | ・認証要求をオンプレADにプロキシ転送するだけなので、データコピー不可のセキュリティ要件をクリア可能。 ・最も導入コストと運用工数が低い [p.190]。 |
「セキュリティ上、自社の機密アカウント（パスワード等）をAWSクラウド上に一切同期・保管したくないが、既存のオンプレADアカウントを用いてAWS側（コンソールやWorkSpaces）への認証を行わせたい」場合。 |
| Simple AD | あり（Samba 4ベースの互換環境をAWS上にデプロイする） [p.190] | ・Microsoftのライセンス費用が不要なため、3つのアプローチの中で最も低コスト。 ・オンプレADとの連携は不可 [p.190]。 |
「オンプレADとの同期や信頼関係は一切不要」で、「AWS上にのみ、独立した小規模（数千人未満）のAD互換システムを最も安価に新規構築したい」場合。 |
4. 【ひっかけ注意ポイント】
ひっかけ①：既存のオンプレミスADドメインに登録されている数万人のユーザー認証情報をAWS上のセキュリティリソースへ連携させるため、AWS上に「Simple AD」をデプロイし、オンプレミスADとの間で「双方向の信頼関係」をマッピングする。
- 真実: Simple ADはSamba 4ベースの簡易互換機能であり、オンプレADとの間の「信頼関係（Trust Relationship）」を設定することは物理仕様上一切不可能です [p.190]。
- 対策: オンプレミスとAWSの間にセキュリティ的な「信頼関係（Trust）」を結んでアカウント共有を実現するハイブリッド要件では、必ず AWS Managed Microsoft AD を選択します [p.190]。
ひっかけ②：各リージョン、および複数アカウントにまたがる膨大なAWSインフラ環境に対し、1つのポータル画面からシングルサインオン（SSO）で安全に各システムへと手動アクセスを分配する統制手法として、「各子アカウントに個別のSAML 2.0フェデレーションを個別にデプロイ・設計する」。
- 真実: アカウント数が極めて多い（マルチアカウント環境）場合、アカウントごとに個別にSAML 2.0などの信頼連携を手動構築していく設計は、構築やセキュリティポリシーの更新（許可セットの変更など）にかかる運用のオーバーヘッドが壊滅的に高くなり、設定ミスの温床となります。
- 対策: AWS Organizations配下のマルチアカウントに対するSSO統制、および権限の一元マッピングは、Organizationsと直結して親アカウントから各子アカウントに対する許可（Permission Sets）を一元管理・配布できる AWS IAM アイデンティティセンター を選択するのが絶対的なベストプラクティスです [p.187]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。