WebSphere Application Server V7高级安全性加强，第1部分：（上）

安全性加强概述和方法

简介

IBM WebSphere Application Server 的安全性在每个版本中都有所改进。除了在新版本中 增加新功能之外，我们还不断增强产品的默认安全性。我们通过改进默认设置不断提高满足默 认安全性这一关键原则的程度。本文的前一个版本 主要关注 WebSphere Application Server V6 和那个版本所需的加强步骤。在后续 WebSphere Application Server 版本中，显著减少了 加强步骤的数量，更重要的是，保留的大多数步骤不太关键了。因此，现在有必要用新信息更 新本文。

本文首先简单讨论安全性为什么重要以及加强系统的困难，然后讨论如何加强 WebSphere Application Server 环境以解决各种安全性漏洞。因为本文主要讨论加强，一些信息是概括性 的，没有进行详细分析。我们尽可能提供相关详细信息的适当参考资料，让您能够进一步研究 相关的子主题。

尽管本文中的信息基于 IBM WebSphere Application Server V7，但是讨论的大多数问题同 样适用于 V6.1。对于某个版本特有的问题，我们会专门指出。

为什么需要安全性？

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

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

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

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

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

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

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

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

同时关注内 部和外部威胁

安全性措施不应该仅仅视为阻挡 “外人” 的大门。那是一个 过于简单化的观点。当前，许多组织将他们的安全性措施完全集中在针对组织以外的人群，他 们错误地认为只有外人才是危险的。实际上并不是这样。对于大型公司，往往有数千人能够访 问内部网络（其中许多人并不是雇员）。这些人都可能成为入侵者，而且由于他们在内部，他 们访问网络更方便。常常只需把笔记本电脑插上网线，就能够访问公司网络。一些研究表明， 有将近一半的入侵是 由组织内部的雇员或者承包人造成的（或涉及到他们）。

就算您 相信网络中的每个人都是值得信任的，那么也能够相信他们永远不犯错误吗？考虑到通过电子 邮件传播的病毒如此猖獗，而且基于 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™ 中不奏效，但是其他小错误仍然可能导致系统受到威胁。

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

安全性加强概述

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 通信流和 SOAP 通 信流。SSL 需要使用公钥/私钥对，对于 WebSphere Application Server，这些密钥存储在密 钥存储库中。因为 SSL 对于保护基础设施具有重要作用，所以我们暂时离开本文的主线，介绍 SSL 的一些与 WebSphere Application Server 相关的重要方面。（这一讨论有意只做简要介 绍，只讨论正确配置 SSL 所需的关键点。）

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

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

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

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

在查看此图时，请注意客户机必须持有签署服务器生成的公钥所用的证书。这是信任的关键 部分。由于客户机信任它拥有的任何证书（在本例中包括 CA 证书），所以它信任 CA 签署的 证书。如果您使用自签名证书，这没有什么价值，因为您需要手工地将这些自签名证书分发到 每个客户机，而不是依靠可能已经在客户机中构建的众所周知的 CA 证书。这并非不安全，但 如果您有许多客户机，要将所有这些签名证书（每个服务器对应一个）分发到所有客户机将会 变得非常难以管理。只分发一个签署了许多证书的 CA 证书容易得多。

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

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

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

只使用 SSL 限制访问

正如刚刚提到的，一旦 SSL 检验过证书，从 SSL 的角度来看身份验证过程就结束了。接下 来理想的情况应该是另一个组件查看证书中的身份，然后使用该身份做出授权决策。授权决策 可以是客户机确认服务器是可信的（Web 浏览器只要核实证书中的名称与 Web 服务器的主机名 称相同，就可以确认服务器可信），也可以是服务器提取用户名，然后使用它为以后的授权决 策创建证书（WebSphere Application Server 在对用户进行身份验证时采取的就是这种方式） 。遗憾的是，并非所有的系统都有这样的功能。对于这样的系统，可以利用流行的 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 和更高版本的设计原则是确保默认情况下的安全性。 目标是在最常见的配置和比较简单的环境中，这个产品在默认情况下具有合理的安全水平，尽 管这个目标还没有完美地实现。显然，复杂的环境会产生难以预料到的独特问题，但是对于比 较简单的环境，我们的目标是让默认的安装和配置能够提供合理的系统安全水平；没有完全安 全的系统，因为这样的东西是不可能存在的。我们也不试图消除每个漏洞，因为许多漏洞的风 险很小，而且在默认情况下封闭它们会显著增加应用程序开发、管理或兼容性的复杂程度。但 是，如果我们认为对于大多数客户机可以以某种方式合理地消除某一漏洞，我们就这么做。

基于基础设施的预防措施

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

图 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 配置有大量网络链路。尽可能地保 护每个链路上的通信流以防范入侵者，这是非常重要的。在本部分剩下的内容中，将讨论保护 刚刚描述的基础设施所需的步骤。下面的列表按优先级次序列出每个步骤。最重要（最关键） 的措施列在最前面。靠后的措施重要性逐渐降低。由您决定您的组织应该完成这个列表中的哪 些措施。

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

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

对浏览器访问使用 HTTPS

配置安全文件传输

保持补丁和修复最新

启用应用程序安全性

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

保护消息传递引擎之间的通信流

加强 Web 服务器和主机

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

加强代理

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

