1.1跨技术、身份和管理边界的身份转换和传播

　　一套完整的业务流程可能由不同厂商的基于异构平台的多种服务组合而成，每个服务都具有各自独立的安全域。这些安全域可能由不同企业的不同部门负责管理和维护，这要求必须在SOA架构范围内建立统一的信任体系，使得请求者(人或程序)能够在服务间自由流动，系统能够自动地将请求者身份随着边界的不同而转换。

　　1.2与合作伙伴建立信任

　　借助Web服务的强大能力，企业往往需要与合作伙伴建立紧密地服务和数据交换，发挥各自的优势来共同组成一个完整的一站式服务。比如一个旅行服务系统，机票订购由专门的机票代理公司提供，旅游线路设计和行程服务则由旅行社负责，而食宿则由当地旅店提供。为了保证客户信息能够在多个系统安全完整地流动，并及时地反映客户实时的旅行状态，必须在企业与合作伙伴之间建立可靠、安全的信任关系。

　　1.3跨多个应用程序统一、重用和共享公共安全性

　　SOA具备来自异构系统的多样性，要求建立一个统一的安全基础设施和标准。每个应用系统可以使用共享安全组件，比如CA认证中心、信道加密方式和SOA安全网关等。此外，统一的安全标准遵从对于SOA整体安全性而言至关重要。

　　1.4政府和行业规范要求的可追究性和可跟踪性

　　在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护，同时可能还需要用安全的方式在一定时期内保存敏感信息。在启用验证、审核和许可之前，必须保证消息源的完整性(如通过公证服务)。消息的完整性和保密性可以通过对敏感信息进行加密和数字签名来实现。完整的SOA设计必须不但涵盖消息级和传输级安全性，而且还要满足保存保护的内容以遵守政府规章制度和业界最佳实践的需要。企业需要对其提供的服务进行担保，确保服务仅执行其公开申明的操作，同时有义务为用户提供足够的安全保障。因此，企业必须保存系统操作记录，以此来跟踪其用户或消息，也就是说企业必须具有很强的服务审计能力。

　　1.5SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互

　　身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。传统的安全防御对象主要是针对人，而SOA更多地强调了机器与机器的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁(大多数情况下，这些请求被人恶意利用和操纵)将是SOA安全防御的一项重要课题。

　　2SOA面临的安全挑战

　　2.1XML通信协议消耗大量带宽，引发安全问题

　　与传统的二进制通信协议相比，XML最高可以消耗高达50倍的带宽，这不仅会导致交互系统性能下降，而且会为分布式拒绝服务攻击提供可趁之机。因此，未经优化的XML通信将导致严重的安全问题。

　　由于SOA架构的开放性本质，您很难控制SOA中未知的第三方，比如您的合作伙伴，它们可以间接访问未受保护的Web服务。因此，未受保护的Web服务很容易超负荷运转，如果没有访问控制，未受保护的Web服务很容易被来自黑客的大量SOAP消息所淹没，结果可能导致拒绝式攻击从而损害系统的正常功能。

　　为了解决这类问题，市场上已出现了专门的XML加速器。利用基于64位平台架构的语法分析器，该设备可以用来加速XMLSOAP的解析、XML模式的确认、XPath的处理以及XSLT的功能转换。据公开的产品测试报告称，这种XML加速器能够达到每秒处理1万多条XML消息的能力。

　　2.2基于XML的服务间通信易受到监听和窃取

　　由于XML的纯文本的本质，未经保护的XML在互联网传输过程中很容易被监听和窃取。为了保障基于XML的通信安全，我们需要从传输层和消息层两个层面进行保护。通过传输安全，可以保证只允许授权用户可以访问基于XML的Web服务，目前可扩展访问控制标记语言(ExtensibleAccessControlMarkupLanguage，XACML)和Web服务策略(WS-Policy)是专门用来解决这个问题的两个标准;通过消息安全，可以保证Web服务环境中交换的XML消息的完整性和保密性，Web服务安全(WebServiceSecurity，WSS)和安全声明标记语言(SecurityAssertionMarkupLanguage，SAML)则用来解决这方面的问题。

原文