你应该知道的数仓安全——细粒度透明加密

1. 前言

  随着《数据安全法》《个人信息保护法》的落地，数仓中敏感数据（如薪资、个人信息）的静态加密成为企业合规刚需。本文以 DWS 细粒度透明加密为例，拆解其原理、配置、实践案例及约束，帮你快速落地数仓数据安全防护。

• 适用版本：【9.1.1及以上】
    透明数据加密是数据库内核层面的数据保护机制。其“透明性”体现在对上层应用完全无感知——应用程序无需任何改造，即可像操作普通数据一样进行读写，而加解密过程由数据库在底层自动完成。该技术的核心原理是：在数据写入磁盘时自动加密，从磁盘读取时自动解密。这使得存储文件始终以密文形式存在，而内存中的数据则以明文形式处理。它能有效防止攻击者通过窃取存储设备、直接访问数据库文件等方式获取敏感信息，从而保证数据的安全。

2. 细粒度透明加密是什么？

  DWS 提供的细粒度数据安全特性，支持表级（行存 / 列存表）、列级（仅列存表）的精准加解密配置，可根据业务敏感数据范围灵活选择加密粒度（区别于 “集群级全量加密” 的粗粒度）。

3. 加密算法

  当前支持两种加密算法AES-CTR-128和SM4-CTR-128。

4. 部署方式

支持以下两种部署形态：

• 云上部署：通过 AK/SK（Access Key ID/Secret Access Key）认证访问云厂商 KMS（密钥管理服务），适配云环境下的数仓部署；
• ESL 本地部署：通过用户名 / 密码认证对接本地 KMS，适配私有化部署场景。”

5. 设计原理

  透明加密通过对存储层的静态数据加密，可以防止攻击者绕过数据库认证机制直接读取数据存储中的敏感信息，即使磁盘文件被窃取，但磁盘中敏感信息已经加密，窃取者无法解密而得不到有效的用户数据，从而保证了数据的安全。

  基本工作原理如下图所示：

• 写入流程：应用程序传入数据明文 → SQL 引擎转发至存储引擎 → 加密模块从 KMS 获取数据密钥 → 对数据加密 → 密文写入磁盘；
• 读取流程：从磁盘读取密文 → 加密模块用数据密钥解密 → 明文传递给 SQL 引擎 → 返回应用程序。

6.密钥缓存

  细粒度透明加密采用了一种密钥缓存机制，在内存中维护一个存储密钥明文和密文的哈希表，从而避免每次数据加解密时都需要与远程KMS服务交互。为了平衡安全与性能，该系统引入了基于时间戳的自动清理机制：每次缓存密钥时都会记录当前时间戳，会定期调用检查所有缓存项。比对每个密钥的时间戳与当前时间，如果发现缓存时间超过预设的有效期（默认为一小时，可通过tde_cache_config参数调整），则立即清除该密钥的缓存记录。这样既保证了高频访问时的性能提升，又确保了密钥明文不会长期驻留内存，有效控制了安全风险窗口。

7.kae加速

配置指南：
细粒度透明加密对于sm4算法适配了KAE加速功能，多个列同时加密时性能提升效果明显。具体配置方法如下（ESL）（需要每个DN机器都配置）。
步骤1：安装FI集群并配置加密算法。
步骤2：登录集群确定是加密集群。
步骤3：安装KAE,并申请license。
步骤4：配置数据库使用KAE。
   - 停集群
   - 修改每个节点的config文件‘.gs_profile’，添加 export OPENSSL_ENGINES=PATH
   - 对每个节点，kill om_monitor，并等待其重新运行
   - 启动集群
步骤5：跑语句，验证KAE生效。

性能摸底：
              

 
从测试数据可看出：KAE 加速引擎对 SM4 加解密性能提升效果显著，使其耗时接近未加密场景的原生耗时水平。

8.案例

假设一个公司的人力资源系统，从最初建立到不断完善安全措施的过程。
起初，小李创建了一个简单的员工信息表，还没有考虑加密：

CREATE TABLE employees (
    emp_id int PRIMARY KEY,
    emp_name text,
    emp_email text,
    emp_phone text,
    salary decimal(10,2),
    hire_date date
);

