2026-08-07（金）AWS基礎＋IAM（権限管理）

1. 【この範囲の全体像】

本範囲（第1章・第7章総復習）は、AWSを安全かつ堅牢に設計するための最重要インフラである「AWSアカウントの防衛」と「IAM（認証・認可）によるアクセス制御」の総仕上げです [p.23, p.175]。

無制限の特権を持つルートユーザーをMFAで完全に封印する鉄則 [p.176]、永続キーの流出を防ぐために「IAMロールの一時的資格情報」をリソースにアタッチする最小権限設計 [p.184]、そして Organizations（SCP）による組織全体のガードレール統制 [p.179] やハイブリッド認証のトポロジー設計まで [p.190]、試験で最大の配点比率を占める「セキュアなアーキテクチャの設計（30%）」の合格防衛ラインを一挙に掌握します [p.6]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
ルートユーザー	アカウント作成時に自動生成される全能のアカウント [p.176]。解約や請求変更など固有の操作以外では一切使用せず、MFA（多要素認証）を設定して物理金庫に封印するのがセキュリティの絶対的な前提 [p.176]。
IAMポリシー	「どのリソース（Resource）に対し、どのような操作（Action）を、許可・拒否（Effect）するか」をJSON形式で記述した認可定義書 [p.182]。
管理ポリシー	複数のユーザーやグループ、ロール間で使い回せる独立したポリシー [p.182-183]。1箇所の修正でアタッチ先すべてに一括適用されるため、ガバナンスと管理効率に優れる [p.182]。
インラインポリシー	特定の1オブジェクト（ユーザー等）に直接埋め込まれ、そのオブジェクトと運命を共にする再利用不可のポリシー [p.182-183]。
IAMグループ	同じ権限ポリシーを持つユーザーをまとめるコンテナ [p.183-184]。ネスト（グループの中にサブグループを入れる階層化）は物理仕様上不可 [p.184]。
IAMロール	永続的なパスワードやアクセスキーを持たず、AWSリソースや外部ユーザーに安全な「一時的セキュリティ資格情報（有効期限付きセッショントークン）」を動的に発行・委譲する仕組み [p.184]。
サービスコントロールポリシー（SCP）	AWS Organizations環境下において、組織（OU）やアカウント全体の「実行可能な最大権限の上限（ガードレール）」を規定するポリシー [p.179]。
AWS IAM アイデンティティセンター	組織（Organizations）全体のマルチアカウントや外部SaaSアプリケーションへのSSO（シングルサインオン）ログインとアクセス権限（許可セット）を中央から一元統制するサービス [p.187]。
AWS Directory Service	オンプレミスのMicrosoft Active Directory（AD）環境をAWSに拡張・連携するためのマネージドサービス群 [p.190]。

3. 【試験で問われる比較ポイント】

① IAMアクセス認可の3大概念の使い分け [p.183-184]

「だれに」「どのような期間」「どうやって」権限を与えるべきかで判断します。

比較項目	IAMユーザー [p.183]	IAMグループ [p.183-184]	IAMロール [p.184]
認証情報の保持	あり（永続的なPW、またはAPI用のアクセスキー） [p.183]。	なし（グループ自身にはログイン認証情報は存在しない） [p.183]。	なし（永続キーを持たない。一時的なトークンを動的発行） [p.184]。
主な対象者・実体	システムを日常操作する「個々の人間（開発・運用者）」 [p.183]。	共通の役割（Administrators等）を持つ「ユーザーの論理的な集まり」 [p.183-184]。	「 EC2やLambda等のAWSリソース」、または他アカウントのユーザー [p.184]。
試験での設計原則	人数分作成して「誰が操作したか」の追跡（CloudTrail等）を担保 [p.183, p.245]。	個別ユーザーへの直接ポリシー付与を止め、「グループベースの権限管理」を徹底する [p.183-184]。	EC2プログラムにアクセスキーを直書きせず、「ロールをアタッチして自動一時認証」させる [p.184]。

② ハイブリッド認証：AWS Directory Service 3つの選択肢 [p.190]

「オンプレミスに既存ADがあるか」「クラウド側にアカウントデータを同期・コピーしてよいか」で切り分けます。

比較項目	AWS Managed Microsoft AD [p.190]	AD Connector [p.190]	Simple AD [p.190]
AWS上のデータ保持	あり（AWS上にWindows ADの実体を展開・管理） [p.190]	なし（認証要求をオンプレADへ中継・プロキシ転送するだけ） [p.190]	あり（Samba 4をベースとしたAD互換をAWS上にデプロイ） [p.190]
オンプレADとの連携	「信頼関係（Trust）」を構築可能 [p.190]。	オンプレADのアカウントを利用可能（中継通信のみ） [p.190]。	連携不可（スタンドアロンでの利用に限定） [p.190]。
主要な決定シグナル	「既存のオンプレドメインと信頼関係を結びハイブリッド認証をしたい」 [p.190]	「社外秘アカウントやパスワードを一切AWS側にレプリケーション（複製同期）したくない」 [p.190]	「オンプレADは無く、AWS上にのみ新規で最も安価にAD互換環境を用意したい」 [p.190]

4. 【ひっかけ注意ポイント】

ひっかけ①：EC2インスタンス上のバッチプログラムから、Amazon S3に蓄積された監査ログを定常的に読み込むため、S3閲覧用のIAMユーザーを作成し、その「アクセスキーIDとシークレットアクセスキー」をプログラム内の設定ファイルに記述（ハードコード）してインスタンス内に保存する。
- 真実: プログラム内への永続的なアクセスキーの直書きは、サーバーへの不正侵入やソースコードの誤共有によって鍵が流出し、アカウント全体の乗っ取りを引き起こす致命的なセキュリティアンチパターンです [p.20, p.183-184]。
- 対策: アプリケーションにAWSリソースへのアクセスを認可する場合は、キーを持たない 「IAMロール」を作成し、これをEC2インスタンスに割り当てます [p.184]。これにより、プログラムはEC2のメタデータ経由でAWS（STS）から安全な「一時的セキュリティ資格情報」を自動取得してセキュアにアクセス可能となります [p.62, p.184]。
ひっかけ②：Organizations配下の子アカウントで「AdministratorAccess」ポリシーを割り当てられた最強権限のIAMユーザーであれば、親の管理アカウントで設定された「SCPによる特定のデータベース（例: Redshift）削除の拒否（Deny）」設定をバイパスして削除を実行できる。
- 真実: SCPは、子アカウントのルート（root）ユーザーおよびフル管理者（AdministratorAccess）を含むすべてのアカウント内ユーザーに対し、例外なく絶対的なガードレール（禁止上限）として上書き強制されます [p.179]。
- 対策: アクセス可否は「SCPが許可（Allow）しており（かつ拒否されておらず）」、かつ「子アカウント内のIAMポリシーでも明示的に許可（Allow）されている」という双方の積集合（両方が許可している部分）のみが実際に実行可能となるルールを正確に見極めます [p.179, p.181-182]。