与基于Internet技术实现人与人通信（e-mail）和人与应用程序（Web页）的通信方式很相似，XML和Web services从根本上改变了应用程序之间的通信方式。他们使应用程序之间的通信更加有效，而不必要处理底层的通信机制。
然而，Web services标准不能彻底解决XML Web services的安全性。本文将提供XML与 Web services相关的安全性问题的概述，略述当前在运用的这些标准，并说明现今如何保护Web services通信的安全，不论其是否在防火墙下。
XML与 Web services相关的安全性问题的概述
Web services会暴露新的重大安全风险，在实现任何关键任务期间，必须解决这个问题。比如：
- 在应用层上，Web services避开了防火墙，所以网络防火墙不能够提供足够的安全保护（防火墙要保护的是网络层的安全，而不是应用层的安全）。
- Web services网络通常是基于同层的，其分散式管理妨碍了标准化、全面可见性和控制。即使出现一些标准，它们也是发展迅速、不断变化，并且是不统一的。因此，在实现Web services时同时，使用多个标准是常有的事。这是因为技术管理人员使用了许多遗留标准，他们不想将赌注下在某一个特殊的标准上。
- Web services网络允许您连接应用程序，这样将导致松散耦合的、具有不同安全方案和能力的异构网络。
- Web services网络是动态的，并且其增长是有机的，这些将增加经营和管理成本。
- Web services接口暴露了比标准接口更多的功能。因为Web services接口是应用程序接口，所以它们暴露了更多会受到内部和外部威胁的功能。由于它们的复杂性和暴露性，这些接口的安全性更容易遭到破坏。
- Web services允许连接不同的应用程序，比如大型机、桌面应用程序、.NET、Sun ONE、打包应用程序等，所以很难为它们定制标准化的安全，也很难通过不同的系统对它们进行监视（如图1）。
（图 1. 获得连接）
标准化安全
身份验证、授权、机密性和签名支持，它们是基于Web通信的4项基本安全要求，同时也是XML Web services安全通信的基础。因此，可以利用实现Web安全的现有基础设施来实现XML Webservices，从而为XML消息提供安全。
然而，Web services也引入了新的安全问题。
尽管XML Web services与大多数Web基础的通信使用的是相同的传输机制，但典型的XML网络还需要其他安全性来确保最小的安全保护级别。因此，即使在可控环境中，也能够使用现有的技术保护试点项目，但是随着时间的推移，各种安全和管理问题还是会出现。
因为Web services只是简单地与诸如提供者、消费者和合作伙伴之类的第三方程序整合在一起，所以必须严密控制身份验证和访问权限，使它们能够及时更新。然而，因为第三方程序常常与Web services网络有关，所以它们很难或者说无法对身份验证和访问控制方案进行标准化（参见图
2）。具体地说，在跨不同公司管理多种格式方面，B2B交易面临着极大的挑战。在极端的情况下，每项服务都需要一个用于其访问的每项服务的独立的证书。单点登陆和证书映射解决方案有助于简化对这些环境的管理，并且参与者使用它们也很方便。
在公司整合了不同的系统之后，互操作性就成为一个严重管理问题。尽管SOAP、WSDL和UDDI标准化了通信，但仍然需要解决安全问题，以及数据和传输互操作性方面的问题。
任何安全解决方案都必须能够从性能方面进行衡量。然而，随着诸如Web 服务安全性之类的新标准出现，可能会出现性能瓶颈，这些标准需要使一些处理器加强功能（比如签名认证和解密）成为网络的组成部分（请参阅文末的参考资料）。您能够使用专门的硬件去执行加密功能，从而转移负载，并在每个Web
services中或者代理器中定位他们，以便通过多个服务共享它们。
经营和管理的可伸缩性引出了另一个尺度问题。通过将服务请求者组合在一起，能够更有效地管理安全策略，而Web services接口是一个常常被遗忘的必要条件，您应该及早计划。
在Web services环境中，单点登录也起着一个十分重要的作用。不同的系统需要彼此进行通信，对于每一个系统而言，维护另一个系统的身份验证权限和访问控制列表（ACL）是不现实的。一种解决方案是为每一个人提供相同的证书。然而，当其中的一个成员不受信任时，就会出现严重的问题。您必须给其他所有有效成员发送新的证书。当需要取消用户的权限时，每项服务都需要一个单独的证书，而这是很难管理的。需要取消用户权限的每个系统很难实现身份验证和授权。确保用户不再访问所有系统同样也很困难。单点登录解决方案和证书映射解决方案有助于解决这个问题。每个Web
service负责处理它所习惯的证书系统，这能降低管理成本，并能提供数据保护。
SOAP接口代表另一种可能的安全漏洞，因为这些软件API可能会暴露功能。例如，一个打包应用程序可能有成百上千的关键操作被暴露，而所有这些都可以通过端口80读取；攻击者可以得到更多他可以使用的标准信息。Web服务描述语言（WSDL）文件、通用描述、检测和整合（UDDI）等这些条目提供了关于服务的详细信息，例如，如何调用它，希望发送和接受什么样的参数等，这些为黑客提供了登录所使用的信息。SOAP信息和WSDL文件都是XML格式的，这种格式是自描述的，它清楚地显示了数据元素和数据结构。拥有这些信息，黑客能够了解信息格式，并充分利用它。尽管随着时间的推移，黑客对Web
services的攻击变得越来越老练，但与此同时，有更多的信息可用于检测系统安全和防止安全问题。
了解攻击的风险
网络防火墙能够阻止标准形式的攻击，但是Web services却提供了新形式、新类型的攻击机会，这些攻击通常是通过端口80进行的。最常见的攻击包括拒绝服务、重放、缓冲溢出、字典口令、SQL注入和跨站点脚本攻击等。熟悉这些攻击类型十分重要，这样可以保护Web services不受攻击。
拒绝服务攻击通常发生在网络层，但是却在整个Web services世界中流行。当前的Web站点技术能够很好地检测标准的拒绝服务活动，但是由于Web services接口是异构的，所以您需要了解更多有关基本Web services应用程序的知识，以便更好地保护它们。例如，一个提供简单信息（比如股票报价服务）的Web services可能每秒钟可以轻松处理1000个请求。然而，由于计算太复杂，申请借款应用程序每个小时可能最多能够处理5个请求。每小时向申请借款接口发送10个请求可以阻止拒绝服务攻击，但是通过正常途径（比如防火墙）很难检测到问题。防火墙无法在每一项操作的基础上提供控制拒绝服务的粒度需求。了解并收集标准使用数据应该对提供有关每项服务的侧面信息很有帮助，这样，您就能够保护这些信息不受拒绝服务的攻击。
与拒绝服务类似，重放攻击是复制有效的消息，并反复将它们发送到某个服务中。您能够应用某些技术检测并处理有利于打击重放攻击的拒绝服务。在某些情况下，因为有效负载信息很容易获得，所以重放服务很容易被检测到。在使用正确工具的情况下，即使通过多种媒体（如HTTP、HTTPS、SMTP等）或通过不同的接口发送相同或者类似的有效负载，也能够检测这些攻击模式。
使用XML Web services时，关于数据参数的信息将被暴漏。另外，更多通过许多不同接口类型传递的数据可能在不同的系统间传递，这为黑客发起缓冲溢出攻击提供了机会。例如，攻击者可以发送一个过长的参数，例如一个超过预期长度或者包含不合需要的编码的口令，这会造成服务崩溃，或者执行攻击者提供的那些代码。在数字字段中发送字符可能会造成一些问题，因为应用程序不会预料到这些。启用Web services的许多遗留系统是设计用于受约束的、可推断的请求的，并且它们可能没有准备好处理异常情况。为Web services提供防止恶意攻击的保护是必需的，特别是那些遗留系统。
黑客通常发送不正常格式的内容来制造与缓冲溢出类似的效果。比如，在字符串中发送引号、句号和通配符等，如果应用程序没有为处理这些攻击做好准备的话，那么这些内容通常可能使应用程序一片混乱。测试并过滤这些异常内容对阻止干扰行为很重要。
SQL注入式攻击通过添加特殊的字符或术语致使SQL语句返回预料之外的数据。例如，一个应该以SQL语句的WHERE子句结尾的字符串可能被欺骗而包含了更多的信息。比如，以下参数值可能造成返回整个表，因为1＝1在WHERE子句中永远为TRUE：
X' OR 1=1
对于任何访问后端数据库的应用程序而言，过滤这些类型的样式是十分重要的。否则，黑客能够运行数据库命令，这可能返回敏感数据，或者修改和删除数据。
脆弱的口令保护是另一种重要的安全风险的代表。字典攻击很常见，在这种攻击模式下，黑客可能手动尝试一些常见的口令，或者通过编程的方式进入一个系统或者多个系统。管理员应该确保用户选择的口令是很难猜测的并经常改变它们。与标准的用户证书不同，管理员决定了应用程序证书。您应该要求用户使用口令加强规则，以便Web services接口应用程序很好地工作。
病毒同样也是Web services安全的一个威胁，加密技术使得检测病毒成为一个挑战。Web services通信量中可能包含一些附件，在加密内容的时候，病毒也被加密。这样，病毒检测程序就很难检测恶意软件。为了阻止病毒通过Web services入侵系统，应该在目的地对加密数据执行病毒检测，或者使用中间物进行病毒检测，这样可以先解密数据进行病毒扫描，然后重新加密后再传输。
对XML Web services的恶意攻击还不是那么很普遍，很大程度上因为多数Web services项目都处于防火墙之下。不信可以试一下，一旦Web services大量泄漏于防火墙之外，攻击将会十分频繁，但是因为Web服务接口的异构特性，这些攻击很难检测。您能够利用各类工具，比如入侵检测系统（IDS）工具和XML防火墙，来避免这些类型的攻击。
研究Web services的标准
虽然一些现有的标准，如LDAP、公钥基础设施（PKI）和SSL，在Web services安全中起着十分重要的作用，但其他一些标准对于提供Web services惟一安全性需要也是必需的。虽然基本的SOAP、WSDL和UDDI Web services标准已经制定好了，但是一些专用于Web services安全的标准，比如安全声明标示语言（SAML）、XML加密、XML签名和WS-Security等，仍然在发展当中。万维网联盟（W3C）领导着这些标准的开发。
SAML协议声明了身份验证和授权信息。可以访问SAML兼容的服务器来获得身份验证和授权数据，从而启动单点登录。XML加密协议描述了数字内容的加密。它包括用来加密XML文档部分的协议，并允许进行端到端加密，因为只有私有内容被加密。会话级加密只能提供两台服务器之间的数据保密。XML签名协议描述了数字内容的签名。它包括用于XML文档签名部分的协议，并允许使用诸如消息完整性之类的功能。XML密钥管理规范（XKMS）描述了公钥的分配和注册。服务能够访问XKMS兼容服务器来接收用于加密和身份验证的更新过的密钥信息。
其他组织在运用另外一些标准。微软和IBM正在开发WS-Security，为保护信息的完整性和机密性提供了核心工具。WS-Security还包括一些与信息安全性有关的机制。当前，WS-Security描述了如何给SOAP消息加上签名、加密和安全标记。OASIS则致力于可扩展访问控制标记语言（XACML），该语言通常用来描述访问权策略，它们提供了一些身份验证和授权信息。Sun和其他自由联盟公司完成了Liberty Alliance Project，交付并支持用于Internet的一个联邦网络身份解决方案，该方案允许消费者与商业用户使用一种开放的、联合的方式实现单点登录。IBM目前还正在发展HTTP－R，这是一个适用于可信赖消息的传递标准。最后，可扩展权限标记语言（XrML）是一种用来安全指定和管理权限以及条件的通用方法，这些条件与包括数字内容和服务的资源相关。假设有很多标准都在发展中，并且很多厂商都着急使用这些标准，那么公司必须注意它们支持的每一个标准。即使您的组织是IBM或者.NET这样的公司，可能也需要使用由其他供应商的解决方案生成的Web
services。
安全性现状，安全性未来
虽然应该与最新出现的Web services安全标准保持一致，但您能够使用遗留的技术保护Web services通信。专用链路或SSL能够确保通信和Web services网络的数据保密。而且您能够使用现有身份验证目录（如LDAP或X.509证书）来进行身份验证和访问控制。可是，这些解决方案只在某种受控制的、简单的环境中起作用，它们并没有很好地从性能和管理方面得到扩展。Web services都与整合不同的系统有关，甚至可以跨不同的企业；使用遗留技术来维持安全互操作性的代价是很高的。为了给那些不固定的和动态的环境提供真正的端到端的安全，需要混合使用一些技术和标准。一开始就构建一个可伸缩的安全性很重要。在制造了一大对类似于尝试在一个标准Web应用程序中确立品质时遇见的问题之后，构建一个可伸缩的安全性。例如，试着在异构的、分散的环境中实施公司级策略，随着添加到网络中的Web
services越来越多，这变得难以处理。加强标准并使用综合技术，例如XML防火墙，随着环境大小和复杂性的增加，这有助于度量环境。（请参阅侧栏“Top 10 Requirements for Effective
Web Services Security”）。
在实现Web services安全性时，企业常常不得不选择在共享服务层中构建安全性，或者在每个应用程序节点中构创它（比如在每台应用服务器上）。每个方法都有其优点和缺点。当在每个Web service中创建安全性时，会获得短期成本效益，并减少了实现每个Web服务所需的时间。使用现有系统也会有一个较低的初始进入壁垒。
然而这种方法也存在许多短期和长期的缺陷。首先，很难将它添加到遗留的代码和打包程序中。此外，在所有节点中实现和维护统一的策略不是一个简单的过程。而且也很难证明您已经实现了一个给定的安全策略。最后，在每个服务中复制安全性很昂贵，特别是在Web services移植到桌面时。
因此，您可能想将安全性视为一种共享服务。当公司将安全性作为共享服务来构建时，其优点是服务具有长期性和可伸缩性，这是不足为奇的。其他优点包括维护互操作性的费用较低，Web services网络、管理和控制的集中可见性，利用最佳密码加速器的能力。不过，这种方式的折衷包括在网络中额外跳跃（extra hop），解决方案必须支持多种标准和技术，并且该解决方案是一个无法伸缩的解决方案，那么会存在潜在的瓶颈。同样，网络防火墙可以以同样的方式成为共享服务，来保护多种Web页面，许多分析家相信应用程序安全性将会逐步成为一种共享服务模式。
从XML Web services中获取商业利益的念头会驱使IT经理们头脑发热。为了成功解决这些新问题，从创建支离破碎的安全系统（它们重点关注使用网络边界（network perimeter）来屏蔽封闭的业务系统）到实现一致的托管安全系统（它们重点关注管理应用程序级安全，以获得分布式、复杂的业务系统），经理们必须改变他们的思想倾向（请参阅侧栏“Web
Services: Who Should Care”）。虽然很多目前正在进行的试点项目只有很少的安全需求，但是随着网络使用的增长，需要确保这些网络是安全的，这一点对于构建具有成本效益并且安全的环境非常重要。也就是说，在开发过程中要尽早地考虑一些重要的系统需求，这对于确保安全通信是至关重要的。
----------------------------------------------------------------------------------------------------------------------------------------------------
关于作者
Andrew Yang是Westbridge Technology公司市场部的高级主管，该公司是XML Web services安全解决方案的提供商。Andrew曾为多家公司工作，其中包括DoubleClick、Oracle公司和Booz-Allen & Hamilton公司。您可以通过andy@westbridgetech.com与Andrew联系。
参考资料
作者简介：Mark O'Neill是Vordel公司的CTO，Vordel公司是一家Web services安全公司。Mark是Web servicesSecurity（Osborne/McGraw-Hill，2003年1月。IBSN：0-0722-2471-1）一书的作者，经常做XML和Web services安全方面的演讲。他经常出外旅游，但同时也尽量抽出时间来陪他在波士顿的妻子Kristen以及他们新出生的孩子Ben。
原文出处
http://www.ftponline.com/wss/2003_TE/magazine/features/ayang/
与基于Internet技术实现人与人通信（e-mail）和人与应用程序（Web页）的通信方式很相似，XML和Web services从根本上改变了应用程序之间的通信方式。他们使应用程序之间的通信更加有效，而不必要处理底层的通信机制。
然而，Web services标准不能彻底解决XML Web services的安全性。本文将提供XML与 Web services相关的安全性问题的概述，略述当前在运用的这些标准，并说明现今如何保护Web services通信的安全，不论其是否在防火墙下。
XML与 Web services相关的安全性问题的概述
Web services会暴露新的重大安全风险，在实现任何关键任务期间，必须解决这个问题。比如：
- 在应用层上，Web services避开了防火墙，所以网络防火墙不能够提供足够的安全保护（防火墙要保护的是网络层的安全，而不是应用层的安全）。
- Web services网络通常是基于同层的，其分散式管理妨碍了标准化、全面可见性和控制。即使出现一些标准，它们也是发展迅速、不断变化，并且是不统一的。因此，在实现Web services时同时，使用多个标准是常有的事。这是因为技术管理人员使用了许多遗留标准，他们不想将赌注下在某一个特殊的标准上。
- Web services网络允许您连接应用程序，这样将导致松散耦合的、具有不同安全方案和能力的异构网络。
- Web services网络是动态的，并且其增长是有机的，这些将增加经营和管理成本。
- Web services接口暴露了比标准接口更多的功能。因为Web services接口是应用程序接口，所以它们暴露了更多会受到内部和外部威胁的功能。由于它们的复杂性和暴露性，这些接口的安全性更容易遭到破坏。
- Web services允许连接不同的应用程序，比如大型机、桌面应用程序、.NET、Sun ONE、打包应用程序等，所以很难为它们定制标准化的安全，也很难通过不同的系统对它们进行监视（如图1）。
（图 1. 获得连接）
标准化安全
身份验证、授权、机密性和签名支持，它们是基于Web通信的4项基本安全要求，同时也是XML Web services安全通信的基础。因此，可以利用实现Web安全的现有基础设施来实现XML Webservices，从而为XML消息提供安全。
然而，Web services也引入了新的安全问题。
尽管XML Web services与大多数Web基础的通信使用的是相同的传输机制，但典型的XML网络还需要其他安全性来确保最小的安全保护级别。因此，即使在可控环境中，也能够使用现有的技术保护试点项目，但是随着时间的推移，各种安全和管理问题还是会出现。
因为Web services只是简单地与诸如提供者、消费者和合作伙伴之类的第三方程序整合在一起，所以必须严密控制身份验证和访问权限，使它们能够及时更新。然而，因为第三方程序常常与Web services网络有关，所以它们很难或者说无法对身份验证和访问控制方案进行标准化（参见图
2）。具体地说，在跨不同公司管理多种格式方面，B2B交易面临着极大的挑战。在极端的情况下，每项服务都需要一个用于其访问的每项服务的独立的证书。单点登陆和证书映射解决方案有助于简化对这些环境的管理，并且参与者使用它们也很方便。
在公司整合了不同的系统之后，互操作性就成为一个严重管理问题。尽管SOAP、WSDL和UDDI标准化了通信，但仍然需要解决安全问题，以及数据和传输互操作性方面的问题。
任何安全解决方案都必须能够从性能方面进行衡量。然而，随着诸如Web 服务安全性之类的新标准出现，可能会出现性能瓶颈，这些标准需要使一些处理器加强功能（比如签名认证和解密）成为网络的组成部分（请参阅文末的参考资料）。您能够使用专门的硬件去执行加密功能，从而转移负载，并在每个Web
services中或者代理器中定位他们，以便通过多个服务共享它们。
经营和管理的可伸缩性引出了另一个尺度问题。通过将服务请求者组合在一起，能够更有效地管理安全策略，而Web services接口是一个常常被遗忘的必要条件，您应该及早计划。
在Web services环境中，单点登录也起着一个十分重要的作用。不同的系统需要彼此进行通信，对于每一个系统而言，维护另一个系统的身份验证权限和访问控制列表（ACL）是不现实的。一种解决方案是为每一个人提供相同的证书。然而，当其中的一个成员不受信任时，就会出现严重的问题。您必须给其他所有有效成员发送新的证书。当需要取消用户的权限时，每项服务都需要一个单独的证书，而这是很难管理的。需要取消用户权限的每个系统很难实现身份验证和授权。确保用户不再访问所有系统同样也很困难。单点登录解决方案和证书映射解决方案有助于解决这个问题。每个Web
service负责处理它所习惯的证书系统，这能降低管理成本，并能提供数据保护。
SOAP接口代表另一种可能的安全漏洞，因为这些软件API可能会暴露功能。例如，一个打包应用程序可能有成百上千的关键操作被暴露，而所有这些都可以通过端口80读取；攻击者可以得到更多他可以使用的标准信息。Web服务描述语言（WSDL）文件、通用描述、检测和整合（UDDI）等这些条目提供了关于服务的详细信息，例如，如何调用它，希望发送和接受什么样的参数等，这些为黑客提供了登录所使用的信息。SOAP信息和WSDL文件都是XML格式的，这种格式是自描述的，它清楚地显示了数据元素和数据结构。拥有这些信息，黑客能够了解信息格式，并充分利用它。尽管随着时间的推移，黑客对Web
services的攻击变得越来越老练，但与此同时，有更多的信息可用于检测系统安全和防止安全问题。
了解攻击的风险
网络防火墙能够阻止标准形式的攻击，但是Web services却提供了新形式、新类型的攻击机会，这些攻击通常是通过端口80进行的。最常见的攻击包括拒绝服务、重放、缓冲溢出、字典口令、SQL注入和跨站点脚本攻击等。熟悉这些攻击类型十分重要，这样可以保护Web services不受攻击。
拒绝服务攻击通常发生在网络层，但是却在整个Web services世界中流行。当前的Web站点技术能够很好地检测标准的拒绝服务活动，但是由于Web services接口是异构的，所以您需要了解更多有关基本Web services应用程序的知识，以便更好地保护它们。例如，一个提供简单信息（比如股票报价服务）的Web services可能每秒钟可以轻松处理1000个请求。然而，由于计算太复杂，申请借款应用程序每个小时可能最多能够处理5个请求。每小时向申请借款接口发送10个请求可以阻止拒绝服务攻击，但是通过正常途径（比如防火墙）很难检测到问题。防火墙无法在每一项操作的基础上提供控制拒绝服务的粒度需求。了解并收集标准使用数据应该对提供有关每项服务的侧面信息很有帮助，这样，您就能够保护这些信息不受拒绝服务的攻击。
与拒绝服务类似，重放攻击是复制有效的消息，并反复将它们发送到某个服务中。您能够应用某些技术检测并处理有利于打击重放攻击的拒绝服务。在某些情况下，因为有效负载信息很容易获得，所以重放服务很容易被检测到。在使用正确工具的情况下，即使通过多种媒体（如HTTP、HTTPS、SMTP等）或通过不同的接口发送相同或者类似的有效负载，也能够检测这些攻击模式。
使用XML Web services时，关于数据参数的信息将被暴漏。另外，更多通过许多不同接口类型传递的数据可能在不同的系统间传递，这为黑客发起缓冲溢出攻击提供了机会。例如，攻击者可以发送一个过长的参数，例如一个超过预期长度或者包含不合需要的编码的口令，这会造成服务崩溃，或者执行攻击者提供的那些代码。在数字字段中发送字符可能会造成一些问题，因为应用程序不会预料到这些。启用Web services的许多遗留系统是设计用于受约束的、可推断的请求的，并且它们可能没有准备好处理异常情况。为Web services提供防止恶意攻击的保护是必需的，特别是那些遗留系统。
黑客通常发送不正常格式的内容来制造与缓冲溢出类似的效果。比如，在字符串中发送引号、句号和通配符等，如果应用程序没有为处理这些攻击做好准备的话，那么这些内容通常可能使应用程序一片混乱。测试并过滤这些异常内容对阻止干扰行为很重要。
SQL注入式攻击通过添加特殊的字符或术语致使SQL语句返回预料之外的数据。例如，一个应该以SQL语句的WHERE子句结尾的字符串可能被欺骗而包含了更多的信息。比如，以下参数值可能造成返回整个表，因为1＝1在WHERE子句中永远为TRUE：
X' OR 1=1
对于任何访问后端数据库的应用程序而言，过滤这些类型的样式是十分重要的。否则，黑客能够运行数据库命令，这可能返回敏感数据，或者修改和删除数据。
脆弱的口令保护是另一种重要的安全风险的代表。字典攻击很常见，在这种攻击模式下，黑客可能手动尝试一些常见的口令，或者通过编程的方式进入一个系统或者多个系统。管理员应该确保用户选择的口令是很难猜测的并经常改变它们。与标准的用户证书不同，管理员决定了应用程序证书。您应该要求用户使用口令加强规则，以便Web services接口应用程序很好地工作。
病毒同样也是Web services安全的一个威胁，加密技术使得检测病毒成为一个挑战。Web services通信量中可能包含一些附件，在加密内容的时候，病毒也被加密。这样，病毒检测程序就很难检测恶意软件。为了阻止病毒通过Web services入侵系统，应该在目的地对加密数据执行病毒检测，或者使用中间物进行病毒检测，这样可以先解密数据进行病毒扫描，然后重新加密后再传输。
对XML Web services的恶意攻击还不是那么很普遍，很大程度上因为多数Web services项目都处于防火墙之下。不信可以试一下，一旦Web services大量泄漏于防火墙之外，攻击将会十分频繁，但是因为Web服务接口的异构特性，这些攻击很难检测。您能够利用各类工具，比如入侵检测系统（IDS）工具和XML防火墙，来避免这些类型的攻击。
研究Web services的标准
虽然一些现有的标准，如LDAP、公钥基础设施（PKI）和SSL，在Web services安全中起着十分重要的作用，但其他一些标准对于提供Web services惟一安全性需要也是必需的。虽然基本的SOAP、WSDL和UDDI Web services标准已经制定好了，但是一些专用于Web services安全的标准，比如安全声明标示语言（SAML）、XML加密、XML签名和WS-Security等，仍然在发展当中。万维网联盟（W3C）领导着这些标准的开发。
SAML协议声明了身份验证和授权信息。可以访问SAML兼容的服务器来获得身份验证和授权数据，从而启动单点登录。XML加密协议描述了数字内容的加密。它包括用来加密XML文档部分的协议，并允许进行端到端加密，因为只有私有内容被加密。会话级加密只能提供两台服务器之间的数据保密。XML签名协议描述了数字内容的签名。它包括用于XML文档签名部分的协议，并允许使用诸如消息完整性之类的功能。XML密钥管理规范（XKMS）描述了公钥的分配和注册。服务能够访问XKMS兼容服务器来接收用于加密和身份验证的更新过的密钥信息。
其他组织在运用另外一些标准。微软和IBM正在开发WS-Security，为保护信息的完整性和机密性提供了核心工具。WS-Security还包括一些与信息安全性有关的机制。当前，WS-Security描述了如何给SOAP消息加上签名、加密和安全标记。OASIS则致力于可扩展访问控制标记语言（XACML），该语言通常用来描述访问权策略，它们提供了一些身份验证和授权信息。Sun和其他自由联盟公司完成了Liberty Alliance Project，交付并支持用于Internet的一个联邦网络身份解决方案，该方案允许消费者与商业用户使用一种开放的、联合的方式实现单点登录。IBM目前还正在发展HTTP－R，这是一个适用于可信赖消息的传递标准。最后，可扩展权限标记语言（XrML）是一种用来安全指定和管理权限以及条件的通用方法，这些条件与包括数字内容和服务的资源相关。假设有很多标准都在发展中，并且很多厂商都着急使用这些标准，那么公司必须注意它们支持的每一个标准。即使您的组织是IBM或者.NET这样的公司，可能也需要使用由其他供应商的解决方案生成的Web
services。
安全性现状，安全性未来
虽然应该与最新出现的Web services安全标准保持一致，但您能够使用遗留的技术保护Web services通信。专用链路或SSL能够确保通信和Web services网络的数据保密。而且您能够使用现有身份验证目录（如LDAP或X.509证书）来进行身份验证和访问控制。可是，这些解决方案只在某种受控制的、简单的环境中起作用，它们并没有很好地从性能和管理方面得到扩展。Web services都与整合不同的系统有关，甚至可以跨不同的企业；使用遗留技术来维持安全互操作性的代价是很高的。为了给那些不固定的和动态的环境提供真正的端到端的安全，需要混合使用一些技术和标准。一开始就构建一个可伸缩的安全性很重要。在制造了一大对类似于尝试在一个标准Web应用程序中确立品质时遇见的问题之后，构建一个可伸缩的安全性。例如，试着在异构的、分散的环境中实施公司级策略，随着添加到网络中的Web
services越来越多，这变得难以处理。加强标准并使用综合技术，例如XML防火墙，随着环境大小和复杂性的增加，这有助于度量环境。（请参阅侧栏“Top 10 Requirements for Effective
Web Services Security”）。
在实现Web services安全性时，企业常常不得不选择在共享服务层中构建安全性，或者在每个应用程序节点中构创它（比如在每台应用服务器上）。每个方法都有其优点和缺点。当在每个Web service中创建安全性时，会获得短期成本效益，并减少了实现每个Web服务所需的时间。使用现有系统也会有一个较低的初始进入壁垒。
然而这种方法也存在许多短期和长期的缺陷。首先，很难将它添加到遗留的代码和打包程序中。此外，在所有节点中实现和维护统一的策略不是一个简单的过程。而且也很难证明您已经实现了一个给定的安全策略。最后，在每个服务中复制安全性很昂贵，特别是在Web services移植到桌面时。
因此，您可能想将安全性视为一种共享服务。当公司将安全性作为共享服务来构建时，其优点是服务具有长期性和可伸缩性，这是不足为奇的。其他优点包括维护互操作性的费用较低，Web services网络、管理和控制的集中可见性，利用最佳密码加速器的能力。不过，这种方式的折衷包括在网络中额外跳跃（extra hop），解决方案必须支持多种标准和技术，并且该解决方案是一个无法伸缩的解决方案，那么会存在潜在的瓶颈。同样，网络防火墙可以以同样的方式成为共享服务，来保护多种Web页面，许多分析家相信应用程序安全性将会逐步成为一种共享服务模式。
从XML Web services中获取商业利益的念头会驱使IT经理们头脑发热。为了成功解决这些新问题，从创建支离破碎的安全系统（它们重点关注使用网络边界（network perimeter）来屏蔽封闭的业务系统）到实现一致的托管安全系统（它们重点关注管理应用程序级安全，以获得分布式、复杂的业务系统），经理们必须改变他们的思想倾向（请参阅侧栏“Web
Services: Who Should Care”）。虽然很多目前正在进行的试点项目只有很少的安全需求，但是随着网络使用的增长，需要确保这些网络是安全的，这一点对于构建具有成本效益并且安全的环境非常重要。也就是说，在开发过程中要尽早地考虑一些重要的系统需求，这对于确保安全通信是至关重要的。
----------------------------------------------------------------------------------------------------------------------------------------------------
关于作者
Andrew Yang是Westbridge Technology公司市场部的高级主管，该公司是XML Web services安全解决方案的提供商。Andrew曾为多家公司工作，其中包括DoubleClick、Oracle公司和Booz-Allen & Hamilton公司。您可以通过andy@westbridgetech.com与Andrew联系。
参考资料
作者简介：Mark O'Neill是Vordel公司的CTO，Vordel公司是一家Web services安全公司。Mark是Web servicesSecurity（Osborne/McGraw-Hill，2003年1月。IBSN：0-0722-2471-1）一书的作者，经常做XML和Web services安全方面的演讲。他经常出外旅游，但同时也尽量抽出时间来陪他在波士顿的妻子Kristen以及他们新出生的孩子Ben。
原文出处
http://www.ftponline.com/wss/2003_TE/magazine/features/ayang/