概要
AWSから Abuse Notice（不正利用通知） を受け取った場合、迅速かつ適切なインシデントレスポンスが求められます。Abuse Noticeは、AWSのTrust & Safetyチームが、お客様のAWSリソースが不正利用（マルウェア配布、スパム送信、DDoS攻撃への加担など）に関与している可能性を検知した際に送信される通知です。
このような通知を受けた際に最も重要なのは、対応の優先順位を正しく判断すること です。証拠を保全する前にインスタンスを再起動してしまったり、脅威の封じ込めより先に検知ツールの設定を始めてしまったりすると、原因究明に必要な情報が失われたり、被害が拡大したりする恐れがあります。
本記事では、Abuse Noticeを起点としたインシデントレスポンスの正しい優先順位と、各ステップで具体的に何を行うかを解説します。
[!NOTE] EC2インシデントレスポンスの全体手順についてはEC2でのインシデントレスポンス手順を、セキュリティグループによるインスタンス隔離の詳細設計についてはEC2隔離用セキュリティグループの設計パターンを、EBSスナップショットによるフォレンジック取得の詳細についてはAWS EC2フォレンジック：EBSスナップショット取得を参照してください。
クラウドおさるAbuse Notice が届いたとき、何から手を付けるかの順番を確かめる記事でござる。証拠保全、封じ込め、調査。この並びを実際にコンソールで追っていくのでござるな。
この記事のメリット
- AWS Abuse Noticeとは何か、どのような場合に送信されるかを理解できる
- インシデントレスポンスの正しい優先順位（証拠保全→封じ込め→調査）を把握できる
- 証拠保全でやるべきこと（EBSスナップショット取得）と、やってはいけないこと（インスタンスの再起動）を明確に区別できる
- フォレンジックワークステーションの概念とネットワーク隔離の設計を理解できる
- SCS試験の「インシデント対応」に関する問いに正確に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
AWS Abuse Noticeとは
AWS Abuse Noticeは、AWSのTrust & Safetyチームが送信する通知で、お客様のAWSリソースが以下のような不正利用に関与している可能性がある場合に届きます。
- スパム: EC2インスタンスからの大量メール送信
- ポートスキャン: 他のホストへの不正なポートスキャン
- DDoS攻撃: 分散型サービス拒否攻撃への加担
- マルウェアホスティング: マルウェアの配布に使用されている
- 不正コンテンツのホスティング: 著作権侵害コンテンツの配信
Abuse Noticeには、AWS が把握している不正利用の内容と、いつまでに回答が必要かが記載されています。通知に記載された期限内に調査・対処を行い、その内容を AWS に返信する必要があります。回答がない、または対応が不十分な場合は、リソースの停止やアカウントの制限が行われる可能性があります。
インシデントレスポンスの優先順位
Abuse Noticeを受け取った際の対応は、以下の優先順位で行います。この順序を守ることが、フォレンジック調査の成功と被害の最小化にとって重要です。なお、AWS のドキュメント「侵害された可能性のある Amazon EC2 インスタンスの修復」でも、まず専用の隔離用セキュリティグループに付け替えて分離し、それから原因を特定する流れが示されています。証拠保全（スナップショット取得）はインスタンスを止めずに実行できるため、隔離と前後しても構いませんが、いずれの場合もインスタンスの停止・再起動・終了は行わないことが要点です。
| 優先順位 | ステップ | 目的 | 具体的な作業 |
|---|---|---|---|
| 1 | 証拠保全 | 調査に必要な情報を失わない | EBSスナップショットの取得 |
| 2 | 封じ込め | 被害の拡大を防ぐ | セキュリティグループによるネットワーク隔離 |
| 3 | 調査 | 根本原因を特定する | フォレンジックワークステーションからの分析 |
ステップ1: 証拠保全
最初に行うべきは 証拠の保全 です。侵害されたインスタンスのEBSボリュームのスナップショットを取得し、ディスク上の証拠を保存します。
EBSスナップショットを取得する理由は以下の通りです。
- インスタンスのディスク内容をポイントインタイムで保存できる
- スナップショットから別のEBSボリュームを作成し、フォレンジックワークステーションにアタッチして安全に分析できる
- 元のボリュームに影響を与えずに調査が可能
ステップ2: 封じ込め（ネットワーク隔離）
証拠を保全したら、次に 脅威の封じ込め を行います。侵害されたインスタンスをネットワーク的に隔離し、外部への不正通信を遮断します。
隔離の方法は、インスタンスのセキュリティグループを 隔離用セキュリティグループ に置き換えることで実現します。
隔離用セキュリティグループのルール設計は以下の通りです。
| ルール種別 | 方向 | 設定 |
|---|---|---|
| インバウンド | 許可 | フォレンジックワークステーションのIPアドレスからのSSHアクセスのみ |
| アウトバウンド | すべてブロック | デフォルトのアウトバウンドルール（0.0.0.0/0）を削除 |
この設計により、以下を実現します。
- 攻撃者のC2（Command and Control）サーバーとの通信を遮断
- 外部への不正なデータ送信を防止
- フォレンジック担当者のみがインスタンスにアクセス可能
[!NOTE] 隔離用セキュリティグループの詳細な設計パターンについては、EC2隔離用セキュリティグループの設計パターンを参照してください。
ステップ3: 調査
証拠保全と封じ込めが完了したら、フォレンジックワークステーション を使って調査を行います。
フォレンジックワークステーションとは、侵害されたインスタンスの調査専用に用意するEC2インスタンスです。以下の特徴があります。
- 侵害されたインスタンスと同じVPCまたはアカウント内に配置
- フォレンジックツール（ディスク分析、ログ解析ツール等）がインストール済み
- 保全したEBSスナップショットからボリュームを作成し、アタッチして分析
- 侵害されたインスタンスへのSSHアクセスが可能（隔離SGで許可されている）
やってはいけない対応
Abuse Noticeを受け取った際に、誤った対応をすると証拠が失われたり、対応が遅れたりします。以下の対応は避ける必要があります。
| やってはいけない対応 | 理由 |
|---|---|
| インスタンスの再起動・停止 | メモリ上の証拠（実行中のプロセス、ネットワーク接続情報、マルウェアのランタイムデータ）が消失する。揮発性データはディスクには残らないため、再起動すると復元できない |
| インスタンスの終了（削除） | すべての証拠が失われ、原因究明が不可能になる |
| GuardDutyの有効化を優先する | Abuse Noticeの時点でインシデントは既に確認されている。検知フェーズは終わっているため、今から検知サービスを有効化しても意味がない。証拠保全と封じ込めを優先する |
| Security Hubによる対応を優先する | Security Hubはセキュリティ体制の全体管理ツールであり、インシデントの初動対応には適さない。まず証拠保全と封じ込めを行った上で、事後の改善プロセスで活用する |
| セキュリティグループで特定ポートだけをブロック | 攻撃者は別のポートに切り替える可能性がある。フォレンジック用アクセスを除くすべての通信をブロックする |
クラウドおさる慌てて再起動すると、実行中のプロセスや接続情報といったメモリ上の証拠が消えて戻らないのでござる。猿山のオンコール当番も、夜中に叩き起こされて真っ先に電源を入れ直したら、長老会に何も説明できなくなるでござろう。止めずに、まず残すのでござるぞ。
Abuse Noticeと既存のセキュリティサービスの関係
Abuse Noticeを受け取った状況と、GuardDutyやSecurity Hubなどのセキュリティサービスの役割を整理します。
| サービス | 役割 | Abuse Notice受信時の位置づけ |
|---|---|---|
| Amazon GuardDuty | 脅威の検知 | すでにAWSが不正利用を確認済みのため、検知フェーズは完了している。事後の継続監視として有用 |
| AWS Security Hub | セキュリティ状態の可視化・管理 | インシデントの初動対応ツールではない。事後のセキュリティ体制改善に活用する |
| Amazon Detective | インシデントの調査・分析 | フォレンジック分析を補完するツールとして有用だが、初動の証拠保全・封じ込めが優先 |
| AWS CloudTrail | API操作の記録 | 調査フェーズで、誰がいつどのようなAPI操作を行ったかを確認するために活用する |
実践
前提条件
- リージョン:
ap-northeast-1（東京） - 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| VPC | lab-vpc | 検証用VPC |
| EC2インスタンス | compromised-instance | 侵害を受けたインスタンス（想定） |
| EC2インスタンス | forensics-workstation | フォレンジック調査用ワークステーション |
ステップ1: 侵害インスタンスのEBSボリュームを確認する
まず、侵害を受けたインスタンスにアタッチされているEBSボリュームを確認します。
- AWSマネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
EC2と入力し、表示された「EC2」を選択します - 左側ナビゲーションの「インスタンス」→「インスタンス」を選択します
- インスタンス一覧で
compromised-instanceのインスタンスIDをクリックし、インスタンスの詳細画面を開きます - 画面下部のタブから「ストレージ」を選択します
- アタッチされているEBSボリュームのボリュームID（例:
vol-xxxxxxxxxxxxxxxxx）をメモします
ステップ2: EBSスナップショットを取得する
証拠保全のため、侵害インスタンスのEBSボリュームのスナップショットを取得します。
- 左側ナビゲーションの「Elastic Block Store」→「ボリューム」を選択します
- ステップ1でメモしたボリュームIDのボリュームを選択します
- 「アクション」→「スナップショットの作成」を選択します
- 「スナップショットを作成」画面が開きます。「スナップショットの詳細」の「説明」に
Forensic snapshot - compromised-instance - incident responseと入力します - 「タグ」セクションで「新しいタグを追加」を3回クリックし、以下の3つのタグを入力します
- キー:
Name、値:forensic-snapshot-compromised-instance - キー:
Purpose、値:incident-response - キー:
Status、値:evidence
- ページ下部の「スナップショットを作成」をクリックします
- 左側ナビゲーションの「Elastic Block Store」→「スナップショット」を選択し、作成したスナップショットの「スナップショットのステータス」が「完了済み」になるまで待ちます（8GiBのボリュームで数分程度）
注意: スナップショットの作成中もインスタンスは稼働し続けます。この時点ではインスタンスを停止・再起動しないでください。メモリ上の証拠が失われます。
ステップ3: 隔離用セキュリティグループを作成する
侵害インスタンスをネットワーク的に隔離するためのセキュリティグループを作成します。
- 左側ナビゲーションの「ネットワーク＆セキュリティ」→「セキュリティグループ」を選択します
- 右上の「セキュリティグループを作成」をクリックします
- 「基本的な詳細」で以下の情報を入力します
- セキュリティグループ名:
quarantine-sg - 説明:
Isolation SG for incident response - allow forensics access only - VPC:
lab-vpc（VPCを選択すると、アウトバウンドルールにデフォルトの「すべてのトラフィック 0.0.0.0/0」が自動で追加されます） - 「インバウンドルール」セクションで「ルールを追加」をクリックし、以下を入力します
- タイプ:
SSH（プロトコルTCP・ポート範囲22は自動で入ります） - ソース:
カスタムを選び、forensics-workstationのプライベートIPアドレスを/32付きで入力します（例:10.80.1.229/32） - 説明 – オプション:
Forensics workstation access only
- 「アウトバウンドルール」セクションで、デフォルトのルール（すべてのトラフィック 0.0.0.0/0）を「削除」します。「このセキュリティグループにはアウトバウンドルールがありません。」と表示されれば、外部への通信はすべて遮断されます
- ページ下部の「セキュリティグループを作成」をクリックします
- 作成完了画面が表示され、セキュリティグループIDが確認できます
クラウドおさる隔離用 SG は、インバウンドをフォレンジックワークステーションからの SSH だけにし、アウトバウンドは空にするのが肝でござる。特定のポートだけ塞ぐのでは、攻撃者が別のポートに切り替えれば抜けられてしまうのでござるな。
ステップ4: 侵害インスタンスのセキュリティグループを置き換える
侵害インスタンスの既存のセキュリティグループを隔離用セキュリティグループに置き換えます。
- 左側ナビゲーションの「インスタンス」→「インスタンス」を選択します
compromised-instanceのチェックボックスを選択します- 「アクション」→「セキュリティ」→「セキュリティグループを変更」を選択します
- 「関連付けられたセキュリティグループ」の検索ボックス（プレースホルダは「セキュリティグループを編集」）をクリックし、一覧から
quarantine-sgを選択して、右側の「セキュリティグループを追加」をクリックします（このボタンは、検索ボックスでセキュリティグループを選ぶまで無効のままです） - 下の一覧で、元から関連付けられていたセキュリティグループの行の「削除」をクリックし、
quarantine-sgだけが残る状態にします
- 「保存」をクリックします
ステップ5: 隔離状態を確認する
セキュリティグループの置き換えが正しく行われたことを確認します。
compromised-instanceのインスタンスIDをクリックし、詳細画面の「セキュリティ」タブを選択します- 「セキュリティの詳細」の「セキュリティグループ」が
quarantine-sgのみになっていることを確認します - 「インバウンドルール」にフォレンジックワークステーションのIPからのSSH（TCP/22）のみが表示されていることを確認します
- 「アウトバウンドルール」が「表示するルールがありません」となっている（すべてのアウトバウンド通信がブロックされている）ことを確認します
これで、侵害インスタンスはフォレンジックワークステーションからのSSHアクセスのみを受け付け、外部への通信はすべてブロックされた状態になります。
ステップ6: インシデントレスポンスチェックリストの確認
ここまでの対応が完了したら、以下のチェックリストで対応状況を確認します。
| チェック項目 | 確認内容 |
|---|---|
| EBSスナップショットの取得 | 侵害インスタンスのすべてのEBSボリュームについてスナップショットを取得したか |
| スナップショットのタグ付け | インシデント対応の証拠であることがわかるタグを付与したか |
| セキュリティグループの隔離 | 侵害インスタンスのSGを隔離用SGに置き換えたか |
| アウトバウンド通信のブロック | アウトバウンドルールをすべて削除し、外部通信を遮断したか |
| インスタンスの稼働維持 | インスタンスを再起動・停止していないか（メモリ証拠の保全） |
| CloudTrailログの確認準備 | 調査フェーズでCloudTrailを確認する準備ができているか |
クラウドおさる問われるのは、不正利用がすでに確認された時点で何を先にやるかの順番でござる。GuardDuty や Security Hub の有効化といった検知・可視化の話と、初動の証拠保全・封じ込めを取り違えやすいのでござるな。
まとめ
本記事のポイントを整理します。
- AWS Abuse Noticeは、AWSリソースが不正利用に関与している可能性がある場合にAWSから送信される通知 です。期限内に適切な対応と報告が求められます
- インシデントレスポンスの優先順位は「証拠保全→封じ込め→調査」 です。この順序を守ることで、フォレンジック調査に必要な情報を失わずに被害の拡大を防止できます
- 証拠保全ではEBSスナップショットを取得し、インスタンスは再起動しない ことが重要です。再起動するとメモリ上の揮発性データ（実行中のプロセス、ネットワーク接続情報など）が消失します
- 封じ込めでは隔離用セキュリティグループに置き換え、フォレンジックワークステーション以外のすべての通信をブロック します。特定ポートだけのブロックでは不十分です
- GuardDutyやSecurity Hubの有効化はインシデント初動の優先事項ではない です。Abuse Noticeの時点で不正利用は確認済みであり、まず証拠保全と封じ込めを行います
参照先
- AWS 不正使用についての報告
- 侵害された可能性のある Amazon EC2 インスタンスの修復
- Amazon EBS スナップショットの作成
- Amazon EC2 のセキュリティグループ
- AWS CloudTrail とは
- AWS セキュリティインシデント対応ガイド
