營運持續計畫與災難復原計畫：關鍵差異

什麼是營運持續計畫與災難復原計畫？

營運持續計畫可在中斷期間維持您組織的營運，而災難復原計畫則會在技術故障後還原您的 IT 系統。您需要兩者協同運作，而勒索軟體情境正好說明了原因。

凌晨 2:47，勒索軟體鎖定您的正式環境系統。到凌晨 3:15，您的 SOC 已控制威脅，但業務營運仍然離線。復原取決於跨越四個不同營運時程的協調：

• 事件回應 最先發生；您的 SOC 會執行技術性遏制。
• 危機管理 隨後進行，由安全領導層與高階主管及利害關係人溝通。
• 營運持續 在還原期間維持組織營運。
• 災難復原 還原 IT 系統以達成營運持續目標。

根據 NIST SP 800-34 Rev. 1，營運持續計畫提供「預先決定的指示或程序，用以說明組織的使命／業務流程如何在重大中斷期間及之後得以維持。」您的 BCP 回答一個問題：當正常營運失效時，您的組織如何持續提供服務？

災難復原計畫的範圍較為狹窄。NIST 將 DRP 定義為「為了因應重大硬體或軟體故障或設施毀損，而在替代設施中復原一個或多個資訊系統的書面計畫。」您的 DRP 特別著重於在技術故障或毀損事件後還原 IT 基礎架構、應用程式與資料。

當 ransomware當攻擊發生時，您的事件回應團隊會在數分鐘到數小時內控制威脅。您的危機管理會在數小時到數天內協調各利害關係人。您的業務持續流程會在數天到數週內維持營運，同時您的災難復原團隊會驗證已還原的系統是否符合安全基準。每項計畫都對應回應流程中的不同階段，而每項計畫都需要各自的規劃、測試與負責歸屬。網路攻擊日益頻繁，使這種協調比以往任何時候都更加關鍵。

營運持續與災難復原如何與網路安全相關

勒索軟體已改變復原規劃。原本為硬體故障而設計的備份系統，當對手鎖定您的資料保護基礎架構時，便會成為主要攻擊目標。  CISA NICE Framework 現在將資料保險庫原則（K1278）納入 cyber resilience 職務的必要能力，這表示不可變備份已從災難復原最佳實務演變為必要的 cybersecurity framework 控制措施。

復原指標說明了財務風險。根據 IBM Cost of a Data Breach Report，勒索軟體與勒索型資料外洩事件使組織平均損失 508 萬美元，約比整體資料外洩平均值 444 萬美元高出 14%。根據 FEMA，40% 的企業在災難後不會重新營業，另有 25% 會在一年內倒閉。

真實世界的攻擊顯示，網路事件與營運持續失敗會彼此加劇。Colonial Pipeline 停擺、NotPetya 對 Maersk 整體 IT 基礎架構的毀損，以及 JBS Foods 工廠關閉，都證明勒索軟體造成的連鎖業務中斷，遠遠超出最初的技術性入侵。

網路事件需要在全部四個營運時程中進行協調回應，而您的安全平台會直接影響您通過各階段的速度：

• 事件回應（數分鐘至數小時）：您的 SOC 會執行技術性遏制程序。當您的安全平台能更快發現威脅時，此時程就會縮短； Singularity Platform 可將警示量減少 88%，讓您的 SOC 能更快從初始遏制推進到經驗證的復原。
• 危機管理（數小時至數天）： 安全領導層會與高階主管、董事會成員、監管機關及客戶溝通。
• 營運持續（數天至數週）： 跨職能團隊會在系統持續中斷期間維持營運。
• 災難復原（數週以上）： 安全工程會驗證已復原系統在返回正式環境前，是否符合強化後的安全基準。

這些延長的時間軸會改變您的 RTO 和 RPO 計算。復原會延伸至所有四個營運階段，而不是像基礎架構故障所允許的那種立即還原。您的安全架構也必須將對抗性情境納入考量：多雲策略會將資料分散到多個供應商，建立可在單一備份儲存庫遭入侵時提供保護的備援。資料保管庫機制可確保備份資料無法被遭入侵的憑證加密或刪除，因此基於相同原因，已成為一項必要的控制措施。

了解營運持續計畫與災難復原計畫的範圍差異，有助於您更有效地建構韌性計畫。

營運持續計畫與災難復原計畫之間的關鍵差異

