读红蓝攻防：技术与策略30业务连续性计划

1. 业务连续性计划

1.1. Business Continuity Plan，BCP
1.2. 重点是确保企业在安全事件或灾难发生后能够存活

• 1.2.1. 重点是确保业务在灾难发生后能够存活下来
  

1.3. BCP是一个包含预防和恢复措施的系统，企业采取这些措施是为了使组织能够幸免于难
1.4. 旨在保护一个组织的人员和所有信息资产
1.5. 为了使BCP有效，它需要在现场环境中进行彻底的测试，模拟各种安全事件，并确定计划在这种情况下如何运作

• 1.5.1. 测试是至关重要的，因为它使一个组织能够确定其计划的有效性，并纠正系统中的潜在问题或错误
  

1.6. 业务持续开发计划

• 1.6.1. 包括建立一个系统的所有活动，该系统旨在帮助组织预防安全事件，并在发生灾难或安全事件的情况下成功恢复业务
  
• 1.6.2. 业务连续性计划需要对所有可能影响企业运营的风险进行定义
  
• 1.6.3. BCP是组织风险管理战略的重要组成部分
  
• 1.6.4. 流程
  
  
  
  • 1.6.4.1. 确定所有已识别的风险可能如何影响业务
    
  • 1.6.4.2. 实施所有必要的保障措施和程序，以帮助组织减轻已识别的风险
    
  • 1.6.4.3. 测试所有制定的保障措施和程序
    

    1.6.4.3.1. 这可以确保所制定的措施确实有效
    

    
    
  • 1.6.4.4. 审查流程以确保它们是最新的
    
  
  
• 1.6.5. BCP的重要性是巨大的
  
  
  
  • 1.6.5.1. BCP试图减轻的威胁可能导致收入损失、利润减少或严重损失
    
  • 1.6.5.2. 保险通常有助于减轻灾害
    
  
  
• 1.6.6. 业务连续性计划是事先设想好的，其制定必须包括组织中所有关键利益相关者的投入
  
• 1.6.7. BCP与DRP（灾难恢复计划）不同：DRP被认为是整个BCP的一部分
  
  
  
  • 1.6.7.1. 虽然DRP的重点是IT系统，但BCP也会处理自然事件，如火灾、疾病暴发等
    
  
  

1.7. 制定业务连续性计划

• 1.7.1. 业务影响分析
  
  
  
  • 1.7.1.1. 在这一步骤中，组织将设法确定公司的所有功能和资源，特别是那些对时间敏感的功能和资源
    
  
  
• 1.7.2. 恢复过程
  
  
  
  • 1.7.2.1. 在这一步骤中，重点是让企业重新上线或重新工作，首先从最关键的功能开始恢复
    
  
  
• 1.7.3. 组织
  
  
  
  • 1.7.3.1. 在这一步中，企业将组建一个业务连续性团队
    
  
  
• 1.7.4. 员工培训
  
  
  
  • 1.7.4.1. 在此步骤中，将为在前一步中组建的业务连续性团队成员提供培训，以确保他们有足够的能力制定有效的计划，并测试计划以确保其按预期工作
    
  • 1.7.4.2. 该团队在培训后进行测试，他们也将在BCP本身的测试期间发挥作用
    
  
  

1.8. 制定一份恢复期间所需项和资源的检查清单

• 1.8.1. 该清单将包括紧急情况下的联系人、业务连续性小组在恢复过程中需要的所有资源清单、重新启动业务所需的备份数据和文件的位置，以及在此期间所有重要人员的名单等细节
  

1.9. 创建有效业务连续性计划的7个步骤

• 1.9.1. 监管审查和状况
  
  
  
  • 1.9.1.1. 制定BCP的第一步是检查监管内容，并确定有什么样的法规会影响BCP的创建过程
    
  • 1.9.1.2. 包括联邦机构和政府、州政府或管理该组织所在行业的行业特定法规部门
    
  
  
• 1.9.2. 风险评估
  
  
  
  • 1.9.2.1. 这是创建BCP的第二步，它需要对整个组织进行风险评估
    
  • 1.9.2.2. 为了帮助识别业务风险以及潜在的业务中断，然后根据其发生后对组织的影响和严重程度进行优先排序
    
  • 1.9.2.3. 几乎不可能涵盖所有的业务风险
    
  
  
• 1.9.3. 业务影响分析
  
  
  
  • 1.9.3.1. 创建BCP的第三步是进行业务影响分析
    
  • 1.9.3.2. 影响：中断对企业的每个流程和功能的各种影响
    
  • 1.9.3.3. 丢失业务流程的时间点将导致以下影响：业务影响取决于时间等因素
    
  
  
• 1.9.4. 制定战略和发展规划
  
  
  
  • 1.9.4.1. 在仔细分析了所有的业务功能和这些业务功能的重要性之后，这一步涉及提出总体战略
    
  • 1.9.4.2. 对于每一个计划，都要用最大的停机时间来确定哪些是可以接受的，哪些是不可以接受的
    
  • 1.9.4.3. 目的是在每个业务功能和计划中容纳最大数量的停机时间
    
  
  
• 1.9.5. 创建事件响应计划
  
  
  
  • 1.9.5.1. 拥有一个完善的事件响应计划是所有业务的关键要求
    
  • 1.9.5.2. 目的是在面临业务中断时有明确的计划和行动指南
    
  • 1.9.5.3. 重要部分是与组织系统中使用的软件和硬件组件的各个供应商联系，以确定当事件发生时供应商将如何响应
    
  
  
