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。