单钥全局唯一、算法锁定不可换、证书口令即数据生死、权限集中易误操作、运维兼容有边界。

活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式



# GBase 8a 加密表和密钥证书操作的风险边界

数据加密这类功能，平时看起来只是一组建表关键字和密钥管理命令；一旦放到生产环境，它就变成了安全、运维和恢复能力共同承担的风险点。GBase 8a 支持表级、列级加密，也支持 AES 和国密 SM4 等算法选择，还涉及密钥证书创建、打开、关闭、口令修改、密钥转换等操作。这里任何一个动作做错，都不是简单改一条 SQL 就能补回来。

尤其要注意一点：加密不是普通字段属性。官方文档里明确提到，数据使用密钥文件内容加解密后，密钥文件内容不能再改变；算法指定后也不允许随意更换，否则原有密钥无法用新算法正确解密数据。也就是说，加密能力上线前必须设计好，不能按“先建起来，后面再改”的思路处理。

## 加密对象先分清表级和列级

GBase 8a 支持通过 `encrypt` 关键字创建加密表或加密列。表级加密适合整张表都属于敏感数据的场景，列级加密适合只保护少数字段，比如证件号、手机号、账户标识等。选择粒度时不要只考虑安全强度，也要考虑查询、加载、备份、恢复和性能影响。

```sql
-- 表级加密示例
CREATE TABLE sec_customer_all (
    cust_id     bigint,
    cert_no     varchar(32),
    mobile_no   varchar(32),
    cust_name   varchar(128)
) ENCRYPT;

-- 列级加密示例
CREATE TABLE sec_customer_part (
    cust_id     bigint,
    cert_no     varchar(32) ENCRYPT,
    mobile_no   varchar(32) ENCRYPT,
    cust_name   varchar(128)
);
```

如果只有两个字段敏感，把整张宽表都加密，可能会增加不必要的管理和性能成本；如果整张表都属于敏感明细，只加密几个字段又可能不符合安全要求。这里最好由业务、DBA、安全三方一起定，不要让开发在建表时临时决定。

| 加密粒度 | 适合场景 | 优点 | 风险 |
|---|---|---|---|
| 表级加密 | 整表敏感 | 管理简单、覆盖完整 | 影响面大 |
| 列级加密 | 少数字段敏感 | 更精细 | 字段遗漏风险 |
| 不加密，仅脱敏 | 展示层保护 | 查询方便 | 落地数据仍敏感 |
| 应用层加密 | 跨库统一 | 数据库不可见明文 | 查询能力受限 |

## 算法选择不要上线后再改

GBase 8a 通过参数 `_gbase_encrypt_new_mode` 指定加密算法，取值为 1 时为 AES，取值为 2 时为 SM4。这个参数只能在配置文件中修改，属于 global 范围。官方说明里还强调，算法指定后不允许更换其他安全算法，强制更换会导致原有密钥不能用新算法正确解密数据，参数超过 2 还会造成服务无法启动。

这类参数绝对不能在生产环境里试。上线前要明确：项目要求 AES 还是国密 SM4，是否有等保、密评、监管要求，是否需要统一算法口径。定下来以后，要把配置、密钥证书、加密对象和恢复预案作为一套资产管理。

```text
加密算法：SM4
配置范围：所有 gcluster、gnode 节点
证书路径：$GBASE_BASE/config/encryption.crt、$GCLUSTER_BASE/config/encryption.crt
证书类型：密文密钥证书
口令保管：双人保管，单独密封记录
恢复验证：测试环境完成证书恢复和加密表查询验证
```

算法选择不是 DBA 一个人的偏好问题，它影响合规、恢复和后续维护。尤其是国密要求场景，最好在库初始化和加密对象创建之前就定好。

## 密钥证书是恢复生命线

加密表最关键的不是建表语句，而是密钥证书。官方文档建议对密钥证书进行备份，因为证书丢失会影响已有数据的解密操作。这个提醒非常重要。很多团队备份数据库文件很认真，但忘了密钥证书本身也是恢复链路的一部分。没有证书，备份文件可能无法正确解密敏感数据。

密钥证书存放在 config 目录，集群环境下 gnode 与 gcluster 都会生成相同的密钥证书文件。生产环境里必须把证书备份纳入备份策略，而不是只备份数据目录。

