内容


在 Web 服务上下文中使用 SLA,第 7 部分

用 SLA 保证来降低漏洞的风险

应用程序安全漏洞

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 在 Web 服务上下文中使用 SLA,第 7 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:在 Web 服务上下文中使用 SLA,第 7 部分

敬请期待该系列的后续内容。

引言

在本系列文章的第 1 部分中(参阅参考资料),我提到访问和响应时间作为两种 Web 服务特性,应该在公开 Web 服务前进行测试。在第 3 部分中(参阅参考资料),我向您展示了如何开发系统中断阀值,以作为提高您的 Web 服务满足 SOA 用户动态消费和生产的资源在运行时可用的 SLA 保证的一种方式。在这篇文章中,我将这些主题扩大为包括漏洞在内并且说明了为什么这一问题关系重大。

在第 4 部分中(参阅参考资料),我解释了企业如何将它们的安全管理集中到统一位置,以便对面向服务的架构中的多个 Web 服务以及相关的其它服务和应用程序的访问控制列表进行更好的管理。用访问控制表保护 Web 服务,然而,这并不能减轻 Web 服务(以及非 Web 服务)漏洞受到恶意攻击的危险。

在这篇文章中,通过在一定程度上考虑三对请求/响应类型:传送、漏洞探测以及补救,讨论了您应该掌握哪些关于用 SLA 减轻利用漏洞的风险的信息。介绍了在 Web 服务的请求或响应被中断和全部恢复之间的较长的时间间隔或大量较短时间间隔之和如何对已有保证的正常运行时可用性产生不利影响。缩小时间间隔很重要,这和将 Web 服务设计为与其它 Web 服务或与 SOA 中以最小中断或无中断方式提供信息的非 Web 服务进行交互一样重要。

评估漏洞

为了证实您将请求的漏洞信息是正确的数据,您需要按照三个简单的步骤评估漏洞。第一步是确定易遭到恶意攻击的关键系统资产——无形的或者有形的。

有形资产是您能够看到、感觉到或触摸到的对象。实例包括了 IBM® Thinkpad® R 系列以及 Websphere® Studio 系统管理员。无形资产是您无法看到、感觉到、或是触摸到,但与有形对象相比有额外价值的对象;例如,客户查询的响应时间作为 WebSphere Application Server 的附加值。

第二步是确定电脑黑客或攻击者可能恶意攻击的漏洞。第三步是提供补救措施,包括将安全装置恰当放置来降低漏洞被利用的风险。

获得信息

减少风险的方法之一就是使用 AVDL(参阅参考资料)或是另一种获得关于如何确定之前已知的漏洞,以及应该如何处理应用程序组件预期的漏洞的 XML 格式描述语言。实例包括操作系统类型/版本、Web 服务器类型、以及数据库类型。

另一种方法是通过 AVDL 获取信息,这些信息说明了会或者不会导致漏洞被利用的应用程序合法使用模式。实例包括目录结构、HTML 结构、以及合法的登录点。

中断阀值

请求初始化信息的时间与发送该请求响应的时间之间的不同能够影响当拒绝服务(DoS)或关键系统资源被破坏时是否进行保存。如果时间间隔很长,中断阀值将会对正常运行时间可用性产生不利影响。

和企业范围的 DoS 或关键系统资源被破坏相比,确定漏洞并在适当的位置采取经济实用的安全措施(例如灾难恢复计划以及日志备份系统)的代价要小得多。贸易伙伴应该及时地以极少中断或无中断的方式获得漏洞以及合法使用的信息。

一种保护 Web 服务避免恶意中断的方法是在 Web 服务中包括关于漏洞评估工具、应用程序安全网关、报表工具、相关系统以及纠正工具的信息。您利用 AVDL 可以完成该方法。规范中没有涉及网络层漏洞的信息,比如网络拓扑、TCP 相关的攻击,或网络层的其它问题。因为这些问题在 Security Assertion Markup Language(SAML)以及 eXtensible Access Control Markup Language(XACML)(参阅 参考资料)中有介绍,所以它没有讨论任何关于身份验证和访问控制的信息。

修改响应类型

