2026 年的云原生银行身处 DORA 审计阶段。第 (EU) 2022/2554 号条例 ⧉自 2025 年 1 月 17 日起生效。依据第 28 至 44 条的关键第三方提供商(CTPP)指定机制在 2025-2026 年间陆续开启,AWS、Microsoft(Azure)、Google(GCP)与 Salesforce 均处于或贴近指定边界。欧洲监管局(EBA、EIOPA、ESMA)于 2024 年发布了关于信息登记 ⧉的最终 RTS 与 ITS。欧洲央行银行监管团队在2026-28 监管优先事项 ⧉中明确列出了云服务中断准备度与威胁导向渗透测试两个专项。机构层面的问题,不再是"是否要把云战略与 DORA 对齐"——这一步已成定局——而是机构的平台工程基础组件能否以部署流水线的节奏产出证据,而不是在考前一周临时拼凑一沓 PDF。
执行摘要 / 核心要点
- DORA 云韧性自 2025 年 1 月 17 日起进入实质执法。 第 6、8、18、26 与 28-44 条全部生效。首轮检查的监管发现于 2025 年第四季度落地。"准备阶段" 的说法已落后两轮。
- CTPP 指定机制开启中。 AWS、Microsoft、Google、Salesforce——处于或贴近指定边界。指定赋予欧洲监管局直接监督权,包括信息索取、现场检查与监管建议。
- 平台工程是真正的交付物。 Kubernetes 铺装道路(EKS / AKS / GKE / OpenShift)、Backstage 风格的开发者门户、GitOps(ArgoCD 或 Flux)、准入处的 Open Policy Agent、端到端 OpenTelemetry。五项明确命名的基础组件;缺一就是一个监管发现。
- 主权云是工程,不是品牌。 AWS European Sovereign Cloud、Microsoft EU Data Boundary、Bleu(Capgemini + Orange + Microsoft)、Thales / S3NS、Oracle EU Sovereign Cloud——各自对应 Schrems II + DORA 第 28 条的某一具体维度;没有一项是开箱即用的答案。
- 必须备齐经过测试的退出证据。 EBA/GL/2019/02 第 81 段与第 113-117 段。季度桌面演练不够;监管期望对每项关键或重要功能每年完成端到端的退出执行测试。
- RTO / RPO 来自 CIF 清单。 一级:2 小时 / 15 分钟。二级:4 小时 / 1 小时。三级:24 小时 / 4 小时。源自业务影响分析,而非平台团队的产能。
为什么 DORA 云韧性已进入审计阶段 #
"准备阶段" 的说法在 2026 年站不住脚,理由有三。
第一,时间表。 DORA 于 2022 年 12 月发布。24 个月的适用过渡期已于 2025 年 1 月 17 日结束。欧洲监管局的最终 RTS 与 ITS——包括用于 CTPP 指定的信息登记 ITS——在 2024 年内陆续发布。首轮监管检查贯穿 2025 年;关于第 6 条 ICT 风险管理框架完整性与第 8 条登记对账的发现,在 2025 年第四季度落到了多家一级机构身上。
第二,CTPP 指定机制。 第 31 条规定了被指定为关键第三方提供商的标准:失效情形下的系统性影响、所提供服务的关键性、服务的规模与复杂度、可替代性。欧洲监管局维护登记并公布指定决定。视各成员国金融服务市场份额而定,AWS、Microsoft(Azure)、Google(GCP)与 Salesforce 均处于或贴近指定边界。指定将直接监督权交给主责监管人(由其中一家 ESA 按提供商分派):依据第 37 条索取信息、依据第 38 条进行现场检查、依据第 35 条提出建议、依据第 41 条进行公开披露。受监督的银行,在如何管理被指定的依赖关系上,要承担相应的监管期望。
第三,欧洲央行的 2026-28 监管优先事项。 优先事项文件点名了两个直接影响云原生银行的专项:重大云服务中断准备度(模拟监管场景测试机构吸收被指定 CTPP 持续性中断的能力),以及对齐 TIBER-EU 的 TLPT(每次 TIBER-EU 演练都会把机构的关键与重要功能纳入范围,如今其中包含承载在公有云上的服务)。2026 年的检查浪潮将在这两条上产出监管发现。
2026 年的框架不再是 "DORA 即将到来",而是 "DORA 检查发现已经送到机构邮箱,你在 2024-2025 年间所做的平台工程取舍,正是监管在这些发现中所细究的对象"。
2026 年指数的架构 #
| 指数层 | "就绪" 的样子 | 就绪度指标 | 失效模式 |
|---|---|---|---|
| 平台成熟度 | 超过 80% 的工作负载运行在铺装道路化的 Kubernetes 平台上(EKS / AKS / GKE / OpenShift),配合策略即代码准入、GitOps 部署、自动化灾备演练 | 上铺装道路的 CIF 占比;影子部署数量;新服务接入平台的平均时长 | 控制不一致的影子平台;关键或重要功能跑在未铺装的基础设施上,在第 8 条登记对账中完全隐形 |
| 第 8 条登记完整性 | 信息登记自动对账平台对外消费的第三方 API + 云物料清单;关键性分级与机构的 CIF 清单保持一致 | 与平台遥测对账的登记条目占比;孤儿条目数;CTPP 边界完整性校验 | 欧洲监管局发现一项机构未在第 8 条下披露的被指定 CTPP 依赖;既是个体发现,也牵连 CTPP 边界 |
| 云集中度 | 关键功能映射到云提供商、子云区域、服务以及可替代性评估;跨 CIF 的相关性敞口可量化 | 每项 CIF 的集中度评分;共用同一被指定 CTPP 区域的 CIF 之间的相关性敞口 | 单一 AWS us-east-1 IAM 故障,同时拖垮四项机构以为彼此独立的 CIF |
| 退出能力(经过测试) | 对每项依赖被指定 CTPP 的关键或重要功能每年完成端到端的退出执行测试;书面 RTO / RPO 达成 BIA 推导的目标;数据可移植路径经过测试 | 各 CIF 的测试通过率;退出执行平均时长对照 RTO 目标;数据可移植路径的延迟 | 退出计划只存在于一份 PDF 中;桌面演练说 RTO 是 4 小时,首次实测要花 48 小时 |
| 可观测性 + 事件报告 | OpenTelemetry 端到端贯穿各服务;自动化的第 18 条 4 小时分级辅助工具接入事件管理平台 | 由 OpenTelemetry 追踪覆盖的 CIF 流量占比;从事件检测到第 18 条分级决定的平均时长 | 重大事件因关键性判定需要专门召集分诊会议而越过 4 小时窗口被分级;第 18 条监管发现 |
| TLPT 整合 | TLPT 范围源自 CIF 清单,持续刷新;发现反馈给平台的策略即代码;闭环发现产出可供监管查阅的证据包 | TLPT 发现的关闭率;从发现到策略更新的周期时长 | TLPT 发现一项漏洞,机构平台工程团队需要超过两轮发布周期才能修复 |
当下需要追踪的信号 #
| 信号 | 对银行的含义 | 来源 |
|---|---|---|
| DORA 自 2025 年 1 月 17 日起实质执法 | 首轮监管发现于 2025 年第四季度落地;第二轮预计在 2026 年下半年陆续到来 | EUR-Lex ⧉ |
| CTPP 指定机制在 2025-2026 年间开启 | AWS、Microsoft、Google、Salesforce 处于或贴近边界;指定赋予 ESA 直接监督权 | EBA ⧉ |
| 欧洲央行 2026-28 监管优先事项明确点名云中断 | 模拟监管场景测试机构吸收被指定 CTPP 持续性中断的能力 | ECB 银行监管 ⧉ |
| TIBER-EU 已与 DORA 第 26 条对齐 | TLPT 范围覆盖关键 / 重要功能,包括承载在云上的服务 | ECB TIBER-EU ⧉ |
| EBA 外包指引(EBA/GL/2019/02)与 DORA 第 28 条互锁 | 实质性存在(第 64 段)、可替代性评估(第 81 段)、退出策略(第 113-117 段)——这些段落正是监管真正会去考查的 | EBA ⧉ |
| 欧盟云服务方案(EUCS)草案推进中 | 依据欧盟《网络安全法案》形成的未来主权云认证体系;ENISA 已发布草案 | ENISA EUCS ⧉ |
平台工程:五项明确命名的基础组件 #
2026 年的云原生成熟度,可归结为五项相互咬合的工程基础组件,共同以部署流水线的节奏产出监管证据。缺任一项,都是早晚要出的监管发现。
1. 基于 Kubernetes 的铺装道路 #
每项 CIF 运行在受管的 Kubernetes 平台上——在被指定 CTPP 上跑 EKS、AKS、GKE 或 OpenShift,或采用厂商管理的替代方案。平台团队运营一套黄金集群模式,只允许受控偏离:节点基于已记录的基础镜像;按团队划分命名空间隔离;启用 pod-security-standards-restricted 配置;部署网络策略;通过服务网格注入(Istio 或 Linkerd)承担服务间认证与可观测性。新服务通过模板化的接入流程加入铺装道路,该流程把第 8 条登记条目作为部署制品产出。
2. Backstage 风格的开发者门户 #
一个集中式的开发者门户——以 Spotify 开源的 Backstage ⧉ 为参考实现,配合若干企业级替代品——为 "什么服务跑在哪里" 提供权威系统。目录列出每个服务、负责人、依赖、关键性分级、应急手册与值班轮值。门户与第 8 条登记互锁:每条目录条目映射到一条登记条目;缺少登记引用的条目触发 CI 失败;缺少目录归属的登记条目,触发先于监管察觉的告警。
3. 通过 ArgoCD 或 Flux 的 GitOps 部署 #
生产部署经由 GitOps 控制器进行——2026 年的生产标配是 ArgoCD 或 Flux——以 Git 版本化的声明状态对运行中的集群进行对账。手动 kubectl apply 被禁用;通往生产环境的唯一路径,是一次已合并的拉取请求。Git 仓库即审计轨迹;监管若问 "某服务 X 在日期 Y 的配置是什么",拿到的是 Git 标签,而不是一张截图。
4. 准入处的 Open Policy Agent #
Open Policy Agent(OPA)位于集群准入链路上,执行平台策略:pod-security 配置合规、镜像出处、资源上限、网络策略到位、按关键性层级合宜的副本数,以及在主权云约束下的子区域投放。策略与服务配置一同进行 Git 版本化与变更管理。被拒部署产出可复核的理由,反哺变更管理证据包。
5. 端到端 OpenTelemetry #
每个服务都发出 OpenTelemetry 的追踪、指标与日志。平台团队运营一套集中式可观测性流水线——通常以 Tempo 或 Jaeger 承担追踪、Prometheus 承担指标、Loki 或 OpenSearch 承担日志——浮现端到端的 CIF 健康度、依赖映射与事件分级输入。第 18 条 4 小时分级窗口从检测开始;OpenTelemetry 流水线把 "从检测到分级" 的路径,从专门召集的分诊会议缩短为一次可查询的检索。
主权云是工程,不是品牌 #
2026 年的主权云策略,必须回答 Schrems II + DORA + EBA 外包指引下四个具体问题:
- 数据在哪里处理与存储? 在欧盟成员国境内;高关键性流量进一步细化到子区域;数据驻留承诺以书面形式落定。
- 谁在法律上能访问数据? 仅本地员工运营;外国政府的访问请求受本地司法程序约束;对合法访问请求的响应经过演练。
- 可替代性侧写如何? 完成 EBA/GL/2019/02 第 81 段的可替代性评估;退出执行经过测试;已识别并签约替代提供商(或书面说明不可行的理由)。
- 技术主权模型是什么? 客户掌控密钥;密码学层面的隔离;主权管理平面;可审计的供应链。
2026 年回应这些问题的供应商选项:
- AWS European Sovereign Cloud(2023 年宣布,GA 预期 2026 年下半年):由欧盟本地 AWS 子公司运营物理区域;欧盟本地的运营与支持;通过 KMS-XKS 模式实现客户掌控密钥。DORA 第 28 条合同内容的对齐工作,将在 2026 年内推进。
- Microsoft EU Data Boundary(2024 年 GA)+ Bleu(Capgemini + Orange + Microsoft,仅限法国):Data Boundary 把欧盟客户数据保留在欧盟区域;Bleu 是对齐 SecNumCloud 的法国主权云,在法国运营控制下运行 Microsoft Azure 技术栈。
- Google Cloud 主权合作:法国的 Thales / S3NS(对应 Bleu);德国的 T-Systems。
- Oracle EU Sovereign Cloud(2023 年 GA):双区域模式(法兰克福 + 马德里)配合欧盟本地运营;在 Schrems II 维度上干净合规。
- 对齐 Gaia-X 的提供商(OVHcloud、Scaleway、Stackit、Aruba Cloud、IONOS):带有 Gaia-X 标签的欧盟本土提供商;规模与生态弱于超大规模厂商,但不暴露于美国《外国情报监视法案》。
战略选择鲜少非此即彼。一级银行通常对大宗工作负载采用 "超大规模厂商 + Data Boundary" 的组合,对被指定为高敏感性的流量(例如处理欧盟居民个人数据的反洗钱 / 制裁案件管理系统)采用主权云方案,并依据 DORA 第 28 条每年测试一条应急可替代路径。
经过测试的退出执行 #
EBA/GL/2019/02 ⧉ 第 113-117 段是关于退出策略的条款。原文表述明确:"机构与支付机构应确保其能够退出外包安排,而不对其业务活动造成不当干扰……退出策略也应作为对外包安排定期审查的一部分被记录在案并经过测试。"
2026 年的监管期望,是对每项依赖被指定 CTPP 的 CIF 每年完成端到端的退出执行测试。桌面演练与文档审阅不够。测试必须产出:
- 恢复时间 测量:从宣布退出到工作负载在替代提供商上恢复运行的实际经过时长,对照 BIA 推导的 RTO 目标。
- 数据可移植性证据:从主提供商完成的数据导出,经过验证可与目的提供商的导入路径对接,并附对账证据。
- 功能等价:在替代提供商上以等价 SLO 运行的工作负载,经过测试。
- 成本证据:书面记录的退出执行成本,对照机构应急规划中假设的恢复成本。
对某项 CIF 首次进行端到端退出测试,通常会暴露书面 RTO 与实际 RTO 之间 5 至 10 倍的差距。补上这一差距是数月起步的工程功夫。一旦这一差距是在监管检查中而不是在自己每年的测试周期中被发现,银行就会陷入本可避免的第三季度发现周期。
从 CIF 清单推导 RTO / RPO 目标 #
每项关键或重要功能,按照机构业务影响分析推导的层级分级映射。层级决定平台工程团队承诺交付的 RTO 与 RPO 目标。
| 层级 | 示例 | RTO | RPO |
|---|---|---|---|
| 一级(任务关键) | RTGS 接入(CHAPS / T2 / Fedwire)、零售支付授权、数字渠道的客户身份认证 | 2 小时 | 15 分钟 |
| 二级(关键) | 反洗钱 / 制裁筛查、欺诈检测流水线、ATM 授权、批量支付处理 | 4 小时 | 1 小时 |
| 三级(重要) | 报送与监管申报、面向客户的知识库、内部协作平台 | 24 小时 | 4 小时 |
| 四级(非关键) | 内部人事系统、营销工具、不面向客户的报送 | 72 小时 | 24 小时 |
这些数字仅作示意——机构自身的 BIA 会产出本机构的版本。平台工程的交付物,是一项可回归测试、能够达成 BIA 推导目标的能力,通过逐服务的自动化灾备测试取得证据,并通过对依赖 CTPP 的 CIF 进行的年度退出执行测试加以验证。
不同类型银行的含义 #
全球系统重要性银行 #
难点在于跨业务线的规模:数千项服务、数百项 CIF、跨产品 / 司法辖区 / 韧性侧写的多重被指定 CTPP 敞口。投入对准的是中央化的平台工程能力——Kubernetes 铺装道路、Backstage 门户、GitOps、OPA、OpenTelemetry——以产出第 8 条登记对账、CTPP 集中度图谱,以及逐 CIF 的退出执行能力,而无需为每条业务线另起炉灶。
综合性与中型银行 #
平台工程投入在这一层是说得通的,但范围有限:挑两到三项最高关键性的 CIF,围绕它们构建铺装道路模式,接受遗留资产在中期内继续沿用既有控制。监管定位比平台覆盖广度更重要——能就 DORA 第 8 条登记完整性以及前三项 CIF 的退出测试拿出证据,就能覆盖监管最关心的部分。
区域性与小型银行 #
宁可选型,不要自建。选一家 Kubernetes 原生架构有文档支撑、第 8 条登记集成已内置、DORA 第 28 条合同内容承诺清楚的银行平台供应商。内部工程能力围绕配置、监控与事件响应,而不是从零构建平台。
服务银行的金融科技、PSP 与 SaaS 供应商 #
2026 年向欧盟银行销售的供应商,要回答的产品问题是:你的平台是否能产出银行合规职能所需的第 8 条登记条目与 DORA 第 28 条合同内容。能输出结构化结果的供应商赢得企业级订单;只能给 PDF 模板的供应商,会输给给得出结构化 JSON 的竞争对手。
结语 #
DORA 云韧性已进入审计阶段。2024-2025 年间所做的平台工程取舍,正是 2026 年监管周期所要细究的对象。在 2026-2028 年面对欧洲央行与 EBA 仍显可信的机构,是那些跑着 Kubernetes 铺装道路、配套 Backstage 风格门户、在 Open Policy Agent 准入下进行 GitOps 部署、并实现端到端 OpenTelemetry 的机构——它们把第 8 条登记证据作为部署制品产出,把经过测试的退出执行证据作为年度循环,而不是作为监管索取的临时回应。
那些没有做这些投入的机构,将检验自己的二线合规团队,能否在第二轮监管发现到来之前先把第一轮消化掉。
像衡量任何一项运营计划那样去衡量平台:铺装道路覆盖率、登记对账率、CTPP 集中度评分、实测退出时长对照 RTO 目标、第 18 条分级平均时长、TLPT 关闭率。证据按流水线节奏产出;文档包只在监管索取时才装订。
常见问题 #
2026 年的 DORA 云韧性是否仍处于准备阶段?
不是。DORA 自 2025 年 1 月 17 日起进入实质执法。第 28 至 44 条下的 CTPP 指定机制在 2025-2026 年间陆续开启。欧洲央行关于第 6 条 ICT 风险管理与第 8 条登记完整性的检查发现,2025 年第四季度已在多家一级机构落地。2026 年的监管问题是机构层面的检查证据,而不是整体的法规就绪度。
哪些云提供商被指定为 CTPP?
欧洲监管局在其官网上公布指定决定。2026 年处于或贴近边界的机构包括 AWS、Microsoft(Azure)、Google(GCP)、Salesforce,以及若干视成员国金融服务市场份额而定的其他机构。受监督的银行,在管理这些依赖关系上承担相应的监管期望。
主权云能否免除 DORA 第 28 条合同内容的要求?
不能。主权云解决的是 Schrems II + 数据驻留维度;DORA 第 28 条合同内容是另一项义务,无论数据落在何处都同样适用。主权云提供商的合同,仍须依第 28 条覆盖数据可访问性、安全、驻留、审计权、退出策略与业务连续性。
用什么工程交付物来证明 DORA 云韧性?
五项相互咬合的平台工程基础组件:Kubernetes 铺装道路(受管集群,受控偏离)、Backstage 风格的开发者门户(目录与第 8 条登记对账)、GitOps 部署(ArgoCD 或 Flux)、准入处的 Open Policy Agent、端到端 OpenTelemetry。证据按流水线节奏产出,而不是等到考时再拼。
退出执行需要多久测一次?
每年对每项依赖被指定 CTPP 的 CIF 完成端到端的退出执行测试。桌面演练与文档审阅不够。测试必须产出恢复时间、数据可移植性证据、功能等价与成本证据——对照 BIA 推导的 RTO 与 RPO 目标加以衡量。
参考文献 #
- 欧盟,(2022)。第 (EU) 2022/2554 号条例 — 数字运营韧性法案(DORA)⧉。
- 欧洲银行管理局,(2019)。EBA/GL/2019/02 — 关于外包安排的指引 ⧉。
- 欧洲银行管理局,(2026)。数字运营韧性法案 ⧉。
- 欧洲监管局,(2024)。关于 DORA 信息登记 ITS 的最终报告 ⧉。
- 欧洲央行银行监管,(2025)。2026-28 监管优先事项 ⧉。
- 欧洲中央银行,(2024)。TIBER-EU 框架 ⧉。
- ENISA,(2024)。欧盟云服务网络安全方案(EUCS)⧉。
- Spotify,(2020-2024)。Backstage 开发者门户 ⧉。
- 云原生计算基金会,(2018)。Open Policy Agent(OPA)⧉。
- 云原生计算基金会,(2019)。OpenTelemetry ⧉。
最近审阅 。
最近审阅 .