2021年12月Ping32月度更新汇总

在2021年最后一个月,Ping32再一次完善了OneDLP数据防泄漏与OneUEM统一终端安全管理子系统中的核心功能。在12月份的更新中,我们新增及修复了以下功能:

一、新增点阵水印

在Ping32水印溯源模块,新增水印模板库与点阵水印显示方式,通过水印模板可预先设置水印用途、水印类型、显示内容等。

点阵式水印即在终端电脑屏幕上添加一层圆点图案,采用轻微的标记方式来展现水印,当机密信息被拍摄外传时,管理员在照片上获取点阵水印图案后可追溯泄密终端的相关信息(包括计算机名称、用户名称、IP、日期等)。相比于文字水印,点阵水印既不影响视觉,又能在无形之中实现可追溯。

点阵水印

二、新增软件合规检测策略

为进一步完善企业软件标准化管理,Ping32软件合规检测策略可以指定强制安装某些软件,若检测当前终端无指定软件,则触发指定事件:禁止所有应用访问网络;浏览器访问网页时自动重定向至指定网页。

软件合规检测

三、新增网络存储加密扫描工具

通过Ping32控制台(当前终端需同时安装客户端并具备加密授权)可扫描指定的网络存储位置的文件,如:文件服务器,需指定网络存储路径、文件范围(加密\未加密文件)、文件类型,扫描到的文件会实时展现,扫描结束后,右键选择相应文件可以进行加解密操作。了解更多网络存储加密扫描工具的使用说明。

网络存储扫描

四、新增触发式截屏

在Ping32泄密追踪中,新增发现泄密时自动截屏功能。当用户发送文件时,系统在指定时间内截取当前的屏幕画面,在泄密追踪记录中右击一条文件外发记录可以链接到事件当时的屏幕记录,可将用户外发文件行为与屏幕记录监控相结合,作为事件发生后更有力的溯源凭证。

触发式截屏

五、问题修复

  1. 修复一个密钥不匹配时,静态解密文件可能导致文件变成一个中间状态文件的问题;
  2. 修复一个软件白名单模式时,软件拦截日志不记录的问题;
  3. 修复一个智能加密和新建文件加密同时生效时,部分逻辑存在冲突的问题;
  4. 修复一个文档外发管控使用复合规则时,逻辑不正确的问题;
  5. 修复一个部分条件下,删除终端组件限制策略时,组件状态未恢复的问题;
  6. 修复若干加密核心组件处理网络路径的加密文件工作不正常的问题;

六、功能优化

  1. 控制台策略管理支持以某个策略参数为模板,创建策略副本;
  2. 应用层的解密网关,支持Internet Explorer浏览器;
  3. 硬件资产统计支持统计主机序列号(如果存在) ;
  4. 剪切板审计支持基于数据分类的敏感内容识别;

Ping32网络存储扫描加密工具

在文档加密软件的部署实施过程中,需要解决的一个问题是如何加密已经存在的文件。加密这些文件的一个难题是,这些文件可能散落在企业各处,由于文件所在的位置不同,那么加密文件用到的方法和逻辑也不一样。最常见的是文件位于终端本地磁盘,对于这种场景,可以通过全盘扫描加密策略对其进行加密。那么对于共享服务器上的文件应该如何处理?下面将介绍Ping32网络存储扫描加密工具。

通过网络存储扫描加密工具,你可以扫描指定网络存储位置的文件,对其加密或解密。最为常见的应用场景:如何对为员工提供文件共享服务的文件服务器(NAS)上的文件进行加密。

Ping本地加密文件扫描工具不同的是,扫描任务的执行不是由客户端,而是通过控制台完成的,这样做的好处就是,针对存储于网络路径下的同一个共享文件,不会被不同的客户端扫描并且执行加密/解密策略。

使用方法

下发网络存储扫描任务的控制台必须同时安装客户端并开启加密授权。在控制台上选择文档加密模块,加密工具,点击网络存储扫描工具,用户需指定路径、扫描范围、文件类型配置扫描策略以实现网络存储位置的文件加解密。

