COBOL 仍運行著約 95% 的 ATM 交易、80% 的線下 POS 機交易，以及全球大多數大型銀行、保險公司和政府機構的核心處理邏輯。運行這些代碼的機構也必須遵守技術領域最嚴格的監管框架：GDPR、DORA、HIPAA、PCI-DSS、巴塞爾協議 III，以及由 FCA、OCC、APRA 和數十個其他國家監管機構執行的特定行業法規。當這些機構考慮將工作負載遷移到雲端時，這不僅僅是一個技術問題，還涉及法律、合約以及能否在特定時間表內向外部審計師進行證明。
對於運行 COBOL 的受監管組織而言，混合雲（即保留部分工作負載在本地，同時將其他工作負載遷移到雲端基礎設施）並非妥協之策，而往往是架構上的最佳選擇。 GDPR 及其國家對應法規下的資料駐留要求可能合法禁止某些資料離開特定司法管轄區。 DORA 下的營運彈性需求則要求證明關鍵財務功能能夠承受雲端服務供應商的故障。巴塞爾協議 III 中關於監管資本的計算完整性要求規定，特定計算必須具備可復現性、可審計性和防篡改性，而當計算在組織控制的基礎設施上進行時，這些特性更容易得到證明。
挑戰在於，受監管的 COBOL 混合雲架構比通用混合雲指南所承認的更為受限。您的混合雲整合策略在從大型主機遷移到雲端的過程中，需要在創新和穩定性之間取得必要的平衡。這種平衡原則本身是正確的。但它忽略了在滿足監管機構要求、保障營運連續性並創建遷移路徑（而非永久分離）的情況下，劃定本地/雲端邊界所需的具體技術和合規架構。
本指南涵蓋了每個主要監管框架如何影響混合邊界決策、適用於受監管 COBOL 環境的四種架構模式、混合架構如果未針對這些模式進行設計則會引入的合規性失敗模式，以及審計人員在審查混合 COBOL 環境時實際檢查的內容。
法規如何塑造混合邊界
對於受監管的組織而言，混合雲架構中最關鍵的決策並非選擇哪家雲端服務供應商或優先遷移哪些工作負載，而是如何劃定合規邊界：哪些資料和處理必須保留在本地，哪些可以遷移到雲端基礎設施而不會觸發違規行為。
每個主要框架對該邊界都有不同的要求：
| 規 | 管轄權 | 主要混合約束 | 哪些物品必須留在店內 |
|---|---|---|---|
| GDPR / nFADP | 歐盟，瑞士 | 歐盟/歐洲經濟區居民個人資料的資料駐留問題 | 任何未經目標雲區域充分性決定而處理歐盟個人資料的 COBOL 系統 |
| 多拉 | 歐盟金融服務 | 營運韌性；資訊通訊技術提供者的第三方風險管理 | 關鍵或重要職能部門必須有退出策略；集中風險限制適用。 |
| HIPAA | 美國醫療保健 | 沒有業務夥伴協議 (BAA)，雲端服務提供者無法處理受保護的健康資訊 (PHI)；加密要求 | 電子受保護健康資訊 (ePHI) 在傳輸和儲存在任何雲端路徑上時，都需要有文件化的控制措施。 |
| PCI-DSS v4.0 | 全球（卡片支付） | 持卡人資料環境必須與網路隔離。 | CHD處理系統；加密金鑰管理 |
| 巴塞爾協議III/IV | 全球（銀行業） | 監理資本計算必須具有可重複性和可審計性。 | 透過基礎設施控制來證明可審計性的計算引擎 |
| 英國金融行為監理局/審慎監理局 | 英國金融服務 | 營運韌性；重要業務服務必須滿足影響容忍度要求 | 取決於服務等級協定 (SLA) 的可證明性；雲端服務並非排除在外，但必須提供證據。 |
| 美國貨幣監理署（美國銀行業） | 美國國民銀行 | 供應商風險管理；第三方盡職調查 | 沒有明文禁止，但需要考慮集中風險並制定退出計劃。 |
對 COBOL 工作負載的實際影響：
處理歐盟客戶帳戶資料的 COBOL 批次程序無法遷移到歐盟/歐洲經濟區以外的雲端區域，除非雲端服務提供者所在司法管轄區已獲得充分性認定或已採取適當的保障措施（標準合約條款）。而僅處理內部營運資料的相同程序則具有更大的靈活性。
在劃定混合邊界之前，每個受監管組織都應對其 COBOL 程序組合進行數據分類：哪些程序涉及個人數據，哪些程序涉及持卡人數據，哪些程序涉及受保護的健康信息 (PHI)，以及哪些程序處理監管資本計算。這個分類決定了哪些程序可以自由遷移，哪些程序無論技術偏好如何都必須留在合規邊界之後。
無人提及的COBOL合規性問題
COBOL 程式引入了特定於該語言及其時代的合規性風險，而通用的雲端合規性指南並未涵蓋這些風險。這些風險目前存在於本地環境中，並在混合環境中演變為可見性問題，因為審計人員希望看到邊界兩側的控制措施。
審計追蹤漏洞。 COBOL程式通常會寫入檔案和資料庫，而沒有原生交易日誌記錄功能。預設情況下，COBOL 中的 VSAM KSDS 更新不會產生關於誰在何時更改了什麼以及從什麼值更改到什麼值的不可更改記錄。在受監管的環境中，這構成合規性漏洞。將存在此漏洞的程式遷移到雲端具備現代審計日誌記錄功能的混合環境中，只會使該漏洞更加明顯，而不是更不明顯。
硬編碼憑證和加密金鑰。傳統的 COBOL 應用程式通常缺乏基於角色的存取控制、即時監控和加密協定等現代功能，使其容易受到複雜的網路威脅。對 COBOL 程式進行靜態分析通常會發現硬編碼金鑰、工作儲存區中的密碼以及嵌入在原始程式碼中的連接字串。在必須滿足 PCI-DSS 金鑰管理要求或 HIPAA 加密控制的混合環境中，這些問題需要在遷移之前而非之後進行修復。
計算可重複性。 COBOL的壓縮十進位運算 (COMP-3) 具有特定的精度和捨入特性。在 z/OS 上執行正確的監管資本計算，由於編譯器在十進制處理方面的差異，在 Linux 上可能會產生不同的結果。這種差異可能只是每筆交易幾美分，但也可能對資本比率產生重大影響。將計算組件拆分到不同平台的混合環境必須明確驗證數值等效性。
四種用於受監管 COBOL 的混合架構模式
不同的受監管工作負載需要不同的混合架構。雖然沒有通用的模式，但這四種架構涵蓋了大多數受監管機構遇到的各種情況。
模式 1：合規邊界 API 網關
最適合：出於監管原因，COBOL 業務邏輯必須保留在本地，但現代應用程式、分析和客戶導向的服務可以遷移到雲端的組織。
COBOL 程式仍然運行在主機上。一個輕量級的 API 層（通常運行在雲端附近的基礎設施或組織內部的私有網路中）將 COBOL 功能以 REST 或 gRPC 端點的形式公開。雲端應用程式呼叫這些端點。 COBOL 程式本身不會遷移，遷移的是與其互動的介面。
Cloud Region (permitted) Compliance Boundary On-Premises (required)
┌─────────────────────┐ │ ┌──────────────────────────┐
│ New cloud-native │ │ │ COBOL programs │
│ applications │──── API ─────┤──────────────│ (regulated processing) │
│ │ call │ │ │
│ Analytics │ │ │ VSAM files (PHI/CHD) │
│ platforms │ │ │ │
│ │ │ │ Audit logs │
└─────────────────────┘ │ └──────────────────────────┘合規優勢：受監管資料永遠不會越過邊界。 API 閘道在邊界處處理身分驗證、授權和日誌記錄，提供 COBOL 程式本身可能無法產生的稽核追蹤。雲端永遠不會直接處理受監管資料。
運行需求： API 層必須設計為能夠處理 COBOL 的同步請求-回應模型。長時間運行的 COBOL 批次作業需要使用非同步模式，並採用回呼或輪詢機制，而不是會逾時的同步 API 呼叫。
模式二：依監理敏感性進行資料分層
最適合：在同一個 COBOL 環境中同時擁有受監管資料和非受監管資料的組織，其中受監管資料可以與操作資料分開。
觸發監管要求的交易資料、個人資料、持卡人資料和PHI（受保護的健康資訊）仍保留在本地。不觸發監管限制的匯總資料、匿名化資料或營運資料則遷移到雲端進行儲存和處理。產生受監管輸出的COBOL程式繼續在大型主機上運作。使用匯總資料的報表程式則在雲端運行。
關鍵實施要求：聚合和匿名化步驟必須可審計。將受監管資料轉換為非受監管資料以供雲端傳輸的過程本身必須進行日誌記錄、測試，並且受到自身控制。在特定輸入條件下失效的去識別化過程可能會產生無意中重新識別個人身份的雲數據，從而構成 GDPR 違規，而其架構的設計初衷正是為了防止此類違規。
模式 3：雙次運行驗證
最適合：遷移執行受監管計算的 COBOL 工作負載的組織，在切換之前必須向監管機構證明新舊系統之間的功能等效性。
原來的 COBOL 程式繼續在主機上運行，處理即時資料。經過平台重構或架構重寫的平行實作版本則在雲端基礎架構上同步運行，處理相同的輸入資料。兩個程式的輸出結果會即時比較。任何差異都會被標記、調查並解決，之後雲端實作版本才能被認證為正式記錄系統。
合規價值：雙系統運作滿足監管機構對執行監管計算的系統變更所要求的等效性證明。組織可以向審計人員提供 N 個月的並行運作記錄、針對差異的協調流程，以及新系統在所有測試輸入條件下產生實質相同的輸出的證據。
營運成本：並行運行兩個系統成本高。雙系統運作是一種過渡機制，而非永久架構。驗證和切換的完成時間表應在專案計劃中明確規定，並在需要預先批准的情況下（例如，根據《資料保護條例》(DORA)，對關鍵功能進行變更需要預先批准）與相關監管機構達成協議。
模式 4：帶有順應性邊界的絞殺圖
最適合：在雲端建立新功能，同時長期在本地維護受監管的 COBOL 工作負載的組織，並為每個工作負載制定明確的遷移路徑，以便在獲得認證後進行遷移。
新功能和麵向客戶的功能從一開始就以雲端原生服務的形式建構。受監管的 COBOL 工作負載仍保留在本地，並透過 API 閘道模式存取。隨著時間的推移，各個 COBOL 程式會獲得雲端部署認證，完成雙重運行驗證，並在需要時滿足監管預先批准要求，最終遷移到雲端。隨著每個程序完成合規性認證，大型主機的規模也會逐步縮小。
這種模式對受監管組織的優勢在於：它允許在非受監管工作負載上快速現代化，同時對受監管工作負載施加適當的嚴格監管。合規邊界明確、可審計且單向推進。組織可以向監管機構證明，雲端的每個工作負載都已通過既定的認證流程，而本地部署的每個工作負載都有相應的認證路線圖。
審計人員實際上會問哪些關於混合 COBOL 環境的問題
合規性不是一種狀態，而是一個可驗證的過程。問題不在於你的混合架構是否合規，而是你能否向那些以發現問題為己任的人證明這一點。
以下是主要監管機構的審計人員在混合 COBOL 環境下提出的問題，以及滿足每個問題的證據：
「這些資料靜態儲存在哪裡？位於哪些司法管轄區？」要求：提供一份最新的資料映射圖，圖中應包含所有資料儲存、VSAM 檔案、DB2 表、雲端物件存儲，並註明其司法管轄區、分類以及已實施的控制措施。寫入資料集的 COBOL 程式也必須出現在此映射圖中，並對其輸出進行分類。
「請提供此交易的審計追蹤記錄。」要求：從交易發起到所有接觸過該資料的系統（包括處理該資料的 COBOL 程序）的完整端對端追蹤記錄。如果 COBOL 程序本身不產生審計記錄，則週邊基礎設施必須提供相應的補償，此功能必須明確設計，而不能想當然。
「如果雲端供應商發生故障，您的關鍵功能會發生什麼情況？」要求（DORA）：記錄在案的運作彈性場景、關鍵功能的測試 RPO 和 RTO，以及證明本地系統可以在組織彈性策略規定的時間內獨立於雲端依賴性運行的證據。
「如何確定遷移後的系統與原始系統產生相同的結果？」需要提供：雙重運行協調記錄、測試案例覆蓋率，以及對於計算敏感型工作負載，需要進行數值等效性分析。
「誰可以存取雲端的受監管數據，以及哪些審批程序控制這種存取？」要求：身分和存取管理策略文件、權限存取管理記錄，以及證明雲端存取控制至少與本地存取控制一樣嚴格的證據。
混合邊界的決策框架
並非所有 COBOL 程式都應位於混合邊界的同一側。此清單用於確定每個工作負載的放置位置：
擺脫監管限制，輕鬆遷移到雲端：
- 本程序不處理GDPR/nFADP管轄區內個人的個人資料。
- 該程序不處理持卡人資料（已確認符合PCI-DSS範圍排除規定）
- 程序不處理PHI（已確認HIPAA範圍排除）
- 程序不執行監理資本比率的輸入計算。
- 程式原始碼中沒有硬編碼的憑證或加密金鑰。
- 程序輸出結果不受任何司法管轄區的資料駐留要求約束。
雲端遷移前需要進行合規性設計：
- 程序產生或處理個人數據，完成數據影響評估
- 該計畫符合PCI-DSS標準，並已完成雲端環境的SAQ/ROC認證。
- 程序執行監理資本計算，完成數值等價分析
- 程序缺乏審計追蹤產生功能，遷移前需要設計補償控制措施。
- 程式包含硬編碼密鑰，請在將其暴露於雲端網路路徑之前進行修復。
必須留在現場，直到獲得監管部門的預先批准：
- 根據《國防授權條例》(DORA)，該程序被歸類為關鍵或重要職能。
- 作為一項重要的商業服務，該計劃須遵守 FCA/PRA 的營運彈性要求。
- 監管機構明確要求對系統變更（核心銀行系統常見做法）進行通知或預先批准。
SMART TS XL 支援受監管 COBOL 的混合架構規劃
本指南中所述的決策，例如合規性邊界的設定、哪些程式處理受監管資料、哪些程式包含安全補救要求、哪些程式執行需要等效性驗證的計算功能，都需要對 COBOL 程式集中的每個程式有準確的結構了解。這種了解無法從文件中取得。在受監管的 COBOL 環境中，現有的文件通常是針對一個已經修改過數十次而沒有相應更新的系統編寫的。
SMART TS XL“ 靜態程式碼分析 本文揭示了 COBOL 原始程式碼中的安全性和合規性模式，這些模式決定了每個程式應位於混合邊界的哪一側：工作儲存區中的硬編碼憑證、加密金鑰處理、稽核日誌產生（或缺失）以及影響監管資本的計算模式。這些發現為受監管工作負載的混合邊界定位之前必須進行的合規性設計工作提供了支持。
應用程式依賴關係映射顯示了哪些程式與其他程式共享數據，以及跨程式的資料集存取模式，這些模式決定了將一個程式部署到雲端是否會在邊界上創建出意料之外的受監管資料流。例如，一個看似只處理操作資料的 COBOL 程序，可能會讀取一個包含由其他程序寫入的個人資料的 VSAM 檔案。依賴關係映射在繪製混合邊界之前，就能顯示這些資料共享關係。
影響分析功能使邊界變更可審計：當程式從本地遷移到雲端時，影響分析會列舉所有其他受此遷移影響的程式、呼叫者、資料集使用者、JCL 作業流，從而提供變更範圍作為監管機構的證據，並作為等效性測試程序的基礎。
企業級搜尋功能可讓整個混合程式中的合規性清單隨時查詢：只需幾秒鐘，即可在數百萬行資料中尋找處理特定資料類型的每個程式、存取特定 VSAM 叢集的每個程式、包含特定模式的每個 COBOL 原始檔。對於受監管機構而言，該清單可向審計人員證明所有相關程序均已識別和評估，是取代人工認證的有力證據。
監管機構並不關心你的遷移時間表
對於運行 COBOL 的受監管組織而言，混合雲並非一種臨時狀態。對許多此類組織而言，混合雲是其永久的營運模式，並非出於技術限制，而是因為監管其資料和功能的框架要求對特定工作負載進行長期的本地控制。正確的問題不是“我們如何擺脫大型主機”，而是“哪些工作負載可以遷移到雲端，在何種合規架構下遷移，以及需要提供哪些證據來證明邊界得到了妥善控制”。
混合架構賦予企業靈活性，使其既能保留本地傳統元件，又能實現雲端整合。對於受監管產業而言，這種彈性並非可有可無，而是特定工作負載類別的必備條件。那些在混合 COBOL 架構中取得成功的企業，會明確設計合規邊界，從一開始就為其配備可審計機制，並將監管證據的生成視為架構要求，而非事後添加的文檔。
