OSG9第十八章 灾难恢复计划

CISSP（Certification for Information System Security Professional）即信息系统安全专业认证，这一证书代表国际信息系统安全从业人员的权威认证

第十八章 灾难恢复计划

• 18.1 灾难的本质
  • 业务连续性计划(business continuity planning, BCP)：的基本内容，他帮助你的组织评估优先级，设计弹性流程，从而在灾难发生时保障业务继续运营
  • 灾难恢复计划(disaster recovery planning, DRP)：是对以业务为中心的 BCP 演习的技术补充。它包括了在中断发生后尽快阻止中断并促进服务恢复的技术控制。
  • 灾难恢复计划和业务连续性计划共同引导应急响应人员采取行动，直至达成最终目标一使主要运营设施恢复全部运营能力。
  • 灾难恢复计划：旨在使组织正常运营中断后出现的混乱局面恢复正常。因为性质特殊，灾难恢复计划几乎总在人员高度紧张和头脑可能不那么冷静时执行
  • DRP 应该被设置为尽可能自动运行
  • 18.1.1 自然灾难
    • 自然灾难反映了我们生存环境的恶劣之处
    • 1. 地震
    • 2. 洪水
    • 4. 火灾
    • 5. 流行病
    • 6. 其他自然事件
    • 在 BCP/DRP 实施过程中，评估团队应当分 析组织的所有运营地区，并评估这类事件可能对业务造成的影响。
  • 18.1.2 人为灾难
    • 1. 火灾
    • 2. 恐怖行为
    • 3. 爆炸
    • 4. 电力中断
      • 组织通常用不间断电源(UPS)设备保护关键业务系统，这些电源使其至少有足够长的时间关闭系统或开启应急发电机
    • 5. 网络、公共设施和基础设施故障
    • 6. 硬件／软件故障
    • 7. 罢工示威抗议
    • 8. 偷窃／故意破坏
  • 我们今天仍应吸取的教训包括
    • 确保备用站点位于离主场所足够远的地方，从而使其不容易受到同一灭难的影响。
    • 需要记住，组织会面对来自内部和外部的威胁
    • 灾难往往不会有预警
