ネットワーク障害復旧の進め方|切り分け手順と再発防止の備え
ネットワーク障害が発生して社内LANやインターネット接続が止まると、現場は個別端末の対応に散りやすく、復旧判断や社内外への説明が後手になりがちです。放置すると、責任分界点(自社が触れる範囲/回線事業者やクラウド事業者の範囲)の見誤りや、トリアージ担当が役割外の調査に踏み込むことで、復旧までの停止時間が長期化します。特に、影響範囲の整理で「単一端末のみ/部門・フロア・一部拠点/全社・全拠点」のどれに当たるかを早期に固めることが、初動の分岐とエスカレーション判断に直結します。以下では、復旧判断の材料として切り分けの順序と運用の要点を示します。
ネットワーク障害復旧の前提
障害の定義と業務影響を整理する
ネットワーク障害とは、社内LAN・拠点間ネットワーク・インターネット接続などの通信経路に不具合が生じ、業務システムや外部サービスが通常どおり稼働しない/利用できない状態を指します。復旧の初動で重要なのは「何が起きているか」より先に、どの業務が止まり、どの程度の影響かを言語化して共有できることです。影響整理が曖昧だと、現場は個別の端末対応に散り、判断者は優先順位を付けられず、復旧が遅れます。
また、BCP(事業継続計画)では、有事に継続すべき重要業務を選び、優先順位を明確にすることが求められます。その判断は売上・利益だけでなく、関係者の生命の安全、企業の社会的責任といった観点も含めて総合的に行い、企業として重視すべき価値観・行動基準を共有することが重要とされています。
- 影響を受けた業務とシステム(メール、チャット、ファイルサーバ、SaaS、決済、製造・販売管理など)
- 影響範囲(単一端末/部門・フロア/拠点/全社/顧客向けサービス)
- 業務継続の優先順位(重要業務の選択と優先順位の明確化)
- 重要業務の実施場所と指示系統(対策本部の指示の下で「事業継続業務指示計画書」に記載の重要業務を実施する運用)
社内要因と外的要因に分けて原因を見る
原因を早く突き止めるには、発生源を社内要因と外的要因に切り分け、責任分界点(自社が触れる範囲/回線事業者やクラウド事業者の範囲)を意識して調査します。分界点を誤ると、外部障害なのに社内設定を弄り続けたり、逆に社内障害なのに事業者の復旧待ちになったりして、停止が長期化します。
さらに、単なる「故障」ではなく、インターネットによる業務妨害(攻撃・侵害)という観点も初期から持つ必要があります。攻撃者は、C2サーバへの通信確立や、別セグメント侵入を目的に、ルーター/ファイアウォール/VPN機器等の設定を変更している可能性があるためです。
- 社内要因:ルーター・スイッチ・AP・ONU等の故障、電源断、配線ミス、変更管理を経ない設定変更、アカウント・認証設定の不整合
- 外的要因:回線事業者・プロバイダー設備障害、災害による断線、クラウド側障害、DDoS等の大量通信
- セキュリティ要因:VPN機器等の不審な設定変更(C2通信確立、異なるセグメント侵入、多要素認証回避等の狙い)
業務停止を避けるために止められない通信と後回しにできる通信を先に分ける
障害時は人員・回線帯域・機器の余力が限られるため、止められない通信(重要業務)と後回しにできる通信を平時に切り分け、復旧の優先順位を迷わない状態にします。重要業務の選択は、事業戦略や売上影響だけでなく、関係者の安全や社会的責任も含めて検討し、価値観・行動基準の優先順位を明確にして共有することが、事業継続マネジメント上の留意点とされています。
| 区分 | 例 | 障害時の扱い |
|---|---|---|
| 重要業務に直結 | 受発注、決済、販売管理、製造ライン制御、顧客影響の大きいWeb | 最優先で帯域・復旧作業を割り当て |
| 業務連絡の生命線 | 代替を含む連絡手段(代替電子メール等) | 使える経路を複線化し、復旧優先度を高く |
| 後回し可能 | OS一斉アップデート、大容量バックアップ、重要度の低い会議配信 | 一時停止・帯域制限の対象 |
障害発生時の切り分け手順
発生範囲別に初動フローを分ける
切り分けは、影響範囲で分岐させるほど速くなります。特に、受付・トリアージ(一次受付と優先順位付け)と、詳細調査は役割を分けるのが実務上のポイントです。影響範囲の詳細調査が必要な報告については、「上位の規程で判断する」または「優先順位判断のため詳細調査が必要」という情報を付加し、トリアージ担当が役割外の詳細調査に手を出さないことが重要とされています。
- 単一端末のみ:端末側(物理接続・無線設定・IP設定・VPN等)から順に確認します。
- 部門・フロア・一部拠点:共通機器(スイッチ、AP、配線、当該セグメントのDHCP/DNS等)を優先して確認します。
- 全社・全拠点:上位装置(コアスイッチ、ファイアウォール、ルーター、ONU)と回線事業者障害を同時に視野に入れます。
- 侵害が疑われる兆候あり:不正通信・設定改変・ログオン成功ログ等を起点に隔離・保全を優先し、復旧を慎重に判断します。
単一端末の接続障害を順に確認する
単一端末のみの障害は、物理層→端末設定→認証/VPN→アプリ層の順に確認し、無駄な操作で範囲を広げないことが重要です。ここで「単なる通信不良」に見えても、端末が侵害されていると復旧操作が逆効果になり得るため、ログ上「通信失敗」ではなく通信成功が記録されている不審挙動がある場合は、優先的に被害状況確認(侵入の可能性確認)を行うべきとされています。
- 有線:LANケーブルの緩み・断線・差し込み(ロック)を確認します。
- 無線:SSID選択、機内モード、電波状態、認証(証明書・ID)を確認します。
- 端末再起動:一時的不整合の解消として実施します。
- IP/DNS:IP重複、DHCP取得、DNS設定の不整合を確認します。
- VPN/セキュリティ:VPN干渉、端末側フィルタ、プロキシ設定を確認します。
- 侵害兆候がある場合:当該端末を隔離・保全し、被害状況確認を優先します。
一部拠点や部門の通信障害を切り分ける
局所的に複数端末が同時に落ちている場合、個別端末よりも共通の中継点に原因がある可能性が高いです。加えて、社内の特定部門が独自に保有・管理しているネットワーク機器(例:独自VPN機器等)が存在すると、それが攻撃者の侵入経路として悪用される可能性があるため、被害機器の接続元が管理外機器でないか確認する必要があるとされています。
- 物理確認:当該エリアのハブ/APの電源、リンクランプ、配線抜けを確認します。
- 共通機器の再起動は慎重に:利用者影響を伝達した上で、順序立てて実施します。
- 直近変更の確認:席替え、工事、配線差し替え、設定変更の有無を確認します。
- ループ等の典型事故:誤配線によるループ接続や誤接続を疑い、切り戻しを試みます。
- 管理外機器の確認:接続元が独自管理VPN等でないか、経路を確認します。
全社ネットワーク障害の復旧対応
全社障害で確認する機器と回線の順序
全社不通では、単一障害点(コア機器・境界機器・回線)の可能性が高いため、下流の共通設備から上流(境界)へ、系統立てて確認します。加えて、攻撃・侵害が疑われる場合、復旧を急いで機器の設定を変えると、攻撃者の潜伏や再侵入を見落とすおそれがあるため、ログと設定の整合確認を並行させる必要があります。
- 電源・ランプ:コアスイッチ、ルーター、ファイアウォール、ONUの電源とアラート表示を確認します。
- 物理配線・環境:機器間の幹線ケーブル抜け、空調不良や過熱、停電の影響を確認します。
- 社内疎通:社内セグメント内の疎通(ゲートウェイ到達)を確認します。
- 外部疎通:上流への疎通が落ちているかを確認し、回線側切り分けへ進みます。
- 名前解決:IP直叩きは通るがドメインが不可ならDNSを疑い、設定・到達性を確認します。
- 設定改変の疑い:ルーター/ファイアウォール/VPN機器の設定が変更されていないか確認します。
事業者へエスカレーションする判断基準
回線事業者側の障害が疑われる段階で、社内で再起動や設定変更を繰り返すのは避け、迅速にエスカレーションします。特に、侵害の可能性がある状況で闇雲に機器操作をすると、証跡(ログ等)を失ったり、状態を悪化させたりします。
- 境界装置(ONU等)がリンクダウンを示し、再起動しても回線復旧しない
- 社内ゲートウェイまでは到達するが、外部への疎通が広範にタイムアウトする
- 事業者側の障害・メンテ情報が公表されている(確認手段が限られる場合はスマートフォン回線等で確認)
- 自社側で実施できる切り分け(物理、社内疎通、DNS等)を行っても回復しない
連絡時は、契約IDや回線名称だけでなく、社内で確認した「どこまで疎通したか」「いつからか」「どの範囲か」を整理して伝えると、事業者側の調査が前に進みます。
原因別の復旧と一時対応
故障やケーブル不良と設定ミスに対処する
物理故障・ケーブル不良・設定ミスは、暫定復旧(止血)と恒久対策を分けます。ただし、攻撃者が機器設定を変更している可能性がある場面では、安易な再起動・初期化が調査の妨げになり得るため、設定確認→安全な切り戻しの順で行います。
また、ネットワーク機器(ルーター、ファイアウォール、VPN機器等)は、攻撃者がC2通信確立や別セグメント侵入、多要素認証回避等を目的に設定を変更する可能性があるため、設定が変更されていないか確認し、不審な変更があればバックアップから元に戻し、戻せない・バックアップの安全性が担保できない場合は初期化を検討するとされています。VPN機器で不審な設定変更や不審アカウント追加がある場合は、ファームウェアの脆弱性悪用も疑い、バージョン確認と必要に応じたアップデート、すぐにアップデートできない場合は一時的な機能停止も検討します。
- ケーブル・ポート不良:予備ケーブル交換、空きポートへの付け替え、予備ハブへの一時バイパス
- 変更直後の不具合:原因追究の前に、変更前コンフィグへロールバックして通信を切り戻し
- 設定改変の疑い:ルーター/ファイアウォール/VPN機器の設定変更有無を確認し、不審変更はバックアップから復元(安全性が担保できない場合は初期化も検討)
- VPN機器の疑義:不審アカウント追加や設定変更があればファームウェア版数確認、アップデート困難なら一時停止も検討
帯域逼迫やアクセス集中を一時回避する
帯域逼迫やアクセス集中は、重要業務の通信まで巻き込んで遅延・遮断が起きるため、原因トラフィックを素早く抑える必要があります。平常時からログ取得と閾値(しきいち)設定を行い、異常値を検出したら自動通知する仕組みを持つことが有効とされています。ファイアウォールの通信ログで送受信容量を確認でき、深夜の大量送受信があればデータ窃取(外部への持ち出し)を疑い、ネットワーク遮断等のアクションを検討する、という運用の考え方も示されています。
- 重要業務の保護:重要業務通信を優先し、後回し通信(大容量送受信や一斉アップデート等)を停止・制限します。
- 入口の抑制:公開系でアクセス集中がある場合、前段で制限・分散し、重要度の低いリクエストを制御します。
- ログで根拠を取る:ファイアウォール通信ログ等で容量・宛先・時間帯を確認し、異常な送受信を特定します。
- 閾値と通知:CPU・メモリ・トラフィック等の異常値を検知する閾値を設定し、アラート自動通知を運用に組み込みます。
インターネットやクラウド障害時の選択肢
インターネット回線やクラウド側の障害は、自社で直接復旧できない領域がある一方、業務停止を小さくする「切替・縮退運用」は自社の責任範囲として準備できます。特にCSIRT等のインシデント対応体制では、通常利用している電子メールが使えない場合に備え、代替の電子メールやコミュニケーション手段を用意することが示されています。
- 代替回線:スマートフォンのテザリング、クラウドSIM対応モバイルルーター等で最低限の通信を確保
- 代替コミュニケーション:通常メールが不可の場合に備え、代替電子メールや別チャネルの連絡手段を準備
- オフライン運用:ローカルキャッシュ・一時保存データで作業を継続し、復旧後に再同期
- 迂回導線:顧客向けWeb等は縮退ページや臨時サイトへの切替要否を検討し、案内導線を確保
復旧を早める監視と運用
監視とログ管理で障害発生を早く捉える
復旧時間を短縮するには、ユーザー申告待ちではなく、監視とログで早期検知します。ログは取得されていても、確認手段がない・解析されないまま放置されがちだという指摘があり、監視設計では「取得」と「見られる状態(収集・相関)」までをセットで整えます。
また、ファイアウォールの通信ログから送受信容量を把握でき、深夜に大量送受信があればデータ窃取を疑って遮断等を検討する、といった運用が可能です。サーバログとネットワーク機器ログの相関分析は、攻撃者の実態把握に役立つとされています。NDR(Network Detection and Response)は、ネットワークのトラフィック状況等を可視化・監視する考え方として位置づけられています。
- 死活・遅延:疎通監視により応答時間やパケットロスの推移を追跡
- リソース異常:CPU・メモリ・トラフィック等の異常値に対して閾値を設定し、アラート自動通知
- 通信の中身の手掛かり:ファイアウォール通信ログで送受信容量・宛先・時間帯を確認
- 相関分析:サーバログとネットワーク機器ログを突合して状況把握
構成の可視化と変更管理で原因特定を早める
原因特定を速くするには、最新の構成情報と変更履歴を即時に参照できる状態が必要です。特に、社内の特定部門が独自に保有・管理しているネットワーク機器があると、平時の構成図に載っていない経路が侵入経路として悪用される可能性があるため、「管理外機器の存在」を構成管理の対象に含めます。
- ネットワーク構成図:ルーター、スイッチ、AP、配線経路、セグメント、IP割当、拠点間経路
- 例外の棚卸し:部門独自管理のVPN等、管理外になり得る機器・回線の一覧化
- 変更管理:影響評価、作業手順、ロールバック計画の事前審査・承認と、実施履歴の記録
冗長化と多重回線で復旧時間を縮める
単一障害点を減らす設計は、復旧時間の短縮に直結します。BCP関連の評価観点として、代替通信インフラの確保やネットワークの冗長化(固定電話・携帯電話等の機能低下や寸断に備え、衛星電話、無線電話、PHS等の確保を含む)が挙げられています。災害時には調達困難も起き得るため、重要業務で使用する情報システムの予備機器確保も論点になります。
- 機器冗長:ルーター・ファイアウォール等を二重化し、障害時に切替できる構成を検討
- 回線多重:異なる回線事業者等で複数経路を持ち、一系統障害時に代替へ切替
- 代替通信手段:衛星電話、無線電話、PHS等を含め、固定・携帯の寸断に備える
- 予備機器:被災時に調達困難となる事態に備え、重要機器の予備を確保
障害後の再発防止と説明
災害時のBCPと代替通信手段を決めておく
災害時は、自社設備が無事でも回線側の断線・停電等で固定回線が使えないことがあるため、BCPとして「重要業務を何で継続するか」を決めておきます。事業継続マネジメントでは、統制環境(重視すべき価値観、行動基準、その優先順位)が重要で、継続すべき重要業務の選択と優先順位の明確化が必要とされています。
また、運用上は「対策本部から指示される業務実施場所において、『事業継続業務指示計画書』に記載されている重要業務を実施する」旨を規定する考え方が示されています。加えて、代替通信インフラの確保として、固定・携帯の機能低下や寸断に備え、衛星電話・無線電話・PHS等を含む代替手段の確保や、ネットワーク冗長化が論点になります。
- 重要業務の選択と優先順位(売上影響だけでなく社会的責任等も含めて判断)
- 対策本部の指示と業務実施場所(事業継続業務指示計画書に基づく運用)
- 代替通信手段(衛星電話、無線電話、PHS等を含む)
- 代替連絡手段(通常メール停止に備えた代替電子メール等)
復旧後の原因分析と再発防止策を残す
復旧後は、原因分析と再発防止を「記録として残す」ことが重要です。特にサイバー被害が絡む場合、攻撃者の二次被害を防ぐため、システム・業務復旧は慎重に行う必要があり、旧環境を使い続けず、OS初期化・最新アップデート済みでウイルス対策ソフトやEDRが導入された端末のみを利用する、といった考え方が示されています。ネットワーク面でも、被害に遭ったVPN機器等の利用禁止や刷新、冗長化、NDRによるモニタリング検討が論点になります。
また、応急対応として「攻撃者がこれ以上侵入できない状況を作る」ため、インターネット接続をルータやファイアウォールから根本で切り離してネットワークを完全遮断することが重要で、サーバのケーブルだけ抜いて侵入経路を残すのは不適切、という指摘があります。
- タイムライン化:検知→一次対応→エスカレーション→暫定復旧の時系列整理
- 設定・アカウント:不審な設定変更や不審アカウント追加の有無、バックアップ復元可否、初期化要否
- 端末・サーバ復旧方針:OS初期化・最新化、ウイルス対策ソフトやEDR導入済みのみ利用
- ネットワーク刷新:被害VPN機器の利用禁止・刷新、冗長化、NDR検討
- 封じ込め手順:根本遮断(ルータ/ファイアウォール起点)を含む遮断判断の条件整理
社内外への報告文に入れる事実を整理する
報告文は、憶測を排し、確定した事実と未確定事項を分けます。特にインシデント対応では、影響範囲の詳細調査がなければ優先順位が判断できない報告もあるため、その場合は「上位の規程で判断する」または「優先順位判断のため詳細調査が必要」といった情報を付加して回答する、という運用上の考え方が示されています。
- 障害の発生日時・検知日時・復旧日時(いつからいつまで影響があったか)
- 影響範囲(拠点、部門、対象システム、顧客影響の有無)
- 一次原因(故障、設定ミス、回線事業者要因、攻撃・侵害の疑い等)
- 根本原因(運用・統制・変更管理・監視設計など背景要因)
- 実施した暫定対応(遮断、切替、帯域制限、ロールバック等)
- 恒久対策と再発防止策(実施時期、担当、完了条件)
よくある質問
ネットワーク障害発生時に最初に何を確認しますか?
最初に確認すべきは、機器操作ではなく、影響範囲の確認と物理層の目視チェックです。加えて、受付・トリアージ段階では、影響範囲の詳細調査が必要な場合に「上位の規程で判断する」または「優先順位判断のため詳細調査が必要」といった情報を付加し、トリアージ担当が役割外の詳細調査に踏み込まない運用が重要とされています。
- 影響範囲:単一端末/部門/拠点/全社/顧客向けのどこまで影響かを確認します。
- 物理:LANケーブル、電源、リンクランプ、ONU等の状態を目視で確認します。
- 直近変更:席替え、工事、設定変更、機器交換の有無を確認します。
- セキュリティ兆候:不審な設定変更や不審通信の兆候があれば、隔離・保全を優先します。
事業者側の障害か社内LANの問題かは見分けられますか?
「どこまで到達しているか」を経路に沿って確認すれば見分けられます。社内側(端末→社内LAN→デフォルトゲートウェイ)まで正常で、外部側が一斉にタイムアウトするなら、回線事業者側の障害を強く疑います。
また、侵害が疑われる局面では、単なる疎通の有無だけでなく、ルーター/ファイアウォール/VPN機器の設定が変更されていないかの確認も重要です。攻撃者がC2サーバへの通信確立や異なるセグメント侵入等を目的に設定を変更する可能性があるためです。
- 端末内:端末自身の通信機能が動いている前提を確認します。
- 社内LAN:同一LAN内の他端末・プリンタ等への到達性を確認します。
- ゲートウェイ:デフォルトゲートウェイ(社内ルーター)まで到達するか確認します。
- 外部:ゲートウェイの先が広範に落ちる場合は回線側を疑い、事業者へ連絡します。
- 設定:境界機器(ルーター/FW/VPN)の不審な設定変更がないか確認します。
クラウドサービス障害では自社でどこまで復旧できますか?
クラウド事業者側の障害は、自社に管理権限がないため根本復旧はできません。一方で、業務影響を抑えるための暫定対応(代替回線、オフライン運用、代替連絡手段)は自社で準備・実行できます。CSIRT等の体制では、通常利用している電子メールが使えない場合に備え、代替の電子メールやコミュニケーション手段を用意することが示されています。
- 代替インターネット:テザリングやモバイル回線で最低限の通信を確保
- 代替連絡:代替電子メール等、別チャネルへの切替案内
- 縮退運用:オフラインで処理し、復旧後に再同期
中小企業でも監視を自動化できますか?
可能です。重要なのは、ツールの豪華さよりも「異常に気付ける仕組み」を作ることです。実務上は、CPU・メモリ・ネットワークトラフィック等の異常値を検出するために閾値を設定し、異常アラート発生時に自動通知する仕組みを導入することが有効とされています。さらに、ファイアウォールの通信ログで送受信容量を確認し、深夜の大量送受信があればデータ窃取を疑って遮断等を検討する、といった運用も可能です。
- 閾値監視:CPU・メモリ・トラフィック等のしきい値と通知先を決めます。
- ログ確認手段:取得したログを確認できる導線(収集・保管・参照)を作ります。
- ネットワーク観測:必要に応じてNDR等の考え方でトラフィックの可視化を検討します。
まとめ:ネットワーク障害への対応で次にすべきこと
ネットワーク障害では、まず「どの範囲が落ちているか」を起点に、単一端末のみ/部門・フロア・一部拠点/全社・全拠点で初動フローを分けることが、切り分けと復旧判断を速めます。次に、社内要因と外的要因(回線事業者・クラウド側)を責任分界点で整理し、社内での再起動や設定変更を繰り返す前に、エスカレーションへ切り替える基準を持つことが重要です。侵害が疑われる場合は、C2サーバへの通信確立などを目的とした設定改変の可能性も踏まえ、隔離・保全とログ・設定の整合確認を並行させ、復旧操作が証跡喪失につながらないよう注意します。復旧後は、タイムライン化と再発防止(監視・ログ、構成の可視化、変更管理、冗長化)を記録として残し、社内外への報告では確定事実と未確定事項を分けて整理します。個別事情により判断が変わるため、攻撃・侵害や顧客影響が疑われる場合は、情報システム部門だけで抱えず、社内の規程に沿って法務・リスク管理や専門家に相談してください。

