李育平

（西安思源科创轨道交通技术开发有限公司 陕西 710054）

0 引言

在企业运作中，越来越多的成果以者电子文档形式存在。企业文档管理中最重要的需求莫过于安全性，尤其是当前网络无处不在的情况下，保证敏感资料的可控性在管理中占据相当重要的地位。本文就Subversion在企业文档管理中使用时的几种服务器配置方式，尤其是其中用户认证、用户授权、通讯加密等安全性相关的部分，进行了简单的介绍和比较。

1 Subversion网络层

Subversion 的网络层是抽象的，即版本库建立后可以通过各种服务器向外发布，并通过支持相应协议的客户端进行访问。理论上有无数种实现方式，实际上目前广泛使用的有几种：一种是Apache网页服务器，借助扩展模块使用基于万维网的分布式创作和版本控制（HTTP Extensions for Web Distributed Authoring and Versioning，WebDAV）协议进行发布，另外一种是通过 svnserve（一个轻量级服务器程序）使用svn协议进行发布，还有一种是在svnserve基础上通过安全壳协议（Security Shell，SSH）隧道化后进行发布。在第三种方式中，由于SSH需要系统账户支持，当版本库需要大量用户进行交互时，除非服务器已具备相关账户设置条件，否则不推荐这种方式，因为一般情况下在企业专用服务器上设置大量账户会带来隐患。下表就前两种配置方式进行简单介绍：

表1 subversion服务器比较

2 网络环境下版本库服务器的安全相关需求

企业环境下，版本库的所有操作都是需要明确的权限的。首先能否进入版本库就是最基本的问题，一般情况下开发人员都应该拥有准入权限，否则无法提交代码等，除非特殊情况如版本库只用来保存稳定版本以作为存档保密设备使用，但这样一来就失去了设置版本库的必要，完全可以用其它方式如烧录光盘存放在保险柜里替代。其次，进入版本库的账户各自拥有的权限必须明确，禁止查看、只读、读写是逐级递进的过程，如保密性资料除了特定人员外，其余人员都是无权查看的，常见的如专利类资料、稳定版本代码等，其余视文件的保密需求设置相应的权限也是类似的。再次，在企业内部局域网环境中的计算机一般都是可信任的，但是随着企业规模的扩大及当前网络技术的发展，网络攻击的手段层出不穷，当攻击者进入突破防火墙进入企业内部网络后，由于内部主机之间相互信任（这几乎是常态），攻击者基本上如入无人之境，可以随意的嗅探网络流量以获取敏感信息，因此版本库服务器也需要具备一定的网络通信加密功能。

2.1 认证

认证是确认“某人就是他所宣称的那个人”的过程，我们可以利用这种机制来过滤进入版本库中进行操作的人员，阻挡允许进入版本库的其余人员。

客户端访问基于Apache的版本库服务器时（以使用摘要认证为例）的简化流程如下：

（1）客户端发送请求；

（2）服务器要求摘要认证，发送用于计算 MD5哈希值的随机数；

（3）客户端使用该随机数、用户名、密码、请求的资源路径等计算MD5哈希值，发送给服务器；

（4）服务器使用相同方式进行计算及比对，一致则认证通过，开始后续通信；

……

基于svnserve方式中，当编译为支持SASL[2]（是上层协议如svn等与SASL机制之间的接口框架）框架时，有很多的认证机制可供选择。下面以GSSAPI（Kerberos V5 for GSS-API）机制为例，当客户端访问这种方式架设的版本库服务器时的简化流程如下：

（1）客户端选择特定版本库；

（2）客户端发送数据开始初始化上下文（数据安全层可选）；

（3）服务器根据本地凭证进行验证，回复客户端是否完成验证；

（4）客户端接收回复后根据自己的凭证进行验证，不通过则开始重新初始化上下文，否则认为建立起安全上下文，开始后续通信；

……

2.2 授权

授权是允许“某人进行他想要进行的查看或修改的操作”的过程，及具有相应的权限以开展工作，一般是建立在认证完成的基础上。在配置合适的情况下，这两种方式都可以授予认证用户所有权限，这在现实中使用的比较广泛，比如各类开源项目的源代码分发、企业内部规章制度、政策性文件等。但是对于一般的企业来讲，相对敏感的技术文件资料等是严格限定阅读修改权限的，并且根据不同的等级、部门、项目都有不同的要求，因此需要粒度更加细致的访问权限控制。

这两种防止也都支持基于路径的访问控制，这种粒度更加细致的访问控制，对于权限的控制相对严格的多。然而现实中并非需要那么严格的权限设定，因为人事、项目、组织架构都在变动，过于严格的权限设定反而会降低效率。例如很多非机密资料可以通过行政性策略如各项规章制度禁止修改，即使无关人员无意或有意修改了本来不应该修改的文件，也可以通过版本库回滚操作恢复，而不是在服务器配置文件中设置成千上万的只读权限来实现。

2.3 数据加密

Apache服务器本身的认证方式比如上文所述简化流程中基本的用户名/密码认证及改进的摘要算法认证，都是通过http协议进行访问，所有的通信如认证用户名密码传输、版本库目录查询等信息在网络上都是公开的，这会给隐藏的嗅探类攻击利用。因此一般会将服务器配置为使用https[3]（http over SSL）对网络进行加密传输，以避免网络上明文传输导致的敏感数据泄露。

当客户端通过https访问时，简化的初始流程如下：

（1）客户端发出https交互请求；

（2）服务器发送证书；

（3）客户端根据根据认证中心（Certificate Authority，CA）列表验证服务器证书；

（4）客户端发送随机对称加密密钥等；

（5）服务器相应已完成握手；

（6）开始加密通信（认证、数据传输等）；

……

这样包括认证信息在内的所有通信就都包含在SSL加密通道里了，即使网络上发生泄露，攻击者也无法对数据进行解密，因为传输的数据都经过了只有服务器和客户端才知道的随机加密密钥（一次性）的加密过程。

基于svnserve的版本库服务器在支持SASL时会提供额外的可选数据安全层，如前文例子中所述。由于不同的svn客户端在访问svnserve的认证过程中，基于兼容性等问题，在服务器提供SASL机制中会选择自己支持的进行交互，这样攻击者可以在认证用户使用无数据安全层的SASL机制的客户端与服务器交互时，对网络流量进行嗅探以获得敏感数据。相比较于使用https对版本库访问，这种架构的服务器配置方式安全性计较差。

3 总结

在这两种方式中，基于svnserve的方式当需要满足企业保密需求时，需要部署相应的SASL机制以达到基于Apache方式的相同安全性能，这时SASL机制的多样性及复杂性可能会给管理员（一般企业甚至可能是兼职）带来不小的障碍，会导致人工失误导致的可靠性、可使用性下降。而Apache使用成熟的https访问版本库方式在认证及数据加密方面相对svnserve更加适合于适合于在实际中部署应用，尤其是在已经具备服务器（部署企业网站、OA系统、内部邮件系统等）条件的企业内，配置维护工作相对 svnserve方式可操作性比较大，此外基于Apache方式还可以获得额外的好处，如本身丰富的日志功能，可以穿透企业防火墙等。因此，无特殊需求的条件下（例如速度优先等），部署基于Apache的版本库服务器无疑是企业的首选。

[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.