IMSI隐私合规检测与APP服务端存储安全加固实践

大多数做APP整改的朋友，关注点都在客户端怎么改、SDK怎么换。但作为一个经历过完整整改周期的技术负责人，我想说一个很容易被忽视但却极其重要的环节——服务端的数据存储安全。这篇文章我会把我们家APP从隐私合规检测到服务端存储加固的完整过程写出来，重点聊聊IMSI相关的数据怎么清理、存储怎么加固、以及如何通过合规检测。

一、隐私合规检测：第一次知道“灯下黑”是什么感觉

我们APP在整改之前，其实已经做过一次隐私合规检测了。但那次检测是“形式性”的——我们自己拿着检测机构的清单逐项核对，觉得该做的都做了。结果正式检测一出来，傻眼了。

问题出在服务端。

检测机构在我们的APP里做数据抓包，发现APP会在用户登录时，把IMSI作为参数传给服务器。然后他们又“假装”攻击了我们的服务器接口，通过越权访问的方式，发现服务器上存储了大量历史IMSI数据，而且明文存储、没有任何加密。

这个问题的严重性在于：

• 虽然我们已经把客户端的IMSI采集停了，但服务端的历史数据还在“裸奔”。
• 历史数据一旦泄露，就构成了数据安全事故。
• 等保测评中，服务端数据保护是重要评分项，这一项扣分非常严重。

那一刻我才明白——整改不能只盯着客户端，服务端才是“灯下黑”的地方。

二、服务端存储加固：从“裸奔”到“全副武装”

确定了问题后，我们制定了服务端存储加固方案，分成五个层面来做。

层面一：存量数据治理

我们最紧急的任务，是处理服务端里已经存了的几百万条IMSI数据。

处理逻辑是这样的：

1. 用脚本把用户表里的imsi字段全量读出来。
2. 对每个IMSI做SHA-256加盐哈希，盐值从密钥服务获取。
3. 把哈希后的值存入新字段imsi_hash。
4. 删除imsi字段。
5. 备份库和从库同样操作。

这个过程比我想象的要复杂。因为有好几个老业务模块在查询时直接依赖imsi字段，我们删掉之后，这些查询就报错了。我们花了额外的时间把这些查询全部改成了用imsi_hash来关联。

层面二：存储加密选型

在处理完历史数据后，我们也重新设计了新数据的存储策略。我们对比了两种主流方案：

我们最终选择了应用层加密。具体做法是：在数据写入数据库之前，用AES-256算法对敏感字段进行加密，写入时存入密文；读取时再解密。密钥由密钥管理服务（KMS）统一管理，不在代码里硬编码。

层面三：访问权限控制

我们还发现，我们有几个内部系统（比如BI报表系统）也能直接访问用户表的IMSI相关字段。这其实是不允许的——内部系统的安全级别往往没有生产系统高，一旦被攻破，数据就全泄露了。

我们做了权限收敛：

• 生产环境数据库只有运维和核心开发人员能访问。
• 测试环境、BI环境的数据库完全不包含真实IMSI数据。
• 所有数据库操作启用了审计日志，谁查了、查了什么、什么时候查的，全部记录。

层面四：传输安全加固

虽然我们已经是HTTPS了，但安全团队评估后认为还不够。我们额外做了两件事：

1. 证书固定（Certificate Pinning）：APP端内嵌了服务端证书的哈希值，只有匹配的证书才能建立连接，有效防止中间人攻击。
2. 请求体加密：所有包含用户敏感信息的请求体，在APP端先用AES加密，到服务端再解密。这样即使HTTPS被破解，数据仍然是安全的。

层面五：定期数据销毁机制

我们建立了数据生命周期管理机制：

• 用户主动注销账号后，所有相关数据在30天内彻底删除。
• 超过3年未登录的僵尸账号，数据做脱敏处理。
• 每季度执行一次数据清理任务，删除过期的日志和备份。

三、合规检测通过：我们的验收标准

所有整改完成后，我们又做了一次完整的隐私合规检测。这次我们制定了自己的验收标准，确保没有任何遗漏：

这次检测，我们终于拿到了“全部通过”的结果。

四、关于服务端加固的两个选择

在服务端加固的过程中，有两个选择我想单独拿出来说说。

