セキュリティインシデント対応は、検知・初動、証跡保全、外部報告の判断、封じ込め・復旧、再発防止という5つの作業に分けて整理できます。発見時は記録と関係者への連絡を始め、被害拡大を防ぐ判断と証跡の保護を並行して進めます。

ログ削除や独断での再起動、侵入経路を残したままの復旧は、原因究明を難しくします。少人数の情シスでも抜け漏れを防げるよう、確認項目と判断・作業・報告の役割を手順書に落とし込みます。

セキュリティインシデント対応の5ステップ完全フロー

インシデント対応は、初動から再発防止までに必要な作業を見通せる形に整理します。次の5ステップは、手順書に落とし込むための作業区分です。ひとつの作業が終わるまで次を待つ意味ではありません。被害拡大の防止、証跡保全、報告の判断は、担当を分けて並行して進めます。

時間は対応計画を作るための目安です。封じ込めや報告判断を後回しにせず、初動から並行して進めます。

関連記事：アカウント侵害に備える不正アクセス対策

対応フローで並行して動く担当と判断事項

対応フローには、作業の順序だけでなく、判断する人と引き継ぐ情報を記載します。技術担当がログを集めている間にも、責任者は業務影響を把握し、法務・広報担当は報告先と通知内容を確認する必要があります。役割が兼務の場合も、作業の担当と承認者を区別しておきます。

すべての役割を情シスだけで担う必要はありません。経営層や法務などと連絡経路を決め、外部専門家へ連絡する条件も手順書に含めておくと、技術作業中に意思決定が止まる状況を避けやすくなります。

初動の記録を次の担当へ引き継ぐ

引き継ぎでは、確認できた事実と未確認の情報を分けて記録します。「不正アクセスの疑い」と「情報漏洩を確認済み」を混同すると、調査や報告の判断を誤ります。発見時刻・影響対象・実施した操作を時系列で残し、担当が替わっても同じ状況を把握できるようにしてください。

引き継ぎ時は、次の項目が記録されているか確認します。

• 発見者・発見状況・対象システム
• 関連ログの保管先と、ネットワーク遮断・アカウント停止の実施状況
• 経営層への連絡内容
• 未確認事項と、次に調べる担当者

対策の完了も、作業したという報告だけで確定させません。封じ込めで被害拡大が止まっているか、復旧前に侵入経路へ対処できたか、再開後に異常がないかを確かめます。記録と確認結果をそろえることで、再発防止策を検討する際にも経緯をたどれます。

参考：NTTセキュリティ・ジャパン「インシデント対応とは？サイバー攻撃の被害を最小化する方法」

Step1：検知・初動対応（最初の30分で何をするか）

最初の30分は、状況把握・記録・第一報と、被害拡大を防ぐ判断に取り組みます。

インシデントの検知方法

従業員からの報告、セキュリティツールのアラート、取引先からの連絡など、発見の経路を問わず、まず何が起きているかを把握します。

最初の30分でやるべきこと

初動で確認するのは次の7項目です。担当を分け、記録・連絡と被害拡大の防止を並行して進めてください。

• 記録の開始：発生時刻・発見者・発見状況を書き留め、以降の全作業を時系列で記録し続ける
• 状況の確認：何が起きているか・影響範囲がどこまでかを把握する
• 経営層・上長への第一報：何が起きたか・現在どう対応しているかを簡潔に伝える
• 影響範囲の仮特定：どのシステム・どのデータが影響を受けているかを概算で把握する
• ネットワーク遮断の判断：感染や侵害が疑われる端末・サーバーをネットワークから切り離すかを判断する
• 証跡の保護：関連するログファイルやシステム状態を変更・削除しないよう関係者に周知する
• 外部専門家への連絡判断：自社対応が困難な場合、セキュリティベンダーやJPCERT/CCへの連絡を検討する

平時の備えとして、利用中のSaaSとアカウントの把握を進める方へ。5分でわかるJosysで製品概要を確認する

やってはいけないNG初動

原因究明や復旧を妨げるため、次の行動は避けてください。

