加强运营复原能力，降低金融服务集中风险

本文以 我们之前的博客 为基础，该博客提供了有关如何在金融服务机构 (FSI) 中增强运营复原能力和管理集中风险的实用指导。

为确保与现有法规和即将出台的法规保持一致，我们在方法中纳入了 FIS 的main监管指南，包括关于运营复原能力主题的持续咨询。

包括：

• 金融稳定委员会 (FSB) 关于加强第三方风险管理和监督的咨询 (2023 年 6 月 22 日 FSB 咨询)
• 欧盟数字运营复原法案 (DORA)
• UK SS1/21：运营复原能力 与 SS2/21 外包和第三方风险管理
• 英国 CTP 制度：英国金融业的关键第三方 (PS16/24、SS6/24 & SS7/24)
• 美国关于第三方关系的跨部门指南
• 美国财政部关于云计算的报告
• 加拿大第三方风险指南
• 新加坡金融管理局成立云复原论坛
• 2021 IOSCO 外包原则

我们的方法与列出的出版物一致，并将随着时间的推移进行更新。 我们的目标是帮助客户按照现有和未来的 FSI 法规，以负责任且合规的方式进行成长和创新。

概述

在 FIS 中使用云技术时，作复原能力和集中风险是相互关联的，因为通过加强各种法规中的作复原能力来解决。 两者都涉及一系列广泛的措施，包括识别和监视关键第三方关系、加强风险治理和管理的要求，以及有关业务连续性和退出规划的指导。

我们的目标是帮助 FIS 解决和加强其运营复原能力，帮助他们以符合法规准则的方式管理企业级别的集中风险。 必须全面讨论本主题，并考虑到所有第三方关系。 必须维护云服务和本地软件产品上的依赖项的使用并保持安全。 此外，监管指南中通常也涉及与关键职能有关的分包问题。

在 2023 年 6 月 22 日 FSB 咨询中，关键服务被定义为服务，其故障或中断可能会显著损害金融机构的生存能力、关键运营或其履行关键法律和监管义务的能力。 在管理集中风险方面，主要关注这些服务。

集中必须与集中风险区分开来。 目前，许多关键 FSI 服务中都普遍存在第三方依赖项的集中，消除它可能不可行。 例如，如果你考虑金融信息网络的广泛使用 (例如彭博或汤森路透) 和软件发行商，如 IBM 和 Oracle，很明显，完全替代将是具有挑战性的。 可以为特定的第三方服务制定退出计划，但很难停止对大型金融机构使用第三方解决方案。 因此，重点应放在降低集中风险上，使其保持在组织的风险容忍度范围内。

虽然其中一些示例在系统上已经很重要，但它们通常并不被视为具有较高的集中度风险，因为它们分布在地理分散的多个位置。 因此，大多数故障只有有限的 (非全局) 影响。 它们还通过最先进的设计提供最高级别的复原能力，例如安全且可复原的作、自动化的使用以及零信任的实现。 这些设计已得到多个独立第三方通过各种认证流程的确认。 这一套集体措施已降低整体风险状况，尽管在企业层面，集中度仍然到位。

FIS 必须侧重于加强运营复原能力，并且必须以符合法规和准则的方式进行。 请务必注意，法规不会强制 FIS 部署混合或多云解决方案，而是采取原则性、基于风险和技术中性的方法来解决集中风险。 这些风险也可能存在于本地环境中。

除了作方面，法规还突出了与外包有关的非运营风险，特别是金融破产风险和解决方法。 非作风险不能通过技术措施进行管理，而是在合同阶段通过法律措施和援引退出战略来解决。

用于管理金融服务运营风险的 6 步方法

在对如何管理运营风险做出关键选择之前，必须考虑几个要素，这就是为什么我们引入了一种六步方法来应对集中风险和加强运营复原能力的原因：

步骤 1 - 更新云风险治理

目前，金融服务监管中的云技术主要受第三方外包准则的监管，这些准则特别适用于此上下文，不同的法规集适用于本地 ICT 环境。 如导言中所述，最近的磋商在 加强业务复原能力方面采取了整体方法。 例如，DORA 和 DORA ICT RMF 等法规草案不仅适用于本地，还将考虑使用 ICT 第三方服务提供商作为其框架的一个组成部分。