• 18.2 理解系统韧性、高可用性和容错能力
  • 可用性是 CIA 三要素（保密性、完整性和可用性）的核心目标之一，而提升系统韧性和容错能力的技术控制会直接影响可用性
  • 任何组件都可能发生单点故障(single point of failure, SPOF)，导致整个系统无法运行。
  • 系统韧性(system resilience)：是指系统在遭遇不利事件时保持可接受服务水平的能力
  • 容错能力：是指系统在发生故障的情况下仍可继续运行的能力
  • 高可用性：是指使用冗余技术组件，使系统能在经历短暂中断后快速从故障中恢复
  • 两地三中心
  • （Resilence）韧性
    • DRP和BCP都是事后行为，属于纠正性措施
  • 18.2.1 保护硬盘驱动器
    • 在计算机中添加容错和系统恢复组件的常见方法是使用 RAID 阵列。
    • RAID 类型
      • RAID-0: 也被称为条带。它使用两个或多个磁盘，它提高了磁盘子系统的性能，但不提供容错能力。性能高，但是不提供容错
      • RAID-1 :也被称为镜像。它使用两个磁盘，每个磁盘保存相同的数据，可以坏一块硬盘，提供坏一块的安全性
      • RAID-5 : 也被称为带奇偶校验的条带。它使用 3 个或更多磁盘，相当于一个包含奇偶校验信息的磁盘
      • RAID-6 : 这提供了另一种使用奇偶校验进行磁盘条带化的方法。它的工作方式与RAID-5 相同，但在两个磁盘上存储奇偶校验信息，以防两个单独的磁盘同时出现故障
      • RAID-10 : 也被称为 RAID1+0 或镜像条带。它被配置为两个或多个镜像(RAID-1)，每个镜像都配置为条带化(RAID-0）。它至少需要 4 个磁盘，优点既有安全有有高性能，考点
    • RAID 可基于软件，也可基于硬件
      • 基于软件的系统：需要操作系统管理阵列中的磁盘，这会降低系统的整体性能，但相对便宜一些，因为不需要除磁盘以外的其他硬件
      • 基于硬件的 RAID 阵列：系统通常更有效、更可靠。尽管硬件的磁盘阵列更昂贵，但当使用这种阵列增加某些关键组件的可用性时，收益大于成本。
    • 大多数基于硬件的阵列支持热插拔，不必关闭系统电源就可以更换损坏的磁盘。
  • 18.2.2 保护服务器
    • 可通过容灾切换集群将容错功能添加到关键服务器中
    • 容灾切换集群：包含两个或多个服务器，如果其中一台服务器出现故障，集群中的另一台服务器可通过名为容灾切换的自动化过程接管其负载。容灾切换集群可包含多台服务器（不只两台），它们可为多个服务或应用程序提供容错功能。
    • 如图 18.2 所示， DB1 和 DB2 都能访问数据库中的数据，这些数据存储在 RAID 阵列上，为磁盘提供了容错能力。
    • 此外， 3 台 Web 服务器被配置在网络负载均衡集群中。负载均衡可基于软件，也可基于硬件，它平衡 3 台服务器上的负载
    • 如果你正在使用云服务商提供的服务器，那么可充分利用他们提供的容错服务。例如，许多 IaaS 供应商提供负载均衡服务，在需要时自动缩放资源
    • 同样，在设计云环境时，一定要考虑数据中心在世界各地的可用性
  • 数据中心等级
    • 容错：指系统层面，可以抵御一个或多个组件故障，服务器
    • 冗余：指组件层面，比系统低一级，电源、网线、磁盘阵列
  • 18.2.3 保护电源
    • 可使用不间断电源（Uninterruptible Power Supply，UPS）、发电机或将两者结合起来为电源添加容错功能。
    • 般来说， UPS 只能短时间供电，持续时间在 5 到 30 分钟之间
    • 发电机提供长期电源
    • UPS 的目标是在足够长的时间内供电，以完成系统的逻辑关机，或直到发电机通电并提供稳定的电源
    • 发电机在长期停电期间为系统供电。发电机提供电力的时间取决于有多少燃料，只要有 充足的燃料且发电机正常工作，就可以持续供电
  • 18.2.4 可信恢复
    • 可信恢复确保系统在发生故障或崩溃后，能够与之前一样安全。
    • 恢复过程的两个要素能够确保可信解决方案的实施
      • 第一个要素是失败准备。除了可靠的备份解决方案外，还包括系统恢复及容错方法
      • 第二个要素是系统恢复的过程。系统必须重新启动到单用户、非特权状态。这意味着系统应该重新启动，使正常用户账户能够登录系统，且系统不再允许非授权用户登录
    • 通用标准(Common Criteria)定义了 4 种类型的可信恢复
      • 手动恢复 ：如果系统出现故障，系统并没有处于故障防护状态。相反，在系统发生故障或崩溃后，管理员需要手动执行必要操作以实施安全或可信诙复。
      • 自动恢复：对于至少一种类型的系统故障系统能自动执行可信恢复。例如， RAID 硬盘可恢复硬盘驱动器故障，但不能恢复整个服务器故障
      • 无不当损失的自动恢复 ：这类似于自动恢复，对于至少一种类型的系统故障，系统能自动恢复
      • 功能恢复： 支持功能恢复的系统能自动恢复某些功能。这种状态能确保系统成功地完成 功能恢复，否则系统将恢复到变更前的故障防护状态。
  • 18.2.5 服务质量
    • 服务质量(Quality of Service，QoS)：控制能够保护负载下的数据网络的可用性
    • 有助于提升服务质最的一些因素
      • 带宽： 可供通信的网络容量。
      • 延迟时间： 数据包从源到目的地所需的时间。
      • 抖动Gitter)： 不同数据包之间的延迟变化。
      • 数据包丢失： 一些数据包在从源到目的地的传送过程中可能丢失，需要重新传输。
      • 干扰： 电噪声、故障设备等因素可能会损坏数据包的内容。CRC冗余校验