选择一：自己写加密工具，还是用专业方案？

我们一开始的打算是自己写一个加密工具类，简单用AES加密一下就好了。但后来考虑到：

• 密钥管理是个大问题，我们自己搞的KMS不专业。
• 加密算法的选型、模式、填充方式都有讲究，用错了反而有安全漏洞。
• 服务端加密和客户端加固最好能联动起来。

基于这些考虑，我们最终还是选择了和几维安全合作。他们的方案不仅覆盖了客户端代码虚拟化加固，还提供了服务端安全检测和加固建议。几维安全作为行业TOP级的厂商，服务过4万多款APP，在服务端数据安全方面有很多经验沉淀。他们帮我们做了几件事：

• 检测了服务端接口是否存在数据泄露风险。
• 针对敏感数据存储提供了加密方案建议。
• 帮我们梳理了服务端的密钥管理策略。
• 通过隐私检测系统联动，确保客户端和服务端的数据安全策略一致。

如果是我自己闭门造车，可能到现在还在纠结CBC模式和GCM模式哪个更适合我们的场景。

选择二：数据脱敏是做哈希还是加密？

对于历史存量数据，哈希和加密的选择也让我们纠结过：

我们最终选择了哈希。因为我们确认了业务上不再需要原始IMSI，用不可逆哈希是最安全的方式。

五、避坑指南

总结

IMSI整改这件事，回头看最大的感悟就是：客户端是面子，服务端是里子。 面子做好了（客户端不采了），里子没做好（服务端还存着），一样过不了合规检测。从存量数据治理到存储加密选型，从访问权限控制到定期销毁机制，每一个环节都马虎不得。在这个过程中，几维安全的隐私检测系统和安全咨询服务给了我们很多专业支持，尤其是他们的全链路视角——既看客户端也看服务端，帮我们补上了很多认知盲区。希望我的经验能帮到大家，别在服务端这个“灯下黑”的地方栽跟头。

常见问题

Q1：服务端历史存量IMSI数据做哈希加盐时，应该选用什么哈希算法？盐值如何处理？ 推荐使用SHA-256或更高级别的哈希算法（如SHA-384）。盐值必须做到每个数据独立（不能所有数据用同一个盐），建议使用安全的随机数生成器生成至少128位的盐值，并与哈希值一同存储。盐值的管理建议使用密钥管理服务（KMS）统一分发，不要硬编码在代码中。

Q2：如果业务确实需要保留IMSI的历史数据用于审计，有什么折中方案？ 如果审计要求必须保留原始IMSI，建议走“分离存储+强访问控制”路线：将IMSI数据从主业务库中分离出来，单独存储到一个独立的、加密的、访问权限极严格的审计库中。主业务库只存哈希值，业务逻辑用哈希关联。审计库需要双人授权才能访问，并且所有访问操作都被审计日志记录。

Q3：服务端加密存储应该选择TDE还是应用层加密？ 两者各有适用场景。TDE的优势在于对应用透明，无需改造代码，适合已有系统快速启用加密；劣势在于密钥管理复杂，且通常是全库加密而非字段级。应用层加密的优势在于灵活可控，能针对敏感字段单独加密，适合需要精细控制加密粒度的场景；劣势在于需要改造代码。对于IMSI这类敏感字段，我们推荐应用层加密，因为它能更精准地保护特定数据。

Q4：数据销毁的合规要求是什么？一般建议多久销毁一次？ 根据《个人信息保护法》及相关法规，个人信息的保存期限应当为实现处理目的所必要的最短时间。超过保存期限的，应当删除或匿名化处理。具体的时间周期取决于业务需求：用户注销后通常30天内删除；僵尸账号（如3年以上未登录）建议做脱敏处理；日志数据建议保留6个月到1年，超过后自动清理。

Q5：服务端接口被越权访问的风险如何防范？ 越权访问主要分为水平越权（用户A访问用户B的数据）和垂直越权（普通用户访问管理员数据）。防范措施包括：① 每个接口都必须做身份校验，不能依赖前端传来的用户ID做权限判断；② 使用统一的权限中间件，对所有接口做权限拦截；③ 敏感数据接口额外做二次校验（如验证Token中的用户ID与请求中的用户ID是否一致）；④ 启用操作审计日志，所有数据访问行为都可追溯。