一、引言：表级与列级加密的价值定位
在金融、政务、医疗等关键行业，数据安全不再是"加分项"，而是系统建设的"基础项"。随着《密码法》、等保 2.0、商用密码应用安全性评估等要求逐步落地，敏感数据加密存储 成为数据库建设的重要能力。尤其在国产化场景下，优先采用国密算法是合规建设的关键要求。
然而，在实际项目中，DBA 和架构师通常面临三类问题：
| 挑战 | 具体表现 |
|---|---|
| 合规要求 | 敏感数据需满足加密存储要求，且很多场景优先要求使用国密算法 |
| 性能顾虑 | 加解密会消耗 CPU 资源，高并发场景下需要平衡安全与性能 |
| 权限隔离 | 仅有"落盘加密"还不够，某些场景还要求 DBA 无法直接查看明文 |
针对这些问题，KingbaseES 提供了覆盖不同安全等级的表级与列级加密能力：
| 方案 | 插件 | 加密粒度 | 核心定位 |
|---|---|---|---|
| 方案一 | sysencrypt |
表级 | 自动透明、业务无感、整表防护 |
| 方案二 | kbcrypto |
字段级 | 国密合规、精准控制、手动加解密 |
| 方案三 | kdb_ce |
字段级 | 全程密态、DBA 不可见、最高安全等级 |
说明 ：本文重点讨论 表级加密与列级加密。
本文将从原理、实战、性能、运维、选型五个维度，对 KingbaseES 的三种常见加密方案进行系统梳理。
二、加密能力全景图：三种方案，各有侧重
2.1 架构定位
从安全能力和实现方式来看，这三种方案并非相互替代，而是分别面向不同场景：
text
┌─────────────────────────────────────────────────────────────────┐
│ KingbaseES 表级与列级加密能力体系 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 方案三：全密态计算（kdb_ce） │ │
│ │ • 磁盘密文 / 传输密文 / 内存密文 │ │
│ │ • 支持密文条件查询（视加密类型而定） │ │
│ │ • DBA 默认无法获取明文 │ │
│ │ • 适用：最高敏感级数据 │ │
│ ├─────────────────────────────────────────────────────────┤ │
│ │ 方案二：字段级国密加密（kbcrypto） │ │
│ │ • 显式调用 SM4 / SM3 │ │
│ │ • 字段级精准控制 │ │
│ │ • 适用：身份证、手机号、口令摘要等场景 │ │
│ ├─────────────────────────────────────────────────────────┤ │
│ │ 方案一：单表透明加密（sysencrypt） │ │
│ │ • 业务无感、自动加解密 │ │
│ │ • 落盘密文、读取解密 │ │
│ │ • 适用：整表敏感数据基础防护 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 安全隔离能力递增 ─────────────────→ 性能开销通常递增 │
└─────────────────────────────────────────────────────────────────┘2.2 三种方案速查表
| 对比维度 | sysencrypt | kbcrypto | kdb_ce |
|---|---|---|---|
| 加密粒度 | 表级 | 字段级 | 字段级 |
| 业务代码改造 | 基本无需改造 | 需要修改 SQL 或应用逻辑 | 一般无需改业务 SQL，需按规范建表与使用客户端能力 |
| 磁盘存储状态 | 密文 | 取决于是否存储加密结果 | 密文 |
| 内存中数据状态 | 查询执行时通常为明文 | 取决于应用调用方式 | 目标是全程密态处理 |
| DBA 是否可直接见明文 | 通常可以 | 通常可以 | 默认不可直接见明文 |
| 查询能力 | 基本与普通表一致 | 取决于应用是否解密 | 支持部分密文计算能力 |
| 国密支持 | SM4（内置） | SM4 / SM3（显式） | 文中示例为 AES256 体系 |
| 性能影响 | 较低 | 通常较低 | 相对较高 |
| 适用场景 | 整表基础防护 | 字段级精细防护 | 高安全隔离、密评场景 |
从工程实践角度看：
- sysencrypt 解决的是"整表落盘加密"问题；
- kbcrypto 解决的是"字段级精细控制"问题；
- kdb_ce 解决的是"连 DBA 也不能直接看到明文"的问题。
三、国密算法基础：SM3 与 SM4
在进入具体方案之前，先明确两个常见国密算法的定位。
3.1 SM4：对称加密算法
| 属性 | 说明 |
|---|---|
| 标准编号 | GB/T 32907 - 2016 |
| 算法类型 | 分组对称加密 |
| 分组长度 | 128 位 |
| 密钥长度 | 128 位 |
| 轮数 | 32 轮 |
| 在 KES 中的典型应用 | sysencrypt、kbcrypto.sm4() |
SM4 是国产商用密码体系中的核心对称加密算法，适合数据存储加密、字段加密等场景，在数据库场景下常用于对敏感信息进行可逆加密保护。简单来说，对称加密就像是用同一把钥匙锁门和开门，SM4 算法规定了这把"钥匙"的长度、加密的具体步骤等，以确保数据在加密和解密过程中的一致性和安全性。
3.2 SM3：哈希算法
| 属性 | 说明 |
|---|---|
| 标准编号 | GB/T 32905 - 2016 |
| 算法类型 | 密码杂凑（哈希） |
| 输出长度 | 256 位 |
| 典型特性 | 不可逆、用于完整性校验与摘要存储 |
| 在 KES 中的典型应用 | kbcrypto.sm3() |
SM3 主要用于用户密码摘要存储、数据完整性校验等不需要还原明文的安全校验场景。可以把哈希算法理解为给数据生成一个独一无二的"指纹"，无论原数据多大，通过哈希算法得到的"指纹"长度固定且不可逆，一旦数据有任何改变，"指纹"就会不同，以此来验证数据的完整性。
3.3 为什么在项目中优先考虑国密？
在国产化、信创、等保与密评场景中，采用国密算法不仅是技术选择，还涉及合规要求。
因此，在 KingbaseES 环境下：
- 整表透明加密优先考虑
sysencrypt； - 字段级可逆加密优先考虑
kbcrypto.sm4()； - 字段级不可逆摘要优先考虑
kbcrypto.sm3()。
实际选型仍应以项目合规要求、产品版本能力和测评口径为准。
四、方案一：单表透明加密（sysencrypt）
核心关键词：透明、整表、业务无感。
如果您的核心诉求是不改业务代码、尽量低成本地让整张表落盘即密 ，那么 sysencrypt 往往是第一选择。
4.1 工作原理
text
写入流程：
应用提交明文 → 数据库处理明文 → 落盘前加密 → 磁盘存储密文
读取流程：
磁盘读取密文 → 数据库解密 → 执行层处理明文 → 返回应用明文它具有以下关键特征：
- 对业务 SQL 基本透明；
- 数据文件以密文方式落盘；
- 查询时由数据库自动完成解密；
- 适合对"整表敏感数据"进行统一防护。
需要注意：透明加密主要解决的是存储层防护 问题，
并不等同于"数据库内任何角色都无法看到明文"。
4.2 环境准备
bash
# 1）修改配置文件
vi $KINGBASE_DATA/kingbase.conf
shared_preload_libraries = '...,sysencrypt'
bash
# 2）重启数据库
sys_ctl restart -D $KINGBASE_DATA
sql
-- 3）创建扩展
CREATE EXTENSION sysencrypt;4.3 创建加密表
sql
CREATE TABLE customer_encrypted (
id INT PRIMARY KEY,
name VARCHAR(50),
id_card VARCHAR(18),
phone VARCHAR(11),
created_at TIMESTAMP DEFAULT NOW()
) ENCRYPTED;插入与查询方式与普通表保持一致：
sql
INSERT INTO customer_encrypted VALUES
(1, '张三', '11010119900307663X', '13800000001', NOW()),
(2, '李四', '11010119911212456X', '13800000002', NOW());
SELECT * FROM customer_encrypted;4.4 验证表是否已加密
sql
SELECT sysencrypt.is_table_encrypted('customer_encrypted');也可以查询系统视图：
sql
SELECT *
FROM sysencrypt.sys_table_encrypt
WHERE tablename = 'customer_encrypted';查看对应的数据文件路径：
sql
SELECT sys_relation_filepath('customer_encrypted');4.5 从底层验证密文落盘
bash
# 请将路径替换为上一步 sys_relation_filepath 的实际输出
hexdump -C $KINGBASE_DATA/base/14712/16482 | head -20关键输出片段（密文特征）：
text
00000040 4f 7f db 0a 39 6b 34 ca 68 d7 98 25 5d 12 a0 db |O...9k4.h..%]..|
00001f60 85 95 6e 57 cf 86 1f b2 23 6f bb 78 a4 f4 35 3a |..nW....#o.x..5:|
00001fb0 85 95 6e 57 cf 86 1f b2 23 6f bb 78 a4 f4 35 3a |..nW....#o.x..5:|如果表已启用透明加密，通常可以看到无明显业务意义的字节流，而不是可直接识别的明文内容。
这一步的意义在于证明：
即便直接读取底层数据文件，也无法直接获取业务明文。
4.6 变更加密状态
4.6.1 原理说明
变更加密状态时，数据库不会修改原文件属性 ，而是重建整个表：
text
原始表 (relfilenode = A)
│
├── 1. 加 AccessExclusiveLock 锁
│
├── 2. 创建新数据文件 (relfilenode = B)
│
├── 3. 逐行读取原表 → 加密/解密 → 写入新文件
│
├── 4. 更新系统目录，将表指向新文件
│
└── 5. 删除原数据文件 (relfilenode = A)为了更直观理解，我们可以用一个简单的比喻：原表就像一栋旧房子，要改变它的加密状态，不是直接在旧房子上修改，而是在旁边重新盖一栋新房子（新数据文件），把旧房子里的东西（数据）搬过去，然后拆除旧房子。这就是为什么变更后 sys_relation_filepath 返回值会变化。
4.6.2 实际操作演示
变更为非加密表：
sql
ALTER TABLE customer_encrypted NOT ENCRYPTED;
sql
SELECT sys_relation_filepath('customer_encrypted');
text
sys_relation_filepath
-----------------------
base/14712/16488 -- 文件路径已变化再变更为加密表：
sql
ALTER TABLE customer_encrypted ENCRYPTED;
sql
SELECT sys_relation_filepath('customer_encrypted');
text
sys_relation_filepath
-----------------------
base/14712/16492 -- 文件路径再次变化此外如果显式指定密钥，也可能出现类似写法：
sql
ALTER TABLE customer_encrypted ENCRYPTED BY 'new_key_2025';但从安全实践角度看：
- 优先使用系统生成或托管密钥；
- 不建议在 SQL 中直接显式写入明文密钥；
- 所有变更加密状态的操作都应在维护窗口执行。
4.7 风险提示
变更表加密状态通常属于重量级操作，需要重点关注以下影响：
- 会持有
AccessExclusiveLock，期间表完全不可读不可写 - 需要重建数据文件，带来较大 I/O 与 CPU 开销
- 操作期间新旧文件同时存在，需额外存储空间（约等于原表大小）
- 大表操作时间可能较长，且会生成大量 WAL 日志
建议：
- 先在测试环境完整演练；
- 评估表大小与业务低峰窗口；
- 检查是否存在长事务与锁等待；
- 变更后再次验证加密状态与业务可用性。
本节小结
sysencrypt 最适合作为整表级的基础防护方案。它的最大优势是改造成本低、上线速度快，尤其适合存量系统。
五、方案二：字段级国密加密（kbcrypto）
核心关键词：精细、灵活、显式控制。
如果您的诉求是只加密某几个字段，且希望明确控制何时加密、何时解密、使用什么算法 ，那么 kbcrypto 更合适。
5.1 加载扩展
sql
CREATE EXTENSION kbcrypto;5.2 常见函数能力
| 函数 | 用途 | 说明 |
|---|---|---|
sm4(data, key, mode) |
SM4 加解密 | mode = 0 加密，mode = 1 解密；参数类型为 BYTEA |
sm4_ex(data, key, mode, pad) |
SM4 扩展函数 | 可控制补位方式 |
sm3(data) |
SM3 摘要 | 不可逆摘要，参数类型支持 TEXT 或 BYTEA |
rc4(data, key) |
RC4 加解密 | 是否使用需视安全规范而定 |
注意 ：
sm4函数参数类型为BYTEA，使用时需要进行类型转换。简单来讲，BYTEA类型就像是一种特殊的"容器"，专门用来存放经过编码的数据，在使用sm4函数对数据进行加解密时，要先把数据放入这个"容器"中。
5.3 字段级SM4加密示例
建表（推荐使用BYTEA类型存储密文）：
sql
CREATE TABLE staff (
id INT PRIMARY KEY,
name VARCHAR(50),
id_card_encrypted BYTEA, -- 存储加密后的身份证号
phone_encrypted BYTEA -- 存储加密后的手机号
);插入时手动加密（使用::BYTEA转换）：
sql
INSERT INTO staff VALUES (
1,
'王五',
sm4('11010119900307663X'::BYTEA, '0123456789ABCDEF'::BYTEA, 0),
sm4('13912345678'::BYTEA, '0123456789ABCDEF'::BYTEA, 0)
);查询时手动解密并转换为可读文本：
sql
SELECT
id,
name,
convert_from(sm4(id_card_encrypted, '0123456789ABCDEF'::BYTEA, 1), 'UTF8') AS id_card,
convert_from(sm4(phone_encrypted, '0123456789ABCDEF'::BYTEA, 1), 'UTF8') AS phone
FROM staff;预期输出：
text
id | name | id_card | phone
----+------+--------------------+-------------
1 | 王五 | 11010119900307663X | 13912345678说明 ：sm4函数解密后返回BYTEA类型，直接查询会显示十六进制格式（如\x313130...）。使用convert_from(..., 'UTF8')可将BYTEA转换为可读的文本字符串。如果表中已使用TEXT类型存储密文，查询时需显式转换：sm4(id_card_encrypted::BYTEA, ...)。建议建表时直接使用BYTEA类型。
5.4 用SM3存储口令摘要
对于密码类字段，通常不建议做"可逆加密"，而是使用不可逆摘要。
sql
CREATE TABLE system_user (
username VARCHAR(50) PRIMARY KEY,
password_hash TEXT NOT NULL, -- SM3返回TEXT，直接存储
created_at TIMESTAMP DEFAULT NOW()
);
-- 注册时保存摘要
INSERT INTO system_user (username, password_hash)
VALUES ('admin', sm3('Kingbase@2024'::BYTEA));
-- 登录校验时比较摘要
SELECT 1
FROM system_user
WHERE username = 'admin'
AND password_hash = sm3('Kingbase@2024'::BYTEA);如果项目允许，密码存储还应进一步考虑引入随机盐、迭代策略等机制。单纯哈希虽然比明文强，但在高安全场景下应采用更严格的口令保护方案。
5.5 显示格式注意事项
查询密文字段时，输出格式可能受bytea_output参数影响：
sql
-- 设置输出格式为转义模式（更易读）
SET bytea_output TO escape;
-- 查看密文
SELECT id_card_encrypted FROM staff;5.6 适用场景总结
kbcrypto非常适合以下场景：
- 身份证号、银行卡号、手机号等单字段敏感信息；
- 对口令做不可逆摘要存储；
- 需要由应用精确控制加解密逻辑的系统；
- 不希望整表加密，只希望加密少量关键字段的系统。
本节小结
kbcrypto的优势在于粒度细、控制强、实现直接 。代价是需要改造SQL或应用逻辑，且需注意BYTEA类型转换。更适合对敏感字段有明确识别能力、愿意承担一定改造成本的应用系统。
六、方案三：全密态计算（kdb_ce）
核心关键词：密态、隔离、最高安全等级。
如果您的要求已经不仅是"防止磁盘泄露"，而是进一步要求数据库管理员也不能直接看到明文数据 ，那么就要考虑kdb_ce这类全密态方案。
6.1 什么是全密态计算？
全密态计算强调的是：数据在存储、传输、处理的关键环节中，尽可能都以密文形式存在，并在一定范围内支持密文条件查询或密文计算。
它和透明加密的本质区别在于：
| 维度 | 透明加密（sysencrypt） | 全密态计算（kdb_ce） |
|---|---|---|
| 主要防护对象 | 底层存储介质泄露 | 存储泄露 + 高权限越权查看 |
| 查询执行过程 | 数据库侧解密后处理 | 尽量以密态方式处理 |
| DBA是否可直接见明文 | 一般可以 | 默认不可以 |
| 密钥控制权 | 更多在数据库侧 | 更强调客户端或外部密钥体系 |
6.2 双层密钥体系
text
CMK（客户端主密钥）
↓ 保护
CEK（列加密密钥）
↓ 加密
业务列数据其中：
- CMK：客户端主密钥，建议存放于本地KMS或HSM；
- CEK：列加密密钥，由CMK保护；
- 数据库端通常只保存受保护后的密钥材料与密文数据。
这种设计的关键价值在于：数据库本身不直接掌握明文密钥，从而降低高权限账号直接接触明文的可能性。
6.3 环境配置
一、加载插件
bash
vi $KINGBASE_DATA/kingbase.conf添加kdb_ce到共享预加载库：
text
shared_preload_libraries = '...,kdb_ce'二、重启数据库
bash
sys_ctl restart -D $KINGBASE_DATA三、设置localkms环境
bash
# 设置环境变量
cat >> ~/.bash_profile << EOF
export KINGBASE_HOME=/opt/Kingbase/ES/V9/Server
export LOCALKMS_FILE_PATH=/opt/Kingbase/ES/V9/Server/etc/localkms/
EOF
source ~/.bash_profile
# 创建密钥存储目录
mkdir -p $KINGBASE_HOME/etc/localkms四、开启客户端全密态模式
bash
# -M参数是开启客户端全密态的关键
ksql -U system -d test -p 54321 -M五、创建插件
sql
CREATE EXTENSION kdb_ce;6.4 创建密钥对象
创建客户端主密钥（CMK）：
sql
CREATE CLIENT MASTER KEY cmk_1 WITH (
KEY_STORE = LOCALKMS,
KEY_PATH = "kms_1",
ALGORITHM = RSA_2048
);创建列加密密钥（CEK）：
sql
CREATE COLUMN ENCRYPTION KEY cek_1 WITH VALUES (
CLIENT_MASTER_KEY = cmk_1,
ALGORITHM = AEAD_AES_256_CBC_HMAC_SHA256
);6.5 创建全密态表
sql
CREATE TABLE creditcard_info (
id_number INT,
name TEXT CLENCRYPTED WITH (
COLUMN_ENCRYPTION_KEY = cek_1,
ENCRYPTION_TYPE = DETERMINISTIC
),
gender VARCHAR(10) CLENCRYPTED WITH (
COLUMN_ENCRYPTION_KEY = cek_1,
ENCRYPTION_TYPE = DETERMINISTIC
),
salary FLOAT4 CLENCRYPTED WITH (
COLUMN_ENCRYPTION_KEY = cek_1,
ENCRYPTION_TYPE = DETERMINISTIC
),
credit_card VARCHAR(19) CLENCRYPTED WITH (
COLUMN_ENCRYPTION_KEY = cek_1,
ENCRYPTION_TYPE = DETERMINISTIC
),
salary2 INT4 CLENCRYPTED WITH (
COLUMN_ENCRYPTION_KEY = cek_1,
ENCRYPTION_TYPE = DETERMINISTIC
)
);6.6 插入与查询数据
插入数据：
sql
INSERT INTO creditcard_info VALUES
(100, 'myname', 'manager1', 112233.123, 'creditcard888888', 123),
(200, 'thename', 'employe', 52233.123, 'creditcard77777', 45678);
CHECKPOINT; -- 数据落盘等值查询：
sql
SELECT * FROM creditcard_info WHERE name = 'thename';非等值查询：
sql
SELECT * FROM creditcard_info WHERE name <> 'thename';6.7 两种加密类型的选择
| 类型 | 特点 | 适用操作 | 安全性 |
|---|---|---|---|
| DETERMINISTIC | 相同明文对应相同密文 | 等值查询、JOIN、部分分组场景 | 相对较低 |
| RANDOMIZED | 相同明文对应不同密文 | 不适合等值匹配 | 更高 |
选择原则通常是：
- 需要参与查询条件 的列：优先考虑
DETERMINISTIC； - 仅存储展示、不参与条件匹配 的列：优先考虑
RANDOMIZED； - 密码类信息：依然更建议使用不可逆摘要，而不是可查询加密。
6.8 验证全密态效果
验证一：存储层加密
在不使用-M参数的普通连接下，查询加密表：
bash
ksql -U system -d test -p 54321
sql
SELECT * FROM creditcard_info;加密列将显示为乱码密文，而非正常数据。
验证二：查看数据文件
sql
SELECT sys_relation_filepath('creditcard_info');
bash
hexdump -c $KINGBASE_DATA/base/14712/16567 | head -20数据文件内容应为不可读的密文。
验证三：抓包验证传输内容（可选）
bash
tcpdump host xx.xx.xx.xxx and port 54321 -i any -vv -X -s 0 -w /tmp/encrypt.pcap6.9 环境清理
sql
DROP TABLE creditcard_info;
DROP COLUMN ENCRYPTION KEY cek_1;
DROP CLIENT MASTER KEY cmk_1;6.10 适用场景总结
kdb_ce适合：
- 金融账户信息；
- 医疗病历核心字段；
- 高密级政务数据；
- 对DBA越权风险有严格隔离要求的场景；
- 密评、等保中的高安全要求项目。
本节小结
kdb_ce提供的是更高等级的数据保护能力，但同时也意味着更高的部署、运维与性能成本。它更适合作为重点核心表的强化方案，而不一定适合全库普遍铺开。
七、性能考量：加密会带来什么影响
任何加密能力都不是"零成本"的。区别只在于开销发生在哪一层、集中在哪个环节、是否可接受。
7.1 性能影响的基本规律
| 影响因素 | 说明 |
|---|---|
| 加密粒度 | 加密范围越大，整体资源消耗通常越高 |
| 并发压力 | 并发越高，加解密CPU开销越容易放大 |
| 硬件能力 | CPU指令集、核心数、主频都会影响加密性能 |
| 访问模式 | 读多写少、写多读少、批量导入等场景影响不同 |
| 方案类型 | 透明加密、字段加密、全密态计算的开销差异明显 |
7.2 三种方案的性能直观对比
| 方案 | 性能影响 | 说明 |
|---|---|---|
| sysencrypt | 较低 | 主要增加存储层加解密开销，对业务改造影响小 |
| kbcrypto | 较低到中等 | 仅加密少数字段时通常可控，但应用侧逻辑会增加复杂度 |
| kdb_ce | 较高 | 涉及客户端、密钥体系与密态处理，整体开销更明显 |
7.3 如何理解"性能损耗可控"？
很多场景中，透明加密的性能损耗是可以接受的，但这并不意味着所有业务都只有固定比例的损耗。
实际影响取决于：
- 表大小；
- 数据类型；
- 查询模式；
- 更新频率；
- 并发连接数；
- 硬件配置；
- 是否有缓存命中。
因此更稳妥的表达应是：
在合理配置与典型OLTP场景下，透明加密的性能影响通常较可控；
但是否满足生产要求，仍需通过本地压测验证。
7.4 优化建议
| 优化方向 | 建议措施 |
|---|---|
| 精准加密 | 只加密真正敏感的表和字段，避免"一刀切" |
| 硬件评估 | 关注CPU性能与硬件加速能力 |
| 分级防护 | 普通敏感表用透明加密，核心字段再叠加字段级加密 |
| 维护策略 | 重量级加密变更必须安排在维护窗口 |
| 压测先行 | 上线前做专项性能测试，而不是只看理论结论 |
八、选型决策：不同场景如何选择
8.1 决策思路
决策思路：
-
是否需要对整张表做快速、低改造的加密防护？
- 是 → 优先考虑
sysencrypt
- 是 → 优先考虑
-
是否只需要对少量敏感字段进行精准保护？
- 是 → 优先考虑
kbcrypto
- 是 → 优先考虑
-
是否要求DBA也无法直接查看明文？
- 是 → 优先考虑
kdb_ce
- 是 → 优先考虑
8.2 场景推荐表
| 业务场景 | 推荐方案 | 改造成本 | 原因 |
|---|---|---|---|
| 客户主数据表、订单表 | sysencrypt |
极低 | 整表防护，业务无感 |
| 密码 / 口令 | kbcrypto.sm3() |
低 | 不可逆摘要更合适 |
| 身份证号、银行卡号、手机号 | kbcrypto.sm4() |
中 | 字段级精准加密，需改SQL |
| 核心账户信息 | kdb_ce |
中高 | 更强的权限隔离能力 |
| 电子病历主表 | sysencrypt + kbcrypto |
中 | 整表基础防护 + 关键字段强化 |
8.3 组合方案示例
在很多真实项目中，并不是三选一，而是分层使用。
例如：
- 整张客户表使用
sysencrypt； - 身份证号字段再用
kbcrypto.sm4()二次加密； - 密码字段使用
kbcrypto.sm3()存摘要； - 对极少数核心账户表再单独考虑
kdb_ce。
sql
-- 组合方案：透明加密整表 + 字段级SM4二次加密
CREATE TABLE customer (
id INT,
name VARCHAR(50),
id_card_encrypted BYTEA, -- SM4加密后的身份证号
phone VARCHAR(11)
) ENCRYPTED;
-- 插入时对敏感字段额外加密
INSERT INTO customer VALUES (
1,
'张三',
sm4('11010119900307663X'::BYTEA, 'field_key_16byte'::BYTEA, 0),
'13800000001'
);本节小结
选型的核心不是"谁最强"，而是"谁最适合当前业务、当前合规要求和当前改造成本"。
九、DBA运维最佳实践
9.1 密钥管理规范
| 项目 | 建议 |
|---|---|
| 密钥强度 | SM4密钥应满足16字节要求，并使用高强度随机值生成 |
| 密钥轮换 | 建立周期性轮换机制，明确流程与影响评估 |
| 密钥备份 | 密钥备份必须独立于数据备份存放 |
| 禁止硬编码 | 禁止在应用代码、脚本、配置文件中明文写死密钥 |
| 权限隔离 | 密钥管理员、DBA、应用管理员应尽量分权 |
| 集中托管 | 高安全场景建议接入KMS / HSM |
9.2 变更加密状态前的检查
sql
-- 1. 评估表大小
SELECT sys_size_pretty(sys_total_relation_size('customer_encrypted'));
sql
-- 2. 检查当前是否已加密
SELECT sysencrypt.is_table_encrypted('customer_encrypted');
sql
-- 3. 检查活动会话与锁影响
SELECT pid, state, query, wait_event_type, wait_event
FROM sys_stat_activity
WHERE query LIKE '%customer_encrypted%'
OR state = 'active';9.3 执行变更与事后验证
sql
ALTER TABLE customer_encrypted ENCRYPTED;变更后建议继续验证：
sql
SELECT sysencrypt.is_table_encrypted('customer_encrypted');
sql
SELECT sys_relation_filepath('customer_encrypted');
sql
SELECT count(*) FROM customer_encrypted;9.4 操作建议
- 所有重量级加密变更必须走维护窗口；
- 上线前必须做测试环境演练；
- 备份文件要单独加密保管；
- 建立密钥保管人与恢复预案；
- 将加密纳入巡检项，而不是一次性交付项。
十、总结
KingbaseES在表级与列级加密方面，提供了从"基础存储加密"到"高等级密态保护"的完整能力体系：
| 方案 | 插件 | 一句话定位 |
|---|---|---|
| 方案一 | sysencrypt |
整表透明加密，改造成本最低 |
| 方案二 | kbcrypto |
字段级国密加密，控制最灵活 |
| 方案三 | kdb_ce |
全密态保护，安全隔离最强 |
如果做一个工程化建议，可以概括为：
- 大多数项目 ：优先使用
sysencrypt做整表透明加密，以较低成本实现基础的数据加密保护，满足一般业务场景对数据安全的需求。 - 关键敏感字段 ：叠加
kbcrypto.sm4()或kbcrypto.sm3()，针对特定敏感字段进行更精细的加密控制，增强敏感信息的安全性。 - 极高安全要求场景 ：对核心表采用
kdb_ce，提供最高等级的数据安全防护，确保在对数据保密性和完整性要求极高的场景下，数据不被非法获取或篡改。
最终，真正合理的方案往往不是"全都上最强"，而是：
按数据敏感度分级、按业务改造成本取舍、按合规要求落地。
一句话总结：
KingbaseES的表级与列级加密能力，既能满足基础的落盘保护，也能覆盖高安全场景下的密态隔离需求。关键在于分层设计、合理选型、规范运维。