简介
IBM WebSphere Application Server 的安全性在每个版本中都有所改进。除了在新版本中增加了一些新功能之外，我们还不断增强产品的默认安全性。我们通过改进默认设置不断提高满足默认安全性这一关键原则的程度。本文的前一个版本 主要关注 WebSphere Application Server V6 和那个版本所需的加强步骤。在后续 WebSphere Application Server 版本中，显著减少了加强步骤的数量，更重要的是，保留的大多数步骤变得不那么关键了。那篇文章的修订版 主要关注 WebSphere Application Server V6.1 以及针对 V7.0 的更新。因为 V6.1 与后续版本之间存在重大的差别，这些差别会使讨论复杂化，所有我们觉得从内容中删除 V6.1 的细节对更高版本的用户会有所帮助。现在，WebSphere Application Server 8.0 和 8.5 版已减少了必要的加强步骤，而增加的一些新功能会更改（或支持额外的）加强需求。因此，是时候用最新的信息来更新本文了。
本文首先简单讨论安全性为什么如此重要以及加强系统的困难，然后讨论如何加强 WebSphere Application Server 环境来解决各种安全性漏洞。因为本文主要讨论加强，所以一些信息是概括性的，没有进行详细分析。我们尽可能提供相关详细信息的适当参考资料，让您能够进一步研究相关的子主题。
尽管本文中的信息基于 IBM WebSphere Application Server V8.5 和 V8.0，但是讨论的大多数问题同样适用于 V7.0，但在某些情况下，WebSphere Application Server V8.0 对默认安全性设置进行了更改。对于某个版本特有的问题，我们会专门指出这些地方。随着时间的推移，我们对主要的 WebSphere Application Server 版本进行了产品更改，如果您使用的是 WebSphere Application Server V6 或更低版本，一定要参考 归档的文章，如果您使用的是 WebSphere Application Server V6.1，请参考 以前的文章。
配置文件备注
如果熟悉 V8.5 之前的 WebSphere Application Server，您就会知道必须要创建一个或多个配置文件。该配置文件可能是一个 Application Server（或 Base）配置文件、一个 Deployment Manager 配置文件等。在本文的剩余部分中，这些配置文件将称为 “完整” 配置文件。进行这样的区分是为了将这些配置文件与 V8.5 中新增的配置文件（Liberty 配置文件）进行对比。本文还提供了特定于新的 Liberty 配置文件的一些建议。
为什么需要安全性？
令人欣慰的是，大多数读者都能够认识到安全性是企业系统的一个关键方面。尽管如此，为了介绍一些考虑安全性的常用方法，我们仍将简要介绍一下安全性。
安全性的基本目的是 “阻止不怀好意的人进入您的系统”。更准确地说，安全性是一个过程，它应用多种技术来防止未经授权的用户（通常称为入侵者）对内容进行未经授权的访问。
有许多类型的入侵者：外国间谍机构、竞争对手、黑客，甚至是您自己的雇员。每个入侵者都有不同的动机、不同的技能和知识、不同的访问入口以及不同的需求级别。例如：
雇员可能对公司有攻击动机。雇员具有非常高的内部访问级别和系统知识水平，但他们的资源和黑客技能可能很有限。
外部黑客也许是安全性攻击方面的专家，但是他们对您可能没有攻击动机。
外国间谍机构可能对攻击您很感兴趣（这取决于您的业务）并拥有极其丰富的资源。
入侵者可能出于两个原因入侵您的系统：为了获取他们本不该拥有的信息，或者为了以某种方式改变系统的正常行为。在后一种情况中，通过改变系统行为，他们可以尝试执行对其有利的事务，或者只是为了用某种有意思的方式导致系统崩溃，从而造成对您的组织的损害。
关键在于，有很多不同类型的入侵者、很多不同的入侵动机以及（我们后面将会看的）许多不同的攻击类型。在规划安全性时，必须认识到这些。
同时关注内部和外部威胁
不应该仅将安全措施视为阻挡 “外人” 的大门。这是一种过于简单的观点。当前，许多组织将他们的安全措施完全集中在针对组织以外的人群，他们错误地认为只有外人才是危险的。实际上并非如此。对于大型公司，往往有数千人能够访问内部网络（其中许多人并不是雇员）。这些人都可能成为入侵者，而且由于他们在内部，所以他们访问网络会更方便。常常只需把笔记本电脑插上网线，就能够访问公司网络。一些研究表明，有将近一半的入侵是 由组织内部的雇员或者承包人（或涉及他们的人）造成的。
就算您相信网络中的每个人都是值得信任的，您能够相信他们永远不会犯错吗？考虑到通过电子邮件传播的病毒如此猖獗，而且基于 JavaScript 的攻击程序和其他程序很容易通过插入计算机的优盘和 CD 进入公司网络，从内部发起攻击，所以假设整个内部网络都是可信任的是一种鲁莽之举 —— 不能这样做。
安全措施应该努力保护系统不被所有的潜在入侵者攻击，这就是本文为什么如此之长的原因。安全性不仅仅是在网络边界上保护系统不受 “外部” 攻击的防火墙。它是一组旨在尽可能地加强系统安全的复杂操作和过程。
限制和现实状况
应该认识到没有完全安全的系统，这一点很重要。您的目标是在业务的约束下尽可能地保护系统。在考虑安全性时，理想情况下应该：
分析攻击的各个方面。
考虑每种攻击的风险。
确定攻击成功而导致安全性被破坏的可能性。
评估为防止每种攻击所付出的代价。
在估计安全性遭到破坏而造成的损失时，不要忘记安全性被破坏会导致系统用户对系统失去信心。因此，“安全性被破坏的代价” 可能包括非常高昂的间接代价（比如，失去投资者的信任）。
一些黑客入侵系统只是为了好玩，因此，如果创建了具有合理安全程度的环境，入侵者就会转向更容易的目标。
一旦完成上面列出的步骤，就可以对风险与成本进行适当的权衡。从本质上说，目标就是要让入侵者为入侵系统而付出的代价超过他们可以获得的利益，同时确保业务能够承受运行安全系统所付出的代价（参见边栏）。
归根结底，需要什么安全级别是一个业务决策，而不是技术决策。然而，作为技术人员，我们必须帮助所有各方理解安全性的价值和重要性。因此，除了保护内部应用程序免受攻击外，本文中建议的大多数安全性加强步骤的成本都相当低。大多数组织都应该都有能力实现它们。本文没有介绍比较复杂和昂贵的安全性方法 —— 强身份验证、审计和入侵检测等，它们超出了 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 资源的能力。
可以想像到，检查所有的系统边界和共享组件这一任务非常困难。此外，保护系统实际上需要充分考虑它的复杂性。关于安全性最困难的事情可能就是创建一个依靠抽象工作的安全系统。也就是说，良好抽象的原则之一就是，对更高层的组件隐藏所关注的问题。这正是人们所需要的一种非常好的做法。遗憾的是，入侵者并不友善。他们并不在乎抽象或者良好的设计。他们的目标是想尽办法入侵系统，所以他们会在您的设计中寻找漏洞。因此，为了验证系统的安全性，必须在每个抽象级别上考虑安全性：从最高的架构层到最低的详细实现层。尽管有许多应用程序扫描工具可以帮助检查代码（比如 IBM Rational AppScan），但是即使使用扫描工具，仍然需要对所有代码和设计决策进行手工检查，以防止应用程序受到攻击。需要对所有的内容进行严格的检查。
最小的错误也可能破坏整个系统的完整性。使用缓冲区溢出技术来控制基于 C/C++ 的系统就是这方面的最好例证。本质上，入侵者会传递一个大于现有缓冲区的字符串。因此，多出的信息会覆盖正在运行的程序的一部分，导致运行时执行本不应该执行的指令。请注意，通过这种方法，入侵者可以让程序做几乎任何事情。作为安全架构师，要想识别这种攻击，就必须深入理解 C/C++ 运行时如何管理内存并执行在运行的程序。即使您了解到缓冲区溢出问题的存在，仍然必须检查每一行代码，以发现此漏洞。目前，我们已经了解了这种攻击，但是它仍然能够获得成功，这是因为个别程序员制定了非常小的错误决策，该决策会危及整个系统的安全。幸运的是，这种攻击在 Java 中不奏效，但是其他小错误仍然可能导致系统受到威胁。
要对安全性进行认真的考虑；这是很难的。
查看本栏目更多精彩内容：http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/