基于subversion的版本庫服務(wù)器簡單比較

李育平

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

0 引言

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

1 Subversion網(wǎng)絡(luò)層

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

表1 subversion服務(wù)器比較

2 網(wǎng)絡(luò)環(huán)境下版本庫服務(wù)器的安全相關(guān)需求

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

2.1 認(rèn)證

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

客戶端訪問基于Apache的版本庫服務(wù)器時(shí)（以使用摘要認(rèn)證為例）的簡化流程如下：

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

（2）服務(wù)器要求摘要認(rèn)證，發(fā)送用于計(jì)算 MD5哈希值的隨機(jī)數(shù)；

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

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

……

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

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

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

（3）服務(wù)器根據(jù)本地憑證進(jìn)行驗(yàn)證，回復(fù)客戶端是否完成驗(yàn)證；

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

……

2.2 授權(quán)

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

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

2.3 數(shù)據(jù)加密

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

當(dāng)客戶端通過https訪問時(shí)，簡化的初始流程如下：

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

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

（3）客戶端根據(jù)根據(jù)認(rèn)證中心（Certificate Authority，CA）列表驗(yàn)證服務(wù)器證書；

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

（5）服務(wù)器相應(yīng)已完成握手；

（6）開始加密通信（認(rèn)證、數(shù)據(jù)傳輸?shù)龋?/p>

……

這樣包括認(rèn)證信息在內(nèi)的所有通信就都包含在SSL加密通道里了，即使網(wǎng)絡(luò)上發(fā)生泄露，攻擊者也無法對(duì)數(shù)據(jù)進(jìn)行解密，因?yàn)閭鬏數(shù)臄?shù)據(jù)都經(jīng)過了只有服務(wù)器和客戶端才知道的隨機(jī)加密密鑰（一次性）的加密過程。

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

3 總結(jié)

在這兩種方式中，基于svnserve的方式當(dāng)需要滿足企業(yè)保密需求時(shí)，需要部署相應(yīng)的SASL機(jī)制以達(dá)到基于Apache方式的相同安全性能，這時(shí)SASL機(jī)制的多樣性及復(fù)雜性可能會(huì)給管理員（一般企業(yè)甚至可能是兼職）帶來不小的障礙，會(huì)導(dǎo)致人工失誤導(dǎo)致的可靠性、可使用性下降。而Apache使用成熟的https訪問版本庫方式在認(rèn)證及數(shù)據(jù)加密方面相對(duì)svnserve更加適合于適合于在實(shí)際中部署應(yīng)用，尤其是在已經(jīng)具備服務(wù)器（部署企業(yè)網(wǎng)站、OA系統(tǒng)、內(nèi)部郵件系統(tǒng)等）條件的企業(yè)內(nèi)，配置維護(hù)工作相對(duì) svnserve方式可操作性比較大，此外基于Apache方式還可以獲得額外的好處，如本身豐富的日志功能，可以穿透企業(yè)防火墻等。因此，無特殊需求的條件下（例如速度優(yōu)先等），部署基于Apache的版本庫服務(wù)器無疑是企業(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協(xié)議安全性分析[J].程序員，2007（7）：53-55.