数据安全：敏感数据识别、加密存储、脱敏处理

数据安全这章，说白了就是给你的SDK加几道锁。但我得先泼盆冷水——锁再结实，你也不知道该锁哪扇门，那等于白干。我见过不少项目，一上来就全量加密，结果性能掉了30%，还被用户骂卡顿。问题的第一步，永远是先把敏感数据找出来。

敏感数据识别——先知道什么是“敏敏”

很多团队认为“敏感数据”就是密码和。其实远不止这些。拿我在Android SDK上踩过的坑来说，有一次上报数据里带着未脱敏的Android ID和IMEI，直接被合规审计打回来了。你想想看，用户根本没授权你拿这些。

SDK里常见的敏感数据类型，我列了一份清单：

类型 示例 识别方法
/ ClientSecret、Bearer 正则匹配 ([A-Za-z0-9-_]{20,})
用户凭证 明文密码、会话Cookie 参数名黑名单 + 内容熵检测
设备标识 IMEI、IMSI、MAC地址 静态扫描Hardcoded字符串
网络数据 HTTPS URL中的Query参数 抓包分析+日志关键词扫描
业务数据 订单金额、手机号、身份证 字段命名规则（如phone、id_card）
日志数据 verbose等级的输出参数 编译期注解 + 运行时Hook

个人习惯：我习惯把识别过程做成两步走。第一步，静态扫描源代码和资源文件，把硬编码的可疑值挖出来。第二步，运行时动态追踪，用自定义的日志拦截器把所有输出内容过一遍筛子。两者缺一不可。

加密存储——存得安全，用得放心

识别出敏感数据之后，就该考虑怎么存了。这里有两个维度：一是数据在本地保存（静态数据），二是数据在内存里流动（动态数据）。我建议你把关注点放在前者——静态加密，因为动态保存通常有系统机制帮你兜底。

加密算法怎么选？我个人习惯直接上AES-256-GCM。为什么？因为它不仅加密，还自带完整性校验。GCM模式会生成一个Tag，如果有人篡改了密文，解密时就能立刻发现。我在一个支付SDK里用过这个方案，配合KeyStore管理密钥，审计直接放行。

// 示例：AES-256-GCM 加密数据
public byte[] encryptData(byte[] plaintext, SecretKey key) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
    byte[] iv = new byte[12];
    SecureRandom.getInstanceStrong().nextBytes(iv);
    GCMParameterSpec spec = new GCMParameterSpec(128, iv);
    cipher.init(Cipher.ENCRYPT_MODE, key, spec);
    byte[] ciphertext = cipher.doFinal(plaintext);
    // 返回 iv + ciphertext + tag（tag已经在ciphertext末尾）
    ByteBuffer buffer = ByteBuffer.allocate(iv.length + ciphertext.length);
    buffer.put(iv);
    buffer.put(ciphertext);
    return buffer.array();
}

避坑指南：我曾经在一个项目里直接用String保存密钥，结果被反编译一锅端。后来我用Android KeyStore或iOS Keychain来存密钥，这些系统级安全区域能防止密钥被导出。记住：密码学算法的安全性，80%取决于密钥管理，20%才是算法本身。

密钥管理上，我推荐用密钥派生函数（KDF），而不是直接硬编码一个AES密钥。举个例子，你可以用用户的生物特征或者设备唯一ID作为输入，通过PBKDF2或Argon2生成一个256位的密钥。这样做的好处是：即使密钥被偷，换一个输入值就能重新生成。

警告：别试图自己拼凑加密方案，比如“先Base64再AES再MD5”。这种组装式加密通常抵不住专业攻击。直接走成熟的AES-GCM + 密钥管理服务（KMS）或硬件安全模块（HSM）。

脱敏处理——露得少反而更安全

加密存储解决了“偷不走”的问题，但有些场景你没法用加密。比如日志输出、测试环境的数据模拟、第三方数据共享。这时候就需要脱敏——把敏感信息隐藏起来，同时保持数据的可用性。

脱敏的方法很多，我按场景分成三类：

方法 描述 适用场景
动态数据屏蔽 运行时替换真实数据，如手机号 138****1234 日志、错误报告、用户界面
哈希/脱敏 用不可逆的哈希值替代原始数据 数据分析、A/B测试
截断/替换 保留部分特征信息，其余用固定字符填充 客服查询、工单系统

我个人习惯在日志脱敏上格外小心。因为日志太容易被忽视了。我记得有一次，SDK的调试日志里把完整的打印出来了，测试环境还好，一上线就被用户抓包抓到了。后来我强制所有日志输出走一个脱敏管道：数字和字母超过16位的，自动替换成“***”。

脱敏还有一个坑：别忘了边界情况。比如手机号只有7位怎么办？我建议做一个最小长度检查，长度不足的就直接不输出。你想想看，脱敏到最后变成了“***”，用户也不知道你在记什么，反而容易产生疑惑。

推荐的脱敏流程：

  1. 先对数据做分类（敏感/非敏感）
  2. 对敏感数据定义脱敏规则（屏蔽、哈希、截断）
  3. 在数据出口（日志、网络、UI、文件）设置脱敏拦截器
  4. 持续回归测试，确保脱敏不泄露原始数据

小技巧：如果你要用哈希脱敏，记得加盐（Salt）。不加盐的话，攻击者可以拿彩虹表反向查。我一般用UUID作为随机盐，每次哈希结果都不一样，即使同一部手机的不同时间日志也看不出关联。

SDK数据安全防御流程 数据采集 敏感数据识别 是否敏感？ 加密存储 AES-256-GCM 脱敏处理 屏蔽/哈希/截断 安全输出 是 否

识别、加密、脱敏，这三步构成了数据安全的基本防线。你不用一开始就做到完美，先跑通一个最小闭环：识别出你最核心的敏感数据类型，用加密存好它们，再用脱敏把日志擦干净。剩下的，慢慢补齐。我个人觉得，数据安全最重要的不是你用了多复杂的算法，而是你有没有把它当成一个持续的过程来做。

← 上一章 📖 返回目录 下一章 →