• 18.3 恢复策略
  • 精心设计的灾难恢复计划应当能够实现：即使正式的 DRP 团队成员未到达现场，第一批到达灾难现场的员工仍能有组织地立即开展恢复工作。
  • 除了提高响应能力外，也可通过购买保险来减轻经济损失
  • BIA
    • 6R模型
  • 18.3.1 业务单元和功能优先级
    • 定义灾难或错误发生后想恢复哪些功能或以将是一个极好的资源。什么样的顺序恢复。在执行此任务时，你在业务连续性工作期间所做的业务影响分析(BIA)
    • 要完成这一目标， DRP 团队必须首先标识关键业务单元，这对于实现组织的使命至关重要
    • 任务完成后的结果应该至少包含一张业务单元优先级列表
    • 最后的结果应该按优先级顺序列出检查表，并列出风险和成本评估，这包括平均恢复时间(MTTR)、最大允许中断时间(MTD) 、恢复时间目标(RTO)和恢复点目标(RPO)
  • 18.3.2 危机管理
    • 如果灾难袭击了你的组织，很可能引起恐慌，与之斗争的最好方法是准备一份系统的灾难恢复计划
    • 许多事情可能看起来属于常识性问题（如发生火灾时拨打应急服务机构的电话），但在紧 急清况下，恐慌中的员工想到的可能只是迅速逃离
    • 危机管理是一门科学，也是一门艺术。如果培训预算允许，不妨对主要员工进行危机培训
  • 18.3.3 应急沟通
    • 当灾难来袭时，组织必须能在内部以及与外界进行沟通
    • 某些情形下，灾难可能破坏一些或所有的正常通信手段
  • 18.3.4 工作组恢复
    • 在设计灾难恢复计划时，重要的是记住，目标是让工作组恢复到正常状态并且重新开始他们在日常工作地点的启动
    • 为推动这项工作，有时最好为不同的工作组修建单独的恢复设施。
    • 例如，如果有几家分支机构分布在不同地点，并且执行的任务与你所在办公室的工作组类似
  • 18.3.5 备用处理站点
    • 灾难恢复计划中最重要的要素之一是在主要站点不可用时选择备用处理站点。
    • 1. 冷站点
      • 冷站点只是备用设施，它足够大，可以解决组织的运营负荷，并有适当的电子和环境支持系统
      • 冷站点可能是仓库、空的办公大楼或其他类似的建筑物
      • 许多冷站点可能只有一些电话线，某些站点可能有备用线路，可使用最低限度的通知设备将其激活。
      • 冷站点的主要优点是比较便宜，因为它没有需要维护的计算基础设备，如果站点未使用，就没有每月的通信费用
      • 冷站点从启用到正式投入使用通常需要数个星期的时间，因此迅速恢复是不太可能的，无法进行测试
    • 2 热站点
      • 热站点与冷站点恰好相反。这种配置中，备用工作设施保待恒定的工作状态，配备完备 的服务器、工作站和通信线路，准备好承担主要的运营职责
      • 主站点服务器上的数据会定期或持续复制到热站点中对应的服务器上，从而确保热站点 中所有的数据都是最新的
      • 根据两个站点之们可以使用的带宽，热站点中的数据可实时同步。
      • 三种选择来启用热站点
        • 如果在主站点关闭前有充足的时间，可在运营控制迁移前强制在两个站点之间进行数据复制
        • 如果无法进行数据复制，可将主站点事务日志的备份磁带搬到热站点，并以手工方式恢复自上次复制以来发生的事务。
        • 如果没有任何可用的备份并且无法强制进行复制，那么灾难恢复团队只能允许丢失部分数据。只有当损失在组织的恢复点目标(RPO)范围内时，才应执行此操作。
      • 如果组织希望维持一个热站点，又想减少购买和维护设备的费用，那么可选择使用外部 承包商管理的共享热站点设施
      • 另一种减少热站点费用的方法是把热站点用作开发或测试环境。
    • 3. 温站点
      • 对灾难恢复专家来说，温站点是介于热站点和冷站点之间的中间场所
      • 温站点中的设备通常是预先配置好的，并准备好运行合适的应用程序，以便支持组织的业务运作
      • 温站点一般不包含客户端数据副本。
      • 灾难发生后，启用品站点至少需要 12 个小时
      • 温站点能避免在维护运行数据环境的实时备份方面耗费的通信及人工费用。
    • 4. 移动站点
      • 对于传统的恢复站点而言，移动站点属于非主流的替代方案。
      • 们通常由设备齐全的拖车或其他容易安置的单元组成
      • 较大的公司有时以“移动方式“维护这些站点，随时准备通过空运、铁路、海运或地面运输，在世界任何地点部署它们
      • 移动站点一般可以配置为冷站点或温站点
    • 6. 云计算
      • 许多组织现在把云计算当作首选的灾难恢复选项
      • 基础架构即服务(IaaS)提供商，如亚马逊的 Web 服务(AWS)、微软的 Azure 、谷歌计算引擎，以较低成本按需提供服务
      • 已经在云中运行其技术资源的组织并不能无视灾难恢复问题。
    • 7. 相互援助协议
      • 相互援助协议(mutual assistance agreement, MAA):也称为互惠协议，在关于灾难恢复的文献中非常流行，但在真实世界中很少被采用
      • 在 MAA下，两个组织承诺在灾难发生时通过共享计算设施或其他技术资源相互援助。
      • MAA缺点
        • MAA 很难强制实施
        • 互合作的组织的地理位置应该相对接近，以方便员工在不同的工作地之间奔走。
        • 出于对保密性的考虑，公司通常会避免将自己的数据交给其他公司
  • 18.3.6 数据库恢复
    • 数据库内容离站备份的三种主要技术手段：电子链接、远程日志处理和远程镜像
    • 1.电子链接
      • 在电子链接这种情况中，数据库备份通过批量传送的方式转移到远处的某个场所。远处 场所可以是专用的备用恢复站点（如热站点）
      • 如果使用了电子链接，需要记住，从组织宣布灾难，到数据库准备好用当前的数据进行 操作，可能有相当长的时问延迟
      • 电子链接存在丢失重要数据的可能性
    • 2. 远程日志处理
      • 远程日志处理以一种更快的方式传输数据。
      • 据传输仍以批量方式进行，但更频繁，通常每小时或更短时间一次
      • 与电子链接场景不同，当数据库备份文件被批量转移时，远程日志处理设置传输数据库事务日志的副本，其中包括从上次批量传输以来发生的事务
    • 3 远程镜像
      • 远程镜像是最先进的数据库备份解决方案
      • 也是最昂贵的！远程镜像的技术水平超过了远程日志处理和电子链接。
      • 用远程镜像时，实时数据库服务器在备份站点进行维护
