异构技术栈、勒索软件和 ITaaS：灾难恢复的噩梦

灾难恢复变得越来越困难，因为 IT 环境横跨本地设备、公共云、SaaS 和第三方 ITaaS 供应商。现在导致系统宕机的主要原因已不再是洪水或火灾，而是勒索软件成为了首要威胁，其破坏系统的速度比任何自然灾害都快。

这使一件事变得更加明确：IT 环境越同质化和标准化，从灾难中恢复就越容易——无论灾难的起因是什么。

如果你使用自己的基于 x86 的服务器，将应用程序部署为虚拟机或容器，并且网络和存储都是软件定义的，那么你就有机会应对灾难。在发生故障时，你可以故障转移到二级数据中心——可以是你自己的数据中心，也可以是配置为复制你的基础设施的公共云环境。

但成功完全取决于你如何严格地保持环境同步：实时或近实时复制所有更改，并定期测试故障转移和故障恢复，以确保它们能够正常工作并满足恢复时间目标。

对于完全采用公共云并在不同区域使用二级部署的组织来说，同样的原则也适用。公共云提供商负责维护和运营其基础设施。如果你不完全信任单个提供商的灾难恢复 (DR) 能力，可以与不同的云供应商建立二级站点以获得额外保护。

ITaaS：你的 DR 计划止步于供应商的起点

你越是偏离这种理想化的同质环境，DR 难度就会越大，从而扩大你在灾难易发区域的影响范围。有两个特别令人关注的领域：IT 即服务 (ITaaS) 和勒索软件。两者结合可能会带来巨大的麻烦。

ITaaS 模式对灾难恢复构成严重风险，因为你实际上是将 DR 责任移交给第三方提供商。顾名思义，ITaaS 不仅仅是租用云服务或订阅软件，而是将整个 IT 功能外包给其他人，比如外部 IT 服务提供商。

当发生中断时，在其技术栈中使用 ITaaS 的组织特别容易受到影响，因为他们依赖于下游供应商，这些供应商可能声称提供强大的 DR，但在关键时刻往往表现不佳。如果没有严格的、合同规定的恢复要求，你完全依赖于供应商声称已部署的内部计划。

而当灾难是恶意软件而不是物理故障时，整个恢复过程变得更加复杂；这既是事件响应也是灾难恢复。基础设施可能仍在运行但不可信任。扫描以检测受感染的计算机和损坏的数据是恢复的第一步（如果你能信任扫描结果的话），然后是擦除或更换系统、重新安装干净的软件，并从不可变的备份库中恢复干净的数据。

如果你使用 ITaaS，你要依赖你的供应商在紧急情况下知道该怎么做，在其做出反应和修复时及时通知你，并协助你在环境中进行任何需要的清理工作。如果你只运行自己的基础设施，好消息是你更能掌控局面；坏消息是，你有更多工作要做。

这些任务绝非易事。根据你的防病毒防护措施，识别恶意软件是如何进入你的网络以及它是什么类型，以便追踪、停止并在未来阻止它，可能会很困难。如果没有全面、最新和不可变的备份，在数 PB 甚至 EB 的块存储、文件存储和对象存储中筛选并恢复好的数据将非常困难。这不仅包括你的本地工作负载，还包括公共云平台和 SaaS 应用程序中的数据。

而且，再次强调之前的观点，如果你的 ITaaS 提供商本身遭受恶意软件攻击，你自己的运营可能会受到严重影响——这是他们系统受损带来的连带损害。

当你将关键应用程序和数据外包给缺乏记录或弹性测试的小众提供商时，风险更高。与多年来一直在抵御攻击和应对硬件故障的成熟 SaaS 巨头不同，较小的 SaaS 供应商没有应对灾难的记录。英国 NHS 和美国医疗运营商已经多次惨痛地吸取了这个教训。

血液、故障和备份：NHS 如何惨痛地吸取教训

2024 年 6 月，在外包供应商 Synnovis 遭受 Qilin 勒索软件团伙攻击后，伦敦两个 NHS 地区的血液病理服务陷入停顿。影响波及医院，导致治疗和手术延迟。在攻击发生约三周后，超过 2,194 个门诊预约和 1,134 个择期手术被推迟。

Synnovis 是 NHS 病理服务和拥有超过 27,000 名员工的德国诊断巨头 SYNLAB 的合资企业。该公司将多个本地病理系统整合在统一的实验室信息管理系统 (LIMS) 下。

尽管在英国遭受攻击时已配备首席信息安全官和安全运营中心，表现出对业务连续性的重视，但 SYNLAB 在欧洲的其他业务此前已遭受勒索软件攻击，例如 2024 年 4 月在意大利的遭遇。

