金仓数据库数据安全双防线:静态存储加密与传输加密实战

聊数据库安全这个话题,我发现很多人有个误区,以为配好了网络加密、设好了权限,数据就安全了。其实这只防住了"动态"的那部分。还有一个更隐蔽的风险点:当硬盘、备份磁带这些存储介质因为丢失、被盗或者报废而脱离了数据库系统的控制,上面躺着的静态数据如果是明文,那就等于裸奔了。

所以一套完整的数据安全防线,得同时管住两头:数据"躺着"的时候(静态存储)和数据"跑着"的时候(网络传输)。这篇文章我想把金仓数据库(KingbaseES)在这两条战线上的能力都讲透------前半部分聊表空间加密怎么保护落盘的静态数据,后半部分聊 SSL/TLS 怎么保护传输中的数据。都是实操过的东西,希望能帮你把存储层和传输层这两道墙都砌牢。

第一部分:静态数据防线------表空间加密

一、表空间加密到底在防什么

先说清楚定位。表空间加密是金仓透明存储加密体系里的一种粗粒度防护方案,它要解决的核心问题就一个:防物理泄露。即使数据库文件或者备份被人非法拿到了,没有密钥,攻击者也读不出里面是什么。

它有几个特别实用的特点。应用完全透明 是我最看重的一点:加密解密全由数据库内核自动完成,你的应用代码一行都不用改。高性能 也很关键,它采用页面级块加密,在存储层做加解密,对整体性能的影响压到了最小。还有批量管理,存进加密表空间的所有对象自动加密,管理成本一下就下来了。

金仓其实提供了三种粒度的加密,放一起对比你就明白该怎么选了:

对比维度	表空间加密	表级加密	列级加密
加密粒度	表空间级	表级	字段级
加密范围	表空间中所有对象	单个表	单个字段
业务改造	无需改造	无需改造	需改 SQL
管理成本	低(批量)	中	高
灵活性	低	中	高
适用场景	批量数据基础防护	整表敏感数据	字段级精准控制

粒度从粗到细,灵活性从低到高。实际项目里,完全可以按数据敏感度和改造成本,选一种或者组合着用。

二、绕不开的核心概念:钱包与密钥体系

进入实操前,有两个概念必须先建立起来,不然后面会一头雾水。

第一个是 TDE 钱包。 钱包是一个加密容器,统一管理所有密钥,而且它跟数据文件是分离存储 的。这点至关重要:没有钱包,你就算拿到数据文件也解不开。钱包默认放在集簇主数据目录下的 wallet 隐藏目录里。我必须重点强调------钱包一定要定期备份,万一系统或硬件损坏导致钱包丢了,加密数据就再也找不回来了。

第二个是三级密钥结构。 金仓的密钥分三层:主密钥唯一,用来加密对象密钥,安全管理员可以通过 SQL 命令更新;对象密钥每个加密对象一个,互不重复,由系统自动维护;块级密钥则根据对象密钥和块标识生成,是加密时实际用的密钥。这种层层保护的设计,让密钥管理既安全又有条理。

至于加密算法,框架内置支持 SM4 和 RC4。其中 SM4 是国密算法,分组长度和密钥长度都是 128 位。合规要求严格的场景,优先用 SM4。

三、环境准备:加载插件与设置钱包

表空间加密依赖 sysencrypt 插件。第一步是把它加到共享预加载库,改配置文件:

bash 复制代码

vi $KINGBASE_DATA/kingbase.conf

ini 复制代码

shared_preload_libraries = '...,sysencrypt'

改完重启数据库,然后创建扩展:

bash 复制代码

sys_ctl restart -D $KINGBASE_DATA

sql 复制代码

CREATE EXTENSION sysencrypt;

用 \dx sysencrypt 能验证扩展装好了。接着是钱包管理,创建加密表空间前必须先设钱包密码并打开钱包。注意钱包密码要满足复杂度要求,而且必须放在双引号里:

sql 复制代码

-- 首次使用,设置钱包密码
ALTER WALLET WITH PASSWORD "Sm4@Wallet#2026";

-- 打开钱包
OPENUP WALLET WITH PASSWORD "Sm4@Wallet#2026";

这里有个血泪警示:钱包密码一旦忘记就无法找回,加密数据将永久无法解密。 务必牢记,并在多个安全的地方备份。

四、方式一:用命令显式创建加密表空间

这种方式的关键词是显式控制、手动创建、灵活指定密钥。先建操作系统目录,再创建加密表空间:

bash 复制代码

mkdir -p /home/kingbase/tbs_finance

sql 复制代码

CREATE TABLESPACE tbs_finance_enc LOCATION '/home/kingbase/tbs_finance'
WITH (encryption = true, enckey = 'Sm4@Fin#2026');

两个参数说明一下:encryption = true 标识这是加密表空间;enckey 是用户自定义密钥,最大有效长度 16 字节,超出会被截断,不指定就用系统生成的主密钥。要注意自定义密码至少包含 1 个数字和 1 个字母,而且必须放在单引号里(跟钱包密码用双引号正好相反,别搞混)。

在加密表空间里建表插数据,执行检查点:

sql 复制代码

CREATE TABLE fin_product (id INT, name VARCHAR(10)) TABLESPACE tbs_finance_enc;
INSERT INTO fin_product VALUES (1, 'PRODUCT_A'), (2, 'PRODUCT_B');
CHECKPOINT;

怎么验证真的加密了?这招很硬核。先找到数据文件路径:

sql 复制代码

SELECT sys_relation_filepath('fin_product');

然后直接用 hexdump 去看文件内容:

bash 复制代码

hexdump -c /data/sys_tblspc/16464/SYS_12_202211151/12259/16465

你会看到一堆乱码似的密文,完全读不出业务明文。作为对比,如果在非加密的默认表空间里建同样的表,hexdump 出来的内容里能直接看到 LOG_A 这种可读字符。这个对比一做,加密效果一目了然。

而且加密对操作完全透明,DQL、DML、DDL 全都正常使用,你该怎么查怎么改,跟普通表没任何区别。

五、方式二:用参数控制自动加密

这种方式的关键词是自动加密、参数控制、批量生效。核心是打开一个参数:

sql 复制代码

-- 默认是 off
SHOW sysencrypt.encrypt_user_tablespace;

-- 改成 on
ALTER SYSTEM SET sysencrypt.encrypt_user_tablespace = on;
SELECT sys_reload_conf();

参数一旦设为 on,之后用户创建的表空间就自动加密,建表时连 encryption = true 都不用写了:

sql 复制代码

mkdir -p /home/kingbase/tbs_log
CREATE TABLESPACE tbs_log_enc LOCATION '/home/kingbase/tbs_log';

这里有个特别需要理解的特性:加密状态是持久的。 表空间一旦加密,哪怕你后来把参数关回 off,它仍然保持加密。我实测过,关掉参数后再在这个表空间里建新表,数据文件依然是密文。除非把表空间删掉重建,否则加密状态不会变。

两种方式怎么选?简单对比一下:命令方式可以给每个表空间指定不同密钥,灵活性高,适合按需创建;参数方式用统一的系统主密钥,自动化程度高,适合批量创建。

六、几个必须记住的关键特性

加密互斥性。 表空间加密和表级加密是互斥的,同一个加密对象不允许同时用这两种方式。表在加密表空间里,表级加密就不生效,反之亦然。

加密范围。 只支持用户自定义表空间,系统表空间和默认表空间 sys_default 不可加密。加密表空间还可以设为默认表空间,之后在它下面建的表默认就是加密的。

变更加密状态是重量级操作。 这点要划重点:如果想给一个已加密的表空间取消加密,只能删掉重建。而变更加密状态时数据文件会被重建,占用大量磁盘 I/O 和 CPU,务必安排在业务低峰期执行。