• ログや記録を削除する：原因究明に不可欠な証跡が失われます
• 感染端末を即座に再起動する：メモリ上のフォレンジック情報が消去されます
• 独断でシステムを復旧させる：侵入経路が残ったまま復旧すると再攻撃を受けます
• インシデントの詳細を関係者以外に伝える：攻撃者に有利な情報を与える可能性があります

参考：IPA「中小企業のためのセキュリティインシデント対応の手引き」（2024年7月）

Step2：証跡（ログ・エビデンス）の収集と保全方法

初動対応と並行して、または直後に取り組むべきが証跡の収集と保全です。この作業の精度が、後の原因究明・法的対応・再発防止策の質を左右します。

証跡収集の重要性

証跡は、ログ・通信記録・システム状態など、発生した事象を示す記録です。原因究明、法的証拠、保険請求、行政への報告に使うため、消失や改変を防ぎます。

収集すべきログの種類

インシデントの種類によって収集すべきログは異なりますが、まず以下の4種類を優先的に確保してください。

• サーバーログ・システムログ：OSのイベントログ、認証ログ（ログイン成功・失敗の記録）、アプリケーションログを収集します。Windowsであればイベントビューア、Linuxであれば/var/log配下のファイルが対象です。
• ネットワークログ：ファイアウォールのアクセスログ、IDS/IPSのアラートログ、プロキシのアクセスログを収集します。外部IPとの通信記録が不正アクセスの経路特定に直結します。
• SaaS・クラウドサービスのアクセスログ：Google Workspace・Microsoft 365・Salesforceなど、各SaaSサービスの管理コンソールから監査ログをエクスポートします。サービスごとに操作方法・保存期間・エクスポート形式が異なるため、事前にAPIや手順を把握しておくことが必要です。
• エンドポイントログ：端末のEDRツールが取得しているプロセス実行履歴・ファイル操作ログ・ネットワーク接続履歴を収集します。

SaaS環境でのログ収集の課題

各SaaSでログの取得先・形式・保存期間が異なります。情シスが把握していないSaaSの利用を指すシャドーITも含め、利用サービスを確認し、管理担当者とログの取得先を整理してください。後述のJosys活用の章では、その前提となるSaaSとアカウントの管理を扱います。

証跡保全の注意事項

収集したログは、改ざん防止の観点から適切に保全する必要があります。ハッシュ値（MD5またはSHA-256）を記録し、ファイルの一致性を後から検証できるようにしておきましょう。収集した証跡のオリジナルには手を加えず、必ずコピーを作業用として使用することが基本です。

参考：各種SaaSのAPIアクセスログ入手方法

Step3：外部報告義務の判断フローと届け出先

インシデントの種類によっては、外部機関への報告が法律で義務付けられています。報告が必要かどうか・どこに報告するか・いつまでに報告するかを正確に判断することが、法的リスクの回避につながります。

個人情報保護委員会への報告

2022年施行の改正個人情報保護法では、一定の条件を満たす個人情報漏洩が発生した場合、個人情報保護委員会への報告が義務付けられています。報告が必要となる主なケースは以下の通りです。

• 要配慮個人情報（病歴・障害・犯歴等）の漏洩
• 財産的被害が生じる可能性がある漏洩（クレジットカード番号・口座情報等）
• 不正の目的による漏洩が疑われる場合（不正アクセスによる漏洩等）
• 1,000件を超える個人情報の漏洩

速報（発覚後速やかに。個人情報保護委員会の目安は発覚日から3〜5日以内）と確報（原則30日以内、不正の目的によるおそれがある場合は60日以内）の2段階での報告が必要です。速報では詳細が判明していなくても、判明した範囲での情報を報告することが認められています。

IPAへの届け出

IPA（情報処理推進機構）への届け出は任意です。ウイルス感染や不正アクセスなどの被害情報は、同種被害を防ぐための注意喚起に活用されます。

警察への被害届

不正アクセスやランサムウェア感染など、犯罪行為が疑われる場合は都道府県警察のサイバー犯罪相談窓口への相談・届け出を検討します。証跡保全と並行して相談を検討し、保全済みの情報と未確認事項を分けて伝えます。

取引先・顧客への通知