网络存储扫描

在扫描结果中,可单个或批量完成文件加密解密操作。

最后,如果你在使用此组件的过程中有其他需求或者建议,请和我们反馈,我们期待和你进行沟通。

2021年11月Ping32月度更新汇总

一、概览

Ping32已于近日发布最新版本3.7.59,本次发版重新设计了新的数据分类规则库以及重构了敏感内容识别引擎,若干底层核心组件的性能优化以及若干问题的修复。

如需获取最新版本,联系我们获取Ping32更多版本信息。

二、新增功能

数据分类规则库:基于规则分析引擎将散落在终端各处以及实时产生的数据进行分类处理,在新版本中将支撑智能加密,泄密追踪,文档外发管控,打印合规,邮件合规等多个功能场景。

敏感内容扫描:基于数据分类,通过Ping32敏感内容识别引擎,可以扫描指定终端上的文档,分析是否包含指定的敏感数据类别,借助智能缓存技术,分析决策流程<20ms。

敏感内容扫描

运维工单:高效的IT系统运维平台,自动流转的工单系统,可以将工单从创建到完结过程中全程监控并完整记录,包括:跟进状态、转派情况、工单办结、工单关闭、工单评价等。

文档加密:

新增支持文件落地加密。支持对指定路径下、指定文件类型的新建文件实时监控落地加密。

支持智能加密模式。智能加密是指,如果文档包含敏感内容,则被加密,否则不加密。

文档安全:

基于数据归类和敏感内容识别服务,重构文档外发管控功能,支持阻断命中指定分类的文档外发行为。

基于数据归类和敏感内容识别服务,支持审计、分析命中指定分类的文档外发行为。

三、功能优化

管控平台:优化电子邮件查看器,提升稳定性;

行为审计:行为审计数据上报时间支持以服务器时间为基准时间进行保存;

系统&网络:优化软件分发的逻辑,支持在低权限帐户的环境下,安装部署软件;

核心组件:优化敏感内容识别的核心组件的健壮性 ;

其他:优化安装部署逻辑,安装时会检测.Net Framework 4.5.2是否安装,如果没有安装,会显示提示用户进行安装。

四、问题修复

文档加密:

  1. 修复一个对某些SMB共享服务器共享的文件进行静态加密、解密失败的问题;
  2. 修复一个某些场景下,全盘加密工作不正常的问题;
  3. 修复一个删除加密授权后,加密部分逻辑依然工作的问题;

上网行为:

  1. 修复一个Windows 10系统上,如果勾选了Beta版的UTF-8全球语言支持特性后,极少数网站无法访问的问题;

系统&网络:

  1. 修复一个开启软件安装管控后,客户端后台自动升级新版本失败的问题;
  2. 其他若干功能优化及问题修复。

Ping32数据防泄漏的数据分类和敏感内容识别引擎

在Ping32的11月份的更新中(3.7.59),我们最重要的一项工作是,在OneDLP数据防泄漏子系统中重新设计了新的数据分类规则库以及重构了敏感内容识别引擎。以及在此基础上,将若干功能与敏感内容识别逻辑进行整合。

数据分类规则库

数据分类是指,将散落在终端各处以及实时产生的数据进行归类,属性涵盖:数据类别、名称、敏感级别等。对于数据防泄漏产品来讲,最核心的一个功能就是对存在数据泄漏风险的行为进行阻断、告警。这里面的一个关键是,如何识别存在数据泄漏风险的行为?我们不妨想象一下职场中常见的一些行为:

1、将一些公司内部文档拷贝到了私人U盘或网盘;

2、在互联网平台上(微博、知乎等)发布了一些不合规的内容、言论;

3、发送出去的电子邮件正文包含了一些敏感的内容;

4、通过微信等即时通讯软件,发送了涉密的内容以及文档;

5、通过打印机,打印了一份涉密文档;

……