• 1.9.6. 测试计划、培训员工和维护
  
  
  
  • 1.9.6.1. 这是创建BCP的第六步，围绕着测试计划以确保其正常运行和维护计划，其中包括在事件发生时为处理事件而设置的应急措施
    
  • 1.9.6.2. 定期的员工培训也是必要的，以确保他们了解安全事件发生时的计划和他们的角色
    
  
  
• 1.9.7. 沟通
  
  
  
  • 1.9.7.1. 这是创建BCP的第七步，也是最后一步
    
  • 1.9.7.2. 在完成上述所有步骤后，你需要就制定的BCP计划与所有相关利益相关者（内部和外部）进行沟通
    
  • 1.9.7.3. 计划的任何更新也应传达给利益相关者
    
  • 1.9.7.4. 任何将受到BCP影响的供应商或第三方都应该被提醒，因为他们在事件中起着关键作用
    
  
  

2. 灾难恢复最佳实践

2.1. 如果遵循某些最佳实践，构成灾难恢复计划一部分的前述流程可以取得更好的效果
2.2. 有一个异地位置来存储存档的备份

• 2.2.1. 云是安全异地存储的现成解决方案
  

2.3. 记录对IT基础设施所做的更改，以简化审查应急计划对新系统适用性的过程

• 2.3.1. 对IT系统进行主动监控，可以尽早确定灾难发生的时间，并启动恢复过程
  

2.4. 为服务器实施独立磁盘冗余阵列(Redundant Array of Independent Disk，RAID)是实现冗余的一种方式
2.5. 测试所做备份的完整性，以确保它们没有错误

• 2.5.1. 如果组织在灾难发生后意识到其备份有错误且毫无用处，那将令人失望
  

2.6. 组织应该定期测试从备份还原系统的过程
2.7. 内部部署

• 2.7.1. 快速行动
  
  
  
  • 2.7.1.1. 如果没有异地备份或可以将运营转移到的热点站点，攻击者可能只需要几分钟就能搞垮整个组织
    
  • 2.7.1.2. 灾难恢复小组应随时待命，随时响应任何事件
    
  • 2.7.1.3. 应该始终拥有可执行的灾难恢复计划以及快速访问组织网络和系统的方法
    
  
  
• 2.7.2. 复制备份
  
  
  
  • 2.7.2.1. 灾难期间的主要问题之一是数据的永久性丢失
    
  • 2.7.2.2. 组织应采用一种战略，将复制的备份保存在计算机或服务器以及外部磁盘上
    
  • 2.7.2.3. 备份应定期更新并安全保存
    
  
  
• 2.7.3. 定期培训
  
  
  
  • 2.7.3.1. 内部灾难恢复有效与否仅取决于其团队能否有效执行它
    
  • 2.7.3.2. 灾难恢复小组应该定期接受有关如何处理各类灾难事件的培训
    
  
  

2.8. 云上部署

• 2.8.1. 云已被用作业务连续性介质，可设置关键服务为在灾难期间将故障转移到云平台
  
• 2.8.2. 这可以避免停机，并让IT安全团队有足够的时间处理灾难事件
  
• 2.8.3. 定期备份上传
  
  
  
  • 2.8.3.1. 该组织的目标是实现从内部部署到云资源的无缝过渡，因此要求近乎实时地进行备份
    
  
  
• 2.8.4. 云冗余连接
  
  
  
  • 2.8.4.1. 洪水等内部灾难可能会影响电缆连接，从而使组织难以访问云资源，因此，组织应始终具有可补充有线连接的冗余连接设置
    
  
  
• 2.8.5. 冷备
  
  
  
  • 2.8.5.1. 预算紧张或业务流程可以承受几分钟或几小时停机的组织可以考虑冷备方法
    
  • 2.8.5.2. 重要系统和数据的副本保存在云中，但仅在发生灾难事件时激活
    
  • 2.8.5.3. 云备份可能需要一些时间来执行业务功能，但这通常是为了将云备份的成本保持在最低水平而做的一种权衡
    
  
  
• 2.8.6. 热备
  
  
  
  • 2.8.6.1. 这适用于预算不紧张并且希望在从内部部署系统转移到云时避免延迟的组织
    
  • 2.8.6.2. 热备是使备份系统保持运行并在灾难发生后立即执行关键业务流程的方式
    
  
  
• 2.8.7. 多站备
  
  
  
  • 2.8.7.1. 这适用于关键系统在任何灾难事件中都必须能够运行的组织，包括创建关键业务系统的冗余副本，并在跨不同地理区域托管的多个云平台上运行它们
    
  • 2.8.7.2. 这可确保关键系统在灾难事件期间实现最高级别的可用性
    
  
  

2.9. 混合部署

• 2.9.1. 好处在于，组织可以从内部部署和云资源的优势中获益
  
• 2.9.2. 快速转移到云站点
  
  
  
  • 2.9.2.1. 发生灾难事件时，最好将所有业务关键型运营都转移到云中以确保连续性并最大限度地减少中断
    
  
  
• 2.9.3. 快速恢复内部部署系统
  
  
  
  • 2.9.3.1. 如果快速恢复内部部署系统并将运营从云转回，这可能有助于将一些费用保持在较低水平
    
  
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！