泰国央行 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 与应用安全审查则验证你的载荷在端到端层面究竟受到了怎样的保护。