個人情報が漏洩した場合は、影響を受けた本人（顧客・取引先担当者等）への通知も必要です。通知のタイミングは早いほど信頼維持につながりますが、誤った情報を提供すると混乱を招くため、ある程度の事実確認ができた段階で行うことが適切です。法律事務所への相談を経て通知文書を作成することも選択肢に入れてください。

参考：個人情報保護委員会「漏えい等の報告・本人への通知」

Step4：被害封じ込めとシステム復旧の進め方

封じ込めは初動から進め、外部報告も並行します。復旧は侵入経路への対処を確認したうえで、再感染や二次被害を防ぎながら段階的に進めます。

封じ込め（短期・長期の2段階）

封じ込めは2段階に分けて実施します。短期的封じ込めは被害拡大を即座に食い止めるための緊急措置で、感染端末・サーバーのネットワーク遮断、不審なアカウントの一時停止、外部への通信ブロックなどが該当します。業務への影響が生じても、この段階では被害拡大防止を最優先に判断してください。

長期的封じ込めは根本的な原因を排除するための対応です。マルウェアの完全削除、脆弱性のあるソフトウェアへのパッチ適用、不審なアクセスに使われたアカウントの完全削除などを実施します。

ランサムウェア感染時の復旧手順

ランサムウェア感染の場合は特に慎重な対応が求められます。まず感染端末・サーバーをネットワークから隔離し、被害範囲を特定します。身代金の支払いについては、支払っても復号キーが提供されるとは限らず、支払い自体が新たな攻撃の契機ともなりうるため推奨されません。

クリーンな環境へのバックアップからの復元が基本的な復旧手段です。ただしバックアップ自体がランサムウェアに感染している可能性があるため、感染前の時点のバックアップであることを確認してから実施してください。

段階的サービス再開

全システムを一度に復旧させるのではなく、業務影響・セキュリティリスクを評価しながら段階的に再開します。コアとなる業務システムから優先的に復旧させ、各段階で異常がないことを確認してから次のシステムの復旧に進む方法が安全です。

Step5：根本原因分析と再発防止策の策定

インシデントの直接対応が完了した後、最も重要な作業が「なぜ起きたか」の分析と再発防止策の策定です。ここを疎かにすると、同じインシデントが繰り返されます。

根本原因分析（RCA）の進め方

根本原因分析では、「なぜ」を繰り返す「5 Whys」などの手法を用いて、表面的な原因ではなく根本的な要因を探ります。「フィッシングメールからアカウント情報が漏洩した」という事象に対して、単に「フィッシング対策ツールを導入する」という対策に留まるのは不十分です。なぜ従業員がフィッシングメールに引っかかったか、なぜ多要素認証が設定されていなかったか、なぜ異常ログインのアラートが機能しなかったか。この順番で掘り下げ、それぞれの根本原因に対処することが求められます。

技術的対策の見直し

根本原因が技術的な脆弱性にある場合、以下の観点で対策を検討します。

• パッチ管理の強化：OSやソフトウェアの更新プログラムを適用する仕組みを整備する
• アクセス権限の見直し：最小権限の原則に基づき、不要な権限を削除する
• 多要素認証の導入：重要なシステムへのアクセスには多要素認証を設定する
• 監視・検知の強化：SIEM・EDR・ログ管理ツールを活用した継続的な監視体制を整備する

プロセス・ポリシーの見直し

技術的な対策だけでは不十分で、業務プロセスやセキュリティポリシーの見直しも並行して実施します。インシデント対応マニュアルの更新、報告フローの整備、ツール利用ルールの明確化などが主な内容です。

従業員教育と訓練

人的要因が根本原因に含まれる場合は、従業員への教育・訓練が欠かせません。フィッシングメール訓練や、インシデント発生を想定した机上演習（テーブルトップ演習）を定期的に実施することで、実際のインシデント発生時の対応力が向上します。

再発防止策の有効性検証

策定した再発防止策は、実施後に有効性を検証する仕組みも設けてください。定期的なセキュリティ診断・脆弱性スキャン、ログ分析による異常検知、ペネトレーションテストなどを通じて、対策が機能しているかを継続的に確認します。

参考：JPCERT/CC インシデントハンドリングマニュアル

セキュリティインシデントとは？企業が直面する主な種類

