2024年、国内企業のセキュリティインシデントは619件に達し、約3日に1回のペースで発生しました（サイバーセキュリティクラウド調べ）。しかし「実際にインシデントが起きたとき、何を、どの順番で、誰が対応するのか」を体制として整えている企業は、まだ少数にとどまっています。

情シス担当者が2〜3名という体制の中小・中堅企業では、インシデント発生時に焦るあまり初動を誤り、被害をさらに拡大させてしまうケースが後を絶ちません。ログを誤って削除する、独断でシステムを再起動して証跡を失う。こうした判断ミスは、後の原因究明や再発防止を著しく困難にします。

本記事では、セキュリティインシデントが発生した際に情シス担当者が取るべき対応手順を、検知から再発防止まで5つのステップで体系的に解説します。すぐに使えるチェックリストも掲載しているため、自社の対応マニュアル整備にお役立てください。

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

セキュリティインシデントとは、企業の情報資産や業務の安全性を脅かす出来事の総称です。JIS Q 27000では「事業運営を危うくする確率及び情報セキュリティを脅かす確率が高い、望ましくない情報セキュリティ事象」と定義しています。サイバー攻撃から人的ミスまで、その範囲は広く、企業規模を問わず発生しうるものです。

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

情シス担当者が対応を求められるインシデントは、大きく5種類に分類されます。それぞれ対応の優先度や影響範囲が異なるため、あらかじめ種類別の対応フローを想定しておくことが重要です。

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

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

インシデントが発生すること自体は大きな問題ですが、対応を誤ることでさらに深刻な事態を招きます。発生後の行動が被害の規模を決定づけるという意味で、対応の質はインシデントそのものと同じくらい重要です。

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

ランサムウェア感染の場合、感染端末をネットワークから即座に切り離さなければ、同一ネットワーク上のサーバーや他の端末へと被害が伝播します。ログを確認しようとして誤って上書きや削除を行うと、原因究明に必要な証跡が失われ、その後の対応がすべて推測に頼らざるを得なくなります。

「とりあえずシステムを再起動して様子を見よう」という直感的な判断は、最も危険な初動のひとつです。再起動によってメモリ上のフォレンジックデータが失われ、攻撃者の侵入経路を特定できなくなることがあります。

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

改正個人情報保護法では、個人情報の漏洩が発生した場合、個人情報保護委員会への報告が義務付けられています。要配慮個人情報の漏洩や不正アクセスによる流出など、一定の条件を満たすインシデントでは72時間以内の速報が求められます。この報告を怠ると、行政指導や企業名の公表といった法的リスクが生じます。

信頼失墜とブランド毀損

対応の遅れや顧客への通知が不適切だった場合、企業への信頼は長期にわたって損なわれます。BtoB企業では、取引先からセキュリティ体制の見直しや取引停止を求められるケースもあります。インシデントの発生そのものより、その後の対応の品質が企業評価を左右することも少なくありません。

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

インシデント対応を体系化する際は、NIST SP800-61の4段階フレームワークが広く参照されています。本記事では、情シス2〜3名体制の企業が実践しやすいよう、これを5ステップに整理しています。各ステップの目安時間も踏まえて、対応計画に活用してください。

各ステップの概要と目安時間は以下のとおりです。

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

インシデント対応の成否は最初の30分に大きく左右されます。この段階での判断の質が、最終的な被害規模を決定づけます。

インシデントの検知方法

インシデントを最初に発見するのは、必ずしも情シス担当者とは限りません。現場の従業員からの報告、セキュリティツールのアラート、取引先からの連絡など、検知の経路は多様です。いずれの経路であっても、まず「何が起きているか」を冷静に把握することから始めてください。

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

初動として確認すべき7項目を挙げます。焦って作業を進める前に、このリストを順番に確認してから動くことが、結果的に対応速度を上げます。

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

やってはいけない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は独自の管理コンソールを持ち、ログのフォーマットも保存期間もバラバラです。インシデント発生時に「あのSaaSのログはどこから取得するのか」「保存期間が過ぎていてログが存在しない」という事態は、珍しくありません。

また、情シスがSaaSの全体像を把握できていないケース（シャドーIT）では、そもそもどこにログがあるかすら分からない状態になります。この課題への対応については、後述のJosys活用の章で詳しく解説します。

証跡保全の注意事項

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

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

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

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

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

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

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

速報（事実を知った後、概ね72時間以内）と確報（概ね30日以内）の2段階での報告が必要です。速報では詳細が判明していなくても、判明した範囲での情報を報告することが認められています。