BCP 與 DRP 在七個關鍵領域中發揮不同功能，這些領域會影響您如何建構韌性計畫並配置安全資源。

• 範圍：您的 BCP 涵蓋整個組織營運與任務關鍵業務流程。您的 DRP 則專門針對 IT 系統、資訊系統與技術基礎架構。
• 目標： 您的 BCP 可在中斷期間及之後維持營運。您的 DRP 則在事件造成技術故障後恢復 IT 能力。
• 時間焦點： 您會在事件發生前、期間及之後，主動且持續地啟動業務持續營運計畫。您則會在特定災難需要技術復原時，被動地觸發災難復原計畫作為回應。
• 涵蓋範圍廣度： 您的 BCP 涵蓋人員、流程、設施、供應鏈、通訊，以及整個組織的技術。您的 DRP 則聚焦於技術基礎架構、系統、應用程式與資料還原。
• 復原指標： 您的 BCP 會在組織層級為業務流程與營運能力定義 RTO 和 RPO。您的 DRP 則專門為系統、應用程式與資料還原建立技術性 RTO 和 RPO。
• 組織整合： 您的 BCP 作為整合整個組織的策略架構。您的 DRP 則作為更廣泛 BCP 架構中的戰術組成部分。
• 計畫啟動觸發條件： 當任何重大中斷影響業務營運時，您會啟動業務持續營運計畫。您則會專門針對 IT 系統故障、資料遺失事件與技術基礎架構損壞而啟動災難復原計畫。

這些差異形塑了您的組織必須在各項計畫中納入的特定組成要素。

業務持續營運計畫與災難復原計畫的必要組成要素

您的業務持續營運計畫需要與災難復原計畫不同的組成要素，儘管兩者都必須整合以實現網路韌性。以下細分說明各計畫必須包含的內容，以及它們的重疊之處。

根據 DRI International 與 FEMA 指引，您的 BCP 必須包括：

• 具指定代理人的復原團隊
• 已文件化的差旅與資源後勤安排
• 桌面系統、重要紀錄與通訊基礎架構的需求
• 替代地點的關鍵聯絡人與設備

您的 DRP 需要支援 BCP 目標的技術專屬組成要素，特別強調保護備份基礎架構免受 ransomware 侵害。核心 DRP 組成要素包括：

具指定代理人的技術職能復原團隊

• 涵蓋備份系統的資料與儲存需求，且備份系統具有不可變儲存庫，以確保 ransomware 無法加密或刪除復原資料
• 語音與資料通訊硬體規格，涵蓋為替代設施設定的網路頻寬、電話交換機與路由器
• 具基礎架構規格的硬體與軟體需求（電力/PDU、發電機/UPS、冷卻系統、佈線）
• 安全控制，包括 防火牆 與驗證系統
• 應用程式相依性對應圖，以及具技術指示的詳細復原程序，以進行系統化還原

每個組成要素都必須回扣到您的 BCP 所定義的業務需求。

根據 FEMA 的 IT 災難復原指引，您的計畫必須包含在 業務衝擊分析 期間制定的優先順序與復原時間目標。技術復原策略必須明確說明您如何在業務復原時限內還原硬體、應用程式與資料。資料備份與復原是不可或缺的組成部分，涵蓋網路伺服器、桌上型電腦、筆記型電腦與無線裝置中的資料。

這些組成要素推動建立流程，但了解各計畫包含哪些內容只是第一步。

如何建立業務持續營運計畫與災難復原計畫

建立有效計畫需要一套循序漸進的流程，將業務需求連結到技術復原能力。NIST SP 800-34 建立了一套 七步驟應變規劃流程，適用於 BCP 與 DRP 的制定。

以下五個核心步驟將該架構調整為建立這兩項計畫的實務工作流程：

