JMS与安全

摘要:许多JMS提供商已将它们的产品应用于众多企业之中,需要应用集成的许多企业也在考虑采用何种消息中间件 厂商的产品,这些产品无疑将会支持JMS。

JMS与安全

冯键编译
JMS(Java Messaging Service)是近年来广受赞誉的一个消息传送服务规范。它的初衷是在已有的各种私有消息中间件产品之上提供统一的应用编程接口(API)。目前,它已经成为实现企业应用松散耦和集成的开放标准。许多JMS提供商已将它们的产品应用于众多企业之中,需要应用集成的许多企业也在考虑采用何种消息中间件厂商的产品,这些产品无疑将会支持JMS。

JMS规范为发布/订阅和基于队列的消息传送机制定义了丰富详细的接口,但是,JMS对以下问题没有给出明确定义:

1. 如何传送消息

2. 如何集群消息服务器

3. 如何支持高效消息传送和容错机制

4. 安全

这些问题留给JMS提供商来定义和实现,因而,对安全问题的实现,不同JMS提供商可能有完全不同的方案。基于这种考虑,充分理解以下两点是非常关键的:

(1) JMS部署的整体企业应用环境;

(2) JMS提供商的产品是否能满足你的安全需要。

1. 企业应用的环境

信息安全对大多应用而言都是需要严重关注的问题,而且,安全的重要性越来越突出。基于Internet的电子商务应用更加使用户对安全的威胁感到焦虑。不同的安全威胁需要不同的技术来解决,这些威胁有如下所列:

机密信息非法窃取:消息中间件是企业信息传送的通道,企业的敏感数据也通过它传送。这种情况下,要确保非授权用户不能接触企业的敏感数据。如企业不同部门之间传送的新产品数据,是企业的敏感信息,企业非常关心这些数据是否会被它的竞争对手非法窃取。

信息的非法篡改: 在消息传送过程中是不允许对消息内容篡改的,例如,银行 间传送的某一账户转账消息,如果这一事务的细节被他人篡改,都会对银行用户或银行造成不可预计的损失。

受保护资源的盗用:消息代理(broker)和它的目的地(消息主题或队列)是非常重要的企业资源,需要保护它们不被非法用户随意使用。例如,如果让某一恶意用户盗用broker来发布股票价格变动的消息,那么,此虚假消息将会造成灾难性的后果!

在这篇文章中,主要讨论解决这些问题的技术和JMS产品的特性。

2. 身份验证

在讨论JMS安全之前,需要为每个负责人(如用户)建立身份标识。JMS客户端与broker交互来验证自身身份,broker具有访问保存有效用户信息资源的权限。最简单的使用方式是验证用户名和口令,较复杂的方法是使用数字证书。证书是数字文档,它描述用户(或应用、服务)的标识和公用密匙(即公钥)。数字证书由一个信任的认证中心(CA)来颁发,CA可以是本地的,也可是第三方如VeriSign。证书最广泛应用的标准是国际通信联盟的X.509,除支持X.509之外,还要保证你有工具来管理企业应用环境中的用户和它们的权限。

用户常会被分配角色和相应的安全权限,简化了安全策略的管理。同样重要的是,broker也能通过与client的交互验证自身,这阻止了一个恶意系统声称为有效broker,并与未知客户端暗中交互通信。

需要说明的是,企业的信息安全架构往往是在部署JMS之间就有的。因而,如何能实现安全架构与消息通信平台的无缝集成问题,显得非常重要。对JMS的身份验证而言,具有外部集成能力或者即插即用的架构是关键。例如,可使用LDAP(Lightweight Directory Access Protocol)保存用户的数字证书,JMS提供商的产品应能实现与LDAP的集成,而不是坚持将证书引入自身的系统。

3. 授权

授权是一个对特定用户指定特定权限的过程,初级系统可实现JMS API层次上的控制,等价于“谁能调用什么操作”。但是,这是一种非常粗粒度的控制,在大多环境中并不适用。

非常有用的授权策略是将broker与JMS的目的地(主题和队列)结合起来。创建一个访问控制列表(ACL)意味着是对某用户主体安全策略的定义和描述,即他能为某一主题或队列发布消息,或者从某一主题或队列中接收消息。另外,你需要能描述对broker和它的JMS目的地管理权限的优先级。

由于某一broker可能管理着成千的主题或队列,为每一个主题和队列维护一个ACL将会增加大量的管理负担,所以,支持层次化管理主题或队列就变得非常重要。例如,一个在线的零售商,其主题层次如下:

Amazon.orders.electronics.cameras.sharp

 

 


 

 

JMS客户端能发布或订阅此主题树上不同点代表的主题。ACL也能应用于主题树上的不同点,通配符主题也被支持。例如,对Amazon.#,ACL定义所有角色都没有发布和订阅的权限,而将定义customer对Amazon.orders.#有发布消息的权限,则此权限沿着主题树向下传播,customer自然具有对Amazon.orders.electronics.cameras.sharp主题的发布权限,这样,就大大减少了ACL的定义数目,若另一ACL定义camara_distributor角色具有对Amazon.orders.electronics.camaras.*的订阅权限,则camara_distributor就能接收到customer发布的订单消息。

4.数据机密性

对于企业而言,确保机密数据不被非法用户访问是非常关键的,为了解决此问题,您需要应用一些加密算法,但需要说明,JMS提供商对数据加密的实现方法并不等同,以下是选择加密方案时需要考虑的方面:

4.1公钥还是私钥?