此外，如 2023 年 6 月 22 日 FSB 咨询中所述， 主要重点是关键服务。 我们也在 DORA 等其他法规中看到了这一点。 必须关注关键服务，否则，随着技术服务日益互联，待评估的服务范围会变得过于广泛。

因此，我们建议公司重新审视内部风险治理框架，并全面整合这些新的运营复原措施，重点关注关键服务，并纳入有关第三方或云外包的各种准则，以确保合规性。

在此上下文中要提出的一些适当问题包括：

1. 是否已定义明确的组织风险容忍度？
2. 哪些服务是业务关键服务？
3. 实际威胁场景对这些情况有何影响？
4. 我公司的整体风险偏好是什么？

风险治理框架还必须每年更新一次，以确保在快速发展的监管环境中持续合规。

引入的法规和指南与这些问题一致，作为加强运营风险的起点。 为了应对各个司法管辖区的这些要求，Microsoft创建了一组广泛的 金融服务合规性清单 ，以帮助客户在云技术使用方面对不同国家/地区的法规进行自我评估。 这些清单具有法规映射，并指出在评估Microsoft云技术的使用情况时相关的特定信息。

此外，Microsoft Cloud 合规性计划旨在帮助所有三道防线的风险和合规性功能，以遵守这些法规，并解决与云使用相关的整体风险。 该计划提供主动和被动功能，为风险利益干系人提供高级支持渠道。

步骤 2 - 识别浓度

与单个第三方提供商的服务集中程度越高，如果出现问题，不利影响的可能性就越大，这称为集中风险。 这种风险就是组织需要清楚地了解业务流程、ICT 平台、软件和第三方关系之间的所有依赖关系的原因。

映射这些依赖项通常作为业务影响分析的一部分执行， (BIA) 。 确定所有第三方关系并将其映射到关键用例后，就可以使用单个第三方提供程序确定关键服务的集中级别。 此视图使公司能够确定在管理集中风险时必须关注的位置。

对于Microsoft云服务，可以通过查看Azure 门户中的订阅和租户 ID 来确定关键工作负载的潜在集中度。 公司还可以 查看和筛选 Azure 资源信息 ，有助于详细了解组织中正在使用哪些服务。 此信息可导出，可与内部 BIA 信息相关联，以帮助实时识别关键依赖项。 对于 Microsoft 365，公司还可以在管理员中心生成有关购买许可证和活动的报告。

步骤 3 - 评估替代方案

一旦公司了解其依赖项及其与关键用例的关系，下一步就是解决相关的集中风险。 首先，确定可进一步深入调查的可行替代方案的简短列表。 你可能想要解决的问题包括：

• 本地、混合、多源和全云中存在哪些实用的替代方案？
• 每种方法的缺点和优点是什么？
• 他们的风险配置文件如何相互比较？ 每种替代方案的复原能力如何？
• 哪些最适合组织的风险偏好和云策略？
• 计划退出时，完全退出供应商是否可行且可取？ 可以考虑哪些替代方案？

集中风险是一个聚合术语，指出不良事件对一个或多个关键服务的影响更大。 在评估此类风险时，必须评估每个基础威胁方案，这反过来又导致一个微妙的视图，包括与服务集中相关的优缺点。 要考虑的威胁因素包括数据中心灾难、硬件故障、网络中断、网络攻击、故障更改和升级、人为错误等。对于其中每个适当的缓解措施，应仔细考虑。 在考虑解决集中风险的优先解决方案时，公司还必须考虑缓解成本、复杂性和内部技能的可用性。

在某些情况下，保持集中度可能是可能的，在某些情况下，甚至希望保持集中度，以便公司可以最大限度地增强复原能力。 与其尝试完全消除第三方依赖项，公司应该专注于通过 解决与集中风险相关的潜在威胁方案 (来增强运营复原能力，例如：区域数据中心灾难事件) 。 通过 (i) 降低威胁事件发生的概率， (ii) 通过降低集中度来限制其影响，通常可以轻松解决这些方案，并降低其缺点：

