変更要約: SCS-C02 第1章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
1.2検出結果の集約と自動対応
検出から対応へ——Security Hub、EventBridge、自動修復（Lambda/SSM Automation）、隔離——を理解します。検出を一元化し、機械的に素早く対処します。
検知したら集約と対応につなげます。Security Hub で一元化し、EventBridge から自動で修復・隔離します。
1.2.1集約と自動対応
- Security Hub：複数サービスの検出結果を一元集約・スコア化し、態勢を可視化する。
- EventBridge：検出イベントを受けて Lambda/SSM Automation を自動起動する。
- 隔離：侵害インスタンスをセキュリティグループ差し替えや分離 VPCで隔離する。
- 資格情報対応：漏洩した可能性のあるキー/認証情報を無効化・ローテーションする。
「検出の一元集約＝Security Hub」「検出→EventBridge→Lambda/SSM Automation で自動対応」「侵害インスタンスの隔離＝SG 差し替え/分離 VPC」「漏洩キーは無効化＋ローテーション」 は SCS-C02 で頻出です。漏洩キーは履歴から消すだけでなく必ず無効化します。
SCS-C02 では「検出を確実に対応へつなぐ自動化パイプライン」を設計できるかが問われます。Security Hub は GuardDuty・Inspector・Macie・Config・IAM Access Analyzer などの検出を ASFF（AWS Security Finding Format）で正規化・集約し、CIS/AWS 基礎セキュリティ標準/PCI DSS 等に対するセキュリティスコアを算出、自動化ルールで重大度の引き上げや抑制も行えます。検出は EventBridge のイベントとして流れ、ルールでフィルタして Lambda（カスタムロジック）や SSM Automation ランブック（定型対応）、Step Functions（多段ワークフロー）へルーティングします。代表的な自動対応は、(1) 侵害が疑われる EC2 を隔離（すべて拒否のセキュリティグループへ差し替え、または隔離用 VPC/サブネットへ移動、ASG からデタッチ）、(2) 漏洩した可能性のあるアクセスキー/ロールを無効化しローテーション（一度公開された資格情報は無効化必須）、(3) 公開された S3 を非公開化、(4) SNS で担当者へ通知、です。組織横断では委任管理者の Security Hub に集約し、メンバーの検出を一元管理。重要なのは、自動対応に冪等性とガードレール（重大度しきい値・タグ条件・承認ステップ）を設け、誤検知時の暴走を防ぐことです。設計の要は、Security Hub で集約→EventBridge で重大度ルーティング→Lambda/SSM で隔離・無効化・通知、を冪等かつ安全に組むことです。
| 役割 | 手段 | 要点 |
|---|---|---|
| 検出の集約/スコア化 | Security Hub（ASFF） | 標準準拠スコア・自動化ルール |
| 検出のルーティング | EventBridge | 重大度でフィルタ→ターゲット |
| 自動対応の実行 | Lambda / SSM Automation | 隔離・無効化・非公開化・通知 |
| 封じ込め | SG 差し替え / キー無効化 | 冪等性＋ガードレールで暴走防止 |
シナリオ：GuardDuty が「EC2 が暗号通貨マイニングの C2 と通信」を検出。自動で封じ込めたい。→ 検出を Security Hub に集約し、EventBridge ルールで重大度 HIGH を SSM Automation ランブックにルーティング。ランブックが当該 EC2 をすべて拒否の SG へ差し替えて隔離し、EBS スナップショットで証拠保全、SNS で SOC に通知。インスタンスロールの資格情報が漏れた可能性があれば無効化＋ローテーションします。承認ステップで本番影響の大きい操作は人手確認を挟みます。
FAQ：侵害インスタンスへの対応は「即削除」でよい？ いいえ。即削除すると証拠（メモリ/ディスク/ログ）を失い、原因分析や再発防止ができません。正しい順序は、隔離（通信を遮断して影響を封じ込め）→証拠保全（EBS スナップショット等）→解析（隔離コピーで）→必要なら復旧/再構築。資格情報が絡む場合は無効化＋ローテーションも並行します。
ひっかけ：漏洩した可能性のあるアクセスキーを「履歴/コードから消すだけ」で済ませるのは誤り——一度露出した時点で漏洩済みなので、必ず無効化（ローテーション）します。また自動対応に冪等性やガードレール（しきい値/タグ/承認）が無いと、誤検知で本番リソースを誤って隔離/削除する恐れがあります。封じ込めの前に証拠保全、を忘れないこと。
1.2.2この節のまとめ
- 集約＝Security Hub／対応＝EventBridge→Lambda/SSM
- 封じ込め＝インスタンス隔離＋資格情報の無効化/ローテーション
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 複数アカウント・複数サービスのセキュリティ検出結果を一元集約し、態勢をスコア化したい。何を使いますか？
Q2. GuardDuty が脅威を検出したら、侵害された可能性のあるインスタンスを自動で隔離したい。何を起点にしますか？
Q3. アクセスキーが漏洩した可能性がある。最優先で取るべき対応はどれですか？