业务连续性管理—第四篇—业务连续性总结和灾难恢复

一、引言

在我们日常工作中常常会将业务连续性管理（BCM）和灾难恢复(DR)两个概念混淆，两者之间有内在联系，但也有所不同。业务连续性管理更加宽泛，关注企业的战略，以保障业务运营为目标，解决全生命周期的问题，而后者更加注重具体操作，以系统为目标，着重解决事中的问题，同步处理事后的问题。一般来讲，可以将灾难恢复做为业务连续性的一个部分，但不是全部。

1）按照CISSP中的定义

灾难恢复的目标是尽量减少灾难或中断带来的影响。这意味着要采取必要的步骤以确保资源、人员和业务流程能够及时恢复运行。这与连续性规划不同，连续性规划提供给我们处理长期运营中断和灾难的方法和程序。灾难恢复计划的目标是在灾难之后，处理灾难及其后果；灾难恢复计划已信息技术为核心。灾难恢复计划是当一切事情仍处于紧急模式时实施的计划，其中每个人都争相所有关键系统重新联机。业务连续性规划采取一个更广泛的解决问题的方法。它可以包括在计划实施中对原有设施进行恢复的同时在另一个环境中恢复关键系统，使正确的人在这段时间内回到正确的位置，在不同的模式下执行业务直到常规条件恢复为止。

2）按照NIST SP800-34的定义

业务连续性计划（BCP）:业务连续性计划的重点是在中断期间和中断之后维持组织的任务/业务流程。任务/业务流程的示例可以是组织的工资单流程或客户服务流程。业务连续性计划可以针对单个业务单元内的任务/业务流程编写，也可以针对整个组织的流程。

灾难恢复计划（DRP）:DRP适用于拒绝长期访问主要设施基础设施的重大、通常是物理性服务中断。DRP是一种以信息系统为中心的计划，旨在在紧急情况发生后恢复备用站点上目标系统、应用程序或计算机设施基础设施的可操作性。一旦备用设施建立，DRP可由多个信息系统应急计划提供支持，以解决受影响的单个系统的恢复问题。DRP可以通过在备用位置恢复任务/业务流程或任务基本功能的支持系统来支持BCP或COOP计划。DRP只处理需要重新定位的信息系统中断。

3）按照GB/T 30145-2013/ISO 22301:2012和 GB/T 20988-2007 定义

业务连续性管理 （ business continuity management）：识别对组织的潜在威胁以及这些威胁一旦发生可能对业务运行带来的影响的一整套管理过程。该过程为组织建立有效应对威胁的自我恢复能力提供了框架，以保护关键相关方的利益、声誉、品牌和创造价值的活动。

业务连续性计划：用于指导组织在业务中断时进行响应、恢复、重新开始和还原到预先确定的业务运行水平的形式文件的程序。

灾难恢复 （disaster recovery）：为了将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态、并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态，而设计的活动和流程。

总结：

针对三个标准的理解，各个标准关于术语定义描述各有侧重，但笔者更加倾向于NSIT的定义。笔者认为：业务连续性计划是基于企业战略的、处理长期的、面向中断中和后维持业务连续性的规划，核心是业务连续；灾难恢复计划是面向重大的、灾难性的系统故障，在异地恢复业务暂时性正常运转的计划。灾难恢复解决的临时性的、针对异地恢复的临时性计划。业务连续性管理从涉及的内容看，包含了灾难恢复计划，还包括高可用性。业务连续性更多侧重策划、执行和管控，灾难恢复更注重执行。

本文是笔者近期，短时间内所学的总结，一定会有理解不对的地方，后期根据知识的更新，会进行更新。总之，业务连续性和灾难恢复，无论从安全角度，还是企业运营的角度是十分重要的。其投资回报是隐性的，但不能因为看不到，摸不着就不投入，一旦事件发生，后悔莫及。因此规划须是自上而下的执行，首先要先从思想的统一，需要高层的支持，作为一把手工程去抓，否则就成了光说不练假把式。

以下内容，主要以IT的视角对业务连续和灾难恢复进行总结。

二、业务连续性管理

业务连续性管理具体包括：

• 出现紧急情况时提供及时和适当的应对措施
• 保护生命和确保安全
• 减少对业务的影响
• 恢复关键业务功能
• 在灾难时减少混乱
• 确保企业的生存能力
• 在灾难发生后迅速“启动并运行”

具体流程和里面涉及的细节进行阐述。

1.BCP的启动阶段工作