```bash
#!/bin/bash
set -e

BACKUP_DIR="/secure_backup/gbase_encrypt_cert/$(date +%Y%m%d_%H%M%S)"
mkdir -p "${BACKUP_DIR}"

cp "$GBASE_BASE/config/encryption.crt" "${BACKUP_DIR}/gnode_encryption.crt"
cp "$GCLUSTER_BASE/config/encryption.crt" "${BACKUP_DIR}/gcluster_encryption.crt"
sha256sum "${BACKUP_DIR}"/*.crt > "${BACKUP_DIR}/sha256sum.txt"
chmod 600 "${BACKUP_DIR}"/*.crt
```

证书备份不是越多人能拿越好。它既要防丢，也要防泄露。比较稳的做法是加密离线备份、双人审批恢复、定期校验文件哈希，并在测试环境演练恢复。

## 密文证书打开和关闭会影响 DML

如果使用密文密钥证书，打开证书后才能对加密列做 DML 操作；关闭密文密钥证书后，对加密列的 DML 操作会失效。这一点在日常运维里很容易踩坑：应用突然不能写入加密列，排查半天才发现证书没有打开或被关闭。

因此，涉及加密表的任务启动前，建议检查证书状态。证书打开、关闭、口令修改这类动作不要由普通发布脚本随意执行，应该走安全审批。

```sql
-- 创建密钥证书示意，生产口令不得写入脚本明文
CREATE ENCRYPTION CERTIFICATE IDENTIFIED BY 'password_example';

-- 查看加密属性
SHOW CREATE TABLE sec_customer_part;
```

实际生产中不要把证书口令写进脚本仓库，也不要放在调度平台明文参数里。口令保管应该独立于数据库账号保管。

## 不支持 ALTER 增加 encrypt，要提前设计

GBase 8a 支持使用 `create table` 和 `encrypt` 关键字创建带加密属性的表或列，也可以通过 `create table like` 建表；但不支持用 `alter` 命令给表或列增加 encrypt 属性。这意味着敏感字段是否加密，最好在建表阶段确定。

如果一张已存在的大表后续被要求加密，通常不能简单 `ALTER COLUMN ENCRYPT`。更现实的做法是新建加密表，迁移数据，验证后切换。

```sql
CREATE TABLE sec_customer_new (
    cust_id     bigint,
    cert_no     varchar(32) ENCRYPT,
    mobile_no   varchar(32) ENCRYPT,
    cust_name   varchar(128)
);

INSERT INTO sec_customer_new
SELECT cust_id, cert_no, mobile_no, cust_name
  FROM customer_old;

-- 校验数据量和关键字段后再切换
SELECT COUNT(*) FROM customer_old;
SELECT COUNT(*) FROM sec_customer_new;
```

切换时要考虑下游对象、权限、加载脚本、报表 SQL、备份策略。如果只是新建加密表而不更新依赖对象，后面很容易出现“数据加密了，但业务还在读旧表”的情况。

## 常见风险清单

| 风险 | 后果 | 预防方式 |
|---|---|---|
| 密钥证书未备份 | 备份数据无法解密 | 证书纳入备份和演练 |
| 算法上线后更换 | 原数据无法正确解密 | 上线前确定算法 |
| 口令明文写脚本 | 安全泄露 | 使用安全保管机制 |
| 证书未打开 | 加密列 DML 失败 | 任务前检查证书状态 |
| 误以为可 ALTER 加密 | 改造计划失败 | 新建加密表迁移 |
| 加密范围过大 | 性能和维护成本上升 | 表级/列级评估 |
| 恢复未演练 | 真故障时不可用 | 测试恢复流程 |

## 结尾总结

GBase 8a 加密能力不能只当成建表语法来用。表级加密、列级加密、算法选择、密钥证书、口令保管、备份恢复，这些内容必须一起设计。尤其是密钥证书，它和数据备份同等重要，甚至在恢复加密数据时更关键。

如果要在生产环境使用加密表，建议先明确算法和合规要求，再确定加密粒度，然后建立证书备份、口令保管和恢复演练流程。已有表后续加密时，不要期待简单 ALTER，而要按新表迁移和对象切换来规划。这样加密功能才能真正提升安全性，而不是变成恢复时最大的风险点。

## 参考资料

```text
[1] GBase 8a 数据加密官方文档 https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/admin-administrator-guide/admin-management-secure/admin-data-encryption
[2] GBase 社区优质文章区 https://www.gbase.cn/community/section/11
```

```

```



GBase 8a 加密表和密钥证书操作的风险边界

GBase 8a 加密表和密钥证书操作的风险边界

评论

热门帖子