WebSphere Application Server V7、V8 和 V8.5 中的高级安全性加强，第 1 部分: 安全性加强的概述和方法

http://www.ibm.com/developerworks/cn/websphere/techjournal/1210_lansche/1210_lansche.html

 

简介

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 进入公司网络，从内部发起攻击，所以假设整个内部网络都是可信任的是一种鲁莽之举 —— 不能这样做。

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

限制和现实状况

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

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 资源的能力。

可以想像到，检查所有的系统边界和共享组件这一任务非常困难。此外，保护系统实际上需要充分考虑它的复杂性。关于安全性最困难的事情可能就是创建一个依靠抽象工作的安全系统。也就是说，良好抽象的原则之一就是，对更高层的组件隐藏所关注的问题。这正是人们所需要的一种非常好的做法。遗憾的是，入侵者并不友善。他们并不在乎抽象或者良好的设计。他们的目标是想尽办法入侵系统，所以他们会在您的设计中寻找漏洞。因此，为了验证系统的安全性，必须在每个抽象级别上考虑安全性：从最高的架构层到最低的详细实现层。尽管有许多应用程序扫描工具可以帮助检查代码（比如 IBM Rational® AppScan®），但是即使使用扫描工具，仍然需要对所有代码和设计决策进行手工检查，以防止应用程序受到攻击。需要对所有的内容进行严格的检查。

最小的错误也可能破坏整个系统的完整性。使用缓冲区溢出技术来控制基于 C/C++ 的系统就是这方面的最好例证。本质上，入侵者会传递一个大于现有缓冲区的字符串。因此，多出的信息会覆盖正在运行的程序的一部分，导致运行时执行本不应该执行的指令。请注意，通过这种方法，入侵者可以让程序做几乎任何事情。作为安全架构师，要想识别这种攻击，就必须深入理解 C/C++ 运行时如何管理内存并执行在运行的程序。即使您了解到缓冲区溢出问题的存在，仍然必须检查每一行代码，以发现此漏洞。目前，我们已经了解了这种攻击，但是它仍然能够获得成功，这是因为个别程序员制定了非常小的错误决策，该决策会危及整个系统的安全。幸运的是，这种攻击在 Java™ 中不奏效，但是其他小错误仍然可能导致系统受到威胁。

要对安全性进行认真的考虑；这是很难的。

 

回页首

安全性加强概述

J2EE 规范和 WebSphere Application Server 提供了一种用于实现安全系统的强大的基础架构。遗憾的是，许多人没有意识到创建基于 WebSphere Application Server 的安全系统的各种相关问题。这些信息有许多自由度和许多不同的来源，所以一些用户往往会忽视安全性问题，部署的系统不够安全。为了避免这种情况，本节对最关键的问题进行了总结。

安全性加强指的是通过配置 WebSphere Application Server、开发应用程序和配置其他各种相关组件，尽可能地提高安全性——实际上是防止、阻碍或减轻各种形式的攻击。要使安全性得到有效加强，了解攻击的形式非常重要。攻击应用服务器有四种基本方法：

• 基于网络的攻击：这些攻击依赖于对网络数据包的低层访问，试图通过修改通信流或者发现这些数据包中的信息来危害系统。
• 基于计算机的攻击：在这种情况下，入侵者已经可以访问运行 WebSphere Application Server 的计算机。对于这种情况，我们的目标是限制入侵者损害配置或者看到不应该看到的内容的能力。
• 基于应用程序的外部攻击：在这种情况下，入侵者使用应用级的协议（HTTP、IIOP、JMX、Web 服务等）来访问应用程序，可能通过 Web 浏览器或者其他类型的客户端来实现该访问。入侵者使用这种访问方式来试图超越应用程序的正常使用方法，做一些不正当的事情。关键是入侵者会使用定义良好的 API 和协议来进行攻击。入侵者并不一定在公司外部，而是从应用程序自身的外部执行代码。这些攻击类型是最危险的，因为它们需要的技能往往很少，并且只要有可用的 IP 连接，就可以从很远的地方实施攻击。
• 基于应用程序的内部攻击（也称为应用程序隔离）：在这种情况下，我们关心的是恶意应用程序的危害性。在这种情况下，多个应用程序共享相同的 WebSphere Application Server 基础架构，我们不能完全信任每一个应用程序。

为了帮助您将保护技术与这些攻击类别联系起来，每种技术使用以下图形代表这些漏洞：

• N：基于网络的攻击
• M：基于计算机的攻击
• E：基于应用程序的外部攻击
• I：基于应用程序的内部攻击

对于每种技术，可以使用适当的方块将加上底纹，这指出了该技术有助于防范的攻击类型。请记住，内部应用程序总是可以利用外部攻击方法进行攻击。因此，当已经标出 E（外部）时，就不会再明确地标出 I（内部）。

请注意，这里没有考虑另一种技术攻击形式：拒绝服务 (Denial of Service, DoS) 攻击。尽管它很重要，但是 DoS 攻击超出了本文的范围。防范 DoS 攻击需要完全不同的技术，这超出了应用服务器所能提供的范围。为了防范 DoS 攻击，需要考虑网络通信量监视器、速率限制器和入侵检测工具等。

加强方法

我们来讨论一下保护 WebSphere Application Server 基础架构和应用程序免受这四种形式的攻击时应该采取的各种已知的步骤。（这里说 “已知的” 步骤当然是因为可能还有其他漏洞没有被发现。）理想的情况下，可以将这些信息分成四个部分，每个部分对应于一种形式的攻击。遗憾的是，攻击并不完全按照这种界线来划分。有几种不同的保护技术可以防范多种形式的攻击，而有时一次攻击可能利用多种入侵形式来达到最终目标。例如，在最简单的情况下，网络嗅探能够用于获取密码，然后这些密码可以用于进行应用级攻击。因而，根据活动发生的时间或问题相关人员的角色，我们可以将安全加强技术组织成符合逻辑的结构：

• 基础架构：为了通过配置 WebSphere Application Server 基础架构尽可能地提高安全性而采取的措施。当基础架构已经构建完成并且仅涉及系统管理员时，通常会采取这些措施。
• 应用程序配置：应用程序开发人员和管理员所采取的措施，这些操作在部署过程中是可见的。本质上，这些是应用程序设计和实现决策，它们对 WebSphere Application Server 管理员可见，并且可以在部署过程中检验（可能有一些难度）。这一部分将介绍大量技术，以便进一步加强安全性的不足之处；安全性是每个参与应用程序设计、开发和部署的人员的责任。
• 应用程序设计和实现：开发人员和设计人员在开发期间所采取的对安全性至关重要的举措，但是这些措施对部署过程可能没有影响。
• 应用程序隔离：这将单独进行详细讨论，因为它涉及到的问题比较复杂。

在每个部分中，将按优先级顺序排列各种技术。当然，优先级是主观的，但是我们会尝试使用这种方法大致确定每个领域中所受威胁的优先级：

• 基于计算机的威胁比网络威胁的可能性小，因为生产环境中的计算机通常是限制访问的。如果您的环境中没有限制访问，那么这些威胁很有可能会出现，您首先应该限制对这些计算机的访问。
• 最严重的攻击是只使用 IP 连接进行的远程攻击。这意味着所有通信都必须是经过身份验证的。
• 要保护通信流，应该对其进行加密，但对 WebSphere Application Server 内部通信流进行加密不如对出入 WebSphere Application Server 的通信流进行加密那么重要。这是因为后一种通信流可能会穿越更多的节点，黑客可以在这些节点上窥探通信流。

 

回页首

SSL/TLS 概述

在本文的余下部分提到协议 SSL 或 TLS 时，都使用词语 “SSL”。在可以使用 SSL 协议的所有地方，也可以使用 TLS；实际上如果连接的两端都支持 TLS，那么在默认情况下就会使用 TLS。

SSL/TLS（后面统称为 SSL）是 WebSphere Application Server 安全性架构的一个关键组件，广泛用于安全通信。SSL 用于保护 HTTP 通信流、IIOP 通信流、LDAP 通信流、MQ 通信流、JDBC 通信流、WebSphere 消息引擎之间通过 SIBus 传输的消息流、J2C 和 SOAP 通信流。SSL 需要使用公钥/私钥对，对于 WebSphere Application Server，这些密钥存储在密钥存储库中。因为 SSL 对于保护基础架构具有重要作用，所以我们暂时离开本文的主线，介绍 SSL 的一些与 WebSphere Application Server 相关的重要方面。（本文特意做了简单介绍，只讨论正确配置 SSL 所需的关键点。）

公钥密码术 (Public Key Cryptography) 从根本上讲是基于公钥/私钥对的。这两个密钥在密码学意义上是相关联的。关键的问题是这些密钥是非对称的；使用一个密钥加密的信息可以使用另一个密钥来解密。私钥自然是私有的。也就是说，您必须始终保护私钥。如果其他任何人能够访问私钥，那么接下来他们就可以用该私钥来 “证明” 其身份，并以您的名义进行活动；私钥很像密码，只是更安全，更改比较困难。持有私钥就是身份的证明。公钥是密钥对的一部分，它可以与其他人分享。

只要有一种安全的方法可以将公钥分发给各方，这就足够了。由于没有这样一种全球公认的技术，所以公钥密码术引入了签名公钥的概念。签名公钥有数字签名（非常类似于人工签名）来表明签署者对公钥的担保。签署者保证与签名公钥相对应的私钥持有者就是由密钥识别的群体。这些签名公钥被称为证书。众所周知的签署者被称为证书授权方 (CA)。也可以使用相应的私钥签署公钥。这些被称为自签名 (self-signed) 证书。自签名证书的安全性不亚于由证书授权方签署的证书，只是乍看起来，它们显得不易于管理。

图 1 显示了使用 CA 创建和分发证书的基本过程；对于本例，证书用于通过 SSL 执行服务器身份验证。也就是说，服务器持有一个证书，用于向客户端表明其身份。客户端不持有证书，因此对 SSL 是匿名的。

在通过配置客户端让其信任 CA 颁发的所有证书之前，提前执行第 1-3 步。第 4-6 步提前在服务器上执行，使它能够在客户端中利用这种 CA 信任关系。当客户端启动一个对服务器的连接时，将执行第 7 步和第 8 步。

图 1. 服务器 SSL 身份验证：证书创建和分发

在查看此图时，请注意客户端必须持有签署服务器生成的公钥所用的证书。这是信任的关键部分。由于客户端信任它拥有的任何证书（在本例中包括 CA 证书），所以它信任 CA 签署的所有有效的证书。证明可能包括确保发放者是受信任的（如图 1 所示），检查证书是否过期（超过有效期），检查证书中定义的用途是否与它的实际用途匹配，以及检查证书是否已被撤销。

我们使用一种类比法来解释证明与验证之间的区别，可将证书想象为驾驶员的驾照。它们由各个省/州/国家发放。官员可通过检查发放国家（它是否一个受信任的省/州/国家？）来验证驾驶员的驾照，确认它没有被篡改（数字签名证明类似于物理检查），检查它是否过期，验证性别是否与持有人相符，持有人是否正将验证驾照用于与之对应的车辆类型（性别和类型：汽车、摩托车和卡车类似于证书扩展属性），最后检查持有人是否拥有未结算的支付款，类似于撤销检查。另一方面，验证驾驶员驾照是为了确认驾照上的照片（身份）与使用它的人相符。