1）BCP项目启动前准备活动

• 确定BCP需求，可以包括有针对性的风险分析以识别关键系统可能的中断
• 了解相关法律、法规、行业规范以及机构的业务和技术规划的要求，以确保BCP与其一致
• 任命BCP项目负责人，建立BCP团队，包括业务和技术部门的代表
• 制定项目管理计划书，其中应明确项目范围、目标、方法、责任、任务以及进度
• 召开项目启动会，获得管理层支持
• 确定收集数据所需的自动化工具
• 设置必要的技能培训和意识提升活动

2）工作任务

• 计划的开发团队与管理层的沟通和联络
• 有权与计划相关所有人进行直接接触和沟通
• 充分了解业务中断对机构业务的影响
• 熟悉机构的需求和运作，有能力平衡机构相关部门的不同需求
• 与高级管理层对话
• 了解机构业务方向和高管理层的意图
• 有能力影响高级管理层的决策

3）BCP项目的关键角色

• 恢复团队：灾难后进行评估、恢复、复原等相关工作的多个团队
• 业务部门代表：识别机构的关键业务功能，协助恢复策略的选择和制定
• IT部门
• 通信部门
• 信息安全部门
• 法律代表

必须建立的团队：

• 损失评估团队：确定灾难原因；确定进一步破坏的可能性；标识影响的业务和领域；标识关键资源可用程度；标识必要的资源；评估要多久完成。若评估时间超过原来评估的MTD值，立即启动升级BCP。
• 还原/重建团队（restoration）：让备用站点投入运营
• 救援团队（salvage）： 把备份站点在转到主站点，让主站点恢复运营。

3）BCP目标

• 确定信息收集技术
• 选择受访者
• 识别关键业务功能(critical business functions)及其支持资源
• 确定如果失去这些资源的支持这些功能能存活多久
• 识别弱点和威胁
• 计算每个业务功能的风险
• 准备提交BIA报告：存在的问题、应对建议

BCP策略：BCP规划最终应该形成业务连续性策略条款，该条款记录的BCP的目标、范围、需求、基本原则和指导方针、职责和责任、关键环节的基本要求。策略条款应得到高级管理层的正式批准，并公布成为机构的政策，指导业务连续性的相关工作。

2.BIA分析

主要工作内容：

• 确定关键功能
• 确定关键资源
• 计算MTD资源
• 识别威胁
• 计算风险
• 确定方案

 

1）BIA过程

 

 

 

2）BIA分析方法

• 定性分析以划分严重程度的方式得出灾难或中断事件造成的影响
• 定量分析以货币的方式得出灾难或中断事件造成的影响

BIA的信息分析过程：整理（Organize） 归纳（Correlate） 分析（Analyses）和确认（Confirm）

BIA分析中断的影响，确定每项业务功能的恢复窗口，具体会涉及几个值：

• 工作复原时间， Work Recovery Time，WRT：从系统正常运转，恢复业务的时间（数据恢复）
• 恢复时间目标，Recovery Time Object，RTO：在系统的不可用性严重影响到机构之前所允许消耗的最长时
• 恢复点目标，Recovery Point Objectives，RPO：数据必须被恢复以便继续进行处理的点。所允许的最大数据损失量

        RTO+WRT<=MTD

关于MTD与RPO、RTO和WRT的关系如下图：

 

关于网络和资源可用性指标

• 平均修复时间（MTTR）：修复一台设备并使其投入生产状态所需的时间
• 平均无故障时间（MTTF）：计算机系统平均能够正常运行多长时间，才发生一次故障。系统的可用性越高，平均无故障时间越长。
• 平均故障时间间隔（MTBF）：期望一台设备可靠运行估计时间.是衡量一个产品（尤其是电器产品）的可靠性指标，单位为“小时”。它反映了产品的时间质量，是体现产品在规定时间内保持功能的一种能力。

 总结：组件越多，整体可靠性越低

3）风险评估

应当识别、评估和记录以下内容：

• 组织中对时间最敏感的资源和活动的所有脆弱点
• 组织中最紧迫的资源以及活动的威胁和危害
• 衡量关键的服务和产品中断的可能性、时间长度以及造成的影响。
• 单点故障的情况
• 由于关键技能的缺失造成的业务连续风险
• 由于外包供应商和供应商造成的业务持续性风险
• 因BCP计划没有涵盖本部门或者BCP计划没有很好地落实而造成的业务连续性风险

3.确定预防控制措施

