基于过滤驱动的SAP系统文件输出安全策略研究

◆杨家成

(广东南华工商职业学院信息工程与商务管理学院 广东 510507)

随着个人及企业对于信息保护的安全意识不断提高，文件安全性问题已经成为国内外研究机构关注的热点领域[1]。使用SAP系统的企业经常会生成用户需要的数据、报表并将数据导出到指定路径的文件中。这样的数据往往涉及企业的商业机密，不可随意复制流通，于是产生了这样的问题，导出数据如何进行保护[2]。SAP系统在这方面并没有相应的涉及，其在安全性方面利用用户角色、权限分配等对系统数据进行保护，而导出功能却不在此安全性控制范围之内。现有的文件加密软件不能实现与 SAP系统的无缝对接以及相应的透明加解密[3]。许多客户在使用的过程中通过安装文件加密软件进行导出数据的保护，但是这些软件普遍存在的问题就是必须通过用户手动选择相应加密的文件或者文件夹才能进行相应的加密，这不仅会因为用户遗忘加密而造成文件的不安全，更会严重地改变用户的使用习惯[4]。由于SAP系统在全球范围内的广泛使用，这样的需求会更加强烈。综合上述，基于SAP系统导出文件的安全性研究对于保护SAP系统导出数据安全以及保证用户正常使用有着广泛而重要的意义。

信息安全和文件保护方面，许多著名的信息安全企业和组织还是推出了自己的文件加密产品，虽然不能直接满足上面提到的需求，但是却可以作为研究的参考资料[5]。使用较为广泛的有赛门铁克推出的企业版端点软件SEP，趋势科技推出的云安全软件Pc-cillin，以及诺顿安全软件 NORTON中的文件加密工具软件DISKREET[6]。使用最为广泛而且典型的就是微软推出的加密文件系统EFS和Office洗了办公软件中的加密功能。主流加密软件均存在各种各样的缺陷，而这样的缺陷均不能实现基于SAP系统导出文件的安全性研究，并且同时满足不改变用户的使用方式即透明加密以及较细的加密粒度。

1 问题描述

SAP系统是一种企业管理解决方案实施软件，在各行各业中得到广泛应用，其在每个行业中都有规范式的解决方案实施标准，充分考虑各行业中的特殊业务与处理需求以统一的形式进行规划。在SAP系统中包含有多个模块，主要有FI、TR、CO、PP、MM、HR、SD等[7]，模块的划分是依据业务逻辑进行的，故SAP系统中每个模块的工作流程均不相同。若脱离具体的业务逻辑，单纯从数据流动情况考虑，SAP系统流程图参见图1所示。

用户凭借用户名、口令以及登录端口凭证登录到 SAP系统中，进入SAP系统初始界面。在此用户根据自身需求键入tcode，跳转至相应的界面并进行操作。在进行操作的过程中首先会产生操作请求，系统接收到请求后验证用户权限，如果用户有此操作权限即可进行操作，否则操作被拒绝。用户权限实现了对系统中数据的基本保护，使得没有权限的用户无法进行非授权操作，具体关系如图2所示。

图1 SAP系统流程图

数据经数据处理模块处理后，根据用户需要实现显示数据或保存数据到数据库，此时该操作执行完成；如果用户有其他操作需要进行，产生相应的操作请求即可。SAP系统中操作请求主要有查询、修改、新建、删除等。在实际使用过程中，不会单独使用某一种操作，如新建操作在处理时首先会进行查询，查询将创建的记录在数据库中是否存在。因为SAP系统的业务逻辑复杂程度高，数据在数据处理部分会经过复杂的业务逻辑计算后，再进行其他操作。

图2 权限、用户、角色关系图

2 SAP导出文件保护设计

2.1 捕获文件操作并处理

