KingbaseES 表级与列级加密完全指南

一、引言：表级与列级加密的价值定位

在金融、政务、医疗等关键行业，数据安全不再是“加分项”，而是系统建设的“基础项”。随着《密码法》、等保 2.0、商用密码应用安全性评估等要求逐步落地，敏感数据加密存储成为数据库建设的重要能力。尤其在国产化场景下，优先采用国密算法是合规建设的关键要求。

然而，在实际项目中，DBA 和架构师通常面临三类问题：

挑战	具体表现
合规要求	敏感数据需满足加密存储要求，且很多场景优先要求使用国密算法
性能顾虑	加解密会消耗 CPU 资源，高并发场景下需要平衡安全与性能
权限隔离	仅有“落盘加密”还不够，某些场景还要求 DBA 无法直接查看明文

针对这些问题，KingbaseES 提供了覆盖不同安全等级的表级与列级加密能力：

方案	插件	加密粒度	核心定位
方案一	sysencrypt	表级	自动透明、业务无感、整表防护
方案二	kbcrypto	字段级	国密合规、精准控制、手动加解密
方案三	kdb_ce	字段级	全程密态、DBA 不可见、最高安全等级

说明：本文重点讨论 表级加密与列级加密。

本文将从原理、实战、性能、运维、选型五个维度，对 KingbaseES 的三种常见加密方案进行系统梳理。

---

二、加密能力全景图：三种方案，各有侧重

2.1 架构定位

从安全能力和实现方式来看，这三种方案并非相互替代，而是分别面向不同场景：

┌─────────────────────────────────────────────────────────────────┐
│              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 工作原理

写入流程：
应用提交明文 → 数据库处理明文 → 落盘前加密 → 磁盘存储密文

读取流程：
磁盘读取密文 → 数据库解密 → 执行层处理明文 → 返回应用明文

它具有以下关键特征：

• 对业务 SQL 基本透明；
• 数据文件以密文方式落盘；
• 查询时由数据库自动完成解密；
• 适合对“整表敏感数据”进行统一防护。

需要注意：透明加密主要解决的是存储层防护问题，
并不等同于“数据库内任何角色都无法看到明文”。

4.2 环境准备

# 1）修改配置文件
vi $KINGBASE_DATA/kingbase.conf

shared_preload_libraries = '...,sysencrypt'

# 2）重启数据库
sys_ctl restart -D $KINGBASE_DATA

-- 3）创建扩展
CREATE EXTENSION sysencrypt;

4.3 创建加密表

CREATE TABLE customer_encrypted (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    id_card VARCHAR(18),
    phone VARCHAR(11),
    created_at TIMESTAMP DEFAULT NOW()
) ENCRYPTED;

插入与查询方式与普通表保持一致：

INSERT INTO customer_encrypted VALUES 
    (1, '张三', '11010119900307663X', '13800000001', NOW()),
    (2, '李四', '11010119911212456X', '13800000002', NOW());

SELECT * FROM customer_encrypted;

4.4 验证表是否已加密

SELECT sysencrypt.is_table_encrypted('customer_encrypted');

也可以查询系统视图：

SELECT *
FROM sysencrypt.sys_table_encrypt
WHERE tablename = 'customer_encrypted';

查看对应的数据文件路径：

SELECT sys_relation_filepath('customer_encrypted');

4.5 从底层验证密文落盘

# 请将路径替换为上一步 sys_relation_filepath 的实际输出
hexdump -C $KINGBASE_DATA/base/14712/16482 | head -20

关键输出片段（密文特征）：

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 原理说明

变更加密状态时，数据库不会修改原文件属性，而是重建整个表：

原始表 (relfilenode = A)
    │
    ├── 1. 加 AccessExclusiveLock 锁
    │
    ├── 2. 创建新数据文件 (relfilenode = B)
    │
    ├── 3. 逐行读取原表 → 加密/解密 → 写入新文件
    │
    ├── 4. 更新系统目录，将表指向新文件
    │
    └── 5. 删除原数据文件 (relfilenode = A)

为了更直观理解，我们可以用一个简单的比喻：原表就像一栋旧房子，要改变它的加密状态，不是直接在旧房子上修改，而是在旁边重新盖一栋新房子（新数据文件），把旧房子里的东西（数据）搬过去，然后拆除旧房子。这就是为什么变更后 sys_relation_filepath 返回值会变化。

4.6.2 实际操作演示

变更为非加密表：

ALTER TABLE customer_encrypted NOT ENCRYPTED;

SELECT sys_relation_filepath('customer_encrypted');

 sys_relation_filepath
