李育平

（西安思源科創(chuàng)軌道交通技術開發(fā)有限公司 陜西 710054）

0 引言

在企業(yè)運作中，越來越多的成果以者電子文檔形式存在。企業(yè)文檔管理中最重要的需求莫過于安全性，尤其是當前網絡無處不在的情況下，保證敏感資料的可控性在管理中占據相當重要的地位。本文就Subversion在企業(yè)文檔管理中使用時的幾種服務器配置方式，尤其是其中用戶認證、用戶授權、通訊加密等安全性相關的部分，進行了簡單的介紹和比較。

1 Subversion網絡層

Subversion 的網絡層是抽象的，即版本庫建立后可以通過各種服務器向外發(fā)布，并通過支持相應協議的客戶端進行訪問。理論上有無數種實現方式，實際上目前廣泛使用的有幾種：一種是Apache網頁服務器，借助擴展模塊使用基于萬維網的分布式創(chuàng)作和版本控制（HTTP Extensions for Web Distributed Authoring and Versioning，WebDAV）協議進行發(fā)布，另外一種是通過 svnserve（一個輕量級服務器程序）使用svn協議進行發(fā)布，還有一種是在svnserve基礎上通過安全殼協議（Security Shell，SSH）隧道化后進行發(fā)布。在第三種方式中，由于SSH需要系統賬戶支持，當版本庫需要大量用戶進行交互時，除非服務器已具備相關賬戶設置條件，否則不推薦這種方式，因為一般情況下在企業(yè)專用服務器上設置大量賬戶會帶來隱患。下表就前兩種配置方式進行簡單介紹：

表1 subversion服務器比較

2 網絡環(huán)境下版本庫服務器的安全相關需求

企業(yè)環(huán)境下，版本庫的所有操作都是需要明確的權限的。首先能否進入版本庫就是最基本的問題，一般情況下開發(fā)人員都應該擁有準入權限，否則無法提交代碼等，除非特殊情況如版本庫只用來保存穩(wěn)定版本以作為存檔保密設備使用，但這樣一來就失去了設置版本庫的必要，完全可以用其它方式如燒錄光盤存放在保險柜里替代。其次，進入版本庫的賬戶各自擁有的權限必須明確，禁止查看、只讀、讀寫是逐級遞進的過程，如保密性資料除了特定人員外，其余人員都是無權查看的，常見的如專利類資料、穩(wěn)定版本代碼等，其余視文件的保密需求設置相應的權限也是類似的。再次，在企業(yè)內部局域網環(huán)境中的計算機一般都是可信任的，但是隨著企業(yè)規(guī)模的擴大及當前網絡技術的發(fā)展，網絡攻擊的手段層出不窮，當攻擊者進入突破防火墻進入企業(yè)內部網絡后，由于內部主機之間相互信任（這幾乎是常態(tài)），攻擊者基本上如入無人之境，可以隨意的嗅探網絡流量以獲取敏感信息，因此版本庫服務器也需要具備一定的網絡通信加密功能。

2.1 認證

認證是確認“某人就是他所宣稱的那個人”的過程，我們可以利用這種機制來過濾進入版本庫中進行操作的人員，阻擋允許進入版本庫的其余人員。

客戶端訪問基于Apache的版本庫服務器時（以使用摘要認證為例）的簡化流程如下：

（1）客戶端發(fā)送請求；

（2）服務器要求摘要認證，發(fā)送用于計算 MD5哈希值的隨機數；

（3）客戶端使用該隨機數、用戶名、密碼、請求的資源路徑等計算MD5哈希值，發(fā)送給服務器；

（4）服務器使用相同方式進行計算及比對，一致則認證通過，開始后續(xù)通信；

……

基于svnserve方式中，當編譯為支持SASL[2]（是上層協議如svn等與SASL機制之間的接口框架）框架時，有很多的認證機制可供選擇。下面以GSSAPI（Kerberos V5 for GSS-API）機制為例，當客戶端訪問這種方式架設的版本庫服務器時的簡化流程如下：

（1）客戶端選擇特定版本庫；

（2）客戶端發(fā)送數據開始初始化上下文（數據安全層可選）；

（3）服務器根據本地憑證進行驗證，回復客戶端是否完成驗證；

（4）客戶端接收回復后根據自己的憑證進行驗證，不通過則開始重新初始化上下文，否則認為建立起安全上下文，開始后續(xù)通信；

