非传统安全威胁_ＳＯＡ的三个安全威胁

　　在当前如火如荼的SOA运动中，SOA的业务价值和架构方法成了所有人关注的焦点，而安全则被有意或无意的忽略。但是如果没有对安全的充分重视，SOA不仅解决不了现实的问题，反而会引起更大的麻烦。
　　
　　外部服务安全问题
　　
　　举个例子来说，一个SOA应用程序可能会依靠一个基于Web的第三方服务来提供重要的功能和服务，这具有非常明显的安全问题。不过这种问题在企业用户激活了微软的自动更新时就已经存在了。
　　从根本上说，这是一个信任的问题，例如你决定是否信任微软发送给你的更新程序。SOA可能会大大增加使用外部服务的次数，一个小时可能进行数百次这样的交互。
　　某些恶意的站点假装提供某种功能或服务，而欺骗某些人决定信任它。恶意软件通常伪装成有用代码，而且有时候也会提供一些它承诺的功能，但是同时又在悄悄的进行用户不希望的事情。
　　这是SOA可能会给企业带来的三个主要安全影响之一，反击恶意软件需要有个综合技术和教育的战略，无论它是与SOA相关的行为，还是企业中某个人从一个文件共享站点上下载“免费”音乐，这些行为都要受到约束。 在恶意软件感染企业网络之前，这个安全技术能够成功阻挡它们。但是最佳解决方案是教育用户具有安全风险意识，让他们知道未知站点的危险性，从而在第一位置将风险最小化。
　　
　　XML文件携带攻击代码
　　
　　第二个主要缺陷发生在企业对XML文件的使用中，它更具有技术性，而且难于被截获。从根本上来说，XML可以包含任何类型的数据或可执行程序，其中包含那些故意搞破坏的东西。今天的大多数企业已经在使用XML编码的文件，因此它们已经被处于无防护的状态下。
　　但是，SOA肯定会以数量级来增加传输的XML数量，这也就意味着安全缺陷的增加。而SOA架构中大量的这类传输也让IT人员难于截获偶尔出现的恶意软件。而且恶意软件日益复杂的技术已经非常清晰的告诉我们，攻击者可以让XML为它们所用。
　　在解决这种安全风险的时候，教育已经效果不大，因为它更有可能被注入到一个合法的数据包中来进入企业网络，甚至可能将自己分为好几部分，混在不同的合法通信中。用户可能没有进行任何错误的操作。这类有针对性的攻击正在变得越来越多。
　　但是，能够解决这个问题的产品已经出现，Crossbeam公司和Forum公司已经结成联盟，组合Crossbeam的X系列安全服务交换机、Forum的Xwall Web服务防火墙和Forum Sentry Web服务网关，推出一个单项最佳解决方案，来截获在XML和其他进入企业的数据流中截获恶意软件。
　　
　　身份验证问题
　　
　　第三个忧虑是企业身份管理的会话模式可能不满足SOA的更复杂要求。在一个简单的交易中，在会话开始的时候进行用户身份认证，然后这个认证就会应用在整个会话中。
　　但是，在SOA模型中，用户可能最初发动一个交易后然后从服务器断开，而交易可能会经过一组后端服务，因此用户没有与最终的交易有直接的联系。不仅要识别是谁发起了交易，还要识别是谁(或者在自动过程中是什么东西)批准和处理了这个交易。需要认证所有这些单个的进程在这个交易中使用的信息，而不是在一个交互的会话中询问它们的信息。这是一个到现在都没完全解决的问题，但是SOA增加了这种安全缺陷的程度。
　　因为SOA非常强大，而且可以被用来轻松地利用外部程序和其他外部可信任伙伴的程序，这种缺陷可能会变得非常大。企业需要谨慎地制定安全策略，加上对用户的安全意识培训，再辅以合适的技术，来将所面临的危险降到最小。
　　最好的解决这种问题的办法是使用Security Assertion MarkupLanguage来创建一个可以附加到交易中的代表性的身份。
　　安全性是SOA中的一个焦点问题，因为SOA强调机器与机器的交互，而大多数IT安全性都是基于人与机器的交互。身份验证和授权在这个环境中变得更加富于挑战性。
　　在未受保护的SOA中，想要阻止Web服务的未授权使用实际上是不可能的；未授权用户可以非常轻松地访问Web服务。Web服务不具备跟踪谁在使用它们或者谁被允许使用它们的固有功能。无法阻止不必要的监听和消息侦听。
　　未受保护的SOA让黑客有机会监听SOAP消息并看到私密信息。此外，在未受保护的SOA中，侦听SOAP消息并重新发送消息或转换消息内容要相对容易一些。
　　由于SOA架构的开放性本质，您无法保护SOA中未知的第三方。第二级和第三级用户(例如您的合作伙伴的合作伙伴)是可以访问未受保护的SOA的。因此，未受保护的SOA很容易超负荷运转。
　　如果没有访问控制，未受保护的用户提供可信身份验证的SAML断言。
　　Web服务应用程序代理在实际的Web服务中接收和处理SOAP请求，从而对安全性有所帮助。它的SOA很容易被来自黑客的大量SOAP消息所“淹没”。结果可能导致DoS攻击损害系统的正常功能。
　　在分析SOA安全性需求时，可以考虑实现一个支持SOAP消息监控、联邦身份验证、应用程序代理、契约管理、证书、密钥和加密以及审计记录的SOA安全性解决方案。这个清单似乎很长，但是事实上，如果缺少其中任何一项，SOA的所有优点都可能遭到破坏。
　　SOAP消息监控利用了一个SOAP拦截器模型，以便在将SOAP消息从调用系统发送给Web服务时对其进行侦听和监控。SOAP消息监控是SOA安全性的基础，因为它让安全性解决方案能够停止和分析每条消息，以进行用户身份验证和授权。
　　为了保护第三方，安全性解决方案利用联邦身份验证过程，从而提供对系统中用户进行身份验证的能力。最终将获得一个为Web服务可以使所有的用户都远离实际的服务。代理不仅可以减轻网络的负载，还可以为SOA提供一个额外的安全层。
　　契约管理是另一项对安全性有所帮助的SOA管理特性。契约确立了谁有权使用Web服务以及何时可以使用它。契约通过消除非契约方的使用，提高了SOA的安全性。
　　对于一个真正安全的SOA来说，证书、密钥和加密同样是必不可少的。最健壮的SOA安全性都源于实现了使用来自认证机构的私钥／公钥进行身份验证的加密消息传递。XML加密允许Web服务用户发送保留XML格式的加密SOAP消息。因此，系统实现了安全性，但却仍然基于标准。数字签名是加密模型的一种变体，它使得Web服务的用户可以创建一个惟一确认的数字“签名”，从而可以验证用户身份和确保消息数据的完整性。
　　最后，为了跟踪SOA的使用，有必要采用可以保存所有SOAP消息请求和响应的动态审计日志的SOA安全性解决方案。审计日志对于在SOA中研究安全性问题和诊断安全性漏洞，以及实现管理规章服从性，都是必需的。