1. 執行業務影響分析。 您的 BIA 可識別哪些業務流程屬於任務關鍵，並量化其遭受中斷時對營運與財務造成的後果。訪談部門主管與流程負責人，以判定每項功能在後果變得不可接受之前，最長可離線多久。這些容忍門檻將成為您的 RTO 與 RPO 目標。
2. 評估風險並對應威脅。評估每項威脅對您的 BIA 所識別關鍵功能的發生可能性與潛在影響，範圍涵蓋勒索軟體、基礎架構故障、自然災害與供應鏈中斷。此評估可決定您的計畫必須涵蓋哪些情境，並協助您排定預防性控制投資的優先順序。
3. 制定復原策略。 您的 BCP 策略應說明在中斷期間如何維持各項關鍵業務功能：替代工作地點、手動因應方式、通訊協定，以及供應鏈替代方案。您的 DRP 策略則應明確說明如何還原各項技術系統：備份與復原程序、容錯移轉組態、替代站點啟用，以及資料還原順序。
4. 明確指派責任歸屬。您的 BCP 需要涵蓋營運、通訊、人資、法務與財務等跨職能領導。您的 DRP 需要由 IT 與資安團隊負責技術層面的責任歸屬，並為每個關鍵角色指定代理人。記錄升級路徑與決策權限，讓團隊在高壓事件期間無須等待核准即可採取行動。
5. 以營運細節進行文件化。納入逐步程序、聯絡人清單、供應商協議與網路圖。若計畫在會議室中讀起來完善，卻缺乏營運細節，便會在實際事件中失效。

真實世界事件顯示，這些步驟若處理不當將付出何種代價。這起 Colonial Pipeline ransomware attack於 2021 年 5 月發生，顯示當事件回應、業務持續性與災難復原缺乏協調時會發生什麼情況：該公司關閉了為美國東南部提供服務的 5,500 英里燃料管線，支付了 440 萬美元贖金，並引發廣泛燃料短缺，最終需要總統發布緊急狀態聲明。這起 NotPetya attack使 Maersk 損失約 3 億美元，因為該惡意軟體摧毀了 45,000 台 PC 與 4,000 台伺服器，迫使員工在十天內從零開始重建整個 IT 基礎架構。

這兩起事件都凸顯，您的計畫制定流程必須將對抗性情境納入考量，而不只是基礎架構故障。當您的計畫建立完成後，下一步就是定義復原指標，以判定這些計畫究竟成功或失敗。

RTO 與 RPO：業務持續性與災難復原的復原指標

Recovery Time Objective (RTO) 與 Recovery Point Objective (RPO) 是您的業務持續性與災難復原規劃中最重要的兩項 資安指標。您的 BIA 流程應產出這些目標，而您 BCP 與 DRP 中的每項復原策略都應可追溯至這些目標。

Recovery Time Objective (RTO)

您的 RTO 定義了業務流程在組織遭受不可接受後果之前，所能容忍的最長中斷期間。當勒索軟體在凌晨 2:47 鎖定您的正式環境時，您的 RTO 將決定您是否必須在上午 8:00 開始營業前恢復營運，或是否可以容忍中斷持續到營業日結束。

勒索軟體復原 會增加複雜性，因為它需要 鑑識調查、惡意軟體清除驗證，以及在系統可安全返回正式環境前進行安全驗證。標準 RTO 假設預期可在事件發生後立即開始還原。網路事件會將您的實際復原時程從數小時延長至數天或數週，因此重新計算實際指標至關重要。

Recovery Point Objective (RPO)

您的 RPO 定義了為在不造成不可接受資料遺失的情況下恢復正常營運，備份儲存中所需檔案或資料的最長可接受時間差。若您最後一次乾淨的備份快照發生在午夜，而勒索軟體於凌晨 2:47 加密系統，您將面臨 2 小時 47 分鐘交易資料可能遺失的風險。您的 RPO 將決定這種資料遺失是否會造成可接受或不可接受的業務影響。

中的回復功能 Singularity Platform 可透過讓系統還原至感染前狀態，同時讓您的資安團隊進行鑑識調查，來因應 RPO 挑戰。

法規要求

法規框架針對這兩項指標都建立了強制性要求。 PCI DSS 要求支付卡處理商制定災難復原計畫。 HIPAA 要求制定包含明確 RTO 與 RPO 的計畫，以保護 ePHI。 CISA's NICE Framework 的能力領域現已將資料保險庫原則 (K1278) 正式列為必要能力，因其認知到不可變備份基礎架構會直接影響組織在對抗性情境下是否能達成其 RPO 目標。

僅定義這些指標還不夠。在您證明這些目標能在真實條件下成立之前，您的 RTO 與 RPO 目標都仍只是理論。

測試、維護與實作最佳實務

超越合規核取方塊演練的測試計畫，是驗證您的業務持續性計畫與災難復原計畫在您需要時是否能發揮作用的唯一方式。

