过去两年我参与过两次企业文档防泄漏（DLP, Data Loss Prevention）项目的落地，一次是制造企业的图纸保护，一次是研发团队的代码与文档管控。两次都踩了同一个坑：第一版方案把重心放在"怎么把文件锁住"上，结果上线第一周就被业务部门投诉到停摆。

复盘下来，问题不在加密技术本身，而在策略设计。加密是一个"点"的能力，而泄密是一条"流"的问题。文件要经历产生、流入、流转、流出四个截面，只在某一个截面上使劲，要么防不住，要么把业务卡死。

后来我们换了思路，按文件生命周期重新分层，每一层只解决一个截面的问题，层与层之间留有缓冲。这套分层最终在迪康端点安全一体化管理系统（XTCM，下文简称 XTCM）上落地。本文记录的是这套分层怎么设计、每层怎么配、以及上线顺序上的经验——设计逻辑本身与具体产品无关，换一套终端安全产品同样能套用，只是下文示例会直接以 XTCM 的配置项来写。

一、先想清楚：防泄密到底防的是哪几种「流」

在动手配策略之前，先把风险面摊开。把文件在终端上的生命周期拆开看，泄密风险集中在四个截面：

对应的设计原则只有一条：让加密动作发生在文件产生的那一刻，而不是文件要出去的那一刻。 前者依赖机制，后者依赖人的判断——而人的判断在赶工期的时候最不可靠。

二、五层防护的整体设计

基于上面的拆解，我们把能力分成五层。注意这个顺序不是随意排的，是从"内"到"外"、从"机制"到"人"：

一个常见的误区是把 L1 当成全部，认为"上了透明加密（Transparent Encryption）就安全了"。实际上加密只解决了"文件出了企业打不开"，解决不了"有权限的人主动把明文发出去"——后者恰恰是泄密事件里占比最高的那一类。

三、逐层落地：怎么配，以及为什么这么配

L1 加密内核：把加密动作下沉到驱动层

透明加密的实现思路是进程授信（Process Whitelisting）+ 文件过滤驱动（File System Filter Driver）：授信进程（比如 AutoCAD、SolidWorks、Office、IDE）读写文件时，在内存中解密，落盘时加密；非授信进程读到的始终是密文。整个过程对使用者近乎无感，这是它能被业务接受的前提。

有三个配置点值得单独说：

第一，加密应用库决定加密范围。 它维护的是"哪些程序、哪些进程、哪些文档类型要纳入加密"。这里最容易犯的错是一把梭——把所有程序、所有类型全勾上。结果是编译产物、日志、临时文件全被加密，构建流水线直接崩。正确做法是先只配核心业务程序（CAD、Office、IDE）和核心文档类型（dwg、docx、xlsx、pptx、pdf、代码源文件），跑稳了再扩。

第二，三种加密模式要按部门区分，不能一刀切。 系统一般提供透明加密、只解密不加密、只读三种模式：

# 策略集配置示例（按部门下发）
policy_sets:
  - name: 研发部门
    mode: transparent_encrypt      # 透明加密：编辑保存自动加密
    apps: [VisualStudio, VSCode, IDEA, AutoCAD, SolidWorks]
    types: [dwg, dxf, sldprt, cs, cpp, java, py, docx, xlsx, pdf]

  - name: 财务_人事
    mode: decrypt_only             # 只解密不加密：接收外部文件时能看，
                                   # 但不主动加密，避免对外报送文件变成密文
    apps: [Excel, WPS, Chrome]
    types: [xlsx, docx, pdf]

  - name: 外部协作_只读
    mode: disabled
    comment: 对接外部供应商的专用终端，不纳入加密体系

财务和人事这类部门，日常工作有大量对外报送（报表、证明材料），如果给他们开透明加密，往外发的文件对方打不开，会反向制造一堆解密申请。给他们配只解密不加密，既能打开内部流转过来的加密文件，又不会把要发往外部的文件变成密文。

第三，加密参数别忽略。 哈希算法用于校验加密文件完整性，分组算法决定加密强度，还有密钥管理方式是手动还是自动。默认配置对大多数场景够用，但如果是等保或涉密场景，这几项需要单独对齐要求。

L2 边界纳管：让外部流入的文件也被纳管

L1 有个天然盲区：它管的是"本机产生的文件"，管不了"从外面进来的文件"。而实际工作里，供应商发来的图纸、客户发来的需求文档，量并不小。这些文件如果一直保持明文，就成了体系内的"飞地"。