IRP（I/O request package）是操作系统内核的一个数据结构。应用程序与驱动程序进行通信需要通过IRP包[8]。当上层应用程序需要与驱动通信的时候，通过调用一定的API函数，IO管理器针对不同的API产生不同的IRP，IRP被传递到驱动内部不同的分发函数进行处理。对于不会处理的IRP包需要提供一个默认的分发函数来处理。MJ表示主要的即主要的派遣函数，主功能码用来标识不同的操作请求，在本系统中需要进行处理的IRP请求包有：IRP_MJ_CREATE、IRP_MJ_READ、IRP_MJ_WRITE、IRP_MJ_CLOSE、IRP_MJ_CLEANUP 等[9]。

2.1.1 获取被操作文件信息

在IRP_MJ_CREATE类型的IRP请求包的后操作回调函数中进行文件信息的获取，主要包括文件名称、文件路径、操作的进程信息以及设置上下文操作。而在其预操作回调函数中，不能获取信息文件的信息，否则在运行系统后，随即出现蓝屏的情况。

在 IRP_MJ_READ的后操作回调函数中判断文件是否加密文件，依据文件头部有无加密标识进行判断。如果是加密文件，从文件头部向后移动加密标识的长度，并调用解密模块进行解密处理，解密的过程中使用解密缓存替换原缓存。在进行缓存的读取时，以块为单位进行处理。

在IRP_MJ_WRITE的预操作回调函数中，判断操作进程是否特定进程，由于系统只针对 SAP系统进程进行处理，即若是SAP系统导出文件，则调用加密模块进行加密处理。在加密缓存中首先写入固定长度的字符串，其用于表示该文件是加密文件，以便后续对文件类型进行判断。在读取缓存的时候，每次以弧顶长度进行加密处理[10]：

（1）如若读取长度已达到固定长度，则直接进行加密处理；

（2）当本地块读取完成，但仍不够固定长度进行加密处理，此时暂不进行处理，等待下一块缓存的传入，进行拼接后仍以固定长度进行加密；

（3）在文件结束时，如若不够固定长度进行加密，在字符串的结尾处进行补零处理，直至长度符合要求。

读写文件操作的一般流程参见图3所示，图中未标识出特殊情况的处理过程。IRP_MJ_READ请求会使得文件内容以明文的形式存在于内存中，如加密文件的复制操作或者发送文件，此时会生成IRP_MJ_READ类型的请求包将文件内容读至缓冲区。后续的IRP_MJ_WRITE写请求会将缓冲区中的内容写入文件中，从而使得文件内容被以明文形式保存。为了解决这一问题，在系统中维护一张加密文件信息链表，其中存放了所有被读取文件内容且没有关闭的文件信息，包括文件路径、原缓存地址、替换缓存地址。写文件前对比链表信息，如果有该信息，则使用原缓存地址进行替换；如若没有该信息，直接进行写操作，从而保证文件复制、发送时仍旧以密文的形式发送。

在IRP_MJ_QUERY_INFORMATION的后操作回调函数中，将文件大小与占用空间的值进行处理，因为查询到的结果中包括加密标识的大小，在实际显示时，不应让用户发觉到加密标识的存在。

在IRP_MJ_SET_INFORMATION的预操作回调函数中，将文件大小与占用空间的值进行处理，因为传入的数据中不包括加密标识的大小，是实际文件大小与占用空间，应在其中加入加密标识的大小才是正确的数据。

读写文件属性流程参见图4所示。在读文件属性中用读取到的数据减去文件头部加密标识的长度，并将差值传递至应用层，使得用户在查看文件属性时，显示的是不包含文件头部加密标识的情况[11]。在写文件属性时，将要写入的值与文件头部加密标识长度相加，将和值传递至下层驱动，使得最终写入的值是包含文件头部加密标识长度的。

图3 读写文件操作一般流程

图4 读写文件属性流程

在IRP_MJ_CLOSE后操作回调函数中，不能进行文件名称、文件路径等信息的获取以及对上下文的操作。这是因为当程序执行到IRP_MJ_CLOSE时，系统内部结构以及资源可能已经析构或者释放，此时再对后操作回调函数进行处理，会出现不定期蓝屏，因为不能保证每次执行都是成功的。