对于数据防泄漏产品来说,识别、捕获以上行为所用到的技术手段不尽相同。但是这里面却有一个共同点:即对捕获到的数据进行风险分析,对数据进行分析、归类的方法可以是基于机器学习技术的某些模型进行自动归类,也可以是依靠人工录入的规则引擎进行分类。下面我将介绍,Ping32数据防泄漏3.7.59的数据分类功能。

上面我们谈到了数据分类的基本属性:数据类别、名称、敏感级别、描述等。这些都非常好理解。此外,分类的对象也是一个重要的概念。我们将数据分为了两个类别,一种是散落在终端各处(本地磁盘、网络存储、可移动磁盘等)的非结构化数据,即文件。另一种是存在于内存中,没有落地的数据,我们泛称为数据,比如:微博、知乎待发布的内容、正在编辑待发送的电子邮件、输入打印机任务队列的数据流、剪切板等。因此我们支持对每个数据分类规则设定生效范围,可以应用到文件规则或是数据规则。对于应用到文件类型的规则,我们还可以进一步根据文件的属性进行筛选,比如:文件大小、文件的文件系统属性、所在位置、文件类型等。我们的决策逻辑会优先分析规则的基础属性,当匹配成功后,才会最终去分析里面的数据规则。

数据规则基础属性

最后,我们再聊聊数据分类中的数据条件。最简单的数据条件就是,要检测数据中是否包含指定的关键字。但是,只检查某个关键字往往很难精准地对这份数据进行定义、归类。因此再次基础上,我们扩展了数据条件的定义规则。目前,我们支持两种类型的特征值,关键字和正则表达式,每种特征都支持设置至少达到指定的命中次数才生效。此外,我们也支持若干个特征条件进行组合。

数据条件

敏感内容识别引擎

数据分类规则设计完成后,另一个重点是敏感内容识别引擎的设计。我们接着回到上文提到的几个数据泄密的场景,在这些场景中,如果想要避免数据泄漏,要解决的核心问题是:快速、精准地识别相关文档是否包含敏感内容。精准很好理解,即文档能根据数据分类规则,精准地被分类。这里面我们要谈一下“快速”这个问题。

谈这个话题前,我们先了解一些前置知识,相信大家都不陌生。我们使用Windows时经常会发现一个现象,某个软件“卡住”了,然后窗口内容变成了毛玻璃效果,同时窗口标题出现了未响应字样。站在Windows窗口机制的角度来描述这个现象是,由于窗口的消息循环处理某个事件耗时过长,然后窗口管理器(DWM)会创建一个新的窗口,类名是Ghost,覆盖在原窗口上。聊这个是因为,有时我们对于一些文件的外发行为进行管控和审计,代码是运行在窗口消息循环的上下文,如果这个分析耗时过长,则容易造成窗口卡住的效果,进而带来了糟糕的用户体验。在引入敏感内容识别后,此类问题往往更容易发生。所以,我们过去的一个工作重点是,如何快速进行敏感内容识别。

在这个版本中,我们引入了一项叫“智能缓存”的技术。顾名思义,我们会根据用户的使用习惯,智能地预加载某些文档到内存中,如果一旦需要在窗口消息循环的上下文中对文档进行敏感内容检测,这时并不会从硬盘中读取数据,然后分析(这个过程可能很慢,取决于磁盘类型和文件大小等),而是从预加载的缓存中进行分析。整个流程可以极大地加速文件的分析。

敏感内容扫描策略

最后,基于我们上述技术核心,我们在这个版本中加入了一个敏感内容扫描策略。通过敏感内容扫描策略,你可以扫描指定终端上的文档,分析是否包含指定的敏感数据类别。

Ping32敏感内容识别

Ping32运维工单功能的优化更新

Ping32在为企业提供数据泄漏防护、终端安全管理的同时,为企业IT系统的高效运维提供了一些实用的内网安全、桌面管理工具。在过去的一段时间里,我们收到了若干个对Ping32运维工单功能的建议和反馈。主要有以下几条:
1、处理人收到运维工单后,系统有弹窗提醒;
2、可以将待处理的运维工单固定在桌面右侧,并设置停留时间,点开后可以查看详情;
3、有多个处理人时,处理人只能收到自己所管分组的工单。而且支持流转工单给其他处理人;
4、发起人可以对工单的处理结果进行评价。
……

