达梦数据库透明加密这个能力最早让我真正重视起来是几年前一个客户的验收环节。对方提的要求很朴素数据库里的身份证号、手机号在磁盘上不允许是明文。我当时的方案是应用层加密字段落库前用代码加密读出来再解密。结果被现实教育了一顿——那个字段的模糊查询、排序、范围统计全部退化业务方不接受而且系统里但凡有一个绕过应用直连库的地方数据就全乱套了。后来才转向达梦数据库自带的透明加密能力。这篇就把我这几年在库级、表空间级、列级三种加密粒度上的配置方法、密钥管理流程、性能实测和踩过的坑完整梳理一遍。内容偏实操适合正在做等保合规、数据安全验收或者准备把敏感字段从应用层加密迁移到数据库层的同行参考。1. 达梦透明加密的三种落地粒度库、表空间、列透明加密Transparent Data EncryptionTDE里的透明说的不是加密算法本身而是加密动作对应用完全透明。数据在写盘的那一刻被加密从盘上读回内存的那一刻被解密中间这层完全由数据库自己完成。你的 SQL 还是那句select * from t_cust where id 1JDBC 里的代码一行都不用改拿到的还是明文。真正发生变化的只有磁盘上那些数据文件、日志文件和备份集的字节内容。这一点非常关键因为它决定了迁移成本。我把一个已经有二十多张表、几十万行数据的测试库从明文切到加密应用侧零改动唯一的工作量在库本身。这也是我后面愿意花时间把达梦这套机制摸透的原因——它把安全需求当成基础设施问题解决了而不是甩给开发去写代码。达梦提供的加密粒度大致分三层这三层的生效时机和改造代价差别非常大选错了粒度后面想改会非常痛苦。加密粒度指定时机能否对存量对象追加影响范围改造代价库级实例初始化dminit阶段基本不行全部数据文件、日志、临时文件最高需要重建实例表空间级创建表空间时只能通过迁移到新表空间间接实现该表空间下所有段中等涉及数据搬迁列级建表或改表时可以对已有列追加指定的列较低但受数据类型限制库级加密最彻底一旦在初始化阶段开启整个实例所有的数据文件都是密文连临时表空间落盘的数据也是密文审计时几乎不用解释范围。它的代价是没有任何后悔药初始化参数定了就是定了想加密只能重新初始化一遍实例再把数据迁过去。所以我的建议很明确——如果合规要求是整库不能有明文那就在项目最早期把参数定下来别等到上线后再补。表空间级是我用得最多的一层。按业务模块划分表空间把涉及个人信息、账号、财务数据的那几个业务表空间建成加密的历史归档表空间保持明文这样既满足合规又不会让整个库白白承担加密开销。列级加密则是精细到最后一公里的手段适合那种整张表九成字段都不敏感只有一列身份证号需要保护的场景。1.1 三种粒度的选择逻辑先看合规边界再看性能预算很多人一上来就问哪个粒度最安全这个问题其实问偏了。安全等级上库级 表空间级 列级但工程上要问的是合规要求的最低边界在哪里。如果审计条款写的是存储公民个人敏感信息的数据库需加密存储那你只要保证承载这些信息的表空间是加密的就已经越过了合规线没必要把整个实例都拖进加密里。我的判断顺序一般是这样先圈出涉及敏感数据的表和它们的表空间归属如果这些表集中在少数几个业务模块就按表空间加密如果散落在十几个表空间里反而是库级加密更省事——因为表空间级加密的运维成本不低每个加密表空间在备份、还原、迁移时都要单独确认密钥和状态。还有一个容易忽略的点临时表空间和归档日志。做报表统计、大排序的时候数据会落到临时表空间上归档日志里也带着变更前后的字段值。如果合规边界卡得很严只加密数据表空间是不够的得评估临时文件和归档的落地风险。这也是库级加密在某些高要求场景下不可替代的原因。1.2 透明加密和应用层自己调加解密函数的本质差别我在前面提过应用层加密的教训这里展开说一下因为它直接决定了你要不要上 TDE。应用层加密的典型做法是插入前调一次加密函数查询出来调一次解密函数。这么做的直接后果是数据库里存的是乱码字符串SQL 层所有的语义操作全部失效——like 138%匹配不了order by排出来的是密文的字典序group by分组的结果没有业务意义索引建了也用不上。想统计某个手机号段的数量只能把整表拉到应用内存里挨个解密。表越大这条路越走不通。而且在达梦里还有一层麻烦加密后的字符串长度跟明文不一样字段定义长度要重新算稍不注意就报截断错误。透明加密走的是完全不同的路径。加解密发生在存储引擎读写数据页的环节SQL 层、优化器、索引层看到的都是明文。这意味着索引照常命中、排序照常工作、聚合统计结果照常正确。代价转移到了另外两个地方一是 CPU每次读写都要做一次密码运算二是密钥数据跟密钥绑定了密钥丢了数据就是一堆不可恢复的字节。值得一提的是达梦本身也提供 SQL 层的内置加解密函数可以做半透明的处理——需要哪些字段解密就显式调函数。这种方式的灵活性更高可以做到同一列对不同用户返回不同结果但代价是应用代码要跟着改而且同样会牺牲索引和查询优化能力。我的经验是能上 TDE 就上 TDE函数级加密留给那些必须在应用侧做二次校验的特殊场景。2. 密钥体系怎么运转主密钥、对象密钥与密钥文件加密这件事算法从来不是最脆弱的一环密钥管理才是。我见过太多项目把加密配好之后密钥这件事就扔在一边直到某天要做一次跨机房恢复才发现没人知道密钥在哪、口令是什么。所以这一节我想把达梦的密钥结构讲清楚后面所有的运维动作都建立在这个理解之上。达梦的透明加密采用两级密钥结构。上层是主密钥Master Key它不直接加密你的业务数据而是用来加密下层的对象密钥下层是对象密钥真正参与数据页或数据列的加解密运算。为什么要绕这一层因为密钥总有更新的时候。如果只有一级密钥换密钥就意味着必须把全库数据重写一遍对于 TB 级的库来说这是一次不可能在停机窗口内完成的操作。有了两级结构更换主密钥只需要把对象密钥重新加密一遍——对象密钥本身很短几百个字节几秒钟的事只有在怀疑对象密钥泄露时才需要做全量数据重写。这个设计的实际意义是日常的密钥轮换可以做得非常轻甚至可以在线完成而高风险场景下的彻底换钥才需要安排停机窗口。搞清楚这一点你在做密钥管理方案时就不会一刀切。2.1 密钥的持久化载体别只盯着数据文件主密钥和对象密钥的持久化方式在不同版本里有差异有的版本会以独立密钥文件的形式放在实例目录下有的版本把密钥信息保存在系统表空间里并用初始化时指定的加密口令做保护。具体形态我不建议死记最稳妥的做法是两条第一用ls -l看一眼实例目录把跟加密相关的文件都记下来形成一份清单后续运维文档里照抄这份清单第二任何一次跨越实例的物理搬迁都直接整目录拷贝不做任何只拷数据文件的偷懒操作。口令这块要单独强调。如果实例初始化时指定了加密口令这个口令不会以可读形式存在任何地方它只存在于人的记忆或者密钥管理系统里。我遇到过一次真实的险情某项目的 DBA 离职交接文档里只写了数据库已加密没写口令后来要搭一套灾备环境怎么都起不来。最后靠老同事回忆才试出来。这件事之后我坚持一个规矩——加密实例上线时口令必须进公司的密码管理系统同时在纸质应急包封存一份双人签字。2.2 密钥载体跟实例的绑定关系密钥跟实例是绑定的这一点在架构设计阶段就要考虑进去。单实例最简单密钥在实例目录下备份时把目录一起归档就行。一旦涉及主备、读写分离集群、共享存储集群这些架构问题就来了。主备架构下备库通常是用主库的全量副本搭起来的如果拷贝的时候只拷了数据文件、没拷密钥载体备库启动后打开数据文件会直接报错表现往往是文件损坏或者解密失败这类看起来像磁盘故障的信息——我第一次碰到时还在检查存储链路折腾了半天才意识到是密钥的问题。共享存储集群的场景稍微复杂一点因为多个节点访问的是同一份数据文件所有节点必须能拿到同一套密钥。如果你的部署方式是把数据文件放在共享存储上、实例目录放在各节点本地那就必须保证每个节点的本地密钥载体是同步的或者在方案设计上把密钥载体也放到共享存储的对应位置。这个细节在建集群的时候特别容易漏因为搭集群的步骤清单里通常只强调数据文件和配置文件。2.3 密钥备份与口令交接一个必须写进流程的动作我现在负责的项目里加密实例上线必须产出三样东西缺一样都不算交付完成一份密钥载体的离线副本介质跟数据库备份分开存放避免一次事故同时毁掉数据和密钥一份加密口令的封存记录进密码管理系统 纸质应急包双份一份无密钥不可恢复的风险告知让业务方签字确认最后一条听起来像是推责任其实是保护双方。因为确实有客户会问我数据库文件都备份了为什么还要单独管密钥当他理解到密钥丢失等于数据永久损坏之后才会认真配合做密钥归档。密钥变更的流程我也固定下来了变更前先做一次全量物理备份并验证可还原变更操作在业务低峰执行变更完成后立刻用客户端连上去做一次读写验证确认解密正常验证通过后再更新密钥归档记录。这套流程走过三四次没出过问题。3. 从零配一遍库级、表空间级、列级加密的实操链路原理讲完进入配置环节。这一节我按库级 → 表空间级 → 列级的顺序把命令走一遍同时把每个环节容易出问题的地方点出来。需要提前说明的是达梦不同小版本在参数名和语法细节上存在差异我给出来的命令是基于常见版本的写法你在自己的环境执行前先用帮助命令确认一下这比照着博客硬抄要可靠得多。3.1 初始化阶段就把库级加密定下来库级加密只能在初始化实例时指定所以第一步是确认当前版本的 dminit 支持哪些加密相关参数cd /dm8/bin ./dminit help | grep -i encrypt如果你看到类似ENCRYPT_NAME、ENCRYPT_PWD这样的参数说明这个版本支持在初始化时指定加密算法和加密口令。确认之后就可以建立实例./dminit PATH/dm8/data DB_NAMEDAMENG INSTANCE_NAMEDMSERVER \ PORT_NUM5236 PAGE_SIZE16 EXTENT_SIZE32 CHARSET1 \ ENCRYPT_NAMESM4 ENCRYPT_PWDYourStrongPwd#2024这里有三个经验点。第一PAGE_SIZE一旦定了就不能改加密实例尤其不要在后期尝试迁移页面大小成本极高。第二加密口令不要用数据库管理员密码也不要跟操作系统账号密码有任何关联它是独立的一套凭证。第三生产环境执行完初始化后立即用ls -l把实例目录里新出现的文件记录下来跟非加密实例对比一次你就能直观看出加密带来了哪些额外文件这些文件后续都要纳入备份范围。初始化完成后我习惯做一次落盘抽查往库里插一条特征字符串然后停库用strings扫一遍数据文件如果扫不到这条字符串说明库级加密生效了。这个方法后面还会详细说。3.2 表空间加密建的时候就定事后很难补表空间的加密状态是在创建时指定的事后对已有表空间开启加密这条路基本走不通可行的做法是新建加密表空间 数据搬迁 删除旧表空间。所以表空间规划要在建库阶段就想好。创建加密表空间的写法CREATE TABLESPACE TS_SEC DATAFILE TS_SEC.DBF SIZE 128 AUTOEXTEND ON NEXT 64 MAXSIZE 4096 ENCRYPT WITH SM4; CREATE USER APP_SEC IDENTIFIED BY App#2024 DEFAULT TABLESPACE TS_SEC;算法选择上如果环境支持国产密码算法优先用 SM4这在合规审查时更好解释如果只是为了满足存储加密的一般要求AES 相关的选项也够用。关键是要在建库前确定因为同一实例里不同表空间用不同算法虽然可行但运维时容易乱。对于存量数据的搬迁我常用的路径是新建加密表空间确认加密标志正常对目标表执行表空间迁移把数据和索引都搬到新表空间用行数、校验和之类的方式做数据比对业务验证通过后再清理旧表空间搬迁这一步骤要特别注意锁和 IO。大表迁移会长时间持有表级锁同时产生大量 redo如果库开了归档归档目录要提前扩容。我曾经因为没预估归档增长迁移到一半把归档盘写满了整个操作中断回滚又花了大半天。所以搬迁前先查一下目标表的数据量和索引数量估算 redo 增量留足空间再动手。3.3 列加密语法简单坑在长度和排序列加密的语法是最直观的直接在列定义后面加加密标记CREATE TABLE T_CUST ( ID BIGINT PRIMARY KEY, CUST_NAME VARCHAR(64), ID_NO VARCHAR(64) ENCRYPT WITH SM4, PHONE VARCHAR(64) ENCRYPT WITH SM4, ADDR VARCHAR(200) );注意我把手机号和身份证号都定义成了VARCHAR(64)而不是直觉上的VARCHAR(18)和VARCHAR(32)。这是我付过代价的地方加密后的数据在存储上会比明文长如果列定义长度卡得太紧插入时会直接报截断错误或者在某些路径上出现截断后无法解密的问题。我的经验做法是加密列的长度按明文最大长度的两倍预留短字段宁可宽一点也不要卡边界。对已经存在的列追加加密可以用修改列定义的方式ALTER TABLE T_CUST MODIFY PHONE VARCHAR(64) ENCRYPT WITH SM4;这个操作会重写列上的数据属于重量级变更一定要在停机窗口里做并且提前备份。执行前先确认这张表上没有不兼容的对象——比如某些特殊类型的索引、依赖该列的分区定义这些在加密列上可能不支持。性能上还有一个必须知道的特性加密列上的等值查询仍然可以走索引因为密文的等值对应着明文的等值但范围查询和排序就没这么幸运了密文的字节序跟明文字节序没有任何必然联系order by、between、前缀匹配这类操作往往拿不到理想的执行计划。所以我在设计表结构时有一条硬规矩加密列只用于精确匹配和展示不做排序键、不做范围过滤条件。业务上确实需要按手机号段筛选的就额外建一个脱敏后的辅助列比如只保留前三位和后四位的掩码列专门服务于查询敏感原值放在加密列里仅供展示和核对。3.4 怎么确认加密真的生效了配置完不代表生效验收环节一定要有客观证据。我一般用三种方式交叉验证。第一种是查字典视图确认表空间或列的加密标志位符合预期。不同版本里字段名不完全一样你在DBA_TABLESPACES这类视图上找跟加密相关的列即可以实际能查出来的为准。第二种是落盘抽查这是我认为最有力的证据。做法是往加密表里插一条特征值明确的测试数据提交后停库然后在操作系统层面对数据文件做扫描# 未加密的库通常能直接扫到明文 strings /dm8/data/DAMENG/TS_SEC.DBF | grep -c 13900001111 # 加密生效时同样的关键字应该扫不到 grep -a -c 13900001111 /dm8/data/DAMENG/TS_SEC.DBF未加密的情况下strings往往能直接命中明文手机号、姓名甚至部分 SQL 文本加密生效后同样的关键字扫不出来。这个方法简单粗暴但非常有效我在验收会上当场演示过一次比任何配置截图都有说服力。提醒一句抽查请用测试数据不要在生产库上把真实敏感数据打印到终端或者重定向到文件里。第三种是通过客户端正常查询看到的是明文说明透明性没问题。这三条都通过才算配置闭环。4. 性能账怎么算加密不是零成本任何说加密对性能没有影响的说法都是不负责任的。准确的说法是影响有多大取决于你的硬件、算法、加密粒度和业务访问模式。这一节我把影响因素拆开再给一套我自己常用的对比方法。4.1 影响开销的几个变量第一个变量是算法。不同算法的运算开销差异明显而且同样一个算法在有指令集加速的 CPU 上跑和在没有加速的 CPU 上跑差距可能是数倍。国产平台上的 SM4 如果有硬件加速支持开销是可以接受的老旧的通用 CPU 上做纯软件运算开销就会明显一些。第二个变量是加密粒度。列级加密只对涉及的那些列做运算其他列的读写完全不受影响所以如果加密列占比很低比如一张宽表只加密两列整体影响会小很多。库级和表空间级加密是对数据页整体处理影响面更大但单位数据的处理效率反而可能更高因为不需要逐列判断。第三个变量是业务访问模式。纯点查、走主键或者唯一索引的场景加密引入的额外运算发生在页面加载环节占比不高而大范围的顺序扫描、批量导入导出会让加解密运算量成倍上升。我用dmfldr做过大批量装载测试加密表和不加密表的耗时差距在批量场景下会更明显。第四个变量是数据特征。同样是加密列短字符串和长文本的单次运算量不一样宽表比窄表受影响更明显因为每次页面读写要处理的数据更多。4.2 一套可复现的对比方法我不太相信网上流传的性能下降百分之几的数字因为环境差异太大。我的做法是在准生产环境上自己跑一组对比具体步骤如下。首先建两张结构完全一致的表一张加密、一张不加密放在不同的表空间里避免互相干扰CREATE TABLE T_BENCH_ENC ( ID BIGINT PRIMARY KEY, PHONE VARCHAR(64) ENCRYPT WITH SM4, MEMO VARCHAR(200) ); CREATE TABLE T_BENCH_PLAIN ( ID BIGINT PRIMARY KEY, PHONE VARCHAR(64), MEMO VARCHAR(200) );然后用同一份数据文件通过dmfldr分别灌入两张表记录耗时接着用disql执行相同的一组 SQL包括主键点查、批量插入、带条件统计开启计时输出对比。判断执行计划是否一致也很重要用EXPLAIN看两张表的计划有没有分叉如果加密表在某个查询上出现了全表扫描而明文表走了索引那性能差距的根源就不在加解密本身而在计划退化这类问题要靠调整 SQL 或者调整表设计解决。我的实测经验大致是主键点查场景加密表的耗时增加通常在个位数百分比高频访问下基本感知不到批量写入场景增加幅度会更明显一些具体多少要看算法有没有加速支持而一旦加密列参与了排序或范围过滤耗时可能是数量级的差别这种情况必须改设计而不是调参数。4.3 硬件与算法选择上的取舍如果项目在硬件选型阶段我的建议很直接优先选支持密码算法硬件加速的处理器平台这对加密场景的收益立竿见影。如果硬件已经定了、没法换那就从粒度和列设计上省——只加密真正必要的列把排序和范围查询的负担转移到辅助列上。还有一个容易被忽略的优化点加密列不要放超大字段。比如备注类的长文本如果整列加密每次读写都要处理这个字段开销不小而实际业务中这类字段的敏感性往往不高。判断一列要不要加密我一般问三个问题这列是不是个人信息或商业机密审计条款有没有点名业务查询里它是不是高频的过滤或排序条件只有前两个是肯定答案、第三个是否定答案时才放进加密列。5. 主备、备份、迁移透明加密真正的坑都在这里配置和使用阶段的问题都还算可控真要出事故多半出在备份、恢复、迁移这些环节。因为加密把数据和密钥拆成了两个必须同时存在的东西任何一个环节漏掉密钥备份就会变成一堆无法解读的字节。这一节专门讲这些场景。5.1 主备环境备库必须拿到同一套密钥载体主备搭建的标准流程是全量备份主库、还原到备库然后配置日志同步。这里的问题在于你做全量备份的时候备份集里是否包含了密钥载体物理备份工具备份的是数据文件、控制文件这类核心文件密钥载体如果是以独立文件的形式存在于实例目录很容易被排除在备份范围之外。我的做法是不依赖工具的选择性备份而是把整个实例目录结构作为一次完整归档——数据文件、配置文件、密钥载体一起打包。搭备库时先还原这份完整归档再用增量方式追日志。这样虽然包大一些但不会缺东西。如果备库已经搭好了、才想起来加密的事检查方法很简单看备库能不能正常启动并读取加密表的数据。如果读不了先别急着排查存储先确认密钥载体是不是没同步过来。这个顺序我调过很多次能省下大量时间。5.2 备份与导出物理备份不等于备份了密钥物理备份和逻辑导出是两个完全不同量级的安全边界这一点必须讲清楚。物理备份比如通过 DMRMAN出来的备份集里面的数据文件仍然是加密状态所以备份集本身也是安全的泄露出去也无法直接读取。但前提是恢复的时候能拿到密钥所以密钥载体必须跟备份集一起归档并且分开存放。逻辑导出比如 dexp就完全是另一回事了。导出的 dmp 文件里是逻辑数据敏感字段在导出过程中已经被解密成明文落盘就是明文。也就是说一个加密库通过逻辑导出之后安全等级瞬间掉回原始状态。我在评审的时候见过好几次这种情况数据库这边加密做得很好结果运维为了迁数据随手导了一份 dmp 放在共享目录里等于把整套加密方案绕过去了。所以我的规范是加密库的逻辑导出文件属于高敏文件落地必须加密传输必须走受控通道用完立即清理。如果是跨环境传数据宁可重新做一次表空间级搬迁也不留明文 dmp。5.3 迁移与升级目标库的状态先对齐跨库迁移的时候很多人只关注数据能不能过去忽略了目标库的加密状态。如果源库是加密的、目标库是明文的数据迁过去之后就变成明文落地了合规上等于没做。所以迁移前的第一件事是确认目标库的表空间加密状态把加密表空间先建好再迁数据。版本升级的场景稍微特殊。升级过程中配置文件和数据文件都会被处理密钥载体通常是原样保留的但升级工具不会替你校验密钥的可用性。我的做法是升级前先做一次完整的加密读写验证记录下来升级后立刻重复同样的验证如果结果不一致先回滚再说。另外升级前那份完整归档含密钥一定要留着它是唯一的退路。应用侧的迁移成本其实很低JDBC、ODBC 连接串不用改SQL 不用改因为加密对上层透明。唯一的例外是那些应用自己还做了一层加解密的系统两层加密叠加在一起排查问题时会非常麻烦遇到这种情况建议评估一下是不是可以把应用层的加解密摘掉交给数据库统一承担。6. 客户端工具与日常巡检连上去看到什么平时盯什么最后聊两个日常场景一个是客户端工具的观察结果一个是巡检清单。这两块虽然不涉及加密配置本身但都是运维中真实会遇到的问题。6.1 用客户端工具连上去看到的依然是明文不管你用的是哪款数据库客户端工具连到加密库上和连到普通库上的体验几乎是一样的——表结构正常显示数据正常展示敏感字段显示的是明文。这正是透明加密的设计目标。不要因为客户端里看到的是明文就怀疑加密没生效验证还是要回到落盘抽查和字典视图上。不过有两件事值得注意。第一客户端工具的导出功能会输出明文数据这个操作权限要管起来最好在工具层面或者数据库层面做限制不允许普通运维账号随意导出敏感表。第二连接失败的时候不要一上来就往加密上想。客户端连不上绝大多数情况是驱动版本、监听端口、账号权限这几类问题如果确实是加密实例特有的问题通常表现为连上了但读某张表报错这时的排查方向应该是密钥状态而不是网络。另外加了一些中间件或者配置中心之后连接串的维护方式会变但加密对连接串本身没有额外要求这一点不用过度设计。6.2 日常巡检该盯的几项加密库的巡检跟普通库相比多出来的主要就是密钥和备份相关的内容。我把自己的检查清单列一下供参考检查项频率判断标准密钥载体是否在位每次变更后 每月文件或系统表空间的密钥信息可正常读取密钥离线副本是否可用每季度能在测试环境用副本恢复出加密库备份集可还原性每月随机抽一次备份做还原演练并读写加密表加密表空间使用率每周与普通表空间一起纳入容量监控日志中解密相关报错每日出现即当故障处理不能忽略口令交接记录人员变动时双人签字确认密码系统里可查还原演练这一项我特别想强调。很多团队的备份是看起来成功但从来没还原过。加密库的还原演练比普通库更严格因为它要同时验证备份集和密钥两样东西。我一般半年做一次完整演练把生产库的一份备份还原到隔离环境验证解密读写正常然后销毁。这个过程能暴露出的问题往往比日常巡检一年发现的都多。7. 几个我踩过、也想提醒你的细节写到这里把一些零散但很实用的经验集中说一下。关于strings抽查这个方法很有效但要在停库之后做运行中的库数据还在内存里刷写抽查结果可能不稳定。而且抽查用的特征字符串要足够独特别用测试这种在任何文件里都可能出现的词。关于加密列的长度膨胀我建议在建表规范里直接写死加密的字符串列长度按明文上限的两倍定义把它变成团队约定这样即使后来换人维护也不会踩坑。关于密钥口令的保管最忌讳的做法是写在一个共享文档里然后全员可见。我的做法是口令本身进密码管理系统只有极少数人有权取用应急封存的那份放在物理保险柜取用需要两个人同时在场。关于加密和脱敏的配合这两件事经常被混为一谈。加密解决的是磁盘上是密文脱敏解决的是展示时不该看到全部。一个成熟的方案通常是两者配合存储层用透明加密保证落盘安全应用层或者视图层用脱敏规则保证非授权人员看到的是掩码数据。只做其中一个都不算完整。关于选型阶段的沟通如果你正在评估要不要上透明加密我建议把问题拆成三句话问清楚哪些数据必须加密、加密到什么粒度、密钥由谁负责保管。这三句话答不上来方案先别急着落地。