DOP-6.3セキュリティモニタリングおよび監査ソリューションを実装する。
採点する
4問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数4
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- DOP-6.3セキュリティモニタリングおよび監査ソリューションを実装する。 0%
- 1
- 2
- 3
- 4
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 4
1. 質問
カテゴリ: DOP-6.3セキュリティモニタリングおよび監査ソリューションを実装する。【DOP-185】FinTech 企業は、AWS Organizations 配下の 10 アカウント合計 500 台の Amazon EC2 を対象に Amazon Inspector 第 2 世代による自動脆弱性スキャンを 1 日 1 回実行したい。
80% のインスタンスはインターネット接続を持たないプライベートサブネットに配置されており、社内セキュリティ基準によりアウトバウンド通信は禁止されている。
委任管理アカウントで Inspector を有効化した後、プライベートサブネット上のインスタンスも確実にスキャンするために、各メンバーアカウントで追加すべき最小構成はどれか。正解不正解ヒントボタン
ヒント1
Amazon Inspector v2 は EC2 内の AWS Systems Manager Agent を再利用しており、スキャン時には Systems Manager、EC2 Messages、SSM Messages の各エンドポイントへ 443/TCP で通信します。プライベートサブネットにいるインスタンスでも、この 3 つを VPC 内に Interface VPC Endpoint として配置すれば AWS ネットワーク内だけで疎通できるため、社内ポリシーで禁止されているインターネット経路を用いずに脆弱性情報を収集できます。ヒント2
NAT Gateway や IGW を設けるとアウトバウンド通信が許可されてしまい FinTech 企業のガバナンスに抵触します。AWS PrivateLink を利用した Interface エンドポイントならトラフィックが VPC 外へ出ず、マネージドサービス側で自動スケールするのでコストと運用負荷も抑えられます。セキュリティグループで 443 番のみ開け、各アカウントが同一ポリシーで横並び運用できる点が最小構成の決め手になります。ヒント3
要件は「組織全体で一括有効化した Inspector を、インターネット非接続の 80% を含む 500 台へ毎日実行」「アウトバウンド通信禁止」「構成追加を最小限」の 3 つです。IAM ポリシー付与や S3／SNS 連携だけでは通信経路が足りず、独自エージェントや NAT を導入するとガバナンスとコストで不一致が生じます。Systems Manager Agent が利用する 3 種の Interface VPC Endpoint を各 VPC に置く方法が、ネットワーク閉域・一括運用・コスト最適化という複数要件を俯瞰した総合的に最適な判断といえます。 -
質問 2 of 4
2. 質問
カテゴリ: DOP-6.3セキュリティモニタリングおよび監査ソリューションを実装する。【DOP-186】映像配信サービス企業 A 社は、5 つのメンバーアカウントに分散した合計 200 台の Amazon EC2（全て Amazon Linux 2、SSM Agent 事前導入済み）を運用している。
要件は次のとおりである。
1) 週次で EC2 の脆弱性を自動検出し、結果を組織単位で集約する。
2) /var/log 配下の OS・アプリケーションログを 5 分以内に中央ログアカウントへ送信し、CloudWatch Logs Insights で検索できる。
3) 新規インスタンス追加時の運用負荷を極小化する。
最も適切な実装はどれか。正解不正解ヒントボタン
週次の脆弱性スキャンを組織全体でまとめたい場合、AWS Organizations と連携し委任管理者アカウントへ結果を自動集約できるのは新版 Amazon Inspector です。Inspector Classic はアカウントごとに個別設定が必要で専用エージェントも追加するため、SSM Agent が既に入っている Amazon Linux 2 での運用簡素化という観点では不利になる点を意識してください。
OS やアプリケーションのログを 5 分以内に検索したいときは CloudWatch Agent で /var/log を CloudWatch Logs へストリーミングする構成が王道です。CloudTrail が捕捉するのは API コールでありインスタンス内ログではないため要件を満たせません。クロスアカウント Logs 送信先やサブスクリプションフィルターを使えば中央ログアカウントへリアルタイム転送が可能です。
インスタンス増加時の運用負荷を抑えるには AWS Systems Manager State Manager で CloudWatch Agent を自動配布し、Organizations で有効化した Amazon Inspector から SSM 経由で週次スキャンを走らせる構成が理にかないます。脆弱性検出の集約性、ログ検索の即時性、追加作業の最小化という複数要件を俯瞰して選択を整理しましょう。
-
質問 3 of 4
3. 質問
カテゴリ: DOP-6.3セキュリティモニタリングおよび監査ソリューションを実装する。【DOP-187】金融業のF社は AWS Organizations 配下に 200 アカウントを運用している。
すべてのカスタマー管理型 CMK はキーの自動ローテーションを必須とし、無効なキーを検出した場合は 60 分以内にセキュリティ運用チームへ E メールで通知しなければならない。
通知はセキュリティ専用の中央監査アカウントで一元管理し、ビジネスアカウント側の追加 IAM 権限と運用負荷は最小限に抑えたい。
各アカウントでは AWS Config レコーダーが有効化済みであり、違反履歴を過去 30 日ぶん保存して監査で参照できることも要件である。
さらに、経営層は組織全体の違反数を単一ダッシュボードで確認したい。
全リージョンで同一ポリシーを適用し、将来アカウントが追加されても自動適用される構成とする。
コスト増は月額 50 USD 以内に収めること。
最適な実装を選択せよ。正解不正解ヒントボタン
全アカウントで一律に CMK 自動ローテーションの設定状況を監査し、経営層が一枚の画面で組織全体の違反数を把握したい場合、AWS Config の評価結果を組織用 AWS Config アグリゲータに自動集約する構成が王道です。アグリゲータはリージョン横断で集計や可視化ができ、中央監査アカウントだけに参照権限を集められるため IAM 変更は最小限で済みます。さらに違反履歴は AWS Config が 30 日間保持し、評価回数 ×0.001USD というシンプルな課金なので厳しい予算制約にもフィットします。
200 ものアカウントへ同じ監査ロジックや通知設定を漏れなく配備し、将来新しいアカウントやリージョンが追加されても自動適用させたいなら、Organizations と連携した CloudFormation StackSets が最適です。委任アカウントから一度テンプレートを公開して AUTO_DEPLOY を有効にすれば、OU 参加と同時に全リージョンへデプロイが走り、各ビジネスアカウント側での追加 IAM 権限や手作業を一切発生させずに運用負荷を劇的に削減できます。
違反検出から 60 分以内にメールを送るには、AWS Config ルールを定期評価（1 時間間隔）に設定し、結果が NON_COMPLIANT になった瞬間を Amazon EventBridge が捉えて中央監査アカウントの Amazon SNS トピックへ転送する流れが確実です。SNS を単一トピックで管理すれば構成がシンプルかつコスト効率に優れ、評価 1 回 0.001USD × 200 アカウント × 各リージョンでも月額 50USD 以内に収まります。自動展開・集中監査・60 分通知・30 日履歴・低コストという複数要件を俯瞰すると、Config＋StackSets＋アグリゲータ＋EventBridge＋SNS の組み合わせがバランス良く全条件を満たすと判断できます。
-
質問 4 of 4
4. 質問
カテゴリ: DOP-6.3セキュリティモニタリングおよび監査ソリューションを実装する。【DOP-188】金融 SaaS 企業は AWS Organizations で 35 アカウントを統制している。
監査部門は「本番アカウント 111122223333 への STS AssumeRole API を、発生から 30 秒以内にセキュリティ Slack チャネルへ暗号化通知する」ことを義務付けた。
イベントは全リージョンで発生し得るため、検知処理はリージョン非依存で統一すること。
検知後のメッセージは SSE-KMS 暗号化済み SNS トピックへ配送し、AWS Chatbot で Slack に投稿すること。
追加コードは Lambda 1 本のみ許可され、定期バッチは禁止。
この要件を満たす最適なアーキテクチャはどれか。正解不正解ヒントボタン
Organizations で多数アカウントを束ねる場合、CloudTrail を組織単位で有効化すると全リージョンの管理イベントを 1 本の Trail に集約でき、集中管理が容易になります。さらに EventBridge へ直接配信すれば eventSource=sts.amazonaws.com と recipientAccountId の両方をフィルタでき、AssumeRole 呼び出しを数秒で捕捉できます。
SNS で Slack へ安全に届けるにはトピック側で SSE-KMS を有効化し、AWS Chatbot をサブスクライブさせると追加インフラなしで暗号化と投稿を同時に実現できます。整形が必要なら Lambda を 1 本だけ挟み、KMS キーのポリシーで監査部門に限定復号権限を付与すればセキュリティ要件と運用簡素化を両立できます。
30 秒以内・リージョン非依存という制約では Athena バッチや AWS Config の評価周期、Glue＋Step Functions の分単位処理では遅延が大きく、GuardDuty も AssumeRole の通常利用を Finding にしません。イベント駆動で暗号化済み SNS を経由し、追加コードを最小化できる CloudTrail → EventBridge → SNS → Chatbot の直線経路が複数要件を俯瞰しても最も整合的です。
改善リクエスト