セキュリティインシデントとは、企業の情報資産や業務の安全性を脅かす出来事の総称です。サイバー攻撃だけでなく人的ミスも含みます。

企業が直面する主要5種類のインシデント

次の5種類について、影響範囲と対応の優先度をあらかじめ整理しておきます。

• 情報漏洩：顧客情報や社内機密データが外部に流出する事象。2024年の国内事例では約2,164万件の個人情報が漏洩したとされています。クラウドサービスの設定ミスや不正アクセスによる抜き取りが主な原因です。
• 不正アクセス：権限のない第三者が社内システムやSaaSサービスに侵入する事象。VPN機器の脆弱性や、フィッシングで入手したアカウント情報を悪用した攻撃が急増しています。
• ランサムウェア感染：システムやファイルを暗号化し、身代金を要求するマルウェアへの感染。2024年にKADOKAWAグループが被害を受け、大規模な業務障害が発生した事例は記憶に新しいところです。
• クラウド・SaaSの設定ミス：アクセス権限の誤設定やパブリックアクセスの意図しない開放により、情報が外部から参照可能な状態になる事象。2024年には阪神タイガース関連会社でクラウド設定ミスにより8,452件の個人情報が漏洩しました。
• 内部不正：従業員や元従業員による意図的なデータ持ち出しや改ざん。退職時のアカウント削除漏れが悪用されるケースも多く見られます。

参考：サイバーセキュリティクラウド「企業のセキュリティインシデントに関する調査レポート2024」

インシデント対応を誤ると何が起きるか

インシデント後の誤操作や報告の遅れは、被害拡大に加え、法的リスクや企業への信頼低下につながります。

初動遅延・誤操作が招く被害拡大

感染端末を切り離さないままにすると、同じネットワークのサーバーや端末へ被害が広がります。ログの上書き・削除や独断での再起動も、原因究明に必要な証跡を失う原因になります。

法的リスクと報告義務違反

改正個人情報保護法では、個人情報の漏洩が発生した場合、個人情報保護委員会への報告が義務付けられています。要配慮個人情報の漏洩や不正アクセスによる流出など、一定の条件を満たすインシデントでは、発覚後速やかな速報（個人情報保護委員会の目安は発覚日から3〜5日以内）と、原則30日以内（不正の目的によるおそれがある場合は60日以内）の確報が求められます。この報告を怠ると、行政指導や企業名の公表といった法的リスクが生じます。

信頼失墜とブランド毀損

対応や通知の遅れは、顧客の信頼を損ないます。BtoB企業では、取引先からセキュリティ体制の見直しや取引停止を求められることもあります。

SaaS多数利用環境でのインシデント対応の課題とJosys活用

SaaS環境では、サービスごとに管理画面とログが分かれます。情シス2〜3名の体制では、平時から確認対象と担当を整理しておく必要があります。

SaaS利用増加でインシデント対応が複雑化する理由

複数のSaaSを利用していると、侵害されたサービス・アカウント・発生時期の確認が必要になります。管理画面を個別に調べる負担を減らすため、利用サービスの全体像を把握しておきます。

散在するSaaSログを一元管理できない問題

SaaSのアクセスログが散在する状態では、具体的に以下のような問題が生じます。

• 初動の遅延：影響を受けたSaaSを特定するのに時間がかかり、その間に被害が拡大する
• 見落としリスク：一部のSaaSのログ確認を忘れ、侵害範囲の把握が不完全になる
• 証跡の欠落：ログ保存期間が短いSaaSでは、遡って確認できない場合がある
• シャドーITの盲点：情シスが把握していないSaaSでのインシデントは検知すら困難

JosysによるSaaSとアカウントの一元管理

Josysは、企業内の認証情報を統合管理するAI駆動のアイデンティティセキュリティ基盤です。SaaSやデバイスの管理に加え、シャドーITの検出、退職者IDの放置や余剰ライセンスの是正を支援します。平時に利用サービスとアカウントを把握しておくことが、インシデント時に調査対象を絞るための土台になります。

