泰國央行 API 載荷加密規則

多年來，“加密傳輸中的資料"只意味著一件事：上 HTTPS。TLS 在負載均衡器處終結，載荷在內部網路裡明文流動，而所有人都稱之為"已加密”。 泰國央行一直在穩步彌合這個缺口，方向也很明確：對於敏感金融資料，僅有傳輸加密已經不夠了。

傳輸加密與載荷加密的區別 #

TLS 保護的是線路上兩點之間的資料，它並不保護應用內部的資料。一旦 TLS 在反向代理、API 閘道器或負載均衡器處終結，載荷就被解密並以明文形式交給後端。

這些明文隨後會流經、駐留在你並不希望它出現的地方：

• 日誌：過於勤快的閘道器把請求體寫進日誌，完整的主賬號和賬號號碼隨之落盤。
• 服務網格與內部跳數：微服務之間的東西向流量常常不加密，理由是"內網是可信的"。
• 記憶體與快取：記憶體中的請求物件、除錯轉儲和 APM 追蹤都可能保留解密後的載荷。
• 可觀測性管道：跨團隊、跨第三方的指標與追蹤資料在轉發 span 時一併帶走了內容。

應用層載荷加密透過加密訊息本身來填補這一缺口，因此無論它跨越多少跳、基礎設施如何處置它，資料都始終受到保護。

標準推薦用什麼 #

載荷加密的機制已經標準化且廣為理解：

• JSON Web Encryption（JWE）（RFC 7516）：加密結構化 API 載荷的事實標準，用非對稱接收方金鑰包裹對稱資料金鑰。
• AES-256-GCM：載荷主體的認證加密主力演算法，同時提供機密性與完整性。
• RSA-OAEP 或 ECDH：金鑰封裝層，保護對稱金鑰在傳輸與靜態儲存中的安全。

這套模式與 TLS 自身如出一轍：用快速對稱密碼處理批次資料，再用非對稱金鑰交換進行封裝，區別在於它作用於訊息層級，因此在 TLS 會話之外依然有效。

央行為何此時推動這件事 #

監管者的邏輯並不深奧。金融 API 如今已是整個泰國支付生態的連線組織：銀行、PSP、金融科技、商戶。一次閘道器配置失誤，不應該讓任何有日誌訪問許可權的人看到賬戶資料。載荷加密是一種縱深防禦措施：它假設傳輸鏈路終將被檢查、被記錄或在某個時刻被攻破，並確保那一刻到來時敏感資料不可讀。

這與 PCI DSS 保護靜態持卡人資料的要求背後的原則一脈相承：當你不再信任任何單一跳點時，你就不會再把"網路是安全的"當作唯一的控制手段。

對你的工程團隊意味著什麼 #

採用載荷加密不是撥一個配置開關。它意味著：

• 金鑰管理成為一等公民。你需要輪換機制、簽名金鑰與加密金鑰的分離，以及受保護的金鑰儲存。
• 閘道器與日誌改造：所有讀取或記錄請求體的元件都必須重新評估，因為中介軟體再也讀不懂報文了。
• 契約變更：下游消費方必須能夠解密，這意味著要在鏈條上的每一方之間做好金鑰分發與版本管理。
• 測試：可觀測性必須從"傾倒載荷"轉變為"先認證授權，再僅在必要處解密"。

只要你身處 BOT 的監管半徑之內，這些都不是可選項。這是一次從"給管道加密"到"保護訊息本身"的轉變。

我們的法規合規服務將 BOT 指引對映為具體的工程要求， API 與應用安全審查則驗證你的載荷在端到端層面究竟受到了怎樣的保護。