当企业内的关键系统发生故障时，最困难的环节在于知道应先恢复什么、谁拥有执行恢复的访问权限、哪个备份可以信任，以及在没有该系统的情况下企业还能维持运转多久。
许多中小型企业（SMB）正是在这里发现了拥有备份与拥有实际恢复套餐之间的差距。备份可能包含您需要的数据，但它不会决定恢复顺序、分配职责、验证恢复是否有效，也无法解决中断期间缺少管理员凭证的问题。
IT 灾难恢复套餐可在中断发生前为这一流程提供结构。它定义了哪些系统最重要、需要多快将其恢复、企业可以容忍多少数据丢失、应实施何种数据丢失防护策略、由谁负责每个恢复步骤，以及如何保护关键凭证。这种清晰性可以防止 IT 事件演变为长时间停机、收入损失或更大范围的运营危机。
什么是 IT 灾难恢复套餐？
IT 灾难恢复套餐是一套记录在案的流程，用于在中断发生后恢复技术系统。它关注企业的 IT 层面：数据、应用、设备、基础设施、云服务、管理员访问权限、备份，以及负责恢复工作的人员。
一份实用的 IT 恢复套餐应回答以下问题：
- 哪些系统必须最先恢复？
- 企业能容忍多长时间的停机？
- 可以接受多少数据丢失？
- 备份存储在哪里？
- 谁可以恢复系统？
- 需要哪些管理员凭证？
- 团队将如何确认已恢复的系统安全且可用？
- 如果主要频道无法使用，企业将如何与员工和客户沟通？
灾难恢复套餐不应只针对网络攻击，还需涵盖硬件故障、凭证丢失和意外删除等日常问题。此外，还应涵盖外部服务中断，例如云平台或 SaaS 工具中断、配置错误，以及关键员工离职时未移交关键访问权限的情况。
恢复机制不能等到中断发生时才临时设计。它需要在企业依赖它之前就完成规划、指定负责人、进行沟通并加以测试。
业务连续性与 IT 灾难恢复的区别
业务连续性和 IT 灾难恢复常被视为同一回事，但二者解决的是不同的问题。
业务连续性关注的是让公司在中断期间持续运营，涵盖客户沟通、临时工作流程、员工职责、供应商协调，以及哪些服务需要在正常系统不可用时仍继续运行等决策。
IT 灾难恢复则聚焦于支撑这些工作的技术层面，定义如何恢复系统、数据、应用、备份和管理员访问权限，使企业能够安全地回归正常运营。
以 CRM 中断为例。业务连续性套餐可以说明销售或支持团队如何在 CRM 不可用时继续服务客户，而 IT 恢复套餐则说明由谁联系供应商、需要恢复哪些数据、有哪些备份或导出可用、需要哪些凭证，以及团队如何确认系统可以安全地重新使用。
对许多中小型企业 (SMB) 而言，这种差距只有在事件发生时才会显现。大家知道由谁联系客户，却不知道谁能恢复计费系统；知道备份存在，却不知道恢复操作是否曾经过测试；知道平时由某位员工负责 IT，却不知道此人不在时该如何应对，或者此人失联时管理员密码存储在何处。
您的 IT 灾难恢复套餐必须涵盖的内容
完善的 IT 灾难恢复套餐不必过于冗长，但必须足够具体，以便在紧张的局势下能够照此执行。
恢复时间目标
恢复时间目标 (RTO) 定义系统需要多快完成恢复。支付系统可能需要在数小时内恢复，而内部报告仪表板则可以容忍更长的中断.
应根据业务影响而非技术偏好来设定 RTO，因为停机的代价既是业务问题也是技术问题。应评估哪些系统会影响收入、客户承诺、法律义务、安全和员工生产力。
恢复点目标
恢复点目标 (RPO) 定义可接受的数据丢失量，这有助于制定合适的数据丢失防护 (DLP) 策略。如果某个系统的 RPO 为一小时，备份或复制就需要支持恢复到大致该时间点。
如果 RPO 为一天，就意味着企业接受了更大的数据丢失区间。RPO 还有助于确定备份频率，因为 RPO 越短，备份就需要越频繁。因此，关键系统的备份频率需要高于低优先级系统。
系统优先级层级
并非所有系统都应同时恢复。小型企业的灾难恢复套餐应将系统划分为不同的优先级层级。
- 第 1 层：核心运营、安全、通信或收入所必需的系统。
- 第 2 层：可以容忍短时间停机的重要系统。
- 第 3 层：可在企业恢复稳定后再行恢复的低优先级系统。
典型的第 1 层系统可能包括电子邮件、身份提供商、密码管理器、财务系统、客户数据库、云存储空间和通信平台。
备份策略
您的备份策略应定义：
- 备份哪些内容以及备份频率
- 备份存储在何处
- 谁可以访问这些备份
- 如何测试恢复操作
NCSC 还发布了（新窗口）适用于云端和本地备份解决方案的抗勒索软件备份原则，并指出备份的数据默认并不具备抗勒索软件能力，应根据勒索软件威胁对其进行评估。
完善的备份策略通常包括对关键数据采用离线或不可变备份、定期测试、记录在案的恢复步骤，以及用于备份管理的独立凭证。
角色与职责
灾难恢复套餐应明确负责人，而不仅仅是任务。如果所有恢复知识都掌握在一个人手中，企业就同时面临人员风险和 IT 风险。应明确由谁：
- 领导恢复工作
- 恢复系统
- 联系供应商
- 批准紧急访问
- 进行内部沟通
- 记录决策
您的 IT 灾难恢复套餐需要定义的内容
| 组成部分 | 解答的问题 |
| RTO | 每个系统需要多快完成恢复？ |
| RPO | 企业能承受丢失多少数据？ |
| 优先级层级 | 哪些系统最先恢复，哪些可以延后？ |
| 备份策略 | 备份哪些内容、存储在何处，以及是否测试过恢复操作？ |
| 角色与职责 | 由谁领导恢复工作、恢复系统、联系供应商并批准紧急变更？ |
凭证恢复：容易被忽视的灾难恢复场景
灾难恢复通常聚焦于数据、服务器和备份。但在实践中，恢复之所以失败，可能是因为团队无法访问恢复运营所需的系统。
凭证恢复要问的问题是：
- 谁拥有管理员帐户的访问权限？
- 备份凭证存储在哪里？
- 哪些帐户可以恢复关键系统？
- 如果密码丢失、已泄露或掌握在无法联系的人手中，该怎么办？
- 紧急凭证是否受到保护并经过审查？
- 访问权限能否被快速撤销和重新分配？
如果备份凭证存储在某个员工的浏览器中、恢复码保存在私人笔记里，或者共享的管理员密码通过聊天工具传播，企业在事件发生时可能无法顺利恢复。
企业密码管理器有助于降低这种风险：它将关键凭证集中存储在加密保险库中、按角色分配访问权限，并在有人离职或职责变更时更轻松地撤销或重新分配访问权限。Proton Pass for Business 可帮助团队生成强密码、安全存储凭证、使用安全分享，并让敏感访问权限远离聊天记录和电子表格。
作为面向 IT 团队的密码管理器，Proton Pass 支持集中式凭证管理、密码策略、安全分享、报告和日志、SCIM 预配以及 SSO 集成。这使得凭证恢复更易于管理，因为对关键系统的访问不再依赖于某个人、某个浏览器配置文件或某个未记录在案的密码。
灾难恢复套餐模板
当灾难恢复套餐足够具体、能够在中断期间指导行动，同时又足够简洁、便于团队在压力下使用时，它才能发挥最大作用。对中小型企业而言，模板应聚焦于要点：需要恢复什么、多快恢复、从哪个备份恢复、由谁执行，以及使用哪些凭证。
1. 范围
定义该套餐涵盖哪些系统、服务、位置、设备和数据。
模板文案： 本 IT 灾难恢复套餐涵盖在技术中断发生后恢复 [Company Name] 关键运营所需的系统、数据、服务、凭证和供应商。
2. 关键系统清单
列出企业所依赖的系统，并分配优先级层级。
模板文案： 关键系统将根据业务影响、恢复时间目标、恢复点目标以及对其他系统的依赖关系，归入第 1 层、第 2 层和第 3 层。
3. 恢复目标
为每个优先系统定义 RTO 和 RPO。
模板文案： 每个系统都必须有记录在案的恢复时间目标和恢复点目标。这些目标应至少每年审查一次，并在重大系统变更后进行审查。
4. 备份和恢复流程
记录备份存储在何处、运行频率、谁可以访问，以及恢复测试如何进行。
模板文案： 备份必须防止未经授权的访问，在适当情况下与主要系统分开存储，并按定期计划进行测试。第 1 层系统的恢复程序必须有书面记录。
5. 凭证与访问权限恢复
定义关键凭证存储在何处，以及恢复期间谁可以访问这些凭证。
模板文案： 灾难恢复所需的管理员凭证、备份凭证、恢复码和供应商访问权限必须存储在经批准的加密保险库中。访问权限必须仅限于经授权的角色，并在角色变更、离职和恢复演练后进行审查。
6. 角色与上报机制
定义恢复负责人、替补人员和上报路径。
模板文案： 每个恢复角色都必须有一位主要负责人和一位替补负责人。该套餐必须明确由谁领导恢复工作、由谁恢复系统、由谁联系供应商、由谁传达更新信息，以及由谁批准紧急变更。
7. 沟通套餐
定义在 IT 中断期间企业如何进行内部和外部沟通。
模板文案： 在恢复事件期间，内部更新将通过 [获批频道] 分享。面向客户、供应商、保险机构或监管机构的外部沟通必须经 [角色/团队] 批准。
8. 测试与审查频率
定义该套餐的测试和更新频率。
模板文案： 本灾难恢复套餐将至少 [每年/一年两次] 进行测试，并在发生重大事件、系统变更、供应商变更或恢复演练失败后进行审查。
如何测试您的 IT 灾难恢复套餐
灾难恢复套餐只有在接近真实中断的条件下经过测试，才能真正发挥作用。存在但从未恢复过的备份仍只是一种假设。只有一个人理解的恢复角色仍只是一种依赖。中断期间谁也找不到的管理员凭证仍是一个阻碍因素。
测试起初无需复杂。对大多数中小型企业而言，目标是证明企业能够在现实可行的时间内，由合适的人员使用正确的凭证恢复正确的系统。
1. 桌面演练
选择一个可能发生的场景，例如勒索软件影响共享文件、云存储空间中断、客户数据被意外删除，或管理员帐户访问权限突然丧失。逐步推演团队在第一个小时会做什么、由谁领导、会联系哪些供应商、哪些系统会被优先处理，以及会缺少哪些信息。
2. 测试恢复操作
选择一个关键文件、数据库、邮箱或系统导出内容，确认其可以恢复到可用状态。检查恢复的数据是否足够新、权限是否仍然有效，以及团队是否知道备份存储在哪里.
3. 定期测试
作为切实可行的基础要求，中小型企业应至少每年测试一次该套餐，以符合 NIST 在特别出版物 800-34 第 1 版（新窗口）中的指导意见，并在重大系统或供应商变更后更频繁地进行测试。
4. 测试凭证恢复
确认经授权的人员无需依赖某个员工的浏览器、私人笔记或记忆，即可访问备份管理员帐户、云管理员帐户、供应商门户、恢复码和紧急凭证。目的不是不必要地暴露敏感密码，而是确认访问模式在企业承压时仍然有效。
每次测试后，记录哪些环节失败、哪些环节耗时过长，并为每项修复指派具体人员和截止日期。好的测试并非一切顺利的测试，而是能在企业还有时间弥补时揭示差距的测试。
围绕系统、数据和访问构建恢复机制
实用的 IT 灾难恢复套餐为企业提供恢复顺序、一组负责人、对可接受停机时间的现实评估，以及维持业务连续性并重新获得对维持工作运转的系统的访问权限的方法。
对中小型企业而言，这可能决定了中断是短暂还是持久。如果电子邮件、财务软件、云存储空间、客户系统或管理员帐户不可用，团队需要知道什么优先处理、谁可以采取行动，以及安全恢复访问权限需要哪些凭证。
这正是恢复规划应将系统、数据和访问权限统筹考虑的原因。备份也许能恢复文件，但凭证才是让团队重新获得恢复所需系统控制权的关键。管理员登录凭证、供应商门户、备份帐户、恢复码和共享的运营凭证都需要受到保护、妥善整理，并在出现问题时可供合适的人员使用。
企业密码管理器有助于加强套餐的这一部分。将关键凭证存储在加密的密码保险库中并仅与经授权的人员分享后，企业在恢复事件期间对某个员工的浏览器、私人笔记或记忆的依赖就会降低。