值得注意的是，如果使用自签名证书，则需要手工地将这些自签名证书分发到每个客户端，而不是依靠可能已经在客户端中构建的众所周知的 CA 证书。这并非不安全，但是，如果有许多客户端，则需要将所有这些签名证书（每个服务器对应一个）分发到所有客户端，这会变得非常难以管理。只分发一个签署了许多证书的 CA 证书要容易得多；这些 CA 证书通常具有更长的寿命，客户端应用程序（比如浏览器）通常会在过期之前自动推出更新或替换证书。

信任强大的 CA 颁发的所有证书有一个重大缺陷。如果某个 CA 遭到破坏，那么很可能会导致严重的信任损失。2011 年，一家为大约 25% 的互联网站颁发证书的 CA (Comodo) 遭到攻击，此 CA 颁发的证书现在已值得怀疑。另一家 CA (Diginotar) 也遭到攻击，这导致该公司关闭；Diginotar 使用的所有证书现在已毫无用处。

对于使用 SSL 的服务器身份验证来说更是如此。在完成最初的握手阶段之后，SSL 实际上将改为使用在握手期间生成的机密密钥执行加密，通过这种方法保护通信通道，但具体的细节与本文无关。

当客户端向服务器验证其自身的身份时，虽然角色相反，但过程与此相似。为了让服务器对客户端进行身份验证（这通常称为客户端证书身份验证，在与服务器身份验证一起使用时称为双向 SSL 或 Mutual SSL），客户端必须持有一个私钥和相应的证书，而服务器必须持有相应的签名证书或客户端证书的副本。这对于它来说是举手之劳。请注意哪些内容是不必要的：SSL 证书身份验证仅确定证书的有效性，不会验证该证书代表谁。验证是 SSL 后处理的责任。这有着重要的意义，稍后我们将会看到。

总之，因为 SSL 使用证书身份验证，所以 SSL 连接的每一端都必须在密钥存储文件中持有适当的密钥。在配置 SSL 密钥存储库时，需要考虑哪一群体需要遵守哪些密钥的基本规则。通常，这会让您知道自己需要什么。

只使用 SSL 限制访问

正如刚刚提到的，一旦 SSL 检验过证书，从 SSL 的角度来看，身份验证过程已经结束了。接下来理想的情况应该是让另一个组件查看证书中的身份，然后使用该身份制定授权决策。授权决策可以是让客户端确认服务器是可信的（Web 浏览器只要核实证书中的名称与 Web 服务器的主机名称相同，就可以确认服务器是可信的），也可以是让服务器提取用户名，然后使用它为以后的授权决策创建证书（WebSphere Application Server 在对用户进行身份验证时采取的就是这种方式）。遗憾的是，并非所有的系统都有这样的功能。对于这样的系统，可以利用流行的 SSL 技巧：限制有效的证书。

在前面涉及客户端身份验证的场景中，客户端提供了一个证书，然后服务器可以根据可信的证书签署者集对其进行检验。一旦检验通过，SSL 握手就完成了。如果限制服务器上可信的签署者，就可以限制谁能完成 SSL 握手。在自签名证书的极端情况下，可以创建只有一个签署者的情形：只有一份自签名证书。这意味着只有一个有效的客户端私钥可以用于连接此 SSL 端点：即在创建自签名证书时生成的私钥。通过这种方式可以轻松地限制谁能通过 SSL 连接到系统，即使服务器端组件不提供授权。可以将这看作是在网络层上创建安全的可信隧道。我将此理念称为 “SSL 隧道技巧”。假设一切都已正确配置完成，那么只有特定的可信客户端才可以通过这一通道建立连接。这在 WebSphere Application Server 中的几种情况下非常有用，这一点我们后面将会讨论。

管理 SSL

正如我们已经看到的，WebSphere Application Server 在密钥存储文件中管理密钥。有两种类型的密钥文件：密钥存储库和信任存储库。根据约定，信任存储库只不过是仅包含可信签署者的密钥存储库。因此，应该将 CA 证书和其他签名证书放入信任存储库中，并将私有信息（包含私钥的个人证书）放入密钥存储库中。

遗憾的是，这个简单的系统存在一个问题。大多数 WebSphere Application Server 都使用 PKCS12 格式。（事实上，WebSphere Application Server SSL 配置支持三种现代密钥数据库格式：JKS、JCEKS 和 PKCS12。）IBM HTTP Server 和 WebSphere Application Server Web 服务器插件使用了一种比较老的密钥格式，KDB 格式（更准确地说是 CMS 格式）。这两种格式在功能上相似，但在格式上不兼容。因此，必须注意不能将它们弄混。

WebSphere Application Server SSL 配置

从 WebSphere Application Server V6.1 开始，产品中为 管理证书和 SSL 提供了健壮的基础架构。本文的其余部分假设您熟悉这些基础架构。

 

回页首

加强 WebSphere Application Server

WebSphere Application Server V6.1 和更高版本的设计原则是遵守默认情况下的安全性的安全性原则。尽管这个目标尚未完美实现，但已经针对该目标发布了一个产品，在大多数常见的配置环境和更简单的环境中，该产品默认情况下具有合理的安全水平。显然，复杂的环境会产生难以预料到的独特问题，但是对于比较简单的环境，我们的目标是让默认的安装和配置能够提供合理的系统安全水平；没有完全安全的系统，因为这样的东西是不可能存在的。我们也不会试图消除每个漏洞，因为许多漏洞的风险很小，而且在默认情况下封闭它们会显著增加应用程序开发、管理或兼容性的复杂程度。但是，如果我们认为，对于大多数客户端，可以采用某种方式合理地消除某个漏洞，我们就是会怎样做的。

管理安全和 Liberty 配置文件

第一次（或者可能第二次）查看 Liberty 配置文件时，您可能会注意到，我们没有启用管理安全。WebSphere Application Server 产品在以前的版本中竭尽全力从默认不安全模式改进为默认安全模型（从 V6.1 开始）。乍看起来，Liberty 配置文件安全状态看起来可能是一大退步。但是，Liberty 配置文件与完整配置文件（Base 和 Network Deployment）之间存在着一项重要、关键的区别。完整的 WebSphere Application Server 配置文件被设计为通过管理控制台、wsadmin、JMS 访问和一个完整配置文件中存在的各种服务器间通信路径进行远程管理。

V8.5 Liberty 配置文件管理模型基于运行配置文件的服务器上的文件的 OS 级读/写访问（请注意，如果您拥有对完整 WebSphere Application Server 配置文件的类似的 OS 级访问权，那么您会拥有单元的总体管理控制权；通过编辑 security.xml 文件，可以更改其他所有设置）。通过添加一个 JMX 连接器功能，可以启用 Liberty 配置文件中的远程管理访问：

• localConnector-1.0 功能要求 JMX 客户端应用程序在同一个主机上使用同一个 OS 用户 ID 运行。
• 可启用 restConnector-1.0 功能，让 JMX 客户端能够远程访问服务器。

在启用 restConnector-1.0 功能时，ssl-1.0 和 appSecurity-1.0 功能都会动态启用，以确保远程访问是默认安全的，这类似于完整配置文件。此外，当启用其中一个连接器时，必须向 Liberty 配置文件配置中添加一个管理用户，否则连接器无法验证和连接 Liberty。

基于基础架构的预防措施

在保护基础架构时，首先必须了解要保护的组件。与任何漏洞分析一样，我们从确定组件及其外部通信路径开始。（这一分析不会揭示内部应用程序漏洞，但会揭示其他大多数漏洞。）这有助于检查标准的 WebSphere Application Server 拓扑（完整配置文件），并了解所有网络链接和协议（参见图 2）。方框中带阴影的项是与 Liberty 配置文件相关的组件。作为关注安全性的人员，您需要了解所有这些链接并专注于保护它们。这些链接代表前面提到的粗粒度系统边界。

图 2. 网络链接图

在图 2 中，链接上的字母表示在那些通信链接上使用的协议。对于每个协议，我们列出了其用途，并提供了一些关于防火墙友好性的信息，因为这对于后面的讨论十分重要。协议如下：

• H = HTTP 通信流
  • 用途：浏览至 Web 服务器、从 Web 服务器到应用服务器的通信以及管理 Web 客户端。
  • 防火墙友好。
• W= WebSphere Application Server 内部通信
  • 用途：管理客户端和 WebSphere Application Server 内部服务器管理通信流。WebSphere Application Server 内部通信使用以下几种协议之一：
    • RMI/IIOP 或 SOAP/HTTP：管理客户端协议是可配置的。
    • 文件传输服务（dmgr 到节点代理）：使用 HTTP(S)。
    • DCS (Distributed Consistency Service)：使用专有协议。用于内存到内存复制、有状态会话 EJB、动态缓存和高可用性管理器。
  • SOAP/HTTP 防火墙友好。DCS 可以是防火墙友好的。
• I = RMI/IIOP 通信
  • 用途：EJB 客户端（独立的客户端和 Web 容器）。
  • 由于使用了动态端口和嵌入式 IP 地址（这会影响防火墙执行网络地址转换），所以通常防火墙对其不太友好。
• M = SIB 消息传递协议
  • 用途：从 JMS 客户端到消息传递引擎的通信。
  • 协议：专有协议。
  • 防火墙友好，因为可以指定使用的端口。防火墙很可能对 NAT 不友好。
• MQ = WebSphere MQ 协议
  • 用途：MQ 客户端（实际客户端和应用服务器）。
  • 协议：专有协议。
  • 防火墙可用（有大量端口可供考虑）。请参阅 WebSphere MQ support pac MA86。
• L = LDAP 通信
  • 用途：WebSphere Application Server 对注册表中的用户信息进行验证。
  • 协议：按照 LDAP RFC 中的定义进行格式化的 TCP 流。
  • 防火墙友好。
• J = 通过厂商 JDBC 驱动程序进行的 JDBC 数据库通信
  • 用途：应用程序 JDBC 访问和 WebSphere Application Server 会话数据库访问。
  • 协议：每个数据库专有的网络协议。
  • 防火墙方面取决于数据库（通常是防火墙友好的）。
• S = SOAP
  • 用途：SOAP 客户端。
  • 协议：通常为 SOAP/HTTP。
  • 当使用 SOAP/HTTP 时防火墙友好。

如图 2 所示，典型的 WebSphere Application Server 配置有大量网络链接。WebSphere Application Server V8.5 包含按需路由器 (ODR)，以前仅在 IBM WebSphere eXtreme Scale 中提供。ODR 引入了一些必须考虑的新网络链接。

尽可能地保护每个链接上的通信流以防范入侵者，这是非常重要的。在这部分剩下的内容中，将讨论保护刚刚描述的基础架构所需的步骤。下面的列表按优先级次序列出每个步骤。最重要（最关键）的措施列在最前面。靠后的措施重要性逐渐降低。由您决定您的组织应该完成这个列表中的哪些措施。

