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]。

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. 【一問一答セルフテスト】

問1（○×問題）

AWSアカウントの「ルートユーザー」は、AWSアカウントサインアップ時に登録したメールアドレスとパスワードでログインする全能の特権アカウントであり、このルートユーザーの操作権限はIAMポリシーやSCPなどのあらゆるポリシー設定をもってしても部分的に制限・剥奪することは物理的に不可能である。 （○ か × か） [p.176, p.179]

問2（○×問題）

AWS Organizationsを導入してマルチアカウントの一括請求（コンソリディテクティッド・ビリング）を構成すると、組織内のすべての子アカウントでの利用合計量が自動的に合算され、データ転送コストやストレージ容量などの「ボリュームディスカウント」の割引メリットを組織全体で最大化してコスト最適化を図ることができる。 （○ か × か） [p.179]

問3（4択問題）

ある企業で、開発チーム用に複数のAWS子アカウントをAWS Organizations環境下で払い出して運用しています。社内の厳格なガバナンス規則により、「どの子アカウントであっても、開発者が誤ってAWS内で最も高額なデータベースクラスである一部の超高性能リソースを起動することを、たとえその子アカウントの管理者（rootユーザー）であっても絶対にできないように制限したい」と考えています。これを最も簡単かつ確実に実現できるセキュリティ設計はどれですか。 [p.179]

• A. 各子アカウントのIAM定義にて、対象のデータベース起動権限を除外した「カスタマー管理IAMポリシー」を全ユーザーへ個別にアタッチする。
• B. 親アカウントのAWS Organizations管理画面にて、対象リソースの作成を拒否する「サービスコントロールポリシー（SCP）」を定義し、該当する子アカウントが所属するOU（組織単位）に適用する。
• C. AWS Configの適合ルールを各アカウントに展開し、対象リソースが起動したことを検知したIAMユーザーアカウントを即座に自動削除する。
• D. 子アカウントの「ルートアカウント」のパスワードを親アカウントの管理者のみが保有し、開発者には一切教えないようにする。

問4（4択問題）

AWS Organizationsにおける「サービスコントロールポリシー（SCP）」の仕様と動作の仕組みに関する説明のうち、最も「正しい」記述はどれですか。 [p.179]

• A. SCPはIAMポリシーと完全に同一の機能であり、SCP単体を組織のOUに適用するだけで、アカウント内の特定の開発用IAMユーザーに対してのみ「S3バケットの作成」を許可（Allow）することができる。
• B. 親アカウントによって子アカウントAに適用されたSCPで「DynamoDBテーブルの削除（dynamodb:DeleteTable）」アクションが明示的に拒否（Deny）されている場合でも、子アカウントAの「ルートユーザー」であればその拒否を無視してテーブルを削除できる。
• C. SCPはアカウントに対する「最大権限の制限（ガードレール）」を規定するものであり、ある操作を実行するためには「SCP」と「子アカウント内のIAMポリシー」の双方がその操作を許可（Allow）していなければならない。
• D. SCPは異なるAWS Organizations組織間（他社のAWS環境など）にまたがって、同一のIAMロールグループへセキュリティ統制を強制するために利用される。

問5（○×問題）

AWS CloudFormationとAWS Organizationsの連携機能である「CloudFormation StackSets」を使用すれば、Organizationsの配下にある数十〜数百におよぶ全ての子アカウントや異なるグローバルリージョンに対し、共通のセキュリティ基準（特定のIAMロール、監査ログを送信する設定など）を、個々のアカウントに個別ログインすることなく親アカウントから並列で安全に一括自動デプロイできる。 （○ か × か） [p.179]

【解答と解説】

解答1：×

• 解説: ルートユーザー自身の権限は、同一アカウント内のいかなる「IAMポリシー」でも制限することは不可能です [p.176]。しかし、親アカウントからOrganizationsを介して子アカウント全体に対して適用される 「SCP（サービスコントロールポリシー）」による制限（Deny）は、子アカウントのルートユーザーに対しても強制的に適用されます [p.179]。そのため「あらゆるポリシーで制限不可能」という記述は誤りです [p.179]。

解答2：○

• 解説: 記述の通りです [p.179]。一括請求（コンソリディテクティッド・ビリング）を有効化して組織内の複数のアカウントを1つに統合することで、個々のアカウント単位では到達しにくい大容量の割引枠（ボリュームディスカウント）をアカウント間で合算して早期にクリアでき、組織全体のAWS利用代金を引き下げることができます [p.179]。

解答3：B

• 解説: 正解は B. OrganizationsのSCP（サービスコントロールポリシー）による制御 です [p.179]。子アカウントのルート（root）ユーザーを含む、アカウント内の全ユーザーに対して絶対に特定の操作を禁止（ガードレール設定）したいという要件を満たせるのは、親組織から強制適用する SCP のみとなります [p.179]。Aはルートユーザーの行動を制限できないため誤りです [p.176]。

解答4：C

• 解説: 正解は C です [p.179]。SCPはあくまで実行可能な「権限の上限（ガードレール）」を制限する機能であり、SCP自体がユーザーに能動的な実行権限を与えるものではありません [p.179]。そのため、ユーザーが特定の操作を行うには、「SCPでその操作が拒否されておらず（かつOrganizationsの基本ポリシーで許可されており）」、なおかつ「子アカウント内のIAMポリシーで明示的に許可（Allow）されている」という、双方の条件を同時にクリアしている必要があります [p.179, p.181]。

解答5：○

• 解説: 記述の通りです [p.179]。CloudFormation StackSets をOrganizationsの組織構造と直接紐付けることで、組織に新しい子アカウントが追加された際にも、あらかじめ親から定義したセキュリティ用のIAMロールやネットワークテンプレート（VPC等）を自動的に並列適用（セルフプロビジョニング）させることが可能になり、ガバナンスと管理効率が大幅に向上します [p.179]。

🚀 これで第7章「AWSアカウント管理とOrganizations（SCP）」のコアガバナンス論点は完璧に掌握されました！

日常のセキュアな作業アカウントを構築し終えたら、次は、このIAMユーザーやEC2に付与することで、一時的な資格情報（アクセストークン）をシームレスに適用してセキュリティキーの漏洩リスクを根本的に排除する 「第7章7-3：IAMポリシー・IAMグループ・IAMロールの設計」 の深い境界線について学習を進めましょうか？