字段级加密：到底在保护什么？
我先问个问题：你做过数据安全合规项目吗？
如果做过，八成会遇到同一个困境——DBA说“整张表加密太影响查询”，业务方说“有些字段不能动”，合规官说“个人信息必须加密”。你看，几边都在踢球。
我最早接触字段级加密是在一个银行客户那里。他们要对信用卡号做保护，但客户名字、交易金额这些完全不需要。全表加密？那是在BLOB里塞进去整张表的二进制，连索引都废了。后来我给他们搭了个字段级加密方案，只在cc_number列上做AES-256，其他列该查查，该统计统计。嗯，从那以后我就觉得，很多时候“一点保护”比“全面封锁”更实用。
什么是字段级加密？
字段级加密，按我的理解，就是只加密数据库表里的某些列（一个或多个字段），其他字段保持明文。你可以想象成：把保险柜嵌在一面普通墙上，墙本身不特殊，但那个格子是锁死的。
核心特征
- 细粒度：列级别，甚至行+列组合（例如只加密张三的身份证号，不加密李四的）
- 逐字段密钥：可为不同字段使用不同密钥，隔离风险
- 应用层或代理层实现：数据库本身通常不感知加密逻辑
说白了，字段级加密把“加密单元”从整张表缩小到一个个格子。用得好的话，既能满足合规，又不破坏大部分查询性能。
应用场景：GDPR 和 HIPAA 里的“硬钉子”
我见过太多团队对着GDPR第32条和HIPAA安全规则发愁。这两个法规不是闹着玩的——罚款按全球营收的百分比算，或者干脆吊销资质。它们对加密的要求非常明确：对个人数据/受保护健康信息采取适当保护措施。那什么是“适当”？字段级加密通常是审计师最买账的方案之一。
| 法规 | 要求领域 | 字段级加密的对应点 |
|---|---|---|
| GDPR（通用数据保护条例） | 个人数据（姓名、身份证号、位置、生物信息等） | 只加密敏感字段，非敏感字段不影响业务 |
| HIPAA（健康保险可携性及责任法案） | 受保护健康信息（PHI：病历、诊断、保单号等） | 最小权限 + 列级加密，降低数据泄露判罚风险 |
我的小建议
在做合规评估的时候，先列一张“敏感字段清单”，用字段级加密只覆盖这些列。别想着加密所有列，那不是安全，是给自己挖坑——性能差、调试难、备份恢复也麻烦。
字段级加密 vs 全表加密：一张表说清楚
有一次在客户现场，他们的架构师非说全表加密更“纯粹”。我问他：“你的用户表里password字段需要加密，但user_name和created_at呢？你也要加密？”他愣了一下。我接着说：“全表加密之后，你连按时间排序查注册日期都做不了，你的业务能不能忍？”最终他选择了字段级。其实说白了，两个方案没有好坏，看场景。
| 对比维度 | 字段级加密 | 全表加密 |
|---|---|---|
| 加密粒度 | 列/行级 | 整张表（通常存为BLOB或加密存储引擎） |
| 查询支持 | 非加密字段可正常过滤、排序、索引；加密字段仅支持等式匹配（如果使用确定性加密） | 几乎无法在数据库内查询，需要全部解密后应用层过滤 |
| 性能影响 | 只影响加密列的操作，“副作用”可控 | 读写整张表都需加解密，IO压力大 |
| 合规适配 | 灵活标记敏感字段，审计师容易理解 | 可能被认定为“过度保护”，反而不符合数据最小化原则 |
| 实现复杂度 | 中：需要管理多个密钥和加密策略 | 低：数据库层面统一下层加密，但对查询能力破坏大 |
| 常见误用 | 忘记加密关联的外键列导致数据泄露 | 把整个表加密后试图用应用层做模糊匹配，性能崩溃 |
我曾经踩过的坑
有个项目，团队选择全表加密来保护一个近百GB的日志表。上线后生产环境查询平均响应时间从50ms暴涨到3秒+，回滚花了整整一夜。后来改用字段级加密，只加密消息体列，其他时间戳、级别、来源IP都明文，查询恢复了，合规也过了。记住：安全不是非黑即白，是性价比平衡。
字段级加密在威胁模型中的位置
我们做威胁建模，目的是找出攻击者可能利用的路径，然后堵上。字段级加密堵的是这么几步：数据库泄露（比如DBA导出备份）、侧信道攻击（比如SQL注入读取内存中的明文字段）、以及合规申报中的“是否对敏感数据加密”这个审查点。
为什么不是全表加密？原因很简单：威胁模型关心攻击面。攻击者想要的是身份证号、病历摘要，而不是那些无关紧要的字段。你把整张表封死，等于把所有业务逻辑也封死了。但如果你只封死那几列，攻击者就算拿到表，看到的敏感列也是一堆乱码——而其他列照样可以用，不影响开发、运维和审计。
下面这张图我经常画在白板上。它展示了字段级加密与全表加密在数据库列层面的区别，以及威胁建模中关注的核心攻击面。
什么时候该选字段级加密？
我总结了一张清单，你可以直接拿去用：
- 你的数据集中，只有部分字段属于敏感数据（比如姓名、证件号、病历摘要）
- 业务需要对非敏感字段做索引、排序、分组、联表
- 合规审计明确要求对敏感数据列单独保护（比如GDPR第25条“数据保护设计”）
- 你希望最小化性能影响，不想动原有的数据库架构
- 你的威胁模型中识别出“数据库泄露”和“备份泄露”风险
再给一个实操经验
如果你们用的是MySQL或PostgreSQL，我建议先看看官方是否支持列级加密插件（MySQL的AES_ENCRYPT/AES_DECRYPT函数、PG的pgcrypto扩展）。实在不行，就在应用层用加密SDK，配合ORM拦截器实现。我曾经在Java项目里用MyBatis的TypeHandler做个透明加密，效果不错，审计也过了。
简单收个尾
字段级加密不是什么新东西，但它在威胁建模里是个很好用的控制手段——既能精准响应合规要求，又能保留大部分业务灵活性。我每次做架构评审，都会先问一句：“你真正需要保护的，是整张表还是那么几列？”十有八九答案是后者。那就从字段级开始吧。