SaaS Discoveryはログイン・ブラウザ活動からSaaS利用を検出し、Access Reviewsはアクセス権のレビューを支援します。利用状況の把握と、調査に必要な各SaaSのログ取得・保全は分けて設計してください。取得できるログの種類や保存期間は、利用サービスごとに確認します。

インシデント発生時の初動対応を効率化する方法

インシデント対応に備えるには、管理対象の把握と是正の運用を整えます。Josysで可視化したSaaSとアカウントの情報を、社内の対応手順に結び付けておくと、確認先を探す負担を抑えられます。確認したいのは次の項目です。

• 利用しているSaaSと管理担当者を把握する
• シャドーITの検出結果を確認し、調査対象から漏らさない
• 退職者IDや不要なアクセス権の是正手順を定める
• 各SaaSのログ取得先と、証跡を保全する担当を決める

アカウントの停止や削除は、証跡保全や業務への影響と合わせて判断します。製品による管理と、対応責任者による判断を手順書で結び付けてください。

自社のSaaSとアカウントをどう把握するか、平時の運用を検討する方へ。Josysの管理画面をデモで確認する

関連記事：SaaSセキュリティ 対策

インシデント対応マニュアル・チェックリストの整備方法

平時に対応手順をマニュアル化し、実施状況をチェックリストで確認できるようにします。担当が替わっても判断と作業を引き継げる形に整えます。

マニュアルに盛り込むべき項目

情シス担当者が中心となって作成するインシデント対応マニュアルには、以下の項目を含めることを推奨します。

• インシデントの分類と対応レベル定義：重大度（Critical/High/Medium/Low）の判断基準
• 対応体制と役割分担：誰が何を担当するか（情シス・経営層・法務・広報・外部委託）
• 連絡先一覧：社内関係者・外部セキュリティベンダー・IPA・JPCERT/CC・警察の連絡先
• 初動対応手順：本記事Step1のチェックリストに基づいた具体的手順
• 証跡収集手順：各システム・SaaSのログ取得方法
• 報告・通知フロー：社内報告経路と外部機関への報告判断基準
• 復旧手順：バックアップからの復旧方法、段階的再開の判断基準

情シス2〜3名でのインシデント対応チームの組み方

専任のCSIRTを持てない中小・中堅企業でも、役割を明確にすることで実効性のある対応チームを組めます。対応責任者（1名）はインシデント対応全体の意思決定と経営層への報告を担い、情シスリーダーが担うことが多いです。技術対応担当（1〜2名）は実際のシステム調査・ログ収集・封じ込め対応を実施します。自社だけで対応が困難な場合は、セキュリティベンダーのインシデントレスポンスサービスやJPCERT/CCのサポートを積極的に活用してください。

定期演習（机上演習）の実施

マニュアルを作成するだけでは、実際のインシデント対応時に機能しないことがあります。半年に一度程度、「ランサムウェアに感染した」「顧客情報が漏洩した」などのシナリオを設定し、役割ごとの対応を確認する机上演習（テーブルトップ演習）を実施してください。演習を通じてマニュアルの抜け漏れを発見し、継続的に改善することが重要です。

関連記事：情報セキュリティ 対策 企業

まとめ

初動から再発防止まで、次の5つの作業と担当を手順書に整理し、平時の演習で抜け漏れを確かめてください。

1. Step1（検知・初動対応）：最初の30分での状況把握・記録開始・第一報が被害規模を決める

2. Step2（証跡収集・保全）：SaaS含む全ログを適切に収集・保全し、原因究明の基盤を作る

3. Step3（外部報告）：報告義務の要否を正確に判断し、発覚後速やかな速報（目安3〜5日以内）に備える

4. Step4（封じ込め・復旧）：再感染リスクを排除しながら段階的にシステムを再開する 5. Step5（再発防止）：根本原因まで掘り下げ、技術・プロセス・人材の3側面から対策を講じる

情シス2〜3名の体制でも、SaaS・アカウントの把握とログ取得・保全の担当を決めておけば、確認先を探す負担を抑えられます。Josysの管理情報は調査対象の把握に活用し、証跡は各SaaSの取得方法と保存期間を確認して保全してください。

関連記事：SaaSセキュリティ 対策

関連記事：情報漏洩 原因 対策 企業

関連記事：内部不正 対策 IT管理