SAP組織の複雑さに対応する設計
あるグローバルなオンライン旅行予約プラットフォーム企業は、AWS Organizations と AWS Control Tower でランディングゾーンを運用している。開発チームの増加に伴い、各チームが自分専用のアカウントを迅速に取得したいという要望が高まっている。中央のクラウドプラットフォームチームは次の要件を満たしたい。
(1) 承認済みのネットワーク・暗号化・タグ標準に準拠したアカウントとベースラインリソースをセルフサービスで払い出す。
(2) 承認外リージョンでの操作や KMS を用いない暗号化を予防的にブロックする。
(3) プロビジョニング後の構成ドリフトを検知し自動修復する。
(4) これらを中央から一元管理し、運用オーバーヘッドを最小化する。
最も適切なアプローチはどれか。
AAWS Control Tower のアカウントファクトリで標準化アカウントを払い出し、承認外リージョンや暗号化必須を SCP で予防的に強制する。委任した管理者アカウントから AWS Config のコンフォーマンスパックを組織全体に展開し、非準拠リソースを自動修復アクションで是正する。
✓ 正解
Control Tower のアカウントファクトリで標準化払い出しを実現し、SCP で予防的ガードレールを組織全体に強制できる。委任管理者からコンフォーマンスパックを一括展開し自動修復まで行うため、検知・是正を中央で一元管理でき運用負荷を最小化できる。
BService Catalog でベースライン製品を各アカウントに公開し、IAM のアクセス許可境界で権限を制限する。コンプライアンス違反は Security Hub のセキュリティ標準で集約して可視化し、検出された逸脱はプラットフォームチームの担当者が個別に手動で修正対応する。
Service Catalog とアクセス許可境界は標準化と権限制御に有効だが、Security Hub での違反是正が手動であり運用オーバーヘッドが残る。自動修復の要件を満たせず、予防的なリージョン・暗号化制御も SCP より弱い。
C全アカウントで GuardDuty と Macie を有効化して脅威と機微データを検知し、EventBridge から Lambda を起動して違反リソースを削除する。アカウントの払い出しは従来どおり手動のチケット運用で受け付け、ネットワークとタグは払い出し後に個別設定する。
GuardDuty は脅威検知、Macie は機微データ検出のサービスであり、リージョンや暗号化の構成コンプライアンス評価には適さない。手動チケットでの払い出しやリソースの一律削除も、標準化・自動修復の要件に反する。
D各メンバーアカウントで AWS Config ルールを個別に作成し、SCP は使用せず IAM ポリシーによってアカウントごとにリージョンと暗号化を制御する。構成ドリフトは CloudTrail のイベント履歴を運用担当が定期的に手動で確認し、逸脱があれば個別に修正する。
各アカウントで Config ルールを個別作成し IAM で制御する方式は、組織全体への一元展開と SCP による予防的ガードレールを欠く。CloudTrail 履歴の手動確認では自動修復ができず、運用オーバーヘッド最小化の要件も満たせない。
解説
AWS Control Tower のアカウントファクトリは、標準化されたネットワークや暗号化設定を含むアカウントをセルフサービスで払い出せる。SCP は予防的ガードレールとして、承認外リージョンや暗号化なしの操作を組織レベルで拒否する。AWS Config のコンフォーマンスパックを委任管理者アカウントから組織全体へ一括展開し、非準拠リソースを自動修復アクションで是正すれば、検知と修復を中央で一元管理でき、運用負荷を最小化できる。
選択肢Bの Service Catalog と Security Hub は可視化には有効だが、修正が手動のため運用オーバーヘッドが残る。
選択肢Cの GuardDuty と Macie は脅威・機微データ検知向けで構成コンプライアンス評価には適さず、手動払い出しも要件に反する。
選択肢Dの アカウント個別の Config ルールと IAM 制御は組織的な予防・一元管理を欠き、手動確認も要件を満たさない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →