概要
EC2インスタンスが侵害された場合、「まず何をするか」が調査の成否を左右します。 AWSはセキュリティインシデントへの対応として、NISTのフレームワークに基づく検出 → 分析 → 封じ込め → 根絶 → 復旧という一連のフローを推奨しています。 この記事では、侵害されたEC2インスタンスを例に、各フェーズで実施すべき内容と全体の流れを解説します。各フェーズで使用するAWSサービス（GuardDuty・Security Hubなど）の詳細な設定方法や仕組みについては、個別の記事で別途解説します。
この記事のメリット
- インシデントレスポンスの5フェーズ（検出・分析・封じ込め・根絶・復旧）の全体像を理解できる
- 各フェーズで使用するAWSサービスの役割と位置付けを把握できる
- AWSが推奨する証拠収集の順序（Order of Volatility）を把握できる
- EBSスナップショット・メモリ取得・ログ保全による証拠保全の手順がわかる
- 「やってはいけない対応」（誤った隔離タイミング・証拠汚染）の理由を理解できる
- SCS試験のインシデントレスポンス問題で正確な判断ができるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
インシデントレスポンスの5フェーズ
AWSのインシデントレスポンスはNISTのフレームワークに基づく以下の5つのフェーズで構成されます。
| フェーズ | 目的 | 主なアクション |
|---|---|---|
| 検出（Detection） | 潜在的なセキュリティイベントを特定する | GuardDuty・Security Hubによるアラート |
| 分析（Analysis） | インシデントの確認と範囲を評価する | EBSスナップショット・ログ保全、影響範囲の調査 |
| 封じ込め（Containment） | 被害の拡大を防ぐ | インスタンスのネットワーク隔離 |
| 根絶（Eradication） | インシデントの原因を除去する | 不正リソースの削除・脆弱性の修正 |
| 復旧（Recovery） | 安全な状態に戻す | クリーンなインスタンスへの置き換え |
なお、これらのフェーズは必ずしも順番通りに発生するわけではありません。たとえば封じ込めと根絶の後、対策が有効かどうかを検証するために分析フェーズに戻ることもあります。
Step1: 検出（Detection）
侵害をいち早く検知するために、AWSでは複数のセキュリティサービスが連携して動作します。
| サービス | 役割 |
|---|---|
| Amazon GuardDuty | VPC Flow Logs・CloudTrail・DNSログを継続的に分析し、不審な挙動を自動検知する |
| AWS Security Hub | GuardDuty・Inspector・Macieなど複数サービスの検知結果を一元管理する |
| Amazon EventBridge | 検知結果をトリガーにSNS通知やLambda実行などの自動対応を実行する |
GuardDutyはEC2インスタンスの侵害に関連する脅威（SSHブルートフォース・暗号通貨マイニング・C&Cサーバーとの通信など）を自動で検知し、Security Hubに集約します。検知結果はEventBridgeルールを使ってSNS経由で担当者へアラートを送ることが可能です。
各サービスの詳細な設定方法や検知パターンについては、別途個別の記事で解説します。
Step2: 分析（Analysis）
検出されたイベントがインシデントかどうかを判断し、影響範囲を評価します。同時に、後続の調査に必要な証拠を保全します。
証拠収集の順序（Order of Volatility）
AWSでは、EC2インスタンスからの証拠収集を以下の順序で実施することを推奨しています。揮発性の高いデータほど先に取得し、後続の封じ込め（ネットワーク隔離）によって証拠が失われないようにします。
| 順序 | 手順 | 内容 |
|---|---|---|
| 1 | インスタンスメタデータの取得 | IPアドレス・VPC ID・起動時刻・IAMロールなどの情報を記録 |
| 2 | インスタンス保護とタグの有効化 | 終了保護を有効化し、quarantine などのタグを付与して誤操作を防止 |
| 3 | ディスクの取得（EBSスナップショット） | 侵害時点のディスク状態を保全 |
| 4 | メモリの取得 | OSメモリのイメージを取得（EBSスナップショットに含まれない揮発性データ） |
この4ステップが完了した後に、Step3の封じ込め（ネットワーク隔離）を実施します。
EBSスナップショットの取得
インスタンスのEBSボリュームのスナップショットを取得することで、侵害時点のディスク状態を保全します。
- スナップショットはS3に保存されるため、インスタンスを終了しても証拠が失われません
- 後からフォレンジクス専用のインスタンスにボリュームをアタッチして分析できます
- 本番アカウントとは別のフォレンジクス専用アカウントにスナップショットをコピーすることで、証拠の改ざんリスクを排除できます
メモリの取得
EBSスナップショットにはメモリ上のデータ（実行中のプロセス・ネットワーク接続・復号済みの認証情報など）は含まれません。メモリを取得する場合は、サードパーティのオープンソースツールまたは商用ツールをEC2インスタンス上で実行してメモリイメージを作成します。なお、ツールを実行するとファイルシステムへの書き込みが発生するため、EBSスナップショットの取得後に行います。
ログの保全
調査に使用するログは主に以下の3種類です。
| ログ | 取得できる情報 |
|---|---|
| CloudTrail | APIコール履歴（誰が・いつ・何の操作を行ったか） |
| VPC Flow Logs | ネットワーク通信のメタデータ（送信元・宛先IP・ポート） |
| OS/アプリログ | ログイン履歴・プロセス起動履歴・エラーログ |
ログはS3へエクスポートして保管します。侵害されたアカウント内にのみ保管すると攻撃者による削除リスクがあるため、別アカウントへの転送やS3 Object Lockによる削除保護が推奨されます。
保全したEBSスナップショットをフォレンジクス環境にアタッチし、ファイルシステムやログを分析して侵害の原因・経路・影響範囲を特定します。詳細な調査手法については、別途「AWSデジタルフォレンジクス」の記事で解説します。
Step3: 封じ込め（Containment）
Step2の証拠収集（メタデータ取得・EBSスナップショット・メモリ取得）が完了した後、インスタンスをネットワークから隔離して被害の横展開を防ぎます。揮発性の高い証拠を先に確保してから隔離することで、証拠を失わずに封じ込めを実施できます。具体的な隔離方法については、別途「EC2隔離の実装方法」の記事で詳しく解説します。
AWS公式ドキュメントでは「既存SGからルールを削除する」方法と「隔離専用SGへ付け替える」方法の両方が封じ込め手段として紹介されていますが、元のSG構成を保全でき、調査アクセスも維持しやすい点から、隔離専用のセキュリティグループへの付け替えがより望ましいアプローチです。
Step4: 根絶（Eradication）
封じ込め後、インシデントの原因となった不正なリソースやアクセス経路を除去します。
- 侵害に使われた認証情報（IAMアクセスキー・SSHキー）を無効化・ローテーションします
- マルウェアや不正なプロセスを特定し、除去します
- 脆弱性の原因（パッチ未適用・設定ミス）を修正します
Step5: 復旧（Recovery）
侵害されたインスタンスは再利用せず、クリーンなAMIから新しいインスタンスを起動することが原則です。
- 侵害されたインスタンスのOSにはバックドアが仕込まれている可能性があるため、パッチ適用や設定変更では根本解決になりません
- 再発防止策（脆弱性の修正・IAMポリシーの見直し・セキュリティグループの強化）を適用した新しいAMIを用意します
- 復旧後、同様の侵害が発生しないかGuardDutyで継続監視します
なお、侵害されたインスタンスの挙動をさらに詳しく調査したい場合は、インスタンスのAMIを作成し、フォレンジクス専用アカウント内のサンドボックス環境で再起動して観察するアプローチも有効です。本番環境から完全に分離した状態でマルウェアの動作確認や通信先の特定を行えます。
コラム: やりがちな誤った対応
「セキュリティグループのルールをすべて削除する」 AWS公式ドキュメントでは封じ込め手段の一つとして紹介されていますが、すべてのルールを削除すると調査に必要なSSH/SSM接続まで遮断されてしまいます。また、削除前のルール構成は攻撃経路の手がかりになる場合があり、復旧も困難です。ベストプラクティスとしては「隔離専用SGへの付け替え」がより望ましいアプローチです。
「EBSスナップショットより先にメモリ取得のツールを実行する」 メモリ取得にはOSにツールをインストールして実行する必要があり、ファイルシステムへの書き込みが発生します。EBSスナップショットの取得前にツールを実行すると、ディスクの状態が変化して証拠が汚染されるリスクがあります。正しい順序は「EBSスナップショット取得 → メモリ取得」です。なお、ディスクやメモリを別途取得できない場合は、インスタンスへのコマンド実行（Systems Manager経由など）によるライブレスポンスでデータを収集するという選択肢もありますが、その場合もシステムへの変更が生じることを理解した上で実施することが重要です。
まとめ
侵害されたEC2インスタンスへの対応は、NISTフレームワークに基づく5つのフェーズで進めることが重要です。
| フェーズ | AWSでの実装 |
|---|---|
| 検出 | GuardDuty + Security Hub によるアラート |
| 分析 | メタデータ取得 → インスタンス保護 → EBSスナップショット → メモリ取得の順で証拠保全・ログのS3保管（別アカウントが推奨） |
| 封じ込め | 隔離専用SGへの付け替えがより望ましい |
| 根絶 | 不正な認証情報の無効化・脆弱性の修正 |
| 復旧 | クリーンなAMIからの再構築 |
SCS試験では「侵害後にまず何をすべきか」という問いに対して、証拠を失わない・汚染しないという観点で選択肢を判断することが重要です。特に「メタデータ取得 → EBSスナップショット → メモリ取得 → ネットワーク隔離」という収集の順序（Order of Volatility）は、問題文の選択肢を絞り込む際の判断軸になります。