在2021年11月的Ping32更新中,我们对运维工单功能做了若干改进和优化。下面我将详细介绍:

1. 运维工单支持选择多个处理人,处理人支持管理员和普通终端用户两种角色。
借助Ping32的策略框架,我们支持为设置不同的终端分组,每个分组包括若干个终端。新版的运维工单可以支持为指定的策略组设置多个处理人。比如设置了管理员A、B、C和终端用户d,4个处理人。这样是合理的,因为对于Ping32的某些大型企业客户,只有管理员作为处理人显然是不合理的。但是问题是,存在多个处理人时,运维工单如何分配呢?我们提供了3种分配机制,分别是:由终端用户自己选择、处理人主动认领和随机分配。
终端用户自己选择:终端用户可以看到候选的处理人列表,在提交工单时自己指定处理人。非处理人看不到这个工单。
处理人主动认领:提交后处于待认领的状态,所有处理人都可以看到这个工单。
随机分配:通过公正的随机分配算法,随机分配处理人。

2. 根据策略设置,可以允许处理人流转工单。
当处理人没有时间处理或者无法解决,提交人员一直得不到最终的处理结果,显然会对提交者造成一定的时间损失。我们提供了一种处理方式:允许处理人流转工单,当前处理人可直接流转给提交人所在策略的处理人进行操作。ps.超级管理员可直接进行流转工单

示例场景
策略设置:处理人A、B、C,分配机制为由终端用户自己选择,允许处理人流转工单
最终提交:终端选择处理人A进行提交
处理人A:没有时间处理或无法处理,那么可选择B、C进行流转
以上操作最终处理人为B,若B同时没有时间处理,同理可再次流转

流转工单

3. 流程评价。
3.1 支持终端对工单处理流程评价。
当工单已被处理人处理完成,状态为已解决或者无法解决时,终端可对这一工单通过业务能力及响应速度两个维度进行打分,且可增加文字性评价更为详细说明打分原因。

3.2 支持处理人查看终端评价内容。
允许处理人查看评价需允许终端评价。对于Ping32某些企业客户,部门较多,每个终端分工不同,可根据实际需要开启处理人查看评价内容。ps.超级管理员可查看所有工单的评价内容

工单处理结果

4. 提交工单内容更全面。
4.1 新增提交内容
当处理人查看待处理的工单时,密密麻麻,无法及时处理更为紧急严重的工单,所以我 们新版运维工单提交在旧版的基础上新增提交项:优先级、严重程度、解决期限、处理人选择。终端可根据当前问题紧急程度选择优先级、严重程度及解决期限,以便于处理人紧急处理并解决。

创建工单

4.2 补充说明
当终端认为提交内容信息不足以处理人全面了解问题情况时,在工单处理完成(已解决/无法解决)之前都可进行补充说明,以便于处理者根据提供信息进行快速的处理。

追加描述

Ping32文档加密软件的“过滤目录查询请求”参数

之前文章中,我们详细讲解了文档加密是如何透明加密\解密一个文件。文档透明加密中,对“透明”一此的理解,不止可以从用户无感知的角度理解,还需从授信软件,感知一个文件的属性(大小、只读、压缩、NTFS安全属性等),读写一个文件的内容等角度进行理解。

读写文件进行解密、加密很好理解,因为这是透明加密的核心,即原始数据写入磁盘时,被我们的加密中间层进行加密;从磁盘读取加密的内容时;被我们的逻辑解密。透明加密核心就像是一个虚拟机一样,作用在系统底层,第三方应用是感知不到它的存在。

下面将要讲的是:感知一个文件的属性的透明化处理

一个前置背景知识是,一个文件被加密后,文件在磁盘上的真实大小,要比原本理论大小大。举个例子,一个ANSI编码(每个ASCII字符是一个字节)的txt文件,里面的内容是1234567890十个数字,那么这个txt文件大小就是10字节。但是经过加密后,这个txt在磁盘上的大小要大于10字节(因为包含了加密文件头,以及加密算法的影响)。

