企业官网建设流程全解析

1. 为什么我最终选择了“手动加密”：从一次等保整改说起

先交代一下背景。前两年做某省项目的数据库国产化改造，业务库从Oracle迁移到人大金仓KingbaseES V8，迁移本身不算难，难的是后面跟上来的等保测评整改项。测评报告里有一条：“敏感数据字段（身份证号、手机号、银行卡号）未加密存储，存在数据泄露风险”。当时有两个方案可选：启用数据库自带的透明加密（TDE）功能，或者做列级加密。但因为业务系统的特殊性，加上数据库版本和企业版Licence的限制，TDE在项目里走不通，而列级加密在当时版本里也没法直接覆盖所有需要加密的字段。最后我这边确定的技术路线是：在应用层和数据库函数层做“手动加密”，把敏感字段以密文形式落库。

这篇内容不是什么高深的理论课，就是把我这次在KingbaseES V8R6上做手动加密的全过程、踩过的坑、以及最终在Java端和SQL端都跑通的方案整理出来。如果你也在做人大金仓数据库的数据加密改造，或者正被等保测评里“敏感数据存储加密”这一条卡住，这篇文章应该能直接帮你省掉一大段时间。

先说结论：“手动加密”这个说法，听起来好像很原始，但实际上它是绕开TDE版本限制、灵活控制加解密权限、满足审计要求的最稳妥路径。它的本质就是：数据在进入数据库落盘之前，先按既定算法加密成密文；数据被读取时，由业务方或数据库函数实时解密回明文。整个过程里，数据库存储的一律是密文，即使备份文件被拖走，拿到的也只是加密后的乱码。

2. 方案选型：SM4国密算法加Java与SQL双路线

2.1 为什么选用国密SM4而不是AES

做国产化项目，第一原则是“自主可控优先”。虽然KingbaseES底层兼容PostgreSQL和Oracle的生态，AES算法也能跑，但在政企和金融类项目中，测评方更认可国密算法。SM4是国密标准里的分组对称加密算法，分组长度128比特（16字节），密钥长度也是128比特，算法结构公开透明，国内很多主流密码机、安全网关都对它有硬件级支持。

我最终选的是SM4/ECB/PKCS5Padding还是SM4/CBC/PKCS5Padding？

这里得说明白，如果你对加密模式没有特别要求，我强烈建议不要用ECB。ECB模式下，相同的明文分组会产生相同的密文分组，容易受到模式分析攻击。我实际用的是SM4/CBC/PKCS5Padding，CBC模式每次加密前会把当前明文分组和上一个密文分组做异或运算，配合随机初始化向量（IV），即使两条明文完全一样，加密后的密文也不一样，安全性明显更好。

2.2 两条加密路线的分工

KingbaseES支持的开发接口很丰富，JDBC、ODBC、PL/SQL、PL/pgSQL都有。我在这次项目里，按照业务场景把“手动加密”拆成了两条路线：

两条路线可以并存，我在项目里就是“Java加密为主、SQL函数兜底”。后面第3节和第4节，我会把两套具体实现完完整整放出来。

3. Java端落地：JDBC写入加密、读取解密的完整实现

3.1 环境说明

• KingbaseES V8R6，数据库兼容模式设置为Oracle（我们的业务原先跑在Oracle上）
• JDBC驱动：kingbase8-8.6.0.jar（人大金仓官方驱动，从安装目录的JDBC子目录里能找到）
• Java版本：1.8以上（项目中用的1.8）
• 加密工具包：BouncyCastle（bcprov-jdk15on）来支持SM4算法；Hutool工具的SM4封装也可以，但如果公司有统一的国密依赖，自己封装也不难

注意一点，直接用JDK内置的javax.crypto是拿不到SM4算法的，必须引入BouncyCastle作为Provider。下面是我在pom.xml里加的内容：

<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk15on</artifactId> <version>1.69</version> </dependency>

3.2 核心工具类：Sm4CryptoUtil

我写了一个工具类，把加密、解密、密钥生成、Base64编解码统一封装好。直接贴核心代码，你复制后改一下密钥就可以用：