……

2.2 授權

授權是允許“某人進行他想要進行的查看或修改的操作”的過程，及具有相應的權限以開展工作，一般是建立在認證完成的基礎上。在配置合適的情況下，這兩種方式都可以授予認證用戶所有權限，這在現實中使用的比較廣泛，比如各類開源項目的源代碼分發(fā)、企業(yè)內部規(guī)章制度、政策性文件等。但是對于一般的企業(yè)來講，相對敏感的技術文件資料等是嚴格限定閱讀修改權限的，并且根據不同的等級、部門、項目都有不同的要求，因此需要粒度更加細致的訪問權限控制。

這兩種防止也都支持基于路徑的訪問控制，這種粒度更加細致的訪問控制，對于權限的控制相對嚴格的多。然而現實中并非需要那么嚴格的權限設定，因為人事、項目、組織架構都在變動，過于嚴格的權限設定反而會降低效率。例如很多非機密資料可以通過行政性策略如各項規(guī)章制度禁止修改，即使無關人員無意或有意修改了本來不應該修改的文件，也可以通過版本庫回滾操作恢復，而不是在服務器配置文件中設置成千上萬的只讀權限來實現。

2.3 數據加密

Apache服務器本身的認證方式比如上文所述簡化流程中基本的用戶名/密碼認證及改進的摘要算法認證，都是通過http協議進行訪問，所有的通信如認證用戶名密碼傳輸、版本庫目錄查詢等信息在網絡上都是公開的，這會給隱藏的嗅探類攻擊利用。因此一般會將服務器配置為使用https[3]（http over SSL）對網絡進行加密傳輸，以避免網絡上明文傳輸導致的敏感數據泄露。

當客戶端通過https訪問時，簡化的初始流程如下：

（1）客戶端發(fā)出https交互請求；

（2）服務器發(fā)送證書；

（3）客戶端根據根據認證中心（Certificate Authority，CA）列表驗證服務器證書；

（4）客戶端發(fā)送隨機對稱加密密鑰等；

（5）服務器相應已完成握手；

（6）開始加密通信（認證、數據傳輸等）；

……

這樣包括認證信息在內的所有通信就都包含在SSL加密通道里了，即使網絡上發(fā)生泄露，攻擊者也無法對數據進行解密，因為傳輸的數據都經過了只有服務器和客戶端才知道的隨機加密密鑰（一次性）的加密過程。

基于svnserve的版本庫服務器在支持SASL時會提供額外的可選數據安全層，如前文例子中所述。由于不同的svn客戶端在訪問svnserve的認證過程中，基于兼容性等問題，在服務器提供SASL機制中會選擇自己支持的進行交互，這樣攻擊者可以在認證用戶使用無數據安全層的SASL機制的客戶端與服務器交互時，對網絡流量進行嗅探以獲得敏感數據。相比較于使用https對版本庫訪問，這種架構的服務器配置方式安全性計較差。

3 總結

在這兩種方式中，基于svnserve的方式當需要滿足企業(yè)保密需求時，需要部署相應的SASL機制以達到基于Apache方式的相同安全性能，這時SASL機制的多樣性及復雜性可能會給管理員（一般企業(yè)甚至可能是兼職）帶來不小的障礙，會導致人工失誤導致的可靠性、可使用性下降。而Apache使用成熟的https訪問版本庫方式在認證及數據加密方面相對svnserve更加適合于適合于在實際中部署應用，尤其是在已經具備服務器（部署企業(yè)網站、OA系統、內部郵件系統等）條件的企業(yè)內，配置維護工作相對 svnserve方式可操作性比較大，此外基于Apache方式還可以獲得額外的好處，如本身豐富的日志功能，可以穿透企業(yè)防火墻等。因此，無特殊需求的條件下（例如速度優(yōu)先等），部署基于Apache的版本庫服務器無疑是企業(yè)的首選。

[1]Ben Collins-Sussman，Brian W.Fitzpatrick，C.Michael Pilato.Version Control with Subversion（2nd Edition）.O'Reilly Media.2008.

[2]Alexey Melnikov.RFC 4422：Simple Authentication and Security Layer（SASL）.IETF.2006-11.

[3]魏興國.HTTP和HTTPS協議安全性分析[J].程序員，2007（7）：53-55.