📚 课程目录第2章数据采集层安全

数据采集层安全：从源头掐住风险

数据采集层，说白了就是遥测系统的第一道防线。我做了这么多年安全，见过太多团队把精力都放在后端防护上，结果采集层被人捅了篓子。嗯，今天我们就聊聊这块。

采集层安全，核心就三件事：协议安全、设备身份、数据可信。这三件事做好了，后面能省一大半的麻烦。

核心观点：采集层安全不是可选项，而是遥测系统的生存底线。一旦采集层被攻破，后续所有安全措施都成了摆设。

一、采集协议安全：MQTT 与 CoAP 的攻防之道

遥测场景里，MQTT 和 CoAP 是两大主流协议。我个人的习惯是，选协议之前先想清楚：你的设备是省电型还是实时型？网络环境稳不稳定？

先说说 MQTT。这玩意儿基于 TCP，长连接，适合设备多、消息频繁的场景。但它的安全问题，很多人容易忽略。

我的经验：MQTT 默认不加密，所有消息都是明文传输。我曾经在一个客户现场发现，他们的 MQTT Broker 直接暴露在公网上，连用户名密码都是默认的 admin/admin。你想想看，这跟把家门钥匙挂在门口有什么区别？

MQTT 安全加固，我建议至少做到这几点：

启用 TLS/SSL：MQTT over TLS 是标配，端口通常是 8883。别再用 1883 明文端口了。
认证机制：除了用户名密码，建议用 X.509 证书做双向认证。设备端和服务端互相验证身份。
ACL 控制：每个设备只能发布和订阅它被授权的主题。别让一个温度传感器能去控制阀门。
Payload 加密：即使走 TLS，敏感数据最好再额外加密一层。防止 Broker 内部人员能看到数据。

再来看 CoAP。这协议基于 UDP，轻量级，适合资源受限的物联网设备。但 UDP 本身无连接、无状态，安全问题更突出。

对比维度	MQTT	CoAP
传输层	TCP（可靠连接）	UDP（无连接）
安全传输	TLS（MQTT over TLS）	DTLS（CoAP over DTLS）
默认端口	1883（明文）/ 8883（加密）	5683（明文）/ 5684（加密）
典型场景	车联网、工业遥测	智能家居、传感器网络
资源消耗	较高	较低

CoAP 的安全核心是 DTLS。DTLS 是 TLS 在 UDP 上的变种，解决了 UDP 丢包和重排序的问题。但 DTLS 有个坑——握手开销大。对于内存只有几十 KB 的传感器设备，完整的 DTLS 握手可能直接让设备死机。

注意：CoAP 还有一个容易被忽视的风险——IP 欺骗。因为 UDP 无连接，攻击者可以伪造源 IP 发送恶意请求。我曾经遇到过有人利用这个漏洞，伪造传感器数据导致整个监控系统误报警。解决方案是启用 DTLS 的客户端证书验证，或者在网络层做 IP 白名单。

二、设备身份认证：别让"李鬼"混进来

设备身份认证，说白了就是回答一个问题："你是谁？" 这个问题回答不好，后面所有数据都不可信。

我见过最离谱的案例：某工厂的遥测系统，所有设备都用同一个 API Key 认证。结果一个传感器被黑客控制，拿到了 API Key，整个工厂的 2000 多个设备全部沦陷。嗯，这就是典型的"一把钥匙开所有锁"。

设备身份认证，我推荐以下几种方案：

X.509 证书认证：每个设备出厂时烧录唯一证书。服务端验证证书链。这是最安全的方式，但管理成本高。
预共享密钥（PSK）：设备和服务端共享一个密钥。适合资源受限设备，但密钥分发是个难题。
设备指纹：结合硬件信息（MAC、芯片序列号等）生成唯一指纹。适合做辅助认证。
动态令牌：每次连接使用一次性令牌，防止重放攻击。

最佳实践：我个人习惯用"证书 + 设备指纹"的双因子认证。证书做主要认证，设备指纹做二次校验。即使证书泄露，攻击者没有对应的硬件也登不进来。

这里给出一段 MQTT 证书认证的配置示例：

// MQTT 客户端证书认证配置示例
const mqtt = require('mqtt')

const options = {
  host: 'broker.example.com',
  port: 8883,
  protocol: 'mqtts',
  // 客户端证书
  key: fs.readFileSync('./device-key.pem'),
  cert: fs.readFileSync('./device-cert.pem'),
  // CA 证书链
  ca: [fs.readFileSync('./ca-chain.pem')],
  // 要求服务端验证客户端证书
  rejectUnauthorized: true,
  // 客户端 ID 必须唯一
  clientId: 'device-001-sn-a1b2c3'
}

const client = mqtt.connect(options)

client.on('connect', () => {
  console.log('设备认证成功，已连接到 Broker')
  client.subscribe('telemetry/device-001/#')
})

三、数据源可信验证：数据到了，但真的是它发的吗？

设备认证通过后，是不是就万事大吉了？不是。你想想看，如果攻击者截获了设备的合法连接，然后篡改数据包内容，怎么办？

这就是数据源可信验证要解决的问题。核心手段是数据完整性校验和来源不可否认性。

我常用的方法有：

数字签名：设备用私钥对每条遥测数据签名，服务端用公钥验签。确保数据未被篡改，且确实来自该设备。
消息认证码（HMAC）：用共享密钥对数据计算 HMAC。比数字签名轻量，但不能提供不可否认性。
时间戳 + 序列号：每条数据带上时间戳和递增序列号，防止重放攻击。

避坑指南：我曾经在一个项目中只用了 HMAC，结果设备密钥被逆向工程提取了。攻击者用提取的密钥伪造了海量数据，导致后端存储爆了。后来我改成"数字签名 + 时间戳"双保险，虽然计算开销大了点，但安全性上了好几个台阶。

来看一个 CoAP 数据签名的实现思路：

// CoAP 数据签名示例（伪代码）
// 设备端
function signTelemetry(data, privateKey) {
  const payload = {
    deviceId: 'device-001',
    timestamp: Date.now(),
    sequence: getNextSequence(),
    data: data
  }
  
  // 计算签名
  const signature = sign(JSON.stringify(payload), privateKey)
  payload.signature = signature
  
  return payload
}

// 服务端验证
function verifyTelemetry(payload, publicKey) {
  // 1. 检查时间戳是否在允许窗口内（±5秒）
  if (Math.abs(Date.now() - payload.timestamp) > 5000) {
    throw new Error('数据已过期，可能为重放攻击')
  }
  
  // 2. 检查序列号是否重复
  if (isSequenceReplayed(payload.deviceId, payload.sequence)) {
    throw new Error('序列号重复，检测到重放攻击')
  }
  
  // 3. 验证签名
  const signature = payload.signature
  delete payload.signature
  const isValid = verify(JSON.stringify(payload), signature, publicKey)
  
  return isValid
}

这里有个关键点：时间窗口。我建议时间窗口不要超过 5 秒，太宽容易给攻击者留机会，太窄又容易因为网络延迟误杀正常数据。具体值要根据你的网络状况调整。

重要提醒：数据源可信验证不能替代设备身份认证。它们是互补关系——设备认证解决"你是谁"，数据可信解决"你说的是不是真的"。两者缺一不可。

小结

数据采集层安全，说白了就是三道关：协议安全守住通道，设备认证守住入口，数据可信守住内容。这三道关都过了，采集层才算真正安全。

嗯，我记得刚入行时总觉得这些是"过度设计"，直到亲眼看到一次因为采集层漏洞导致整个系统瘫痪的事故。从那以后，我再也不敢在采集层安全上偷懒了。