将面向服务架构（SOA）视为发展方向的公司最为关注的内容之一就是安全。其原因部分来自人们的担心， 即当任何形式的网络都能获取IT应用程序和系统时，人们会本能地担心非正当人群也能访问程序和系统。互联网可能对全世界开放，从而更加剧了人们的忧虑。事实上，有一家负责处理银行之间付款的主要金融机构甚至拒绝设置企业网站，因为这可能向其用户表示，通过某些方法可以利用互联网访问该网站。

　　然而，SOA也以其它方式影响了人们对安全的关注。当然，它确实提出了刚才所讨论的注意事项，也就是说，开放应用程序成为可调用的SOA服务或者Web服务时存在危险，此时客户端应用程序可能无需经过必要的权限许可就能调用服务。这个问题必须加以解决，而此类安全问题也非常容易理解。公司都知道保护网络接入、认证用户以及运行访问控制列表。假设所采用的SOA基础架构具有实施安全粒度的权力，这就应该使得有效控制访问方式成为可能。同样地，保证数据在网络输送过程中的隐秘性是一个熟悉的难题，要达到一定的保护水平，可以采用各种加密标准。

　　但是，SOA带来了新的挑战；坦白地说，市场并没有很好地处理整个SOA安全事件。简单地看看与安全相关的Web服务 “标准”草案： WS-Security、WS-SecureConversation、WS-SecurityPolicy、WS-Trust和WS-Federation等等。人们都知道目前大多数Web服务标准尚未成熟、考虑欠佳，并不真正实用；但有趣的是，至少WS-Security目前已经相当成熟，这就证明了一个事实：总体说来，在Web服务的使用和SOA方面，安全是个大问题。SOA最有趣的安全含义或许在于现有安全域面临受感染的危险。问题产生于这样一个事实：SOA的总体原理是不再采用整体应用基础，而是集合各种表征个体商业操作系统的共享服务。因此，举例来说，不是每个应用程序都具有“创建客户”选项，而是只提供一个“创建客户”服务，所有应用程序可以根据需要调用。当然，这么做存在许多好处，这也是目前SOA如此流行的原因。维护应用程序的成本降低，系统变得更加敏捷和灵活，同时服务质量也得到了改善。但是从安全角度讲，将商业应用变为SOA服务的集合，而这些服务又能在采用SOA的系统中随处运行，这就产生了许多令人担忧的问题。

　　来考虑一个重要的商业应用程序，它拥有严格的相关安全需求。提供相应的安全需求水平也就意味着提供硬件加密、物理存取控制和先进的入侵检测系统等。但是，本例中安全域围绕应用程序本身而建。当应用程序实质上是一个整体，且在已知地点的特定计算机上运行时，这种方法就很实际。在这种情况下，实行强大的安全控制相对比较容易——就好像管理一个具有闭合边境的内陆国家的安全。现在考虑一下实施SOA策略产生的影响，此时这种商业应用程序分解成一些专门的代码，可以选择调用共享的SOA服务，如“创建客户”的例子所示。采用SOA的基本原理就是服务调用人员无需了解服务运行地点以及服务赖以运行的技术。

　　但是，这种灵活性可以攻击现有安全域的漏洞。一旦其它系统成为执行商业应用程序的一部分，之前处于安全等级的系统就会面临受感染的风险。如果 “创建用户”服务的访问控制一开始就不够严格，那么服务遭无意或者恶意篡改的风险更大，从而对这种重要商业应用程序的服务水平造成破坏。如果“创建用户”服务在不具备相同加密策略的计算机上运行，可能偶尔会遭遇一些敏感信息。

　　或许，这个问题中最令人担心的是这些变化可能会在我们不了解其中含义的情况下发生。最严重的安全问题在于员工不知道问题已经产生。答案与SOA控制和管理的繁琐问题紧密相关。

　　必须配置合适的程序，才能仔细考虑共享特殊SOA服务的意义。应结合策略管理工具和时间设计注册表，从而有可能避免使用安全规范不合理的服务。但是最后，有效控制安全的问题又返回到SOA持续成功的秘密——仔细准备，在引进、布置SOA策略时不要忽略工作方案和管理程序。

　　作者简介：
　　Steve Craggs是Lustratus Research Inc公司的创始人，曾就职于IBM，负责MQSeries中间件的全球行政主管。