主要的目标实施控制，以降低风险

1)数据备份方案的选择

数据备份开始位置：归档位。

 

归档位:操作系统的文件系统通过设定归档位来跟踪发生变化的文件。

完全备份（full backup）：整个数据的备份

增量备份（incremental process）:对最近完全备份和增量备份以后发生的所有文件进行备份;阶段性叠加；占用空间少，但恢复慢，恢复时需要把所有增量加上全备份进行恢复

差量备份（differential process）：对最近完全备份发生改变的部分进行备份；与完全备份的差异部分备份；需要空间大，恢复快。恢复时只需要最新一次差量和一个完备

具体关系图如下:

 

 

 

 

完全备份是增量备份和差异备份的前提条件，首次需要先完成一次完全备份后才能开在增量备份、差异备份。若选择差异备份，当要恢复数据时需要选择一次完全备份和以此完全备份为基础的最近一次的差异备份，这种方式的缺点是备份时间长、占用空间大，例如开始数据10G，每天增加1G，那么完全备份的数据是10G，第一天的差异备份是1G，第二天的是1G+1G，第三天的是1G+1G+1G，这样恢复时，只需要恢复一个完全备份，选一个需要恢复时间点的差异备份即可；若选择增量备份，但恢复数据时需要选择一次完全备份和以此完全备份为基础的所有增量备份，这种方式缺点是恢复慢，例如开始书记10G，每天增量1G，那么完全备份的数据是10G，第一天是1G，第二天是1G，第三天是1G，这样恢复时，需要先恢复完全备份，然后恢复第一天，再恢复第2天，再恢复第3天。顺序不能乱。

2）高可用性

应用层（负载均衡+高可用）、数据层（rac）、设施层（HA）

3）电子备份解决方案

• 磁盘映像（disk duplexing）（RAID 1）
• 电子传送（electronic vaulting）：在文件发生改变时进行备份，再定期传送到另一个地点；不是实时 （使用备份软件）
• 电子链接：一种实时备份到异地设施批量传送方法（使用备份软件/备份设备）
• 远程日志处理（remote journaling）：离线数据传输方法；只将日志或事务处理日志传送到异地，不传送实际文件；类似数据库的归档；通过日志可重建丢失的数据，实际为数据被增删改的记录；实时发生（归档日志）

4）设施选择

完备场所（hot sit）：拥有与主站点的所有软硬件设施，唯一缺的是数据。在几个小时就能投入运营

基本完备场所（warm site）：只配置了主要软硬件

基础场所（cold site）：只提供机房环境

软件备份：代码第三方托管

5）其他因素    

• 网络和计算机设备冗余
  
• 语音和数据通信资源冗余
  
• 人力资源
  
• 设备和人员运送
  
• 环境问题
  
• 数据和人员安全
  
• 办公资源
  
• 文档记录
  
• 外包 ：一种风险转移措施

互惠协议（reciprocal agreements）：组织间用于分享宕机风险。在灾难发生时，每个组织承诺承担彼此的数据和处理任务。

4.制定恢复策略

业务流程、设施、供应和技术、用户和用户环境、数据

• 恢复策略的选择必须符合组织需求
  
• 成本效益分析 (CBA)
  
  • 建立策略的初始费用
    
  • 维护恢复策略解决方案的持续费用
    
  • 方案定期测试的费用
    
  • 通信相关的费用

5.制定BCP

文档化程序包括：计划程序、恢复程序、恢复解决方案、角色和任务、应急响应

业务连续性计划流程如下：

a)确定业务关键功能

公司的业务计划通常就决定了公司关键的使命和业务功能。必须为这些功能设定优先级别

b)确定支持关键功能的资源和系统

在确定了关键的功能之后，就有必要找出实现这些功能究竟需要那些支持。

需要有人来对这些资源进行分析，这样的分析应该由那些理解资源并知道它们是如何为企业提供功能的人来完成。

c)估计潜在的灾难事件

确定所有可能的意外事故和灾难

BIA的结果作为以上的输入。

d)选择计划策略

制定有关如何恢复关键资源和评估应急方案

6)实施策略

一旦决定了策略，就需要将它们归档，这使得我们的努力从纯粹的计划阶段进入到了实际的实施和行动阶段。

 

6.操作、演练和测试

需要对业务连续性计划做定期测试，因为环境总是在持续变化，每一次测试都能够带来一些改进。一般会形成以下计划：

• 测试计划
• 改进计划
• 培训计划

1）具体测试类型包括：

