Q87: 敏感数据如何加密传输？
核心结论
敏感数据加密传输的第一选择通常不是自研协议加密，而是成熟的传输层安全方案。
更务实的顺序通常是：
- 优先使用 TLS 保护传输通道
- 在必要场景补充消息级签名或应用层保护
- 把精力更多放在密钥管理、会话绑定和业务校验上
因为很多系统的真实问题不是“算法不够强”，而是：
- 密钥管理差
- 明文落日志
- 会话和重放控制没做好
一、先区分传输加密和业务安全
传输加密解决的是：
- 数据在链路上不被窃听
- 中间人难以篡改
它不自动解决：
- 重放
- 业务越权
- 客户端伪造合法请求
所以“加密传输”和“业务可信”不是一回事。
二、为什么通常优先 TLS
原因很简单：
- 协议成熟
- 实现成熟
- 工具链成熟
- 漏洞暴露和修复路径更清晰
对大多数在线系统来说，自研一套“消息加密协议”很少比 TLS 更稳。
三、应用层额外保护什么时候有价值
一些场景仍可能需要补充：
- 敏感后台接口签名
- 支付回调鉴权
- 重放控制
- 关键消息完整性校验
但这里更常见的是“补充校验”，而不是替代传输层安全。
四、真正容易出问题的是密钥和会话管理
即使加密算法没问题，如果：
- 会话票据泄露
- 密钥长期不轮换
- 调试日志写了明文
- 重连票据可重复使用
系统仍然很危险。
所以工程上更重要的是：
- 密钥轮换
- 会话绑定
- 票据过期
- 最小暴露面
五、游戏里哪些数据最值得优先保护
通常包括：
- 账号认证信息
- 支付相关信息
- GM 与后台操作
- 高价值业务请求
不是所有消息都要做同样重的保护，但关键链路必须上强保护。
六、工程上更稳妥的组合
常见做法是：
- 外部传输统一走 TLS
- 高价值接口补签名和时效控制
- 会话票据短期有效并与连接或身份绑定
- 日志和监控避免输出敏感明文
七、常见误区
1. 自定义加密一定比 TLS 更安全
通常不是。大多数团队很难把自研协议做到比成熟 TLS 更稳。
2. 只要链路加密了，业务就安全了
重放、越权和幂等仍然要单独处理。
3. 所有消息都值得做很重的加密
要看成本和价值，重点保护关键链路。
参考资料
- TLS、消息签名和票据管理实践资料