公钥加密使用两个钥匙:仅对拥有者公开的私钥和对所有希望与私钥拥有者通信的人公开的公钥。公钥加密是一种非对称加密技术,因为加密使用的钥匙不同于解密使用的钥匙。公钥解密技术的不足之处在于非对称加密算法需要占用CPU较多的计算时间,会影响JMS系统的运行性能。

替代方法是发送者和接收者都共享一把钥匙来加密和解密,这种对称钥匙加密算法比非对称算法在速度上至少要快100到1000倍。性能改进了,但随之而来的是如何建立发送者和接收者共享密钥的问题,通过配置方法或在软件 中硬编码的方法都不安全,而应将二者交互的过程认为是握手协议的一部分,为此过程建立密钥。

当向众多的消息订阅者发布时,使用包含加密消息和共享密钥的数字信封更为有效,此密钥自身使用公钥加密,接收者通过私钥解密来获得此密匙。公钥加密的非对称技术和私钥加密的对称技术结合,不仅提高了企业应用环境的安全等级,同时也不影响整体系统的运行性能。

4.2什么密码更强壮?

你应为JMS解决方案提供一套的密码,使你更容易选择,但这需要在加密强度和性能之间进行折衷。一般加密采用56位的数据加密标准(DES),但此密码可能会被攻击者采用特定设备并花费1百万美金的前提下39小时内攻破;更强状的加密采用168位的DES3,它将超出攻击者的能力,它需要花费许多年才有可能会被攻破。

4.3加密通道或者消息加密?

JMS规范没有讨论采用什么协议用来传送消息,因而,在实现上会有许多不同,如采用TCP、UDP、HTTP、IIOP、RMI等。从安全考虑,通常采用SSL来提供加密数据的传送通道(channel),这种技术会使broker和client通信的每一部分都被加密,如消息、二者之间的确认报文、协议所需的额外数据等等。

如果你仅需要对部分消息体加密的化,那么,采用SSL技术将是不恰当的,它可能会使整个系统做许多大量额外的工作。替代方法是对消息层次进行加密,而使用非加密协议,所有或部分消息在被传送之前首先被加密。选择每个消息是否加密的方法是可能的,如价格变动消息不需加密就可发布到某一目的地,但是,到同一目的地的购买请求消息却被加密,处理此消息队列时会显著影响系统的性能。

5.消息的完整性

即使消息如4.3节所述被加密处理,但是,接收者并不能确保这些消息是否在传输过程中被篡改过。为了保证这一点,需要定义一个hash函数,以消息为输入,产生一个固定长度的摘要(digest),类似于校验和。这种方法的缺点是存在着hash冲突,hash函数可能为不同消息产生相同的摘要值。一个恶意的侵入者可改变消息内容为其他值,此值被hash后与原有消息的摘要相同。摘要值越大,消息完整性越能被保证,MD5能产生128位的摘要,SHA-1能产生160位的值。

6.部署位置和安全

JMS部署的方案也可能会对你的安全需求产生重大影响。部署JMS系统跨越防火墙 实现Internet消息传送会带来其它 问题。防火墙在概念上被认为是确保网络安全 的独立实体,但是,企业防火墙实际上是代理服务器 (proxy Server),路由器 、防火墙软件包、甚至是中介网络(常称为DMZ)等构成的复杂体。通过企业防火墙传送消息,需要JMS产品支持Internet Messaging,JMS产品需要支持以下特征:

防火墙友好的协议

模块分布

强壮的broker

使用代理

6.1防火墙友好的协议

可能是防火墙软件的限制或是系统管理员的偏好,你可能发现JMS软件的本地协议是被禁止穿越防火墙的,需要其它协议的支持,防火墙最友好的协议是HTTP,它可用做JMS传输或者利用HTTP头建立HTTP通道来传送TCP或其它包通过防火墙。为了确保安全,这两种方法的任一种都能用做通道加密或消息加密,HTTPS用于通道加密是必要的,它是在SSL上实现HTTP传输。

一些HTTP/1.0的实现可能不包含保持连接的头信息(keep-alive connection),而保持连接的头信息会允许网络连接一直保持,因而会有更好的性能。HTTP/1.1规范支持保持连接的头信息,因而,当性能是考虑因素时,建议使用HTTP/1.1。

6.2模块分布

当前的防火墙架构关键特征是:应用部件的分布化使为不同模块提供隔离的保护措施。它能保证当某一模块失效后整个系统不会瘫痪。对部署在DMZ的JMS实现而言,这意味着将broker与它永久消息存储的分离,对broker的安全破坏不会影响永久消息存储模块的安全。

6.3强壮的broker

如果broker部署在DMZ环境,它的潜在攻击是相当高的,因而,需要密切关注它的模块。如broker有一个配置文件,它包含了关键的密码和安装参数,那么,此配置文件需要加密,你必须能在加密的配置文件下启动运行broker。

6.4使用代理

用户可能认为在DMZ环境中部署JMS是不合适的,broker需部署在内部网络。此种情况下,broker与外部client端的连接可通过使用逆向的代理服务器来获得,这些代理服务器部署在DMZ环境中。这中部署方案需要确保你的JMS已经测试过,并被证明能使用这些代理服务器。

7.总结

并不是所有的JMS实现都提供相同或支持高级的安全策略,这是由JMS提供商来决定的。但是,在企业应用集成环境中部署JMS方案时,你需要思考如下问题:

集成方案需要什么层次的安全保证?

client和broker如何部署?

加密的强度到底是怎样的?

如何平衡安全与性能的矛盾?什么方案是现实可接受的?

企业信息资源受何种威胁?哪种威胁最大?

说明:本文译自《eAI Journal》2002年7月的《Security and JMS》,作者:Steve Trythall, 任Sonic Software 公司的产品管理总监。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值