1. 将 Web 服务器放在 DMZ 中，但是不放置 WebSphere Application Server
2. 将生产网络与内部网隔离开
3. 不要将 ODR 放在 DMZ 中
4. 对浏览器访问使用 HTTPS
5. 保持补丁和修复最新
6. 启用应用程序安全性
7. 使用 ldapRegistry 代替 quickStartSecurity 或 basicRegistry
8. 限制对 WebSphere MQ 消息传递的访问
9. 加强 Web 服务器和主机
10. 删除 Web 服务器和插件安装程序遗留的 JRE
11. 加强代理
12. 谨慎地配置和使用信任关联拦截器 (trust association interceptor)
13. 谨慎地使用证书身份验证
14. 考虑对 Web 服务器到 WebSphere Application Server 的 HTTP 链接进行身份验证
15. 不要在生产环境中运行示例
16. 选择合适的进程身份
17. 保护配置文件和私钥
18. 加密从 WebSphere Application Server 到 LDAP 的链接
19. 确保只通过 HTTPS 传输 LTPA cookie
20. 确保定期改变 LTPA 加密密钥
21. 不要在命令行上指定密码
22. 为基于文件的 VMM 密码增加附加数据
23. 为生成的证书使用更长的密钥
24. 创建单独的管理用户 ID
25. 利用管理角色
26. 考虑加密 Web 服务器到 Web 容器的链接
27. 加密 WebSphere MQ 消息传递链接
28. 加密 Distribution and Consistency Services (DCS) 传输链接
29. 保护从应用服务器到数据库的链接
30. 考虑把 cookie 限制为 HTTP Only
31. 通过培训让用户正确地理解证书警告
32. 考虑限制 HTTP 数据的大小
33. 谨慎地限制可信的签署者
34. 强制 CSIv2 传输使用 SSL
35. 考虑端口过滤
36. 考虑 SSL 主机名验证
37. 禁用不使用的端口
38. 考虑禁用密码缓存
39. 考虑启用 FIPS 140-2 或 SP800-131 遵从性

1. 将 Web 服务器放在 DMZ 中，但是不放置 WebSphere Application Server

在典型的 DMZ 配置中，有一个外部防火墙、一个包含尽可能少的组件的 DMZ 网络以及一个保护内部生产网络的内部防火墙。

DMZ（参见边栏）有三个基本原则需要考虑：

• 来自外部的入站网络通信流必须终止于 DMZ 中。网络传输负载平衡器（例如 Network Dispatcher）自身并不满足这个要求。
• 从 DMZ 到内部网的通信流类型和开放端口数量必须进行限制。
• 必须对在 DMZ 中运行的组件进行加强，并遵循最少功能和最低复杂度的原则。

因此，一般将 Web 服务器放在 DMZ 中，将 WebSphere Application Server 应用服务器放在内部防火墙内。这种做法比较理想，因为这可以使 Web 服务器具有非常简单的配置，需要的软件也很少。DMZ 的另一个作用是终止入站请求。最后，内部防火墙上必须开放的惟一端口是用于目标应用服务器的 HTTP(S) 端口。这些步骤使 DMZ 对攻击者的防范非常严格。如果愿意，也可以把安全的代理服务器放在 DMZ 中，替代 Web 服务器或与 Web 服务器共存。

如果把 WebSphere Application Server 放在 DMZ 中的计算机上，则必须在那些计算机上安装更多的软件，并且必须在内部防火墙上开放更多的端口，使 WebSphere Application Server 可以访问生产网络。这极大地降低了 DMZ 的价值。

可以在 DMZ 中放置 Web 服务器以外的其他组件。将安全代理放在 DMZ 中也是合理的，比如 IBM Tivoli® Access Manager WebSEAL、WebSphere Application Server V7 安全代理或 IBM WebSphere DataPower® 等加强了安全保护的组件。关键是放在 DMZ 中的组件不能是复杂的应用服务器，必须加强安全保护，还必须终止入站连接。

2. 将生产网络与内部网隔离开

现在，大多数组织都了解 DMZ 将 Internet 上的外人与内部网隔离开的价值。然而，很多组织没有意识到许多入侵者都来自内部。正如前面所提到的，需要同时防范来自内部和外部的威胁。正如保护自己免受来自大量不可信的 Internet 用户的攻击一样，您还应该保护生产系统免受大量不可信的内部网用户的攻击。

可以使用防火墙将生产网络与内部网络隔离开。这些防火墙看似比面向 Internet 的防火墙随意得多，但仍然能够防御许多形式的攻击。通过应用这一步骤和前一步骤，应该可以建立图 3 所示的防火墙拓扑。（有关 WebSphere Application Server 防火墙端口分配的更多信息，请参阅WebSphere Application Server V5 中的防火墙端口分配。）

请注意，我们在防火墙的边缘放置了 wsadmin。这样做是为了试图说明，虽然最好只在生产网络中（受保护的区域内）运行 wsadmin，但也可以将 wsadmin 访问限制为与管理员桌面对应的特定地址，从而轻松地穿过防火墙访问 wsadmin。图 3 还在边缘上显示了 EJB 客户端，因为它们可能位于防火墙的任意一侧。

图 3. 推荐的防火墙配置

这里只显示了单个防火墙，并没有显示面向内部网的整个 DMZ，因为这是最常见的拓扑。但是，完整的 DMZ（以及内部 DMZ 中的 Web 服务器）越来越常见，它们保护生产网络免受来自非生产内部网的攻击。这的确是一种合理的方法。

如果使用按需路由器功能，请查看下一个加强技巧。

3. 不要将 ODR 放在 DMZ 中

WebSphere Application Server V8.5 包含按需路由器 (ODR)，以前仅在 WebSphere eXtreme Scale 中提供。ODR 是一个基于 Java 的系统，具有上一个主题中提及的所有问题。使用 ODR 的安全拓扑如图 4 所示。而且，不支持将 ODR 放在 DMZ 中。

图 4. 按需路由器放置

图 4 显示了基于 Java 的 ODR 服务器的放置，这与 IBM DataPower SOA Appliances 的应用程序优化 (AO) 功能所提供的按需路由功能截然不同。尽管 Java ODR 不应放在 DMZ 中，但 DataPower SOA 设备是一个适合放在 DMZ 中的加强的设备。

4. 对浏览器访问使用 HTTPS

虽然可以通过未加密的通道发送 LTPA 令牌，但是为了最大程度地保护它们，最好通过加密链接发送它们。如果 LTPA 令牌被成功截获，那么窃取者可以冒充该用户的身份，直到令牌到期为止。

如果站点要执行任何身份验证或者有任何应该保护的活动，则需要对从浏览器到 Web 服务器的访问使用 HTTPS。如果不使用 HTTPS，那么密码、用户活动、WebSphere Application Server 会话 cookie 和 LTPA 安全令牌（参见边栏）等信息可能被入侵者看到，因为通信流要穿过外部网络。

对于在执行身份验证之前允许 HTTP 通信流的应用程序，一定要密切注意 cookie。如果某个 cookie（比如 JSESSIONID）是在使用 HTTPS 之前设置的，那么在使用 HTTPS 之后，该 cookie 可能带来风险，因为入侵者可能已经修改或捕获了它。这正是 WebSphere Application Server 对经过身份验证的用户使用单独的 cookie 的原因。另一种更狡猾的攻击方式是，入侵者可以修改通过 HTTP 返回的任何页面——甚至包括页面中嵌入的 URL。因此，用户可能会单击页面上看似安全的 URL，但他实际上会被转到入侵者的站点上。

5. 保持补丁和修复最新

本文假设您已应用了最新的补丁包（在撰写本文时，最新的补丁包是 7.0.0.25、8.0.0.4 和 8.5.0.0，请参阅 最新的 WebSphere Application Server 修复包），以及最近发布的所有安全 APAR。这些补丁包和 APAR 解决或堵住了本文未提到的其他漏洞，所以要确保系统处于最新的修复级别并确认应用了所有已知漏洞的补丁，这非常重要。当然，随着时间的推移，应该经常关注新发布的安全修复。毫无疑问，以后还会不断发现新问题。

与其他复杂产品一样，IBM 会不时地发现和修复 WebSphere Application Server、IBM HTTP Server 和其他产品中的安全性 bug。保持这些修复最新非常重要。建议订阅您使用的产品的支持公告板，对于 WebSphere Application Server，需要经常访问您的版本的 安全公告网站。这些公告板常常包含最近发现的安全性 bug 和修复通知。可以肯定的是，潜在的入侵者会很快得知那些安全性漏洞。您越早采取行动越好。

在 WebSphere Application Server 安全 页面上，可以找到关于 WebSphere Application Server 安全性的一般性信息，包括对加强 WebSphere Application Server 基础架构的建议。

6. 启用应用程序安全性

在默认情况下，WebSphere Application Server 完整配置文件的定义中启用了管理安全性。因此，在大多数情况下，基础架构会在默认情况下为管理通信流提供合理的身份验证、授权和加密。在启用管理安全性时，部署管理器和应用服务器之间的 WebSphere Application Server 内部链接以及从管理客户端（Web 和命令行）到部署管理器的通信流是经过加密和身份验证的（参见图 3）。这意味着，在运行管理工具时，需要对管理员进行身份验证。后面会讨论一些例外情况。

除了在管理方面利用应用服务器的安全性之外，强烈建议在应用程序安全性方面利用它。这样做可以让应用程序能够访问强大、健壮且基于标准的安全基础架构。在没有利用应用服务器安全性的应用程序中，常常会发现很严重的安全性漏洞。设计和实现安全的分布式基础架构并不容易。

要想启用应用程序安全性，应该进入全局安全性面板，并选择 Enable application security（不需要启用 Java 2 安全性；正如后面讨论的，它通常不适用），参见图 6。

图 5. 应用程序安全性

在 V8.5 Liberty 配置文件中，通过将清单 1 中所示的元素包含在配置文件的 server.xml 文件中来启用应用程序安全性。

清单 1. 在 Liberty 中启用应用程序安全性

<featureManager>
     <feature>appSecurity-1.0</feature>
</featureManager>

警告：仅仅启用应用程序安全性并不能确保应用程序是安全的。这只是让应用程序能够利用应用服务器提供的安全特性（包括 Java EE 安全性）。后面会进一步讨论这个主题。

7. 使用 ldapRegistry 代替 quickStartSecurity 或 basicRegistry 元素

Liberty 配置文件在设计时采用了极简理念。为了给希望测试其应用程序是否兼容安全性的开发人员提供轻松支持，可以使用一个包含单个用户 ID 和密码的 quickStartSecurity 注册表。basicRegistry 允许定义多个用户和组。这两个安全注册表都包含在 server.xml 内。

上述两个简单的注册表在开发人员的个人环境中已经够用。在测试环境外，这些 Liberty 配置文件应配置为使用 ldapRegistry 功能。

8. 限制对 WebSphere MQ 消息传递的访问

如果使用 WebSphere MQ 作为消息传递提供者，则需要通过其他技术来提供队列授权。在使用客户端/服务器模式时（绑定模式依赖于计算机中的进程到进程身份验证），默认情况下 WebSphere MQ 不会执行任何用户身份验证。事实上，当您在连接工厂上为 WebSphere MQ 指定用户 ID 和密码时，这些值会被 WebSphere MQ 忽略。

WebSphere MQ 安全警告

因为本文主要关注 WebSphere Application Server 安全性，所以这一节只讨论如何保护从应用服务器到 WebSphere MQ 的链接。这并不能保证 WebSphere MQ 本身是安全的。关于如何正确地保护 WebSphere MQ，请参阅 WebSphere MQ 安全性炙手可热。