1. 通过增强解决方案设计中的复原能力，可降低概率。 一组可靠的风险管理过程可以增强作复原能力，尽管关键功能集中在单个第三方提供商中。 措施可能包括在最先进的基础结构上运行、运行零信任安全模型、使用最新更新修补系统、确保业务连续性措施已设置并证明有效、部署模块化和开源技术、 (例如：容器) 等。其中每一个都有助于获得一个具有最大弹性的环境。

2. 通过将服务设计为在主动/主动配置中跨多个可用性区域运行，可以降低较低级别的集中度来限制影响;确保有足够的冗余和恢复机制 (例如备份) ，以及利用异地冗余设计。 此类配置不仅可带来更高的复原能力和更好的 SLA，而且还有助于缓解威胁，例如，由于数据中心的分布式特性而丢失单个数据中心甚至整个区域。 可以降低威胁的影响，从而降低集中风险，在某些情况下甚至超出本地或混合方案中的可行范围。

总之， 如果与替代方案相比，完整的云拓扑提供更高的复原能力，那么集中风险也会有效地降低，尽管集中本身不会降低。 此结果既可以接受，也可以是可取的。

我们建议将此作模型合并到企业云策略中，因为这样可以指导业务和 ICT 团队了解组织的首选拓扑是什么，以及在解决方案设计中要考虑哪些元素。 考虑这一点的另一个原因是，通常与一个或多个云提供商建立战略联盟，以交付 ICT 第三方服务，而管理相关风险的方法通常在更高的级别进行管理。

步骤 4 - 复原能力设计

在此阶段，ICT 技术、安全和运营团队开始深入了解解决方案设计，将之前的结论和要求构建到单个用户案例中。

ICT 团队必须确保在默认情况下配置和设计应用程序时具有安全性和可复原性。 这意味着确保解决方案可靠、安全、无单一故障点，并可能利用可用性区域来建立恢复时间目标 (RTO) 、恢复点目标 (RPO) ，以及服务级别 (SLA) 业务要求。 必要时实施备份、更新业务连续性和退出计划也是此过程的一部分。

尝试使用Microsoft云技术最大化端到端 SLA 时，请考虑查看 适用于Microsoft联机服务的 SLA。 你会发现 SLA 因服务而异，并且取决于客户的设计选择，跨多个可用性区域部署的 SLA 更高。 通过选择正确的设计，客户可以在云中实现 99.999% 的每月可用性 SLA。

确保强大且默认安全的设计并非易事，ICT 团队在实施过程中存在留下弱点或出错的风险。 这一挑战就是为什么我们在Microsoft云上部署时提供最佳做法指南。

Microsoft 365 和 Dynamics 365 等 SaaS 服务已从头开始设计，旨在最大程度地提高复原能力，并最大程度地减少这些云服务的中断。 我们为 Exchange、SharePoint、OneDrive、Teams & Microsoft Entra 等服务提供了内置冗余，并设计了该服务，使其可以在硬件层和数据中心层之间使用多个抽象层运行。 有关此工作原理的详细信息，请参阅此处有关Microsoft合规性 的服务保障文档 。

我们还提供有关 如何利用 Microsoft 365 的内置版本控制功能和还原功能为 Microsoft 365 租户部署勒索软件防护的指导。 正确配置后，这可能足以满足组织的需求，但许多大型企业都希望能够更精细地从任何事件（包括勒索软件攻击）中恢复和还原，并跨越更长的时间跨度。 这是 Microsoft 365 备份 所在的位置，它将有助于使用频繁的恢复点和快速的批量恢复时间快速恢复。 它既作为Microsoft服务提供，也可通过一些合作伙伴提供，这些合作伙伴可能会提供其他功能来满足你的需求。 可在此处找到基于 Microsoft 365 备份 存储平台的已获认可的合作伙伴解决方案。 还可以在此 白皮书中阅读有关如何做出备份解决方案采购决策的信息。 仅依赖于 Microsoft 365 数据的导出副本的解决方案将难以提供足够的恢复时间性能，以帮助你在发生影响复原能力的事件后重新获得业务运营。 请仔细考虑你采购的解决方案的性能，以便你能够最好地满足 DORA 要求。

