数据库敏感字段的加密方案

发布时间:2026-06-08 09:33

手机号、证件号、地址这类敏感字段存进数据库时，明文存储意味着一次拖库就造成全部泄露。加密是公认的对策，但加密方案的选择比加密本身更重要：在哪里加密、密钥放在谁手里、加密后还能不能查询，这些取舍决定了方案是否真正可用。常见的路线有应用层加密与存储层加密两条，各自适合不同的场景。 ## 两条路线的对比 应用层加密在数据写入数据库前由业务代码完成加密，读取后由业务解密。它的优势是保护边界最大：数据库管理员、备份文件、从库同步看到的都是密文，泄露面被压到应用层；密钥体系由业务自主掌控，可以做字段级的细粒度控制。代价也明显：加密后字段失去原生的等值与模糊查询能力，需要配合额外的索引设计，比如保留前几位做筛选列，或建立哈希索引列支持精确匹配；业务代码的复杂度上升，加密算法与密钥轮换都要自己实现。存储层加密由数据库或底层存储透明完成，应用无感知，全库或全表落盘即密文，查询能力完全保留。它的边界在于数据库进程内部仍是明文，掌握数据库高权限账号或拿到运行内存的人依然可以读到数据，且密钥管理依赖数据库或平台自身。 ## 各自的适用面 应用层加密适合字段级的核心敏感数据：用户身份信息、支付凭证、联系方式的存储，这类数据字段集中、查询模式相对固定，值得为它承担开发成本。存储层加密适合整体性的保护需求：满足落盘加密的合规要求、防备份介质丢失泄露、防磁盘被拔走读取，覆盖面广但粒度粗。两者并不互斥，成熟的做法通常是双层叠加：敏感字段应用层加密，全库再启用透明加密，分别应对不同的威胁。 ## 选择建议 选择前先回答三个问题：防的是谁，是外部拖库、内部越权还是介质丢失；查的是什么，敏感字段是否需要参与条件查询与排序；谁能管密钥，业务团队还是平台方。防外部与介质丢失为主，查询需求重，优先存储层方案；防内部与高权限滥用为主，字段查询模式简单，上应用层方案；两类威胁都真实存在，就双层并用。密钥管理是两条路线共同的命门，密钥与密文分离存放、定期轮换、恢复流程演练，缺一样方案都不完整。顺云用户可以先用云盘加密与快照保护兜住存储层，再针对最敏感的字段做应用层加密，按数据价值分层投入。