微型机与应用
MICROCOMPUTER & ITS APPLICATIONS
1999年 第18卷 第1期 Vol.18 No.1 1999



连载之五：WebST安全性能(二)
那日松
(接上期)
6.2　通过WebST安全网关对Internet用户进行身份验证
　　WebST安全网关可以将采用其他安全机制的Internet用户集成到WebST安全服务中来。WebST安全网关是用来与Internet用户之间动态地建立起相互信任的安全会话过程，然后将Internet用户身份映射到WebST访问控制机制可以管理的WebST内部网络用户身份。目前版本的WebST安全网关支持与安全套接字SSL技术的用户的集成，其他安全技术将在未来的版本中加以支持。
　　WebST安全网关与用户集成得到的安全性能取决于用户使用的浏览器的具体实现。例如SSL定义中允许服务器方和客户方互相进行身份验证，但是目前支持SSL的商业化产品并不提供用户―方的身份验证。也就是说，只有用户能够验证WebST安全网关而浏览器并不支持WebST安全网关对使用浏览器用户的身份进行直接的验证。
　　在WebST网关和使用支持SSL(未来的版本中将包括S-HTTP)的浏览器的Internet用户之间的身份验证，是建立在公开密钥加密数字签名和授权证明之上的。数字签名工作如下：
　　.用户产生一段文字信息然后对这段文字信息进行单向不可逆的变换。用户再用自己的秘密密钥对生成的文字变换进行加密，并将原始的文字信息和加密后的文字变换结果传送给指定的接收者。这段经过加密的文字变换结果就被称作数字签名。
　　.文字信息和加密后的文字变换的接收者将收到的文字信息进行同样的单项不可逆的变换。同时也用发送方的公开密钥对加密的文字变换进行解密。如果解密后的文字变换和接收方自己产生的文字变换一致，那么接收方就可以相信对方的身份，因为只有发送方的秘密密钥能够产生加密后的文字变换。
　　.要向发送方验证接收方的身份，接收方根据自己的密钥创建一个新的数字签名然后重复上述过程。
　　一旦两个用户互相验证了身份，他们就可以交换用来加密他们交换数据的密钥(如DES加密密钥)。(公开密钥加密方法对于大量的数据加密来说速度太慢)。图1的例子表示了WebST网关B向浏览器验证自己身份并且交换密钥的过程。浏览器应该能够在类似的交换过程中使用它的公开/秘密密钥组合对来验证它的身份。但是目前在WEB上公开密钥加密技术(即SSL)的实现中还没有出现支持浏览器身份验证的产品。

