2026-08-04（火）AWS基礎＋IAM（権限管理）
1. 【この範囲の全体像】
本範囲（第7章7-1・7-2）は、AWSにおける最も根本的なセキュリティ境界線である「AWSアカウント」と、組織規模でのマルチアカウント運用を支える「AWS Organizations」を扱います [p.176, p.178]。
全能の権限を持つルートユーザーを徹底的に保護・封印する原則 [p.176]、および、Organizationsの「SCP（サービスコントロールポリシー）」による子アカウントへの絶対的な統制（ガードレール設計）を理解することは [p.179]、試験で最も配点比率の高い「セキュアなアーキテクチャの設計」を攻略するための重要な防衛ラインです [p.8, p.177]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| AWSアカウント（ルートユーザー） | アカウント作成（サインアップ）時に生成される、すべてのAWSサービスやリソースに対して制限なしに完全な操作を実行できる「全権を握るルート（特権）アカウント」 [p.176]。 |
| 多要素認証（MFA） | パスワードによる認証に加え、スマートフォンなどの物理デバイスに一時的に表示されるワンタイムコードの入力を追加で義務付ける、アカウント乗っ取りを防ぐための最優先セキュリティ設定 [p.176]。 |
| IAM ユーザー | AWSリソースを日常的に操作する人（開発者等）やプログラムごとに作成する「個別の作業用ID」 [p.176, p.177]。初期状態では一切の権限を持たず、最小権限のみを付与して日常の操作に使用する [p.176, p.177]。 |
| AWS Organizations | 複数のAWSアカウントをグループ化し、親となる「管理アカウント」から子アカウントを一元的に管理・統制するためのマルチアカウント管理サービス [p.178]。 |
| 組織単位（OU: Organization Unit） | AWS Organizations内でアカウントを論理的にまとめる、階層構造を構築可能な「フォルダ」のような管理単位 [p.178]。 |
| サービスコントロールポリシー（SCP） | 組織内（親OUから各子アカウント）の最大権限を制限する、Organizations専用のガードレールポリシー [p.179]。 |
| 一括請求（コンソリディテクティッド・ビリング） | 組織内にある複数のAWSアカウントの請求を1つの管理アカウントに統合して一括支払いを可能にし、ボリュームディスカウントなどの恩恵を組織全体で共有するコスト最適化機能 [p.179]。 |
| CloudFormation StackSetsとの連携 | Organizations内の複数の子アカウントやリージョンに対して、共通のインフラ（セキュリティグループやIAMロール等）を、親アカウントのテンプレートから一貫性を持って並列で一括自動デプロイする機能 [p.179]。 |
3. 【試験で問われる比較ポイント】
試験では、「 どのポリシーが誰に対して、どのレベルで影響を及ぼすか 」 という権限の強さと適用境界を正しく区別できるかが問われます [p.179, p.181-182]。
① 権限コントロール：IAMポリシー vs SCP [p.179, p.181-182]
「個々のユーザーの行動を許可する」IAMポリシーと、「アカウント全体が実行できる限界を定める」SCP（ガードレール）の決定的な違いを比較します [p.179, p.182]。
| 比較項目 | IAMポリシー [p.181-182] | SCP (サービスコントロールポリシー) [p.179] |
|---|---|---|
| 適用するターゲット | 個別のIAMユーザー、IAMグループ、IAMロール [p.181-182] | AWS Organizations内の組織（OU）、または特定の「AWSアカウント」 [p.179]。 |
| 主な役割と本質 | 該当のユーザー等に対して「実際に実行してよい具体的なアクション」を許可（または拒否） する [p.182]。 | アカウントが実行できる 「最大権限の上限（ガードレール）」を制限する [p.179]。※これ単体でユーザーに実行権限を与える（許可する）ことはできない。 |
| ルートユーザーへの影響 | ルートユーザーの行動をIAMポリシーで制限することは不可能 [p.176]。 | 子アカウントのルートユーザーを含む、アカウント内の全ユーザーの行動を強力に制限（拒否）できる [p.179]。 |
| 最終的なアクセス判定 | IAMポリシーで許可（Allow）が定義されていれば実行可能。 | 「SCP」と「IAMポリシー」の双方が許可（Allow）しているアクションのみ実行可能。どちらか一方で拒否（Deny）されていればブロックされる。 |
| 試験シナリオ例 | 「開発担当者に特定のS3バケットへの読み書き権限だけを安全に付与したい」 | 「 子アカウント内のすべてのユーザー（ルートを含む）に対し、東京リージョン（ap-northeast-1）以外のすべての操作を禁止してコンプライアンスを徹底させたい 」 [p.179] |
4. 【ひっかけ注意ポイント】
ひっかけ①：子アカウントで「何でも実行できるフル管理者権限（AdministratorAccess）」を与えられたIAMユーザーであれば、親アカウント側で設定されたSCP（サービスコントロールポリシー）による禁止事項（例：Redshiftクラスター起動の拒否）をバイパスしてリソースを起動できる。
- 真実: SCPは、子アカウント内のすべてのユーザー（たとえ最強のAdministratorAccessを持つユーザーや、アカウントの「ルートユーザー」であっても）を例外なく強力に縛ります [p.179]。
- 解決理由: SCPで拒否（Deny）されたアクションは、子アカウントの内部でどのような強力なIAMポリシーを作成しようとも、絶対に実行することができません [p.179]。SCPが「枠（最大可能範囲）」を決め、その枠の中で「IAMポリシー」が実際に実行するアクションを許可する、という多層防御の構造を理解するのが正解です [p.179, p.181]。
ひっかけ②：日常の本番環境インフラ構築作業や運用メンテナンスにおいて、あらゆるリソースをスムーズに操作できるよう、ログイン情報の安全性が確保された開発者の端末から「ルートユーザー」で直接サインインして作業を行う。
- 真実: ルートユーザーは全権限を持つため、どれだけ注意を払っていても、オペレーションミスで「アカウントの解約」や「請求データの勝手な変更」などの取り返しのつかない致命的な損害を自ら引き起こすリスクがあります [p.176]。また、万が一ログインパスワードが漏洩した場合、アカウント全体が完全に攻撃者に乗っ取られて破滅的な不正利用に繋がります [p.176]。
- 解決理由: AWSの絶対的なセキュリティベストプラクティスは、「 ルートユーザーには直ちにMFA（多要素認証）を設定して物理金庫に封印し、日常的な操作には一切使用しない 」 ことです [p.176]。日常の最高管理者作業であっても、必ず必要最低限の権限のみを与えた（あるいは管理者用の）「IAMユーザー」または一時的な資格情報を取得する「IAMロール」を別途作成してサインインし、それらを用いて安全に作業します [p.176, p.177, p.184]。
ひっかけ③：AWS Organizationsの「一括請求（コンソリディテクティッド・ビリング）」を有効化してグループ化すれば、同一組織に所属する子アカウントA内のEC2やS3内の機密データに対して、子アカウントB内のアプリケーションからデフォルトのままで自由かつ安全にデータを直接読み書きしてアクセス共有できる。
- 真実: AWS Organizationsは、アカウントの「請求支払い」や「セキュリティ統制（SCP）」を中央から束ねて一元化するだけの管理サービスです [p.178, p.179]。一括請求グループになったからといって、異なるアカウント間のリソース共有境界（セキュリティ分離壁）が自動的に無効化されたり、接続が解放されるようなことは一切ありません [p.179]。
- 解決理由: アカウント間の安全なデータ共有やリソースアクセスを確立するには、 Organizationsに頼るのではなく、通常のアカウント間クロスアクセスと同様に「適切なクロスアカウントIAMロール」を設定して一時的なアクセス資格を別アカウントのユーザーに委譲する構成を個別にマッピングする必要があります [p.184]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。