個人で管理しているLinuxサーバーやクラウド環境で、「見覚えのない海外IPからのログイン形跡がある」「高額なGPUインスタンスが勝手に立ち上がっている」「身に覚えのないプロセスがCPUを占有している」といった異常を発見した瞬間、強烈な不安と焦燥感に襲われます。「今すぐサーバーを削除してなかったことにしたい」「とりあえず再起動してみよう」と考えがちですが、パニックに任せた衝動的な操作は、攻撃者が最も喜ぶ「証拠隠滅」に手を貸す結果となります。
セキュリティインシデントにおける初動対応（最初の30分から数時間）の成否は、その後の被害規模を最小限に食い止められるか、侵入原因を特定して再発を防げるか、そして法的な報告義務や対外的な説明責任を果たせるかを大きく左右します。
この記事では、個人運用サーバーやクラウド環境で不正アクセスの疑いが生じた、あるいは侵入が確定した際にエンジニアが取るべき「技術的初動対応マニュアル」を解説します。絶対にやってはいけないNG行動の整理から、証拠保全、ネットワーク遮断、認証情報の全失効、侵入経路とデータ漏洩の検証、公的機関（個人情報保護委員会や警察、IPA）への相談基準、そして安全な復旧手順までを順を追って網羅します。
この記事で行うこと
- パニック時の混乱を防ぐ「発覚後30分の初動タイムライン」を把握する
- 証拠消失や被害拡大を招く5大NG行動を正しく理解する
- スナップショットの作成と揮発性データの記録による確実な証拠保全を行う
- ネットワーク隔離と認証情報の全失効により被害の拡大を即座に封じ込める
- 侵入経路の特定と保存データの漏洩有無を客観的に検証する
- 個人情報保護法に基づく個人情報保護委員会（PPC）や警察・IPAへの報告基準を確認する
- 侵害されたサーバーを使い回さず、クリーンな環境へ安全に復旧する手順を確立する
前提条件・対象読者
- AWS、Google Cloud、さくらのVPS、ConoHa、Linode等でLinuxサーバーを運用している個人開発者・エンジニア・小規模事業者
- 不正アクセスの兆候を発見し、今まさに緊急の対処法を求めている方
- 将来の万が一に備えて、確実なインシデント初動マニュアルを手元に備えておきたい方
- 最終確認日：2026年11月（IPA「中小企業のためのセキュリティインシデント対応の手引き」、個人情報保護委員会「漏えい等の対応とお役立ち資料」、AWS公式インシデント対応ガイドに準拠）
1. Quick Reference：インシデント初動の30分アクション早見表
不正アクセスの疑いが生じた直後、最初の30分で実施すべきアクションをタイムライン順に整理しました。
| 時間帯 | フェーズ | 最優先アクション | やってはいけないNG操作 |
|---|---|---|---|
| 0〜5分 | 現状固定 | ターミナルログ開始、画面キャプチャ、ディスクスナップショット作成 | サーバーの即時削除、OSのシャットダウン |
| 5〜15分 | ネットワーク隔離 | クラウドFW / セキュリティグループで全通信を遮断（インバウンド・アウトバウンド） | OS内部からの iptables 誤設定による切断 |
| 15〜25分 | 認証全失効 | ルート・IAM・SSH・APIキーの無効化とパスワード変更 | 侵害された疑いのあるPC・端末からのパスワード変更 |
| 25〜30分 | 不正リソース停止 | 身に覚えのない課金インスタンスの停止、不正プロセスの特定 | 単発でのプロセスkill（親プロセスが再生成） |
| 30分以降 | 調査・復旧計画 | ログ分析、漏洩データの特定、公的機関への相談、クリーン再構築 | 侵害された既存サーバーのそのまま再利用 |
インシデント初動対応の基本サイクルは、以下の5つのステップで構成されます。必ず「証拠保全」を行ってから「通信遮断」へ進む順序を守ることが極めて重要です。
[インシデント初動対応の5大ステップ]
1. 証拠保全（最初の10分）
│ ──> ディスクスナップショット取得、画面記録、揮発情報の退避
2. 封じ込め（10〜20分）
│ ──> ネットワーク完全隔離、全認証情報（IAM/SSH/APIキー）の失効
3. 不正リソース停止（20〜30分）
│ ──> 不正インスタンス停止、課金被害の停止
4. 原因調査・影響範囲特定
│ ──> 侵入経路特定、データ漏洩検証、公的機関への相談判定
5. 安全な復旧
└──> クリーン環境の新規構築、検証済みデータの復元
2. 絶対にやってはいけない5大NG行動
不正アクセスに直面した際、焦りから以下の行動をとってしまうと、調査が不可能になったり、かえって被害を拡大させます。
2-1. 慌ててサーバーインスタンスやボリュームを削除する
「怖いから今すぐ消してしまいたい」とサーバーを破棄してしまうと、攻撃者がどこから侵入したのか、データベースの中身が盗まれたのか、何台の外部サーバーに攻撃を仕掛けたのかという証拠が完全に消滅します。原因が不明なままでは、新しいサーバーを立てても同じ手口で即日再侵入されます。
2-2. 安易にOSをシャットダウン・再起動する
サーバーを再起動すると、揮発性メモリ（RAM）上にのみ存在していたマルウェアのプロセス、確立されていたネットワーク接続セッション、未保存のコマンド履歴、削除されたファイルのディスク記述子がすべて消去されます。
2-3. 単発で不審プロセスをkillする・不審ファイルを適当に消す
攻撃者はバックドアを維持するために、複数のプロセスで死活監視を行っていたり、crontabやsystemdタイマーで数分おきにプロセスを再生成する仕掛けを設けています。単発でプロセスを終了させると、攻撃者に調査を悟られ、残されていたすべてのログファイルを一括削除されるなどの対抗措置を取られるリスクがあります。
2-4. 侵害された可能性のあるサーバーから直接クラウド管理操作を行う
侵入されたサーバー上でAWS CLIやgcloudコマンドを実行して、権限変更やリソース削除を試みてはいけません。攻撃者のシェルスクリプトやルートキットにクレデンシャルが傍受される危険があります。管理コンソールへのアクセスやAPIキーの無効化は、必ず手元のクリーンな管理者PCから実施します。
2-5. 身代金要求（ランサムウェア）に独断で応じる・攻撃者に連絡する
サーバー上のファイルが暗号化され、画面やテキストファイルに「復旧したければ暗号資産を送金せよ」と記載されている場合でも、絶対に攻撃者に連絡したり身代金を支払ってはいけません。金銭を支払っても復旧キーが渡される保証はなく、かえって「身代金を払うカモ」として更なる恐喝の標的になります。
3. ステップ1：証拠保全（最初の10分）
最初のステップは、攻撃の現状をそのまま固定する「証拠保全（フォレンジック・スナップショット）」です。
3-1. クラウド/VPSコンソールからのディスクスナップショット取得
OS内部を操作する前に、クラウドやVPSの外部管理コンソールから、対象サーバーのディスクボリューム（EBSボリュームや仮想ディスク）全体の「スナップショット」を作成します。
AWSの場合
EC2コンソールから「Elastic Block Store」の「ボリューム」を選択し、「アクション」から「スナップショットの作成」を実行します。
Google Cloudの場合
Compute Engineコンソールの「ディスク」から該当ディスクを選択し、「スナップショットを作成」を実行します。
VPS（さくらのVPS等）の場合
コントロールパネルのバックアップ機能やスナップショット機能を利用して、ディスク全体のバックアップイメージを即時作成します。
3-2. ターミナル作業の全記録と画面キャプチャ
調査開始時のターミナル操作は、後から公的機関や専門家に提示できるようにすべてテキストファイルに記録します。
script incident_investigation_$(date +%Y%m%d_%H%M%S).log
script コマンドを実行してから作業を開始することで、ターミナル上で入力したすべてのコマンドと出力結果がタイムスタンプとともに記録されます。作業終了後に exit を入力すれば記録が完了します。また、クラウドコンソールの異常な請求画面や警告メッセージは、URLと日時が分かるようにブラウザのスクリーンショットを保存します。
3-3. 揮発性メモリ・接続情報の退避
現在サーバーにSSHログインできている場合、メモリ上にしか残らない一時的な情報をファイルに書き出して安全な外部へ保存します。
{
echo "=== DATE ==="
date -u
echo "=== UPTIME & LOAD ==="
uptime
echo "=== LOGGED IN USERS ==="
w
echo "=== LOGIN HISTORY ==="
last -F -n 30
echo "=== ACTIVE CONNECTIONS ==="
ss -tulpn
echo "=== PROCESS LIST ==="
ps auxf
} > /tmp/volatile_evidence.txt
この出力ファイルを scp や安全なストレージ経由で手元の調査用PCへダウンロードしておきます。
4. ステップ2：被害拡大の封じ込め（ネットワーク遮断と認証失効）
証拠を固定したら、直ちに外部との通信を断ち、悪用可能な認証情報をすべて無効化して被害の拡大を物理的に止めます。
4-1. ネットワークの即時隔離（Isolation Security Groupの適用）
サーバーをインターネットから完全に切り離します。OS内部でファイアウォールを変更するのではなく、クラウド基盤側の機能を使用します。
隔離用セキュリティグループの作成
インバウンド（受信）およびアウトバウンド（送信）の全ルールを空（すべての通信を拒否）にした「隔離用セキュリティグループ（Isolation SG）」を作成します。
インスタンスへの適用
対象の仮想マシン（EC2やCompute Engine）に割り当てられている既存のセキュリティグループをすべて外し、隔離用セキュリティグループのみを割り当てます。
これにより、攻撃者からのリモート接続が切断され、外部サーバーへのデータ持ち出しやDDoS攻撃への加担が瞬時に停止します。以降の調査は、クラウド提供の「シリアルコンソール」や「VNCコンソール」から行います。
4-2. ルート・IAMユーザー・サービスアカウントのパスワード・キー全失効
攻撃者がクラウドの管理アカウント自体に侵入している可能性があるため、関連するすべての認証情報を手元の安全なPCから無効化します。
管理コンソールのパスワード変更
ルートアカウントおよびすべてのIAMユーザーのパスワードを変更し、既存のすべてのアクティブセッションをログアウトさせます。
アクセスキーの無効化（Deactivate）
発行されているすべてのアクセスキー（Access Key ID）のステータスを即座に「Inactive」に変更し、その後削除します。
サービスアカウントキーの削除
Google Cloudのサービスアカウントに作成されているJSONキーをすべて削除します。
4-3. SSH秘密鍵・APIキー・環境変数シークレットのローテーション
サーバー内部に保存されていたすべての機密情報は、攻撃者に盗み出された前提で対処します。
- サーバーに登録されていたすべてのSSH公開鍵（
~/.ssh/authorized_keys）を無効化する .envや設定ファイルに記載されていた外部サービスのAPIキー（Stripe、SendGrid、OpenAI、GitHub Personal Access Token等）をすべて各サービスのダッシュボードから再生成（ローテーション）または失効させる- データベースの管理者パスワード、アプリケーションのシークレットキーを変更する
4-4. 不正リソースの即時停止
クラウド請求の急増を止めるため、身に覚えのない仮想マシンやコンテナを停止します。
- 普段利用していないリージョン（海外リージョン等）のEC2やCompute Engineインスタンスを確認し、不審なリソースを「停止（Stop）」する（後で調査するために即座の削除は避ける）
- 未知のLambda関数やCloud Runジョブがデプロイされていないか確認し、無効化する
5. ステップ3：侵入経路調査とデータ漏洩の検証
通信を遮断し認証情報を失効させた後、スナップショットから複製した調査用ディスクを用いて、冷静に原因と影響範囲を調べます。
5-1. 侵害された時間枠（タイムライン）の策定
攻撃がいつ始まり、どの期間継続していたのかを特定します。
- ログに記録された最初の不審なアクセス日時を特定する
- クラウド請求ダッシュボードで利用料が急増し始めた日時を確認する
- サーバー内で最も古い不正ファイルの作成・変更日時（タイムスタンプ）を特定する
5-2. 侵入経路の特定
攻撃者がサーバーに入り込んだ「最初の穴」を突き止めます。主な侵入経路は以下の4つに大別されます。
経路1：SSH等の管理ポートの認証突破
パスワード総当たり（ブルートフォース）または流出したSSH秘密鍵によるログイン成功。
経路2：Webアプリケーションの既知脆弱性
WordPressの古いプラグイン、Webフレームワーク（Spring、Log4j等）のRCE（リモートコード実行）脆弱性を突いたWebシェルの設置。
経路3：GitHub等からのAPIキー・アクセスキー漏洩
公開リポジトリに誤ってプッシュされたクラウドのアクセスキーを利用した外部APIからの侵入。
経路4：管理コンソールの認証乗っ取り
フィッシングや推測可能なパスワードにより、AWSやGoogle Cloudの管理コンソールへ直接ログインされた。
5-3. 機密データ・個人情報の漏洩有無の確認
最も深刻な被害は「データの外部持ち出し」です。以下の証拠を確認します。
- データベースログの点検: 顧客データやユーザーテーブルに対する
SELECT *やダンプコマンド（mysqldump、pg_dump）の実行履歴がないか - ネットワークログの確認: VPCフローログやファイアウォールログで、数GBから数十GB単位の大規模なアウトバウンド通信が発生していないか
- 一時ファイルの確認:
/tmpや/var/tmpに、データベースのダンプファイルやZIP圧縮されたアーカイブファイルが残されていないか
6. ステップ4：公的機関・専門窓口への相談基準と報告義務
不正アクセスの被害が発生した場合、状況に応じて公的機関への相談や法令に基づく報告が義務付けられます。
6-1. 個人情報保護委員会（PPC）への報告義務基準（4要件）
個人情報保護法により、管理している個人データが漏えい、滅失、毀損した場合、またはそのおそれがある事態が生じた際、以下の4つの類型のいずれかに該当する場合は「個人情報保護委員会への報告」および「本人への通知」が法律上義務付けられています。
報告義務となる4つの類型
- 要配慮個人情報が含まれる事態（病歴、信条、犯罪歴等）
- 不正に利用されることにより財産的被害が生じるおそれがある事態（クレジットカード番号、決済アカウントのID・パスワード等）
- 不正の目的をもって行われたおそれがある事態（サイバー攻撃、不正アクセス、ランサムウェア等による侵入）
- 本人の数が1,000人を超える事態
個人運用のWebサービスであっても、不正アクセスによってユーザーのパスワードや個人情報が漏えいした（または漏えいしたおそれがある）場合、「不正の目的をもって行われたおそれがある事態」に該当するため、法律上の報告義務が発生します。
報告の期限（2段階報告）
- 速報（第一報）: 事態を知った後、速やかに（概ね3日から5日以内）に把握している範囲で報告を行う。
- 確報（続報）: 事態を知った日から30日以内（不正アクセス等の不正目的のおそれがある場合は60日以内）に、詳細な原因や再発防止策を含めて報告を行う。
個人情報保護委員会の公式ウェブサイト（https://www.ppc.go.jp/personalinfo/legal/leakAction/）にある「漏えい等報告フォーム」からオンラインで申請を行います。
6-2. 警察庁サイバー警察局・各都道府県警察への被害届提出
システムが不正に改ざんされたり、脅迫を受けたり、外部への攻撃に悪用された場合、不正アクセス禁止法違反や電子計算機損壊等業務妨害罪に該当する立派な犯罪被害です。
- 都道府県警察のサイバー犯罪相談窓口一覧（
https://www.npa.go.jp/bureau/cyber/ichiran.html）または警察相談専用電話（#9110）へ連絡します - 証拠保全したログファイル、スナップショット、画面キャプチャ、タイムラインのメモを提出し、被害届の提出や相談を行います
6-3. IPA「情報セキュリティ安心相談窓口」および届出制度
技術的な対処法に困った場合や、客観的なアドバイスを受けたい場合、独立行政法人 情報処理推進機構（IPA）の専門窓口が極めて頼りになります。
- 情報セキュリティ安心相談窓口: 電話（03-5978-7509、平日10:00〜17:00）またはメール（
anshin@ipa.go.jp）にて、ウイルス感染や不正アクセスの技術的対処に関する相談を無料で受け付けています - コンピュータウイルス・不正アクセス届出制度: IPAへの被害届出を行うことで、サイバー攻撃の手口分析や社会全体の再発防止活動に貢献できます
7. ステップ5：安全な復旧と再発防止（クリーン再デプロイ）
調査が一段落したらサービスの復旧に進みますが、ここで最大の鉄則があります。
7-1. 「侵害されたサーバーの使い回し」は絶対禁止
「不審なファイルを消したから大丈夫」「ウイルス対策ソフトで駆除したからこのまま動かそう」と、一度侵入されたOS環境をそのまま使い続けることは絶対に禁止です。
現代のマルウェアやルートキットは、カーネルレベルに潜伏したり、システムコマンドを巧妙に書き換えて自身の存在を隠蔽します。手作業による駆除では、攻撃者が残したバックドアを100パーセント見つけ出すことは不可能です。
7-2. 新規インスタンスの立ち上げとOSクリーンインストール
復旧は必ず「完全な初期化（クリーンな環境の再構築）」によって行います。
- 侵害された既存インスタンスは証拠保全のために停止状態（またはスナップショット保管）のまま隔離し、復旧には使わない
- 新規にクリーンなOSイメージから新しいインスタンスを起動する
7-3. 脆弱性を修正した安全なコードと検証済みバックアップの復元
- ソースコードの検証: Gitリポジトリのコミット履歴を確認し、不正なコードが混入していないか最新コミットを点検する
- 原因となった脆弱性の修正: 侵入経路となったWebアプリケーションのバグ、古いパッケージ、WordPressプラグインを最新版に修正・アップデートする
- データベースの復元: 侵入日時より前に取得されたクリーンなバックアップからデータを復元する。侵入後に作成されたバックアップは不正データが含まれている可能性があるため慎重に検証する
7-4. 新しい認証情報の再設定
- サーバーのSSH鍵ペアを新規に作成し直す
- データベースの接続ユーザー・パスワードを推測不能な新しい値で再発行する
- 外部APIキーをすべて新規発行し、古いキーは完全に破棄する
- クラウドのIAMロールを最小権限で再割り当てする
7-5. 事後レビューとチェックリスト運用へのフィードバック
復旧完了後、なぜインシデントが発生したのかを振り返り、根本原因に対する恒久的な防壁を講じます。
- 多要素認証（MFA）が未設定だった場合は即時強制する
- ポートが全開放されていた場合はセキュリティグループを接続元IP限定に厳格化する
- 今回の教訓を月次点検チェックリストに組み込み、定期的な点検をルーチン化する
よくある質問（FAQ）
Q1. 侵害されたサーバーを削除せずに停止したままにしておくと、追加で課金され続けませんか？
仮想マシンインスタンスを停止（Stop）した場合、CPUやメモリなどのコンピュート料金の課金は停止します。ただし、ディスク（EBSボリューム等のストレージ）の保存容量に対するわずかな課金（月数十円〜数百円程度）は継続します。証拠保全が完了し、スナップショットを安全な外部ストレージにアーカイブした後は、停止中のインスタンス自体を削除してスナップショットのみを保持することで、コストを最小限に抑えつつ証拠を残すことが可能です。
Q2. 個人が運営する小さなブログやWebサービスでも、個人情報保護委員会への報告義務はありますか？
あります。2022年4月に施行された改正個人情報保護法では、取り扱う個人情報の件数に関わらず、すべての個人情報取扱事業者に漏えい報告が義務付けられています（個人事業主や個人開発者であっても、事業として個人データを取り扱っていれば対象となります）。特に不正アクセスによる漏えいのおそれがある場合は、漏えいした人数が1人であっても報告義務の対象となります。
Q3. 警察に相談する際、証拠として何を持っていけばよいですか？
ディスクのスナップショット、ターミナルログ、サーバーのアクセスログおよび認証ログ、不審なプロセスのキャプチャ、そして「いつ何が起きたか」を時系列でまとめたタイムライン資料を準備します。可能であれば、ログをUSBメモリ等の外部媒体に保存し、改ざんされていないことを示すSHA-256などのハッシュ値を記録しておくと証拠能力が高まります。
まとめ
個人運用サーバーやクラウドの不正アクセス初動対応では、焦って操作することなく、証拠を保全しながら段階的に封じ込めを行う冷静さが求められます。
- パニック時のNG行動を避ける: 慌ててサーバーを削除・再起動せず、不審なプロセスを単発でkillしない。
- 最初の10分で証拠を固定する: クラウド管理画面からディスクスナップショットを作成し、ターミナルログと画面を記録する。
- 外部通信を即座に遮断する: 隔離用セキュリティグループを適用し、インバウンド・アウトバウンド通信を完全遮断する。
- すべての認証情報を即時失効させる: ルートやIAMパスワード、アクセスキー、SSH鍵、外部APIキーを安全な別端末から変更する。
- 侵入経路と漏洩範囲を客観的に調べる: タイムラインを作成し、データベースアクセスや外部送出パケットの規模を検証する。
- 公的機関への相談・報告義務を果たす: 個人情報保護委員会の報告基準（速報3〜5日）を確認し、警察やIPAへの相談を検討する。
- クリーンな新環境へ再構築する: 侵害されたサーバーを使い回さず、新規インスタンスに脆弱性を修正した状態で安全に復旧する。
緊急時こそ基本に立ち返り、一つひとつのステップを着実に実行して、安全で確実なインシデント解決を図ってください。
次に読むおすすめ記事
平時からの不正アクセス点検手順や、再発を防ぐための月次点検チェックリストについては、以下の記事で詳しく解説しています。
個人向けセキュリティ対策の全体像と相談窓口の使い分けは、以下の完全ガイドを参考にしてください。