图1　身份验证及交换密钥的过程
　　为了利用数字签名，接收方必须拥有发送方的公开密钥。公开密钥是通过授权证明(Certificates of Authority,CA)来发布的，在图1的例子中，WebST网关发送包含有它的公开密钥的CA给浏览器(目前由于只使用了服务器方的身份验证，所以在CA中只需要包含WebST安全网关的公开密钥)。这些授权证明是由可信赖的第三方生成的并且经过可信赖的第三方用秘密密钥“数字签名”的。
　　用户的浏览器(或者其他客户方的程序)要接收由受信赖的第三方签发的正确的CA就必须要配置受信赖的第三方的公开密钥(浏览器用户使用配置好受信赖的第三方公开密钥的浏览器，来验证CA中的受信赖的第三方的数字签名)。如果该浏览器没有配置受信赖的第三方的公开密钥，它就无法验证WebST安全网关的身份。一些浏览器预先配置有受信赖的第三方公开密钥，并且用户不能增加其他签发CA的受信赖的第三方，这就限制了在无关公司推出的浏览器用户与公司拥有的服务器之间建立相互信任关系的能力。
　　需要指出的是很多现有的商业浏览器对于用户来说接受或拒绝一个由特定第三方数字签名的CA并不很方便。用户可以移去第三方密钥来拒绝所有第三方签发的证明，但是无法配置浏览器只拒绝特定的身份证明。
　　目前的基于SSL的浏览器并不允许WebST网关验证浏览器用户的身份，或者允许浏览器用户自动接受并解密有用户的公开密钥加密的信息。使用WebST技术的企业能够建立一种辅助的过程，来分发CA并且支持用用户公开密钥加密信息。
　　例如，一家公用事业公司可以将它的公开密钥刊登在它每个月的帐单上。绝大多数用户都会相信他们每个月的帐单及其包含的信息是确实由该公用事业公司提供的。然后用户就可以使用公司的公开密钥传送经过加密的、包含他们的帐号、还可能有他们自己公开密钥的信息(利用其他辅助程序如PGP等)。在公用事业一端的WebST网关就能够利用用户的公开密钥对相应信息进行加密，用户通过浏览器将这些相应信息下载后就可以通过其他辅助程序进行解密。
　　在理论上说公开密钥加密方法很适合互相不熟悉的用户之间建立相互信任关系。不幸的是目前CA管理模式和在商业化浏览器中的支持程度限制了它的效果。基于支持CA发展的根本要求，WebST产品将开发利用更多的公开密钥进行身份验证策略等功能。到那时，WebST产品将使采用支持公开密钥加密的浏览器用户能够通过WebST网关公开/秘密密钥组合进行身份验证，用获得的阶段性密钥来与WebST网关进行加密通信。一般情况下WebST网关并不对浏览器用户身份进行验证，浏览器用户必须在发送机密信息之前配置他们的浏览器以验证来自WebST网关的CA正确性。
7　访问控制
　　WebST利用了DCE安全性提供的访问控制。DCE安全性允许将访问控制表(ACL)与WebST Web服务器上的每一个对象元素联系到一起。一个ACL规定对对象元素完成某些操作的权限。比如，如果目标对象是一个文件，ACL能规定对它进行读、写、执行、删除或移动的权限，同时也能规定这个文件在网络传输时是否必须加密。每个用户都有一组相关的权限关系，并由DCE安全服务进行维护，当用户登录WebST系统时，用户和其权限就被联系起来。DCE安全服务确保用户有足够的权限去完成对WebST Web服务器上目标对象的操作。
　　WebST安全服务允许将用户组成用户组，同组成员具有相同的权限，这大大简化了访问控制特权的管理。比如所有“普通用户”组的成员可以允许读某些文件，但“管理员”组的成员就可以修改这些文件。
　　Internet用户通过WebST网关访问企业内部网的WebST，也将由DCE分配权限。我们提到在目前应用公开密钥加密的浏览器实现中并不支持WebST网关对用户的身份验证。因此，安全策略规定这类用户的特权比Webse用户的特权要少得多。
　　WebST安全服务器提供了管理控制台功能。采用了稀疏访问控制技术和基于角色的访问控制技术。
　　访问控制规定了用户对资源对象的访问权限。从数学上来看，访问控制是一个表，其行表示资源对象，其列表示用户，行和列的交叉点表示某个用户对某项资源的访问权限。当一个网络有1 000个用户，1 000项资源时，ACL表有100万项，如果管理员1天能配置1 000项(假设他一直头脑清醒)，那么完成所有配置需要3年时间!稀疏访问控制技术模仿了数学上的稀疏矩阵技术。WebST稀疏访问控制技术的思想是：将资源按树型结构组织，就像WINDOWS的资源管理器一样：靠近根的资源，能够访问的人很多，但访问权限很小；靠近页的资源，能够访问的人很少，但访问权限很大。这样就可以实现授权继承，即用户一旦对某个资源点具有某种访问权限，他就对该点以下的所有点具有同样的权限。这种方式与WINDOWS资源管理器中的共享设置完全类似。稀疏访问控制技术大大简化了授权管理的工作量，而且保证一致性。
　　角色在戏剧中定义了具有一定行为规范的人物，即人物和人物的行为规范，这与网络中基于用户身份的授权是类似的。WebST中的角色包括用户或用户组，以及这些用户的访问权限设置。在网络中，用户的角色定义可以根据用户的职称、职务、部门等多种方式定义，可以灵活地反映网络管理的需求。WebST中，角色表示为一把锁，将锁拖动到资源树的某一节点上，就自动实现了可继承的访问控制，大大简化了授权管理和维护。
8　在WebST中使用防火墙
　　防火墙是限制对传统TCP/IP应用服务进行网络访问的有用工具。防火墙主要通过协议过滤来实现访问限制。当试图提供从安全区域到Internet的单向访问或者在地理上隔开的区域建立加密通道时，这种过滤是非常有用的。但是，这种特性也限制了更广泛的网络使用，例如企业的成员希望能够从家里获得和在办公室里一样的网络访问服务时就会受到限制。
　　管理的重点可以放在对应用提供的服务以及该应用的用户的分析上。经过分析后可以定义并且配置基于WebST ACL的安全模型来限制网络访问。对安全问题更加细致的控制可以用基于访问控制的方式直接构造进应用程序中。WebST服务器采用了DCE访问控制作为构造区域安全政策的模型以及实现的基础。
　　防火墙和WebST服务的网络之间关系非常简单。所有WebST/SEAT通信都是在底层网络上使用DCE远程过程调用RPC进行的。防火墙不需要担心在WebST服务器上实施安全政策，因为它们可以被配置成只通过RPC端口接受服务请求。WebST的网络管理员只需要将精力集中在建立访问控制列表数据库上。
　　在区域的过滤器中，可以根据不加任何处理地通过所有WebST RPC这一主要规则对防火墙进行配置。WebST服务器将严格遵守为网络资源定义的访问规则(这包括在WebST服务器和SEAT客户方之间保密数据的访问规则)，严格遵守提供服务的日期。如果服务器接收到SEAT客户相应安全级别的请求，它将只传输被定义为秘密的数据。
　　如图2所示，WebST安全单元是通过SEAT客户方来访问的。在WebST Web服务器和Webse客户方之间的通信是通过DCE RPC进行的。这就减少了防火墙进行干预的需要。被配置成支持远程Webse访问的防火墙过滤路由器有一条主要过滤规则就是允许所有DCE RPC操作通过而不作任何干预。


