安全性是让我们远离面向服务架构的理由。虽然完全成熟的面向服务架构安全还没有来临，但目前有30%的企业使用面向服务架构来保持与用户及合作伙伴的外部互联。对于使用SOAP的标准网络服务来说，WS-Security作为基础性标准获得了临界物质。另一方面，先进的面向服务架构安全涉及合作伙伴之间的联合，认可和多重服务执行标准范围内的用户身份复制，目前它还处在发展的初期阶段。为了从目前安全状态过渡到未来的高级面向服务架构安全，需要考虑的事项 包括：建立可以推动面向服务架构发展的重复设计流程来满足目前和未来的安全需求，新兴的行业标准，另外还要和面向服务架构安全的功能以及定制安全集成的可 能性结合在一起。

　　作为设计面向服务架构安全的基础，保证面向服务架构需求和反馈安全的最简单方法就是把他们放置在虚拟私人网络中。对于外部面向服务架构安全的最 常用方法是使用双向安全套接协议层(简称SSL)，双向服务套接协议层：1)可以允许每个互相联络的合作伙伴相互识别，2)为安全设置门槛：黑客甚至无法 连接上以面向服务架构为基础的服务，除非他们从服务用户处窃取了证书和密钥。虽然虚拟个人网络建立起来相对容易，但是以虚拟个人网络为基础的面向服务架构 安全比较粗糙，也无法支持高级功能，比如说在服务执行过程中对多层套接协议层内的用户身份进行复制；多重安全域的协调和联合；以及严格的认可。目前证书的 管理也是一种管理上的负担。

　　虽然面向服务架构安全的其他主要选择还包括Java或。NET应用软件平台中现有的面向服务架构安全特性和面向服务架构专业产品中包含的面向服务架构安全，这些产品有企业服务总线，面向服务和网络服务管理解决方案，面向服务架构安全服务器或者面向服务架构应用工具。应用工具能为面向服务架构安全 提供最简单也最专业的解决方案，但是在用户建立完整的面向服务架构平台时要考虑这些面向服务架构产品就显得太过复杂。

　　对于应用软件服务器和面向服务架构专业产品中出现的新特性，简单的面向服务架构安全解决方案更加引人瞩目。从历史经验来看，企业用户在应对高级应用软件安全需求的困难时通常表现的不够积极。随着面向服务架构安全执行的成熟和安全联盟体系架构的拓宽，这些解决方案在执行高级安全需求方面会变得越来 越简单。许多企业用户会发现高级面向服务架构安全成为一种需要，特别是逐渐增长的数据隐私和其他法规需求。虽然这很重要，但在你开始执行简单的面向服务架 构安全解决方案时，随着企业需求和面向服务架构安全的成熟，我们需要保持开放的心态和开发更加深入的安全功能。

　　Forrester咨询公司强烈推荐你设计一个不需要应用软件研发人员来参与安全代码编写的解决方案。虽然有着强大的指导方针和代码审核，但应用软件代码内置的安全在保持安全的持续性和应用软件安全未来的灵活性方面都存在风险隐患。需要注意的是让研发人员不要参与安全代码编写并不意味着培训应用 软件研发人员使用安全代码的需求就没有了。实际上安全代码是应用软件安全实践中一个独立的领域，它要保证应用软件故障不会导致安全漏洞。

　　行业标准，产品，集成和安全战略的框架的正确结合是一个重复的过程：

　　1. 确认你的安全需求。对你的安全需求进行评估。这个过程为设计面向服务架构安全战略和解决方案奠定了基础。企业需求要和面向服务架构解决方案的主要设计焦点 相一致。Forrester使用的是一个围绕服务客户，需求反应，服务提供商和安全环境的模型。当你继续面向服务架构设计的重复流程时，你可能要重新考虑 所选的需求，了解更多有关标准，产品和企业满足面向服务架构需求方面的能力的信息。

　　2.判断面向服务架构安全标准的使用情况。你的面向服务架构安全需求为决定面向服务架构安全标准的范围奠定了基础(这些标准可能都要满足你的需 求)。在选择你要使用的实际标准时，你必须了解你基础架构中的产品(包括现有的产品以及将来你可能为面向服务架构采购的产品)能支持那种标准。核心的标准 包括WS-Security, WS-I Basic Security Profile, XML Encryption和XML Signature。高级标准包括WS-Trust, WS-SecurityPolicy, WS-Federation, XACML和WS-SecureConversation。

　　3. 选择能为你提供核心面向服务架构功能的产品。面向服务架构安全解决方案中的许多功能，诸如使用WS-Security抬头进行认证的功能在不同产品分类的多种产品类型中都可以实现。你设计的流程必须考虑到每种选择，选择的产品要为面向服务架构安全提供核心功能。对你的面向服务架构解决方案有用的主要产品分类包括：面向服务架构应用工具，面向服务架构管理解决方案，企业服务总线，面向服务架构安全服务器，应用软件服务器，安全令牌服务器，授权管理服务器和识 别及访问管理解决方案。

　　4.将产品结合起来共同发挥作用。你可能有各种产品在执行面向服务架构安全功能，这些产品必须能结合在一起共同发挥作用。这种结合可能要通过产品配置选择来完成，但是可能需要使用产品编程界面来创建集成组件。

　　5.填充框架中的漏洞。在产品集成完成后，为应用软件研发人员建立助手框架是很用的，这样他们就不必在以面向服务架构为基础的应用软件内编写安全代码。

　　Forrester 推荐这种重复流程有两个原因。首先并非所有的应用软件都需要满足所有的安全需求：最初的应用软件可能在构建面向服务架构安全解决方案时要求不高，后来的应用软件需要你用额外的特性去补充你的解决方案。其次每次你在重复这些流程时，你都会了解更多有关构建最有效的面向服务架构安全解决方案的知识。

　　面向服务架构的领先者仍然在积极的探索着这个领域的最新发展。对一些企业来说，这可能是一种具有高价值的业务方式。这些企业要证明构建高级面向服务架构安全解决方案的价值。这些领先者将推动行业标准的稳固，帮助厂商让他们的产品更加成熟。如果你的企业是迫切需要高级面向服务架构安全的一员，有许 多种的产品和标准可以选择，但是需要警惕的是：你应该多花一些时间来为建模，产品调试，实施和扩展测试进行规划。