简介： 安全性不仅仅是在网络边界上保护您不受外部攻击的防火墙。安全性是一组旨在尽可能加强系统安全的复杂的操作和过程。本文讨论安全性概念的多个方面，包括 IBM® WebSphere® Application Server 的安全性架构，讨论如何增强 WebSphere Application Server 环境的安全性。本文是 以前的文章 的修订，针对 WebSphere Application Server V6.1 和 V7 做了大量更新，只关注安全性加强方面。这是由两部分组成的文章的第 1 部分。 本文来自于 IBM WebSphere Developer Technical Journal 中文版。
IBM WebSphere Application Server 的安全性在每个版本中都有所改进。除了在新版本中增加新功能之外，我们还不断增强产品的默认安全性。我们通过改进默认设置不断提高满足默认安全性这一关键原则的程度。本文的前一个版本 主要关注 WebSphere Application Server V6 和那个版本所需的加强步骤。在后续 WebSphere Application Server 版本中，显著减少了加强步骤的数量，更重要的是，保留的大多数步骤不太关键了。因此，现在有必要用新信息更新本文。
本文首先简单讨论安全性为什么重要以及加强系统的困难，然后讨论如何加强 WebSphere Application Server 环境以解决各种安全性漏洞。因为本文主要讨论加强，一些信息是概括性的，没有进行详细分析。我们尽可能提供相关详细信息的适当参考资料，让您能够进一步研究相关的子主题。
尽管本文中的信息基于 IBM WebSphere Application Server V7，但是讨论的大多数问题同样适用于 V6.1。对于某个版本特有的问题，我们会专门指出。如果您使用以前版本的 WebSphere Application Server，请参考 以前的文章，因为有显著差异。
令人欣慰的是，大多数读者都能够认识到安全性是企业系统的一个关键方面。尽管如此，为了介绍一些考虑安全性的常用方法，我们仍将简要介绍一下安全性。
安全性的基本目的是 “阻止不怀好意的人进入您的系统”。更准确地说，安全性是一个过程，它应用多种技术来防止未经授权的用户（通常称为入侵者）对内容进行未经授权的访问。
有许多类型的入侵者：外国间谍机构、竞争对手、黑客，甚至您自己的雇员。每个入侵者都有不同的动机、不同的技能和知识、不同的访问入口以及不同的需求级别。例如：
- 雇员可能对公司有攻击动机。雇员具有非常高的内部访问级别和系统知识水平，但他们的资源和黑客技能可能很有限。
- 外部黑客也许是安全性攻击方面的专家，但是他们对您可能没有攻击动机。
- 外国间谍机构可能对攻击您很感兴趣（这取决于您的业务）并拥有极其丰富的资源。
入侵者可能出于两个原因之一入侵您的系统：为了获取他们本不应该拥有的信息，或者为了以某种方式改变系统的正常行为。在后一种情况中，通过改变系统行为，他们可以尝试执行对其有利的事务，或者只是为了用某种有意思的方式导致系统崩溃，以造成对您的组织的损害。
要点是，有很多不同类型的入侵者、很多不同的入侵动机以及（我们后面将会看的）许多不同的攻击类型。在规划安全性时，必须认识到这些。
安全性措施不应该仅仅视为阻挡 “外人” 的大门。那是一个过于简单化的观点。当前，许多组织将他们的安全性措施完全集中在针对组织以外的人群，他们错误地认为只有外人才是危险的。实际上并不是这样。对于大型公司，往往有数千人能够访问内部网络（其中许多人并不是雇员）。这些人都可能成为入侵者，而且由于他们在内部，他们访问网络更方便。常常只需把笔记本电脑插上网线，就能够访问公司网络。一些研究表明，有将近一半的入侵是 由组织内部的雇员或者承包人造成的（或涉及到他们）。
就算您相信网络中的每个人都是值得信任的，那么也能够相信他们永远不犯错误吗？考虑到通过电子邮件传播的病毒如此猖獗，而且基于 JavaScript™ 的攻击程序和其他程序很容易通过插入计算机的优盘和 CD 进入公司网络并从内部发起攻击，所以假设整个内部网络都可以信任是鲁莽之举 —— 不能这样做。
安全性措施应该努力保护系统不被所有的潜在入侵者攻击，这就是本文为什么如此之长的原因。安全性不仅仅是在网络边界上保护系统不受 “外部” 攻击的防火墙。它是一组旨在尽可能加强系统安全的复杂的操作和过程。
应该认识到没有完全安全的系统，这一点很重要。您的目标是在业务的约束下尽可能保护系统。在考虑安全性时，理想情况下应该：
- 分析攻击的各个方面。
- 考虑每种攻击的风险。
- 确定攻击成功而导致安全性被破坏的可能性。
- 评估为防止每种攻击要付出的代价。
在估计安全性被破坏而造成的损失时，不要忘记安全性被破坏会导致系统用户对系统失去信心。因此，“安全性被破坏的代价” 可能包括非常高昂的间接代价（比如，失去投资者的信任）。
一旦完成以上列出的步骤，就可以对风险与成本做出适当的权衡。从本质上说，目标就是要让入侵者为入侵系统而付出的代价超过他们可以获得的利益，同时确保业务能够承受运行安全系统所付出的代价（见边栏）。
归根结底，需要什么安全级别是一个业务决策，而不是技术决策。然而，作为技术人员，我们必须帮助所有各方理解安全性的价值和重要性。因此，除了保护内部应用程序免受攻击外，本文中建议的大多数安全性加强步骤的成本都相当低。大多数组织都应该都有能力实现它们。本文没有介绍比较复杂和昂贵的安全性方法 —— 强身份验证、审计和入侵检测等，它们超出了 WebSphere Application Server 产品功能的范围。
安全性是一个很大的主题，本文不可能完全覆盖安全性的所有方面。本文不是对安全性的介绍或者关于如何保护系统的教程。而是对涉及 WebSphere Application Server 安全性时需要考虑的核心技术问题的概述或检查表。本文中的信息应该与创建安全企业的更大型工作结合起来。
希望了解更多信息的读者请查阅 参考资料 部分。特别是 我的网站 提供一些应用程序安全性基本知识的概要性说明，不过有些内容是过时的。
由于这是一篇技术性的文章，因此重点讨论保护系统的技术解决方案，具体地说主要集中于安全性难题的 WebSphere Application Server 部分。尽管如此，您应该意识到使用社会工程技术危害系统往往更加简单。也就是说，通过欺骗在组织中工作的人员，攻击者可以获得权限以访问他们本不应该访问的系统和信息。从社会工程攻击技术可以得出的一个结论是：通过使用社会工程，攻击者可能来自您的网络内部。这再次强调了前面提到的观点：仅仅防御来自网络外部的攻击者是远远不够的。因此，这里的讨论集中于多个级别的安全性。每个级别防范不同的攻击类型，并提供对攻击者更有效的屏障。
在详细研究具体建议之前，我们先花一些时间来概述创建安全系统的基础技术。基本观点是着眼于每个系统边界或共享点，检查哪些参与者访问了这些边界或共享的组件。也就是说，假设这些边界存在（假设子系统内部比较可信），那么入侵者如何突破这些边界呢？或者，假定某些东西是共享的，那么入侵者是否可以不正当地共享某些东西呢？
大多数边界是很明显的：网络连接、进程与进程的通信、文件系统、操作系统接口等等，但是有些边界不容易辨别。例如，如果一个应用程序使用 WebSphere Application Server 中的 J2C 资源，那么必须考虑另一个应用程序试图访问这些资源的可能性。这是因为第一个应用程序和 WebSphere Application Server 之间以及第二个应用程序和 WebSphere Application Server 之间都存在系统边界。可能这两个应用程序都可以访问这个资源（实际上它们确实可以）。这可能是不合理的共享。
要防止各种形式的攻击，可以应用许多众所周知的技术。对于较低层的基于网络的攻击，可以应用加密和网络过滤。这样可以拒绝入侵者查看或访问他们不应该看到的内容。还依赖操作系统提供的机制来保护操作系统资源不被滥用。例如，不希望普通用户级代码能够访问系统总线以及直接读取内部通信。还利用大多数现代操作系统对系统 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）是 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 是匿名的。
在查看此图时，请注意客户机必须持有签署服务器生成的公钥所用的证书。这是信任的关键部分。由于客户机信任它拥有的任何证书（在本例中包括 CA 证书），所以它信任 CA 签署的证书。如果您使用自签名证书，这没有什么价值，因为您需要手工地将这些自签名证书分发到每个客户机，而不是依靠可能已经在客户机中构建的众所周知的 CA 证书。这并非不安全，但如果您有许多客户机，要将所有这些签名证书（每个服务器对应一个）分发到所有客户机将会变得非常难以管理。只分发一个签署了许多证书的 CA 证书容易得多。
对于使用 SSL 的服务器身份验证来说更是如此。在最初的握手阶段之后，SSL 实际上将改为使用在握手期间生成的机密密钥执行加密，以此保护通信通道，但其细节与本讨论无关。
当客户机向服务器验证其自身的身份时，虽然角色相反，但过程与此相似。为了让服务器对客户机进行身份验证（这通常称为客户机证书身份验证，在与服务器身份验证一起使用时称为双向 SSL），客户机必须持有一个私钥和相应的证书，而服务器必须持有相应的签名证书或客户机证书的拷贝。这对它来说是举手之劳。请注意什么不是必需的：SSL 证书身份验证仅仅确定证书的有效性，而不关心该证书代表谁。这是 SSL 后处理的责任。这有着重要的意义，稍后我们将会看到。
总之，因为 SSL 使用证书身份验证，所以 SSL 连接的每一端都必须在密钥存储文件中持有适当的密钥。在配置 SSL 密钥存储库时，需要考虑哪一群体需要哪些密钥的基本规则。通常，这将让您知道您需要什么。
正如刚刚提到的，一旦 SSL 检验过证书，从 SSL 的角度来看身份验证过程就结束了。接下来理想的情况应该是另一个组件查看证书中的身份，然后使用该身份做出授权决策。授权决策可以是客户机确认服务器是可信的（Web 浏览器只要核实证书中的名称与 Web 服务器的主机名称相同，就可以确认服务器可信），也可以是服务器提取用户名，然后使用它为以后的授权决策创建证书（WebSphere Application Server 在对用户进行身份验证时采取的就是这种方式）。遗憾的是，并非所有的系统都有这样的功能。对于这样的系统，可以利用流行的 SSL 技巧：限制有效的证书。
在前面涉及客户机身份验证的场景中，客户机提供一个证书，然后服务器根据可信的证书签署者集对其进行检验。一旦检验通过，SSL 握手就完成了。如果限制服务器上可信的签署者，就可以限制谁能完成 SSL 握手。在自签名证书的极端情况下，可以创建只有一个签署者的情形：只有一份自签名证书。这意味着只有一个有效的客户机私钥可以用于连接此 SSL 端点：也就是在创建自签名证书时生成的私钥。通过这种方式可以轻松地限制谁能通过 SSL 连接到系统，即使服务器端组件不提供授权。可以将这看作是在网络层上创建安全的可信隧道。假设一切都已正确配置完成，那么只有特定的可信客户机才可以通过这一通道连接。这在 WebSphere Application Server 中的几种情况下非常有用，这一点我们后面将会讨论。
正如我们已经看到的，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 中，链路上的字母表示在那些通信链路上使用的协议。对于每个协议，我们列出其用途并提供一些关于防火墙友好性的信息，因为这对于后面的讨论很重要。协议如下：
- 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 可以是防火墙友好的。
- 用途：管理客户机和 WebSphere Application Server 内部服务器管理通信流。WebSphere Application Server 内部通信使用以下几种协议之一：
- 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 中。网络传输负载平衡器（例如 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 中的组件必须不是复杂的应用服务器，必须加强了安全保护，还必须终止入站连接。
现在，大多数组织都理解 DMZ 将 Internet 上的外人与内部网隔离开的价值。然而，非常多的组织没有意识到许多入侵者是来自内部的。正如前面提到的，需要同时防范来自内部和外部的威胁。正如保护自己免受来自大量不可信的 Internet 用户攻击一样，您也应该保护生产系统免受大量不可信的内部网用户攻击。
可以使用防火墙将生产网络与内部网络隔离开。这些防火墙看似比面向 Internet 的防火墙随意得多，但仍然能够防御许多形式的攻击。通过应用这一步骤和前一步骤，应该可以建立图 3 所示的防火墙拓扑。（有关 WebSphere Application Server 防火墙端口分配的更多信息，请参阅 WebSphere Application Server V5 中的防火墙端口分配。）
注意，我们在防火墙的边缘放置了 wsadmin。这样做是为了试图说明，虽然最好只让 wsadmin 在生产网络内（受保护的区域内）运行，但也可以把 wsadmin 访问限制为与管理员桌面对应的特定地址，从而非常容易地穿过防火墙访问 wsadmin。图 3 还在边缘上显示 EJB 客户机，因为它们可能位于防火墙的任一侧。
这里只显示单个防火墙，而不是面向内部网的整个 DMZ，因为这是最常见的拓扑。然而，完整的 DMZ（以及内部 DMZ 中的 Web 服务器）越来越常见了，它们保护生产网络免受来自非生产内部网的攻击。这的确是一种合理的方法。
如果站点要执行任何身份验证或者有任何应该保护的活动，则需要对从浏览器到 Web 服务器的访问使用 HTTPS。如果不使用 HTTPS，则密码、用户活动、WebSphere Application Server 会话 cookie 和 LTPA 安全令牌（见边栏）等信息可能被入侵者看到，因为通信流要穿过外部网络。
对于在执行身份验证之前允许 HTTP 通信流的应用程序，一定要密切注意 cookie。如果一个 cookie（比如 JSESSIONID）是在使用 HTTPS 之前设置的，那么在使用 HTTPS 之后它可能带来风险，因为入侵者可能已经修改或捕获了它。这正是 WebSphere Application Server 对经过身份验证的用户使用单独的 cookie 的原因。另一种更狡猾的攻击方法是，入侵者可以修改通过 HTTP 返回的任何页面 —— 甚至包括页面中嵌入的 URL。因此，用户可能会单击页面上看似安全的 URL，但是他实际上会被转到入侵者的站点上。
（在 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。
cd \bin wsadmin.bat -user -password wsadmin>source ../../../bin/redeployFileTransfer.jacl wsadmin>fileTransferAuthenticationOn dmgr wsadmin>$AdminConfig save |
如果没有记住计算单元名称和节点名称，可以在概要的 config 目录中找到它们。请记住，这个节点是部署管理器的节点，因此名称结尾可能是 “CellManager”。
与其他复杂产品一样，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 基础设施的建议。
在默认情况下，WebSphere Application Server 启用管理安全性。因此，在大多数情况下，基础设施默认地为管理通信流提供合理的身份验证、授权和加密。在启用管理安全性时，部署管理器和应用服务器之间的 WebSphere Application Server 内部链路以及从管理客户机（Web 和命令行）到部署管理器的通信流是经过加密和身份验证的（图 3）。这意味着，在运行管理工具时，需要对管理员进行身份验证。后面会讨论一些例外情况。
除了在管理方面利用应用服务器的安全性之外，强烈建议在应用程序安全性方面利用它。这样做可以让应用程序能够访问强大、健壮且基于标准的安全性基础设施。在不利用应用服务器安全性的应用程序中，常常会发现很严重的安全性漏洞。设计和实现安全的分布式基础设施并不容易。
要想启用应用程序安全性，应该进入全局安全性面板并选择 Enable application security（不需要启用 Java 2 安全性；正如后面讨论的，它常常不合适），见图 4。
警告：仅仅启用应用程序安全性并不能确保应用程序是安全的。这只是让应用程序能够利用应用服务器提供的安全特性（包括 Java EE 安全性）。后面会进一步讨论这个主题。
如果使用 WebSphere MQ 作为消息传递提供者，则需要通过其他技术来提供队列授权。当使用客户机/服务器模式时（绑定模式依赖于计算机中的进程到进程身份验证），在默认情况下 WebSphere MQ 并不执行任何用户身份验证。事实上，当在连接工厂上为 WebSphere MQ 指定用户 ID 和密码时，这些值会被 WebSphere MQ 忽略。
解决这个问题的一种方法是，在 WebSphere MQ 服务器端实现自己的定制 WMQ 身份验证插件来对 WebSphere Application Server 发送的用户 ID 和密码进行验证。第二种（可能更简单的）方法是将 WebSphere MQ 配置为使用 SSL 来进行客户机身份验证，然后确保只有 WebSphere Application Server 服务器持有用于连接 WebSphere MQ 的证书。（更多信息参见 保证 WebSphere Application Server 和 WebSphere MQ 之间连接的安全；这篇文章有点儿过时了，但是相同的原理和技术也适用于这两个产品的新版本。在实现其中提到的技术时，应该考虑到产品的变化。）
（在 V7 中默认情况下已经解决。）
在 V7 之前，SIBus 在默认情况下提供客户机的身份验证和授权，但是不要求消息传递引擎相互验证身份。这是一个安全性漏洞，因为入侵者可能可以伪装成消息传递引擎并截获总线通信流。在总线安全性面板上指定身份验证别名，就可以配置引擎间身份验证（和隐式授权），见图 5。
如果采用 步骤 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 管理服务器。这看似是一种比较好的方法，但是许多人仍然认为这有风险，最好在 DMZ 中根本没有管理功能。
当安装 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，并在过程结束时再次将其删除。
如果把安全代理服务器放在 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。
证书身份验证可能导致两种非常特殊的风险：
- 撤消：证书可能被破解，必须采取措施以撤消被破解的证书。
证书提供一种强大的身份验证形式，从安全性的角度来说非常不错。但是，必须考虑到撤消的问题。因为用户控制自己的私钥，所以私钥有可能被窃取。因此，所有 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。
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 技巧来限制具有访问权限的群体。具体地说，需要执行以下操作：
- 为 Web 容器创建一个密钥存储库和信任存储库，为 Web 服务器插件创建一个密钥存储库。
- 从所有密钥存储库（包括信任存储库）删除所有现有的签名证书。此时，不能使用任何密钥存储库来检验证书。这样做是有意的。
- 在这两个密钥存储库中创建自签名证书，并只导出该证书（而不是私钥）。一定要记录这些证书的到期时间。当插件证书到期之后，它就不能联系 Web 容器了！将从 Web 容器密钥存储库中导出的证书导入到插件密钥存储库中。将插件证书导入到 Web 容器信任存储库中。现在，每一端都只包含一个签名证书。这意味着只能使用它们检验一个证书 —— 为对方创建的自签名证书。
- 将新创建的密钥存储库安装到 Web 容器和 Web 服务器插件中。
WebSphere Application Server 附带了几个非常好的示例，它们演示 WebSphere Application Server 的各个部分。这些示例不是为在生产环境中使用准备的。不要在生产环境中运行它们，因为它们会带来严重的安全风险。特别是 showCfg 和 snoop Servlet 会向外部人员提供大量关于您的系统的信息。这正是您不希望潜在的入侵者获得的信息。只要不在生产环境中运行 server1（它包含这些示例），就很容易解决这个问题。如果使用的是 WebSphere Application Server Base，实际上应该从 server1 中删除这些示例。
WebSphere Application Server 进程是在操作系统上运行的，因此必须在某个操作系统身份下运行。有三种运行 WebSphere Application Server 的方式与操作系统身份有关：
- 以 root 身份运行一切程序。
- 以单一用户身份（例如 “was”）运行一切程序。
- 以 root 身份运行节点代理，以应用服务器自己的身份运行各个应用服务器。
IBM 测试过并完全支持前面两种方法。第三种方法看似很有吸引力，因为那样就可以利用操作系统权限，但它在实践中不是非常有效，这有以下几点原因：
- 配置它非常困难，而且过程没有文档说明。许多 WebSphere Application Server 进程都需要对无数文件具有读访问权限，并对 log 和 transaction 目录具有写访问权限。
- 通过以 root 身份运行节点代理，实际上会向 WebSphere Application Server 管理员和在 WebSphere Application Server 中运行的任何应用程序授予 root 权限。
- 这种方法的主要价值在于控制应用程序对文件系统的访问。但是，使用 Java 2 权限也可以实现这一点。
- 这种方法会造成应用程序互相隔离的错觉。其实不是。WebSphere Application Server 内部安全模型基于 J2EE 和 Java 2 安全性，不受操作系统权限的影响。因此，如果选择使用这种方法来保护自己免受 “恶意” 应用程序的侵害，则方法的方向错了。
第一种方法明显是不可取的，因为作为一般的最佳实践，如果可以的话，最好避免以 root 身份运行任何进程。这样就只剩下第二种方法，它是完全受支持的。在某些很少见的情况下，并不关心应用程序隔离，但是希望以不同的操作系统身份运行应用程序以便审计，那么可以使用第三种方法。这从安全性的角度来看没有价值，而且实际上会略微增加风险，但是有可能使用操作系统级审计。
应该利用操作系统文件权限来限制对 WebSphere Application Server 文件的文件系统访问。与任何复杂的系统一样，WebSphere Application Server 使用和维护大量敏感信息。一般来讲，不应该有人对大多数 WebSphere Application Server 信息具有读或写权限（见边栏）。特别是 WebSphere Application Server 配置文件 (/config)，它既包含配置信息，也包含密码。
另外，应该注意避免不小心共享密钥。例如，不要在生产环境中使用与其他环境中相同的密钥。许多人对开发和测试计算机及他们自己的密钥有访问权限。应该谨慎地保护生产环境用的密钥。
如果不谨慎地控制谁对文件系统有写访问权限，用户只需手工编辑配置文件，就可以破坏产品的安全性控制（比如审计）。
18. 加密从 WebSphere Application Server 到 LDAP 的链路
当使用 LDAP 注册表时，WebSphere Application Server 会使用标准的 ldap_bind 来验证用户密码。这要求 WebSphere Application Server 将用户密码发送到 LDAP 服务器。如果该请求没有加密，则黑客可以使用网络嗅探器来窃取用于身份验证的用户密码（包括管理密码！）。大多数 LDAP 目录都支持 LDAP over SSL，并且可以把 WebSphere Application Server 配置为使用它。在 LDAP 用户注册表面板中（请参见图 7），选中 SSL enabled 选项，然后配置适合您的 LDAP 目录的 SSL 配置。很可能需要将用于 LDAP 服务器证书的签名密钥（证书）放在信任存储库中。最好是创建只供 LDAP 使用的新的 SSL 配置，以避免给当前使用 SSL 的其他领域造成问题。
如果使用定制的注册表，显然需要使用任何可用的机制来保护该通信流。
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 发送。
通过在会话管理面板上指定相似的设置，还可以把 HTTP Session（默认情况下是 JSESSION） cookie 限制为只使用 SSL。
警告：在安装 APAR PM00610 之前，Requires SSL 标志在 WebSphere Application Server V7 中无效。一定要安装它。
WebSphere Application Server 使用 LTPA 加密密钥加密各种用户令牌（包括 LTPA cookie）。与任何密码术密钥一样，应该定期改变这些密钥。根据 WebSphere Application Server 和补丁级别不同，自动密钥生成在默认情况下可能启用了，也可能关闭了；版本越新，默认情况下它关闭的可能性越大。
应该确保定期改变 LTPA 加密密钥。可以启用自动 LTPA 密钥替换（见图 9），也可以手工地重新生成密钥（见图 10）。无论选择哪种方式，一定要考虑 LTPA 密钥不一致的问题：
- 首先，如果计算单元中的某些节点在一段时间（比如密钥寿命的两倍）内一直停机，它们就会丧失通信能力。
- 第二，如果与其他组件（比如另一个计算单元或 WebSphere DataPower）共享 LTPA 密钥，那么在改变密钥时，就需要在所有地方更新它们，这通常会造成停机。
图 9. 启用自动 LTPA 密钥更新
图 10. 手工生成新的 LTPA 密钥
一旦启用了安全性，WebSphere Application Server 管理工具就要求您只有通过身份验证才能使用它。执行身份验证的明显方式就是在命令行中指定用户 ID 和密码，将其作为参数传递给该工具。请不要这样做。这会向在您身边窥探的任何人暴露您的管理密码。而且在许多操作系统中，任何可以看到进程列表的人都可以看到命令行上的参数。相反，应该确保由管理工具提示输入用户 ID 和密码。从 WebSphere Application Server V6.0.2 起，如果在命令行上没有提供用户 ID 和密码，所有管理工具会自动提示输入。不需要其他的操作。
如果使用以前版本的 WebSphere Application Server，则可以通过让这些工具使用 RMI（默认是 SOAP）通信来强制它们提示输入用户 ID 和密码。RMI 引擎在需要时会显示提示。要实现这一点，只需指定：
–conntype RMI –port
下面的示例以这种方式启动 wsadmin，连接到监听默认端口的部署管理器：
wsadmin.sh –connectype RMI –port 9809
如果觉得命令行工具以图形方式提示输入用户 ID 和密码非常烦人，可以改变该行为，让工具使用基于文本的简单提示。要实现这一点，应该通过编辑合适的配置文件，将 loginSource 从 prompt 改为 stdin。在默认情况下，管理工具使用 SOAP，因此应该编辑 soap.client.props 文件。如果使用的是 RMI，则编辑 sas.client.props。请在适当的文件中查找 loginSource 属性，并更改它以指定 stdin。
当为 WebSphere Application Server V6.1 和更高版本配置安全性时，在开始时会配置一个主管理 ID（见边栏）。这个 ID 实际上等同于 WebSphere Application Server 中的根用户，它能够执行任何管理操作（包括下一节提到的所有管理角色）。由于这个 ID 很重要，所以最好不要随便共享其密码。理想情况下，在最初配置之后不应该再使用这个 ID。
与大多数系统一样，WebSphere Application Server 允许多个主体担任管理员。只需使用管理应用程序并进入系统管理控制台用户（或用户组）部分，指定应该授予管理权限的其他用户或用户组。当进行这样的授权之后，在管理 WebSphere Application Server 时每个人都可以以自己的身份进行身份验证。从 WebSphere Application Server 5.0.2 开始，会导致更改 WebSphere Application Server 配置的所有管理操作都需要经过部署管理器的审核，包括执行更改的主体的身份。从 V7 开始，引入了一个新的审计框架，它可以提供更详细的管理操作审计信息。显然，如果每个管理员有单独的身份，这些审计记录会更有用。
在由中心管理员管理多个 WebSphere Application Server 计算单元的环境中，为每个管理员授予单独的管理访问权限会非常方便。虽然每个计算单元都有自己的本地 “根” ID 和密码，但是可以配置所有这些计算单元以共享公共注册表，这样管理员就可以使用相同的 ID 和密码来管理每个计算单元。
根据版本不同，WebSphere Application Server 允许不同的管理角色：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 可以更改配置，但是无法 “掩盖” 操作痕迹，因为他无法禁用审计。
即使不对从 Web 服务器到 Web 容器的链路进行身份验证，也可能希望考虑对它进行加密。Web 服务器插件通过 HTTP 把来自 Web 服务器的信息传输到 Web 容器。如果到达 Web 服务器的请求使用的是 HTTPS，那么在默认情况下插件使用 HTTPS 转发请求。如果到达的请求使用的是 HTTP，那么插件使用 HTTP。这些默认行为对于大多数环境是合适的。但是，有一种例外情况。
在某些环境中，当请求到达您的网络之后，会在其中添加敏感信息。例如，一些身份验证代理服务器（比如 WebSEAL）会在请求中添加密码信息。Web 服务器中的定制代码可能做相似的事情。如果是这种情况，应该采取额外步骤保护从 Web 服务器到 Web 容器的通信流。要想迫使从此插件发出的所有通信流都使用 HTTPS，只需在每个应用服务器上的 Web 容器中禁用 HTTP 传输，然后重新生成和部署插件（图 11）。现在，此插件只能使用 HTTPS，所以无论通信流如何到达 Web 服务器，它都使用 HTTPS 执行转发。
（在 V7 中默认情况下已经解决。）
WebSphere Application Server V5.1.1 为支持 主题传播 引入了一种新的 LTPA cookie 格式 (LTPAToken2)。在引入新格式的同时，也解决了旧格式中一些理论上的缺点。请记住，这些缺点只是在理论上存在的；还没有出现已知的威胁。无论如何，应该使用新的更强的格式，除非不得不使用旧格式。
新的 LTPA 令牌使用以下强加密技术：
- Random salt
- 强 AES 密码
- 对数据签名
- 对数据加密
出于好奇，我们使用 1024 位 RSA 密钥对进行签名，使用 128 位机密密钥 (AES) 进行加密。用于加密的密码是 AES/CBC/PKCS5Padding。
在 V7 之前，默认情况下同时支持新旧 cookie 格式，以确保在创建 LTPA cookie 时与其他系统相兼容，例如较老版本的 WebSphere Application Server、IBM Lotus® Domino®（V8 以前的版本）和 Tivoli Access Manager WebSEAL（V6 以前的版本）。如果您不需要这种兼容性，则应该禁用它。要禁用它，请进入 Security > Authentication Mechanisms > LTPA > SSO configuration 面板并取消选择 interoperability mode（图 12）。
警告：在 V7 以前，不能同时禁用互操作性和安全属性传播（也称为主题传播）。如果同时禁用它们，身份验证就会失败。
如果您使用的是 WebSphere MQ 而非默认的消息传递提供者，当然应该对 WebSphere MQ 使用 SSL。有关这一点的更多信息，请参阅 参考资料。 在 WebSphere Application Server V7 中，WebSphere MQ 客户机 SSL 配置是第一类构造，可以像其他 SSL 配置一样通过管理控制台设置。
27. 加密 Distribution and Consistency Services (DCS) 传输链路
核心组依赖于 DCS，它使用可靠的多播消息 (RMM) 系统来进行传输。RMM 可以使用几种有线传输技术之一。根据环境不同，可以通过 DCS 传输敏感信息。例如，使用 DCS 传输 DynaCache 和安全性主题缓存中的数据。为了确保这一点，需要选择一种通道框架传输类型，并选择 DCS-Secure 作为每个核心组的通道链（图 13）。
请注意，当启用全局安全性时，DCS 始终对消息进行身份验证。一旦传输被加密，就有了一个高度安全的通道。
一旦做到这一点，所有依赖于 DCS 的服务都将使用加密且经过身份验证的传输。这些服务是 DynaCache、内存到内存会话复制、核心组、Web 服务缓存和有状态会话 bean 持久化。
与其他任何网络链路一样，机密信息可以被写入数据库或从数据库中读取。大多数数据库都支持某种形式的身份验证，您应该利用它。
这里是一个 IBM DB2 示例。
如果黑客能够通过在浏览器中插入恶意的 JavaScript. 攻破 Web 应用程序（这通常称为跨站点脚本攻击），就可以执行许多恶意操作，应用程序实际上完全被攻破了。他们可以执行的恶意操作之一是窃取 LTPA cookie 等敏感的 cookie。大多数现代 Web 浏览器都支持 HTTP Only cookie 概念。
WebSphere Application Server 提供一种确保把 LTPA cookie 标为 HTTP Only 的方法。这需要把安全性定制属性 com.ibm.ws.security.addHttpOnlyAttributeToCookies 设置为 true。（这是最近通过 APAR PK82764（V6.0 或 V6.1）或 PM03760（V7）增加的。）
目前，这个属性只用 HTTP Only 标志保护 LTPA cookie。对于使用 Java EE 安全性并启用会话安全性（稍后讨论）的以正确方式编写的应用程序，这应该足够了。
但是，即将发布的一个 APAR (PK98436) 将支持在任意 cookie 上设置 HTTP Only 标志。当这个新特性推出之后，应该使用它而不是老特性，因为它更灵活更完整。这个 APAR 允许通过 Web 容器属性 com.ibm.ws.webcontainer.httpOnlyCookies 控制要保护的 cookie。这个属性的值是要保护的 cookie 的逗号分隔列表（* 表示所有 cookie）。
警告：尽管这个 APAR 看起来是防御跨站点脚本攻击的解决方案，但它不是。如果黑客可以在您的浏览器中执行任意代码，他们能够造成的危害远远不只是窃取 cookie。他们实际上可以看到浏览器屏幕上的所有内容，可以捕获每次击键，这比窃取 cookie 严重多了。
当使用 SSL 进行通信时，安全地交换信息的关键之一是根据客户机信任存储库检验服务器的证书。如果由于在信任存储库中没有相应的签署者，服务器提供的证书不可信，那么大多数客户机（Web 浏览器、SSH、wsadmin 等）会提示用户决定应该怎么做。这些客户机通常会向用户警告这是一个未知的证书，提供证书的指纹（通常是 SHA），并询问 should I trust this?。遗憾的是，大多数用户会盲目地单击 yes。这是一个可怕的决定。如果这么做，就不知道您将与什么服务器通信。对于 WebSphere Application Server 管理客户机，下一步就是把管理用户 ID 和密码发送到未知的服务器。
相反，管理员应该检查指纹信息，判断它是否是正确的指纹（理想情况下最终用户也应该这么做）。管理工具提供了查看证书指纹的方法。在管理控制台中选择一个个人证书，显示它的指纹。
用户（尤其是管理员）应该了解指纹信息，当客户机（无论是 Web 浏览器还是 wsadmin）提示时理想情况下应该检验指纹。
图 15. Web 服务器证书警告，第一部分
图 16. Web 服务器证书警告，第二部分
清单 2. 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)
|
即使您不采纳这个建议，至少应该在第一次遇到警告时把证书导入客户机信任存储库。如果再次看到消息，一定要查明原因！在证书更改之前，提示应该不会再次出现。如果出乎意外地出现提示，一定有很严重的错误。
在使用证书身份验证（客户机或服务器）时，需要理解信任存储库中的每个签署者都代表一个可信的身份信息（证书）提供者。您信任的签署者应该尽可能少。否则，有可能两个签署者颁发的证书映射到同一个用户身份。这会在架构中造成严重的安全漏洞。
应该检查客户机和服务器上的信任存储库，删除任何不需要的签署者。在默认情况下，信任存储库包含的可信签署者比以前的版本少得多，这有助于提高默认情况下的安全性。但是，仍然有几个签署者问题可能需要解决：
- 在默认情况下，信任存储库中有 dummyclientsigner 和 dummyserversigner，它们用于与使用这些默认签署者的以前版本兼容（我们一直建议不使用它们）。在 V7 中默认情况下没有这些签署者。
- 在默认情况下，KDB/CMS 密钥存储库包含大多数众所周知的 CA 的签署者。没有合理的理由这么做，应该删除它们。
- 在 V7 中，默认的计算单元信任存储库包含一个 WebSphere DataPower 签名证书，这意味着所有 DataPower 计算机都可以颁发应用服务器所信任的证书。为了提高安全性，应该删除它。
（在 V7 中默认情况下已经解决。）
当通过 SSL 通信时，通信流会加密。为了更好地保护通信流，应该使用强密码。遗憾的是，在 V7 之前，默认的 SSL 强密码选择包含一些明显非常弱的密码。应该删除这些密码，否则客户机可能会选用它们。正常情况下，如果 Web 服务器支持强密码，客户机会隐式地选择强密码，但是最好确保这么做。
尽管这里不详细讨论，但是还应该确保把 Web 服务器配置为只接受使用强密码的通信流。
当 WebSphere Application Server 服务器和客户机使用 CSIv2 IIOP 进行通信时，它们之间协商传输安全性。选择对双方来说都可接受的形式。一般来说，这是可以的，但应该注意一个潜在的漏洞。WebSphere Application Server 支持 CSIv2 over SSL 或明文方式。在默认情况下，双方通常会协商使用 SSL，从而建立加密的通信通道。然而，如果在协商中有任意一方请求使用明文，则将使用明文。您甚至可能不会意识到通信流是以明文方式发送的！这种问题可能出现，例如如果一个客户机配置错误的话。如果想要（也应该）保证通信流是加密的，更保险的做法是确保始终使用 SSL。
可以通过在 CSlv2 入站传输面板中指明 SSL 是必需而不是可选的，从而确保对 IIOP 使用 SSL。对 CSIv2 出站传输也应该这样做（图 18）。
有时候，希望根据网络信息限制谁可以连接。尽管这样的配置对于安全性不一定有价值，但是为了完整，这里仍然讨论一下。WebSphere Application Server 中的大多数传输（IIOP 除外）使用 Channel Framework，因此可以使用包含或排除列表根据 IP 地址或 DNS 名称过滤入站通信流。
警告：伪造 IP 地址是相当容易的，所以依靠 IP 地址保证安全性是不明智的。在 WebSphere Application Server 中根据 IP 地址进行过滤尤其不明智。更好的方法是装备防火墙和交换机，从而识别来自无效 IP 地址的数据包。它们还可以检查 MAC 地址。
加强安全性的基本原则是使潜在攻击的攻击面最小化。当给定的服务没有已知的安全问题时尤其应该这样。如果该服务对系统的正常运转是不必要的，则应该将其删除，从而尽可能降低攻击者在将来的某个时候利用这个多余的功能进行攻击的可能性。查看图 20，您会看到典型的 WebSphere Application Server 应用服务器正在监听大量端口。
图 20. Network Deployment 应用服务器的默认端口
如果给定的服务不是必需的，则可以禁用其监听的端口。查看此列表，可以考虑禁用的端口是：
- SAS_SSL_SERVERAUTH_LISTENER_ADDRESS：用于与 WebSphere Application Server V4 和更早版本兼容。这是旧的 IIOP 安全性协议。从 V5 开始，CSIv2 替代它了。
- SIB_ENDPOINT_*：供内置的消息传递引擎使用。如果没有使用消息传递，则不需要使用它们。
- SIB_MQ_*：供消息传递引擎在与 WebSphere MQ 连接时使用。
- 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_* 端口，所以不需要对它们采取措施。
警告：在决定要禁用哪些端口时以及在实际禁用它们时，应该特别谨慎。否则，可能无意间禁用管理端口，这样就会禁用管理进程的机制，无法删除和重新创建进程（例如服务器）定义。
在执行基于密码的身份验证时，运行时会以单向散列的形式缓存密码，供以后检验时使用。因为这个散列是不可逆的，所以密码没有被截获（甚至包括通过内存转储截获）的危险，但是这个缓存对安全性有影响。如果以后到达的请求要求身份验证，而且它们使用相同的用户 ID 和密码组合，就会使用缓存的密码数据（和用户信息）。这意味着，即使注册表中的用户密码更改了，他仍然能够使用旧的密码通过身份验证，直到缓存到期为止（默认情况下是 10 分钟）。
一些人认为这是一个安全性漏洞（作者并不认同）。如果您担心这个问题，可以通过设置 JVM 级属性 com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled 禁用密码缓存。设置之后，就不再缓存密码，对于所有密码身份验证，都要查询注册表。请记住，这对性能有显著的消极影响。如果使用每个请求都要求身份验证的无状态协议（比如使用 UserNameTokens 的 WS-security），这会产生很大的注册表身份验证通信流。
在执行加密时，有多种密码学算法可供选择。另外，在建立 SSL 连接时，实际上有三个选择：SSL V2（在默认情况下禁用）、SSL V3 和 TLS。美国政府已经定义了与计算机安全性有关的标准 (Federal Information Processing Standards)，涵盖许多领域。在这些标准中，认证了符合 FIPS 标准的密码技术，还认证了 TLS（但是没有认证 SSL V3）。
如果用户希望把应用程序限制为只使用符合 FIPS 的密码技术和 TLS，可以手工配置每个端点，也可以使用管理工具启用 FIPS 遵从性。启用 FIPS 之后，就只使用 符合 FIPS 的密码技术。
这篇分两部分的文章的第 1 部分讨论了安全性的几个方面，主要关注加强 WebSphere Application Server 环境的核心方案。希望这些信息能够向您提供切实保护 Java EE 环境所需的基础知识。
第 2 部分将讨论更广泛的主题，包括基于应用程序的预防措施、计算单元信任、跨计算单元信任、管理和应用程序隔离、身份传播、桌面开发安全性等等。
如果希望进一步了解 WebSphere Application Server 安全性，请联系 IBM Software Services for WebSphere，参加关于 WebSphere Application Server 安全性的定制的现场课程。这个课程深入讲解安全性加强、定制身份验证、集成、单点登录和各种其他相关主题。
原文链接:http://www.ibm.com/developerworks/cn/websphere/techjournal/1004_botzum/1004_botzum.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-669858/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-669858/
4016
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
