证书、密钥和加密

　　这些年来，IT领域先后出现了很多消息级的安全性技术，包括密码术。现在，也可以对SOA应用这些技术。这些过程，包括数字签名、证书、密钥和加密，都可用来保护SOA。在这里我声明一点：对于这4种安全性技术中的每一种，都可以写出一本甚至是好几本著作。请把本节看作是对与SOA相关的基于加密的安全性的一个概述。

　　如果希望让SOA拥有健壮的安全性，保证web服务的用户都可以得到适当的身份验证，而未经身份验证的人无法读取在web服务及调用它们的应用程序之间往返的信息，那么无疑需要对SOA安全性解决方案应用功能强大的公钥/私钥加密工具。密钥是一个具有某种特殊的数学特性的大数（数百个数位）。尽管形式和大小各不相同，但密钥都有一个基本属性，即，可以与另一个密钥进行惟一关联。也就是说，当一个密钥遇到其惟一的匹配密钥时，双方都会说，“哦，就是你了，我惟一的匹配…不会再有其他的什么人了。”

　　惟一的密钥对具有如下两个基本功能：

　　因为它们是惟一的，所以它们是非常强大的身份验证工具。

　　由于它们的数学特性，它们可用于创建经过不可测知的过程进行加密的惟一消息，这些消息只能被拥有惟一的匹配密钥对的用户所读取。

　　下面讲述当两个用户想交换加密信息时的工作原理：用户A创建一个惟一的密钥对。然后，他在自己的系统中隐藏其中的一个密钥（“私钥”），却把另一个密钥（“公钥”）发送到用户B可访问的网络上某处。然后，用户B使用公钥来加密他想要发送给用户A的信息。实际过程涉及到大量让我想一想就头痛的数学知识，但是基本上，公钥和消息数据是通过一个加密算法来运作的，该加密算法生成一个没有私钥不可能打开的加密文件。接下来，用户B把经过加密的消息发送给用户A，而用户A则使用最初隐藏的私钥来对加密数据进行解密。结果，用户A是世界上惟一一个能够解密这些加密数据的人，因为（只有）他拥有与用户B的公钥匹配的惟一私钥。

　　现在，如果您像我一样爱刨根问底，您可能会想，但是用户A如何知道用户B真的是用户B呢?如果某位黑客侵入到用户B的系统中，并找到了他使用的公钥，那怎么办呢?为了回答这个有效性问题，人们使用了大量实体来确保特定用户的真实性，并授予他们证明其真实性的数字证书。这些实体叫做certificate authority （认证机构，CA）。CA的一个著名例子是VeriSign，它提供用于电子商务事务的证书。

　　使用密钥、加密和证书来实现保密性和身份验证的SOA安全性解决方案如图11所示。在我们的制造商例子中，供应商系统想发送一条SOAP消息给制造商的web服务。为了做到这一点，制造商必须首先发送一个公钥给CA。然后，供应商系统从CA请求一个证书。供应商收到的证书包含与制造商系统中存在的私钥相匹配的公钥。然后，供应商使用证书的公钥加密其消息，然后再把消息发送给制造商。然而，和前面的例子一样，SOA安全性解决方案侦听消息，并使用CA检查证书的有效性。这可以验证供应商的身份。只有在通过身份验证之后，加密后的SOAP消息才能被发送给制造商。SOAP消息到达之后，制造商就使用它的私钥对消息进行解密和处理。

　　如果您觉得这听起来更多地像是在发送消息，那么您想得没错。就像在IT的其他领域中一样，SOA中的安全性会带来大量“开销”。在到达目的地之前，每条消息都必须经过好几个地方。证书文件可能会很大，从而给网络造成很大的负担，而且整个过程往往会降低性能。但是遗憾的是，它仍然是必不可少的。

　　XML加密　

　　图 5 在安全性SOA中使用公钥/私钥加密和证书的步进式过程

　　图字：

　　制造商将公钥发送给认证机构，并将私钥隐藏在自己的域中

　　供应商从认证机构请求包含制造商公钥的证书

　　供应商向制造商发送使用公钥进行加密并包含证书的消息

　　SOA安全性解决方案向认证机构发送证书，以便对供应商进行身份验证

　　SOA安全性解决方案向制造商发送使用私钥进行加密的SOAP消息

　　为了保留SOA的开放性，同时制订严格的消息级的安全性标准，您很可能想在加密时使用XML。当SOA安全性解决方案使用密钥对消息进行加密时，它会把消息转换为一段经过加密的XML。消息是XML格式的，但是内容并不可见，因为使用加密算法将其隐藏起来了。这样做的好处在于，接收消息的系统可以把它当作XML来接收、解密和处理，而不依赖于定制或专有的消息传递标准。这样我们就获得了安全性，同时系统仍然基于开放标准。

　　数字签名

　　数字签名是另一种消息级的安全性形式，它是证书、密钥和加密等安全性方法的变体。数字签名就是附加给SOAP消息的证明真实性的数学语句。数字签名是一个基于密钥的数（同样是一个非常大的数），它对您的身份和消息内容进行惟一的处理，具体方法是对两组数据（密钥和消息）运行一个特殊的算法。举一个简单的例子，如果您的消息是“hello”而密钥是12345，算法将处理这两种输入——单词“hello”的数值和密钥数12345——并生成第三个数，这第三个数就是数字签名。当接收系统获得消息和附加的数字签名时，它可以使用密钥来验证以下内容：

　　您是消息的真正创建者（身份验证），

　　SOAP消息在传输过程中没有改变。

　　如果消息被改变了，那么惟一的数字签名将不再与密钥和用于创建密钥的原始消息相匹配。数字签名和先前描述的完整加密过程之间的区别在于，如果使用数字签名，不必对整条消息进行加密。因此，系统的性能得到了提升。只要您不介意别人可以看到您的纯文本格式的消息，那么数字签名就可以为SOA提供高度的数据安全性和完整性。

　　签名可以是一个不可否认性（nonrepudiation）组成部分，该特性是一个需要在SOA环境中解决的安全性重要方面。不可否认性是指一个组织的一种能力：验证发生了特定的处理，并从而不给发送方提供否定进行了处理的机会。例如，如果您针对某种商品下了一份电子订单，而该订单并没有以某种方式（比如使用数字签名）进行验证，那么对方就有可能否认收到该订单。如果批发商的系统提供不可否认性，那么批发商就可以肯定该订单已经送达。

　　重放攻击保护和审计

　　最后，SOA安全性解决方案应该提供一种用于跟踪SOAP请求的工具，从而降低DoS攻击带来损害的可能性。通常，跟踪特性将监控SOAP消息的发送方及其创建时间。在某些情况下，SOA安全性解决方案将使用一个惟一的识别码给SOAP消息打上印记。如果解决方案被设置为阻塞复制消息，那么同一条消息是不可能被发送两次的。消除这种可能性有助于降低黑客使用复制请求淹没SOA的可能性，这是DoS攻击中常用的一种手法。

　　审计是SOAP消息跟踪功能的进一步发展。如果SOA安全性解决方案被配置为跟踪消息，那么它应该能够生成特定时期中SOA消息流量的使用日志和审计报告。审计有很多用途，但是在安全性领域中，它用于记录所发生的事情，以便研究安全性问题并诊断潜在的安全漏洞。这类日志已经成为实现管理目标（比如对Sarbanes-Oxley法案的服从）所必不可少的。

　　明智的管理人员所给出的忠告：不要让安全性吓倒了您

　　SOA安全性是一个很大的主题。我可以就这个主题写一本书。（事实上，这是一个不错的主意…）在本章中，我的目的是提供一个概述，好让您可以评估自己对这个主题所掌握的信息。如果您是一位企业主管，我的建议是，要避免被安全性问题吓倒。人们很容易被安全性吓倒，安全人员也不例外，这阻止了他们做些实际工作以消除对于安全性问题的恐惧。实际上，我本来可以提出一个您正在考虑的IT解决方案，并让您了解到围绕该解决方案的大量安全性噩梦，这些噩梦足以使您远离该解决方案。

