物流WMS等保三级,到底哪些数据要加密:加密范围判定与落地
测评现场:问"加密范围怎么定的",答不上来
某物流企业 WMS 系统做等保三级测评,测评员问了两个问题,项目组当场卡壳:
"你们的加密范围是怎么划定的?哪些表加密了、依据是什么?" "WMS 和承运商、关务系统的数据交换,传输和落库怎么保护的?"
很多人做等保整改,第一反应是"把所有数据库都加密一遍"。但测评问的不是"你有没有加密",而是**"你的加密范围有没有依据、边界清不清楚"**。范围划得乱七八糟,比不加密更难看。
加密范围判定的逻辑:不是全部,是"重要数据"
等保三级"数据保密性"要求的是重要数据加密存储,不是全库加密。判定的通用逻辑是三步:
第一步:盘点数据 → 按类型归类(客户/货值/订单/配置) 第二步:定敏感级 → 哪些是个人信息、商业敏感、可溯责数据 第三步:划加密范围 → 敏感数据落库加密,其余按需要落在这个逻辑上,WMS 里优先加密的是这几类:
| 数据类别 | 具体内容 | 为什么加密 |
|---|---|---|
| 收货人个人信息 | 姓名、手机号、地址 | 个人信息保护要求 |
| 货值与结算 | 货值、运费、结算单 | 商业敏感,可溯责 |
| 报关/EDI报文 | 报关数据、EDI 交换报文 | 海关数据安全要求 |
| 合同与供应商 | 合同价、供应商信息 | 商业机密 |
不急着加密的是:库存流水、操作日志这类体量大、敏感度低的表——加密它们只会拖累查询性能,却换不来合规收益。
数据交换安全:WMS 的另一半
WMS 加密不能只盯落库,数据交换是物流系统特有的风险面——WMS 要跟一堆外部系统打交道:
| 交换对象 | 交换方式 | 要保护什么 |
|---|---|---|
| 承运商/TMS | EDI 报文、API | 报文完整性、防篡改 |
| 关务/报关系统 | 报关数据接口 | 传输加密、签名 |
| 上游 ERP | 订单/库存接口 | 数据机密性 |
| 仓储设备 | WCS/RF 手持机 | 指令与回执可信 |
数据交换安全的落点:
- 传输加密:WMS 与外部系统间走国密加密通道,报文加密传输,避免明文在链路上被截获
- 签名验签:EDI 报文、报关数据加签名,接收方验签,保证"是谁发的、有没有被改"
- 文件摆渡管控:WMS 导出的报表、对账文件,加密后再传输,别裸奔
落地:范围划定后,怎么动库
加密范围定了,落库就按范围逐表启用透明加密,在线执行、不停机、不锁表:
-- 收货人信息表启用透明加密(SM4,在线,不停机) EXEC tde_enable_table_encryption @database_name = 'wms_core', @table_name = 't_receiver_info', @encryption_algorithm = 'SM4_256', @key_id = 'tde_wms_receiver_key', @rotation_interval_days = 90, @mode = 'online';加密密钥统一由密钥管理平台管,90 天自动轮换,根密钥进硬件密码机永不导出。这样测评要"加密范围依据"时,能直接给出:哪几张表、什么依据、用什么密钥、多久轮换——一张表讲清楚。
踩坑:加密范围判定的三个误区
误区一:全库加密,性能背锅。把库存流水这种高吞吐低敏感的表也加密,查询性能下降明显,等保没加分,运维先叫苦。范围要按敏感级划,不是多多益善。
误区二:只加密传输,不加密落库。数据交换通道加密了,但落库还是明文——"数据保密性"这一项照样不达标。传输和存储是两块,都要覆盖。
误区三:漏了备份文件。核心表加密了,但备份文件明文散落在存储里——拖库绕不过数据库,拖备份文件一拖一个准。备份要纳入加密范围,恢复演练在解密端执行。
验收:四条能向测评证明
| 验收项 | 怎么验 |
|---|---|
| 加密范围有依据 | 给出数据分类分级表,加密范围与之对应 |
| 核心敏感表加密 | 无授权直查收货人/结算表输出密文 |
| 交换报文防篡改 | 修改一条 EDI 报文,验签失败 |
| 备份文件不可读 | 直接打开备份文件内容为密文 |
WMS 等保三级的加密,关键不是"加密了多少",而是**"加密范围划得清、落得实、讲得明"**。按数据敏感级划范围、传输存储都覆盖、备份别漏——这套逻辑同样适用于其他业务系统。安当 TDE 数据库透明加密、KSP 密钥管理、HSM 密码机,可支持物流 WMS 等保三级的加密整改落地。
文章作者:安当加密技术负责人