基于過濾驅動的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系統的操作與對應文件聯系起來。最后針對該軟件系統實現功性能測試并分析實驗結果數據，驗證研究成果、方法、技術的可行性。