セキュアなアーキテクチャの設計
AWS SAA (SAA-C03) 過去問・解説組織はマスターアカウントと複数のメンバーアカウントで構成され、セキュアな設計として IAM ポリシー・ロール・SCP・マルチアカウントを用いた最小権限とガバナンスの実装を求められています。開発者は全アカウントでモニタリング作業を実行できるが、直接 IAM ユーザーの作成・変更、他のサービスへの権限付与などは行えないようにしたい。次の実装設計のうち、要件を最も満たすものはどれか。
AApp-Infra アカウントに MonitoringAssumeRole を作成し、信頼ポリシーでメンバーアカウントの root ARN を信頼元として許可する。このロールにはモニタリング関連のアクションのみを許可する IAM ポリシーをアタッチし、各メンバーアカウントには sts:AssumeRole の権限を付与する IAM ポリシーを用意する。さらに Organizations の SCP で iam:CreateUser、iam:CreateRole、iam:AttachRolePolicy などの作成・変更を拒否する deny ルールを設定する。
正解 ⭕⭕
【正解の理由】【正解】 要件であるマルチアカウント間の最小権限でのモニタリング権限を、中央のロールを通じて付与する設計です。信頼元をメンバーアカウントの root ARN に限定し、SCP で作成・変更系の権限を禁止することでガバナンスを実現します。
BMonitoringRole を App-Infra アカウントに作成せず、各メンバーアカウント内で直接モニタリング用のIAMポリシーを付与する。これによりクロスアカウントアクセスは実現されず、また sts:AssumeRole の代替手段を用いることで管理が複雑化する。さらに、組織レベルのガバナンスを強化する SCP は設定しない。
誤答C監視用途の権限を持つロールを各メンバーアカウントに個別に作成し、その信頼ポリシーをマスターアカウントの特定の IAM ユーザーに限定する。この設計では、メンバーアカウントのユーザーがモニタリングを実行できず、またロールの分散管理は非効率である。組織全体のセキュリティ境界を定義する SCP も導入しないため、ガバナンスが不十分となる。
誤答D全ての権限を広範囲に許可する管理者ロールを各アカウントに作成し、組織内の全アカウントの全ユーザーがそのロールを Assume できるようにする。これは最小権限の原則に著しく違反し、セキュリティリスクを大幅に増大させる。また、組織レベルでの権限の乱用を防ぐための SCP も存在しない。
誤答🎯正解の決め手・公式要点まとめ
正解を導くキーは、クロスアカウント設計におけるロールを中心とした権限委譲と、SCP による境界設定、そして最小権限の徹底です。信頼ポリシーとロールポリシーの組み合わせ、MFA 要件は任意だが追加すると更に強化されます。
⚠️ 誤答トラップ・他の選択肢が誤りの詳細理由
この選択肢は〇〇の定義と混同しやすく、本番試験で正答率が落ちる典型的なトラップです...
💡 似た概念との決定的な違い
実務および試験で頻出する関連用語の使い分けは次の3原則で整理できます...
🔒
「誤答トラップ解説」＆「全選択肢の個別解説」はPRO会員限定
月額3,000円で全8資格3,200問を解放。毎日演習で翌月実質無料（1日100円学習割）になる逆算サブスク。
アプリで演習を始める（全問解放） ➜💬ディスカッション・質問スレッド (0)
疑問や改善要望を投稿しようスレッドを読み込み中...
Googleアカウントでログインすると質問の投稿やスレッドへの参加ができます。