• 清单/检查表测试（checkling test）：计划副本发涉及的部门让他们审核，避免出现不切实际或遗漏的措施。

        各部分分头审核提意见

• 组织演练测试/结构化排练测试（structured walk-through test）：各部门人员聚在一起审核计划。

        聚集在一起审核提意见

• 模拟测试（simulation test）：所有相关人聚集在一起，根据某个场景展开练习如何执行灾难恢复计划。测试每个人的反应。确保没有遗漏步骤。测试过程只包含哪些实际灾难中可能存在的情况。测试一直持续到搬到了异地设施处并真正配置了替换设备为止。

        所有人聚集一起测试，选定场景，知道设备搬到异地备份结束。

• 并行测试（parallel test）：系统搬到备用厂所运行，然后与原厂所对比。

        只系统搬到异地，本地还运行，对比分析

• 全中端测试（full-interrupution test）：完全模拟真实场景，原站点关闭，备用站点启用。

        本地全停用，异地启用，管理层批准，先要完成并行测试。

2）测试策略包含测试目标和范围

• 测试BCP/DRP 每年至少测试一次： 当重大变更发生时需要进行测试
• 测试目标刚开始可以简单逐渐增加复杂度、参与级别、职能以及物理位置
• 测试不要危及正常业务运行
• 测试展示在模拟危机下各种管理和响应能力，逐渐增加更多的资源和参与者
• 揭示不恰当之处以便修正测试程序
• 考虑偏离测试脚本插入意外事件，比如关键个人或服务的损失
• 包括足量所有类型交易确保恢复设施适当的能力和功能

 测试策略包含测试计划：基于预定的测试范围和目标

• 包含测试计划评审程序
  
• 包含各种测试场景和方法的开发
  

测试计划：主测试计划应包括所有的测试目标

测试目标和方法的具体描述

• 所有测试参加者包括支持人员的角色
  
• 测试参与者的委派
  
• 测试决策制定者和后续计划
  
• 测试位置
  
• 测试升级条件和测试联系信息
  

7.维护BCP

整合到变更控制流程中，主要包括：

• 分配责任
• 更新计划
• 更新后发布

 8.应急事件处理流程

 

再造阶段（reconstittution phase）：当公司开始搬回原来的场所或搬进一个新设施时。

 三、灾难恢复计划

灾难恢复：指自然或人为灾害后，重新启用信息系统的数据、硬件及软件设备，恢复正常商业运作的过程。

灾难恢复目标：降低灾难或业务中断的影响；采取必要的步骤保证资源、人员和业务流程尽快恢复运作。往往更加关注IT层面。

预防性措施与恢复战略的区别

• 预防性是不仅降低公司经历灾难的可能性，同时减轻破坏程度，对灾难本身进行缓解
• 恢复战略是灾难发生后用于保护公司的方法，利用提供备用场所，对灾难本身没有啥改变

业务流程恢复：是一组相互关联的步骤，它通过特定的决策活动完成具体的任务

DR包括反应、人员、沟通、评估、恢复和培训

灾难恢复计划执行大体上可以以下几步组成：

 

 

响应阶段：开始判断灾难的原因，先分析才能对症下药。

沟通阶段：针对事件情况进行沟通评估

评估阶段：确定需要立即替换的资源、判断关键系统上线的时间，为下一步工作作准备，并确定是否启动BCP计划。

恢复阶段：宣告灾难，开始灾难恢复。

 

 四、其他相关计划

业务连续性计划：着重于恢复必须重建的业务流程而非IT组件

操作连续性计划：在灾难发生后建立高级管理层和总部，说明角色、权威，继任的先后顺序

IT应急计划：用于网络、系统和主要应用程序恢复的过程计划

紧急通信计划：包括内部和外部沟通结构和角色

网络事故响应计划：主要关注恶意软件、入侵攻击和其他安全问题

灾难恢复计划：重点说明在发生灾难后恢复各种IT机制

场所应急计划：人员安全和撤离程序。

 

 

 

 

 

特别声明：

1.以上所有描述内容部分参考链接/文献未逐一列出，若有侵权，请及时告知，有则改之无则加勉。

2.以上仅是学习过程的总结，相信有很多理解偏差的地方，特别希望指出，给予帮助，更新知识体系，共同进步。

3.以上内容大部分是采用百度翻译，结合自己的理解，所有有些理解偏差的，请批评指正！

参考文献：

 

<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">

 

 

 

 

来自为知笔记(Wiz)