解决这个问题的一种方法是，在 WebSphere MQ 服务器端实现自己的自定义 WMQ 身份验证插件，对 WebSphere Application Server 发送的用户 ID 和密码进行验证。第二种（可能更简单的）方法是，将 WebSphere MQ 配置为使用 SSL 进行客户端身份验证，然后确保只有 WebSphere Application Server 服务器持有用于连接 WebSphere MQ 的证书。（有关的更多信息，请参阅 保证 WebSphere Application Server 和 WebSphere MQ 之间连接的安全；本文有点儿过时，但相同的原理和技术也适用于这两个产品的新版本。在实现其中提到的技术时，应该考虑到产品的变化。）

9. 加强 Web 服务器和主机

如果采用 步骤 1 中推荐的标准拓扑，那么 Web 服务器是在 DMZ 中运行的。因为 DMZ 是防范潜在入侵者的第一道防线，所以必须特别注意加强此服务器。

本文不讨论加强 Web 服务器 的具体方法，但您应该在操作系统加强、限制装载的 Web 服务器模块和其他 Web 服务器配置步骤上下足功夫。（有关的更多信息，请参阅 Apache hardening information 和图书 Building Secure Servers with LINUX。）

在加强 Web 服务器时，有一个 WebSphere Application Server 特有的问题需要考虑。通过 WebSphere Application Server 管理基础架构来管理 Web 服务器是有可能的。虽然它便于使用看似是一件好事，但这却带来了严重的安全问题。有两种方式可以管理 Web 服务器：

• 使用托管节点要求在 Web 服务器（通常位于 DMZ 中）上放置一个节点代理，而且要求使用该代理作为 WebSphere Application Server 计算单元的一部分。这从安全角度来看是完全不可接受的，因此不应该使用，除非在极少数不需要 DMZ 的情况下。这种方式不可接受的原因有两点：
  • 首先，节点代理是计算单元的一个全功能成员，因此它有完全的管理权限。如果它在 DMZ 中遭到攻破，那么整个计算单元都会受到侵害。
  • 第二，WebSphere Application Server 是一个强大的大型产品，因此很难加强安全性，这样的产品不应该放在 DMZ 中。
• 第二种方式要求使用 IBM HTTP Server 和配置 HTTP 管理服务器。在这种情况下，部署管理器将管理请求发送给在 Web 服务器主机上运行的 HTTP 管理服务器。尽管这是一种比采用基于 Java 的节点代理更好的方法，但是许多人仍然认为这种做法存在风险，最好根本不在 DMZ 中提供管理功能。

10. 删除 Web 服务器和插件安装程序遗留的 JRE

在安装 IBM HTTP Server 时，安装程序会遗留一个 JRE。应该删除此 JRE，因为它提供的功能是 Web 服务器或插件在正常情况下所不需要的。请记住，这样做之后，将不能在此 Web 服务器上运行 ikeyman 等工具。我们不认为这个问题很重要，因为在 DMZ 中运行这样的工具并不合适。

当使用 IBM 安装程序安装 WebSphere Application Server HTTP Server 插件时，也会遗留一个 JRE。同样，在完成安装后，应该删除此 JRE。

如果您决定删除 JRE，那么应该做一下备份，以防将来使用。一种方法是对该 JRE 执行 zip 或 tar，并在以后需要时将它放回原处（例如，在应用补丁时，WebSphere Application Server 更新安装程序需要它），然后对其执行 zip/tar，并在过程结束时再次将其删除。

11. 加强代理

如果把安全代理服务器放在 DMZ 中，替代 Web 服务器（或与 Web 服务器共存），那么前面的建议也适用于这个代理，但是这里并不打算提供具体细节，因为具体的加强方法与代理相关。

关于 WebSphere DataPower 的一个要点是：Web 安全代理通常并不适用于代理 Web 服务通信流，因为它们无法阻止在传输 XML 时可能出现的威胁。要提供安全的 Web 服务（或任何基于 XML 的协议），可 使用 XML 防火墙，比如 WebSphere DataPower。

12. 谨慎地配置和使用信任关联拦截器 (trust association interceptor)

TAI 经常用于让 WebSphere Application Server 能够识别来自 Web SSO 代理服务器（例如 Tivoli Access Manager WebSEAL）的现有身份验证信息。这通常没什么问题。然而，在开发、选择和配置 TAI 时需要特别注意。TAI 会扩展信任域。目前 WebSphere Application Server 信任 TAI 以及 TAI 所信任的所有内容。如果 TAI 开发或配置不正确，就有可能彻底危害 WebSphere Application Server 的安全性。如果您自行开发 TAI，则需要确保 TAI 仔细检验请求中传递的参数，并确保以可靠的方式进行检验。我们曾经见过 TAI 做蠢事，比如直接接受 HTTP 头中的用户名。这是没用的，除非确保 WebSphere Application Server 收到的所有通信流都是通过身份验证代理发送的。例如，使用 前面 描述的技术。这样身份验证代理总是会覆盖客户端设置的 HTTP 头，因为可以伪造 HTTP 头。

• WebSEAL TAI 配置

  为了说明仔细配置的重要性，本文将详细讨论 IBM 提供的遗留 WebSEAL TAI，但任何 TAI 都需要认真设计和配置才能获得安全性。对 WebSphere Application Server 和 Tivoli Access Manager WebSEAL 之间的信任关系进行合理的配置是创建安全配置的关键。要创建安全配置，就必须对 WebSphere Application Server 和 WebSEAL 都执行一些步骤。在 WebSphere Application Server 中，必须对 Web 容器配置和 WebSEAL TAI 配置都进行合理的设置。

  这两种产品之间的信任关系是很重要的，因为 WebSphere Application Server 中的 WebSEAL TAI 接受来自 WebSEAL 的身份断言。如果可以攻破该链接，入侵者就可以断言任何身份，并彻底破坏基础架构的安全性。WebSphere Application Server 和 WebSEAL 之间的信任关系可以通过以下两种机制之一建立：相互 SSL 身份验证和基于密码的身份验证。这两种机制在安全的环境中都适用。然而，每一种机制都必须进行合理的配置，否则可能会出现严重的安全问题。在每种机制中，WebSEAL 都将最终用户的用户 ID 作为 iv-user 头在 HTTP 请求中发送。这两种配置的区别在于 WebSEAL 向应用服务器证明自身的方式。

• WebSEAL 密码配置

  在使用密码身份验证时，WebSEAL 会将其用户 ID 和密码作为基本的 auth 头在 HTTP 请求中发送（该用户的用户 ID 位于 iv_user 头）。基于密码的身份验证在两个地方配置。首先，对于要配置的汇合点，必须配置 TAM WebSEAL，以便将其用户 ID 和密码发送给应用服务器。当然，此密码是机密的，必须小心保护。WebSEAL TAI 在收到密码时会根据注册表对其进行检验。

  然而，这一点很不起眼，容易被忽视。如果在 WebSEAL TAI 属性中没有设置 LoginId 属性，TAI 就会检验从 WebSEAL 发送出来的用户 ID 和密码组合；如果它是任何有效的用户 ID 和密码组合，则会信任它。这种配置是不安全的，因为这意味着知道任何有效用户 ID 和密码组合的任何人都可以连接到 WebSphere Application Server，并断言任何用户的身份。在指定 LoginId 属性时，WebSEAL TAI 会忽略基本 auth 头中的入站用户 ID，并检验 LoginId 和 WebSEAL 密码组合。在这种情况下，能够从 WebSEAL 发出的有效密码只有一个（大概接近于受保护的机密）。当然，应该配置从 WebSEAL 到应用服务器的 SSL，以确保该机密密码不会以明文形式发送。

• WebSEAL mutualSSL 配置

  Mutual SSL 是通过三个单独的非常重要的步骤配置的：

  1. 必须把 WebSEAL 配置为使用 SSL 与 WebSphere Application Server 进行通信，而且该 SSL 配置必须包含只有 WebSEAL 才知道其私钥的客户端证书。
  2. 必须配置应用服务器 Web 容器，以便执行客户端证书身份验证。还必须更改其信任存储库，使之仅包含 WebSEAL 正在使用的客户端证书。这个步骤至关重要，因为只有这样才能保证对应用服务器 Web 容器的请求仅来自 WebSEAL，而非某个入侵者（仅仅使用相互身份验证的 SSL 是不够的）。还必须将非 HTTPS 传输从 Web 容器中删除，确保在与服务器联系时只使用相互身份验证的 SSL。
  3. 必须在 WebSEAL TAI 的属性中设置 mutualSSL=true。然而，必须了解的是，最后这个步骤只是向 TAI 表明它应该假设这个连接是安全的，而且它使用了相互身份验证的 SSL。如果前面两个步骤没有严格地正确配置，环境就会十分不安全。

  因此，在选择使用 mutualSSL 时必须非常谨慎。任何配置失误都会导致环境可被任何用户模仿。

  如果在环境中添加一个 Web 服务器，则会使情况变得更加复杂。在这种情况下，必须谨慎地配置 WebSEAL 和 Web 服务器之间的 mutualSSL 配置，以及 Web 服务器插件和 WebSphere Application Server Web 容器之间的第二个配置。

多种 WebSEAL TAI

目前，可以使用三种 TAI 在 WebSEAL 和 WebSphere Application Server 之间提供 SSO：

• WebSphere Application Server 附带的遗留 WebSEAL TAI (WebSealTrustAssociationInterceptor)：不要使用这种 TAI，因为它在 V7 中已经弃用了，而且如果配置不当，会很危险。
• WebSphere Application Server 附带的 Tivoli Access Manager Interceptor Plus TAI (TAMTrustAssociationInterceptorPlus)。这种 TAI 解决了前一种 TAI 的安全漏洞，应该优先选用它。但是，它在功能方面与遗留 TAI 有些差异（包括需要 TAM 客户端配置），所以一些用户不喜欢使用它。
• 可以 从 IBM 下载 的 Enhanced Tivoli Access Manager TAI (TAMETai)。这种 TAI 与 TAMPlus TAI 一样妥善地加强了安全性，但是增加了一些重要功能，比如可以像遗留 WebSEAL TAI 一样在没有 Tivoli Access Manager 客户端的情况下运行。

一般情况下，应该根据自己的需要使用第二种或第三种 TAI。

13. 谨慎地使用证书身份验证

证书身份验证可能导致两种非常特殊的风险：

• 撤消：证书可能被破解，必须采取措施来撤消被破解的证书。

  证书提供一种强大的身份验证形式，从安全性的角度来说非常不错。但是，必须考虑到撤消的问题。因为用户控制自己的私钥，所以私钥有可能被窃取。因此，所有 CA 都提供证书撤消机制；也就是说，CA 声明这个证书不再可信。为了让证书撤消起作用，证书的接受者必须检查它是否仍然有效。许多人忽视了这一点。如果不适当地支持撤消，那么使用证书执行身份验证是很愚蠢的。有多种技术可供使用（这里不再详细讨论）；简单地说，您可以选用以下技术：

  • Online Certificate Status Protocol (OCSP)。
  • Certificate Revocation List，可以通过证书中嵌入的端点或分发点信息找到这个列表。
  • 如果证书数量很少，那么只需颁发自签名证书即可。只需删除相应的签署者，就可以撤消证书。

  WebSphere Application Server 支持所有这些技术，但是都需要配置。一定要执行相应的配置步骤。Liberty 配置文件不支持 OCSP 或 Certificate Revocation List。

