4. 字段加密粒度与策略配置
聊到字段级加密，最核心的一个问题就是：到底加密哪些字段？
全量加密听起来最安全，但性能代价你扛得住吗？只加密敏感字段又怕漏掉关键信息。我个人习惯是，先把业务字段分三类：核心敏感字段（身份证、手机号）、高价值字段（地址、邮箱）、普通字段（昵称、备注）。
4.1 全字段加密
顾名思义，就是把表中所有字符串字段都加密。这种策略在早期SDK设计中很常见，因为“宁可错杀，不可放过”。
优点：安全等级高，不存在“漏加密”的问题。我在项目中遇到过，合规审计时对方只问一个问题：“你们确定所有敏感字段都加密了吗？”——如果是全字段加密，你直接回答“是”。
缺点：性能开销大，尤其是索引字段。
我曾经踩过的坑：在某个金融项目中，全字段加密了一个用户表，结果WHERE条件里对手机号做精确查询，每次都要遍历全表解密——因为加密后无法使用普通索引。后来切成了确定性加密+部分加密才解决。
// 全字段加密配置示例（伪代码）
sdk.configureTable("user", new TableConfig()
.setEncryptAllFields(true) // 全部加密
.setEncryptAlgorithm("AES-256-GCM")
.setDeterministic(false) // 随机加密
);
4.2 部分字段加密
这是目前生产环境的主流做法。你想想看，不加密的字段可以走索引、做排序、参与join，收益是性能，风险是漏掉敏感字段。
我建议的筛选原则：
- 必加密：身份证、手机号、银行卡、密码、密钥
- 建议加密：地址、邮箱、真实姓名
- 可免加密：用户名、注册时间、状态标记
为什么会这样？因为要平衡安全与性能。记得我参与的一个电商订单表，订单金额和收货地址加密了，但订单状态和商品ID没加密——这样大批量的统计查询就能直接走索引，性能提升十几倍。
// 部分字段加密配置
sdk.configureTable("order", new TableConfig()
.setEncryptFields(Arrays.asList("phone", "id_card", "address"))
.setPlainFields(Arrays.asList("order_id", "status", "amount"))
);
| 对比维度 | 全字段加密 | 部分字段加密 |
|---|---|---|
| 存储开销 | 高（膨胀30%~50%） | 低（仅加密字段膨胀） |
| 查询性能 | 差（索引失效） | 好（非加密字段可用索引） |
| 迁移兼容性 | 差（所有字段需转换） | 好（逐步迁移） |
| 安全覆盖率 | 100% | 依赖配置准确性 |
4.3 动态配置
好，前面两种都是静态配置——SDK启动时就定死了。但现实是，业务需求会变。
我记得有一次，业务方突然说：“我们要把用户邮箱也加密，合规要求临时升级了。”如果是静态配置，得重新打包发版、重启服务，甚至做数据迁移。太慢了！
动态配置就是解决这个痛点的。它允许你在运行时不重启应用，通过远程配置中心或数据库动态调整加密策略。
实现方案：配置中心（如Nacos、Apollo）+ 热加载机制。SDK定期拉取配置，比对本地的策略映射，发现有变更就重新初始化加密上下文。
// 动态配置示例（通过配置中心获取）
// 假设配置中心的JSON如下:
// { "table": "user", "encryptFields": ["phone","email","address"] }
public void refreshConfig(String tableName, JSONObject config) {
List<String> encryptList = config.getJSONArray("encryptFields").toJavaList(String.class);
// 重新加载加密映射
this.fieldEncryptorMap.put(tableName, new FieldEncryptor(encryptList));
// 不影响已有的连接，新请求走新配置
}
动态配置的核心挑战有两个：
- 一致性：配置变更期间，旧数据和新数据如何共存？我建议用“灰度切换”——先读旧配置解密，写数据用新配置加密。
- 安全：配置本身不能明文传输，否则加密策略泄露等于开了后门。配置通道建议走TLS，配置内容加密存储。
避坑指南：我曾经遇到过配置推送到一半，SDK热加载失败的情况。原因很简单——新旧线程同时持有加密上下文，导致部分请求解密异常。后来我加了一个双缓冲机制：配置变更时先准备新上下文，等所有旧请求处理完再原子切。你可以参考这种设计。
最后总结一下三种策略的适用场景：
- 全字段加密：用于数据量小、合规要求极高、索引需求弱的场景
- 部分字段加密：生产环境默认选项，平衡安全与性能
- 动态配置：用于频繁业务迭代、多环境异构的场景（如dev/test/prod差异化加密）
嗯，其实没有银弹。你需要在项目早期就设计好策略的可扩展性——哪怕现在只需要部分字段加密，也建议在架构上预留动态配置的能力。要不然后面改起来会很痛苦。