SOA面临安全挑战
当前，面向服务的架构（SOA）是一种很流行的技术，其原理采用松耦合服务模式，通过标准化的接口来联系各种形式的服务，无论服务置于何地，均能通过一种便捷而统一的方式实现相关功能，这对信息资源的二次利用和服务模式的二次重整具有极大的作用。
在具体技术上，SOA是通过XML/SOAP等几种系列的标准化技术来实现的。但是围绕SOA的安全问题一直没有彻底解决的方法，其原因在于：
第一，不同信任域的信任关系的转移和认同。业务流程可能由不同厂商的基于异构平台的多种服务组合而成，每个服务都具有各自独立的安全域。这些安全域可能由不同企业的不同部门负责管理和维护，这要求必须在SOA架构范围内建立统一的信任体系，然而这种努力确实难度极大的。
第二，不同应用服务统一、重用和共享的安全性。SOA具备来自异构系统的多样性，要求建立一个统一的安全基础设施和标准。但是目前情况是不同的应用系统有不同的认证、授权模式，协调和统一的难度大。
第三，SOA强调设备与设备的交互，而大多数IT安全性都是基于人与设备的交互。传统的安全防御对象主要是针对人，而SOA更多地强调了设备与设备的交互，即所谓服务的互操作性，如何应对来自合作伙伴或第三方服务交互请求的威胁（大多数情况下，这些请求被人恶意利用和操纵），将是SOA安全防御的一项重要课题。身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的。未授权用户可以非常轻松地访问Web服务，而Web服务往往不具备跟踪谁在使用它们或者谁被允许使用它们的固有毛病。
另外，SOA整套架构在应用层与表示层的隔离上做得不完美，这会导致未来阶段，新的代理程序很容易寻找和利用SOA的安全漏洞；僵尸网络工具准确找到应用中的安全漏洞的概率很大，而且准确性比现在的工具高得多。
新的安全标准
为了应对上述问题，国际OASIS组织制定了一系列技术标准，这些标准包括：
WS-Security：描述如何将XML加密（XML Encryption）和XML签名（XML Signature）应用于SOAP文档或信息。
WS-SecurityPolicy：对哪些人被允许访问某个服务以及访问方式做出规定，并对认证方式的类型和/或所需要的加密等级做出限制。他是Web服务策略（WS-Policy）的子集，以更为通用的方式对服务的能力和限制进行描述。
WS-SecureConversation：按照WS-Security标准，实施WS-SecurityPolicy中所描述的策略的方法。此标准于2007年3月通过审批，Actional公司、BEA Systems、思科公司、CA公司、Layer7 Networks、Oracle、Reactivity公司、RSA等其他厂商也都表示支持此标准。
WS-Trust：应用WS-Security标准传输密码、数字证书以及安全性断言标记语言（SAML）断言等安全标识。XML密钥管理规范XKMS和SAML有部分相同之处。
WS-Federation：根据WS-SecurityPolicy中描述的服务规则，应用WS-Trust中提到的被传输的安全标识，通过Web服务的认证。相较SAML，他的主要优势在于，Windows支持这一标准。
安全解决之道
目前解决SOA的安全问题主要包括以下三种方法。
第一，在服务模块前通过SOAP解析器来解决安全问题。著名的Hugh Taylor， Eric Pulier在《松散耦合的SOA环境中的安全性》一文中提到了这种方法。
第二，整合信任源。不同的信任源有不同的信任基础，比如通过用户名＋口令、证书、生物识别，需要整合上述信任基础，统一到一个完整的信任库中，通过Security Assertion标签完成信任基础的定义并明确导向。基于目前的现状，建议整合到CA平台上，目前的问题是CA的认证比较复杂，规模和流量对SOA的影响颇大，面向政府的SOA架构可能没有太多问题，但是对于大型系统（如客票系统）可能就有问题。
第三，使用专用安全产品。主要包括：SOA 安全网关。网关为进入企业的XML流量提供了一个代理，并运用安全策略来确保某种形式的请求与验证。主要作用是对SOAP进行解析，如果SOAP中涉及encrypt标签，需指向专门的SOAP加解密设备来完成；SOA安全平台。主要提供验证和授权方面的安全支撑；SOA反病毒邮件网关。目前能够针对SOAP病毒的反病毒邮件网关还比较少，需要增加特定的SOAP协议支持才能对SOAP病毒进行防范。
另外，在具体的SOA安全服务实施过程中，需要注意：第一，分析SOA中对信息安全性要求。包括了信息机密性、完整性和可用性需求，通过制定表格把信息敏感性确定下来；第二，具体描述SOA中的标签。通过信息的敏感性分别定义不同的SOAP安全标签，如
【编辑推荐】
