许多企业正在开始投向SOA的怀抱，使之作为一个增加应用软件灵活性以及整合更易于管理，更低开发成本，更统一的技术体系的方案。SOA的吸引力在于：它把公司的IT基础设施分解成服务，每一个服务实现了一个可供用户或者服务消费的商业过程。

　　举个例子，某个服务可能会暴露添加一个新雇员到雇员工资名单和福利系统中的功能。为了使服务在多种环境中可用，也为了降低成本和增加处理的一致性，每一个服务都提供一个契约（contract）来描述它如何被使用及包含的功能。

　　但是，SOA方法和今天企业使用的传统安全方法截然不同。SOA服务的“混合和匹配”（mix-and-match）的性质，以及它使用消息作为SOA的复合应用程序的协调机制，使得企业无法建立明确边界和安全屏障。非常特别的一点是，SOA的灵活性反而也增加安全风险。

　　服务契约（Service contract）会暴露你的宝藏

　　让我们来考察一下典型的服务是怎样在典型的SOA基础设施上执行的：用户和服务的通信依赖于彼此间通过ESB（企业服务总线）传递的消息。ESB作为企业的消息管道，需要理解可用的服务，它们的语义和怎样在点和点之间获取一个应用程序的消息。每一个在ESB上的服务必须使用ESB的标准消息传递协议（通常是SOAP）来寻址。

　　为了使服务易于使用，每一个服务必须有一个方法来描述自身以及服务是怎样被使用的。这个描述被称为服务契约（Service contract），并通常通过WSDL（网络服务描述语言）来描述。很少有像SOA这样严格执行交互契约的开发方法。为了简化收集和发现新的契约，在许多SOA构架中，每一个服务提供给客户询问和找回契约的方法。这个找回契约的方法常常是标准化的，不是由应用程序框架供应商操作，就是由SOA从业者自己操作。

　　标准化的契约和契约找回方法使SOA系统更加容易被攻击者发现，因此这些都是SOA潜藏着的新的安全风险。

　　虽然这种免费提供的契约非常有助于开发商为整个企业构建新的服务和重用现有的服务，但不幸的是，有利于开发商的元素同样也有利于想要了解企业及其服务的攻击者。攻击者可以收集这些契约，并利用它们轻易地创建一个企业内部的“藏宝图”。为了确定高价值目标，攻击者可以使用这种“地图”，并审查那些认证薄弱的、或者负责高价值服务（如安全管理）的契约。

　　SOA从业者可以通过在认证或离线分配时禁用匿名发布服务契约来禁止攻击者建立这样一张地图。虽然这是一个很实在的安全决定，但它并不适用于所有服务和所有企业。这是因为限制契约的分配会使得合法用户更难发现服务，还使得开发工具无缝引入契约变得更加不可能。

　　消息层安全反而有助于攻击者找到入侵的途径

　　具有讽刺意味的是，消息层安全的使用和另一个SOA的漏洞相关。消息层安全使开发人员能够挑选出消息中需要签署或加密的部分。为了支持寻址和ESB上的路由，邮件的目的地信息往往被排除在该邮件的加密部分。选择性加密/签名的方式不同于其他点到点或传输层安全协议，诸如保护整个连接的SSL。

　　由于有了消息层安全，攻击者通过被动地监控网络可以获取在发送者和接受者之间传递的关于应用层消息的深入信息。有选择地应用安全增加了复杂性，开发人员或管理员对特定消息实施关键安全保护失败的可能性也会增加。

　　在某些环境下，服务信息的暴露可能不会存在高风险，但也不能掉以轻心。攻击者获得的信息越多，攻击就越有具有针对性。在SOA以前，通过使用广泛的协议来实现分离的系统还具有一定的模糊性，在这样一个环境中攻击者很难发现和理解所有的系统，然而SOA却消除了这一障碍，反而大大提高了攻击者执行探测的能力。

　　中介信息的使用增加了潜在的攻击目标数