-----------------------
 base/14712/16488      -- 文件路径已变化

再变更为加密表：

ALTER TABLE customer_encrypted ENCRYPTED;

SELECT sys_relation_filepath('customer_encrypted');

 sys_relation_filepath
-----------------------
 base/14712/16492      -- 文件路径再次变化

此外如果显式指定密钥，也可能出现类似写法：

ALTER TABLE customer_encrypted ENCRYPTED BY 'new_key_2025';

但从安全实践角度看：

• 优先使用系统生成或托管密钥；
• 不建议在 SQL 中直接显式写入明文密钥；
• 所有变更加密状态的操作都应在维护窗口执行。

4.7 风险提示

变更表加密状态通常属于重量级操作，需要重点关注以下影响：

• 会持有 AccessExclusiveLock，期间表完全不可读不可写
• 需要重建数据文件，带来较大 I/O 与 CPU 开销
• 操作期间新旧文件同时存在，需额外存储空间（约等于原表大小）
• 大表操作时间可能较长，且会生成大量 WAL 日志

建议：

1. 先在测试环境完整演练；
2. 评估表大小与业务低峰窗口；
3. 检查是否存在长事务与锁等待；
4. 变更后再次验证加密状态与业务可用性。

本节小结

sysencrypt 最适合作为整表级的基础防护方案。它的最大优势是改造成本低、上线速度快，尤其适合存量系统。

---

五、方案二：字段级国密加密（kbcrypto）

核心关键词：精细、灵活、显式控制。

如果您的诉求是只加密某几个字段，且希望明确控制何时加密、何时解密、使用什么算法，那么 kbcrypto 更合适。

5.1 加载扩展

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类型存储密文）：

CREATE TABLE staff (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    id_card_encrypted BYTEA,   -- 存储加密后的身份证号
    phone_encrypted BYTEA       -- 存储加密后的手机号
);

插入时手动加密（使用::BYTEA转换）：

INSERT INTO staff VALUES (
    1,
    '王五',
    sm4('11010119900307663X'::BYTEA, '0123456789ABCDEF'::BYTEA, 0),
    sm4('13912345678'::BYTEA, '0123456789ABCDEF'::BYTEA, 0)
);

查询时手动解密并转换为可读文本：

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;

预期输出：

 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存储口令摘要

对于密码类字段，通常不建议做“可逆加密”，而是使用不可逆摘要。

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参数影响：

-- 设置输出格式为转义模式（更易读）
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 双层密钥体系

CMK（客户端主密钥）
   ↓ 保护
CEK（列加密密钥）
   ↓ 加密
业务列数据

其中：

• CMK：客户端主密钥，建议存放于本地KMS或HSM；
• CEK：列加密密钥，由CMK保护；
• 数据库端通常只保存受保护后的密钥材料与密文数据。

这种设计的关键价值在于：数据库本身不直接掌握明文密钥，从而降低高权限账号直接接触明文的可能性。

6.3 环境配置

一、加载插件

vi $KINGBASE_DATA/kingbase.conf

添加kdb_ce到共享预加载库：

shared_preload_libraries = '...,kdb_ce'

二、重启数据库

sys_ctl restart -D $KINGBASE_DATA

三、设置localkms环境

# 设置环境变量
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

四、开启客户端全密态模式

# -M参数是开启客户端全密态的关键
ksql -U system -d test -p 54321 -M

五、创建插件

CREATE EXTENSION kdb_ce;

6.4 创建密钥对象

创建客户端主密钥（CMK）：

CREATE CLIENT MASTER KEY cmk_1 WITH (
    KEY_STORE = LOCALKMS,
    KEY_PATH = "kms_1",
    ALGORITHM = RSA_2048
);

创建列加密密钥（CEK）：

CREATE COLUMN ENCRYPTION KEY cek_1 WITH VALUES (
    CLIENT_MASTER_KEY = cmk_1,
    ALGORITHM = AEAD_AES_256_CBC_HMAC_SHA256
);

6.5 创建全密态表

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 插入与查询数据

插入数据：

INSERT INTO creditcard_info VALUES 
    (100, 'myname', 'manager1', 112233.123, 'creditcard888888', 123),
    (200, 'thename', 'employe', 52233.123, 'creditcard77777', 45678);

CHECKPOINT;  -- 数据落盘

等值查询：

SELECT * FROM creditcard_info WHERE name = 'thename';

非等值查询：

SELECT * FROM creditcard_info WHERE name <> 'thename';

6.7 两种加密类型的选择