ISO 22301 第 8.5 條要求執行業務持續性演練，以驗證您的計畫是否代表及時且有效的策略。 NIST SP 800-34 將計畫測試、訓練與演練列為七步驟應變規劃流程中的第六步。DRI International Professional Practice Eight 將「Business Continuity Plan Exercise/Test, Assessment, and Maintenance」列為整合能力。

FINRA Rule 4370 為受監管公司建立了最低年度測試要求，以「確認 BCP 已更新，並評估其有效性，尤其是與任務關鍵系統與流程運作相關的部分。」若您在受監管的金融服務領域營運，則至少必須每年測試一次。 Purple AI 透過提供對安全資料的自然語言存取，加速此驗證測試，使分析師能跨遙測資料進行查詢，並在無需手動調查延遲的情況下確認復原整備狀態。

計畫維護需要依變更驅動進行更新，而非僅依賴以日曆為基礎的審查。ISO 22301 管理審查要求規定，您必須考量「與 BCMS 相關的外部與內部議題變更」以及「來自 BIA 與 風險評估 的資訊」。FINRA 監管指引要求公司「在必要時，根據公司營運、結構、業務或地點的變更，審查並更新其 BCP」。

當您部署新應用程式、遷移至雲端服務、收購公司，或面臨新興威脅時，這些都會觸發強制性的計畫審查。您的技術堆疊變更或商業模式演進都需要更新 BCP 與 DRP；僅僅經過 12 個月並不足夠。

您的實作方法應遵循 NIST SP 800-34 所建立的七步驟流程：

• 制定應變規劃政策聲明，以建立組織承諾與治理架構。
• 執行業務衝擊分析（BIA），根據實際業務容忍度系統化判定 RTO 與 RPO 需求。
• 識別預防性控制措施。
• 定義直接源自 BIA 發現的技術復原與業務持續策略。
• 建立資訊系統應變計畫。
• 確保進行計畫測試與訓練，將策略轉化為營運能力。
• 使用 Plan-Do-Check-Act 方法論，透過定期更新維護計畫。

ISO 22301 第 5 條將建立業務持續領導與監督的責任指派給高階管理層與董事會。領導階層必須建立並記錄與策略方向一致的業務持續政策，而非僅將此責任委派給 IT 或安全部門。

版本控制與變更管理紀律，是成熟計畫與合規作業之間的分水嶺。DRI International Professional Practice 8 要求您稽核變更控制流程並維持嚴謹的版本控制。這些治理實務可確保在發生網路事件時，您的計畫仍可執行，而合適的安全平台能讓執行的每個階段都更快速。

使用 SentinelOne 強化業務持續與災難復原

您的業務持續與災難復原成效，取決於協調四條營運時間軸：事件回應（數分鐘至數小時）、危機管理（數小時至數天）、業務持續（數天至數週），以及災難復原（數週以上）。 Singularity Platform 透過在事件回應期間快速發現威脅，並實現符合安全基準的驗證式復原，來壓縮這些時間軸。警示減少 88% 後，您的 SOC 可減少分流處理時間，將更多時間投入推動復原。

Purple AI 可加速全部四個階段的調查與回應，提供警示的情境摘要、建議的後續步驟，以及在生成式與代理式 AI 協助下展開深入調查的能力。早期採用者回報 威脅調查速度提升 80%。

當您能在主動調查期間隔離受損端點，同時維持部分業務功能時，您的業務持續計畫執行成效就會提升。 Singularity Endpoint 使用分析異常行為並即時識別惡意模式的行為式與靜態 AI 模型來發現勒索軟體，而一鍵回復功能可讓系統快速還原至感染前狀態。這讓您能在中斷期間維持營運，而不是關閉整個業務單位，這正是 BCP 的核心目標。

向 SentinelOne 申請示範，了解 Singularity Platform 如何強化您的業務持續與災難復原策略。

Cloud Security Demo

Discover how AI-powered cloud security can protect your organization in a one-on-one demo with a SentinelOne product expert.

Get a Demo

重點整理

業務持續計畫可在中斷期間維持組織營運，而災難復原計畫則在技術故障後還原 IT 系統。您需要兩者協同運作，尤其是在勒索軟體情境中，因為這類情況在復原前需要進行鑑識調查與安全驗證。 

RTO 與 RPO 計算必須納入延長的網路事件時間軸，這些時間軸橫跨事件回應、危機管理、業務持續與災難復原階段。測試代表持續性的計畫要求，對受監管產業而言至少需每年進行一次，以確保您的計畫能隨著營運與威脅演變而持續有效。