但是，公司安全团队很快指出，员工信息包含敏感数据（如工资），必须加密存储。
安全团队首先要求对整个数据库集群启用加密，并定期轮转密钥：

-- 初始加密密钥设置（由安全团队完成，小李负责执行）
-- 假设已经设置过，现在进行第一次轮转：
ALTER CLUSTER ENCRYPTION KEY ROTATION;

小李决定对员工表进行加密。由于员工信息经常需要按行访问，他选择行存加密，并使用默认的AES_CTR_128算法：

CREATE TABLE employees_encrypted (
    emp_id int PRIMARY KEY,
    emp_name text,
    emp_email text,
    emp_phone text,
    salary decimal(10,2),
    hire_date date
) WITH (encrypt_option = table);

由于中国金融行业要求使用国密算法，公司决定对财务部门访问的工资信息使用SM4_CTR_128算法。小李创建了一个新的工资表：

CREATE TABLE salaries (
    emp_id int,
    salary decimal(10,2),
    bonus decimal(10,2),
    effective_date date
) WITH (encrypt_option = table, encrypt_algo = SM4_CTR_128);

人力资源分析团队需要分析员工信息，但只关心某些列，并且需要高效的列式扫描。小李创建了一个列存加密表，并只加密敏感列：

CREATE TABLE hr_analysis (
    emp_id int,
    emp_name text,
    emp_department text,
    salary decimal(10,2) ENCRYPT,   -- 只加密工资列
    performance_score int
) WITH (orientation = column, encrypt_option = column);

但是，后来安全政策要求所有列都必须加密，于是小李又创建了一个全列加密的列存表：

CREATE TABLE hr_analysis_full_encrypt (
    emp_id int,
    emp_name text,
    emp_department text,
    salary decimal(10,2),
    performance_score int
) WITH (orientation = column, encrypt_option = table);

后来，公司决定将员工姓名和邮箱公开（例如用于内部通讯录），因此小李将原来的加密表解密：

ALTER TABLE employees_encrypted SET (encrypt_option = none);
-- 执行vacuum full刷新数据
vacuum full employees_encrypted;

由于安全政策升级，原来未加密的员工表（employees）现在需要加密。小李使用以下语句将其转换为加密表：

ALTER TABLE employees SET (encrypt_option = table);
-- 执行vacuum full刷新数据
vacuum full employees;

但是，财务部门要求使用国密算法，所以小李又将工资相关的表改为使用SM4_CTR_128：

ALTER TABLE salaries SET (encrypt_algo = SM4_CTR_128);
-- 执行vacuum full刷新数据
vacuum full salaries;

公司安全标准升级，要求所有加密表使用国密算法。小李将员工表的加密算法改为SM4_CTR_128：

ALTER TABLE employees SET (encrypt_algo = SM4_CTR_128);
-- 执行vacuum full刷新数据
vacuum full employees;

按照公司安全策略，每半年进行一次密钥轮转。小李执行：

ALTER CLUSTER ENCRYPTION KEY ROTATION;

注：如果表的加密属性改变之后需要执行vacuum full将存储数据刷新。

9. 约束与限制

• 集群级透明加密和细粒度透明加密功能互斥，无法同时开启。已经开启了集群级透明加密，则无法开启细粒度透明加密功能。
• 升级观察期内，不支持创建透明加密表。
• 行存表不支持列级的透明加密配置。
• 索引不支持修改透明加密配置。
• 不支持基于加密表创建物化视图， 不支持对物化视图加密。
• 普通列存+delta表、Hstore非opt表、行列混存和LSM表不支持表级加密。
• 临时表不支持加密。
• 大宽表不支持加密。

10. 总结

   DWS 细粒度透明加密通过 “表 / 列级灵活加密 + 密钥缓存 + KAE 加速” 的组合，在满足数据安全合规的同时兼顾性能。实践中需注意其约束条件（如行存 / 列存的加密粒度差异），结合业务场景选择加密方式，并定期执行密钥轮转，才能构建安全、高效的数仓环境。