类型	特点	适用操作	安全性
DETERMINISTIC	相同明文对应相同密文	等值查询、JOIN、部分分组场景	相对较低
RANDOMIZED	相同明文对应不同密文	不适合等值匹配	更高

选择原则通常是：

• 需要参与查询条件的列：优先考虑DETERMINISTIC；
• 仅存储展示、不参与条件匹配的列：优先考虑RANDOMIZED；
• 密码类信息：依然更建议使用不可逆摘要，而不是可查询加密。

6.8 验证全密态效果

验证一：存储层加密

在不使用-M参数的普通连接下，查询加密表：

ksql -U system -d test -p 54321

SELECT * FROM creditcard_info;

加密列将显示为乱码密文，而非正常数据。

验证二：查看数据文件

SELECT sys_relation_filepath('creditcard_info');

hexdump -c $KINGBASE_DATA/base/14712/16567 | head -20

数据文件内容应为不可读的密文。

验证三：抓包验证传输内容（可选）

tcpdump host xx.xx.xx.xxx and port 54321 -i any -vv -X -s 0 -w /tmp/encrypt.pcap

6.9 环境清理

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 决策思路

决策思路：

1. 是否需要对整张表做快速、低改造的加密防护？

   • 是 → 优先考虑sysencrypt

2. 是否只需要对少量敏感字段进行精准保护？

   • 是 → 优先考虑kbcrypto

3. 是否要求DBA也无法直接查看明文？

   • 是 → 优先考虑kdb_ce

8.2 场景推荐表

业务场景	推荐方案	改造成本	原因
客户主数据表、订单表	sysencrypt	极低	整表防护，业务无感
密码 / 口令	kbcrypto.sm3()	低	不可逆摘要更合适
身份证号、银行卡号、手机号	kbcrypto.sm4()	中	字段级精准加密，需改SQL
核心账户信息	kdb_ce	中高	更强的权限隔离能力
电子病历主表	sysencrypt + kbcrypto	中	整表基础防护 + 关键字段强化

8.3 组合方案示例

在很多真实项目中，并不是三选一，而是分层使用。

例如：

• 整张客户表使用sysencrypt；
• 身份证号字段再用kbcrypto.sm4()二次加密；
• 密码字段使用kbcrypto.sm3()存摘要；
• 对极少数核心账户表再单独考虑kdb_ce。

-- 组合方案：透明加密整表 + 字段级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 变更加密状态前的检查

-- 1. 评估表大小
SELECT sys_size_pretty(sys_total_relation_size('customer_encrypted'));

-- 2. 检查当前是否已加密
SELECT sysencrypt.is_table_encrypted('customer_encrypted');

-- 3. 检查活动会话与锁影响
SELECT pid, state, query, wait_event_type, wait_event
FROM sys_stat_activity
WHERE query LIKE '%customer_encrypted%'
   OR state = 'active';

9.3 执行变更与事后验证

ALTER TABLE customer_encrypted ENCRYPTED;

变更后建议继续验证：

SELECT sysencrypt.is_table_encrypted('customer_encrypted');

SELECT sys_relation_filepath('customer_encrypted');

SELECT count(*) FROM customer_encrypted;

9.4 操作建议

1. 所有重量级加密变更必须走维护窗口；
2. 上线前必须做测试环境演练；
3. 备份文件要单独加密保管；
4. 建立密钥保管人与恢复预案；
5. 将加密纳入巡检项，而不是一次性交付项。

---

十、总结

KingbaseES在表级与列级加密方面，提供了从“基础存储加密”到“高等级密态保护”的完整能力体系：

方案	插件	一句话定位
方案一	sysencrypt	整表透明加密，改造成本最低
方案二	kbcrypto	字段级国密加密，控制最灵活
方案三	kdb_ce	全密态保护，安全隔离最强

如果做一个工程化建议，可以概括为：

• 大多数项目：优先使用sysencrypt做整表透明加密，以较低成本实现基础的数据加密保护，满足一般业务场景对数据安全的需求。
• 关键敏感字段：叠加kbcrypto.sm4()或kbcrypto.sm3()，针对特定敏感字段进行更精细的加密控制，增强敏感信息的安全性。
• 极高安全要求场景：对核心表采用kdb_ce，提供最高等级的数据安全防护，确保在对数据保密性和完整性要求极高的场景下，数据不被非法获取或篡改。

最终，真正合理的方案往往不是“全都上最强”，而是：

按数据敏感度分级、按业务改造成本取舍、按合规要求落地。

一句话总结：

KingbaseES的表级与列级加密能力，既能满足基础的落盘保护，也能覆盖高安全场景下的密态隔离需求。关键在于分层设计、合理选型、规范运维。

---