在某家大型銀行內部，一支工程師團隊近期完成了將兩百萬行 COBOL 代碼轉譯為 Java 的工作——這項遷移歷時十四個月，通過了所有測試套件，並如期上線，然而安全團隊在第一週內便發現，信用卡號碼、社會安全號碼及帳戶餘額正在毫無防護地流經 API 端點、Kafka 管道，以及原有大型主機架構從未暴露過的分析資料湖。
現代化改造成功了，但資料保護卻失敗了，而這種情況在大多數企業中發生的頻率遠比他們願意承認的要高得多。
大型主機現代化的支出正在加速，但相關討論仍主要聚焦於代碼轉譯、雲端基礎設施與成本削減，而資料安全——這個決定現代化專案究竟是創造風險還是消除風險的唯一因素——在出現問題之前幾乎得不到應有的重視。
現代化所製造的邊界問題
傳統大型主機從未以現代意義上的安全性為設計目標；它們的設計目標是讓外部無法觸及。IBM z/OS 環境依賴實體隔離、RACF 存取控制，以及其架構本身的高度不透明性來保護敏感資料，數十年來，資料始終留在邊界內，因為它無處可去。
現代化從根本上改變了這一格局，因為一旦組織將 COBOL 應用程式遷移至雲端，或將 DB2 資料表複製至資料倉儲，敏感資料便開始跨越以前從未存在過的信任邊界，而每一個新的整合點——無論是 API 呼叫、資料管道，還是下游分析平台——都成為原有安全模型從未構建來保護的攻擊面。
這項挑戰因這些系統的老舊程度而更加複雜——COBOL 代碼與沒有人完整記錄的業務邏輯緊密耦合，編寫這些代碼的開發人員正陸續退休，而幾乎所有運行大型主機的企業都奉行同一政策：不安裝代理程式、不修改生產代碼、不冒風險中斷處理關鍵任務交易的工作負載。
為何僅靠代碼轉譯還不夠
AI 輔助代碼轉譯工具加速了遷移進程——以往需要數年完成的工作現在數月即可完成——但將 COBOL 轉譯為 Java 或 Python，並不能轉譯在資料留存於大型主機期間保護它的安全控制措施。在典型的 z/OS 部署中，加密由專用密碼處理器在硬體層面處理，存取控制透過 RACF 或 ACF2 強制執行，且資料在未經過嚴格管控的批次處理流程前絕不會外流。
然而，當同樣的資料移至雲端原生環境時，保護模型將發生根本性變化：資料現在分散於多個服務、區域和供應商之間，PCI DSS、HIPAA 及 GDPR 的合規範圍也擴展至所有在資料離開 z/OS 後接觸敏感資料的系統。若未在遷移開始前設計好資料保護策略，組織將發現自己所做的與其說是現代化了安全性，不如說是遷移了風險。
在不觸及大型主機的情況下保護資料
在現代化改造期間及之後保護資料的最實用方法，是在網路層而非應用層上運作，這一區別至關重要，因為修改舊版 COBOL 應用程式幾乎不可行，而在生產大型主機上安裝代理程式則會帶來難以接受的運營風險。無代理資料保護解決方案在資料於大型主機與下游系統之間流動時攔截資料——即時對敏感欄位進行代幣化、遮罩或加密，無需更改大型主機代碼、資料庫結構描述或現有工作流程——而 最佳的大型主機升級與現代化解決方案現在已將這種內聯安全性作為核心元件整合，而非事後補救。
代幣化尤其已成為在大型主機環境中運營的企業的首選方法。保格式代幣維持了舊版驗證檢查所預期的資料結構——例如信用卡號碼的 Luhn 驗證——同時消除了代幣與原始值之間的數學關係，這意味著代幣可以在雲端管道、分析平台和第三方整合中流通，而不會暴露敏感資料或破壞依賴一致格式的下游系統。
企業在遷移前應評估的事項
規劃大型主機現代化計畫的組織，應在第一個工作負載遷移之前評估其資料安全狀態——具體而言，包括敏感資料分佈於大型主機資料庫和應用程式資料存放區的位置、哪些遷移路徑將使該資料暴露於新環境，以及資料到達雲端後保護措施如何持續有效。那些正確推進現代化的企業，從第一天起就將資料安全視為設計約束條件，而非事後補加的合規核選方塊；而那些做錯的企業，往往在為時已晚時才發現，他們建造的不過是現有系統一個更快、更便宜、卻也更加脆弱的版本。