IPAへの届け出

IPA（情報処理推進機構）への届け出は任意ですが、ウイルス感染・不正アクセス・サイバー攻撃の被害を受けた場合は届け出が推奨されます。IPAは報告情報を集約し、同種の被害が他社に広がることを防ぐための注意喚起に活用しています。届け出を通じてIPAから対応アドバイスを得られるケースもあります。

警察への被害届

不正アクセスやランサムウェア感染など、犯罪行為が疑われる場合は都道府県警察のサイバー犯罪相談窓口への相談・届け出を検討します。捜査には証拠保全が前提となるため、警察への連絡前にStep2の証跡保全を完了させておくことが重要です。

取引先・顧客への通知

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

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

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

外部への報告と並行して、被害の封じ込めと段階的なシステム復旧を進めます。このフェーズで最も避けるべきは、「完全な復旧」を急ぎすぎることです。再感染や二次被害を防ぎながら慎重に進めることが、長期的な安定稼働につながります。

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

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

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

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

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

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

段階的サービス再開

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

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

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

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

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

技術的対策の見直し

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

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

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

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

従業員教育と訓練

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

再発防止策の有効性検証

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

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

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

SaaSの導入が進む現代の企業では、インシデント対応においてオンプレミス環境とは異なる課題が生じています。この課題は、情シス2〜3名体制の組織にとって特に深刻です。

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

中規模企業でも数十種類のSaaSを並行して利用するケースが当たり前になっています。インシデント発生時には、どのSaaSに不正アクセスされたか・どのアカウントが侵害されたか・いつから不審な動きがあったかを迅速に把握しなければなりません。

しかし各SaaSがそれぞれ独自の管理コンソールとログ形式を持つ環境では、この把握に膨大な時間がかかります。情シス2〜3名のチームが、緊張した状況の中で複数のSaaSの管理画面を個別に確認して回ることは現実的ではありません。

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

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

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

ジョーシスのプラットフォームによる一元管理

ジョーシスのプラットフォームは、企業が利用するSaaSアプリケーションを一元的に管理し、アクセスログと監査証跡を統合的に収集・可視化する機能を提供しています。インシデント発生時に「どのユーザーが・どのSaaSに・いつアクセスしたか」を単一の画面から把握できる環境が整います。

以前は複数のSaaSの管理コンソールを個別に確認していた情シス担当者が、ジョーシスのプラットフォームを通じて全SaaSのアクセス状況を一か所で確認できるようになることで、インシデント発生時の初動対応時間を大幅に短縮できます。

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

ジョーシスのプラットフォームを活用したインシデント対応の効率化は、具体的には以下の場面で効果を発揮します。

• 不正アクセスの検知：普段とは異なる時間帯・場所からのログインなど、異常なアクセスパターンを可視化します
• 影響範囲の迅速な特定：侵害が疑われるアカウントがどのSaaSにアクセス権を持っているかを即座に確認し、一括で権限を停止できます
• 証跡の一元収集：複数のSaaSにまたがるアクセスログを統合的に収集・保存し、インシデント調査に活用できる証跡を整備します
• 退職者アカウントの管理：アカウントの削除漏れによる不正アクセスリスクを、退職処理と連動したアクセス権管理で未然に防ぎます

‍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（外部報告）：報告義務の要否を正確に判断し、72時間以内の速報に備える
4. Step4（封じ込め・復旧）：再感染リスクを排除しながら段階的にシステムを再開する
5. Step5（再発防止）：根本原因まで掘り下げ、技術・プロセス・人材の3側面から対策を講じる

情シス2〜3名という体制でも、仕組みが整っていれば対応の質は大きく変わります。その核心となるのが、SaaS全体のアクセスログと監査証跡の一元管理です。散在するSaaSのログをリアルタイムで把握できる環境が整っていれば、インシデント発生時の初動対応スピードは劇的に上がります。ジョーシスのプラットフォームは、そのための基盤として機能します。

【関連記事】

• SaaSセキュリティ 対策
• 不正アクセス 対策 情シス
• 情報漏洩 原因 対策 企業
• 内部不正 対策 IT管理

参考資料：

• IPA「中小企業のためのセキュリティインシデント対応の手引き」（2024年7月）
• 個人情報保護委員会「漏えい等の報告・本人への通知について」
• JPCERT/CC インシデントハンドリングマニュアル
• サイバーセキュリティクラウド「企業のセキュリティインシデントに関する調査レポート2024」
• NTTセキュリティ・ジャパン「インシデント対応とは？サイバー攻撃の被害を最小化する方法」