图2　防火墙与WebST的关系
　　与WebST服务器同时使用的WebST防火墙用来保证在一个WebST安全单元内的系统只能通过DEC RPC协议进行访问。这一协议保证客户服务器之间的交互是在DCE安全服务和服务器访问控制服务的控制之下的。　　
　　通过去除防火墙的许多对原始数据进行加工的服务(包括加密)，WebST可以为需要持续的数据流的应用服务提供方便。这也有助于减轻防火墙的负载，因为WebST只对有加密需求的访问控制进行数据加密。它只能对网络节点之间或者区域之间所有数据进行加密，或者针对某个TCP端口的所有数据进行加密。
　　WebST能与现存的、允许对某个TCP端口采用“通过”规则的防火墙很好地结合起来。典型的WebST安装时配置防火墙基于下列两点原因：
　　.对传统应用的保护。
　　.限制只能用DCE RPC访问WebST安全单元。
　　WebST服务器和SEAT客户方负责端到端的数据保护。
9　综述
　　概括而言，WebST利用DCE安全性，使用基于DES加密和用户口令的审核协议来互相验证Webse和WebST Web服务器。DCE安全服务器也建立一个基于DES的阶段性的密钥，用以加密在SEAT用户和WebST Web服务器之间传输的信息。
　　安全套接层(SSL―Secure Sockets Layer)是NetScape或其它软件使用的安全性机制，它用公开密钥加密的数字签名来验证WebST安全网关，并且建立基于DES的阶段性密钥用来加密在浏览器和基于SSL服务器之间传输的信息。WebST网关允许在DCE所提供的集中控制的安全管理下，将SSL或SHTTP安全用户(以及建立动态信任关系的临时用户)结合在一起。表1为WebST的安全性说明。
表1　WebST的安全性

　企业内部网的
WebST安全性SSL通过WebST安全
网关的WebST安全性
大量数据加密DESDES(可用其它加密方法)
身份验证互相之间。
基于由DCE安全服务管理的口令。仅服务器端。
基于由WebST安全网关批准公共密钥。
安全和信任管理安全WebST管理器和DCE保证所有用户和服务器采用一致的安全性。
企业用户不必决定信任与否。安全WebST管理器和DCE保证Internet用户访问企业内部网络时的安全。
最终用户必须决定是否信任WebST安全网关。
访问控制DCE访问控制表(ACL)用户被映射到DCE并且使用访问控制表(ACL)


　　安全政策可以基于下列问题：
　　.客户和服务器之间的传输安全吗?
　　.研究开发部门是否应该能够读这个URL?
　　.URL目录的内容可以被非管理职员阅读吗?
　　由于WebST基于DCE的访问控制可以使客户方请求的安全内容由服务器应用程序来进行评估，安全政策以此为基础建立模型。访问控制由WebST管理员集中管理。这样也使实现企业安全规则变得容易。
　　这一模型更接近许多企业试图联入公共网络时出现的商业上的问题。与此相反，只采用防火墙的模型是将商业问题映射到协议、网络节点间通信以及不同网络区域之间通信的加密。
　　WebST/SEAT应用到应用模型提供了建立以应用为中心的安全政策的工具。这种以应用为中心的安全机制给予安全区域用户更大的灵活性。总之，WebST扩大了安全区域，允许利用协议隧道技术通过像Internet这样不安全的区域并不受限制地访问WebST服务器。
　　在防火墙领域，WebST能与防火墙很好地结合，允许配置成通过防火墙访问WebST服务器。WebST服务器控制端到端的安全，就像定义访问控制资源和数据一样。在这种配置中，防火墙通过阻止对传统应用的访问，并且加强在传统应用领域中IP协议层的保密性。 
(全文完)
作者单位：北京清华得实网络安全技术有限公司(100084)
(收稿日期：1998-08-10)