• Web 身份验证信任风险：必须正确地配置用来检验证书的机制；在默认情况下，证书检验机制并不适用于 Web 通信流。

  当对 Web 通信流使用基于证书的身份验证时，可能会出现一个非常不起眼的信任问题。当 Web 客户端向 Web 服务器验证身份时，Web 服务器会检验证书。然后，WebSphere Application Server Web 服务器插件将来自 Web 服务器的证书信息转发给应用服务器。通过转发这一信息，Web 容器就可以将证书映射到一个 Java EE 身份。问题是，这一信息仅仅是对证书的描述（在公共证书中可以找到的信息）。如果入侵者直接连接 Web 容器，绕过 Web 服务器，就很容易攻破系统，因为入侵者可以伪造证书信息，欺骗运行时环境，将自己伪装成任何人。这意味着，如果使用证书执行身份验证（基于 Java EE 的身份验证或自定义的应用程序代码直接检查证书），就必须堵住这个漏洞。

  您需要考虑两种情况。如果打算使用证书向 Web 服务器验证身份，让 Web 容器可以使用这些证书执行身份验证，则需要对 Web 服务器到 Web 容器的链接进行身份验证（参见 下一小节）。如果打算使用证书直接向 Web 容器验证身份（也就是说没有 Web 服务器），则必须通过配置 Web 容器让它忽略 HTTP 头中的证书信息（在这种情况下，这些信息可能是伪造的）。为此，必须在每个应用服务器的 Web 容器上配置 "trusted" 自定义属性，并把它的值设置为 false，参见图 6。

  图 6. 将 Web 容器设置为忽略来自客户端的证书头

  

要将 Liberty Web 容器配置为忽略来自客户端的证书头，可将 webcontainer 信任元素包含在配置文件的 server.xml 文件中，如清单 2 所示。

清单 2. 在 Liberty 中忽略来自客户端的证书头

<webcontainer trusted=’false’/>

如果目标是支持向 Web 服务器和 Web 容器进行证书身份验证，则需要使用自定义的代码，因为这两个解决方案都不够安全；都容易受到来自其他连接路径的攻击。实际上，需要开发自定义的 TAI 或应用程序代码，从而利用 IBM 特有的特性，让 Web 容器中运行的代码能够判断通过 Java EE API 获得的证书信息的来源：是直接连接到 Web 容器（因此证书是可信的），还是从 HTTP 头获取（在这种情况下，证书实际上是不可信的）。如果是后一种情况，自定义的代码可以直接查看在 SSL 握手过程中提供给容器的证书信息，检查设置 HTTP 头的群体是否可信；例如，自定义的代码可以检查 SSL 客户端证书（通过请求属性 com.ibm.websphere.ssl.direct_connection_peer_certificates 获取），检查直接容器连接是否来自 WebSphere Application Server 插件；如果是这样，请接受 HTTP 头中的证书信息。这个特性是 7.0.0.7 中新增的，相关信息参见 WebSphere Application Server 信息中心。

14. 考虑对 Web 服务器到 WebSphere Application Server 的 HTTP 链接进行身份验证

WebSphere Application Server Web 服务器插件将来自 Web 服务器的请求转发给目标应用服务器。在默认情况下，如果到 Web 服务器的通信是通过 HTTPS 完成的，那么在将请求转发到应用服务器时，插件会自动地使用 HTTPS，从而保护其机密性。

另外，更谨慎的做法是将应用服务器（它包含一个小的嵌入式 HTTP 监听器）配置为只接受来自已知 Web 服务器的请求。这样做可以防止各种绕过 Web 服务器前或 Web 服务器中的任何安全性检查的暗中攻击，创建一个可信的网络路径。这种情况看似不太可能出现，但确实存在这种可能。我们无法一一列举所有场景，下面是一些例子（这绝不是全部例子）：

• 有一个身份验证代理服务器，它只是将用户 ID 作为 HTTP 头发送出去，并不发送任何身份验证信息。可以直接访问 Web 容器的入侵者只需要提供相同的头，就可以成为任何人。（IBM Tivoli Access Manager WebSEAL 不存在这种漏洞。）
• 有一个代理服务器，它执行重要的授权，以很粗的粒度限制谁可以访问哪些应用程序。
• 有一个代理服务器，它执行重要的审计，不希望它被绕过。
• 像前一小节讨论的一样，使用客户端证书向 Web 服务器验证身份。

要创建从 Web 服务器到应用服务器的可信网络路径，需要配置应用服务器 Web 容器 SSL 配置，以便使用客户端身份验证。一旦确保了正在使用客户端身份验证，就需要确保只有可信的 Web 服务器才能联系 Web 容器。要实现这一点，必须通过应用 只使用 SSL 限制访问 中介绍的 SSL 隧道技巧或者确认前一节中提及的直接 SSL 对等方来限制具有访问权限的群体。具体地说，需要执行以下操作：

1. 为 Web 容器创建一个密钥存储库和信任存储库，为 Web 服务器插件创建一个密钥存储库。
2. 从所有密钥存储库（包括信任存储库）删除所有现有的签名证书。此时，不能使用任何密钥存储库来检验证书。这样做是有意的。
3. 在这两个密钥存储库中创建自签名证书，并只导出该证书（而不是私钥）。一定要记录这些证书的到期时间。当插件证书到期之后，它就不能再联系 Web 容器了！将从 Web 容器密钥存储库中导出的证书导入插件密钥存储库中。将插件证书导入到 Web 容器信任存储库中。现在，每一端都只包含一个签名证书。这意味着只能使用它们检验一个证书——为对方创建的自签名证书。
4. 将新创建的密钥存储库安装到 Web 容器和 Web 服务器插件中。

15. 不要在生产环境中运行示例

WebSphere Application Server 附带了几个非常好的示例，它们演示了 WebSphere Application Server 的各个部分。这些示例不是为在生产环境中使用而准备的。不要在生产环境中运行它们，因为它们会带来严重的安全风险。特别是 snoop Servlet 会向外部人员提供大量关于您的系统的信息。这正是您不希望潜在的入侵者获得的信息。只要不在生产环境中运行 server1（它默认包含这些示例），不在配置文件创建期间安装这些示例，或者从 server1 卸载示例应用程序，就很容易解决这个问题。

16. 选择合适的进程身份

WebSphere Application Server 进程是在操作系统上运行的，因此必须在某个操作系统身份下运行。有三种运行 WebSphere Application Server 的方式与操作系统身份有关：

• 以 root 身份运行一切程序。
• 以单一用户身份（例如 “was”）运行一切程序。
• 以 root 身份运行节点代理，以应用服务器自己的身份运行各个应用服务器。

IBM 测试过并完全支持前面两种方法。第三种方法看似很有吸引力，因为那样就可以利用操作系统权限，但它在实践中不是十分奏效，主要具有以下几个原因：

• 配置它非常困难，而且配置过程没有文档说明。许多 WebSphere Application Server 进程都需要对无数文件具有读访问权限，并对 log 和 transaction 目录具有写访问权限。
• 通过以 root 身份运行节点代理，实际上会向 WebSphere Application Server 管理员和在 WebSphere Application Server 中运行的任何应用程序授予 root 权限。这可能包含一个 Generic Server，它是一个非 WebSphere Application Server 进程。这可能是一个 Java 或原生可执行文件，将以 root 身份运行。
• 这种方法的主要价值在于控制应用程序对文件系统的访问。但是，使用 Java 2 权限也可以实现这一点。
• 这种方法会造成应用程序互相隔离的错觉。其实不是。WebSphere Application Server 内部安全模型基于 J2EE 和 Java 2 安全性，不受操作系统权限的影响。因此，如果选择使用这种方法来保护自己免受 “恶意” 应用程序的侵害，那么方法的方向可能弄错了。

第一种方法明显是不可取的，因为作为一般的最佳实践，如果可以的话，最好避免以 root 身份运行任何进程。这样就只剩下第二种方法，它是完全受支持的。在某些很少见的情况下，可能并不关心应用程序隔离，但是希望以不同的操作系统身份运行应用程序以便进行审计，那么可以使用第三种方法。从安全性的角度来看，这没有什么价值，而且实际上会略微增加风险，但是有可能使用操作系统级审计。

17. 保护配置文件和私钥

对于限制权限也不要过于极端。我们见过非常多这种情况：在开发期间，甚至不允许开发人员查看应用服务器日志文件。这种极端做法完全没有必要。当然，在生产期间，应该尽可能地保护 WebSphere Application Server。但是，在开发期间，没有必要实现最大的安全性，这会影响开发人员的生产力。

应该利用操作系统文件权限来限制对 WebSphere Application Server 文件的文件系统访问。与任何复杂的系统一样，WebSphere Application Server 使用和维护大量敏感信息。一般来讲，不应该有人对大多数 WebSphere Application Server 信息具有读或写权限（参见边栏）。特别是 WebSphere Application Server 配置文件 (<root>/config)，它既包含配置信息，也包含密码。

Password encryption for WebSphere 安全文件的密码加密

在 WebSphere Application Server V6.0.2 之前，即使不喜欢 WebSphere Application Server 为 J2C 资源存储密码的方式，您通常也是无能为力。您可以编写自己的自定义 J2C 登录模块，从 WebSphere Application Server 外部的来源获取密码，但这对 WebSphere Application Server 使用的其他密码没有帮助：LDAP 绑定、WebSphere Application Server 管理员等。

WebSphere Application Server V6.0.2 引入了一个接口，您可在其中实际地配置您自己的自定义密码编码器，可实现您认为合适的保护。为此，需要实现插件接口 (com.ibm.wsspi.security.crypto.CustomPasswordEncryption)，然后在 security.xml 中指定两个自定义安全属性。也可以在 PropFilePasswordEncoder.bat/sh 中设置这些属性。这两个属性是：

• com.ibm.wsspi.security.crypto.
  customPasswordEncryptionClass
• com.ibm.wsspi.security.crypto.
  customPasswordEncryptionEnabled.

有关的更多信息，请参阅信息中心文章 自定义密码加密的插入点。

尽管如此，我并不相信加密这些 WebSphere Application Server 密码会在编码的基础上提供任何有意义的保护。密码编码的设计目标是预防意外泄漏；例如，某个在后面偷窥的人可在一个文件中看到明文密码。另一方面，如果某人访问包含密码的文件，编码和加密都无法避免此人访问该密码。再一次声明，任何具有对加密的密码的文件访问权的人也能够访问原始密码。这是因为用于加密的密钥/证书必须存储在文件系统上，以便 WebSphere Application Server 进程能够在需要时解密密码，并将它发送到任何需要的地方。因此，任何能够访问文件系统的人都能访问包含（加密的）密码和密钥的文件，然后使用这些信息来解密密码。

另外，应该注意避免不小心共享密钥。例如，不要在生产环境中使用与其他环境中相同的密钥。许多人对开发和测试计算机及他们自己的密钥具有访问权限。应该谨慎地保护生产环境所用的密钥。

如果不谨慎地控制谁对文件系统有写访问权限，那么用户只需手工编辑配置文件，就可以破坏产品的安全控制（比如审计）。

18. 加密从 WebSphere Application Server 到 LDAP 的链接