import org.bouncycastle.jce.provider.BouncyCastleProvider; import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.StandardCharsets; import java.security.Security; import java.util.Base64; public class Sm4CryptoUtil { static { if (Security.getProvider(BouncyCastleProvider.PROVIDER_NAME) == null) { Security.addProvider(new BouncyCastleProvider()); } } // 密钥必须16字节，这里用32个十六进制字符表示16字节 private static final String SECRET_KEY_HEX = "0123456789ABCDEF0123456789ABCDEF"; // IV向量也需要16字节，同样十六进制表示 private static final String IV_HEX = "00000000000000000000000000000000"; private static final String ALGORITHM = "SM4"; private static final String TRANSFORMATION = "SM4/CBC/PKCS5Padding"; public static String encrypt(String plainText) throws Exception { if (plainText == null || plainText.isEmpty()) { return plainText; } byte[] keyBytes = hexStringToByteArray(SECRET_KEY_HEX); byte[] ivBytes = hexStringToByteArray(IV_HEX); SecretKeySpec keySpec = new SecretKeySpec(keyBytes, ALGORITHM); IvParameterSpec ivSpec = new IvParameterSpec(ivBytes); Cipher cipher = Cipher.getInstance(TRANSFORMATION, BouncyCastleProvider.PROVIDER_NAME); cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec); byte[] encrypted = cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); return Base64.getEncoder().encodeToString(encrypted); } public static String decrypt(String cipherText) throws Exception { if (cipherText == null || cipherText.isEmpty()) { return cipherText; } byte[] keyBytes = hexStringToByteArray(SECRET_KEY_HEX); byte[] ivBytes = hexStringToByteArray(IV_HEX); SecretKeySpec keySpec = new SecretKeySpec(keyBytes, ALGORITHM); IvParameterSpec ivSpec = new IvParameterSpec(ivBytes); Cipher cipher = Cipher.getInstance(TRANSFORMATION, BouncyCastleProvider.PROVIDER_NAME); cipher.init(Cipher.DECRYPT_MODE, keySpec, ivSpec); byte[] decrypted = cipher.doFinal(Base64.getDecoder().decode(cipherText)); return new String(decrypted, StandardCharsets.UTF_8); } private static byte[] hexStringToByteArray(String hex) { int len = hex.length(); byte[] data = new byte[len / 2]; for (int i = 0; i < len; i += 2) { data[i / 2] = (byte) ((Character.digit(hex.charAt(i), 16) << 4) + Character.digit(hex.charAt(i + 1), 16)); } return data; } }

3.3 业务代码里的调用方式

在你的Mapper层或者Service层，凡是涉及敏感字段的写入，先加密再落库。读取的时候，解密后再返回前端。以用户手机号为例：

// 写入用户信息时加密 UserDO userDO = new UserDO(); userDO.setUserId(1001L); String rawMobile = "13800138000"; String encryptedMobile = Sm4CryptoUtil.encrypt(rawMobile); userDO.setMobile(encryptedMobile); userMapper.insert(userDO);

// 查询用户信息时解密 UserDO userDO = userMapper.selectById(1001L); String encryptedMobile = userDO.getMobile(); String rawMobile = Sm4CryptoUtil.decrypt(encryptedMobile);

这里有个细节需要特别提醒：加密后的密文长度会膨胀。SM4分组加密后，再经过Base64编码，20位的手机号加密后大约会变成44个字符左右。所以你在建表的时候，如果原字段是varchar(20)，加密后至少要改到varchar(64)，否则插入会直接报“值超出长度”。这个我在第一次联调的时候就踩了，建表语句卡在字段长度上。

3.4 关于密钥和IV的代码组织，劝你别学我

上面工具类里我把密钥直接写在常量里了，这是为了演示方便。实际生产环境绝对不要这么做，密钥要放到配置中心、环境变量或者独立的密钥管理服务（KMS）里，并且按环境（开发、测试、生产）分别配置。密钥一旦泄露，加密就等于裸奔。我在项目里最终是接入了公司内部的KMS，从配置中心动态读取密钥，然后初始化工具类，而不是像上面这样写死。

4. SQL函数路线：创建自定义函数实现倒数据的应急通道

4.1 为什么需要SQL函数加密

应用中会有很多历史数据修复、临时统计、管理员手工处理的数据操作场景。比如上线加密功能之前，库里已经有大量明文手机号，我得先把这些历史数据批量改成密文。这种场景如果要求业务系统发版再处理，周期太长。更灵活的方式是：直接在KingbaseES里创建加解密函数，用一条UPDATE语句就能把整表数据刷成密文。

4.2 在KingbaseES里创建SM4加解密函数

KingbaseES对Oracle的兼容模式做得不错，但SM4算法是国密标准，数据库内置函数里并没有现成的SM4加解密函数——至少在V8R6版本我没有找到。我的做法是：把Java里的加解密逻辑改写成PL/pgSQL函数。虽然SQL里的实现不如Java灵活，但对于批量数据处理来说完全够用。

下面是一个可以直接在KingbaseES的“命令行工具ksql”里执行的函数创建脚本。这个函数做的是：用固定密钥对输入的字符串做SM4/CBC/PKCS5Padding加密，输出Base64编码的密文。

-- 首先需要加载 pgcrypto 扩展以使用哈希和随机函数辅助（如果还没加载） CREATE EXTENSION IF NOT EXISTS pgcrypto; -- 创建 SM4 加密函数 CREATE OR REPLACE FUNCTION sm4_encrypt(plain_text TEXT, key_hex TEXT, iv_hex TEXT) RETURNS TEXT AS $$ DECLARE encrypted_bytea BYTEA; key_bytea BYTEA; iv_bytea BYTEA; BEGIN IF plain_text IS NULL OR plain_text = '' THEN RETURN plain_text; END IF; key_bytea := decode(key_hex, 'hex'); iv_bytea := decode(iv_hex, 'hex'); -- 使用 openssl 的 sm4-cbc 接口（KingbaseES 底层依赖 openssl 提供算法） SELECT encode(encrypt_iv(convert_to(plain_text, 'UTF8'), key_bytea, iv_bytea, 'sm4-cbc'), 'base64') INTO encrypted_bytea; RETURN encrypted_bytea; END; $$ LANGUAGE plpgsql;

注意，上面我用了encrypt_iv函数。这是pgcrypto扩展提供的接口，在KingbaseES的PostgreSQL兼容模式下可用。其中'sm4-cbc'对应openssl里的SM4-CBC模式。如果你的数据库里不确定openssl是否编译了SM4支持，可以先做一个快速验证：

SELECT pgcrypto.crypt('test', gen_salt('md5')); -- 或者直接执行 SELECT encrypt_iv(convert_to('13800138000', 'UTF8'), decode('0123456789ABCDEF0123456789ABCDEF','hex'), decode('00000000000000000000000000000000','hex'), 'sm4-cbc');

如果上面能返回一串密文，说明数据库底层openssl支持sm4-cbc。如果直接抛“invalid cipher name”错误，说明当前openssl版本或编译选项不支持SM4，那就得走Java加解密的路线来批量刷历史数据了。

4.3 解密函数的对应实现

解密函数和加密函数对称：

CREATE OR REPLACE FUNCTION sm4_decrypt(cipher_text TEXT, key_hex TEXT, iv_hex TEXT) RETURNS TEXT AS $$ DECLARE decrypted_bytea BYTEA; key_bytea BYTEA; iv_bytea BYTEA; BEGIN IF cipher_text IS NULL OR cipher_text = '' THEN RETURN cipher_text; END IF; key_bytea := decode(key_hex, 'hex'); iv_bytea := decode(iv_hex, 'hex'); SELECT convert_from(decrypt_iv(decode(cipher_text, 'base64'), key_bytea, iv_bytea, 'sm4-cbc'), 'UTF8') INTO decrypted_bytea; RETURN decrypted_bytea; END; $$ LANGUAGE plpgsql;

4.4 批量更新历史数据：一条SQL刷全表

有了加密函数之后，刷历史数据很简单。但我的经验是：不要直接在原表上批量更新，先把数据备份出来。我上次踩过一个坑，就是刷数据时函数里密钥传错了一个字节，结果整列数据全部解不回来。虽然有备份可以从容恢复，但如果没备份，那就真的灾难了。

建议按下面三个步骤走：

1. 建备份表：

CREATE TABLE t_user_info_bak_20241201 AS SELECT * FROM t_user_info;

2. 更新加密字段：

UPDATE t_user_info SET mobile = sm4_encrypt(mobile, '0123456789ABCDEF0123456789ABCDEF', '00000000000000000000000000000000') WHERE mobile IS NOT NULL AND mobile NOT LIKE '%==%'; -- 避免二次加密

3. 验证解密函数能还原数据：

SELECT mobile, sm4_decrypt(mobile, '0123456789ABCDEF0123456789ABCDEF', '00000000000000000000000000000000') AS mobile_plain FROM t_user_info LIMIT 10;

这里有个非常实用的判断技巧：如果加密后的明文里本身不含==后缀，那么可以用mobile NOT LIKE '%==%'来跳过已经是密文的行。因为Base64编码后的字符串，最大特点就是尾部可能会有一到两个=。对于手机号这种长度，加密后的Base64字符串尾部几乎都会带上==。但是这个判断并不绝对，如果原文明文里也碰巧带=，就会判断错。稳妥做法是：加一列is_encrypted标志，或者单独建一张映射表记录哪些行已经加密。

5. 手动加密过程中最隐蔽的三个大坑

这一节想好好聊聊我在实际改造中，花费时间最多、也最容易让后面接手的人怀疑人生的三个问题。单独列出来，希望对你有切实帮助。

5.1 坑一：字符串编码不一致导致解密乱码

问题描述：应用端通过Java加密后写入KingbaseES，数据库里看到的是Base64密文。在数据库里用sm4_decrypt函数解密，结果能解，但解出来全是乱码。

排查链路：

• 一开始我以为是密钥不同。但我确认了两边的密钥、IV、算法模式完全一致，这个可能性排除。
• 然后我怀疑是SQL函数里convert_to(plain_text, 'UTF8')和Java里getBytes(StandardCharsets.UTF_8)编码不一致。两边都是UTF-8，也没问题。
• 最后我发现问题出在数据库客户端连接的编码上。kingbase的ksql命令行工具，在Linux下默认连接字符集是GBK还是UTF8取决于LANG环境变量。我执行解密函数后，如果用GBK方式显示，密文解密出来的UTF-8字节流被按GBK解码，自然全是乱码。

解决办法：在ksql连接时强制指定客户端编码：

ksql -h 127.0.0.1 -p 54321 -U system -d testdb -W root123 # 登录后执行 SET client_encoding = 'UTF8';

或者直接用JDBC连接，设置?useUnicode=true&characterEncoding=UTF-8。

这个坑最常见的迷惑性在于：看起来像是加解密代码写错了，实际却是“显示层编码”和“存储层编码”没对齐。所以排查加解密问题时，先确认客户端编码，再怀疑算法实现，这个顺序能省很多时间。

5.2 坑二：WHERE条件查密文，索引完全失效

加密改造上线后，业务方反馈“用户查询模块变慢了”。原来是根据手机号直接查用户，SQL大概是这样：

SELECT * FROM t_user_info WHERE mobile = '13800138000';

改造后，手机号在库里变成了密文，这条SQL没法直接用了。正确做法是先在应用层把明文加密成密文，再用密文去查：

String encryptedMobile = Sm4CryptoUtil.encrypt("13800138000"); List<UserDO> list = userMapper.selectByMobile(encryptedMobile);

SQL语句变成：

SELECT * FROM t_user_info WHERE mobile = ?;

这样能命中普通索引，前提是你把mobile列上的索引正常建好。但是注意，如果手机号每次加密时使用随机IV，那么同样的明文手机号每次产生的密文都不一样，用密文等值查询就永远查不到。所以使用CBC模式加密时，IV必须固定且不随机，或者改用ECB模式加固定填充。我在项目里为了保证能用加密字段做等值查询，最终在“业务索引字段”上使用了固定IV的CBC模式，而“超大文本字段”则使用随机IV。这一点如果你不注意，上线后就会发现所有按手机号查询的接口全部失效。

这里补一个实践建议：如果字段仅用于展示（如身份证、详细地址），建议用随机IV；如果字段需要频繁参与精确查询（如手机号、邮箱、证件号等），必须使用固定IV或可重复密文方案。要是监管还要求“不同记录密文不同”，那就引入密文检索方案，或者单独冗余一个“密文哈希”列用于查询，但这是另一个话题了，这里不展开。

5.3 坑三：Base64换行符带来的数据错乱

这个坑可太隐蔽了。有些加解密库在输出Base64时，会按照76个字符插入一个换行符。如果你的明文很长（比如地址、备注），加密后的Base64字符串超过76个字符，Java里如果直接单行取出，数据库里存的可能带换行符，而Java解密的时候没做换行符处理，Base64.getDecoder()在某些实现下遇到非法字符会抛IllegalArgumentException。

排查链路：我当时处理一条身份证+家庭住址的长文本时，后台报错解密失败，但是短文本（手机号）解密正常。后来把报错信息里的密文逐字符打印出来，发现中间藏着一个\n。原因找到了：生产环境上一次批量刷数时，用的SQL函数内部可能因为字段换行导致了换行符进入Base64串。

解决办法：加密时替换掉明文里的换行符，加密后去掉所有Base64串中的\r\n：

// 加密前处理 plainText = plainText.replace("\r", "").replace("\n", ""); // 解密前处理 cipherText = cipherText.replace("\r", "").replace("\n", "");

这个处理逻辑看起来有点笨，但对于确保全链路加解密的稳定性非常有效。

5.4 附加提醒：备份恢复之后的密钥匹配验证

手动加密和TDE有个很大区别：TDE的密钥是数据库自己管理的，备份恢复到新环境后，只要密钥文件也在，数据可以直接读到明文。但手动加密的密钥是我们自己管理的，如果备份恢复到新库，密文数据可以整库导入，但解密必须依赖我们手里的密钥。所以我在每次备份恢复演练时，都会加一个“解密验证步骤”：从生产库导出一小部分密文数据，导入到恢复环境，再用密钥去解密，确认结果和原文一致。这个验证必须在正式切换前完成，否则等备份已经用于应急恢复时才发现密钥对不上，那才是真正的灾难。

6. 手动加密下的查询与统计：不能回避的性能问题

加密不是“加了个壳”就完事。上线后最直接的冲击，就是对查询和统计的影响。做这个方案前，你一定要有心理准备：任何手动加密方案，都会在一定程度上牺牲查询的灵活性。

6.1 精确查询：应用层构造密文等值匹配

刚才第5.2节已经讲了，精确匹配是可以用密文等值查询来做的，前提是固定IV。思路就是：前端输入明文手机号，应用层先加密成密文，再拼到SQL的WHERE条件里。这样索引还可以用，但前提是你预留了足够长度的字段。比如手机号字段原来varchar(20)，改成密文存储后至少需要varchar(100)，并且这个长度必须建表时一次性考虑好，否则后续改字段类型会比较痛苦。

6.2 模糊查询：正确姿势是“先缩小范围再解密”

业务上经常有“根据手机号后四位模糊搜索用户”这样的需求。加密以后，LIKE '%6789%'是绝对查不出来密文的，因为密文和明文没有可推测的映射关系。

我的做法是分两步：

1. 先在应用层把待匹配的关键字做一次加密，如果业务允许“前缀匹配”，可以尝试用密文前缀来查，因为CBC/ECB模式下，固定IV时相同前缀的明文加密后密文前缀大概率也相同。但如果算法内部做的是整个明文的填充加密，前缀匹配也不一定稳定。实测下来，这种方案并不可靠。

2. 更稳妥的做法是：先用其他非敏感条件（如创建时间、状态、所属机构）把候选数据缩小到一个很小的集合（比如几百条），然后只对这批候选数据在应用层遍历解密，再做内存中的模糊匹配。虽然看起来“不优雅”，但数据量可控时性能完全可接受。如果数据量实在太大，那就要考虑引入搜索引擎（如Elasticsearch）做明文索引，数据库只存密文，但这已经超出本篇范围了。

6.3 统计类SQL：解密函数直接参与运算可行吗

有些统计场景需要基于明文做聚合，比如统计某地区手机号段分布、统计证件号位数异常的数据等。理论上可以在SQL里直接调用sm4_decrypt函数再GROUP BY，但如果数据量上了百万级，这种写法会非常慢，因为每条记录都要先做一次解密运算，索引也没办法参与。我在项目里遇到类似的统计需求，基本都是把数据从库里导出来，在应用层解密后再统计，而不是在数据库里硬扛。

如果实在要在数据库里做，建议分批处理，每次取几万条解密统计完再取下一批，避免一次性全表解密把数据库CPU打满。我在压测环境里试过一次全表50万行解密，直接导致数据库连接超时告警。所以，能避免在数据库里做解密聚合，就尽量避免。

7. 密钥管理的几个落地原则和备份恢复验证

7.1 密钥冷热分离与访问控制

手动加密的核心资产就是密钥。密钥管理我总结了这么几条落地原则：

• 密钥不能和数据库放在同一台服务器上。这个是最基本的。如果攻击者连数据库带服务器一起拿走，密钥就在同目录下，那加密就等于白做了。
• 生产密钥与测试密钥必须分开。不要图省事用一套密钥。测试密钥泄露了，不至于影响生产。
• 密钥要有版本号和轮换机制。我的建议是至少在密钥中带一个“密钥版本标识”，比如密文头部加一个前缀{v1}，这样将来轮换密钥时，老数据还能根据版本标识找到对应的老密钥来解密。
• 访问密钥要有审计。谁来读取了密钥、什么时间读取的，都要有日志。

7.2 备份恢复与密钥的联动验证

手工加密的数据，备份恢复时必须保证“数据”和“密钥”能对上。具体怎么做：

1. 数据库全量备份（物理备份或逻辑备份均可）。
2. 单独备份密钥（加密后存储，比如用RSA公钥加密SM4密钥后存到保险柜或密钥管理系统）。
3. 恢复到新环境后，取几行密文数据，用备份的密钥做解密验证。
4. 验证通过后，再正式对外提供数据库服务。

我在项目里把这个“解密验证”写进了标准操作流程文档，每次恢复演练都必须执行。有一次我发现恢复环境中某个表的数据解出来是一半乱码，排查后发现是备份时用了历史密钥，而新密钥已经轮换过。幸好做了验证，否则等真正用来恢复业务时才发现问题，后果不堪设想。

7.3 密钥遗失后的“逃生通道”

坦率地说，手动加密方案最大的风险就是密钥遗失。密钥丢了，所有密文数据等于永久丢失。所以我在实际项目里做了双人保管机制：A保管密钥前半段，B保管密钥后半段，两人同时到场才能拼出完整密钥。同时，密钥的明文版本加密备份到两家不同的存储位置。

这个方法不一定适合所有团队，但它的思路是：不要让密钥成为单点故障。如果你的组织有KMS、密码机等专门设施，优先用设施来管理，人工保管只是兜底。

8. 加密字段运行监控与日常维护

8.1 如何确认数据始终是密文状态

加解密功能上线后，需要定期巡检，防止有人绕过应用层直接往数据库里写明文。我写了一个简单的巡检SQL：

SELECT count(*) AS total_cnt, count(*) FILTER (WHERE mobile NOT LIKE '%==%') AS possibly_plain_cnt FROM t_user_info WHERE mobile IS NOT NULL;

这个SQL的含义是：如果mobile字段是正规的SM4/CBC + Base64编码后的密文，通常末尾会带==（具体看位数）。如果发现大量记录不以==结尾，就说明可能有明文数据混入。当然这个方法不严谨，但它可以作为一个快速巡检手段。

更严格的做法是：在应用层做一个“规则判断”，比如解密后必须符合手机号正则^1[3-9]\d{9}$，解密失败或格式不对就告警，说明数据可能被篡改或写入不规范。

8.2 轮换密钥时，存量数据的平滑过渡

密钥轮换是迟早要面对的事。轮换密钥有两种方式：

• 解密旧数据，用新密钥重新加密，回写到库中。这种方式最直接，但需要停机窗口，且数据量大会有较长的更新时间。
• 双密钥模式：增量的新数据用新密钥加密，存量老数据继续用旧密钥。解密时先识别密文头部的密钥版本号，选择对应的密钥来解密。这种方式无需大规模更新存量数据，但代码要能兼容多版本密钥。

强烈建议一开始设计手动加密方案时，就考虑好“密钥版本标识”的设计，不要等轮换时再改表。哪怕只是简单的在密文前加{v1}前缀，也能省很多事。

9. 写在最后：这套方案能不能长期跑下去

手动加密方案在人大金仓数据库上，目前已经稳定运行了将近一年。回看当初的选择，它确实绕开了TDE版本限制，也解决了等保测评的整改项，但代价是我们把“密钥管理”和“解密性能”这两个包袱背到了自己身上。如果贵单位的数据库版本支持TDE，且预算充足，TDE依然是第一选择；如果因为各种限制必须自己动手，那这篇内容里的方案应该能给你一个足够完整的参考。

我个人在项目里的体会是：手动加密这件事，技术上并不难，难的是把密钥管理、查询改造、历史数据迁移、恢复演练这些周边工作全部考虑周全。加密算法只是其中的一小部分，真正决定这个方案成败的，往往是那些容易被忽视的细节——IV是否固定、字段长度是否够、编码是否统一、备份后能不能解回来。希望这篇内容能帮你少踩几个坑。