谨慎地使用证书身份验证

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

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

选择合适的进程身份

保护配置文件和私钥

加密从 WebSphere Application Server 到 LDAP 的链路

确保只通过 HTTPS 传输 LTPA cookie

确保定期改变 LTPA 加密密钥

不要在命令行上指定密码

创建单独的管理用户 ID

利用管理角色

考虑加密 Web 服务器到 Web 容器的链路

只使用新的 LTPA cookie 格式

加密 WebSphere MQ 消息传递链路

加密 Distribution and Consistency Services (DCS) 传输链路

保护从应用服务器到数据库的链路

考虑把 cookie 限制为 HTTP Only

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

谨慎地限制可信的签署者

限制为强密码

强制 CSIv2 传输使用 SSL

考虑端口过滤

禁用不使用的端口

考虑禁用密码缓存

考虑启用 FIPS 遵从性

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 所示的防火墙拓扑。

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

图 3. 推荐的防火墙配置

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

3. 对浏览器访问使用 HTTPS

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

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

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

4. 配置安全文件传输

（在 V7 中默认情况下已经解决）

部署管理器使用文件传输协议向节点代理发送配 置更新。在 V6.1 和以前的版本中，在默认情况下这是未经过身份验证的协议。更准确地说， 节点代理使用未经过身份验证的文件传输服务从部署管理器获取管理配置更新。因此，任何外 来的客户机都可能连接到部署管理器并上传任意文件。如果上传无数大文件，操作系统会耗尽 磁盘空间，导致整体故障。理论上也可以下载从部署管理器复制到节点的文件。然而，考虑到 这些文件的短暂特性，这种可能性不大。

为了确保部署管理器只响应来自计算单元中可 信的服务器的文件传输请求，必须安装 filetransferSecured 应用程序并替换现有的不安全的 应用程序。因为此应用程序是一个系统应用程序，所以它通常不可见，但确实存在。IBM 为此 提供了一个脚本，参见 WebSphere Application Server Information Center。清单 1 给出安 装 filetransferSecured 应用程序的步骤（这里显示的是 Windows® 示例，但 UNIX® 基本相同）。清单 1 采用 WebSphere Application Server Network Deployment；如果使用的 是 WebSphere Application Server Base，则服务器名称可能是 server1 而不是 dmgr。

清单 1. 安装 filetransferSecured

cd　\bin　
wsadmin.bat　-user　　-password　　
wsadmin>source　../../../bin/redeployFileTransfer.jacl　
wsadmin>fileTransferAuthenticationOn　　　dmgr　
wsadmin>$AdminConfig　save　

如果没有记住计算单元名称和节点名称，可以在概要的 config 目录中找到它们。请记住， 这个节点是部署管理器的节点，因此名称结尾可能是 “CellManager”。

5. 保持补丁和修复最新

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

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

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

6. 启用应用程序安全性

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

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

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

图 4. 应用程序安全性

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

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

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

WebSphere MQ 安全性警告

因为本文主要关注 WebSphere Application Server 安全性，这一节只讨论如何保护从应用 服务器到 WebSphere MQ 的链路。这并不能保证 WebSphere MQ 本身是安全的。

解决这个问题的一种方法是，在 WebSphere MQ 服务器端实现自己的定制 WMQ 身份验证插 件来对 WebSphere Application Server 发送的用户 ID 和密码进行验证。第二种（可能更简 单的）方法是将 WebSphere MQ 配置为使用 SSL 来进行客户机身份验证，然后确保只有 WebSphere Application Server 服务器持有用于连接 WebSphere MQ 的证书。

8. 保护消息传递引擎之间的通信流

（在 V7 中默认情况下已经解决。）

在 V7 之前，SIBus 在默认情况下提供客户机的身份验证和授权，但是不要求消息传递引擎 相互验证身份。这是一个安全性漏洞，因为入侵者可能可以伪装成消息传递引擎并截获总线通 信流。在总线安全性面板上指定身份验证别名，就可以配置引擎间身份验证（和隐式授权）， 见图 5。

图 5. 消息传递引擎身份验证

9. 加强 Web 服务器和主机

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

本文不讨论加强 Web 服务器 的具体方法，但您应该在操作系统加强、限制装载的 Web 服 务器模块和其他 Web 服务器配置步骤上下足功夫。

在加强 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 管理服务器。这看似是一种比较好的 方法，但是许多人仍然认为这有风险，最好在 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 防火墙。

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 配置

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

必须把 WebSEAL 配置为使用 SSL 与 WebSphere Application Server 进行通信，而且该 SSL 配置必须包含只有应用服务器 Web 容器才知道的客户机证书。

必须配置应用服务器 Web 容器以执行客户机证书身份验证。还必须更改其信任存储库，使 之只包含 WebSEAL 正在使用的客户机证书。这个步骤至关重要，因为只有这样才能保证对应用 服务器 Web 容器的请求仅来自 WebSEAL，而非某个入侵者（仅仅使用相互身份验证的 SSL 是 不够的）。还必须将非 HTTPS 传输从 Web 容器中删除，以确保在与服务器联系时只使用相互 身份验证的 SSL。

必须在 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 支持所有这些技术，但是都需要配置。一定要执行相应的 配置步骤。

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 容器设置为忽略来自客户机的证书信息

如果目标是支持向 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 Information Center。