把人脸设备直接暴露公网这份协议的安全设计得先搞懂设备要跨公网连服务器第一反应肯定是安全吗。我刚翻这份协议时也有点犯嘀咕——XML 明文 WebSocket这不跟裸奔似的后来把各命令串起来看发现协议其实埋了几层防护只是散在不同地方得自己拼。这篇就聊聊设备接入的安全设计给做平台、做 SaaS 的同行提个醒。一、传输层ws 还是 wss差着一个天地协议原文写得很直白设备菜单里设的 URL 形如ws://sample/ 或 wss://sample一字之差天壤之别。ws是明文人脸模板、考勤日志、甚至远程开门指令都在里面裸奔wss是 TLS 加密。生产环境毫无悬念选wss。我见过有项目图省事用ws在内网联调结果上线忘了改数据全明文出去了——这种低级错误真不是吓唬人。二、连接韧性每 10 秒重连协议说上电后设备每 10s 尝试连服务器连接关闭自动重试。意味着你服务器重启、网络短暂抖动设备自己会兜回来不用人工干预。但反过来想——如果有人拿非法请求狂连设备也会忠实地每 10s 重试。所以服务器侧做好限流和鉴权比指望设备乖重要得多。三、CloudId 白名单租户隔离的钥匙更新日志里 2016/03/12 那条写得很关键Added theCloudIdtag in the Register request from the device, so that the server can deny the connection attempt of the devices with the invalid cloud id.Register请求里带了CloudIdServer 可以拒绝 cloud id 非法的设备连接。这其实就是个租户/项目隔离标识——多客户 SaaS 场景下A 客户的设备带 A 的 cloud idB 客户的带 B 的从根本上混不到一块。做平台的人这个一定得用上不然多客户数据就串了。四、Token 校验设备身份的密码注册阶段协议 2.2 Registration的逻辑是管理员把设备序列号录进数据库Server 生成 token 并存库。设备Register时带上来Login时再校验。2023/9/27 的更新日志还专门给Login加了Updated Login to add Result: FailUnknownTokentoken 对不上直接拒绝。所以 token 是设备身份的核心凭证——必须在服务端生成、存库、定期轮换千万别硬编码在客户端固件里。五、TransID防重放的关键每条消息包括设备主动推的TimeLog_v2都带TransIDxxx/TransID服务器回Response时也回同一个TransID!-- 设备推来的事件 --EventTimeLog_v2/Event...TransIDxxx/TransID!-- 服务器回 --ResponseTimeLog_v2/ResponseTransIDxxx/TransIDResultOK/Fail/Result这东西看着不起眼作用大着一是把请求和响应关联起来异步消息流里分清谁是谁二是可以做去重 / 防重放。想想TakeOffManager那种远程强开门指令——如果没有 TransID 校验重放攻击随便就能再开一次门。细思极恐所以这步不能省。六、KeepAlive 心跳2016/08/04 新增的KeepAlive命令维持长连接。配合上面每 10s 重连链路基本不会假死。wss TLS 加密CloudId 白名单通过通过设备端服务器接入层: 拒绝非法 cloud idLogin: Token 校验 FailUnknownToken消息层: TransID 关联 去重KeepAlive 心跳保活正常命令/事件循环坑和建议都是真家伙生产必须wssws明文等于把人脸模板送人。token 服务端管别下发写死支持轮换别用永久有效的。CloudId 当租户隔离多客户系统必备提前规划。TransID 必须校验否则远程控制类指令有重放风险开门那种最要命。wss 证书要有效。注意设备端似乎有不校验证书的开关协议里SetUserData出现过AllowNoCertificate字段生产环境别开这个选项。服务器侧限流 鉴权设备会 10s 重试别被它刷爆。安全这东西没出事前都觉得多余出了事就是大事。这份协议给的防护够用但得你真去用——尤其是wss和token这两道别偷懒。下一篇换个轻松点的写法直接给你一份出事了对着查的排障手册。
把人脸设备直接暴露公网这份协议的安全设计得先搞懂设备要跨公网连服务器第一反应肯定是安全吗。我刚翻这份协议时也有点犯嘀咕——XML 明文 WebSocket这不跟裸奔似的后来把各命令串起来看发现协议其实埋了几层防护只是散在不同地方得自己拼。这篇就聊聊设备接入的安全设计给做平台、做 SaaS 的同行提个醒。一、传输层ws 还是 wss差着一个天地协议原文写得很直白设备菜单里设的 URL 形如ws://sample/ 或 wss://sample一字之差天壤之别。ws是明文人脸模板、考勤日志、甚至远程开门指令都在里面裸奔wss是 TLS 加密。生产环境毫无悬念选wss。我见过有项目图省事用ws在内网联调结果上线忘了改数据全明文出去了——这种低级错误真不是吓唬人。二、连接韧性每 10 秒重连协议说上电后设备每 10s 尝试连服务器连接关闭自动重试。意味着你服务器重启、网络短暂抖动设备自己会兜回来不用人工干预。但反过来想——如果有人拿非法请求狂连设备也会忠实地每 10s 重试。所以服务器侧做好限流和鉴权比指望设备乖重要得多。三、CloudId 白名单租户隔离的钥匙更新日志里 2016/03/12 那条写得很关键Added theCloudIdtag in the Register request from the device, so that the server can deny the connection attempt of the devices with the invalid cloud id.Register请求里带了CloudIdServer 可以拒绝 cloud id 非法的设备连接。这其实就是个租户/项目隔离标识——多客户 SaaS 场景下A 客户的设备带 A 的 cloud idB 客户的带 B 的从根本上混不到一块。做平台的人这个一定得用上不然多客户数据就串了。四、Token 校验设备身份的密码注册阶段协议 2.2 Registration的逻辑是管理员把设备序列号录进数据库Server 生成 token 并存库。设备Register时带上来Login时再校验。2023/9/27 的更新日志还专门给Login加了Updated Login to add Result: FailUnknownTokentoken 对不上直接拒绝。所以 token 是设备身份的核心凭证——必须在服务端生成、存库、定期轮换千万别硬编码在客户端固件里。五、TransID防重放的关键每条消息包括设备主动推的TimeLog_v2都带TransIDxxx/TransID服务器回Response时也回同一个TransID!-- 设备推来的事件 --EventTimeLog_v2/Event...TransIDxxx/TransID!-- 服务器回 --ResponseTimeLog_v2/ResponseTransIDxxx/TransIDResultOK/Fail/Result这东西看着不起眼作用大着一是把请求和响应关联起来异步消息流里分清谁是谁二是可以做去重 / 防重放。想想TakeOffManager那种远程强开门指令——如果没有 TransID 校验重放攻击随便就能再开一次门。细思极恐所以这步不能省。六、KeepAlive 心跳2016/08/04 新增的KeepAlive命令维持长连接。配合上面每 10s 重连链路基本不会假死。wss TLS 加密CloudId 白名单通过通过设备端服务器接入层: 拒绝非法 cloud idLogin: Token 校验 FailUnknownToken消息层: TransID 关联 去重KeepAlive 心跳保活正常命令/事件循环坑和建议都是真家伙生产必须wssws明文等于把人脸模板送人。token 服务端管别下发写死支持轮换别用永久有效的。CloudId 当租户隔离多客户系统必备提前规划。TransID 必须校验否则远程控制类指令有重放风险开门那种最要命。wss 证书要有效。注意设备端似乎有不校验证书的开关协议里SetUserData出现过AllowNoCertificate字段生产环境别开这个选项。服务器侧限流 鉴权设备会 10s 重试别被它刷爆。安全这东西没出事前都觉得多余出了事就是大事。这份协议给的防护够用但得你真去用——尤其是wss和token这两道别偷懒。下一篇换个轻松点的写法直接给你一份出事了对着查的排障手册。
)