• 18.4 灾难恢复计划开发
  • 一旦为组织建立业务单元优先级并获得合适的备份恢复站点的办法，就该起草实际的灾难恢复计划了
  • • BCP主要关注业务的持续
    • DRP针对所有措施不起作用，必须有人宣布（高级管理层）进入灾难模式后启用
    • BCP、DRP人员都是最重要的
    • 都基于BIA
  • 在最终形成书面文档前， DRP 团队可能要反复修改文档，以满足关键业务单元的运营需求
  • 该计划还应考虑灾难恢复预算和可用人员对资源、时间和费用的限制
  • 要考虑的文档类型
    • 执行概要，提供对计划的高度概括
    • 具体部门的计划
    • 对负责实现和维护关键备份系统的 IT 技术人员的技术指南
    • 对灾难恢复团队人员的检查
    • 灾难恢复团队重要成员准备的完整计划副本
  • 18.4.1 应急响应
    • 灾难恢复计划中应当包含重要人员在识别出灾难或灾难即将来临时应立即遵守的简单清晰的指令
    • 应急响应计划通常以检查表的形式放在一起，交给响应者
    • 在设计这些检查表时，需要记住一条重要的设计原则：对检查表的任务进行优先级安排，最重要的任务排在第一位！
    • 记住确保这些检查表将在危机发生时被执行
    • 在这些基本任务中，有一项是正式宣布灾难
    • 建筑物火灾的响应检查表通常包括下列步骤：
      • (1) 启动建筑物警报系统。
      • (2) 确保有序撤离
      • (3) 如果可能，可以尝试用灭火器或其他灭火设备扑灭火灾
      • (4) 离开建筑物后，使用移动电话呼叫紧急服务号码（在美国范围内是 911) ，以确保应急 机构接到警报通知
      • (5) 确保受伤人员接受适当救护。
      • (6) 启动组织的灾难恢复计划，以确保业务运营的连续性。
  • 18.4.2 职员和通信
    • 灾难恢复计划中还应该包括一份人员列表，以便在发生灾难时进行联络，BCP管理协调人
    • 这份响应检查表应该包括备用的联系方式（如手机号码、呼机号码等），每一个角色还要有一个通讯录备份，以防联系不上主要联系人或其出于某种原因不能到达恢复场所的情况。
  • 18.4.3 评估
    • 当灾难恢复团队抵达现场时，他们的首要任务之一就是评估现状
  • 18.4.4 备份和离站存储
    • 备份在灾难恢复计划中起着重要作用。它们是存储在磁带、磁盘、云或其他介质上的数 据拷贝，是最后的恢复选项
    • 完整备份： 顾名思义，完整备份存储着受保护设备包含的数据的整个副本，一旦完整备份完成，每个文件的归档位都会被重置、关闭或设为 0
    • 增量备份：增量备份只复制那些自最近一次完整备份或增量备份以来修改过的文件。一旦增量备份完成，被复制的文件的归档位都会被重置、关闭或设为 0 。
      • 完整备份+增量备份
        • 优点，速度快，空间占用小
        • 缺点：恢复慢
    • 差异备份
      • 差异备份复制那些自最近一次完整备份以来修改过的所有文件
        • 完整备份+差异备份
          • 优点：数据恢复快
          • 缺点：速度慢，存储空间占用大
      • 增量备份和差异备份之间最重要的差异在于发生应急事件时还原数据所需的时间
      • 完整备份和增量备份不同的是，差异备份过程并不改变归档位。
    • 备份解决方案
      • 1. 磁盘到磁盘备份
        • 在过去 10 年中，磁盘存储变得越来越便宜
        • 许多备份技术是围绕磁带范式设计的。虚拟磁带库(VTL)通过使用软件把磁盘存储虚拟 成磁带，使备份软件可使用此型号的磁盘。
        • 磁盘需要异地保存
      • 2. 最佳备份实践
        • 备份数据会随着时间的推移而增加，导致每次执行备份时备份（和还原）过程都比之前 花费更长的时间，并且每次备份会占用更多的存储空间
        • 为避免定期备份存在的问题，可以部署某些实时连续的备份形式，例如 RAID、 集群或服务器镜像
        • 仅在备份中包含必要的信息
        • 最后，请记住测试组织的恢复流程，经常出现的情形是，备份软件报告备份成功而恢复 尝试却失败了，然而检测到有问题时已经太晚了。这是备份失败的最大原因之一
      • 3. 磁带轮换
        • 备份常用的几种磁带轮换策略包括：祖父－父亲－儿子(grandfather-father-son, GFS)策略、汉诺塔策略以及六带轮换策略
        • 也可通过使用商用备份软件或全自动分层存储管理(hierarchical storage management, HSM)系统来自动实现这些策略。
        • HSM 系统是自动的机械备份换带机，由 32 或 64 个光学或磁带备份设备组成。 HSM 系统中的所有驱动元件都被配置为单个驱动器阵列（有些像 RAID) 。
  • 18.4.5 软件托管协议
    • 软件托管协议是一种特殊的工具，当软件开发商未能为产品提供足够的支持或软件开发 商破产而造成产品失去技术支持时，该协议可使公司免受影响。
    • 最终用户和开发商之间的协议具体定义了什么是“触发事件”，如开发商无法满足服务水平协议(SLA)条款或开发商破产
  • 18.4.6 公用设施
    • 组织要依靠一些公用设施来提供自身基础设施的关键要素，如电力、 水、天然气和管道服务等
    • 因此，灾难恢复计划中应该包含联系信息和措施，以解决这些服务在灾难发生过程中出现的问题。
  • 18.4.7 物流和供应
    • 面临调拨大量人员、设备和供应物资到备用恢复站点的问题
    • 恢复团队会负责给他们提供食物、水、避难所和适当的设施
  • 18.4.8 恢复与还原的比较
    • 灾难恢复团队成员可操作的时间很短，他们必须尽可能迅速地应用 DRP 并还原 IT 能力
    • 抢救团队必须确保新的 IT 基础设施的可靠性
    • 恢复：涉及将业务运营和流程还原至工作状态
    • 还原：步及将业务设施和环境还原至可工作状态。