程序读取文件内容的简化逻辑一般是:

1.获取文件大小,按照文件大小申请内存缓冲区;
2.读取文件大小的数据;
3.将读到的数据放入缓冲区。

假设,一个未加密的文件大小是10字节,那么程序即可获取到10字节这个值,申请的缓冲区大小也是10字节,然后程序从文件头读取10个字节的内容放到缓冲区里,最终也成功读取到了10个字节(因为大小确实是10字节),一切都很和谐。

但是如果透明加密介入,就会引入一些问题。假设,一个未加密时大小是10字节,但是被加密过的txt文件,加密后大小是100字节。那么记事本获取文件大小时,获取到的这个文件大小该是多少,是10还是100。假设是100(也就是加密文件在磁盘上的真实大小),那么按照读取文件的逻辑进行操作,申请100字节的缓冲区,然后试图读取100个字节,但是很遗憾,由于加密中间层的存在,读到的数据是被透明解密的,透明解密的大小只有10,那么只能读取到10个字节的数据。这时,程序认为文件有100个字节,但是只读取到了10个字节,这时就会认为可能出现了错误,进而出现一些不可预知的错误。

所以,这就是开头提到的,一个授信软件不仅读写文件数据是被透明加解密的,除此之外,感知文件属性也应该是透明的。也就是说,记事本感知加密文件的大小,应该是文件的理论未加密大小,而不是磁盘上的真实大小。

Windows里获取一个文件大小的方法有很多,常规的做法是直接获取文件大小;偏冷门的做法是某些软件使用Windows未公开方法(没有编程接口,但是通过某些特殊手段调用)快速获取一个目录里所有文件的大小。加密核心默认针对直接获取文件大小的行为默认做了透明化处理,但是对于冷门的做法,我们给了一个开关,即加密规则高级设置里的过滤目录查询请求。勾选开启,那么这种冷门方法获取的是透明化处理的大小,即理论未加密大小;未开启,则这种冷门方式获取到的是磁盘上文件的真实大小。

此处可以做一个实验,即explorer.exe,建立一个规则可以透明加解密*.txt,分别启用、关闭过滤目录查询请求得到的结果如下图(这几个文件理论未加密大小只有几十个字节)。

未启用过滤目录查询请求

启用过滤目录查询请求

最后留两个问题:
假设某备份软件备份某个目录里所有文件时,获取文件大小使用的是这种冷门方法。

1.如果我希望,备份软件备份某目录的加密文件到云端是解密(未加密状态)的,该如何设置策略。
2.如果我希望,备份软件备份某目录加密txt到云端是解密的,备份加密jpg则依然是加密状态,我们现有的规则是否支持,为什么?

如果你对其他技术细节也感兴趣,也可以和我们取得联系

文档加密软件核心技术:文件系统微过滤驱动(minifilter)

文档加密软件产品目前使用的技术有两种,一种是应用层的API HOOK,另一种则是文件系统的微过滤驱动技术。Ping32文档加密软件使用的是文件系统的微过滤驱动技术。在聊文件系统的微过滤(minifilter)之前,我们先聊聊通用的过滤驱动概念。

阅读更多

文档外发管控的策略设置重构

在之前的文章中,我介绍了我们11月份的一个主要研发任务即:文档透明加密的新建文件加密。除此之外,11月份我们的另一项重要的工作就是,重构了文档外发管控的策略设置界面。首先我们了解一下什么是文档外发管控。文档外发管控是指,通过策略规则设置,对终端用户通过一些常见的软件(如:QQ、微信、邮件、网盘等)外发文件的行为进行控制。这是提升企业数据安全,文档安全最行之有效的手段之一,是数据防泄漏产品不可缺少的一个核心功能。谈到重构,我们就要谈重构前的不足和重构后的改进。我们先来说重构之前的不足之处。

阅读更多

