前言
朝日集團於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進行輪換管理。
- 數據面:不可變備份保留在離線/異地,並進行每年兩次的復原演習。
- 檢測:通過EDR/NDR檢測C2通信、大量加密、AD偵察,並透過SOAR實現自動隔離。
- 郵件/邊界:嚴格實施MFA、附件分離/URL跳板、WAF/CDN、漏洞管理SLA。
4-3. 業務持續性(BCE)
- 縮退運行:訓練能夠以紙本/CSV處理每週○萬件的最小流程(訂單→出貨→開票)。
- “樞紐摧毀”設計:
- 訂單/庫存/配送應設計為鬆散結合API的迂迴系統(例如:暫時性直接配送訂單)。
- 主數據參考應保留在不同域的專用副本中。
- 報表應使用簽名模板在本地部署。
4-4. 30-60-90天路線圖
- 第0-30天:實施MFA要求、展開EDR全端部署、暫停高風險VPN、進行特權清查、測試備份一致性。
- 第31-60天:設計ID/網絡分割、實施NDR/日誌可視化、進行復原演習①(測量RTO/RPO)。
- 第61-90天:實現SOAR自動化、推行PAM、進行縮退運行演習②、與交易夥伴達成“緊急情況協議”。
▼註解(本章所用的縮寫與專業術語)
- PAM:特權訪問管理(Privileged Access Management)。
- Vault:集中管理和自動更新秘密信息的系統,產品名稱的一般用法。
- C2:命令與控制(Command & Control),攻擊者的遠端操作通信。
- AD:活動目錄(Active Directory),ID/認證基礎設施。
- WAF/CDN:網路防護/內容配送基礎設施。
- SLA:服務水平協議(Service Level Agreement)。事先約定的品質標準。
- BCE:企業持續性(Business Continuity for Enterprise),本稿的便捷用語。
- API:應用程式介面(Application Programming Interface),應用間的連接接口。
- VPN:虛擬私人網路(Virtual Private Network)。加密隧道連接。
從結果的反思中得到的回饋
事後顯現的教訓 |
產品/流程 |
交易權衡/風險 |
樞紐一旦崩潰,<br>整體即停擺 |
認證、主數據、檔案的<br>論理分割,<br>參考副本 |
運營複雜化→IaC/自動化是前提 |
檢測是“分”的比賽 |
EDR/NDR+SIEM、<br>SOAR隔離 |
警報疲勞→案例設計與調整 |
縮退運行的熟練度<br>救助供應 |
紙/CSV、電話替代的<br>處理目標在演習中驗證 |
成本增加→季節性演習優化 |
不支付原則的<br>明文化 |
政策文檔、對外公告模板、<br>政府/保險聯絡網 |
泄漏威脅→法律/對外公告的<br>即時應對機制降低風險 |
▼註解(本章所用的縮寫與專業術語)
- IaC:基礎設施即代碼(Infrastructure as Code),通過代碼管理配置的技術。
- SIEM:安全信息與事件管理(Security Information and Event Management)。
- 模板:模板的縮寫,這裡指的是事先批准的文案。
結尾
關鍵在於,不僅僅是工廠單體的運作受到影響,而是業務流程的停擺。必須確保業務樞紐的SPOF拆解、“分”檢測與隔離、以及縮退運行的事前設計和訓練。如能在90天內推進這三個要點,便能顯著縮小損害的面積與持續時間。
原文出處:https://qiita.com/comty/items/e1f1f82b89278c1a7e8d