• 18.5 培训、意识与文档记录
  • 与业务连续性计划一样，必须对所有涉及灾难恢复工作的人员进行培训
  • 培训计划考虑因素
    • 对全体新员工进行入职培训。
    • 对第一次担任灾难恢复角色的员工进行初始培训。
    • 对灾难恢复团队的成员进行详细的再培训。
    • 所有的其他员工进行简要的意识培训（可以作为会议的一部分或通过电子邮件新闻之类的形式发给所有员工）。
  • 灾难恢复计划还应该进行完整的文档记录。
  • DRP 应被视为极其敏感的文档，并且只在职责分离和因需可知的基础上提供给个人
• 18.6 测试与维护
  • 每一种灾难恢复计划都必须定期进行测试，以确保计划的条款是可行的并且符合组织变 化的需求
  • 5 种主要的测试类型
    • 通读测试
    • 结构化演练
    • 模拟测试
    • 并行测试
    • 完全中断测试
  • 18.6.1 通读测试
    • 通读测试(read-through test)：是其中最简单的，但也是最重要的一种测试。
    • 只需要向灾难恢复团队成员分发灾难恢复计划的副本，并要求他们进行审查，文档审查
    • 三个目标：
      • 划确保关键人员意识到他们的职责并定期复习知识。
      • 为人员提供了审查计划中过时信息的机会，并根据组织的变化更新需要修改的内容。
      • 在大型组织中，计划有助于标识这样的情况：重要的人员已经离开公司，并且没有人 负责重新分配他们的灾难诙复职责，这也是应该将灾难恢复职责纳入岗位描述的重要原因
  • 18.6.2 结构化演练/桌面演练
    • 结构化演练(structured walk-through)：执行进一步的测试
    • 在这种经常被称为＂桌面演练”的测试类型中，灾难诙复团队成员聚集在一间大会议室中，不同的入扮演灾难发生时的不同角色。
    • 结构化演练的范围和意图可能有所不同。一些演练包括采取物理动作或至少考虑其对演练的影响。例如，结构化演练可能要求所有人离开大楼，回家参加演练。
  • 18.6.3 模拟测试
    • 模拟测试(simulation test)：与结构化演练类似。模拟测试向灾难恢复团队成员呈现情景并要求他们做出适当的响应
    • 这种测试可能会中断非关键的业务活动并使用某些运营人员。消防演习
  • 18.6.4 并行测试
    • 并行测试(paralleI test)：表示下一个层级的测试，涉及将实际人员重新部署到备用恢复站点并实施站点启用过程
    • 测试不会中断主要设施的运营，这个站点仍然处理组织的日常业务。
  • 18.6.5 完全中断测试
    • 完全中断测试(full-interruption test)：与并行测试的操作方式类似，但涉及实际关闭主站点的运营并将其转移至恢复站点
    • 这类测试有很大的风险，因为它们要求中断主站点的运营，并转移到恢复站点
    • 完全中断侧试非常难以安排，通常会遇到来自管理层的阻力。
  • 18.6.6 经验教训
    • 在任何灾难恢复行动或其他安全事件结束后，组织应举行一次总结经验教训的会议。
    • 总结经验教训的最常见方式是把所有人召集起来，或通过视频会议或电话将他们联系起来，并邀请训练有素的主持人主持会议。
    • 总结经验教训的过程。这些问题包括：
      • 到底发生了什么？什么时候发生的？
      • 员工和管理层在处理事件方面表现如何？
      • 否遵循了文件化的程序？
      • 程序是否足够？
      • 是否采取了可能阻碍恢复的步骤或行动？
      • 下次发生类似事件时，员工和管理层会采取哪些不同的措施？
      • 如何改进和其他组织的信息共享？
      • 哪些纠正措施可以防止将来发生类似事件？
      • 未来应注意哪些前兆或指标来检测类似事件？
      • 需要哪些额外的工具或资源来检测、分析和抑制未来的风险事件？
  • 18.6.7 维护
    • 记住，灾难恢复计划是一份活的文档。随着纠织需求的变化，必须对灾难恢复计划进行 修改以适应这些变化，需要纳入变更管理流量
    • 灾难恢复计划编制人员应当借鉴组织的业务连续性计划，把它用作恢复工作的模板
    • 大多数组织都应用正式的变更管理流程，这样在 IT 基础设施发生变更时就能更新和检查 所有相关的文档，以便反映变更