　　SOA改变单一软件为自我包含的软件的情况，可以根据需要精心配制相应的组件，这使系统变得更加动态。为了协调这些组件，SOA推荐当消息在ESB上传送时使用消息路由器和服务注册。为了消息路由器能够操作消息，要么让部分的消息不能加密，要么邮件路由器必须能够解密关键信息。这种方法意味着你不能在服务提供商和服务客户之间使用传输层安全协议。同时它还意味着，黑客可以利用这些管理信息和协调中介机构来对终端发起攻击。

　　乍一看，你可能认为在“以明码传递路由信息”和“在SSL一类的协议报文中以明码表示IP和TCP头”并没有多大的不同。但这实际上却很不相同：作为中介的SSL在保证整个信息已签名和加密的条件下，只提供关于消息流内容很少的信息，并且不允许中介进行“转发信息”以外的操作。但是作为中介的SOA通常更进一步，而且往往在签名还未失效的情况下就对信息本身进行了修改。在攻击者试图改变SOA环境时，这种操纵窗口给攻击者提供了一个可用的工具。

　　的确，在消息安全上，WS-Security可以提供类似SSL的保障，但WS-Security标准的灵活性和复杂性却增加了“消息中的敏感信息不能被恰当加密和完整保护”的风险。

　　同样，服务注册表是有风险的中介机构，SOA方法依赖它来工作的。它们类似于DNS提供服务的方式，当一个服务消费者希望找到适当的服务供应商，消费者从服务注册表找到该服务提供者的当前地址。在许多部署方式中，服务注册表可以由管理员或由提供者动态地更新。这为SOA可以更容易的重新配置，因为服务的地址会随着服务地址而相应的改变。

　　但是，正是配置控制功能使服务注册表成为了对攻击者来说有吸引力的目标。例如，黑客可以操纵注册表返回地址，让其指向被黑客攻击的服务主机的地址。如果攻击者锁定了正确的服务（如安全服务），攻击者可以给尝试使用安全服务的客户伪造客户响应。在一个客户端的部署中，已证明能够劫持安全服务，并完全批准所有的访问请求。

　　部署一个安全、动态的SOA，开发者和架构者必须考虑系统的哪些部分需要动态处理、哪些部分需要保持静态。使的重配置生效的 SOA的配置元素 必须再次审查，从而使得攻击者无法全面了解系统的信息。

　　在ESB内部和ESB直接的通讯为攻击者提供了新的切入点

　　任何重大SOA部署的中心都是一个能够处理消息路由、并提供所需基本服务的ESB。通常情况下，企业会使用数个通过网桥连接的ESB。

　　不管你有一个还是多个ESB，只要是使用了ESB就无法安装传统的“软”防火墙，这使ESB成为一个攻击目标——特别当它是关键服务（如记录和认证）的主机时。“软”防火墙是当连接方没有使用相同的协议时对通信所采取人为限制。因此，即使攻击者登录了某个系统，协议的不兼容将限制其攻击范围。例如，攻占了Web服务器的攻击者可能无法到达大型主机，因为大型主机使用令牌网协议，而在TCP / IP网上的Web服务器并没有把二者连接起来。

　　ESB的目的是为了消除通信障碍，这意味着如果部署了SOA攻击者可以很容易的从Web服务器到达大型主机。同样，SOA再次有利于攻击。

　　ESB高连通性使得内部、外部和ESB服务的部署更加需要一个坚实的应用程序安全措施。在把那些防护脆弱的传统大型机连接到ESB上时，需要审查其安全属性，从而确保该系统能够在充满威胁的环境中运行。你需要站在攻击者的角度，考查在你的SOA中所实现的全新通讯环境，并对攻击可能从一个被攻克的服务器中蔓延开来的距离进行建模，然后再制定出一个缓解方案，从而控制和制止攻击的蔓延。

　　部署类似于SOA这样灵活的系统是一种真正的安全挑战，但如果你从一开始就采取正确的步骤，保证系统的安全性也不是一件不可能的事情。