以进程为控制粒度的文档加密驱动介绍

本文介绍了基于文件系统微过滤(minifilter)框架实现的对文件进行动态透明加解密驱动的开发方案及实现细节,标题中基于授信进程是指对加密文件的原始视图和解密视图的访问限制可以以进程为单位粒度进行限制。

Windows中常见的几种文档加密解决方案

EFS(加密文件系统)和Bitlocker是Windows内置的标准加密解决方案。

Bitlocker提供完整的扇区级分区加密服务。Bitlocker驱动程序(fvevol.sys)位于文件系统堆栈中的ntfs.sys驱动程序下方。它自动加密、解密由NTFS从物理驱动器写入、读取的数据块。因此,物理NTFS驱动器看起来像是解密的,但是如果你试图绕开NTFS读取磁盘原始内容,那么你读取的将是加密过的数据。应该注意的是,使用Bitlocker最安全的方式应该是——借助TPM加密协处理器,这也是Windows 11的硬件要求之一。不过Bitlocker依然可以在没有TPM的计算机上运行,不过这种情况如果想实现重启保护,往往需要借助USB闪存设备来引导系统。要了解的是,Bitlocker可以防范由于计算机设备丢失等场景带来的数据泄漏风险,并无法保证用户数据免受在Windows中运行的恶意程序(比如:勒索病毒)的侵害,也不能防范用户使用计算机时主动将文件通过网盘、QQ、微信、电子邮件、可移动存储等途径主动引发的数据泄漏。

加密文件系统(EFS)是一种标准的NTFS机制,它可以为逻辑驱动器的不同部分进行加密。EFS对应用程序透明地运行。EFS加密基于特定的帐户密码。当在有权限解密的用户会话中运行应用程序访问数据时,数据会被自动地加密和解密。因此EFS和Bitlocker一样,无法保证数据免受恶意程序地侵害,因为在指定用户会话中运行的恶意程序同样也有解密的权限。此外,EFS也无法防范用户主动引发地数据泄漏。

以进程为控制粒度的文档加密解决方案

我们已经阐述过,上述的两个方案都无法防范用户主动引发的数据泄漏。如果想满足这样的需求,须开发自定义的内核驱动程序。以便允许以进程为控制粒度,将进程划分为授信进程和非授信进程。这样将保证,在统一用户会话中读取数据时,一些应用程序读取的是文件的解密视图,而另外的应用程序读取的依然是加密视图。

使用minifilter实现文档加密

minifilter的原理以及和其他驱动的关联

minifilter的原理很简单,它连接到选定的系统分区,包括可移动存储,并过滤、查看、修改对位于这些分区中的文件对象的操作。

因此,无论应用程序执行什么文件操作,minifilter都会捕获到,并修改操作参数。例如,它可以阻止打开文件或启动应用程序;重定向文件操作到另一个文件;加密、解密或只是在读取、写入文件时检查数据。驱动可以保存每个分区的特定信息,然后用于每个操作。例如,此功能可用于为每个分区设置不同的加密参数。驱动程序可以为每个系统分区使用不同逻辑。特定于分区或其他文件系统对象的信息位于成为context的对象中。

minifilter实现的通用加密方案

没有进程的访问限制

要开始加密minifilter的开发,我们需要了解解决方案中采用的通用加密方案的原理。为了加密用户数据,minifilter必须分别注册几个回调处理器:IRP_MJ_READ 和 IRP_MJ_WRITE。

文件系统中的几种读写操作类型:
1、从文件缓存中读取:文件系统驱动从缓存中读取数据。如果缓存中没有数据,缓存管理器将文件中的数据读取到缓存中,然后将读取的数据返回到文件系统。
2、分页I/O读取:文件系统驱动直接从驱动器中读取数据。如果这个操作是由缓存管理器发起的,那么数据被移动到缓存中,如果是由应用程序发起的,那么数据不会被移动到文件缓存中。
3、Fast IO读取:直接从缓存中读取数据,不创建IRP。
4、缓存写入文件:数据写入缓存,缓存管理器不保证数据会理解写入驱动器上的文件。
5、分页I/O写入:数据直接写入驱动器上的文件。如果这个操作是由缓存管理器发起的,那么会导致刷新,如果是由应用程序发起的,那么数据将写入文件而不是移动到缓存中。
6、Fasr IO写入:数据直接写入缓存,绕过文件系统。

