在企业数据防泄漏（DLP）的技术栈中，“加密”一词容易被简化成一件事：选一个算法，把文件变成密文。但真正部署过终端加密方案的人会意识到，难点几乎从来不在算法本身——AES-256 和 SM4 都是公开的、经过充分分析的标准化算法。真正的工程复杂度在于：加密和解密应该在什么条件下发生，以及如何让这个过程不打断业务的正常运转。
迪康的加密体系提供了一个值得拆解的技术样本。它的核心不是某个自研密码学原语，而是一套以操作系统内核为支点的系统级机制设计。
一、透明加密的本质：算法之上的一层“环境判定”
官方技术文档对透明加密的定义值得注意：其“本质并非某种特定算法（如AES或SM4），而是‘文件+身份+终端+进程’联合判定的系统级保护机制”。这个定位是准确的，也解释了为什么单纯比较“用了什么算法”不足以理解这类方案的行为特征。
在算法层面，采用的是标准算法组合：AES-256 和 SM4 用于文件正文的对称加密，SM2 和 SM3 用于密钥管理和完整性校验。对称加密负责吞吐，非对称与哈希负责身份与密钥的交换和校验。这套组合本身没有秘密可言，真正的设计空间在于：什么时候用哪把密钥，以及由谁触发加解密。
二、驱动层拦截：透明性的技术来源
透明加密部署在操作系统内核的文件系统过滤驱动层，具体来说是 Windows 的 Minifilter 架构。过滤驱动插入文件系统驱动栈中，拦截文件 I/O 请求包（IRP），在数据写入磁盘之前触发加密引擎，在数据从磁盘读入内存之前触发解密引擎。
从应用程序的视角看，它调用的仍然是标准的 CreateFile / ReadFile / WriteFile，拿到的始终是明文。加密和解密完全发生在 I/O 路径的下层，应用层没有任何感知。这就是“透明”一词的工程含义。
一个容易混淆的点是：透明加密并不等同于“全盘加密”。过滤驱动在拦截到 I/O 请求后，需要先判断这个请求是否“命中策略”。判断依据包括文件类型、产生文件的进程、用户身份、目标路径等条件。换句话说，驱动层不是对所有文件一视同仁地加密，而是执行一个预先下发的、细粒度的策略决策。
配套的进程白名单机制进一步收窄了加密范围：只有受信进程（通过文件哈希、签名、路径等多因子指纹识别）产生的文件才会进入加密流程，系统缓存、临时目录等路径可以被显式豁免。这个设计的直接目的是避免误加密导致系统或应用异常，但它也意味着：透明加密的覆盖范围本质上是策略配置的产物，而不是一个自动的、全量的属性。
三、文件级密钥与密文形态
在密钥组织上，采用文件级数据加密密钥（DEK）的模型：每个受保护文件生成独立的 DEK，由上层密钥体系（可能涉及 SM2 或 PKI 体系）进行封装和管理。文件级密钥的好处是隔离性——单个 DEK 的泄露或轮换不会波及同目录或同用户的其他文件。
密文在磁盘上的形态是“加密头 + 密文正文”。加密头中承载了策略标识和密钥索引信息，使得过滤驱动在读取时能够定位到正确的 DEK 并完成解密。文件脱离授权环境后，由于缺少策略服务器签发的授权票据或无法匹配终端身份，过滤驱动不会执行解密，文件呈现为不可读的密文状态。
四、多模式策略：同一套内核的不同“行为面”
在同一套过滤驱动内核之上，暴露了五种加密模式，管理员可以按部门、岗位或进程下发差异化配置：
| 模式 | 行为特征 | 典型技术用途 |
|---|---|---|
| 透明加密 | 受控进程读写自动加解密，用户无感 | 持续产出涉密文档的研发、设计岗位 |
| 智能加密 | 已加密文件保持密态，外来明文不强制加密 | 高频接收外部资料的岗位 |
| 只解密不加密 | 可读密文，修改后输出明文 | 管理层审阅场景 |
| 只读加密 | 仅允许读取，禁止修改和另存 | 文档借阅、资料分发 |
| 不加密 | 不产生密文，同时无法读取密文 | 普通办公终端的隔离 |
这五种模式共享同一个驱动层拦截框架，差异仅在于策略引擎对“写操作是否触发加密”和“读操作是否触发解密”的判定逻辑不同。从架构角度看，这是一种策略与机制分离的设计：内核机制保持稳定，行为变化通过策略配置来实现。
五、性能与兼容性：驱动层方案的固有张力
驱动层拦截的位置决定了性能开销的量级。官方给出的口径是：明密文变换在内存中完成，对磁盘 I/O 的影响小于 3%。这个数字的合理性需要放在具体负载下理解：对于常规 Office 文档的读写，过滤驱动的判定和内存中的对称加解密确实可以做到接近线性的开销；但在大文件（如数百 MB 的 CAD 装配体或视频素材）连续读写时，过滤驱动的介入和 DEK 查找可能引入可观测的延迟。
更大的工程挑战在兼容性侧。研发场景中，源代码加密后不仅要能编辑，还需要被编译器、链接器、版本管理工具正确处理。驱动层方案必须妥善处理内存映射文件、临时文件、多进程句柄共享等细节，否则会出现“文件能打开但编译报错”一类的问题。这也是为什么这类方案的上线通常需要灰度——先圈定小范围验证工具链兼容性，再逐步扩大覆盖范围。
六、边界与限制
从技术诚实性的角度，加密系统（以及同架构的透明加密方案）的能力边界需要被明确：
它解决的是“文件被私自拷贝带出后不可读”的问题，不解决“数据以其他形态离开”的问题。 截屏、拍照、人工抄写、在授权终端上将内容复制到未加密的新文件中——这些通道不经过文件加密的判定路径，需要配套的剪贴板管控、截屏防护、水印和审计来覆盖。驱动层加密是纵深防御中的一层，而不是全部。
离线场景是一个安全与可用性的权衡点。 笔记本带离内网后，策略服务器不可达，解密授权需要依赖客户端本地缓存的票据。缓存有效期的设定直接决定了设备丢失后的风险敞口：期限越长，移动办公越顺畅，但密文在设备外的可读窗口也越长。
策略配置的复杂度本身构成落地风险。 一体化管控平台的能力覆盖面越广，第一版方案“把所有开关都打开”的诱惑就越大。常见的失败模式是策略过严导致业务部门投诉，最终被迫回退。驱动层加密的工程成熟度，相当一部分体现在策略灰度工具和豁免机制的精细程度上，而非加密引擎本身。
迪康的技术价值，在于它展示了一条与“应用层加密”截然不同的工程路径：把加解密下沉到操作系统 I/O 路径中一个应用无法绕过的位置，用进程授信和路径策略来控制谁能在什么条件下看到明文。这条路径的代价是内核级开发的复杂性和兼容性负担，收益则是安全属性绑定在文件本体上——文件走到哪里，密文状态就跟到哪里。理解这个 trade-off，比记住它支持哪些算法更有助于在具体场景中判断它是否适用。
转载自 CSDN-专业IT技术社区
