存储机密性保护方案对比分析
佰倬文件系统密码模块+密控隔离CERI vs 传统应用层加密机
— 重点聚焦：数据泄密风险的本质差异 —
01
背景与架构概述
本文在「业务上层应用—数据库引擎—存储介质」三层架构下，对两种商用密码保护方案进行系统性比较。两种方案的保护逻辑和作用平面存在根本差异：
两种方案都不是“无感加密”：
1. 方案一：业务上层应用调用硬件加密机时必须完成的SDK配置、密钥导入和接口测试。
2. 方案二：管理员须主动为应用架构中的数据库完成用户身份注册和进程签名绑定，对接密控隔离CERI；每次运行时，系统对访问主体的身份（用户+程序（进程））进行实时验证，Type 1通过验证方能读明文、写密文，Type 2只能看到密文，不能写，Type 3（含root）直接拒绝。方案二是一台随应用分布部署的软加密机，接入过程有感、运行过程有控、安全管控更严。
02
存储机密性核心对比
以下矩阵覆盖主要威胁场景，从存储机密性（防泄密）角度评价两方案的保护效果：
03
泄密风险深度分析
方案一的核心假设是「加密字段=安全」，但该假设在存在大量明文关联数据的环境下根本不成立。
3.1.1 攻击原理
数据库中被加密的仅是「重要字段」（如薪资、身份证号），但同行或关联表中大量非重要字段以明文落盘，且数据库服务器完全无技术保护。攻击者或内鬼一旦获得数据库服务器访问权，即可获取：
与加密字段同行的明文字段（职级、部门、入职年限、绩效等级、地区等）
关联表的明文业务实体（外键关联的人员档案、组织结构等）
数据库索引结构（索引列通常不加密，可泄露值域分布甚至近似值）
访问日志、查询日志中隐含的字段关联模式
这些数据作为特征向量，可对加密字段发起关联推断或语义重建攻击。即使密文本身从未被解密，机密性在信息论意义上已被部分破坏。
3.1.2 现实案例：情报行动中的Metadata关联推演
以下三个近期真实军事行动证明：被「保护」的核心信息，可被周边未受保护的metadata所瓦解。其逻辑与方案一的关联推演漏洞完全同构。
3.1.1 攻击原理
以下三个经典的学术与工业案例进一步证明：即使敏感字段已被「保护」或「匿名化」，只要周边关联数据存在，攻击者便可通过关联推演还原出被保护的信息。
类比至方案一：加密字段相当于「被保护的核心信息」，而大量明文关联数据就是「周边未受保护的metadata」。数据库服务器一旦被访问，关联推演或AI方法的攻击路径与上述情报实践在逻辑上完全同构，且不可控。
3.1.4 为何此风险「不可控」
攻击者不需要破解任何密码算法，仅需数据库服务器的OS层访问权限；
关联推演（含AI方法）随关联数据维度增加，推断精度显著提升，且难以预估风险边界；
方案一无法在不重构整个数据库模型的前提下消除这一风险。
方案二中存在且仅存在一种泄密路径：
值得强调的是：方案一中DBA通过数据库引擎看到加密字段为密文，这不是数据库服务器的主动保护，而是上层应用加密的副产品。DBA仍可绕过引擎，通过OS层直接读取数据文件、redo log，或通过进程内存dump获取明文——方案一对此毫无防护。方案二的「DBA 可见明文」是已授权路径的已知风险，方案一的「DBA可绕过引擎」是无保护路径的未知风险，两者风险性质截然不同。
04
方案二的额外优势
除存储机密性外，方案二在以下维度具有方案一完全无法覆盖的系统性优势：
方案二通过密控隔离，限制只有授权的数据库启动用户+进程才能对数据库文件执行写操作。非授权进程的写请求在内核层被拦截。
典型场景
运维人员误操作或恶意执行rm-rf，内核层阻断；
攻击者取得服务器访问权后尝试篡改数据库文件，被密控策略阻止；
内部人员以非数据库进程身份直接写入，操作被拒绝，并可触发审计告警。
方案一对上述场景完全没有任何防护机制。
勒索软件的核心行为是：以非授权进程身份对存储文件执行大量加密写操作。方案二的密控隔离从内核层拒绝非授权进程对数据库文件的写权限，使勒索软件的加密行为在数据库存储层失效。
典型场景
勒索软件通过漏洞进入数据库服务器，尝试加密/var/lib/mysql目录下的所有文件；
由于勒索软件进程不在密控授权名单中，内核层拦截所有写操作；
数据库文件完好，业务恢复时间（RTO）接近零。
方案一对勒索软件完全没有防护，数据库服务器一旦感染，所有数据文件均可被加密或删除。
方案二在FS层对数据库全量文件加密，覆盖数据文件、redo/undo log、temp文件、索引文件。存储介质即便被物理取走，离线读取到的全部是密文，无法还原任何明文数据。
方案一仅对选定重要字段加密，日志、索引、临时文件均无保护，物理介质被窃取后，攻击者可通过这些旁路获取大量明文。
方案二的加解密在内核文件系统层以生态适应方式执行，不对业务应用和数据库引擎生态产生破坏性的影响，不引入网络调用链路，也不依赖外部加密机的可用性。
方案二在内核文件系统层工作，通过产品侧主动改造，对上层的数据库引擎（MySQL、PostgreSQL、Oracle等）和业务应用完全生态适应。不需要修改任何应用源代码、数据库配置或SQL逻辑。
对比方案一的改造代价
需要在业务应用层嵌入加解密SDK或API调用逻辑；
需要管理密钥生命周期，设计加密字段的存储与查询方案；
无法对索引列加密（否则无法查询），导致覆盖面天然受限；
当数据库引擎升级或迁移时，加密逻辑需要同步适配，维护成本持续存在。
05
综合结论
核心结论
方案一在存储机密性上的唯一实质性优势（加密字段在数据库引擎层显示为密文）是应用层加密的副产品，而非数据库服务器侧的主动保护，且被关联推演（含AI方法）风险根本性削弱。方案一存在不可控的关联推演（含AI方法）风险。方案二以全量FS层+密控隔离（CERI）保护， 在离线攻击场景下基本消除了关联推演所需的数据基础，将泄密风险收敛至「授权DBA可见明文」这一可控的已知边界，同时覆盖防破坏、防勒索、防窃取、高可用、应用侧零代码改造等方案一完全无法触及的维度。
