SAP既存のソリューションの継続的改善
ある保険会社は、AWS Organizations 配下の 6 アカウントにまたがり Amazon Linux 2 と Windows Server が混在する約 300 台の Amazon EC2 を運用しています。現在パッチ適用は各チームが手動で SSH/RDP 接続して実施しており、適用漏れによる脆弱性が監査で複数指摘されました。経営層は、OS パッチをスケジュールに沿って自動適用し、業務時間外のメンテナンスウィンドウで実行し、組織全体のパッチコンプライアンス状況を一元的に可視化する運用改善を求めています。運用チームの追加人員は割り当てられず、既存の運用負荷を増やさない前提です。最も適切な設計はどれですか。
A各アカウントで Amazon Inspector を有効化して脆弱性を継続検出し、検出結果を Security Hub に集約する。修正が必要なインスタンスは運用チームが個別にログインしてパッケージを更新し、対応状況を手動で表計算に記録して監査に提出する
Amazon Inspector は脆弱性を検出できますが、修正が手動ログインと表計算記録のままで自動適用・メンテナンスウィンドウ・一元可視化のいずれも実現できず、運用負荷を増やさない要件に反します。
BAWS Systems Manager Patch Manager でパッチベースラインとメンテナンスウィンドウを設定し、State Manager で適用を自動化する。パッチコンプライアンス状況は Systems Manager Explorer に組織横断で集約して可視化する
✓ 正解
Patch Manager のパッチベースラインとメンテナンスウィンドウで OS 混在環境を業務時間外に自動適用し、State Manager で継続適用、Explorer で組織横断のコンプライアンスを一元可視化でき、要件を追加人員なしに満たします。
CAWS Config のマネージドルールでパッチ状態を評価し、非準拠を検出したら EventBridge から Lambda を起動して該当 EC2 を停止・再作成する。最新パッチ適用済みの AMI を毎晩ビルドして全インスタンスを自動的に置き換える
Config でパッチ非準拠を評価できても、稼働中の EC2 を停止・再作成する対応は破壊的で状態を失うリスクが高く、毎晩の全台 AMI 置換も過剰です。パッチ適用の運用手段として適切ではありません。
DEC2 Image Builder で定期的にゴールデン AMI をビルドして Auto Scaling グループの起動テンプレートを更新し、全インスタンスをローリング置換する。パッチ適用の履歴は CloudTrail のログから抽出して監査資料に使用する
EC2 Image Builder の AMI 置換は Auto Scaling のステートレス構成には有効ですが、非 ASG や個別状態を持つ 300 台全体への適用は非現実的で、CloudTrail 抽出ではパッチコンプライアンスを正確に可視化できません。
解説
Systems Manager Patch Manager は Linux/Windows 混在環境に対しパッチベースラインで承認ルールを定義し、メンテナンスウィンドウで業務時間外に自動適用できます。State Manager で望ましい構成を継続適用し、Systems Manager Explorer は AWS Organizations と統合して複数アカウント・リージョンのパッチコンプライアンスを単一ダッシュボードに集約できます。マネージドサービスの組み合わせで人手を増やさず運用を自動化・可視化できます。
選択肢Aの Amazon Inspector は脆弱性検出には有効ですが、パッチ適用は手動・表計算記録のままで、自動化と負荷軽減の要件を満たしません。
選択肢Cの Config + Lambda で稼働中の EC2 を停止・再作成する方式は、ステートフルなサーバーの破壊的置換となりリスクが高く、パッチ適用手段として過剰かつ不適切です。
選択肢Dの EC2 Image Builder による AMI 置換は Auto Scaling 配下のステートレス構成には有効ですが、混在・非 ASG のインスタンスを含む全台に適用する前提としては現実的でなく、コンプライアンス可視化も CloudTrail 抽出では不十分です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →