SOA安全性解决方案

SOA安全性解决方案一个设计正确的SOA安全性解决方案可以解决SOA中的绝大部分安全性问题。解决方案本身可以包含多个分别解决SOA安全性中的某个特定方面的子解决方案。根据具体需求和现有的安全性基础架构，不同的企业需要不同的解决方案。SOAP消息监控基于SOAP侦听的SOA消息监控是构建高效SOA安全性解决方案基础的一种手段。SOAP侦听图1一个用于监控SOAP消息的SOAP拦截器用作这个SOA中的安全性基础。SOAP拦截器分析它监控的SOAP消息的标题头中包含的用户身份，并将其与保存在现有安全性基础架构中的名称相比较。结果就是对SOAP消息发送方和接收方进行了身份验证和授权。就是在web服务消费者和web服务之间来回传递的SOAP消息的路径中放入一个叫做“SOAP拦截器”的特殊软件块。因为其分类、监控、复制和转发包含大量数据的SOAP消息的能力，SOAP拦截器可以在SOA安全性方面发挥重大作用。如图7所示，一个SOA安全性解决方案“监视”着到达web服务的SOAP调用消息和对这些服务调用的响应。当它“看见”一条消息时，SOA安全性解决方案就会进行检查，以确保发出请求的实体是经过身份验证和授权可以使用web服务的。SOA安全性解决方案通过检查SOAP消息标题头中包含的数据实现了这一点。在大多数情况下，SOA安全性解决方案是对现有安全性解决方案的扩展，而现有安全性解决方案是在迁移到SOA之前为保护整个企业而部署的。因此，SOA安全性解决方案很可能不得不与现有安全性基础架构进行连接和通信。如图7所示，SOA中的用户身份验证和授权发生在基于企业的授权用户数据库检查用户证书的时候。侦听SOAP消息，并把消息标题头中列出的用户与保存在现有安全性基础架构中的用户进行比较，便可实现身份验证和授权。SAML和联邦身份验证当需要对企业外部的SOA用户进行身份验证和授权时，又会怎么样呢?SOA的开放性使得上述情况比以往任何时候都更可能出现。您可能会面临这样一个难题:在一组在现有安全性基础架构中没有记录的用户中，搞清楚每个用户的身份。为了解决保护第三方过程中固有的安全性问题，SOA安全性解决方案可以使用联邦身份验证。联邦身份验证是这样一个过程:通过这个过程，多方可以达成一致，使用一组给定的标准来对一组指定的用户进行身份验证。联邦身份验证方法的使用者可以创建一个联邦身份管理系统(FederatedIdentityManagementSystem)，这是一个已验证用户的库。SOA安全性解决方案可以通过检查联邦身份管理系统来对某个用户进行身份验证。换句话说，一些相互通信的系统的“联邦”，可以一致同意某个用户是合法的。在某些情况下，身份验证过程会导致在SOA安全性解决方案中创建安全断言标记语言(SecurityAssertionMarkupLanguage，SAML)断言，用于以一种可为用户调用的web服务所接受的方式表达用户的真实性。SAML是一种基于XML的标准，它为以标准方式描述安全性信息提供了一个框架。WS-Security是迄今为止得到认可的安全性标准集合的总称。许多SOA安全性解决方案都利用了这些新兴的安全性标准。如图8所示，SOA安全性解决方案可以侦听SOAP消息，然后使其经过一个对用户进行身份验证的过程。接下来，SOA安全性解决方案把SOAP消息传递给目的web服务，但是会附加上一个SAML断言。注意:SAML断言不依赖于联邦身份验证过程。图2要在SOA安全性中使用联邦身份验证，SOAP拦截器必须把传入的SOAP消息转发给安全性解决方案，该安全性解决方案再把SOAP消息标题头中包含的用户身份与联邦身份验证数据库中列出的用户进行匹配。如果匹配成功，SOA安全性解决方案就会创建一个安全“断言”，内容是用户已经在安全断言标记语言文档中通过了身份验证，该文档是在SOAP消息到达它要调用的web服务时附加给该SOAP消息的。应用程序代理一种非常有效的保护核心系统的方法是避免让任何人访问驻留平台的服务。可以通过为SOA中的web服务部署一个代理做到这一点。如图9所示，一个受保护的代理可以代表实际的web服务接收所有web服务请求，并对其做出响应，从而保护web服务免遭恶意的侵害。代理方法的另一个好处在于，它能够减轻企业安全性基础架构的负担。代理可以降低网络流量，具体方法是集中管理和缓存对web服务请求的身份验证和授权，而不是每次用户想调用web服务时，就在网络上使用大量消息对该用户进行身份验证和授权。代理还在消息中插入了身份验证和授权SAML断言，从而消除了实际web服务直接查询安全性系统的需要。契约管理在下一章中，我们将花大量时间来讲述这个主题，但是作为主要的SOA管理问题之一，契约管理同样在SOA安全性中起着举足轻重的作用。契约就是用于管理web服务使用情况的一组规则。例如，某个契约可能会规定，某个特定用户有权每天调用某个特定的web服务十次。而且在调用过程中，服务水平必须满足特定的参数，比如一秒钟的响应时间。在安全性方面，契约有助于确定SOA是否运行正常，或者由于违反安全性规则而误用。如图10所示，SOA拦截器把web服务请求和响应数据发送给SOA安全性解决方案，然后该SOA安全性解决方案再确定是否满足契约。如果某个安全性问题(比如DoS攻击)使web服务的速度降低到契约规定的服务水平以下，SOA安全性解决方案就会警告管理方有问题存在。当然，一次足够严重的攻击可以导致整个网络崩溃，但是安全性解决方案至少可以发出有问题存在的通知。图3通过处理SOAP消息流量，降低企业安全性基础架构的负担，并保护web服务免于误用，web服务代理有助于保护SOA。图4SOA安全性解决方案监控服务水平，并在安全性问题导致web服务降低到契约规定的服务水平以下时发出警告。证书、密钥和加密这些年来，IT领域先后出现了很多消息级的安全性技术，包括密码术。现在，也可以对SOA应用这些技术。这些过程，包括数字签名、证书、密钥和加密，都可用来保护SOA。在这里我声明一点:对于这4种安全性技术中的每一种，都可以写出一本甚至是好几本著作。请把本节看作是对与SOA相关的基于加密的安全性的一个概述。如果希望让SOA拥有健壮的安全性，保证web服务的用户都可以得到适当的身份验证，而未经身份验证的人无法读取在web服务及调用它们的应用程序之间往返的信息，那么无疑需要对SOA安全性解决方案应用功能强大的公钥/私钥加密工具。密钥是一个具有某种特殊的数学特性的大数(数百个数位)。尽管形式和大小各不相同，但密钥都有一个基本属性，即，可以与另一个密钥进行惟一关联。也就是说，当一个密钥遇到其惟一的匹配密钥时，双方都会说，“哦，就是你了，我惟一的匹配…不会再有其他的什么人了。”惟一的密钥对具有如下两个基本功能:因为它们是惟一的，所以它们是非常强大的身份验证工具。由于它们的数学特性，它们可用于创建经过不可测知的过程进行加密的惟一消息，这些消息只能被拥有惟一的匹配密钥对的用户所读取。下面讲述当两个用户想交换加密信息时的工作原理:用户A创建一个惟一的密钥对。然后，他在自己的系统中隐藏其中的一个密钥(“私钥”)，却把另一个密钥(“公钥”)发送到用户B可访问的网络上某处。然后，用户B使用公钥来加密他想要发送给用户A的信息。实际过程涉及到大量让我想一想就头痛的数学知识，但是基本上，公钥和消息数据是通过一个加密算法来运作的，该加密算法生成一个没有私钥不可能打开的加密文件。接下来，用户B把经过加密的消息发送给用户A，而用户A则使用最初隐藏的私钥来对加密数据进行解密。结果，用户A是世界上惟一一个能够解密这些加密数据的人，因为(只有)他拥有与用户B的公钥匹配的惟一私钥。现在，如果您像我一样爱刨根问底，您可能会想，但是用户A如何知道用户B真的是用户B呢?如果某位黑客侵入到用户B的系统中，并找到了他使用的公钥，那怎么办呢?为了回答这个有效性问题，人们使用了大量实体来确保特定用户的真实性，并授予他们证明其真实性的数字证书。这些实体叫做certificateauthority(认证机构，CA)。CA的一个著名例子是VeriSign，它提供用于电子商务事务的证书。使用密钥、加密和证书来实现保密性和身份验证的SOA安全性解决方案如图11所示。在我们的制造商例子中，供应商系统想发送一条SOAP消息给制造商的web服务。为了做到这一点，制造商必须首先发送一个公钥给CA。然后，供应商系统从CA请求一个证书。供应商收到的证书包含与制造商系统中存在的私钥相匹配的公钥。然后，供应商使用证书的公钥加密其消息，然后再把消息发送给制造商。然而，和前面的例子一样，SOA安全性解决方案侦听消息，并使用CA检查证书的有效性。这可以验证供应商的身份。只有在通过身份验证之后，加密后的SOAP消息才能被发送给制造商。SOAP消息到达之后，制造商就使用它的私钥对消息进行解密和处理。如果您觉得这听起来更多地像是在发送消息，那么您想得没错。就像在IT的其他领域中一样，SOA中的安全性会带来大量“开销”。在到达目的地之前，每条消息都必须经过好几个地方。证书文件可能会很大，从而给网络造成很大的负担，而且整个过程往往会降低性能。但是遗憾的是，它仍然是必不可少的。XML加密图5在安全性SOA中使用公钥/私钥加密和证书的步进式过程图字:1.制造商将公钥发送给认证机构，并将私钥隐藏在自己的域中2.供应商从认证机构请求包含制造商公钥的证书3.供应商向制造商发送使用公钥进行加密并包含证书的消息4.SOA安全性解决方案向认证机构发送证书，以便对供应商进行身份验证5.SOA安全性解决方案向制造商发送使用私钥进行加密的SOAP消息为了保留SOA的开放性，同时制订严格的消息级的安全性标准，您很可能想在加密时使用XML。当SOA安全性解决方案使用密钥对消息进行加密时，它会把消息转换为一段经过加密的XML。消息是XML格式的，但是内容并不可见，因为使用加密算法将其隐藏起来了。这样做的好处在于，接收消息的系统可以把它当作XML来接收、解密和处理，而不依赖于定制或专有的消息传递标准。这样我们就获得了安全性，同时系统仍然基于开放标准。数字签名数字签名是另一种消息级的安全性形式，它是证书、密钥和加密等安全性方法的变体。数字签名就是附加给SOAP消息的证明真实性的数学语句。数字签名是一个基于密钥的数(同样是一个非常大的数)，它对您的身份和消息内容进行惟一的处理，具体方法是对两组数据(密钥和消息)运行一个特殊的算法。举一个简单的例子，如果您的消息是“hello”而密钥是12345，算法将处理这两种输入——单词“hello”的数值和密钥数12345——并生成第三个数，这第三个数就是数字签名。当接收系统获得消息和附加的数字签名时，它可以使用密钥来验证以下内容:您是消息的真正创建者(身份验证)，SOAP消息在传输过程中没有改变。如果消息被改变了，那么惟一的数字签名将不再与密钥和用于创建密钥的原始消息相匹配。数字签名和先前描述的完整加密过程之间的区别在于，如果使用数字签名，不必对整条消息进行加密。因此，系统的性能得到了提升。只要您不介意别人可以看到您的纯文本格式的消息，那么数字签名就可以为SOA提供高度的数据安全性和完整性。签名可以是一个不可否认性(nonrepudiation)组成部分，该特性是一个需要在SOA环境中解决的安全性重要方面。不可否认性是指一个组织的一种能力:验证发生了特定的处理，并从而不给发送方提供否定进行了处理的机会。例如，如果您针对某种商品下了一份电子订单，而该订单并没有以某种方式(比如使用数字签名)进行验证，那么对方就有可能否认收到该订单。如果批发商的系统提供不可否认性，那么批发商就可以肯定该订单已经送达。重放攻击保护和审计最后，SOA安全性解决方案应该提供一种用于跟踪SOAP请求的工具，从而降低DoS攻击带来损害的可能性。通常，跟踪特性将监控SOAP消息的发送方及其创建时间。在某些情况下，SOA安全性解决方案将使用一个惟一的识别码给SOAP消息打上印记。如果解决方案被设置