NHS 因其 ITaaS 供应商遭受攻击而受害。任何外包关键功能的医疗保健提供商——无论是血液病理还是保险支付处理——都面临类似风险。

例如，同样在去年 4 月，Octapharma Plasma 在遭受网络攻击后被迫暂时关闭其在美国的 150 多个血浆捐献中心，导致全国血浆收集中断和手术取消。三个月后，在供应商 OneBlood 遭受勒索软件攻击后，阿拉巴马州、佛罗里达州、乔治亚州和卡罗来纳州的约 350 家医院经历了血液供应中断。

美国医院协会发言人总结了日益增长的担忧："我们继续强烈建议医院和医疗系统识别所有生命攸关和任务关键的第三方服务和供应链提供商，并制定业务和临床连续性程序以及供应链弹性计划，以维持 30 天或更长时间失去这些关键服务和供应的情况。"

另一个美国的例子：UnitedHealth Group 的数据处理公司 Change Healthcare 在去年 2 月遭受勒索软件攻击。作为每年处理 150 亿healthcare交易的主要处理商，这次入侵扰乱了美国数十万医生、医院和药房的保险理赔和支付。

虽然初步恢复工作在几周内就开始了，但许多医疗保健提供商在几个月内都在应对财务和运营挑战。UnitedHealth Group 已提供数十亿美元的临时财务援助，完全恢复工作仍在继续。

这里的重要教训适用于所有 ITaaS 供应商和客户——不仅仅是医疗保健领域。许多 ITaaS 供应商和他们的上游客户的灾难恢复计划要么不够充分，要么过分关注物理事件，而不是勒索软件或其他形式的恶意软件等数字威胁。如果这些计划存在的话，往往植根于传统思维：硬件故障、数据中心中断或自然灾害。

对供应商而言，没有什么能替代强大的、不可变的备份、在良好安全状态下重新部署应用程序的计划，以及经过测试的恢复程序（涵盖物理和网络事件）。灾难恢复计划需要包括详细的操作手册，以应对直接攻击和上游故障造成的连带损害。

客户也必须在自己的 DR 规划中考虑第三方灾难，特别是当他们依赖 ITaaS 进行关键任务操作时。是的，这需要成本。是的，当你外包 IT 以节省成本时，这很令人沮丧。但忽视它可能会付出更大的代价。

这并不是说完全自己管理基础设施就能免受攻击并且容易恢复。但至少你有完全的控制权和可见性，尽管也需要实施上述所有措施。而且你知道它已经实施。ITaaS 可能带来好处，但你可能会以艰难的方式发现你的提供商并不像你希望的那么靠谱，所以在制定 DR 计划时要考虑这一点——或者与你的提供商沟通。

你的 DRaaS 供应商可能无法覆盖你的实际灾难

有许多灾难恢复即服务（DRaaS）供应商，Gartner 的 Peer Insights 列表中有 63 个。

例如，Cohesity 提供带有 SiteContinuity 编排和 FortKnox（一个用于防范勒索软件的离线不可变保管库）的 DR 服务。Rubrik 为混合环境提供类似的快速恢复工具。

HPE 的 Zerto 保护跨本地、AWS 和 Azure 的 VMware 和 Hyper-V 工作负载。它还声称支持一些 SaaS 应用程序，包括 Active Directory、Microsoft 365、Dynamics 365、Power BI 和 Google Workspace，但覆盖范围取决于设置，可能需要额外配置。如果你的技术栈超出该列表，你需要其他选择。

Veeam 通过云合作伙伴提供 DRaaS，但仅适用于已由 Veeam 保护并复制到提供商基础设施的工作负载。当勒索软件袭击加拿大东安大略卫生部门时，其预配置的 Veeam 设置在不到两小时内就恢复了核心系统，这得益于精简的 VM 环境和随时可用的云备份。

你的 CIO 不想听到的三个硬道理

这里的一个普遍教训是：IT 环境越同质化，就越容易防范灾难。所有 DRaaS 供应商都会有不同程度的同质化要求。

此外，数据保护供应商只能保护他们能备份的内容，而这很少是全部。根据我们的经验，认真对待本地灾难恢复的组织倾向于迁移到主流的虚拟化或容器化应用程序，这些应用程序在设计上就兼容云，在需要时可以在云中运行。

第二个教训是要非常非常认真地对待勒索软件。假设你和你的 IT 供应链供应商会受到攻击，并准备经过测试的恢复计划和经验证的不可变备份。

第三个教训是，抱歉一再强调这点，你必须监督你的 ITaaS 供应商，要求他们有有效的 DR 计划，并验证他们的恢复程序。不要只是信任，要验证——如果你无法验证，那就不要信任。