一、字段级加密SDK概述与核心概念

1.1 什么是字段级加密

我们先从最基础的问题说起。什么是字段级加密？说白了，就是只对数据表中某个或某几个敏感字段进行加密，而不是把整条记录或整张表都锁起来。

我之前做过一个金融数据共享平台的项目。业务方要求把用户的身份证号、手机号加密存储，但同时又需要支持姓名和地址的模糊查询。如果对整个数据库加密，查询性能直接崩掉。字段级加密刚好能解决这类痛点——只保护最敏感的部分，其他字段照常使用。

加密颗粒度	范围	性能影响	灵活性
库级加密	整个数据库文件	高，读写全部解密	低
表级加密	整张表的数据页	中，按页加解密	中
列级加密	某一列的全部值	中，按列处理	中
字段级加密	单个字段值	低，按需加解密	高

1.2 字段级加密SDK的典型架构

一个成熟的字段级加密SDK，通常包含下面这几个模块。我在设计早期版本时踩过不少坑，比如密钥管理模块和加解密引擎耦合太紧，后来重构才拆开。

1.3 核心概念：加密字段、密钥版本、数据格式

这三个概念是字段级加密SDK的基石，理解不透彻，后面版本升级一定会出问题。

1.3.1 加密字段

加密字段是指在数据模型中标记为「需要加密保护」的字段。注意，不是所有字段都要加密，只选真正敏感的那些。

我见过一个团队把所有 varchar 字段都加密了，理由是“保险”。结果业务方要做全文搜索，性能惨不忍睹。后来他们改成了只加密身份证、手机号、银行卡号这几个字段，查询效率提升了 5 倍。

1.3.2 密钥版本

密钥版本就是给每个密钥编号。为什么要这么做？因为密钥需要定期轮换，而且不同时间段加密的数据可能使用不同密钥。你想想看，如果只用一把固定密钥，一旦泄露，所有历史数据都会暴露。

密钥版本通常包含在密文的头部信息中。SDK 在解密时，先读取版本号，再找到对应的密钥进行解密。这样即使旧密钥被废弃，也能安全读取历史数据。

密钥版本号	生效时间	用途
v1	2023-01-01 ~ 2023-06-30	加密旧数据
v2	2023-07-01 ~ 2024-03-31	轮换密钥后加密新数据
v3	2024-04-01 至今	当前活跃密钥

1.3.3 数据格式

字段级加密SDK输出的密文，通常不是纯粹的字节流，而是带有结构化信息的。举个例子：[版本号][算法标识][密钥版本][初始向量][密文]。这个格式叫什么？我习惯叫它「加密数据包」。

格式设计的核心原则：自描述。就是说拿到这段密文，不需要外部查表，就能知道它用什么算法、哪个密钥版本加密的。

// 一个典型的加密数据包结构（伪代码）
struct EncryptedField {
    byte version;          // 数据格式版本，用于兼容性判断
    byte algorithm;        // 加密算法标识，如 0x01=AES-256-GCM
    int64 keyVersion;      // 密钥版本号
    byte[12] iv;           // 初始向量
    byte[] ciphertext;     // 真正的密文数据
    byte[16] authTag;      // 认证标签（GCM模式）
}

1.4 字段级加密的典型应用场景

讲完了概念，我们聊聊实际场景。什么情况下你会需要字段级加密SDK？

• 金融风控系统：身份证、银行卡号需要加密，但交易金额、交易时间需要明文计算。
• 医疗健康平台：病历中的患者姓名、诊断结论可能涉密，但检查项指标需要统计分析。
• 跨境电商：用户收货地址是敏感字段，但商品名称、价格需要全文检索。
• 企业内部系统：员工的薪酬字段需要加密，但部门、职级等字段允许普通查询。

1.5 本章核心知识点思维导引

到这里，第一章的骨架基本搭完了。我们快速回顾一下：

• 字段级加密保护的是「单个字段值」，不是整条记录，也不是整张表。
• SDK 的架构主要分三层：应用层 → 核心 API → 加密引擎/密钥管理/元数据管理。
• 三个核心概念：加密字段（选准目标）、密钥版本（支持轮换）、数据格式（自描述是核心）。
• 应用领域覆盖金融、医疗、电商、企业系统等对敏感数据有精细化管控需求的场景。

这些基础概念理解了，后面讲版本升级策略和兼容性测试的时候，你就知道哪些地方容易出问题了。