インシデントレスポンス — 事件が起きたら何をする

午前3時。あなたのスマートフォンにSlack通知が来る。「セキュリティアラート：未承認のIAMキー作成が検出されました」。心臓が止まります。さあ、どうする？

「検出から修復まで」のセキュリティオーケストレーションについて深掘りしていきます。

事件は現場で起こってる

GuardDutyが異常を検知しても、なぜ起きたのかまで調べるのは別の話ですよね。つまり、セキュリティは「検出」と「調査」と「対応」——三つの層に分かれてます。その中でも特に「調査」の部分が人力だと致命的に遅い。

ここで重要。言ってみれば Detective は 刑事です。GuardDuty が「容疑者らしい人を見つけた」って通報するなら、Detective が「この人、本当に悪いやつ？」って犯行現場のビデオから確認する。

Amazon Detective — ビヘイビアグラフの本質

Detective の核になるのが「ビヘイビアグラフ」。つまりね、CloudTrail と VPC Flow Logs と GuardDuty Finding を全部まぜて、その IAM ロールが普段何をしてるか という行動パターンを自動学習する機能です。

重要ポイント：ここで最大48時間の遅延が発生する可能性があるわけです。だから、「リアルタイムセキュリティ」には Detective 単体は向きません。その代わり EventBridge と組み合わせる——そこで初めて自動対応が可能になります。

CloudTrail は15～30分の遅延、VPC Flow Logs は3～5分、GuardDuty はほぼリアルタイム。全部の層のデータを集約して一つのグラフにするから、どうしても遅延が大きくなります。

Detective 調査フロー——4ステップ

一つ、Finding から Entity を特定する。EC2 インスタンスが疑わしい？ では、そのインスタンスに紐付く IAM ロール、ネットワークカード、セキュリティグループを全部追跡する。

二つ、Timeline で時系列に追う。具体的には「2024年4月27日 14:30、DescribeInstances」「14:30:18、GetSecretValue」「14:30:22、CreateAccessKey」——操作を秒単位で見える化。

三つ、関連 Entity をたどる。この IAM ロール、どの EC2 インスタンスから実行されたのか？ どの S3 バケットにアクセスしたのか？ つまり、攻撃経路を点と線で図解する。

四つ、コンテキスト情報を収集。IP Reputation、First Seen フラグ、複数アカウント環境での関連性——つまり「背景知識」を全部集めます。

注意。Detective のビヘイビアグラフはリセットされません。12ヶ月の完全な履歴が保持されます。だから、新規アカウントを追加すると初期2週間はグラフが不完全です。

できないこと・制約

Detective は「調査ツール」であって「検出ツール」ではない。GuardDuty が Finding を生成しなきゃ、Detective には何も出現しない——ここ重要です。

データ保持期間が12ヶ月で完全削除されます。カスタマイズ不可。コンプライアンス要件で「5年保持」が必要な場合は、CloudTrail → S3 アーカイブを別途用意。

EventBridge — セキュリティイベント駆動自動化

ここから魔法が始まります。Detective は「後追い調査」ですが、EventBridge は「起きたら即座に対応」する仕組みです。

流れとしては：GuardDuty Finding → EventBridge ルール（マッチング判定）→ Lambda / SNS / SystemsManager（実行）

重要ポイント。EventBridge のイベント配信は通常 <1秒。ただしターゲット側の処理時間は別。Lambda の Cold Start で2～3秒かかるとか、そういう話。

セキュリティイベント駆動の4パターン

パターン1：GuardDuty Finding → EC2 自動隔離。Severity 7以上で自動トリガー、セキュリティグループを「隔離SG」に切り替え。元のセキュリティグループはタグに保存しておいて、後で復旧時に参照。

パターン2：Security Hub Finding → マルチチャネル通知。Critical・High の Finding が来たら同時に SNS メール、Lambda で Slack、SMS まで送信。つまり、通知の「多重化」です。

パターン3：Config Rule 非準拠 → Automation で自動修復。DLQ（Dead Letter Queue）を併設して、修復に失敗した場合は SQS メッセージで保留——セキュリティチームが後で手動確認。

パターン4：IAM Access Analyzer Finding → 権限削除。外部アクセスが検出されたら、すぐにポリシーを削除するか Deny を追加。

ルール設計の工夫

イベントパターンで「AND条件」を書きたい場合、JSON のネスト構造が自動的に AND になります。例えば、"source": ["aws.guardduty"] かつ "detail.severity": [7, 8, 9] かつ "detail.type": ["EC2/UnauthorizedAccess*"] という風に。

ワイルドカード（*）で接頭辞マッチも可能。つまり EC2/UnauthorizedAccess の配下にある全 Finding Type をカバー。

クロスアカウント・クロスリージョンイベント

企業規模だと複数アカウントがありますよね。その場合、Security Account に中央 EventBus を構成して、Workload Account から「このアカウントの GuardDuty Finding を中央に送ってくれ」という設定をします。

結果として、セキュリティチームは「複数アカウントの Finding を一箇所で監視」——つまり、スケーラビリティが確保できます。

自動修復パイプラインの設計

GuardDuty が EC2 に問題を検出。EventBridge が Severity >= 7 でマッチして Lambda を実行。

Lambda 内では：

1. EC2 の現在のセキュリティグループをタグに記録
2. セキュリティグループを「隔離SG」（全 Ingress 拒否）に切り替え
3. CloudWatch Metrics に「EC2 Isolated」カウント
4. SNS で通知（セキュリティチームに即報）

次に、Run Command で隔離確認。その後、EBS スナップショット取得（フォレンジック用）。

最後に、Detective で調査開始。Timeline を確認して「いつ、何が起きた」を把握。

フォレンジック用 VPC 設計

重要なのが「フォレンジック VPC は外の世界と通信禁止」。つまり、Air-gapped network。攻撃者がフォレンジック VPC にも侵入するリスクを排除するため、インターネットゲートウェイもVPC Peering も禁止。

セキュリティチーム用に固定 IP からの SSH のみ許可。それ以外の egress は S3（証拠保存用）へのみ。

試験で狙われるポイント

Detective のデータ遅延は「最大48時間」ってやつですね。リアルタイム対応には向きません。

EventBridge のルール数は最大300個（ソフト上限）。ターゲット数は ルール当たり 100個。

InputTransformer で Finding の JSON をカスタマイズして、Lambda に渡すペイロード形式を制御。

言ってみれば「検出 → 自動修復 → 調査 → 監査」のサイクルを EventBridge と Detective で組み立てる——ここが試験の骨です。

まとめ

結論としてですね、セキュリティインシデント対応は「並列処理」です。

自動修復は EventBridge で即座に。調査は Detective で後追い。監査証跡は CloudTrail で永久記録。

この三つを組み合わせることで初めて「エンタープライズグレード」のセキュリティ体制が成立するわけです。