はじめに
アサヒグループは2025年9月29日にサイバー攻撃があったと発表しました。（サイバー攻撃によるシステム障害発生について）
報道されたランサムウェア起因のシステム障害は、生産設備そのものではなく、受注・出荷・顧客対応といった業務フローが止まることで供給全体が止まる現実を浮き彫りにしました。併せて、東証プライム企業でも類似の外部攻撃事例が続いています（例：KADOKAWA/DWANGO、CASIO、HOYA。詳細は各社の公式発表参照）。
本稿は、これらの教訓を結果論としてのフィードバックに落とし込み、実装チェックリストと90日ロードマップまで示します。
1. 事例で学ぶ：どこが「止まった」のか
1-1. アサヒグループのケース
- 影響が大きかったのは注文・配送・顧客対応などの業務系。ここが止まると在庫引当→出荷→請求の鎖が切れ、工場ラインが回っても出荷できない状況に陥る。
- 一部では暫定手作業（電話・メール・紙・CSV）への切替が必要になり、処理量の限界がボトルネック化。
1-2. 東証プライム企業の近年実例
- KADOKAWA/DWANGO：大規模攻撃でコンシューマサービス停止が長期化。受発注・物流・会計にも波及。
- CASIO：ランサムウェアで情報流出を公表し、要求に応じない方針で復旧・通知を進行。
- HOYA：医療・製造関連の一部システムで不正アクセスを公表し、遮断→調査→強化策を実施。
実務での論点
- 工場＝OTよりも、むしろ業務＝ITの停止が全体停止を招く
- 業務ハブ（認証・マスタ・ファイル共有・ジョブ/メッセージング）に依存する度合いが高いほど脆い
▼注釈（この章で使った略語・専門用語）
- CSV：Comma Separated Values。表形式データをカンマ区切りで保存するファイル形式。
- OT：Operational Technology。製造ライン等の制御系。
- IT：Information Technology。業務システム等の情報系。
2. なぜ止まるかを深掘り
現象：出荷・受注・顧客対応が停止し、工場も巻き添えで止まる。
-
なぜ止まった？
→ 認証・注文・配送など業務ハブが機能不全になったから。 -
なぜハブが落ちると全体が止まる？
→ 受注→在庫→出荷→請求が密結合で、疎結合な代替フローが用意されていないから。 -
なぜ代替が回らない？
→ マスタ・在庫・与信の参照ができず、意思決定の根が欠落するから。 -
なぜ“根”が欠落？
→ ID/ファイル/ジョブといった共通基盤の単一障害点（SPOF）に依存しているから。 -
なぜSPOFが生まれる？
→ 効率性のための集中管理が進み、攻撃前提の分離（ゼロトラスト）設計が後手になったから。
▼注釈（この章で使った略語・専門用語）
- マスタ：取引先や品目など基礎データの正本。
- 与信：取引先の信用枠設定。出荷判断の基本。
- SPOF：Single Point Of Failure。単一障害点。
3. 仮説→根拠→再検証→示唆
仮説A：「身代金は払わない」前提と被害最小化を初動で同時確定
- 根拠：支払いは再犯リスクと法的・倫理的論点が大きい。初動は影響範囲特定→遮断→復旧計画。
- 再検証：CASIOは要求に応じず復旧・通知を実行。
- 示唆：経営決裁テンプレ（原則不払い/例外条件・広報文・当局/保険連絡）を事前整備。
仮説B：業務ハブのSPOF解体が復旧時間短縮の最短路
- 根拠：アサヒや他事例で業務ハブ依存が全体停止の引き金に。
- 再検証：KADOKAWA/DWANGOでの業務横断影響はハブ集中の表れ。
- 示唆：認証・マスタ・ファイル・スケジューラを論理分割し、縮退運転の迂回路を設計。
仮説C：検知と隔離の“分”勝負
- 根拠：暗号化開始前の横移動検知と即時隔離が被害面積を決める。
- 再検証：国内でランサム被害は継続発生。MTTD/MTTR短縮が鍵。
- 示唆：EDR/NDR+SIEM/SOARで自動隔離し、演習で誤検知と運用疲れを抑制。
▼注釈（この章で使った略語・専門用語）
- MTTD/MTTR：検知までの時間/復旧までの時間。
- EDR/NDR：端末/ネットワークの検知・対応。
- SIEM/SOAR：ログ統合・自動対応基盤。
4. 実装チェックリスト（具体）
4-1. 経営・組織
- 方針：不払い原則を文書化（例外条件・広報/法務/保険/警察/JPCERT連絡網を即時起動）。
- KPI：MTTD/MTTR、RTO/RPO、横移動検知率、四半期演習回数。
4-2. アーキテクチャ
- 認証分離：ID基盤の冗長化/ドメイン分割、管理系LANと業務LAN/OTの段階的分離。
- 最小権限/PAM：特権は一時付与+録画、秘密情報はVaultでローテーション。
- データ面：Immutableバックアップをオフライン/オフサイトで保持、年2回復旧演習。
- 検知：EDR/NDRでC2通信・大量暗号化・AD偵察を検知、SOARで自動隔離。
- メール/境界：MFA徹底、添付分離・URL踏み台、WAF/CDN、脆弱性管理SLA。
4-3. 業務継続（BCE）
-
縮退運転：注文→出荷→請求の最小フローを紙・CSVで週○万件処理できる訓練。
-
“ハブ潰し”設計：
- 受注/在庫/配送は疎結合APIで迂回系を用意（例：一時的に配送直発注）。
- マスタ参照は参照専用レプリカを別ドメインに保持。
- 帳票は署名済みテンプレをローカル配備。
4-4. 30-60-90日ロードマップ
- Day 0-30：MFA義務化、EDR全端末展開、高リスクVPN停止、特権棚卸、バックアップ整合性テスト
- Day 31-60：ID/ネットワーク分割設計、NDR/ログ可視化、復旧演習①（RTO/RPO測定）
- Day 61-90：SOAR自動化、PAM導入、縮退運転演習②、取引先“非常時プロトコル”合意
▼注釈（この章で使った略語・専門用語）
- PAM：Privileged Access Management。特権アクセス管理。
- Vault：秘密情報を集中管理・自動更新する仕組み。製品名の一般名詞化用法。
- C2：Command & Control。攻撃者の遠隔操作通信。
- AD：Active Directory。ID/認証の基盤。
- WAF/CDN：Web防御/配信基盤。
- SLA：Service Level Agreement。合意済みの品質基準。
- BCE：Business Continuity for Enterprise。本稿での便宜用語。
- API：Application Programming Interface。アプリ間接続の窓口。
- VPN：Virtual Private Network。暗号化トンネル接続。
5. 結果論からのフィードバック
| 事後に見えた教訓 | プロダクト/手順 | トレードオフ/リスク |
|---|---|---|
| ハブを落とされると 全停止 |
認証・マスタ・ファイル 共有の論理分割、 参照レプリカ |
運用複雑化→IaC/自動化 が前提 |
| 検知は“分”の勝負 |
EDR/NDR+SIEM、 SOAR隔離 |
アラート疲れ→ユースケース 設計と調整 |
| 縮退運転の練度が 供給を救う |
紙/CSV・電話代替の 処理目標値を演習で検証 |
コスト増→四半期演習 で最適化 |
| 不払い原則の 明文化 |
方針文書・広報テンプレ・ 当局/保険連絡網 |
流出脅迫→法務/広報の 即応体制で低減 |
▼注釈（この章で使った略語・専門用語）
- IaC：Infrastructure as Code。構成をコードで管理する手法。
- SIEM：Security Information and Event Management。
- テンプレ：テンプレートの略。ここでは事前承認された文案。
おわりに
大切なことは、工場単体ではなく業務フローが止まるという事実です。業務ハブのSPOF解体、“分”単位の検知と隔離、そして縮退運転の事前設計と訓練。この三点を90日で前進させれば、被害の面積と時間を有意に縮められます。
各社の公式リリースと公的ガイド（IPA/NISC/JPCERT/CC 等）を確認しつつ、自社の前提条件に合わせて即日着手しましょう。