缓存管理器通常使用分页I/O读写操作将数据读入缓存或从缓存刷新到文件。这样,分页IO读取后,数据被移动到缓存中,分页IO写入后,数据直接写入驱动器上的文件。例如,如果缓存中有加密数据,并且应用程序进行了文件映射,则应用程序将直接引用缓存区域,该区域是来自文件的数据所在的区域。因此,minifilter不会接收和解密读取操作。为了处理这种情况,32位系统上,我们挂钩了Nt函数,64位系统上,这个行为是被禁止的。连接到分区并注册处理回调后,minifilter会看到上述所有的操作类型(Fast IO除外)。但是对于每个从缓存管理器写入的分页IO的数据加密和从缓存管理器读取的每个分页IO的解密就足以实现通用的透明文件加密,而没有每个进程的访问限制。因此,所有应用程序和缓存中总会有解密的数据,并且驱动器上的文件中总会有加密的数据,

进程存在不同访问限制的复杂性

不同的进程存在不同的访问限制,使动态文件加密驱动的开发变得更加复杂。在 minifilter 中处理操作时,会确定该进程是被允许还是被阻止。为了做到这一点,可以使用与每个 FileObject 相关的上下文。此上下文是在打开/创建文件操作的处理程序中创建的。此时打开目标文件的过程已经清楚了。有关进程的信息可以存储在此上下文中。在 FileObject 关闭操作期间可以删除上下文。此外,使用 Per-file 上下文也很重要。 顾名思义,此上下文直接链接到驱动器上的文件,而不管打开的 FileObject 的数量如何。对于为特定文件打开的所有文件对象,此上下文是唯一的,并且可以通过任何文件对象接收。当最后一个 FileObject 关闭时,系统将删除此上下文。注意:每个文件的上下文与文件系统加密驱动程序中的 FCB 结构相关,并且由于该结构存在直到任何打开的 FileObject 存在,因此上下文也是如此。诸如文件是否被加密、其解密大小、文件修改标志以及用于加密实现的其他数据等信息将存储在该上下文中。

此框架的问题

使用minifilter方法开发文件加密驱动程序有一个很大的缺点,即没有经验的开发人员可能没有意识到这一点。在使用文件映射时,禁止解密文件的进程仍然可以访问该文件的解密数据。发生这种情况是因为在文件映射的情况下,应用程序可以直接访问文件视图所在的缓存部分。因此,minifilter无法检测文件映射操作。在不改变加密方案架构的情况下,这个问题可以通过使用文件映射函数钩子来解决。在 x64 操作系统中,它只能是用户模式挂钩。这种方式涉及流程,非原生,会导致大量潜在的应用问题,很难预见。由于目前可用的钩子引擎的不完善以及需要考虑钩子实现的大量细微差别,这变得越来越复杂。操作系统最原生的解决方案(就设计而言)使用自定义微过滤器驱动程序和自定义文件系统驱动程序。

Ping32将在3.7.59中支持文件落地加密

文件落地是一个很场景化的描述,比如:微信收到了对方发来的一个Word文件;将U盘中的CAD图纸拷贝到了桌面……这些行为我们都可以理解为文件落地。如果站在技术角度来看待文件落地行为,我们可以理解为某个应用调用了(Nt)CreateFile创建了一个文件。在11月要发布的版本中,我们会引入对文件落地加密的支持,这个功能我们称之为:新建文件加密

