1. 传输脱敏概述

大家好，我是老周。做安全这行十几年了，今天咱们聊聊传输脱敏。说实话，很多人一听到「脱敏」两个字，第一反应就是数据库里那些打星号的身份证号。嗯，那只是静态脱敏。传输脱敏，完全是另一回事。

什么是传输脱敏

传输脱敏，说白了就是——数据在网络上跑的时候，把敏感信息藏起来。不是存的时候藏，是传的时候藏。

你想想看，数据从 A 点到 B 点，中间要经过多少跳？交换机、路由器、负载均衡、网关……任何一个环节被截住，裸数据就全漏了。传输脱敏干的事，就是在数据离开源头之前，或者在路上，把敏感字段替换掉、加密掉、或者直接抹掉。

我习惯把它分成两类：

• 源头脱敏——数据发出前就处理掉，接收方拿到的是脱敏后的数据
• 链路脱敏——数据在传输过程中动态处理，不同节点看到不同级别的数据

举个例子。你在电商平台下单，订单信息从前端传到后端。如果做传输脱敏，前端发出去的时候，手机号中间四位就已经是 **** 了。后端收到的是 138****1234，不是完整号码。这就是源头脱敏。

为什么需要传输脱敏

这个问题我问过很多刚入行的朋友。他们的第一反应是：「不是有 HTTPS 吗？」

对，HTTPS 加密了传输通道。但通道加密不等于数据安全。为什么？

• 内部威胁——你的运维人员、中间件、日志系统，都能看到解密后的明文
• 第三方接口——你调了别人的 API，数据出去了，对方怎么处理你管不了
• 合规要求——PCI-DSS、GDPR、等保三级，都明确要求传输过程中对敏感字段做脱敏处理
• 日志泄露——我见过太多案例，HTTPS 没破，但日志里明文打印了身份证号

我曾经帮一家金融公司做安全审计。他们的交易系统用了 HTTPS，所有通信都加密。结果呢？运维人员在排查问题时，直接在日志里 grep 出了客户的银行卡号。为什么？因为应用层打印了完整的请求报文。HTTPS 没破，但日志把数据卖了。

从那以后，我建议所有项目都把传输脱敏作为默认选项，而不是可选项。

传输脱敏与静态脱敏的区别

很多新人容易搞混这两个概念。我画了一张对比图，你看完就清楚了。

我再用表格给你梳理一下关键差异：

对比维度	静态脱敏	传输脱敏
处理时机	数据存储前或存储后，离线批量处理	数据传输过程中，实时在线处理
数据流向	源库 → 脱敏 → 目标库	发送方 → 脱敏 → 接收方
可逆性	通常不可逆（测试环境不需要还原）	可逆或不可逆，取决于场景
对源数据影响	源数据不变，生成脱敏副本	源数据不变，传输内容被变形
典型工具	DataMask、Desensitizer、脚本批量处理	API网关、Sidecar代理、数据防泄漏DLP
合规场景	等保三级、GDPR数据脱敏存储	PCI-DSS传输加密、金融数据接口安全

传输脱敏的典型应用场景

说了这么多理论，咱们看看实际中哪些地方必须用传输脱敏。我挑几个最常见的场景：

1. API 接口数据脱敏

这是最普遍的场景。前端调后端接口，返回的 JSON 里包含手机号、身份证、银行卡号。在 API 网关层做传输脱敏，根据调用方的权限级别，返回不同脱敏程度的数据。

// 原始返回
{
  "userId": 1001,
  "phone": "13812345678",
  "idCard": "110101199001011234"
}

// 传输脱敏后（给普通前端）
{
  "userId": 1001,
  "phone": "138****5678",
  "idCard": "110101********1234"
}

// 传输脱敏后（给内部审核系统）
{
  "userId": 1001,
  "phone": "13812345678",
  "idCard": "110101199001011234"
}

你看，同一个接口，不同调用方看到的数据不一样。这就是传输脱敏的「按需脱敏」能力。

2. 日志采集与传输

我曾经遇到一个客户，他们的日志系统把用户密码明文写进了日志文件。虽然日志只在内网传输，但内网也不是绝对安全的。后来我们在日志采集代理层加了传输脱敏，所有匹配正则的敏感字段，在写入日志前就被替换成 [REDACTED]。

3. 数据库实时同步

主库到从库、生产库到分析库，这些同步链路经常被忽视。很多公司用 Canal、Debezium 做 Binlog 同步，数据在网络上明文传输。如果中间被人截了，整个数据库就裸奔了。

解决方案是在同步工具里嵌入脱敏插件，对 Binlog 中的敏感列做实时替换。这样从库拿到的数据已经是脱敏后的，不影响分析查询，但保护了敏感信息。

4. 第三方接口调用

你调用支付宝、、银行接口，数据出去了，你控制不了对方怎么处理。但你可以控制自己发出去的数据。比如给第三方传身份证号时，只传后四位，或者传一个脱敏后的令牌。

我习惯的做法是：在调用第三方接口之前，先经过一个脱敏代理层，把敏感字段替换成业务需要的脱敏格式。这样即使第三方被攻击，泄露的也是脱敏数据。

5. 消息队列与流处理

Kafka、RabbitMQ 这些消息中间件，数据在生产和消费之间是明文传输的。如果消息体里带了敏感信息，任何一个能访问 Broker 的人都能看到。

解决方案是在生产者端做传输脱敏，消息发出前就把敏感字段处理掉。消费者拿到的是脱敏后的消息，不影响业务处理，但保护了数据。