　　相反，我建议您寻求安全性方面的高质量建议，并探讨企业中已经实施了哪些。如果您这样做，那么您的企业就很可能会拥有一个（或一些）相当健壮的安全性系统。实施SOA的难点在于如何把现有的安全措施扩展成为由SOA构成的web服务。许多SOA安全性解决方案的设计目的就是为了与现有的安全功能有效互连。如果实现的话，安全性风险可能稍微易于管理一些，而您也可以继续实施您的计划了。

　　结束语

　　安全性是SOA中的一个焦点问题，因为SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互。身份验证和授权在这个环境中变得更加富于挑战性。在未受保护的SOA中，想要阻止web服务的未授权使用实际上是不可能的;未授权用户可以非常轻松地访问web服务。Web服务不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。无法阻止不必要的监听和消息侦听。未受保护的SOA让黑客有机会监听SOAP消息并看到私密信息。此外，在未受保护的SOA中，侦听SOAP消息并（出于危害和欺骗的目的）重新发送消息或转换消息内容要相对容易一些。

　　由于SOA架构的开放性本质，您无法保护SOA中未知的第三方。第二级和第三级用户（例如您的合作伙伴的合作伙伴）是可以访问未受保护的SOA的。因此，未受保护的SOA很容易超负荷运转。如果没有访问控制，未受保护的SOA很容易被来自黑客的大量SOAP消息所“淹没”。结果可能导致DoS攻击损害系统的正常功能。最后，您还没有处理记录。未受保护的SOA无法跟踪其用户或消息。因此，没有可用于研究安全性问题或诊断安全性漏洞的可审计使用记录。

　　存在一些可以解决所有这些问题的预打包和定制的SOA安全性解决方案。在分析SOA安全性需求时，可以考虑实现一个支持SOAP消息监控、联邦身份验证、应用程序代理、契约管理、证书、密钥和加密以及审计记录的SOA安全性解决方案。这个清单似乎很长，但是事实上，如果缺少其中任何一项，SOA的所有优点都可能遭到破坏。

　　SOAP消息监控利用了一个SOAP拦截器模型，以便在将SOAP消息从调用系统发送给web服务时对其进行侦听和监控。SOAP消息监控是SOA安全性的基础，因为它让安全性解决方案能够停止和分析每条消息，以进行用户身份验证和授权。为了保护第三方，安全性解决方案可以利用联邦身份验证。应该通过一个联邦身份验证过程提供对系统中的用户进行身份验证的能力。最终将获得一个为web服务的用户提供可信身份验证的SAML断言。

　　Web服务应用程序代理在实际的web服务中接收和处理SOAP请求，从而对安全性有所帮助。它可以使所有的用户都远离实际的服务。代理不仅可以减轻网络的负载，还可以为SOA提供一个额外的安全性层。

　　契约管理是另一项对安全性有所帮助的SOA管理特性。契约确立了谁有权使用web服务以及何时可以使用它。契约通过消除非契约方的使用，提高了SOA的安全性。

　　对于一个真正安全的SOA来说，证书、密钥和加密同样是必不可少的。最健壮的SOA安全性都源于实现了使用来自认证机构的私钥/公钥进行身份验证的加密消息传递。XML加密允许web服务用户发送保留XML格式的加密SOAP消息。因此，系统实现了安全性，但却仍然基于标准。数字签名是加密模型的一种变体，它使得web服务的用户可以创建一个惟一确认的数字“签名”，其用途有二：验证用户身份和确保消息数据的完整性。

　　最后，为了跟踪SOA的使用，有必要采用可以保存所有SOAP消息请求和响应的动态审计日志的SOA安全性解决方案。审计日志对于在SOA中研究安全性问题和诊断安全性漏洞，以及实现管理规章服从性，都是必需的。