七、选型决策

我把选型思路梳理成一条决策链,照着走就行:

需要批量保护大量数据?→ 优先表空间加密
需要对单个表精细控制?→ 优先表级加密
需要对字段精准保护(身份证、银行卡号这类)?→ 优先列级加密
要求连 DBA 都看不到明文?→ 优先全密态计算(kdb_ce)

真正合理的方案往往不是单选,而是按数据敏感度分级、按管理成本取舍、按合规要求落地。

第二部分:传输数据防线------SSL/TLS 加密配置

静态数据守住了,接下来该管数据在网线上跑的时候了。

八、为什么传输也必须加密

网络通信中,数据明文传输面临三大风险:被窃听、被篡改、身份被冒充。而数据库客户端和服务器之间传的,往往是最核心最敏感的业务数据。SSL(安全套接层)及其继任者 TLS(传输层安全)就是行业标准的解法,它能带来三重保障:

数据机密性 ,通过加密通道传输,数据包就算被截获,攻击者也解读不了内容。数据完整性 ,协议能检测数据在传输中是否被篡改,确保收发一致。身份验证,尤其是双向认证模式下,不光客户端验证服务器,服务器也验证客户端,只允许持合法证书的授权客户端连库,从根上防住未授权访问。

再加上等保、网络安全法这些合规要求明确规定敏感数据传输必须加密,配置 SSL/TLS 基本是绕不过去的一道工序。

九、用 OpenSSL 一步步生成证书

双向认证需要一套证书体系,我们用 OpenSSL 从零生成。整个思路是:先有一个根 CA 给大家签名背书,再为服务器签发证书。

第一步,为根 CA 生成私钥和自签名根证书。 先生成一个 2048 位的 RSA 私钥:

bash 复制代码

openssl genrsa 2048 > rootca.key

再用这个私钥生成自签名根证书,执行时各选项默认回车即可:

bash 复制代码

openssl req -new -x509 -nodes -days 3600 -key rootca.key -out rootca.crt

-days 3600 给了根证书将近十年的有效期,根 CA 是信任链的源头,有效期给长一点省得频繁更换。

第二步,为服务器生成私钥和证书请求文件(CSR)。

bash 复制代码

openssl req -newkey rsa:2048 -nodes -keyout kesserver.key -out kesserver.csr

这一步有个特别容易踩坑的地方 必须提醒:如果客户端的 sslnode 验证等级配成了 verify-full,它会校验证书里的 common name(通用名)。所以填 common name 的时候,要填服务器的真实名字,或者用 * 通配符表示不限制。这个字段填错,verify-full 模式下连接会直接失败,排查起来还挺费劲。生成 CSR 之后,再拿根 CA 给它签发出正式的服务器证书,整条信任链就接通了。

十、两道防线的协同

把这篇文章的两部分串起来看,你会发现金仓的数据安全是分层的:

存储层靠表空间加密,确保数据落盘后即使介质丢失也是密文;
传输层靠 SSL/TLS,确保数据在客户端和服务器之间流动时不被窃听篡改。

更进一步,如果安全要求极高,还可以叠加 WAL 日志加密,实现从存储到归档的全链路加密。这种"静态 + 传输"双管齐下的思路,才是构建完整数据安全体系的正确姿势。单守一头,另一头就是缺口。

写在最后

数据安全这件事,没有银弹,只有体系。表空间加密以批量、透明、高效的方式守住静态存储这道墙,SSL/TLS 则把传输通道这道墙砌牢。两者配合,再辅以规范的钱包备份、合理的选型决策和证书管理,才能真正构建起经得起考验的数据安全防线。

我的建议还是那句老话:加密配置先在测试环境充分评估,尤其是变更加密状态这种重量级操作,以及 verify-full 下的证书校验细节,都值得提前演练。把功夫下在平时,真正出事的时候才不会慌。