在使用 LDAP 注册表时，WebSphere Application Server 会使用标准的 ldap_bind 来验证用户密码。这要求 WebSphere Application Server 将用户密码发送给 LDAP 服务器。如果该请求没有加密，那么黑客可以使用网络嗅探器来窃取用于身份验证的用户密码（包括管理密码！）。大多数 LDAP 目录都支持 LDAP over SSL，并且可以将 WebSphere Application Server 配置为使用 LDAP over SSL。在 LDAP 用户注册表面板中（请参见图 7），选中 use SSL enabled 选项，然后配置适合您的 LDAP 目录的 SSL 配置。很可能需要将用于 LDAP 服务器证书的签名密钥（证书）放在信任的存储库中。最好是创建只供 LDAP 使用的新的 SSL 配置，以避免给当前使用 SSL 的其他领域造成问题。

图 7. 启用 LDAP SSL

如果使用一个自定义注册表，您一定想要使用所提供的机制保护此通信流。

要对 Liberty 配置文件启用 LDAP SSL，可将一些元素包含在服务器的 server.xml 中，类似于清单 3 中加粗的元素示例。

<featureManager>
     <feature>ssl-1.0</feature>
</featureManager>

<ssl id="ldapSSLConfig" keyStoreRef="ldapTrustStore" 
	trustStoreRef="ldapTrustStore"/><keyStore id="ldapTrustStore"
   location="ldapTrustStore.jks" type="JKS" password="123456" />

<ldapRegistry id="IBMDiretoryServerLDAP" realm="SampleLdapIDSRealm"
        host="host.domain.com" port="389" ignoreCase="true"
        baseDN="o=domain,c=us"
        ldapType="IBM Tivoli Directory Server"
        idsFilters="myidsfilters"
        sslEnabled="true"
        sslRef="ldapSSLConfig" />

19. 确保只通过 HTTPS 传输 LTPA cookie

Web 应用程序使用 cookie 跨请求跟踪用户。尽管这些 cookie 本身通常不包含敏感信息，但是它们会将用户与后端系统上用户的现有状态联系起来，如果入侵者捕获了您的 cookie，那么他们就有可能使用这个 cookie 伪装成您。因为网络通信流常常通过不可信的网络进行传输（考虑一下您喜欢的 WiFi 热区），数据包很容易被捕获，所以应该使用 SSL 加密重要的 Web 通信流，包括重要的 cookie。显然，如果所有请求都使用 SSL，那么 cookie 就会得到保护。但是，许多应用程序（可能偶尔）通过 HTTP 发送请求，并没有使用 SSL，这可能会暴露 cookie。幸运的是，HTTP 规范允许指定浏览器只通过 SSL 发送 cookie。

对于 WebSphere Application Server，最重要的 cookie 是 LTPA cookie，因此，应该将它配置为只通过 SSL 发送。

图 8. 将 LTPA cookie 限制为只使用 SSL

要在 Liberty 配置文件中将 LTPA cookie 限制为仅使用 SSL，可以将一个 webAppSecurity 元素包含在服务器的 server.xml 文件中，该文件还包含 ssoRequiresSSL 属性，如清单 4 中的示例所示。

清单 4. 在 Liberty 中启用应用程序安全性

<webAppSecurity ssoRequiresSSL=’true’/>

通过在会话管理面板上指定相似的设置，还可以将 HTTP Session（默认情况下是 JSESSION） cookie 限制为只使用 SSL。

要在 Liberty 配置文件中将 HTTP Session cookie 限制为仅使用 SSL，可将一个 httpSession 元素包含在服务器的 server.xml 中，该文件还包含 cookieSecure 属性，如清单 5 中的示例所示。

清单 5. 在 Liberty 中启用 HTTP Session cookie SSL

<httpSession cookieSecure=’true’/>

警告：在安装修复包 7.0.0.9 之前，Requires SSL 标志在 WebSphere Application Server V7 中无效。一定要安装它。

20. 确保定期改变 LTPA 加密密钥

WebSphere Application Server 使用 LTPA 加密密钥加密各种用户令牌（包括 LTPA cookie）。与任何密码术密钥一样，应该定期改变这些密钥。根据 WebSphere Application Server 和补丁级别不同，可能在默认情况下启用了自动密钥生成，也可能关闭了该功能；版本越新，默认情况下它关闭的可能性就越大。为了避免可能的宕机，请确保此功能已关闭，如图 9 所示。

在首次对某个 Liberty 服务器启用安全性时，会生成 LTPA 密钥。

应该确保会定期更改 LTPA 加密密钥。对于完整配置文件，可以启用自动 LTPA 密钥替换（参见图 9），也可以手工地重新生成密钥（参见图 10），或者通过 AdminTask.generateKeyForKeySetGroup 命令执行。

对于 Liberty 配置文件，可以创建一个新配置文件，启用安全性，启动服务器，然后复制新生成的 ${server.config.dir}/resources/security/ltpa.keys 文件。

一定要考虑 LTPA 密钥不一致的问题：

• 首先，如果计算单元中的某些节点在一段时间内一直停机（而且密钥更改两次），那么它们可能会丧失通信能力。
• 第二，如果与其他组件（比如另一个计算单元或 WebSphere DataPower）共享 LTPA 密钥，那么在更改密钥时，需要在所有地方更新它们，这通常会造成停机。

因此，可以规划在计划的宕机期间更改您的 LTPA 密钥。将新密钥分发给计算单元中的所有节点，并在这个宕机窗口中将新密钥分发给所有外部系统/计算单元。

图 9. 不启用自动 LTPA 密钥更新

图 10. 手工生成新的 LTPA 密钥

21. 不要在命令行上指定密码

一旦启用了安全性，WebSphere Application Server 管理工具就会要求您仅在通过身份验证的情况下使用它。执行身份验证的明确方法是在命令行中指定用户 ID 和密码，将其作为参数传递给该工具。请不要这样做。这会向在您身边窥探的任何人暴露您的管理密码。而且在许多操作系统中，任何可以看到进程列表的人都可以看到命令行上的参数。另外，以前的命令可在命令历史中看到，包括密码参数。相反，应该确保通过管理工具提示输入用户 ID 和密码。请注意，在所有当前支持的 WebSphere Application Server 版本中，这是默认设置，所以无需执行任何显式操作来确保发生此行为。

如果觉得命令行工具以图形方式提示输入用户 ID 和密码非常烦人，可以改变此行为，让工具使用基于文本的简单提示。要实现这一点，应该通过编辑适当的配置文件，将 loginSource 从 prompt 更改为 stdin。在默认情况下，管理工具使用 SOAP，因此应该编辑 soap.client.props 文件。如果使用的是 RMI，则编辑 sas.client.props。请在适当的文件中查找 loginSource 属性，并更改它以指定 stdin。

这一项不适用于 V8.5 中的 Liberty 配置文件。

22. 考虑在基于文件的 Federated Repository 注册表中增加附加数据

如果在使用 Federated Repository 注册表的同时还使用了该注册表中内置的文件存储库，那么该注册表中的用户会将他们的用户 ID 和密码存储在计算单元 config 目录中的 fileregistry.xml 文件中。这些密码经过了单向哈希计算，这意味着您无法从哈希值获得实际的密码。哈希值可借助一些密码学上的附加数据来计算。在 WebSphere Application Server V8.0 和 8.5 中，可以指定附加数据的长度和使用的哈希算法。此文件应由 OS 定义的访问控制列表来保护，以便只有特权 OS 用户才能读取该文件。要预防通过彩虹表的密码破解攻击，可以考虑增加附加数据量或使用更强的哈希函数。

这一项不适用于 V8.5 中的 Liberty 配置文件。

23. 考虑为生成的证书使用更长的密钥长度

在 WebSphere Application Server V8.0 中，生成的证书所使用的默认密钥长度从 1024 更改为 2048。从 V7.0 开始，在通过 wsadmin 生成密钥时，可指定比 1024 更长的密钥长度。从 V8.0 开始，管理控制台（图 11） 支持选择密钥长度。

这一项不适用于 V8.5 中的 Liberty 配置文件。

图 11. 在管理控制台中选择密钥长度

支持的密钥长度范围为 512-16384（必须是 8 的倍数）。

这一项不适用于 V8.5 中的 Liberty 配置文件。

24. 创建单独的管理用户 ID

主管理 ID 与用于服务器到服务器通信的安全服务器 ID 并不相同。从 V6.1 开始，注册表中不再需要具有这个身份，甚至不必有相关联的密码。它在默认情况下只用于内部通信。如果需要的话，可以指定服务器 ID 和密码，但是不建议这么做，除非绝对必要——比如使用包含不同版本的计算单元（包括 V6.0 和更低版本），或者涉及 V6.0 或更低版本的跨计算单元 SSO。

当为 WebSphere Application Server V6.1 和更高版本配置安全性时（Liberty 配置文件除外），在开始时会配置一个主管理 ID（参见边栏）。这个 ID 实际上等同于 WebSphere Application Server 中的 root 用户，它能够执行任何管理操作（包括下一节提到的所有管理角色）。由于这个 ID 很重要，所以最好不要随便共享其密码。理想情况下，在最初配置之后不应该再使用这个 ID。出于安全原因，在 V8.5 中，默认情况下并未启用 Liberty 配置文件。

与大多数系统一样，WebSphere Application Server 允许多个主体担任管理员。只需使用管理应用程序并进入系统管理控制台用户（或用户组）部分，指定应该授予管理权限的其他用户或用户组。在进行这样的授权之后，当管理 WebSphere Application Server 时，每个人都可以以自己的身份进行身份验证。会导致更改 WebSphere Application Server 配置的所有管理操作都需要经过部署管理器的审核，包括执行更改的主体的身份。从 V7 开始，引入了一个新的审计框架，它可以提供更详细的管理操作审计信息。显然，如果每个管理员有单独的身份，这些审计记录会更有用。

在由中心管理员管理多个 WebSphere Application Server 计算单元的环境中，为每个管理员授予单独的管理访问权限会非常方便。虽然每个计算单元都有自己的本地 “根” ID 和密码，但是可以配置所有这些计算单元来共享公共注册表，这样管理员就可以使用相同的 ID 和密码来管理每个计算单元。

25. 利用管理角色

根据版本不同，WebSphere Application Server 的完整（非 Liberty 配置文件）允许采用不同的管理角色：Administrator、Operator、Monitor、Configurator、AdminSecurityManager、iscadmins、Deployer、Auditor。这些角色使得授予个人（和自治系统）适当的访问权限成为可能。强烈建议尽可能地利用这些角色。通过使用权限较少的 Monitor 和 Operator 角色，可以限制管理员能够执行的操作。例如，可以只授予较为低级的管理员启动和停止服务器的能力；只授予夜间操作员监视系统的能力（Monitor）。这些操作让人员只具有他们需要的权限，这极大地限制了损害风险。

在 WebSphere Application Server Information Center 中可以找到关于角色及其拥有的权限的完整文档。但是，应该特别注意下面三个角色：

• Monitor：如果授予用户或系统这个访问级别，则意味着他们只能监视系统状态；不能更改状态，也不能更改配置。例如，如果您开发用于检查系统运行状况的监视脚本，并且必须用该脚本在本地保存用户 ID 和密码，那么应该使用具有 Monitor 角色的 ID。即使该 ID 被窃取，所造成的损害也不会很严重。
• AdminSecurityManager：（V6.1 中增加的）具有此角色的用户可以授予其他用户管理角色。Administrator 角色本身没有这个权限。现在，可以向用户授予各种权限（甚至包括 Administrator 权限），同时仍然确保他们无法将这些权限再授予他人。
• Auditor：（V7 中增加的）具有此角色的用户可以配置审计系统，但是没有其他任何权限。另一方面，Administrator 可以配置除审计系统之外的任何东西。这提供明确的职责分隔。Administrator 可以更改配置，但是无法 “掩盖” 操作痕迹，因为他无法禁用审计。

这一项不适用于 V8.5 中的 Liberty 配置文件。Liberty 配置文件只有一个管理员安全角色可绑定多个主体。

26. 考虑加密 Web 服务器到 Web 容器的链接

即使不对从 Web 服务器到 Web 容器的链接进行身份验证，也可能希望考虑对它进行加密。Web 服务器插件通过 HTTP 把来自 Web 服务器的信息传输到 Web 容器。如果到达 Web 服务器的请求使用的是 HTTPS，那么在默认情况下插件使用 HTTPS 转发请求。如果到达的请求使用的是 HTTP，那么插件使用 HTTP。这些默认行为对于大多数环境是合适的。但是，有一种例外情况。

在某些环境中，当请求到达您的网络之后，就会在其中添加敏感信息。例如，一些身份验证代理服务器（比如 WebSEAL）会在请求中添加密码信息。Web 服务器中的自定义代码可能做相似的事情。如果是这种情况，应该采取额外步骤保护从 Web 服务器到 Web 容器的通信流。要想迫使从此插件发出的所有通信流都使用 HTTPS，只需在每个应用服务器上的 Web 容器中禁用 HTTP 传输，然后重新生成和部署插件。必须同时禁用 WCInboundDefault 和 HttpQueueInboundDefault 传输链（图 12）。现在，此插件只能使用 HTTPS，所以无论通信流如何到达 Web 服务器，它都会使用 HTTPS 执行转发。

图 12. 确保只使用 HTTPS

要在 Liberty 配置文件中确保仅使用 HTTPS 连接 Web 容器，可将一个 httpEndpoint 元素包含在服务器的 server.xml 文件中，该文件还包含一个 httpsPort 属性，但不包含 httpPort 属性（如清单 6 中的示例所示）。

清单 6. 在 Liberty 中确保仅使用 HTTP 连接到 Web 容器

<httpEndpoint id="defaultHttpEndpoint" host="localhost"
httpsPort="9443" />

27. 加密 WebSphere MQ 消息传递链接

如果您使用的是 WebSphere MQ 而非默认的消息传递提供者，当然应该对 WebSphere MQ 使用 SSL。有关这一点的更多信息，请参阅 参考资料。在 WebSphere Application Server V7 中，WebSphere MQ 客户端 SSL 配置是第一类构造，可以像其他 SSL 配置一样通过管理控制台设置。

这一项不适用于 V8.5 中的 Liberty 配置文件。

28. 加密 Distribution and Consistency Services (DCS) 传输链接

核心组依赖于 DCS，它使用可靠的多播消息 (RMM) 系统来进行传输。RMM 可以使用几种有线传输技术之一。根据环境不同，可以通过 DCS 传输敏感信息。例如，使用 DCS 传输 DynaCache 和安全性主题缓存中的数据。为了确保这一点，需要选择一种通道框架传输类型，并选择 DCS-Secure 作为每个核心组的通道链（图 13）。

图 13. 配置 DCS 以使用受保护的链接

请注意，当启用全局安全性时，DCS 始终对消息进行身份验证。在加密传输之后，就有了一个高度安全的通道。

一旦做到这一点，所有依赖于 DCS 的服务都将使用加密且经过身份验证的传输。这些服务是 DynaCache、内存到内存会话复制、核心组、Web 服务缓存和有状态会话 bean 持久化。

29. 保护从应用服务器到数据库的链接

与其他任何网络链接一样，可以将机密信息写入数据库或从数据库中读取机密信息。大多数数据库都支持某种形式的身份验证，您应该利用这一点。

这里是一个 IBM DB2 示例。

这一项不适用于 V8.5 中的 Liberty 配置文件。

30. 考虑将 cookie 限制为 HTTP Only

如果黑客能够通过在浏览器中插入恶意的 JavaScript 攻破 Web 应用程序（这通常称为跨站点脚本攻击），就可以执行许多恶意操作，应用程序实际上完全被攻破了。他们可以执行的恶意操作之一是窃取 LTPA cookie 等敏感的 cookie。大多数现代 Web 浏览器都支持 HTTP Only 概念。

WebSphere Application Server 提供了两种确保 LTPA cookie 被标记为 HTTP Only 的方法。第一种方法是将安全性自定义属性 com.ibm.ws.security.addHttpOnlyAttributeToCookies 设置为 true。此功能通过修复包 7.0.0.9 添加。

该功能只使用 HTTP Only 标志保护 LTPA cookie。对于以正确方式编写的使用 Java EE 安全性并启用会话安全性（稍后讨论）的应用程序，这应该足够用了。

第二个功能（也在修复包 7.0.0.9 中发布）支持在任意 cookie 上设置 HTTP Only 标志。此功能比第一个功能更可取，因为它更加灵活且更加完整。借助此 APAR，要保护的 cookie 由一个 Web 容器属性 com.ibm.ws.webcontainer.httpOnlyCookies 控制。该属性是要保护的 cookie 的一个逗号分隔列表（使用 * 表示所有 cookie）。在 V7.0 中（应用了 7.0.0.9），这个功能默认情况下是禁用的。要使用它，则必须显式设置该属性。在 8.0 和 8.5 版中，此属性默认情况下已对 LtpaToken2、JSESSIONID 和 WASReqUrl cookie 启用，无需执行进一步的操作，除非您希望将它应用于其他 cookie。请注意，由于默认行为中的这一更改，从更早版本迁移来的用户可能会遇到应用程序破坏问题。

默认情况下，LtpaToken2 (SSO) 和e WASReqURL cooki 在 Liberty 配置文件中设置为 HTTP only。要在服务器的 server.xml 文件中显式设置此属性，可以包含一个具有 httpOnlyCookies 属性的 webAppSecurity 元素，比如清单 7 中的示例。

清单 7. 在 Liberty 中将 LTPA 会话 cookie 限制为 HTTP Only

            <webAppSecurity httpOnlyCookies=’true’ /><!- - This is the default- ->

默认情况下，HTTP 会话在 Liberty 配置文件中也被设置为 HTTP only。要在服务器的 server.xml 中显式设置此属性，可以包含一个具有 cookieHttpOnly 属性的 httpSession 元素，比如清单 8 中的示例。

清单 8. 在 Liberty 中将 HTTP 会话 cookie 限制为 HTTP Only

<httpSession cookieHttpOnly=’true’ /><!- - This is the default- ->

警告：尽管这些功能看起来是防御跨站点脚本攻击的解决方案，但它不是。如果黑客可以在您的浏览器中执行任意代码，那么他们造成的危害就远远不只是窃取 cookie。他们实际上可以看到浏览器屏幕上的所有内容，可以捕获每次击键，这比窃取 cookie 严重得多。

31. 通过培训让用户正确地理解证书警告

当使用 SSL 进行通信时，安全地交换信息的关键之一是根据客户端信任存储库检验服务器的证书。如果由于信任存储库中没有相应的签署者而导致服务器提供的证书不可信，那么大多数客户端（Web 浏览器、SSH、wsadmin 等）会提示用户决定应该怎么做。这些客户端通常会向用户警告这是一个未知的证书，并提供证书的指纹（通常是 SHA），询问 should I trust this?。遗憾的是，大多数用户会盲目地单击 yes。这是一个可怕的决定。如果这么做，那么您就不会知道自己将与什么样的服务器通信。对于 WebSphere Application Server 管理客户端，下一步是将管理用户 ID 和密码发送到未知的服务器。

相反，管理员应该检查指纹信息，判断它是否是正确的指纹（理想情况下最终用户也应该这么做）。管理工具提供了查看证书指纹的方法。在管理控制台中选择一个个人证书，显示它的指纹。

图 14. 证书指纹

用户（尤其是管理员）应该了解指纹信息，当客户端（无论是 Web 浏览器，参见图 15 和图 16，还是 wsadmin，参见清单 9）。

图 15. Web 服务器证书警告，第一部分

图 16. Web 服务器证书警告，第二部分

清单 9. wsadmin 证书警告

./wsadmin.bat
*** SSL SIGNER EXCHANGE PROMPT ***
SSL signer from target host localhost is not found in trust store 
	C:/IBM/WebSphere/AppServer/profiles/AppSrv02/etc/trust.p12
Here is the signer information (verify the digest value matches what 
	is displayed at the server):
Subject DN:    CN=keysbotzum, O=IBM, C=US
Issuer DN:     CN=keysbotzum, O=IBM, C=US
Serial number: 1151337276
Expires:       Tue Jun 26 11:54:36 EDT 2007
SHA-1 Digest:  53:43:75:86:A8:C3:55:15:98:35:54:E7:49:B7:15:AF:16:A9:53:6F
MD5 Digest:    29:36:B1:9C:22:5A:36:AD:78:B3:7E:FD:D3:B1:B4:19
Add signer to the trust store now? (y/n)

即使您不采纳这个建议，至少应该在第一次遇到警告时将证书导入客户端信任存储库。如果再次看到这类消息，一定要查明原因！在证书发生更改之前，提示应该不会再次出现。如果出乎意外地出现提示，一定存在很严重的错误。

32. 考虑限制 HTTP 数据的大小

一种常见的拒绝服务 (DOS) 工具是向应用程序发送非常大的 HTTP 头、很多 HTTP 头或很大的请求正文。我们非常支持进行深度防御。理想情况下，一个入侵检测系统、一个防火墙、一个 WebSphere DataPower SOA Appliance，甚至是应用服务器前面的 Web 服务器，都应该保护您的 WebSphere Application Server，使它们远离这些基于规模的 HTTP 攻击。WebSphere Application Server 中还有一些控件可保护它们远离这些攻击类型。

任何单个 HTTP 头的默认最大大小为 32768 字节。可以将它设置为不同的值。

HTTP 头的默认最大数量为 50。可以将它设置为不同的限制值。

另一种常见的 DOS 攻击是发送一个请求，这个请求会导致一个长期运行的 GET 请求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 属性可限制任何请求的重试数量。这可以降低这种长期运行的请求的影响。请参阅 信息中心 了解详细信息。

如果您希望限制任何请求正文的最大大小，也可以对其进行设置。有关的详细信息，请参阅 信息中心。

33. 谨慎地限制可信的签署者

在使用证书身份验证（客户端或服务器）时，需要了解信任存储库中的每个签署者都代表一个可信的身份信息（证书）提供者。您信任的签署者应该尽可能少。否则，两个签署者颁发的证书有可能映射到同一个用户身份。这会在架构中造成严重的安全漏洞。

应该检查客户端和服务器上的信任存储库，删除任何不需要的签署者。在默认情况下，信任存储库包含的可信签署者比以前的版本少得多，这有助于提高默认情况下的安全性。但是，仍然有几个签署者问题可能需要解决：