在 Azure (IaaS) 上构建解决方案时，事情可能会变得复杂。 因此， Microsoft创建了Microsoft Azure Well-Architected Framework ，以提供有关如何设计可靠性和安全性的其他指导。 Microsoft提供了资源来帮助公司实现高复原能力方案，包括 Azure 可靠性概述、Azure 安全性概述以及查看 Azure 可用性区域和区域的概念。 要考虑的其他方面包括建立 卓越运营 ，以及在较小程度上优化成本和性能。

因此，必须把大量注意力放在整体安全上，特别是在金融服务方面。 我们建议在 azure Microsoft 云采用框架中评估我们的安全性，该云采用框架提供了有关如何在云上最有效地应对当今网络安全威胁的核心原则和实践指导。 它还包含指向不同用例的参考体系结构和安全基线的链接。

最后，ICT Teams 应以满足所有法规和内部策略要求的方式部署云资源。 Azure 治理 通过将此类策略强制实施到 Azure 云资源，帮助公司实现这些法规和内部控制要求。 此外，公司可能会回顾我们对 Azure 混合和多云的介绍，这有助于支持混合和多云部署。

步骤 5 - 测试业务连续性计划

业务连续性规划和测试过程已在受监管的 FIS 中建立。 此步骤的重点是评估可能导致第三方外包中断的影响， (在此过程中使用Microsoft云) 。 DORA 关于信通技术风险管理工具方法流程和政策的《DORA RTS草案》第26条的ICT业务连续性计划测试介绍了一个很好的测试示例。

这需要共同承担责任，我们的 Microsoft复原能力和连续性概述 可帮助客户为灾难场景做好准备。 它为每个Microsoft云服务提供具体指导，包括Microsoft如何处理每项服务的业务连续性，以及客户如何利用Microsoft云服务来准备灾难事件的指导。

使用 Microsoft 云时，金融公司应定期测试业务连续性，因为责任遵循 共同责任模型。 对于 Microsoft 365 等 SaaS 解决方案和某些 Azure 服务，Microsoft负责定期执行这些测试。 有关更多见解，客户可以查看Microsoft的 季度业务连续性和灾难恢复计划验证报告 ，Microsoft发布在其 服务信任门户 的“业务连续性和灾难恢复”部分下，了解有关云服务的具体Microsoft表现的更多见解。

步骤 6 - 准备退出计划

某些威胁方案无法使用业务连续性计划或技术复原措施进行管理，例如第三方提供商的破产或解决方案风险。 退出计划具有处理此类灾难性情况的好处，应被视为对测试业务连续性计划的补充。

这就是为什么每个组织都应为其关键用例制定整体退出策略和单个退出计划，因为其基础是多个法规和未来指南。

6月23日FSB咨询的第3.7节 提供了有用的指导，指出退出策略和退出计划的要素，如 () 合同约定过渡期，以尽量减少中断的风险： (ii) 确保逻辑和物理资产（包括数据和应用程序）以经济高效且及时的方式返回， (iii) 适当地制定与记录的所有权、维护、保存和长期可用性相关的合同条款。

DORA第28条 (8) 还要求公司制定支持关键或重要职能的信通技术服务的退出战略。 同样， 2021 年 3 月英国 PRA 关于外包和第三方风险管理的监管声明 SS2/21 在第 10 节中对退出计划要求进行了广泛描述，并引入了有压力的退出的概念。 这些司法管辖区的金融公司必须评估这些准则，并制定适当的合同安排，以支持这些准则的执行，例如，通过要求强制性过渡期，信通技术第三方服务提供商 (继续提供相关服务，例如：《DORA》第30.3.f条提到合同规定一个强制性的充分过渡期) 。

欧洲银行联合会于 2020 年 6 月撰写的一份技术论文介绍了根据 EBA 指南为金融机构实现退出计划测试的一些方法。