AVDL 目前没有对为每一种响应类型包含中断阀值信息的问题进行处理。因为这一原因,我修改了 传送容器(transversal container)、漏洞探测(vulnerability probe)、以及补救(remediation)的概念,并在 AVDL 规范中进行讨论以处理这些问题。我将漏洞响应分成三类:

  • 漏洞传送容器
  • 漏洞探测容器
  • 漏洞补救容器

Web 服务用来发送请求和接收响应的往返过程中的任何延长的中断都备受关注。一个原因是它也许会产生能够影响 SLA 保证的中断阀值。

我观察了为应用程序下载大量补救文件时如何因为网络问题而造成多次中断。我不能在没有补丁(例如,防火墙协议)的情况下使用该应用程序。幸运的是,聪明的供应商在它的软件中设定了一种机制,对这批中断的地方附加了临时恢复点。

采用这种方式我可以在恢复点重新启动下载,而不是从头开始。在下载操作完成之后,应用程序的防火墙组件开始正常工作。对于这一事件来说中断阀值是很重要的。

漏洞容器

让我们检查一下三种容器,其中任意一种都与您在 Web 服务中用于描述应用程序安全漏洞的响应类型相关。

传送容器

漏洞传送容器只是 HTTP 上往返过程中请求响应对的视图。它是说明请求响应在何处进入 SOA 的图像。您在容器中至多可以有一对。这意味着您不能为每个容器建立一个以上的图像。如 图 1 所示,当在 SOA 中时,为了完成一个会话中的一系列任务,您可以拥有若干个容器。

图 1. 简单会话
简单会话

我讨论的是屏幕后的一个会话。当需要为屏幕之后的多个会话提供信息以减少漏洞风险时,您可以使用我所说的一个 human-facing 会话。对于 Web 应用程序的每个页面,您都可以有数个请求响应。

页面完成所有任务所需的容器个数取决于页面的复杂性及其内容。您需要包括关于确定漏洞传送的中断阀值重不重要的策略信息。我推荐应该创建日志来记录传送中断时间、恢复发生时间、每类中断发生次数、以及由此引发的中断阀值。

探测容器

每个漏洞探测容器都描述了 Web 应用程序的一个漏洞。与传送容器会话相似,漏洞探测会话可以包含多个容器,其中每一个容器仅由一对完成往返过程的请求响应组成。

探测容器比传送容器更进一步(参阅图 2)。探测会话由两个层次级别的容器组成,而传送会话仅由一个层次级别的容器组成。这意味着探测会话可以有多个协议,每个协议包含它自己的请求/响应对。

图 2. 两层会话
两层会话

您需要包括关于确定漏洞探测的中断阀值重不重要的策略信息。探测中断阀值日志能够与传送中断阀值日志相结合。

补救容器

补救包括安全措施,当它投入使用时,是用于关闭漏洞。在 XML 中,补救被指派了特定于补救的安全设置代码。它包括开放程序块,可以在程序块中用机器语言对补救措施进行硬编码。 如果预先考虑到补救代码会很长,那么也可以包含一些信息来说明在何处可以下载到补救代码来修改漏洞。

使用补救容器的问题是,当大量补丁按顺序依次下载的时候,常常存在一个或多个容器中的请求/相应对由于某些网络问题造成中断。虽然有在中断发生处附加恢复点的机制,但却没有一个机制来记录中断发生的时间,恢复发生的时间、恢复发生的时间,以及下载中断发生的次数。

您需要建立确定补救下载的中断阀值重不重要的策略。这个日志能够与在传送、探测以及补救过程中跟踪中断的日志结合起来,并计算中断阀值。我建议这个日志应该包括我在这个关于 SLA 保证的系列文章中提到的其他变量(参阅参考资料)。

结束语

减少在异构 SOA 中利用 Web 服务漏洞的风险需要提前制定计划,以解决请求/响应中断的问题,中断可能当漏洞以及补救信息在传送或下载时发生。开发人员应该同安全负责人或漏洞方面的专家进行沟通,讨论在 SLA 中可接受的水平上指定中断阀值的问题。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=144087
ArticleTitle=在 Web 服务上下文中使用 SLA,第 7 部分: 用 SLA 保证来降低漏洞的风险
publish-date=02012005