IRP_MJ_CLOSE与IRP_MJ_CLEANUP有本质的区别，前者产生的条件是当FO引用计数为0时，发送此IRP；后者产生的条件是当一个文件对象的句柄引用为0时，发送此IRP，即该文件对象所有句柄均关闭。一般，IRP_MJ_CLOSE都是产生于IRP_MJ_CLEANUP之后，有可能紧随着其产生，也可能比IRP_MJ_CLEANUP晚较长时间[12]。

2.1.2 获取操作文件的进程信息

在IRP_MJ_CREATE类型IRP请求包的后操作回调函数以及在IRP_MJ_WRITE类型IRP请求包的预操作回调函数中进行操作文件的进程信息获取，包括进程名称、进程路径。

2.1.3 缓存数据处理

对缓存的处理过程参见图5所示，缓存的读取以块为单位。读取原缓冲区内容时，以块的形式读取，从块中截取固定长度的字符串用于加解密处理，此时需要对字符串的长度进行判断，如果长度为固定长度则直接进行加解密处理；如果长度小于固定长度，判断是否到文件结尾。若未到文件结尾，读取下一块缓存，并将其与之前的字符串拼接再进行处理；若已到文件结尾处，需对字符串进行补0处理，直至长度为固定长度。

图5 读写文件属性流程

2.2 文件驱动与应用程序通信

由于密钥的生成是在应用层生成的，而文件的加解密操作在驱动层实现，故需要将密钥从应用层下发至驱动层。如图4-1（没有图4-1！）所示，在文件过滤驱动程序中有通信模块，实现文件过滤驱动与应用层Server端的通信，将密钥请求上传至Server端，并接收来自Server端的下发信息，该信息中包含有文件加解密的密钥。

2.2.1 通信的建立

通信的建立过程并非是单一的密钥请求发送，验证并下发密钥的过程。为了防止重放攻击以及信息发送与接收过程中可能的其他攻击行为，采用授信的第三方介入到通信的建立过程中。这里的授信的第三方是指KDC（Key Distribution Center）即密钥分配中心，通信双方的会话密钥是由KDC下发的。KDC在Windows操作系统中作为一个域服务来使用，它使用 A ctive Directory作为数据库，使用GlobalCatalog传输数据到其他的域。KDC保存着每一个用户与其之间通信的唯一密钥，该密钥用来保证用户与KDC之间通信的安全性，并且根据该密钥判断信息的来源是可信的。在会话密钥的分配过程中，KDC按照需要生成密钥，并下发至需要进行通信的双方。会话密钥的下发过程中，信息经用户与KDC通信的密钥进行加密处理，以保证会话密钥的安全性[13]。KDC在kerberos中通常提供两种服务：

（1）Authentication Service （AS）：认证服务；

（2）Ticket-Granting Service （TGS）：授予票据服务。

2.2.2 数据传递

在文件透明加密系统中，由于系统相对于用户是透明的，如何获取密钥并分发就显得非常重要。结合本系统自身的特点，SAP系统导出的文件仅能在本地进行正常的操作，不允许离开本机单独操作。结合密钥分配中心KDC，由授信的第三方进行密钥的分配。

图6 密钥分发过程

如图7所示密钥分发过程，通信A方与B方进行通信：

（1）通信A方向KDC发送通信请求，请求中包括A的标识符IDA、N1（随机数与时间戳组合）、请求通信方B标示符IDB。通信请求使用通信A方的主密钥KA（用于与KDC通信）进行加密，这样确保只有KDC可以接收该请求。KDC接收到通信A的通信请求，向通信B方转发通信A方的通信请求，如图6所示（2）流程。

（2）KDC转发A方的通信请求，请求中包括A的标识符IDA、N1、KAB（会话密钥）。通信请求使用通信B方的主密钥KB进行加密，确保只有通信B方能接收该请求，并且让通信B方确信该请求来自KDC。

（3）通信B方发送应答请求，告知KDC通信B存在，可以进行通信。该应答请求中包括A的标识符IDA、f（N1）、B的标示符IDB，该应答请求利用KB进行加密，保证只有KDC能够接收该信息。