这一层用两个能力补齐：

落地加密 —— 落入指定路径的文件自动加密或自动解密。典型配置是把浏览器的默认下载目录、IM 的文件接收目录纳进去。配置时一定要按文件类型和文件大小做范围限制：不要把整个下载目录的所有文件都加密，否则下载的 zip 安装包被加密后解压异常，会引发大量误报障。

加密网关（Encryption Gateway） —— 配置 HTTP/HTTPS 下载加解密，支持用通配符号匹配 URL。比如把公司网盘的域名配进去，从网盘下载的文件自动带上加密标识：

# 加密网关 URL 规则示例
https://pan.corp-internal.com/*
https://doc.corp-internal.com/download/*
!https://pan.corp-internal.com/public/*     # 排除公开目录

落地加密和加密网关的区别在于：前者看"落到哪个目录"，后者看"从哪个 URL 来"。两个一起配，基本能覆盖外部文件流入的主要路径。

L3 分域隔离：横向与纵向的双隔离

这一层是很多团队会漏掉的。加密解决了"内外"问题，但企业内部同样有隔离需求——A 项目组不该看到 B 项目组的图纸，科室不该看到总师办的密件。

安全区域（Security Zone）解决横向隔离：按项目、部门或业务线划分区域，跨区域的文件互不互通。研发 A 项目组加密的文件，拷到 B 项目组的机器上打不开，即使两台机器都装了客户端、都在加密体系内。

密级管理（Document Classification）解决纵向隔离：给加密文件设置保密级别，高级别终端可以解密低级别终端加密的文件，反向不行。这符合组织层级里"上级看下级，下级看不到上级"的直觉。

配这两个能力之前，需要先想清楚组织的隔离维度。横向按项目还是按部门？纵向分几级？这两个问题没想清楚就配，后期调整成本很高——因为已经加密的文件带着区域和密级标识，改策略意味着存量文件要重新处理。

L4 出口管控：审批、阻断、扫描三件套

到这里，文件"被动泄露"的路径基本堵住了。剩下的是"主动带走"，这必须靠流程和审计。

解密审批 —— 手动解密必须经过审批。这个能力本身不复杂，关键在审批通道是否通畅。系统支持对接企业微信、钉钉、飞书和第三方审批通知，也有自动审批、超期自动拒绝、批量审批这些辅助开关。我的建议是审批通道一定要接 IM，如果审批只能在管理端网页上处理，管理员一忙就积压，业务就会绕开流程直接找人要明文，流程形同虚设。

外发阻断 —— 加密文件通过聊天软件外发时阻断并记日志。对应的日志里有外发阻断日志和文档流转日志，后者可以针对指定文档追溯完整生命周期，做事件复盘时很有用。

敏感文件扫描与审查 —— 按设定的敏感词扫描终端存量文件。这是上线初期必须做的一步：在开启加密之前，先扫一遍全网，看看历史上已经有多少明文敏感文件散落在各个终端上。不清理存量就直接上加密，等于只锁新门不关旧窗。审查任务支持基于已有结果添加新任务，可以做成周期性的常态检查。

上线顺序上有个经验：先只审计、不阻断，跑一到两周看误报率，再切阻断模式。 直接上阻断，一旦规则配宽了，会瞬间打断正常业务，信任感一旦丢掉很难重建。

L5 兜底恢复：防勒索与备份

前四层都在做"防"，这一层做的是"万一防不住怎么办"。

防勒索规则的思路值得单独说一句：它不是靠病毒特征库识别勒索软件，而是零信任式的访问控制——配置敏感文档类型，再添加允许访问这些文档的应用程序白名单，未授信程序一律禁止访问。勒索软件不管怎么变形，它总归是一个"未授信的程序"，动不了被保护的文档。这个思路比特征匹配更抗变种。

文档备份解决误删和被篡改：终端用户修改或删除文档时自动备份到本地，支持手动备份、按文件大小备份、上报备份日志，还可以设置备份到服务器后删除本地副本，并配置保留份数。存量文件可以用全盘备份处理，支持指定文件类型。

全盘加解密用于存量文件的批量处理。有两个配置细节：一是可以按文件类型和文件路径限定范围，二是任务一定要配置执行时间段，选工作时间之外或空闲时段跑。几百 GB 的图纸目录在工作时间全盘扫一遍，终端会明显卡顿，这个投诉我们挨过。

