2026 年的雲端原生銀行,身處 DORA 稽核階段。Regulation (EU) 2022/2554 ⧉ 自 2025 年 1 月 17 日起施行。Articles 28-44 下的關鍵第三方提供者(CTPP)指定制度自 2025 至 2026 年逐步開啟,AWS、Microsoft(Azure)、Google(GCP)與 Salesforce 處於指定範圍之內或周邊。歐洲監理機構(EBA、EIOPA、ESMA)於 2024 年完成資訊登錄冊 ⧉的最終 RTS 與 ITS。ECB 銀行監理在2026-28 監理優先事項 ⧉中明確編列雲端中斷準備度與威脅導向滲透測試兩項專案。對機構而言,問題不是雲端策略要不要對齊 DORA —— 那早已是定局 —— 而是平台工程基本元件能否以部署管線的速度產出證據,而不是在考試前一週把 PDF 拼湊出來。
執行摘要 / 關鍵要點
- **DORA 雲端韌性自 2025 年 1 月 17 日起積極執法。**第 6、8、18、26 條與 Articles 28-44 全部生效。首波檢查的監理發現於 2025 年第 4 季出爐。「準備」這套敘事已落後兩個週期。
- **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 盤點。**Tier 1:2 小時 / 15 分鐘。Tier 2:4 小時 / 1 小時。Tier 3:24 小時 / 4 小時。由業務衝擊分析推導,而非平台團隊產能所及上限。
為什麼 DORA 雲端韌性已進入稽核階段 #
2026 年仍把「準備」當作敘事,有三個理由站不住腳。
**首先,時程。**DORA 於 2022 年 12 月公布。24 個月的適用準備期於 2025 年 1 月 17 日屆滿。歐洲監理機構的最終 RTS 與 ITS —— 包括用於 CTPP 指定的資訊登錄冊 ITS —— 在 2024 年陸續發布。第一波監理檢查跑了一整個 2025 年;針對第 6 條 ICT 風險管理框架完整性與第 8 條登錄冊對帳的稽核發現,於 2025 年第 4 季在多家 Tier 1 機構出爐。
**其次,CTPP 指定制度。**第 31 條訂定關鍵第三方提供者的指定要件:故障時的系統性影響、所提供服務的關鍵性、服務的規模與複雜度、可替代性。歐洲監理機構維護登錄並公告指定決定。AWS、Microsoft(Azure)、Google(GCP)與 Salesforce 視各會員國的金融服務市占而定,處於指定範圍之內或周邊。指定後,主導監督機構(由歐洲監理機構之一依供應商分配)即取得直接監督權:第 37 條的資訊調閱、第 38 條的現場檢查、第 35 條的建議,以及第 41 條的公開揭露制度。受該等 CTPP 服務的銀行,亦須就如何管理該指定依賴關係,承擔相對應的監理期待。
**第三,ECB 的 2026-28 監理優先事項。**該優先事項文件明確列出兩項直接影響雲端原生銀行的專案:大型雲端服務中斷準備度(模擬監理情境檢測機構是否能吸收指定 CTPP 的長期中斷),以及對齊 TIBER-EU 的 TLPT(每一場 TIBER-EU 演練都會劃定機構的關鍵與重要功能,如今已包含部署於公有雲的服務)。2026 年的檢查週期將就兩者產生稽核發現。
2026 年的敘事不是「DORA 即將上路」,而是「DORA 檢查發現正陸續寄達貴行信箱,而 2024 至 2025 年所做的平台工程決策,正是監理機關在這些發現中所檢視的對象」。
2026 年指數架構 #
| 指數層次 | 「就緒」的樣貌 | 就緒度指標 | 失效模式 |
|---|---|---|---|
| 平台成熟度 | 逾 80% 工作負載執行於鋪好道路的 Kubernetes 平台(EKS / AKS / GKE / OpenShift),搭配政策即程式碼准入、GitOps 部署與自動化 DR 測試 | 位於鋪好道路平台的 CIF 比例;影子部署數量;新服務上線平台的平均所需時間 | 控制不一致的影子平台;在未鋪好路的基礎建設上執行的 CIF,對第 8 條登錄對帳隱形 |
| 第 8 條登錄完整性 | 資訊登錄冊自動對帳至平台的第三方 API 消耗 + 雲端物料清單;關鍵性分類與機構的 CIF 盤點一致 | 已對帳至平台遙測的登錄項目比例;孤兒項目數;CTPP 邊界完整性檢查 | 歐洲監理機構發現機構未依第 8 條揭露的指定 CTPP 依賴;個案發現,並引發 CTPP 邊界後續效應 |
| 雲端集中度 | 關鍵功能對應到雲端供應商、子雲端區域、服務以及可替代性評估;跨 CIF 的相關曝險量化 | 各 CIF 集中度分數;共用指定 CTPP 區域之 CIF 間的相關曝險 | 一次 AWS us-east-1 IAM 中斷,讓機構原以為彼此獨立配置資源的四項 CIF 同時掛掉 |
| 實測退場能力 | 每項依賴指定 CTPP 的 CIF,每年皆執行端到端退場測試;書面 RTO / RPO 達 BIA 衍生目標;資料可攜路徑已實測 | 各 CIF 測試通過率;平均退場執行時間相對 RTO 目標;資料可攜路徑延遲 | 退場計畫僅存在於 PDF;桌面演練宣稱 4 小時 RTO,首次實測卻是 48 小時 |
| 可觀測性 + 事件通報 | 跨服務端到端的 OpenTelemetry 追蹤;自動化第 18 條 4 小時分級小幫手接入事件管理平台 | 由 OTel 追蹤涵蓋的 CIF 流量比例;從事件偵測到第 18 條分級決策的平均時間 | 重大事件因關鍵性判定須召開分流會議而超出 4 小時窗口;觸發第 18 條稽核發現 |
| TLPT 整合 | TLPT 範圍由 CIF 盤點推導並持續更新;發現回饋至平台政策即程式碼;結案發現可產出供監理檢視的證據包 | TLPT 發現結案率;由發現到政策更新的循環時間 | TLPT 發掘出機構平台工程團隊在兩個發布週期內仍無法修復的弱點 |
當前須追蹤的訊號 #
| 訊號 | 對銀行的意義 | 來源 |
|---|---|---|
| DORA 自 2025 年 1 月 17 日起積極執法 | 首波監理發現於 2025 年第 4 季出爐;第二波預計於 2026 年下半年陸續到位 | EUR-Lex ⧉ |
| CTPP 指定於 2025-2026 期間開啟 | AWS、Microsoft、Google、Salesforce 位於範圍內或周邊;指定賦予歐洲監理機構直接監督權 | EBA ⧉ |
| ECB 2026-28 監理優先事項明確點名雲端中斷 | 模擬監理情境檢測機構能否吸收指定 CTPP 的長期中斷 | ECB Banking Supervision ⧉ |
| TIBER-EU 對齊 DORA 第 26 條 | TLPT 範圍涵蓋關鍵 / 重要功能,包括雲端託管服務 | ECB TIBER-EU ⧉ |
| EBA 委外指引(EBA/GL/2019/02)與 DORA 第 28 條互鎖 | 實質存在(§64)、可替代性評估(§81)、退場策略(§113-117) —— 監理機關真正會檢視的條文 | EBA ⧉ |
| EU 雲端服務認證(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 已停用;進入生產的唯一路徑,就是合併的拉取請求(pull request)。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 小時分級窗口,從偵測開始計時;OTel 管線把「偵測 → 分級」的路徑,從分流會議縮短為一次可查詢的查找。
主權雲是工程,不是品牌 #
2026 年的主權雲策略必須回答四個關於 Schrems II + DORA + EBA 委外的明確問題:
- **資料在哪裡處理與儲存?**歐盟會員國位置;高關鍵性流向的子區域;書面化的資料駐留承諾。
- **誰有合法存取資料的權限?**僅由當地員工進行的營運;外國政府的資料調閱請求須經當地法院程序;合法存取請求的回應流程已實測。
- **可替代性樣貌為何?**EBA/GL/2019/02 §81 的可替代性評估;退場執行已實測;已識別並簽約的替代供應商(或記錄為何不可行)。
- **技術主權模型為何?**客戶掌控的金鑰;密碼學分離;主權管理平面;可被稽核的供應鏈。
2026 年回應上述問題的廠商選項:
- AWS European Sovereign Cloud(2023 年宣布,正式上線預計於 2026 年下半年):由歐盟註冊的 AWS 子公司營運的實體區域;歐盟在地營運與支援;以 KMS-XKS 模式由客戶掌控金鑰。DORA 第 28 條合約內容對齊待 2026 年完成。
- Microsoft EU Data Boundary(2024 年正式上線)+ Bleu(Capgemini + Orange + Microsoft,僅限法國):Data Boundary 將歐盟客戶資料保留於歐盟區域;Bleu 則是對齊 SecNumCloud 的法國主權雲,在法國營運控制下執行 Microsoft Azure 技術堆疊。
- Google Cloud 主權合作:法國的 Thales / S3NS(Bleu 的對應版本);德國的 T-Systems。
- Oracle EU Sovereign Cloud(2023 年正式上線):雙區域配置(Frankfurt + Madrid),由歐盟在地團隊營運;在 Schrems II 合規性上俐落到位。
- 對齊 Gaia-X 的供應商(OVHcloud、Scaleway、Stackit、Aruba Cloud、IONOS):歐盟在地原生供應商,具備 Gaia-X 標示;規模與生態系小於超大規模廠商,但無 Foreign Intelligence Surveillance Act 的曝險。
策略決定鮮少是二選一。Tier 1 銀行的常見做法,是大宗工作負載採用超大規模廠商搭配 Data Boundary 的配置,針對指定的高敏感流向(例如處理歐盟居民個資的 AML / 制裁案件管理系統)採用主權雲選項,並依 DORA 第 28 條每年實測一條應變替代路徑。
實測退場執行 #
EBA/GL/2019/02 ⧉ 第 113-117 段是退場策略條款。條文對要求寫得很白:「機構與支付機構應確保其能在不對業務造成不當干擾的情況下退出委外安排…… 退場策略亦應作為委外安排定期審查的一部分,予以書面化並進行測試。」
2026 年的監理期待,是每一項依賴指定 CTPP 的 CIF,每年皆執行端到端的退場執行測試。桌面演練與文件審查並不足夠。測試必須產出:
- 復原時間測量:從宣告退場到工作負載在替代供應商上恢復服務的實際經過時間,並對照 BIA 衍生的 RTO 目標。
- 資料可攜性證據:從主要供應商實測的資料匯出,對照目的端供應商的匯入路徑進行驗證,並具備對帳證據。
- 功能對等性:工作負載在替代供應商上以同等 SLO 實測運行。
- 成本證據:書面化的退場執行成本,對照機構應變規劃中所假設的復原成本。
針對單一 CIF 進行的首次端到端退場測試,通常會揭露「書面 RTO」與「實際 RTO」之間 5 至 10 倍的落差。要把這道落差補起來,是耗時數月的工程工作。若銀行是在監理檢查中才發現,而不是透過自家年度測試循環察覺,等著它的會是一輪本可避開的第 3 季稽核發現。
RTO / RPO 目標來自 CIF 盤點 #
每一項關鍵或重要功能,依機構業務衝擊分析推導對應的分級。分級驅動平台工程團隊承諾交付的 RTO 與 RPO 目標。
| 分級 | 範例 | RTO | RPO |
|---|---|---|---|
| Tier 1(任務關鍵) | RTGS 連線(CHAPS / T2 / Fedwire)、零售支付授權、數位通路客戶認證 | 2 小時 | 15 分鐘 |
| Tier 2(關鍵) | AML / 制裁篩查、詐欺偵測管線、ATM 授權、批次支付處理 | 4 小時 | 1 小時 |
| Tier 3(重要) | 報表與監理申報、面向客戶的知識庫、內部協作平台 | 24 小時 | 4 小時 |
| Tier 4(非關鍵) | 內部 HR 系統、行銷工具、非面向客戶的報表 | 72 小時 | 24 小時 |
這些數值僅供示意 —— 各機構自行的 BIA 才產出真正的目標值。平台工程的可交付成果,是經迴歸測試、能滿足 BIA 衍生目標的能力,並以各服務自動化 DR 測試提供佐證,再透過依賴 CTPP 的 CIF 年度退場執行測試予以驗證。
不同類型銀行的意涵 #
全球系統重要性銀行 #
難處在於跨業務線的規模:數千項服務、數百項 CIF,跨產品、跨司法管轄區與跨韌性樣貌的多重指定 CTPP 曝險。投資對象是中央平台工程能力 —— Kubernetes 鋪好的道路、Backstage 入口、GitOps、OPA、OTel —— 在無須為每條業務線量身打造的前提下,產出第 8 條登錄對帳、CTPP 集中度地圖,以及一項一項落實的退場執行能力。
全方位銀行與中型銀行 #
平台工程投資在此層級值得,但範圍須節制:挑出兩三項關鍵性最高的 CIF,圍繞它們建立鋪好道路的模式,接受傳統資產在中期內仍以既有控制持續運作。監理定位比平台廣度更重要 —— 能就前三大 CIF 提出 DORA 第 8 條登錄完整性與實測退場證據,就已涵蓋監理機關的核心關切。
區域與中小型銀行 #
選廠商,別自建。挑一家銀行平台廠商,要求其 Kubernetes 原生架構有完整文件、其第 8 條登錄整合是內建、其 DORA 第 28 條合約內容承諾清楚明確。內部工程能力聚焦於設定、監控與事件回應,而非平台建構。
服務銀行的 Fintech、PSP 與 SaaS 供應商 #
賣進歐盟銀行的廠商,2026 年的產品問題是:平台能否產出銀行法遵單位所需的第 8 條登錄項目與 DORA 第 28 條合約內容。能提供結構化輸出的廠商,贏得大型企業合約;只交付 PDF 樣板的廠商,輸給提供結構化 JSON 的競爭對手。
結論 #
DORA 雲端韌性已進入稽核階段。2024 至 2025 年所做的平台工程決策,正是 2026 監理循環檢視的對象。在 ECB 與 EBA 眼中於 2026-2028 期間仍具公信力的機構,是那些跑著 Kubernetes 鋪好道路、配備 Backstage 風格入口、以 Open Policy Agent 准入控管下的 GitOps 部署、再加上端到端 OpenTelemetry 的機構 —— 把第 8 條登錄證據視為部署產物產出,把退場執行證據視為年度循環例行,而非監理請求收到後才動工。
沒做這些投資的機構,將會親身驗證自家第二道防線的法遵團隊,能不能在第二輪監理發現抵達前,先消化掉第一輪。
像衡量任何營運專案那樣衡量平台:鋪好道路覆蓋率、登錄對帳率、CTPP 集中度分數、實測退場時間相對 RTO 目標、第 18 條分級平均時間、TLPT 結案率。以管線速度產出證據;只在監理機關提出要求時,才另行整理成文件包。
常見問題 #
2026 年 DORA 雲端韌性還在準備階段嗎?
不在。DORA 自 2025 年 1 月 17 日起積極執法。Articles 28-44 下的 CTPP 指定制度自 2025 至 2026 年逐步開啟。ECB 針對第 6 條 ICT 風險管理與第 8 條登錄完整性的檢查發現,已於 2025 年第 4 季在多家 Tier 1 機構出爐。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 年)。Regulation (EU) 2022/2554 — Digital Operational Resilience Act(DORA) ⧉。
- European Banking Authority,(2019 年)。EBA/GL/2019/02 — 委外安排指引 ⧉。
- European Banking Authority,(2026 年)。Digital Operational Resilience Act ⧉。
- European Supervisory Authorities,(2024 年)。DORA 資訊登錄冊 ITS 最終報告 ⧉。
- ECB Banking Supervision,(2025 年)。2026-28 監理優先事項 ⧉。
- European Central Bank,(2024 年)。TIBER-EU 框架 ⧉。
- ENISA,(2024 年)。歐盟雲端服務網路安全認證(EUCS) ⧉。
- Spotify,(2020-2024 年)。Backstage 開發者入口 ⧉。
- Cloud Native Computing Foundation,(2018 年)。Open Policy Agent(OPA) ⧉。
- Cloud Native Computing Foundation,(2019 年)。OpenTelemetry ⧉。
最後審閱 。
最近審閱 .