WebSphere Application Server V7、V8 和 V8.5 中的高级安全性加强1

0

系列内容：

配置文件备注

如果熟悉 V8.5 之前的 WebSphere Application Server，您就会知道必须要创建一个或多个配置文件。该配置文件可能是一个 Application Server（或 Base）配置文件、一个 Deployment Manager 配置文件等。在本文的剩余部分中，这些配置文件将称为 “完整” 配置文件。进行这样的区分是为了将这些配置文件与 V8.5 中新增的配置文件（Liberty 配置文件）进行对比。本文还提供了特定于新的 Liberty 配置文件的一些建议。

为什么需要安全性？

令人欣慰的是，大多数读者都能够认识到安全性是企业系统的一个关键方面。尽管如此，为了介绍一些考虑安全性的常用方法，我们仍将简要介绍一下安全性。

安全性的基本目的是 “阻止不怀好意的人进入您的系统“。更准确地说，安全性是一个过程，它应用多种技术来防止未经授权的用户（通常称为入侵者）对内容进行未经授权的访问。

有许多类型的入侵者：外国间谍机构、竞争对手、黑客，甚至是您自己的雇员。每个入侵者都有不同的动机、不同的技能和知识、不同的访问入口以及不同的需求级别。例如：

    雇员可能对公司有攻击动机。雇员具有非常高的内部访问级别和系统知识水平，但他们的资源和黑客技能可能很有限。

    外部黑客也许是安全性攻击方面的专家，但是他们对您可能没有攻击动机。

    外国间谍机构可能对攻击您很感兴趣（这取决于您的业务）并拥有极其丰富的资源。

入侵者可能出于两个原因入侵您的系统：为了获取他们本不该拥有的信息，或者为了以某种方式改变系统的正常行为。在后一种情况中，通过改变系统行为，他们可以尝试执行对其有利的事务，或者只是为了用某种有意思的方式导致系统崩溃，从而造成对您的组织的损害。

关键在于，有很多不同类型的入侵者、很多不同的入侵动机以及（我们后面将会看的）许多不同的攻击类型。在规划安全性时，必须认识到这些。

同时关注内部和外部威胁

就算您相信网络中的每个人都是值得信任的，您能够相信他们永远不会犯错吗？考虑到通过电子邮件传播的病毒如此猖獗，而且基于 JavaScript™ 的攻击程序和其他程序很容易通过插入计算机的优盘和 CD 进入公司网络，从内部发起攻击，所以假设整个内部网络都是可信任的是一种鲁莽之举 —— 不能这样做。

安全措施应该努力保护系统不被所有的潜在入侵者攻击，这就是本文为什么如此之长的原因。安全性不仅仅是在网络边界上保护系统不受 “外部” 攻击的防火墙。它是一组旨在尽可能地加强系统安全的复杂操作和过程。

限制和现实状况

应该认识到没有完全安全的系统，这一点很重要。您的目标是在业务的约束下尽可能地保护系统。在考虑安全性时，理想情况下应该：

1.    分析攻击的各个方面。

2.    考虑每种攻击的风险。

3.    确定攻击成功而导致安全性被破坏的可能性。

4.    评估为防止每种攻击所付出的代价。

在估计安全性遭到破坏而造成的损失时，不要忘记安全性被破坏会导致系统用户对系统失去信心。因此，“安全性被破坏的代价” 可能包括非常高昂的间接代价（比如，失去投资者的信任）。

一些黑客入侵系统只是为了好玩，因此，如果创建了具有合理安全程度的环境，入侵者就会转向更容易的目标。

一旦完成上面列出的步骤，就可以对风险与成本进行适当的权衡。从本质上说，目标就是要让入侵者为入侵系统而付出的代价超过他们可以获得的利益，同时确保业务能够承受运行安全系统所付出的代价（参见边栏）。

归根结底，需要什么安全级别是一个业务决策，而不是技术决策。然而，作为技术人员，我们必须帮助所有各方理解安全性的价值和重要性。因此，除了保护内部应用程序免受攻击外，本文中建议的大多数安全性加强步骤的成本都相当低。大多数组织都应该都有能力实现它们。本文没有介绍比较复杂和昂贵的安全性方法 —— 强身份验证、审计和入侵检测等，它们超出了 WebSphere Application Server 产品功能的范围。

安全性是一个很大的主题，本文不可能完全覆盖安全性的所有方面。本文不打算介绍安全性，或者说不是关于如何保护系统的教程。而是提供了涉及 WebSphere Application Server 安全性时需要考虑的核心技术问题的概述或检查表。本文中的信息应该与创建安全企业的更大型工作结合起来。

社会工程

由于这是一篇技术性文章，因此将重点讨论保护系统的技术解决方案，具体地说，主要集中于安全性难题的 WebSphere Application Server 部分。尽管如此，您应该意识到，使用社会工程技术来危害系统往往更简单。也就是说，通过欺骗组织中的工作人员，攻击者可以获取权限，以不当地手段访问系统和信息。从社会工程攻击技术可以得出的一个结论是：通过使用社会工程，攻击者可能来自您的网络内部。这再次强调了前面提到的观点：仅仅防御来自网络外部的攻击者是远远不够的。因此，这里的讨论集中于多个级别的安全性。每个级别防范不同的攻击类型，并提供对攻击者更有效的屏障。

总的系统观点：细节问题

在详细研究具体建议之前，我们先花一些时间来概述创建安全系统的基础技术。基本观点是着眼于每个系统边界或共享点，检查哪些参与者访问了这些边界或共享的组件。也就是说，假设存在这些边界（假设子系统内部比较可信），那么入侵者如何突破这些边界呢？或者，假定某些东西是共享的，那么入侵者是否可以采用不正当手段共享某些东西呢？

大多数边界是很明显的：网络连接、进程与进程的通信、文件系统、操作系统接口等等，但是有些边界不容易辨别。例如，如果一个应用程序使用了 WebSphere Application Server 中的 J2C 资源，那么必须考虑另一个应用程序试图访问这些资源的可能性。这是因为第一个应用程序和 WebSphere Application Server 之间以及第二个应用程序和 WebSphere Application Server 之间都存在系统边界。可能这两个应用程序都可以访问这个资源（实际上它们确实可以）。这可能是不合理的共享。

在 WebSphere Application Server 环境中，操作系统对 API 的保护的价值比较有限，因为它们是基于进程标识符的，由于应用服务器同时接受数千用户发出的请求，所以这是一个非常粗粒度的概念。

要防止各种形式的攻击，可以应用许多众所周知的技术。对于较低层的基于网络的攻击，可以应用加密和网络过滤。这样就可以拒绝入侵者查看或访问他们不应该看到的内容。还可以依赖操作系统提供的机制来保护操作系统资源不被滥用。例如，不希望普通用户级代码能够访问系统总线和直接读取内部通信。还可以利用大多数现代操作系统，对系统 API 进行可靠地保护（参见边栏）。在较高层面上，应该严格应用身份验证和授权。每个 API、每个方法和每个资源都可能需要某种形式的授权。也就是说，必须根据需求严格地限制对这些东西的访问。当然，如果没有可靠的身份验证，授权也就失去了它的价值。身份验证所做的事情就是可靠地判断调用者的身份。这里增加了可靠 这个词，这是因为容易被伪造的身份验证是没有价值的。

如果无法进行适当的身份验证和授权，那么只能采用巧妙的设计和过程来防止潜在的问题。我们就用这种方式来保护 J2C 资源。由于 WebSphere Application Server 没有对访问 J2C 资源提供授权机制，我们只好应用其他技术来限制（基于配置）应用程序以不正当的方式访问 J2C 资源的能力。