四、上线顺序与踩过的坑

把上面五层串起来，我们最终采用的灰度节奏是这样的：

几个具体的坑：

例外清单要提前对齐，别等报障。 加密应用库和白名单要在灰度前就和产品、研发、IT 三方确认。事后补白名单的每一单都要走变更，成本远高于事前梳理。
审批流不接 IM 等于没接。 上面提过，这里再强调一次，这是流程能否活下来的关键。
存量文件单独排期。 别指望一次全盘任务搞定，分批、限时、限类型，跑完一批验证一批。
关注大文件的保存延迟。 加密是驱动层行为，几百 MB 的 CAD 图纸保存时的耗时变化要实测。必要时可以配置快速落盘程序或调整授信策略，不要只看平均性能。
多端能力要分别确认。 XTCM 这套体系在 Windows、macOS、信创、Linux、安卓多个平台都有客户端，但能力是逐步对齐的，Windows 端最完整。做方案时按端分别核对能力边界，不要按 Windows 的能力去对其他端做承诺。安卓端相对特殊，它是"加密阅读器"的定位——通过授权让指定设备获得打开加密文件的权限，同时可以管控截屏、分享、USB 传输等行为，不能当成 Windows 客户端那样去规划功能。
策略集（Policy Set）和角色（Role）管理要早用。 系统支持按系统位数、CPU 架构、操作系统、IP 地址、计算机名等条件划分角色，再把策略打包成策略集下发给角色。一开始就按部门/角色建好策略集，比后期在一堆终端上逐台改策略轻松得多。

五、怎么验证策略真的生效了

策略配完不等于生效。我们整理了一份上线后的验收清单，每条都要实测：

验证项操作预期结果加密生效新建文档保存后，拷到未安装客户端的机器打开乱码或无法识别授信进程正常在授信程序内打开同一文件正常读写落地加密从网盘/指定 URL 下载文件到配置目录文件自动带加密标识跨区域隔离把 A 区域文件拷到 B 区域的终端无法打开密级兼容高级别终端打开低级别文件 / 反向前者正常，后者失败外发阻断通过 IM 外发加密文件被阻断，外发阻断日志有记录防勒索用未授信程序尝试访问敏感文档被拒绝，防勒索日志有记录备份可用修改或删除文档备份目录生成副本

批量验证跑一遍会更省事。

六、几个取舍

安全与体验不是零和，但确实要排优先级。 完全无感的加密方案不存在，驱动层拦截必然带来一定的性能开销和兼容性风险。我们的做法是：核心资产（图纸、源码、合同）严格管控，一般办公文档宽松处理，用策略集区分对待，而不是全网上同一套最严策略。

加密不是终点，可视化才是持续运营的抓手。 系统提供的泄密风险分析、外流统计、解密统计、文档流转日志这些能力，上线初期看着像"报表"，但真正让安全策略持续迭代的正是这些数据——哪类外流途径占比最高、哪个部门解密申请最多、哪些文件反复流转，这些信号会告诉你下一轮策略该往哪儿调。

别指望一套策略打天下。 组织结构会变、业务系统会变、终端类型会变。用策略集 + 角色管理把策略做成可复用、可按条件自动匹配的单元，比手工维护一堆终端策略要可持续得多。

最后

回顾这两次落地，最大的收获不是学会了怎么配加密策略，而是想明白了一件事：文档防泄密是运营问题，不是部署问题。 装上客户端、配好加密策略，只是这套体系的起点；真正决定成败的是灰度节奏是否合理、例外清单是否提前对齐、审批流程是否通畅、以及有没有人持续去看那些审计数据。

五层防护的意义在于，它让"防泄密"从一个开关变成了一套可分层、可灰度、可回退的工程动作。任何一层出问题，都可以单独调整而不至于全线回滚——这一点在第一次上线时救过我们。

本文的方案以迪康端点安全一体化管理系统（XTCM）为落地平台，文中示例均来自其真实配置项；多平台客户端（Windows / macOS / 信创 / Linux / 安卓）、策略集与角色下发、开放平台 API 等也都是该系统的既有能力。但分层思路本身与产品无关，换一套终端安全产品，从 L1 到 L5 的配置逻辑同样成立。如果你也在做类似的落地，欢迎在评论区交流灰度顺序和审批流的坑。