文档透明加密的核心逻辑是将指定进程配置为授信进程,授信进程创建的文件自动加密,打开文件则自动解密;其余非授信进程则不具备打开查看文件解密视图的能力。在此基础上衍生出来半透明加密的概念,即:打开文件自动解密,但是创建文件不加密。这里面的一个重要的概念是授信进程。文件落地加密功能与文档透明加密核心的不同之处在于,文件落地加密没有授信进程的概念,这个很好理解,因为我们无法控制,到底是哪个软件进程实现了落地,比如:浏览器、网盘、QQ、微信、迅雷等软件都可以下载一个文件,这个过程就是文件落地,但是我们无法把这些软件设置为授信软件。

因此,在策略的交互设置中,我们仅仅设置了:加密的路径、加密的文件类型、忽略的路径、忽略的文件类型。通过这些组合,我们实现了全盘或者局部的指定文件类型的落地自动加密。

全盘加密

文件落地加密在使用场景上是简单易理解的,但是在技术细节上,会有若干问题,下面我将对其进行阐述说明。

1、优先执行授信软件的规则行为,并且规则匹配成功后不再匹配执行新建文件加密规则。
举个例子,我们设置了如下语义的新建文件加密规则:
对在 D:\Test1 目录下新建 *.txt 文件进行加密;
对在 D:\Test2 目录下新建 *.log 文件进行忽略;
同时,我们的透明加解密核心设置了针对记事本(notepad.exe)操作 *.txt 和 *.log 文件类型透明加解密的规则。那么会有以下几个问题:

1、记事本在 D:\Test1 中创建了一个 *.txt 文件,文件是否会被加密。
答:会被加密。加密是因为匹配到了授信软件的规则。

2、记事本在 D:\Test1 中创建了一个 *.log 文件,文件是否会被加密。
答:会被加密。加密是因为匹配到了授信软件的规则。

3、记事本在 D:\Test2 中创建了一个 *.log 文件,文件是否会被加密。
答:会被加密。因为系统会优先执行授信软件的规则行为,哪怕新建文件加密规则设置了:在 D:\Test2 目录下新建 *.log 文件进行忽略。

4、非授信软件在 D:\Test1 中创建了一个 *.txt 文件,文件是否会被加密。
答:会被加密。因为触发了新建文件加密规则。

 

2、Ping32仅支持针对新建文件对象的连续写入进行加密。
举个例子,我们需要将 123456 这几个字符写入到一个txt文档中。
一般来说,软件的API执行流程是CreateFile -> WriteFile(“123456”) -> CloseFile,针对这种API调用顺序,Ping32可以正常加密。但是如果软件的API调用风格是这样的:CreateFile -> WriteFile(“123”) -> CloseFile -> OpenFile -> WriteFile(“456”) -> CloseFile。那么这个场景使用新建文件加密是不安全的。事实上,这种场景是理论不严谨、存在安全缺陷的,即使我们引入某些算法进行优化,也很难保证都能得到妥善处理。

 

3、Ping32不支持网络路径的新建文件加密。
无论是通过映射网络驱动器的方式,还是直接通过网络共享路径直接访问,即使规则对路径匹配成功,Ping32都不会对网络路径下的新建文件进行加密。这个行为是符合设计意图的,并非缺陷。

 

4、请勿设置 ‘针对全盘范围对常见的文件类型进行落地加密’ 这种过于宽松的规则。
比如:全盘范围,新建 *.png 类型文件进行加密。很多软件后台默认行为可能会随时产生*.txt、*.jpg、*.png等常见文件类型的临时文件,这个过程用户如果不借助专业的工具是无法察觉的,如果借助ProcMon则一目了然。如果对这些后台行为产生的文件落地加密,则可能导致软件工作不正常的问题。所以请勿设置过于宽泛的规则。如果由于宽泛的规则导致某个软件使用的文件被加密了,可以使用本地加密文件扫描工具扫描并解密。

 

5、某些软件下载接收文件时,在完成前,文件后缀可能并非是实际后缀。
相信很多人都注意到这个现象,比如某个软件下载一个 *.mp4 文件,在下载过程中即创建一个新的文件用来接收数据流,但是这个新的文件类型可能并非 *.mp4,有可能是 *.mp4.xltmp,针对这种场景,需要设置正确的文件类型。