（4）KDC转发B方的应答请求，请求中包括B的标识符IDB、f（N1）、KAB。通信请求使用通信A方的主密钥KA进行加密，确保只有通信A方能接收该请求，并且让通信A方确信该请求来自KDC。

（5）通信A方使用会话密钥KAB对会话请求加密，确保只有通信B方能够接收该请求。会话请求中包括A的标识符IDA、N2、B的标识符IDB。

（6）通信B方使用会话密钥KAB对会话请求进行解密，确保只有通信A方能够发送该请求，并验证通信A方信息。通信B方发送会话应答以KAB进行加密，会话应答中包括A的标识符IDA、f（N2）、B的标识符IDB。

（7）通信A方经验证会话应答，确认会话应答是从通信B方发送，且AB之间通信安全。通信A方利用KAB对会话内容加密，会话内容中包括文件密钥，从而实现AB之间安全的信息传递，实现密钥的分发。

2.3 文件透明加密

文件的加密过程在写文件的过程中实现，即在IRP_MJ_WRITE类型IRP请求包的处理函数中进行。处理函数分为预操作回调函数与后操作回调函数，而加密的过程是在预操作回调函数中完成的，即拦截IRP的过程中，从请求包中获取写文件信息。如果该文件是需要加密的文件，则申请新的缓存区，逐长度的读取字符串，经过加密运算，将加密结果写入新的缓存区，全部字符串加密完成后，将新的缓存区的地址写入IRP请求包中，替换原有的IRP请求包中的缓存地址。

在判断文件是否是需要加密的文件过程中，是依据获取的操作文件的进程信息进行判断的，判断进程名称是否是SAPLogon.exe，如果是则表示该文件是 SAP系统的导出文件，是需要进行加密处理的。

结合SAP系统导出文件的特点，SAP系统在显示数据部分常用ALV、OOALV、REPORT等方式，通过对SAP系统工作流程的研究，导出文件操作均是针对显示数据进行的。以导出文件到桌面为例，具体流程参加图7所示。

导出文件时，例如导出到桌面，文件在写入完成前，不会在桌面生成临时文件（.temp）并最终实现临时文件的保存、覆盖等操作。

图7 文件导出流程图

而是在SAP系统目录下，首先生成模板临时文件，将模板信息导出写入临时文件中并保存。然后在桌面上生成临时文件，将前面已经导出的模板文件内容复制到桌面临时文件中，再将ALV中展示数据导出到桌面临时文件中，导出完成后保存文件并删除SAP系统目录下导出模板文件。

如果在导出操作完成前终止导出操作，根据导出操作进行的程度，会产生不同的效果，未生成模板文件、生成模板文件且未生成导出文件、生成模板文件且导出部分数据。在对系统模型测试过程中，需对以上所有可能发生的情况进行验证，以保证系统模型涵盖所有导出情况。

加密的过程采用DES加密算法以及AES加密算法。系统中采用两种加密算法是为了对加密效率进行比较，并证明本系统的可实现性。解密的过程与加密的过程相反，但不是完全相同的。

另外针对文件复制与发送的特殊情况，文件被操作时，虽然没有执行读操作，但是实际上有IRP_MJ_READ类型的IRP请求包生成，在执行该操作时，文件的内容已经被读至缓冲区，并且是以明文的形式保存。如果此时直接进行文件写操作，即生成IRP_MJ_WRITE类型的 IRP请求包，会造成缓冲区中的明文被写入文件中，从而使得文件加密被破解。

为了解决这样的问题，在处理 IRP_MJ_WRITE类型的 IRP请求包时，加入加密文件链表。链表中保存着文件名称、原缓冲区地址、新缓冲区地址等信息，并且该文件是进行过IRP_MJ_READ但没有关闭的加密文件。当有加密文件被读取内容时，将该文件的信息插入至链表中；当文件被关闭时，将该文件信息从链表中删除。在上面的步骤中加入对文件信息的判断，即当有IRP_MJ_WRITE类型的IRP请求包生成时，判断缓存地址是否在链表中有记录，如果有该条记录，则将链表中的原缓存地址替换此IRP请求包中的缓存地址，即将密文写入到文件中。从而实现对文件的保护。

