關於本文引用的法規狀態
本文條號依據《外籍移工匯兌機構資訊系統標準及安全控管作業基準》草案版本。依草案第二十五條，本基準須「經中華民國電子支付商業同業公會理事會議通過，函報主管機關核定後施行」——目前尚未核定施行，正式版條號與文字仍可能調整。實務作業請以核定公布的版本為準。
換句話說，現在不是罰則期，是準備期。這正是把架構補起來最划算的時候。
一個很具體的問題
打開你們的匯兌 App，使用者在登入畫面輸入密碼。這串密碼經過 TLS 加密送出，穿過網際網路，抵達你們機房的負載平衡器——然後 TLS 在那裡終結了。密碼以明文的形式，繼續往後走到應用伺服器，在那裡被拿去跟資料庫裡的雜湊值比對。
這是絕大多數系統的做法，行之有年，看起來也沒什麼不對。
基準草案要求的是：那串明文不該出現在那裡。
這部基準是什麼
金管會近年推動外籍移工國外小額匯兌業務的專法化，《外籍移工國外小額匯兌業務管理辦法》已於民國 110 年發布、113 年修正。而配套的技術規範——《外籍移工匯兌機構資訊系統標準及安全控管作業基準》——目前以草案形式流通，全文二十五條，由電子支付商業同業公會研議，通過後報金管會核定施行。
它的骨架大量沿用了電子支付機構的資安基準：訊息的隱密性、完整性、來源辨識性、不可重複性、不可否認性，五種防護措施；對稱與非對稱演算法的強度下限；行動 App 的檢測週期。對做過電支系統的團隊來說，這份文件不會陌生。
但對只做過一般 Web 服務的團隊來說，其中有一條會讓架構圖整個重畫。
拆解第 10 條第 1 款第 8 目
草案第十條規範「本業務平臺之設計原則」，第一款是網際網路應用系統，其下第八目針對「採用固定密碼進行身分確認者」，要求加強安全機制。這一目的第 2 子目，逐字是這樣寫的：
提供端點對端點加密機制。係指於使用者輸入固定密碼後立即加密，傳送至外籍移工匯兌機構可信任網段（如經兩道防火牆隔離之獨立網段）於符合 FIPS 140-2 Level 3 以上之硬體安全模組（如 HSM）內進行解密，並於硬體安全模組內或於無洩漏解密資料疑慮之安全環境進行驗證。
一句話，四個約束。拆開來看：
約束一：加密的起點是「使用者輸入後立即」。 不是送出前、不是進網路層之前，是輸入的那一刻。這意味著加密必須發生在使用者端的程式碼裡——瀏覽器的 JavaScript、Android App、iOS App——而不是在你的伺服器上。
約束二：解密的終點是可信任網段裡的 HSM。 草案還順手定義了什麼叫可信任網段：「如經兩道防火牆隔離之獨立網段」。也就是說 DMZ 不算，應用伺服器所在的一般內網也不算。
約束三：HSM 必須符合 FIPS 140-2 Level 3 以上。 Level 3 的門檻在於實體防篡改——外殼被撬開時，模組必須主動銷毀內部的金鑰材料。這排除了軟體金鑰庫，也排除了大多數 Level 2 的設備。
約束四：連驗證都要在 HSM 內做。 這是最容易被忽略的一句。密文在 HSM 裡解開之後，如果把明文密碼丟回應用伺服器去比對雜湊，前面三個約束就全白費了——明文還是落地了。草案要求驗證動作本身也在 HSM 內完成，或至少在「無洩漏解密資料疑慮之安全環境」。
「我們有 TLS」為什麼不算數
這是最常見的第一反應，也是最容易誤判的地方。
TLS 保護的是傳輸通道，而且是一段一段的。使用者到負載平衡器是一段，負載平衡器到應用伺服器是另一段。現代架構為了做流量檢查、WAF、L7 路由，TLS 幾乎都在邊界就終結了——這是刻意的設計，不是疏失。
問題在於，TLS 一終結，密碼就變回明文。它會出現在：
- 負載平衡器的記憶體裡
- 應用伺服器的 request body 裡
- 你不小心開了 debug level 的存取日誌裡
- APM 工具側錄的請求樣本裡
- 任何一個有 root 權限的維運人員的
tcpdump裡
E2EE 要解決的正是這一段。它保護的不是通道，而是資料本身——密文從使用者的鍵盤一路帶到 HSM 前才解開，中間所有經手的元件，包括你自己的伺服器和你自己的員工，都看不到明文。
這也是為什麼稽核會盯著這一條看：它是少數可以用「明文有沒有出現在應用層」這種二元問題直接驗證的規定。
要說清楚的是，TLS 仍然要做——它解決的是傳輸通道被竊聽的問題。但它不能取代 E2EE，因為兩者保護的根本不是同一個東西。
配套的三條
E2EE 不是孤立的要求，草案裡另有三條把它的技術細節鎖死：
| 條號 | 規範內容 | 對系統的實際意義 |
|---|---|---|
| 第 6 條 | 訊息隱密性須採 3DES 112 bits、AES 128 bits、RSA 2048 bits、ECC 256 bits 以上，或同等安全強度之演算法 | 這是下限不是建議。自研的「加密」演算法、Base64 編碼、XOR 混淆一律不合格 |
| 第 9 條 | 資料傳輸應採訊息加密，涵蓋註冊時的機敏資料、匯款訂單、受款人資料、與代收機構及境外匯兌機構的資料交換、帳務核對，確保不被篡改及洩露 | 加密範圍不只登入密碼。機構之間的資料交換同樣要保護 |
| 第 14 條 | 固定密碼儲存時須先做不可逆運算並加鹽；採加密演算法者，其金鑰應儲存於硬體安全模組內並限制匯出功能；金鑰須由非開發維護單位的二個以上單位分持基碼單 | HSM 不只是解密的地方，也是金鑰的唯一歸屬地。而且金鑰的產製與保管必須分權，開發團隊不能一手包辦 |
第 14 條的分持要求特別值得注意。它管的不是技術，是組織：金鑰的基碼單要由客服、會計、業管這類非開發維護單位的兩個以上單位產製並分持。換句話說，寫程式的人不能同時是掌管金鑰的人。
這代表導入 HSM 時，你需要的不只是一台設備，還有一套跨部門的金鑰管理程序、以及能留下稽核軌跡的儀式性流程。買一台 HSM 不等於符合第 14 條。
不只 E2EE：草案的其他要求
第 10 條第 1 款第 8 目是最硬的一條，但不是唯一一條。掃一遍草案，其他會影響開發排程的規定包括：
- SDK 嵌入第三方 App 仍須合規（第 10 條第 4 款）。如果你把匯兌功能做成 SDK 給仲介公司或人力銀行的 App 嵌入，那個 SDK 仍須符合第 10 條第 2 款對行動裝置應用程式的全部要求。不會因為「App 不是我們發的」就免責。
- App 檢測有固定週期。至少每三年由合格實驗室依「行動應用 App 基本資安檢測基準」通過 L2 檢測；另外每年針對 App 及其應用伺服器辦理程式碼掃描或黑箱測試，修正中／高風險漏洞。
- 新功能上線要過 OWASP Mobile Top 10。應用程式新功能首次上線、架構異動或既有功能異動時，須依 OWASP Mobile Top 10 辦理檢測，中／高風險漏洞修完才能上線。
- 越獄偵測與偽冒 App 處理。偵測到裝置疑似 root／jailbreak 時須提示風險並限制辦理業務；另須建立偽冒 App 的偵測、下架或告警機制。
- 交易確認的防呆。生成繳款代碼、條碼或虛擬帳號前，須讓匯款人再次確認受款人資料，且行動裝置上生成的代碼須顯示受款人姓名（第 9 條）。
這幾條的共同點是：它們都需要時間。L2 檢測不是送件隔天就拿得到報告，跨部門的金鑰分持程序也不是一次會議就能定案。這正是「草案階段」比「已經開罰」更值得動作的理由。
實作上真正的難點
把規範讀懂之後，工程上的坑才開始。
金鑰輪替。 使用者端要拿到公鑰才能加密。這把公鑰怎麼發、多久換一次、換的時候舊版 App 怎麼辦？如果做成硬編碼在 App 裡，一旦要換金鑰就得逼所有使用者升級——而 App 商店的更新覆蓋率永遠不會是 100%。
前向安全性。 如果每次連線都用同一把長期公鑰加密，那麼攻擊者只要側錄下歷史流量，未來某天拿到私鑰（或等到量子電腦成熟），就能把過去所有的通訊一次解開。這就是業界說的「先錄後解」（Harvest Now, Decrypt Later）。務實的做法是每次連線重新協商一組一次性的會談金鑰，讓歷史流量即使被錄下也無法回溯解密。
HSM 的高可用。 HSM 現在是登入流程的必經之路——它掛了，使用者就登不進來。這代表你需要 HSM 叢集、需要處理連線池與 session 管理、需要規劃韌體升級時的切換程序。單台 HSM 就是單點故障。
跨平台的一致性。 加密邏輯要同時在 JavaScript、Android、iOS 上實作，三份程式碼、三套密碼學函式庫，任何一邊的填充模式（padding）或編碼細節對不上，就是一個只在特定機型上出現的登入失敗。這種 bug 極難查。
稽核文件。 最後你還得向稽核證明上面每一件事都做到了。演算法強度的證明、HSM 的 FIPS 認證文件、金鑰分持的簽核紀錄、系統架構圖與法規條號的對應說明——這些東西的準備時間，通常比寫程式還久。
一種現成的解法
上述難點沒有一項是無解的，但每一項都要時間，而且都不是匯兌業務的核心價值——你的競爭力在匯率、通路與使用者體驗，不在自己重寫一套密碼學堆疊。
雲杉科技的**極點 E2EE 系統**就是為了這一段而做的：提供 JavaScript／Android／iOS 的跨平台 SDK 作為加密起點，後端以 HSM 作為解密與驗證的終點，金鑰協商、輪替與前向安全性由系統處理，並隨案提供法規條號與技術機制的對應說明，供法遵團隊與外部稽核直接引用。導入方式是嵌入現有 App 與網頁系統，不需要重建架構。
如果你正在評估這部基準對現有系統的衝擊，或想確認架構上還缺哪一塊，歡迎與我們聯絡。
延伸閱讀
- PQC 遷移的第一步：用 cbom_scanner 替內網密碼學資產建檔 — 在動手改演算法之前，先盤清楚系統裡到底還有哪些過期的密碼學資產
- 極點 E2EE 端對端加密系統 — 產品架構與導入說明