2026-09-04（金）復習週＋模試1
1. 【頻出ひっかけパターンTOP5】
AWS認定ソリューションアーキテクト‐アソシエイト（SAA-C03）試験において、第7章「アイデンティティとガバナンス」 はセキュリティの根幹をなす最重要論点です [p.20, p.298]。 特に、IAM（AWS Identity and Access Management）や AWS Organizations に関する、受験者が最も間違えやすい「ひっかけパターン」を5つ厳選しました。
❌ ひっかけ①：EC2から他サービス（S3など）にアクセスする際、アクセスキーを直接埋め込む罠
- 罠のパターン： 「プライベートサブネット内のEC2で稼働するバックエンドアプリケーションが、Amazon S3バケットから画像を読み込む必要がある。これを実装するため、十分な権限を持つIAMユーザーの『アクセスキーID』と『シークレットアクセスキー』を発行し、アプリケーションの設定ファイルにテキストとしてハードコードした [p.184, p.298]。」
- なぜ間違いか（セキュリティ設計のアンチパターン）： ソースコードや設定ファイルに静的なアクセスキーを直接記述することは、ソース管理システムへの漏洩や不正利用、乗っ取りの温床となるため極めて危険な設計違反です [p.298, p.310]。
- ベストプラクティス（「なぜそうするのか」の理由）： 「IAMロール」をEC2インスタンスプロファイルとして割り当てます [p.62, p.184]。 IAMロールを使用すると、AWSが一時的なセキュリティ認証情報（有効期限付き）をEC2内部に自動的に作成・マウントし、ローテーション（自動更新）を完全自律で行ってくれます [p.62, p.184]。これにより、プログラムコード内にアクセスキーを一切保持することなく、完全に安全な認証情報の管理が可能となります [p.184]。
❌ ひっかけ②：SCP（サービスコントロールポリシー）を「権限付与」に使う罠
- 罠のパターン： 「AWS Organizations内の特定の開発アカウントにおいて、開発者たちに DynamoDB へのフルアクセス権限を付与することになった。管理者は、AWS Organizations のコンソールを開き、その開発アカウント（OU）に対して DynamoDB のフルアクセスを『Allow』するSCPをアタッチした [p.179]。」
- なぜ間違いか（SCPの正しい動作特性）：
SCPは「最大権限を制限するガードレール」であり、権限を直接「付与」する能力はありません [p.179]。
どれだけSCPで特定のアクションを
Allowに設定しても、アカウント内部のIAMユーザーやIAMロールに対して適切な「IAMポリシー」が別途アタッチされていない限り、ユーザーは該当サービスを実行できません（デフォルトで拒否されます） [p.179, p.181]。 - ベストプラクティス（「なぜそうするのか」の理由）： SCPは「アカウント内で実行可能な操作の上限」を規定するためにのみ使用し（例：東京リージョン以外の操作を完全拒否するなど） [p.179]、具体的な権限付与はアカウント内部の個々のユーザーやグループに対してアタッチする「IAMポリシー（Identity-based Policy）」で行うのが正しい設計です [p.179, p.181, p.182]。
❌ ひっかけ③：同一の権限を、複数のIAMユーザーに直接個別にアタッチする罠
- 罠のパターン： 「自社のAWS開発チームに、新しく3名の開発者が追加された。これら3名に対して、開発用RDSの管理権限を割り当てるため、3つのIAMユーザーアカウントを個別に作成し、それぞれのIAMユーザーに対して同じRDSFullAccessポリシーをアタッチして管理した [p.183]。」
- なぜ間違いか（運用の優秀性のアンチパターン）： 権限をユーザーに直接マッピングする運用は、チーム規模が拡大した際に「誰がどのような権限を持っているのか」のガバナンスが完全に崩壊し、設定漏れや不要な特権の放置（セキュリティホール）に繋がります [p.183, p.298]。
- ベストプラクティス（「なぜそうするのか」の理由）：
「IAMグループ」を作成し、グループに対して権限ポリシーをアタッチします [p.183]。
そして、個々のIAMユーザーは該当するグループ（例：
DB-Adminsなど）に所属させることで権限を引き継がせます [p.183]。 これにより、人事異動やメンバー追加時の権限変更が「グループへの追加・削除」という単一のオペレーションだけで安全に完結し、ガバナンスと管理工数を劇的に改善できます [p.183]。
❌ ひっかけ④：他アカウントからのクロスアカウントアクセスに「IAMユーザー」を作成して渡す罠
- 罠のパターン： 「提携する外部のセキュリティ監査会社の担当者に、自社のAWSアカウント内の監査用ログを収集させたい。そのため、自社アカウント内に監査会社用の『監査用IAMユーザー』を作成し、その静的なアクセスキーをメール経由で提供した [p.184, p.298]。」
- なぜ間違いか（マルチアカウント運用のアンチパターン）： 外部のサードパーティや別のアカウントに対して、永続的なアクセス情報を持つIAMユーザーのアカウントを発行して共有することは、資格情報の漏洩リスクを大幅に高めるため絶対に避けなければなりません [p.184, p.298]。
- ベストプラクティス（「なぜそうするのか」の理由）： 「信頼関係（Trust Policy）を定義したIAMロール」を作成し、相手のアカウントに引き受けて（AssumeRole）もらいます [p.184]。 これにより、相手は自身のAWS環境から自社アカウントのIAMロールを呼び出すことで、一時的な認証情報を動的に受け取ってログインできます [p.184]。 自社側はパスワードやアクセスキーなどの機密情報を相手に受け渡す必要が一切なく、不要になった際は信頼ポリシーを削除するだけで即座にアクセスを無効化できるため、非常に安全です [p.184]。
❌ ひっかけ⑤：オンプレミスのADユーザー移行に「Simple AD」を構築する罠
- 罠のパターン： 「自社のオンプレミス環境で稼働している既存の Active Directory（AD）で管理された社員ユーザーが、AWSのマネジメントコンソールにログインできるようにSSOを構築したい。管理の手間を最小限に抑えるため、AWS上に『Simple AD』を新規にデプロイし直してドメインを新規作成した [p.187, p.190]。」
- なぜ間違いか（Directory Serviceの選定境界）： Simple ADはSambaベースの安価な互換ディレクトリであり、「既存のオンプレミスADとの信頼関係の構築（Federation）」や、既存ドメインからの同期機能を持っていません [p.190]。 これを選んでしまうと、オンプレミスで動いている全ユーザーのパスワードやアカウント情報をAWS側のSimple ADへ手動で再登録・重複管理しなければならず、構築コストとガバナンス負荷が爆発します。
- ベストプラクティス（「なぜそうするのか」の理由）： 既存のオンプレミスADが存在し、それをそのままAWSと同期・連携させてSSOログインを機能させたい場合は、オンプレADへのプロキシとして機能する 「 AD Connector 」 を配備するか、またはオンプレADとの間に強固な双方向信頼関係を構築できる 「 AWS Directory Service for Microsoft Active Directory (Managed Microsoft AD) 」 を選定し、「 AWS IAM Identity Center（旧AWS Single Sign-On） 」 とマッピングして自動SSOを構成するのが絶対のベストプラクティスです [p.187, p.190]。
2. 【混同しやすいサービスの比較表】
試験において「どちらも権限管理やアカウント統制に使えるサービス」に見えて迷いやすい類似機能の決定境界を、クリアに比較整理しました。
① ポリシー設計の落とし穴：管理ポリシー vs インラインポリシー [p.182, p.183]
| 比較項目 | 管理ポリシー (AWS管理 / カスタマー管理) [p.182] | インラインポリシー [p.182, p.183] |
|---|---|---|
| 主な特徴 | IAMから独立した論理的オブジェクト。再利用可能。 | 特定のIAMアイデンティティに1対1で直接埋め込まれたポリシー。 |
| 適用範囲 | 複数のIAMユーザー、グループ、ロールに繰り返しアタッチできる [p.182]。 | 埋め込み先のユーザーやロールが削除されると、ポリシーも同時に消滅する [p.183]。 |
| バージョン管理 | 対応（誤って更新しても、過去のバージョンへ即座に差し戻し可能） [p.182]。 | 非対応（上書きすると過去のポリシー履歴は消失する）。 |
| 選定シグナル | 「 『読み取り専用権限』など、複数の開発者やコンテナに共通して使い回したい汎用的なポリシー 」 [p.182] | 「 絶対に他のリソースに適用されては困る、単一の特殊なLambdaやEC2にのみ固定したい固有のポリシー 」 [p.183] |
② アカウント統制の境界：IAMポリシー vs SCP (Service Control Policy) [p.179, p.181, p.182]
| 比較項目 | IAMポリシー [p.181, p.182] | SCP (サービスコントロールポリシー) [p.179] |
|---|---|---|
| 定義する場所 | 個別のAWSアカウント内部 [p.181]。 | AWS Organizations の管理親アカウント [p.179]。 |
| 適用ターゲット | アカウント内の特定の「IAMユーザー」「IAMグループ」「IAMロール」 [p.181]。 | 組織内の「AWSアカウント（全体）」「OU（組織単位）」 [p.179]。 |
| ルートユーザーへの影響 | アカウントのルートユーザー（最強権限）の操作を制限することはできない [p.176]。 | メンバーアカウントのルートユーザーの操作をも強制的に制限（遮断）できる [p.179]。 |
| 最大の役割 | 該当リソースやユーザーへの具体的な権限の「許可（Allow）」 [p.182]。 | アカウントが実行可能な「最大権限の上限保護（Denyによるガードレール）」 [p.179]。 |
| 選定シグナル | 「 特定のアプリケーションに対して、S3バケットへのPutObject権限を安全に付与したい 」 [p.181] | 「 子アカウントが勝手に高額なリソースを起動したり、特定のリージョン以外を使用するのを全アカウントで強制禁止したい 」 [p.179] |
③ AWS Directory Service の選定境界：AD Connector vs Managed Microsoft AD [p.190]
| 比較項目 | AD Connector [p.190] | Managed Microsoft AD [p.190] |
|---|---|---|
| 主な実態・仕組み | オンプレミスADへのリクエストを転送する 「 プロキシ（中継器） 」 [p.190]。 | AWSクラウド上で動作する 「 本物のWindows Active Directory（ドメインコントローラー） 」 [p.190]。 |
| データの保持・複製 | AWS上には一切のAD情報・ユーザーパスワード情報をキャッシュも保持もしない [p.190]。 | AWS上にドメインコントローラーが構築され、ADデータベースが完全に複製・自律動作する [p.190]。 |
| オンプレAD連携 | オンプレADが常時正常動作していることが前提（回線切断時は認証不可） [p.190]。 | オンプレADとの間に「双方向の信頼関係」を構築することで、回線切断時もAWS単体で認証可能 [p.190]。 |
| 決定的な選定シグナル | 「 オンプレミスにあるADをマスターとしてそのまま使い、AWS上に追加のドメインを置かずにプロキシ接続だけで安価にSSOログインさせたい 」 [p.190] | 「 オンプレミスの既存ADの資産（グループポリシー等）を活用しつつ、AWS上に完全に冗長化された大規模なADを置いて強固に双方向信頼関係を結びたい 」 [p.190] |
3. 【弱点確認クイズ】
問1（4択問題）
VPC内のプライベートサブネットで稼働する複数の自動処理用 EC2 インスタンスが、Amazon DynamoDB テーブルに対して毎分ログの書き込みを実行するアーキテクチャを設計しています。 「EC2インスタンス内部にAWSの静的なアクセスキー情報を一切保存させずに、最も安全にセキュリティの最小特権の原則を満たしてDynamoDBへの書き込みアクセス権限を移譲したい」、かつ「インフラ運用の手間を最小に抑えたい」と考えています。 この要件を満たすために選択すべき、最も適切なセキュリティ設計はどれですか。 [p.62, p.143, p.184, p.298]
- A. 書き込み専用のIAMユーザーを作成し、アクセスキーIDとシークレットアクセスキーをEC2インスタンスのユーザーデータ（User Data）スクリプト内に環境変数としてテキスト記述しておく [p.62]。
- B. DynamoDBの書き込みアクション（
PutItem）のみを明示的に「Allow」したIAMポリシーを含む「IAMロール」を作成し、そのロールをEC2インスタンスに「インスタンスプロファイル」としてアタッチする [p.62, p.184, p.298]。 - C. S3バケットポリシー内に、対象のEC2インスタンスのプライベートIPアドレスからのアクセスを「Allow」する記述を追加してバケットを公開する [p.109]。
- D. AWS Organizationsの管理アカウントにおいて、該当EC2が所属するメンバーアカウント全体にDynamoDBへのアクセスを常時許可する「SCP（サービスコントロールポリシー）」を強制適用する [p.179]。
問2（○×問題）
AWS Organizationsを運用しているエンタープライズ環境において、開発者用の子アカウントに対して、すべてのリソースの強制削除および特定の高額なEC2インスタンスクラスの新規デプロイ操作をアカウントのルートユーザーを含めて一律でブロック・禁止するため、Organizationsの管理アカウントから「明示的拒否（Explicit Deny）」を記述した「SCP（サービスコントロールポリシー）」を子アカウント（OU）にアタッチした [p.179]。 このとき、該当する子アカウントの「ルートユーザー（Root User）」でログインすれば、アカウント内での最高特権が保持されているため、このSCPによる削除禁止制限をバイパスしてリソースを削除することができる。 （○ か × か） [p.176, p.179]
問3（4択問題）
自社のAWSアカウント内において、提携先の外部サードパーティ企業（AWSアカウントID: 987654321012）のセキュリティエンジニアに対して、自社のアカウント内の Amazon S3 バケットに蓄積されたシステムセキュリティログファイルの読み取りと分析監査のみを許可したいと考えています。
「外部の監査者が自社のアカウントにアクセスする際、永続的なAWSログインパスワードやアクセスキー情報の共有を完全に排除したい」、かつ「第三者によるなりすましアクセスを防ぐため、サードパーティ企業が提供する固有のユニークなID（外部ID: External ID）を要求する最も安全なクロスアカウントアクセス」を構成したいと考えています。
この要件を満たすために自社アカウント側でプロビジョニングすべき、最も適切な設定パターンはどれですか。 [p.184, p.298]
- A. 自社アカウント内に「監査用IAMユーザー」を新規作成し、S3への読み取り権限（
s3:GetObject）ポリシーをアタッチした上で、アクセスキーをCSVで相手に送信する [p.184]。 - B. 相手のアカウントID（
987654321012）を「信頼されたエンティティ（プリンシパル）」として定義し、さらに信頼関係（Trust Policy）の条件（Condition）に「外部ID（sts:ExternalId）」の完全一致を記述した「IAMロール」を自社アカウント内に作成して相手に共有する [p.184, p.298]。 - C. 自社のS3バケットポリシーを「全世界に公開（パブリックオープン）」し、バケットのURLを知っている全員が読み出せるように設定する [p.109, p.111]。
- D. 相手のエンジニア専用に、自社のAWSアカウントの「ルートユーザー（MFA付き）」のログインIDとパスワードを貸与する [p.176]。
問4（○×問題）
AWS IAM（Identity and Access Management）におけるポリシー設計において、「カスタマー管理ポリシー」と「インラインポリシー」の2つの設計境界を評価している。 「カスタマー管理ポリシー」はIAMリソースから独立して単一のエンティティオブジェクトとして作成されるため、アカウント内の複数のIAMユーザー、グループ、ロールに対して同時にアタッチして共通利用（再利用）することが可能である [p.182]。 一方、特定のユーザーに1対1で直接埋め込まれる「インラインポリシー」は再利用はできないが、埋め込み先のユーザーを物理削除した際、同時にポリシーも完全に自動削除されるため、権限の「削除忘れによるセキュリティリスク」を確実に防止したい限定的なシーンにおいて有効である [p.182, p.183]。 （○ か × か） [p.182, p.183]
問5（4択問題）
企業の既存のオンプレミス Active Directory（ユーザー数300名）で稼働している社内アイデンティティ（社員データ）とAWSの連携を推進しています。 「社内メンバーが、オンプレミスの使い慣れたActive Directoryの認証情報（パスワード）をそのまま使用して、追加の認証情報を管理することなくAWSマネジメントコンソールにシングルサインオン（SSO）で安全にログインできるようにしたい」、かつ「AWS側へユーザーアカウントのパスワード情報自体をレプリケーション（複製・保持）させず、認証リクエストのみを安全にオンプレミスADへ転送・中継（プロキシ）させたい」と考えています。 この要件に適合する、最も適切なDirectory Serviceとサービスの組み合わせはどれですか。 [p.187, p.190]
- A. AWS上に「Simple AD」を新規作成し、全ユーザーを手動で再インポートしてSSOを有効化する [p.190]。
- B. AWS上にオンプレADへのプロキシ（中継器）として機能する「AD Connector」をプロビジョニングし、「AWS IAM Identity Center」と連携させてSSOをマッピングする [p.187, p.190]。
- C. AWS上に「Managed Microsoft AD」を新規構築し、オンプレミスADからユーザーデータをすべて削除し、AWS側を単一のプライマリADとして統一してSSOログインさせる [p.190]。
- D. 各ユーザーに「IAMユーザー（アクセスキー：はい）」を作成し、MFA認証を強制化させる [p.177, p.183]。
【解答と解説】
問1：正解 B
- 解説：EC2インスタンスからDynamoDBやS3などの他のAWSサービスに対して、安全かつパスワードやアクセスキーの直接保持なし（認証情報のハードコードなし）に接続させるための絶対のベストプラクティスは、「IAMロール」を割り当てることです [p.62, p.184]。 これにより、EC2インスタンス内部のアプリケーションは一時的なセキュリティ認証情報を自動で取得・利用できるため、認証情報の不正流出リスクを極小化できます [p.184, p.298]。Aは静的アクセスキーの埋め込みであり不適合 [p.298]、DのSCPは直接的なアクセス許可を付与することはできないため誤りです [p.179]。
問2：×（誤り）
- 解説：誤りです [p.179]。 AWS Organizationsの SCP（サービスコントロールポリシー） の最も強力な仕様特性として、「 子アカウント（メンバーアカウント）のルートユーザーの操作に対しても、例外なく100%強制的に制限を適用する 」 というルールがあります [p.179]。 したがって、どれだけルートユーザーであっても、SCPで特定アクション（例：特定のインスタンス起動や削除など）が「Deny」されている場合は、その子アカウントの内部からは絶対にその操作を実行することはできません [p.179]。これにより、子アカウント内での誤操作や悪意ある暴走を強力にガードレール制限することができます [p.179]。
問3：正解 B
- 解説：外部アカウントやサードパーティ企業などの「他者」に対して、自社のアカウント内のリソースアクセス（クロスアカウントアクセス）を一時的に安全に許可する設計手法は、「信頼関係のあるIAMロール」の作成です [p.184]。 さらに、外部ADなどの第三者連携において、他者が自社の情報を勝手に引き受ける「混乱した代理（Confused Deputy）問題」を防止し、確実ななりすまし防御を行うため、信頼ポリシーの条件（Condition）に相手から提示された固有の文字列である 「外部ID（External ID）」の一致チェック を埋め込むのが最上位のセキュリティベストプラクティスとなります [p.184, p.298]。A、Dのように永続的パスワードやキーを他人に共有する設計は重大なセキュリティ違反です [p.184]。
問4：○（正解）
- 解説：正解です [p.182, p.183]。 カスタマー管理ポリシーとインラインポリシーの境界が正確に記述されています [p.182, p.183]。管理ポリシーはオブジェクトとして独立しているため、複数のユーザー等に安全に使い回し、一括修正や過去5世代までのロールバック（バージョン管理）を行えます [p.182]。 一方、インラインポリシーはユーザーに直書きされるため再利用はできませんが、「ユーザー削除と同時にポリシーも自動的に物理消滅する」ため、将来の「ゴミポリシー（削除漏れ）の放置」をシステム的に排除したい極めて局所的な設計シーンにおいて役立つ、仕様に完全に合致した正しい内容です [p.183]。
問5：正解 B
- 解説：既存のオンプレミスActive Directoryが存在し、AWS上にパスワードデータ自体を一切同期（レプリケーション・キャッシュ保持）させずに、認証要求をそのままプロキシ転送・中継させたいという要件に適合するのは、AWS Directory Serviceの「AD Connector（プロキシ専用）」 です [p.190]。 これと、AWSのアカウント・権限へシームレスにシングルサインオンログインを仲介する 「 AWS IAM Identity Center（旧AWS Single Sign-On） 」 を組み合わせることで、オンプレミスの認証情報を1文字も変更・移行することなく、最も管理オーバーヘッドを低く要件を完璧にクリアできます [p.187, p.190]。
🛡️ これにて、AWS認定ソリューションアーキテクト‐アソシエイト（SAA-C03）の最重要インフラガードレールである「アイデンティティとガバナンス（第7章）」の1時間徹底攻略講義は完璧に完了しました！
「IAMロールによる一時的な認証情報（アクセスキー埋め込みの完全廃止）」 [p.184]、「SCPは最大権限のガードレールでありルートユーザーも縛る」 [p.179]、「他アカウント連携には外部ID（External ID）付きIAMロール」 [p.184]、「既存オンプレADの認証中継プロキシにはAD Connector」 [p.190]。 これらは、試験で最も出題される「セキュアな設計の構築（30%）」における最強の解答フィルターとなります [p.6]。
確実な一発合格へ向け、このまま自信を持って進んでいきましょう！
🏁 模擬試験への挑戦の前に、試験直前の廊下で最後にスマホで流し見するだけで得点力を底上げできる、「 OrganizationsにおけるSCP、IAM Identity Center、およびオンプレAD信頼関係のトラフィック接続フローだけを1つのビジュアル関係性にまとめた『直前ファイナル・ガバナンスマップ』 」 を、最後にサクッと1分で総チェックして完璧に仕上げますか？