3 原型系统实现和仿真实验

3.1 原型系统架构

系统主要包括三个部分，分别是SAP系统导出文件、驱动层文件操作处理与文件透明加解密、Server端。具体结构参见图8所示。

从图8中可以看出，文件过滤驱动程序是本系统的核心部分，也是开发的重难点。操作处理中主要对操作处理回调函数进行设置，尤其是对前后的选择。缓存处理，将经过处理的缓存替换原有缓存，并将信息传递给下层进行处理。加解密模块实现了两种加密算法，用于证明该系统对多种加解密算法的支持。应用层通信，用于向应用层Server端发送获取密钥请求并接收密钥。文件类型，根据文件头部是否存有加密标识判断文件是否加密文件。

图8 系统结构图

图9显示了系统中数据的流向，文件过滤驱动程序位于文件系统驱动程序之上，拦截需要处理的IRP，并交给相应的操作处理回调函数进行处理。文件过滤驱动程序与应用层Server端通信，实现密钥的获取请求发送与密钥的接收。

图9 系统数据流程图

3.2 实验环境

本系统的测试环境主要有 WinDbg与虚拟机联调、WDK、DriverMonitor。不仅在最后的测试环节中，在程序调试的过程中，WinDbg与虚拟机联调起着重要的作用。在测试过程中，测试文件大小为1.27M、10.43M、100M，分别使用三种类型文件进行测试，测试过程中时间计算是从加解密开始计算计时，不包括SAP系统导出时其响应时间。

3.3 结果分析

别对EXCEL、TXT、WORD三种类型导出文件进行测试，测试该系统模型对文件类型的可支持性。并且测试 1.27M、10.43M、100M三个文件大小数量级，检测该系统模型耗时是否是用户可接受的。在文件加解密过程中，采用通用的AES与DES两种加密算法。在表5-1所显示的部分测试数据中，加密时间范围为1.86-124.77，解密时间范围为1.97-124.83，均在可接受的范围之内。

通过对具有不同数量级大小的三种类型文件进行 DES与AES加解密处理测试，初步证明了该系统模型的可行性，及对多种文件的支持。为了验证上述结论的正确性，本文进行了大量的实测实验，并绘制加解密时间随文件大小变化的分布图，参见图5-13所示，其中的数据来源是EXCEL类型文件经AES加密算法处理过程中获取的，其他两种文件类型的数据分布与图10类似，区别在于饱和点的位置不同。从分布图中可以看到文件大小增长到1000M时，加密时间仍在可接受范围内。

表1 部分测试数据

图10 加密时间随文件大小变化分布图

实验数据证明了本文提出的对 SAP系统导出文件实施保护方法的有效性与可行性，以及本文实现的系统模型的正确性。该系统安装后，不改变用户的使用习惯，用户可以正常操作SAP系统并实现导出文件。在本地计算机中打开文件可以看到文件内容正常显示，将文件复制到其他计算机上，文件可以打开，显示为乱码，从而实现了对SAP系统导出文件的加密保护，将导出文件限制在本地计算机中，而对其他文件不产生影响。

4 结论

本文基于企业信息安全实际的需求，设计并实现软件系统，完成了基于 SAP系统导出文件设计与安全性提升的功能要求。对文件监控的方式有应用层的API、驱动层的SSDT以及驱动层IRP三种方式。结合SAP系统自身的特点，研究、综合比较三种方式，选取其中最适宜的方式进行本系统模型的建立，并最终实现本系统。由于本文不是按照文件类型对文件实施加密的，即在同一台计算机上只有由 SAP系统导出的文件需要加密，其他文件均不需要加密。因此对文件系统监控时，判断进程信息，若是特定进程即进行监控。SAP系统并不直接对文件进行操作，故需研究如何将 SAP系统的操作与对应文件联系起来。最后针对该软件系统实现功性能测试并分析实验结果数据，验证研究成果、方法、技术的可行性。