• 在 V7 中，默认的计算单元信任存储库和 CMS 密钥环文件包含一个 WebSphere DataPower 签名证书，这意味着所有 DataPower 计算机都可以颁发应用服务器所信任的证书。为了提高安全性，应该删除它。在安装最新的修复包后创建的 Truststore 和 CMS 密钥环文件无需 DataPower 签名证书即可创建。您应在 truststore 或密钥环文件中检查这个不必要的 DataPower 签名文件，如果存在该文件则删除它。
• 在 V8.0 和 V8.5 中，DataPower 签名证书已从生成的 truststore 和 CMS 密钥环文件删除。

34. 强制 CSIv2 传输使用 SSL

（这一项默认情况下已在 V8 中解决，这是一项行为更改。因此，从更早的 WebSphere Application Server 版本迁移且未启用 CSIv2 SSL 的用户应该知道，SSL 身份验证失败可能在 V8 中引起问题。）

当 WebSphere Application Server 服务器和客户端使用 CSIv2 IIOP 进行通信时，它们会就传输安全性进行协商，选择对双方来说都可以接受的形式。一般来说，这是可行的，但应该注意一个潜在的漏洞。WebSphere Application Server 支持 CSIv2 over SSL 或明文。在默认情况下，双方通常会协商使用 SSL，确保建立一个经过加密的通信通道。然而，如果在协商中有任意一方请求使用明文，则将使用明文。您甚至可能不会意识到通信流是以明文方式发送的！这种问题是有可能出现的，例如，如果某个客户端配置出错的话。如果想要（也应该）保证通信流是加密的，更保险的做法是确保始终使用 SSL。

通过在 CSlv2 入站传输面板中指明 SSL 是必需的而不是可选的，确保对 IIOP 使用 SSL。对 CSIv2 出站传输也应该这样做（图 17）。

图 17. 配置只使用 SSL

这一项不适用于 V8.5 中的 Liberty 配置文件，因为没有提供对 EJB 或 CSIv2 的支持。

35. 考虑端口过滤

有时候，希望根据网络信息限制谁可以连接。尽管这样的配置对于安全性不一定有价值，但是为了提供完整的说明，这里仍将对它们进行讨论。WebSphere Application Server 中的大多数传输（IIOP 除外）使用 Channel Framework，因此可以使用包含或排除列表，根据 IP 地址或 DNS 名称来过滤入站通信流。

图 18. 端口过滤

警告：伪造 IP 地址是相当容易的，所以依靠 IP 地址保证安全性是不明智的。在应用层上根据 IP 地址进行过滤尤其不明智。更好的做法是装备防火墙和交换机，识别来自无效 IP 地址的数据包。它们还可以检查 MAC 地址。

36. 考虑在传出 SSL 连接上执行主机名验证

当一个 SSL 客户端打开一个与 SSl 服务器的 SSL 连接时，服务器将它的证书发送给客户端。预期结果是 SSL 服务器的证书将在它的常用名中包含主机名。一些客户端会确认所提供的证书上的常用名是否与 URL 中的主机名匹配（比如 Web 浏览器会执行此检查）。这称为主机名验证。

在某些情况下，此验证的一次失败可能表明存在 SSL 中间人攻击：

• 当证书由于是自签名证书而受信任时，没有必要执行主机名验证。SSL 握手不会通过，除非提供的证书与受信任的证书完全匹配。
• 当证书由于是由一个受信任 CA 颁发而受信任时，MITM 攻击者可以返回同一个受信任 CA 为它颁发的合法证书来代替真正的证书。假设 CA 没有颁发多个具有相同 CN 的证书，那么主机名验证就可以检测到 MITM 攻击者。

要启用主机名验证，必须设置一个安全自定义属性 com.ibm.ssl.performURLHostNameVerification=true。

RFC 2818 Section 3.1 Server Identity 中要求执行主机名验证。总体来讲：

• 如果 URI 被指定为一个 IP 地址，而不是主机名，那么认证可在证书中使用 iPAddress subjectAltName 执行，并且必须与 URI 中的 IP 准确匹配。
• 如果 URI 是使用一个给定的 DNS 名称指定的，那么验证可使用证书的 dNSName 类型的 subjectAltName 扩展（如果存在）来执行。否则，（最明确的方法）将使用证书的 Subject 字段中的 Common Name 字段。尽管现在的做法是使用 Common Name，但已不推荐使用它，建议证书颁发机构使用 dNSName。

  匹配使用 RFC2459 所指定的匹配规则来执行。如果证书中存在多个具有给定类型的证书（例如，多个 dNSName 名称），那么任何集合中的匹配值均被视为可接受。）

设置此属性时的考虑因素：

• 此属性会影响计算单元中所有基于 URL 的通信流，包括 IIOP 和 WebSphere Application Server 内部通信。
• 在创建 WebSphere Application Server 配置文件期间，可以为配置文件配置节点的主机名。您可以覆盖配置文件创建工具所确定的值。请确保它与主机名匹配。
• 如果您的系统是多宿主的，则具有多个主机名，请记住只会返回 SSL 配置的密钥库的默认证书的单个主机名。可以使用替代的主机名创建一个证书；在从一个 CA 获取证书时，就可以这么做。

换句话说，尽管启用此属性可加强针对中间人攻击的安全防御，您的 SSL 证书和主机名解析必须是无瑕疵的。如果不是，那么您的计算单元将无法再通过 SSL 进行通信，因为内部通信可能使主机名验证失败。

37. 禁用不使用的端口

加强安全性的基本原则是使潜在攻击的攻击面最小化。当给定的服务没有已知的安全问题时尤其应该这样。如果该服务对系统的正常运转是不必要的，则应该将其删除，从而尽可能地降低攻击者在将来的某个时候利用这个多余的功能进行攻击的可能性。查看图 20，您会看到典型的 WebSphere Application Server 应用服务器正在监听大量端口。

图 19. Network Deployment 应用服务器的默认端口

如果给定的服务不是必需的，则可以禁用其监听的端口。查看此列表，可以考虑禁用的端口包括：

• SAS_SSL_SERVERAUTH_LISTENER_ADDRESS：用于与 WebSphere Application Server V4 和更早版本进行兼容。这是旧的 IIOP 安全性协议。从 V5 开始，CSIv2 替代它了。
• SIB_ENDPOINT_*：供内置的消息传递引擎使用。如果没有使用消息传递，则不需要使用它们。
• SIB_MQ_*：供消息传递引擎与 WebSphere MQ 连接时使用。
• SIP_*：这些端口供 SIP 容器使用。
• WC_adminhost*：用于管理性 Web 浏览器访问。如果应用服务器没有部署管理器，则应该确保已经禁用了这些端口。遗憾的是，即使服务器上没有管理应用程序，大多数应用服务器 Web 容器仍然要监听两个管理端口。这是因为服务器通常是基于 server1 模板创建的，这个模板包含这些端口。应该在所有应用服务器上禁用或删除这些端口。
• WC_defaulthost*：默认的 Web 容器监听端口。如果已经添加了自定义的监听端口，那么有可能不需要这些端口。

不同的端口需要使用不同的技术来禁用，这取决于它们的实现方式：

• 可以通过在全局安全性面板中选择 CSI 作为活动协议，将 SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 从服务中除去。在 V7 中，默认情况下会禁用 SAS，但是仍然监听这个端口。
• WC_* 端口都是用于 Web 容器的。最好在 Web 容器传输链配置面板 (Application servers > servername > Web container > transport chain) 中删除、修改或禁用它们。只需要监听应用程序使用的那些 Web 端口。
• 除非启用了消息传递引擎，否则不会启动 SIB_* 端口，所以不需要对它们采取措施。
• 除非启动了 SIP 应用程序，否则不会启动 SIP_* 端口，所以不需要对它们采取措施。

警告：在决定要禁用哪些端口时以及在实际禁用它们时，应该特别谨慎。否则，可能无意间禁用管理端口，这样做会禁用管理进程的机制，导致无法删除和重新创建进程（例如服务器）定义。

38. 考虑禁用密码缓存

在执行基于密码的身份验证时，运行时会以单向散列的形式缓存密码，供以后检验时使用。因为这个散列是不可逆的，所以密码没有被截获（甚至包括通过内存转储截获）的危险，但是这个缓存对安全性有影响。如果以后到达的请求要求身份验证，而且这些请求使用了相同的用户 ID 和密码组合，则会使用缓存的密码数据（和用户信息）。这意味着，即使注册表中的用户密码更改了，他仍然能够使用旧的密码通过身份验证，直到缓存到期为止（默认情况下是 10 分钟）。

一些人认为这是一个安全漏洞（作者并不认同）。如果您担心这个问题，可以通过设置 JVM 级属性com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled 禁用密码缓存。进行这样的设置之后，就不再缓存密码，对于所有密码身份验证，都要查询注册表。请记住，这对性能有明显的消极影响。如果使用每个请求都要求身份验证的无状态协议（比如使用 UserNameTokens 的 WS-security），这会产生很大的注册表身份验证通信流。

39. 考虑启用 FIPS、SP800-131 或 Suite B 遵从性

在执行加密时，有多种密码学算法可供选择。另外，在建立 SSL 连接时，实际上有三个选择：SSL V2（在默认情况下禁用）、SSL V3 和 TLS。美国政府已经定义了与计算机安全性有关的标准 (Federal Information Processing Standards)，该标准涵盖许多领域。这个标准称为 FIPS 140-2。在这些标准中，认证了符合 FIPS 标准的密码技术，还认证了 TLS（但是没有认证 SSL V3）。

美国国家标准和技术研究所 (NIST) 定义了一个新标准 SP800-131 来取代当前的 FIPS 140-2。类似地，国家安全局 (NSA) 也开发了一个名为 Suite B 的新标准。这些新标准进一步限制了使用的密码选择并要求使用 TLS 1.2；而 FIPS 140-2 禁止使用 SSL V3，SP800-131 禁止使用 TLS 1.0 和 TLS 1.1。

如果用户希望将应用程序限制为只使用符合 FIPS 140-2 的密码技术和 TLS，那么可以手工配置每个端点，也可以使用管理工具启用 FIPS 遵从性。启用 FIPS 之后，就只能使用 符合 FIPS 的密码技术。

WebSphere Application Server V8.5（以及修复包 8.0.0.3 和 7.0.0.23）引入了对 SP800-131 和 NSA Suite B 的遵从性。类似于 FIPS 遵从性，可以转换整个计算单元，以遵从 SP800-131 和 Suite B。启用之后，只有支持 SP800-131 的客户端能够连接到该计算单元。目前，支持 SP800-131 和 TLS 1.2 的客户端应用程序很少。向此标准的迁移可能很耗时且需要规划。

 

回页首

结束语

这篇分两部分的文章的第 1 部分讨论了安全性的几个方面，主要关注加强 WebSphere Application Server 环境的核心方案。希望这些信息能够向您提供切实保护 Java EE 环境所需的基础知识。

第 2 部分 将讨论更广泛的主题，包括基于应用程序的预防措施、计算单元信任、跨计算单元信任、管理和应用程序隔离、身份传播、桌面开发安全性等等。

如果希望进一步了解 WebSphere Application Server 安全性，请联系 IBM Software Services for WebSphere，参加关于 WebSphere Application Server 安全性的自定义的现场课程。这个课程将深入讲解安全性加强、自定义身份验证、集成、单点登录和其他各种相关主题。