级别： 初级 Keys Botzum, Senior Consulting I/T Specialist, IBM Software Services for WebSphere
2004 年 9 月 01 日 安全性的组成不仅仅是在您的网络边缘防止外部威胁的防火墙。它是一套困难且复杂的操作和规程，致力于尽可能的加固您的系统。本摘录包括了许多常见的安全方面内容，详细介绍了 WebSphere Application Server 安全性体系结构，还讨论了如何加固 WebSphere Application Server 环境，并提供了关于安全性故障诊断的一些技巧。
本文摘录于新书
IBM WebSphere：部署及高级配置，该书的作者是 Roland Barcia、Bill Hines、Tom Alcott 和 Keys Botzum，本书将于 2004 年 8 月由 IBM Press 出版。本文进行了编辑和排版以作为独立的文章发布。
引言
在本文中，我们将介绍安全性的几个方面。我们将首先简单讨论一下安全性为什么重要，然后详细介绍 WebSphere Application Server 安全性体系结构。本文将说明 WebSphere Application Server 安全性的一些要点，然后详细讨论如何加固 WebSphere Application Server 环境以使其更加安全。最后，会提供一些关于安全性问题故障诊断的技巧。由于篇幅有限，本资料的很多内容是高级别的，且没有进行详细分析。我们将尽可能的为读者适当引用详细信息。
为什么需要安全性？
大多数读者都能够认识到安全性是企业系统的一个关键方面。尽管如此，为了引入一些理解安全性的常用方法，我们仍将简短的介绍一下安全性。
安全性的基本目的是为了阻止坏人进入您的系统。进一步说，安全性是一个流程，它应用多种技术来防止未经授权的用户（也就是通常所说的入侵者）对内容进行越权访问。
有多种类型的外部入侵者：外国间谍机构、您的竞争对手、黑客、甚至是您自己的雇员。每个入侵者都有不同的动机、不同的技能和知识、不同的访问入口以及不同的需求级别。例如：
- 雇员可能对公司有攻击动机，虽然雇员有非常高的内部访问和系统知识级别，但他们的资源和黑客技能可能很有限。
- 外部黑客也许是安全性攻击的专家，但是他们可能对您并无攻击的动机。
- 外国间谍机构，可能对攻击您很感兴趣（这取决于您的业务）并且拥有丰厚的资源。
入侵者可以为了两个原因其一而侵入您的系统：为了获取他们本不应该拥有的信息，或者为了用某种方式改变系统的正常运转状况。在后一种情况中，通过改变系统的运行状况，他们可以寻求执行对其有利的事务，或者他们只是为了用某种有意思的方式导致您的系统崩溃，以造成对您的组织的损害。
如您所见，有很多不同类型的入侵者、很多不同的动机，以及我们后面将讨论的，许多不同类型的攻击。当您规划您的安全性时，必须注意这些。
我们还希望强调的是，安全性不应该仅仅被视为阻挡“外人”的门户。那是一个过于简单化的观点。当今的许多组织将他们的安全性完全集中在针对组织外部的人群，他们有一个错误的观念，即认为只有外部人群才是危险的。这不是实际的情况。组织内部的人也很有可能攻击您的系统。一些最近的研究表明，可能有将近一半的入侵是由（或涉及）组织内部的雇员或者合同工造成的。您的安全性应该努力保护您的系统不被所有的潜在入侵者攻击。这就是本文为什么如此之长的原因。安全性不仅仅是在网络边缘保护您的系统不受外部攻击的防火墙。它是一套困难且复杂的操作和规程，致力于尽可能的加固您的系统。
限制和现实状况
应该认识到没有完美的安全系统，这一点很重要。您的目标是在业务约束下尽可能的保护系统。在考虑安全性时，理论上应该：
- 分析攻击的多个方面。
- 考虑每种攻击的危害。
- 确定由成功的攻击而导致安全性被破坏的可能性。
- 评估为防止每种攻击而付出的代价。
在估计安全性被破坏而造成的危害时，不要忘记安全性的破坏会导致系统使用者对您的系统丧失信心。因此，“安全性被破坏的代价”可能包括非常高的间接代价（比如，投资者信任的丧失）。
一旦您已经完成了以上列出的步骤，就可以对风险对抗的代价做出适当的权衡。从本质上说，这个目标就是要让入侵者为侵入您的系统而付出的代价超过他们可以获得的利益，同时确保业务能够承受运行安全系统所付出的代价。（当某些黑客侵入您的系统的目的只是为了取乐时，这就将是一个问题。您能够期望的是通过创建合理的安全环境，入侵者将转而攻击其他更容易的目标。）归根结底，需要什么安全级别是一个业务决策，而不是技术上的问题。然而，作为技术人员，我们必须帮助所有的团体理解安全性的价值和重要性。
安全性是一个很大的课题，不可能在本文中完全包含安全性的所有方面。本文不打算作为安全性的介绍或者关于如何保护基于 WebSphere Application Server 的系统的教程。而是打算作为一个高级别的概述或涉及 WebSphere Application Server 时需要考虑的核心技术问题的检查表。本文的信息应该用于创建安全企业这些更大型的工作。
希望了解更多相关信息的读者请查阅
参考资料部分。
企业应用程序安全性详细提供了企业安全性基础的高级别概述。
社交工程
由于这是一篇技术性的文章，因此我们重点讨论保护系统的技术解决方案。实际上，我们主要集中于安全性难题的 WebSphere Application Server 部分。尽管如此，您应该意识到使用社交工程技术而达到危害系统的目的往往更加简单。这就是说，通过欺骗在您的组织中工作的人员，攻击者可以获得权限以访问他们本不可以访问的系统和信息。（请参阅
什么是社交工程？以获取更多信息。）
也许对本文所讨论的关于社交工程攻击技术的一个结论就是，通过使用社交工程，攻击者可以来自于您的网络内部。这再次强调了早前提到的仅仅防御来自网络外部的攻击者是一个愚蠢的错误。这就是为什么本文的讨论要集中于多级别安全性的原因。每个级别防范不同的攻击，并提供对攻击者的更有效的屏障。
WebSphere Application Server 安全性体系结构
我们假设读者熟悉 J2EE 安全性和安全性基础。如果您不熟悉，请查阅 J2EE 规范以获取关于 J2EE 应用程序中如何指定安全性的详细信息（以及
企业应用程序安全性）。在这里，我们关注 WebSphere Application Server 如何实现安全性。我们将不深入研究低级别的详细情况，这是因为它们通常不必关心，但是却对从高级别理解 WebSphere Application Server 安全性基础架构如何工作很有帮助。这将有助于定义安全性基础架构和故障诊断。
与所有的安全系统一样，WebSphere Application Server 提供身份验证、授权和数据保护功能。WebSphere Application Server 提供三种形式的身份验证：
- 用户名/密码
- 客户端证书
- 身份断言（identity assertion）
WebSphere Application Server 实现了所需的 J2EE 身份验证方法，也提供可作为外部身份验证引擎用于 Tivoli Access Manager 的插件。在大多数情况下，WebSphere Application Server 在通过网络连接传递信息时使用 SSL 来进行数据保护。现在我们将非常详细的讨论每种形式的身份验证。
身份验证
有两类身份验证需要考虑：
我们将不讨论 Web 服务身份验证。除了简单提及 JAAS 客户端身份验证 API（用于 EJB 客户端），我们也不讨论 JAAS。这是因为尽管 WebSphere Application Server V5 部分支持 JAAS 和自定义登录模块，但 JAAS 仅能够对 WebSphere Application Server 身份验证流程提供补充。由于 JAAS 自定义登录模块不能改变或取代现有的 WebSphere Application Server 身份验证令牌（token），因此 JAAS 登录模块可以将自定义属性添加到 Subject，但是仍然需要执行 WebSphere Application Server 登录模块以完成适当的身份验证。图 1 说明了 WebSphere Application Server 身份验证基础架构的基本体系结构。
图 1. WebSphere Application Server 身份验证体系结构
 |
关于版本的提示
本部分的信息适用于 WebSphere Application Server V5.0.x 和 WebSphere Application Server V5.1.0 的早期版本。WebSphere Application Server V5.1.1 将包含一些强大的新功能以支持围绕 JAAS 而创建的更复杂的身份验证。这将支持在应用程序服务器和增强插件间传递自定义 Subject 属性。随着该模型的发展，TAI 和 JAAS 登录模块将有可能为 WebSphere Application Server 提供其所需的信息，以创建 WebSphere Application Server 凭证。这将允许使用现有的安全性系统进行更加灵活的集成。
|
|
Web 身份验证
对 Web 客户端最常用的验证方法是通过提供一个用户名和密码（比如 HTTP Basic Auth 或 Form-based）。WebSphere Application Server 获取这些信息，在注册表中查找用户的唯一 ID（例如，用于 LDAP 的 DN），然后利用注册表来验证密码。在 LDAP 情况下，执行一个
ldap_bind 。
Web 客户端也可以使用客户端证书进行验证。像所有的 SSL 系统一样，客户端证书验证都在 SSL 连接终止的时候进行。因此，由 Web 服务负责执行客户端证书验证，而不是由 WebSphere Application Server 负责。一旦完成了证书验证，WebSphere Application Server Web 服务器插件便将客户端证书信息传送给 WebSphere 应用程序服务器，然后应用程序服务器从证书中提取信息并在注册表中查找该用户。用于查找的信息是可定制的，并且如果开发了自定义注册，这些信息可以完全定制。
Trust Association Interceptors
Web 客户端也可以通过信任关联拦截器（Trust Association Interceptor，TAI）来进行验证。从实质上说，通过使用 TAI，WebSphere Application Server 允许外部组件来验证用户，然后将身份（身份断言）断言到 WebSphere Application Server Web 容器。您可以自定义开发 TAI 或者使用已经可用于商业的几个 TAI 其一。这些 TAI 通常在与 Web 身份验证服务器相连接的设备中使用，比如 IBM 的 Tivoli Access Manager 或者 Netegrity® 的 SiteMinder®。这些产品对用户进行身份验证，然后简单通知 WebSphere Application Server 终端用户的身份。这一般通过代理服务器将用户 ID 和一些附加验证信息发送到应用程序服务器来完成。TAI 提取这些信息，然后将用户 ID 返回到 WebSphere Application Server。然后 WebSphere Application Server 通常查询注册表但不验证用户的密码。（如果用户名没有在注册表中查找到，当然身份验证会失败。）这提供了一个强有力的机制以允许 WebSphere Application Server 参与到单点登录（Single Sign On）域中。
无论如何，当 Web 身份验证完成后（在 TAI 或普通 Web 身份验证情况下），WebSphere Application Server 将创建一个包含用户身份验证信息的 JAAS Subject 和一个 LTPA 令牌。对于 Web 客户端，WebSphere Application Server 同样创建一个 LTPA cookie 用于发送到浏览器。该 cookie 本质上是 LTPA 令牌的字符串表示法。
EJB 客户端身份验证
EJB 客户端可以使用密码或证书来进行验证。在基于密码的身份验证情况下，客户端运行时负责获取用户名和密码，并将它们发送到服务器，在该服务器中将针对注册表对用户名和密码进行验证。无论如何，如果身份验证确定为有效，将会确定一个包含 LTPA 令牌的 CSIv2 session 以用于将来的请求。与 Web 客户端身份验证一样，也会创建一个 JAAS Subject。
如果需要用户名和密码时，WebSphere Application Server 客户端运行时缺省使用一个图形化对话框来提示输入用户名和密码。该行为可以通过编辑 sas.client.props 来进行控制。您甚至可以在该文件中指定一个用户名和密码。然而，客户端最好是使用 JAAS Login API，这样当获取用户名和密码之后，可以在应用程序控制下通过某种适当的方式来进行验证。
内部身份验证
应用程序代码以及 WebSphere Application Server 自身也可以从流程内部进行验证，实质上是随时创建一个已验证的 Subject。为此，需要使用标准 JAAS login API。在完成以后，相同的方法可以在其他的场景中使用。所提供的用户名和密码通过注册表来进行验证，如果验证成功，将会创建 JAAS Subject 和 LTPA 令牌。虽然不是那么显然易见，但这意味着当 WebSphere Application Server 服务器验证其自身时，它们使用相同的注册表进行用户级别的身份验证。
|
JAAS Subject.doAs() 方法的提示
当使用 JAAS LoginContext.login() 方法创建 JAAS Subject 时，Subject 与当前的执行线程并无关联。为了让 WebSphere Application Server 进行身份验证，应用程序代码必须明确的使用 WSSubject.doAs() 方法将 Subject 与当前线程相关联（因为 JVM 的标准 Subject.doAs() 方法不能将 WebSphere Application Server 的基于 CORBA 的凭证与当前线程相关联）。要获取详细信息，请查阅
WebSphere Application Server 信息中心。
|
|
JAAS Subject 和 LTPA 令牌
一旦身份验证流程完成，WebSphere Application Server 将创建一个 JAAS Subject 以表示当前已确认的用户。该 Subject 包含 WebSphere Application Server 运行时所需的 WebSphere Application Server 凭证以对用户访问授权。正如您所期望的，Subject 包含的信息来自于注册表。Subject 通过每个应用程序服务器在存储表中缓存。
除了 JAAS Subject，WebSphere Application Server 还在 Subject 表中创建一个 LTPA 令牌，它实质上是一个密钥。出于安全性原因，LTPA 令牌的生命期有限，并被数字签名且加密。一旦令牌生命期结束，用户必须重新验证。令牌自身仅包含用户的唯一标识符和一个时间戳（TimeStamp）。因此，令牌本身包含的有价值信息很少。整个方法提供了高度的安全性。
由于 LTPA 令牌唯一标识一个用户，所以如果一个 LTPA 令牌被发送（通过 Web 请求或 IIOP 请求）到应用程序服务器且该服务器没有用户 Subject 的缓存副本，那么目标 WebSphere 应用程序服务器就可以通过查询注册表来重新创建该 Subject。一旦该项工作完成，这个 Subject 将被保存到缓存中，以确保将来请求的高性能。该方法确保了单点登录到 Web 层和 EJB 层。
|
SWAM
您可能已经注意到我们还没有提到 SWAM。这并不意外，除 LTPA 之外，SWAM 是另一个身份验证机制。SWAM 在许多级别上次于 LTPA。首先，由于它依赖于 HTTP Session 来维护状态，因此相比于 LTPA 而言更低效。其次，SWAM 身份验证不可用于远程 EJB，因此在多节点 WebSphere Application Server Network Deployment (ND) 环境中，SWAM 的用处非常有限。实际上，SWAM 甚至不可以用于 WebSphere Application Server ND。最后，由于 WebSphere Application Server 的所有版本都支持 LTPA，因此没有理由使用 SWAM。
|
|
注册表
我们已经多次提到过注册表。WebSphere Application Server 支持三种类型的注册表：
当使用操作系统注册表时，WebSphere Application Server 使用自带的操作系统命令来针对本地计算机验证用户信息。一般说来，操作系统注册表不能用于多节点 WebSphere Application Server ND 环境，这是因为每台计算机都有自己的注册表。（通过 Windows® 主机和通用域注册表，当使用操作系统注册表时，单个 WebSphere Application Server 单元可以跨越多个主机。）
LDAP 注册表是到目前为止的最佳方法，它完全支持多节点 WebSphere Application Server ND 环境。当 WebSphere Application Server 被配置为使用 LDAP 时，它使用标准 LDAP V3 协议来与 LDAP 目录通信并验证用户信息。
WebSphere Application Server 还支持自定义注册表。当您不能使用任何支持的注册表时，您可以通过实现 UserRegistry 接口（用 Java™ 语言）来任意编写您自己的注册表。
无论怎样，当 WebSphere Application Server 使用注册表时，下列操作将作为身份验证流程的一部分而被执行。理解这些操作在执行时通常不顾及其他的考虑：
-
获取完整的用户唯一标识符
对保密信息的跟踪是基于这个内部注册标识符，而不是人们通常提供的短用户名。
-
验证密码
如果使用密码身份验证，就需要使用这一流程。
-
获取用户组信息
这作为授权的一部分在以后使用。（在 WebSphere Application Server V5.1.1 中，将发布一个被称为 TAI++ 的新接口，该接口通过使用 TAI 将可能避免这一步。TAI 基本上可以为 WebSphere Application Server 断言组信息。）
需要认识到单个 WebSphere Application Server 单元只可以有一个注册表。这意味着包括 WebSphere Application Server 管理员和安全性服务 ID 在内的所有用户都必须在该注册表中。这也意味着那些用户的所有组信息也必须在同一个注册表中。如果您需要将用户放到几个注册表中的一个时（可能您有多个 LDAP 服务器），您将必须编写自定义注册表。
授权
为了与规范保持一致，WebSphere Application Server 实现了 J2EE 所需的授权模型。J2EE 应用程序能够使用这个标准的 J2EE API 以及部署描述符来指定授权信息。
也可以将 WebSphere Application Server 授权交给 Tivoli Access Manager 和一些其他授权提供商来处理，但是我们在这里没有包含这些说明。
|
Java 容器授权约定（JACC）- JSR 115
将来，WebSphere Application Server 将支持新的 Java 标准，将授权由容器转到外部授权引擎。
|
|
安全性配置的高层次考虑
我们假设读者熟悉 WebSphere Application Server 安全性配置基础。如果您并不熟悉，请查阅 WebSphere 安全性手册或者 WebSphere Application Server 信息中心（请参阅
参考资料）。在这里，我们将讨论一些关于配置 WebSphere Application Server 安全性的更高级并且可能更模糊的方面。
SSL、密钥库和 iKeyman
SSL 是 WebSphere Application Server 安全性体系结构的一个关键组件，它被广泛用于安全通信。SSL 用来保护 HTTP 传输、IIOP 传输、LDAP 传输和内部 SOAP 传输。SSL 需要使用公共/私有密钥对（key pair），并且在 WebSphere Application Server 情况下，这些密钥被保存在密钥库（keystore）中。为了更好的理解如何适当的配置 SSL，我们准备暂时岔开，进行关于 SSL 和公共密钥的高级别讨论。该讨论尽量不深入探讨，只讨论您需要用来在 WebSphere Application Server 中适当的配置 SSL 的关键点。
公钥密码术（Public Key Cryptography）从根本上说是基于公共/私有密钥对。这些密钥对是相关联的密码。关键的问题是这些密钥是非对称的 -- 使用一个密钥加密的信息可以使用另一个密钥来解密。私有密钥是私有的，这就是说，当您发布一个“证书”，证书有时包含私有密钥作为证书创建流程的一部分时，您必须谨慎保护那些私有密钥。如果您在请求 CA 对公共密钥签名之前创建您自己的公共/私有密钥对，因而创建一个证书，那么您仍然必须保护那些私有密钥。持有私有密钥是身份的证明。公共密钥是密钥对的一部分，它可以与其他人共享。
如果有一种安全的方法可以将公共密钥发布给受信任的人群，这就足够了。然而，公钥密码术更进了一步，并且引入了签名公共密钥的概念。签名公共密钥有数字签名（非常类似于手工签名）来表明签署者对公共密钥的担保。签署者确信持有与签名公共密钥相应的私有密钥的人群是通过密钥识别的人群。这些签名公共密钥被称为证书。众所周知，签署者被称为证书授权方。也可以使用公共密钥签署其自身。这些被称为自签署（self-signed）证书。自签署证书的安全性不亚于通过证书授权方签署的证书，它们只是乍看起来不易于管理。图 2 说明了创建证书和发布证书的基本流程。
图 2. 服务器证书的创建和发布
在查看图 2 时，请注意客户端必须持有证书，该证书签署了所生成的公共密钥。这是信任的关键部分。由于客户端信任 CA（因为它有 CA 证书），因此它信任由 CA 签署的证书。如果您使用自签署的证书，将没有什么价值，您将需要将这些自签署证书手工发布到每个客户端，而不是依靠众所周知的公共 CA 证书。这并非不安全，但是如果您有许多客户端，就会变得更加难于管理。
为了让客户端使用证书来验证服务器，服务器必须持有自己的私有密钥和相应的证书。客户端必须持有与服务器证书对应的签名证书。另一方面，为了让服务器验证客户端（通常称为客户端证书验证），将以上的条件颠倒过来就可以。就是说，客户端必须持有自己的私有密钥和相应的证书，同时服务器必须持有与客户端证书对应的签名证书。这就是全部的实际条件。由于 SSL 使用证书验证，因此 SSL 连接的每个端都必须持有密钥库中合适的密钥。当您配置 SSL 密钥库时，需要考虑一些基本规则，以确定哪个人群需要哪些密钥。通常，那些基本规则将告诉您所需要的。
正如我们已经看到的，WebSphere Application Server 在密钥库文件中管理密钥。有两种类型的密钥库：
- 密钥库（keystore）
- 信任库（truststore）
信任库只不过是密钥库通过约定仅包含公共信息。因此，您应该将 CA 证书和其他签名证书放入信任库，并把私有信息放入密钥库。然而，它对 WebSphere Application Server 没有什么真正的影响。
不幸的是，这个简单的系统有一个问题。大多数 WebSphere Application Server 使用新的 Java 定义的密钥库格式，该格式被称为 Java Key Stores（JKS）。（WebSphere Application Server SSL 配置支持三种现行的密钥数据库格式：JKS、JCEKS 和 PKCS12。）IBM HTTP Server 和 WebSphere Application Server Web 服务器插件使用一种更老的密钥格式，改格式被称为 KDB 格式（或者更准确的称作 CMS 格式）。这两种格式在功能上相似，但是在格式上不兼容。因此您必须注意不要将它们混合使用。
IBM 提供一个名为 iKeyman 的工具，它用于管理密钥库。这是一个非常简单的工具，可用于创建密钥库、生成自签署证书、导入和导出密钥，并能够为 CA 生成证书请求。当您管理密钥库时，应该使用这个工具。从 WebSphere Application Server V5.1 起，iKeyman 的一个单独版本支持所有需要的密钥库格式。如果你还在使用 WebSphere Application Server 的早期版本，包含在 WebSphere Application Server 的
bin 目录中的 iKeyman 不支持 KDB 格式。要想创建 KDB 文件，您必须运行更老的 iKeyman，当您安装 WebSphere Application Server 时附带安装的 GSK5 目录下应该有这个 iKeyman。（在 Windows 系统中，GSK 通常在
c:\program files\ibm\gsk5 目录下。在 Solaris 系统中，通常在
/opt/ibm/gsk5 目录下。其他的平台与此类似。）
基于 Web 的管理接口和证书验证
当安全性被启用，并且您使用 Web 管理控制台连接到 WebSphere Application Server 时，您的 Web 浏览器将很可能警告您证书不可靠，且主机名与证书中的主机名不匹配。您可以看到如图 3 和 4 所示的消息（使用 Mozilla Web 浏览器显示）。
图 3. Mozilla 通知用户证书不可靠
图 4. Mozilla 通知用户证书指定的主机名与期望的不符
这些消息是指出了可能的安全问题的警告，这与 WebSphere Application Server 所使用的证书相关。当您更新缺省的 keyring 时（请参阅
巩固安全性），您可以设法防止这些警告。首先，生成一个证书，该证书的 Subject 名称与运行管理 Web 应用程序（WebSphere Application Server Base 的一个服务程序，或者其他版本的部署管理程序）的主机名相同。它将维护第二个浏览器错误消息。第一个消息可以通过从 CA 购买 WebSphere Application Server 管理控制台（这可能比较费钱）或者简单的通过永久接受证书来避免。请记住如果您再次见到这个消息，那就很可能标志着安全性被破坏。因此，您的系统管理人员应该认识到该警告只应该在证书更新时出现。如果它出现在其他时候，这就是系统受到侵害的危险警报。
高级 LDAP 考虑事项
在配置 WebSphere Application Server 以使用 LDAP 的时候，需要考虑许多问题。首要问题是需要认识到 WebSphere Application Server 完全支持“标准”LDAP 访问。这意味着一般说来，WebSphere Application Server 可以被配置为与任何 LDAP 服务器以及任何遵循通用 LDAP 技术的合理配置共同工作。WebSphere Application Server 对 LDAP 的使用非常有限，正如早前提到的，即使是这些有限的使用也非常灵活。通过使用 LDAP 配置页面和 LDAP 高级设置页面，您能够控制大量的 WebSphere Application Server 行为。图 5 展示了 LDAP 配置主页面。
图 5. LDAP 配置主页面
以下是将 LDAP 与 WebSphere Application Server 相关联的一些值得注意的配置项：
-
Host:当 WebSphere Application Server 连接到 LDAP 时，将使用这个单独的主机名。如果到 LDAP 的连接失败，WebSphere Application Server 将重新连接相同的主机。这意味着 WebSphere Application Server 不支持重复的 LDAP 目录，除非这种重复非常明确，可能使用了负载均衡器，比如 Network Dispatcher。
-
Base Distinguished Name:这是 LDAP 查找树的起点，通常类似于 "ou=software, o=ibm."。WebSphere Application Server 将在这个根节点下通过查找来发现用户和组。WebSphere Application Server 不支持完全独立的树或 LDAP 服务器中的用户和组。
-
SSL Enabled:通过指定该选项和包含 LDAP 目录证书签名密钥的 SSL 配置，WebSphere Application Server 将在联系 LDAP 时使用 SSL。由于 WebSphere Application Server 将密码发送到 LDAP 以执行
ldap_bind ，因此使用 SSL 非常重要。
在您配置完基本设置（包括指定 LDAP 目录类型）之后，就已经完成了工作。然而，如果您的 LDAP 目录没有通过 IBM 测试，或者如果用某种比较特殊的方法配置了目录，那么您能够控制 WebSphere Application Server 如何查询您的目录。为此，单击
Advanced LDAP Settings链接。图 6 展示了您将看到的。
图 6. 高级 LDAP 设置
在图 6 中，您看到的是查询 LDAP 时 WebSphere Application Server 所使用的过滤器。这些过滤器使您可以灵活的控制 WebSphere Application Server 的查询。我们将花一些时间来讨论那些设置：
-
User Filter:当用户类型是 userid 且 WebSphere Application Server 试图在 LDAP 中查找用户纪录时，将使用第一个过滤器。您将注意到在本范例中，用户通过
uid 字段来识别并且类型为
ePerson 。您可以修改其中任一个以满足您的需求。在一些注册表中，您可以将
uid 修改为
samAccountName 或
cn 。
-
Group Filter:该过滤器与 User Filter 非常类似。
-
User Id Map:该设置标志着当 WebSphere Application Server 查找关于用户的 LDAP 条目时，唯一标识用户的字段是
uid 字段。同样，您可以按你的需要对此进行修改。
-
Group Id Map:该设置与 User Id Map 非常类似。
-
Group Member Id Map:该设置指定 WebSphere Application Server 将如何确定组成员。这是一个用分号相隔的对列表，它解释了 attribute:member 或 objectclass:attribute 对。WebSphere Application Server 能够通过两种方法查找组成员：查找组本身以确定用户的 DN 是否在组的特定属性中列出，或者在包含用户成员信息的用户对象上查找特定的属性（这种方法更高效）。如果对象类的值与组过滤器中指定的对象类的值相同，则 WebSphere Application Server 考虑使用 Id Map 进行第一种查找。否则，就假定为后一种。本范例演示了后一种情况，成员左边指定的属性明显不是组对象类。因此，假设指定的属性在 LDAP 中用户条目对象上，并且保存用户的组成员关系。用这种方法，WebSphere Application Server 通过检查单个的属性从 LDAP 目录中获取用户组成员信息。该目录能够用任何看似合适的方式创建和管理这个属性。在图中，值 ibm-allGroups:member 的意思是当试图为用户确定组成员关系时，在用户条目中查找 ibm-allGroups 属性。
-
Certificate Map Mode:如果用户使用证书进行验证，该设置会告诉 WebSphere Application Server 如何将证书中的信息与 LDAP 相匹配，以找到相应的用户。缺省的方法也是最安全的方法是对证书中的 DN 使用严格的匹配。如果这种方法不可能实现，您可以通过在证书过滤器字段指定自定义属性来进行匹配。（请参阅
WebSphere Application Server 信息中心以获取更多信息。）
不可以选择如何控制 WebSphere Application Server 验证密码。那是因为 WebSphere Application Server 并不从 LDAP 中查询密码。相反，它使用一种 LDAP 定义的标准方法，称为
ldap_bind 。如果您某种没有密码的非常不规范的方法来配置了您的 LDAP 目录，这显然将不能正常工作。请牢记 WebSphere Application Server 不能也无需控制用户密码在 LDAP 目录中是如何保存或管理的。那些完全受 LDAP 管理员的控制。（要获取更多关于 LDAP 的信息，请在
参考资料中参阅理解和部署 LDAP 目录服务。）
现在我们已经讨论了 WebSphere Application Server 安全性基础，下面我们把讨论转移到安全性的真正目的：创建安全的环境。
巩固安全性
J2EE 1.3 规范和 WebSphere Application Server 提供了一种用于实现安全系统的强大的基础架构。不幸的是，许多人没有意识到围绕创建基于 WebSphere Application Server 的安全系统的各种问题。该信息有许多不同的自由度和许多不同的资源。这有助于指导人们居高临下的发现 WebSphere Application Server 安全性问题以及指导部署不是非常安全的系统。本部分将试图总结最为重要的关键问题。
安全性巩固关系到用某种方法配置 WebSphere Application Server、部署应用程序和配置各种其他相关组件，以使安全性最大化。从本质上说，就是防止或阻挡各种形式的攻击。为有效的完成这项工作，了解攻击的形式是非常重要的。
有四种基本方法用于攻击基于 J2EE 的系统：
-
基于网络的攻击
这些攻击依赖于对网络数据包的低级别访问，它失误通过改变传输或者从数据包中发现信息来达到危害系统的目的。
-
基于计算机的攻击
在这种情况中，入侵者已经可以访问运行 WebSphere Application Server 的计算机。这里，我们目标是限制对 WebSphere Application Server 配置进行损害的能力，或者限制入侵者看到不应该看到的内容。
-
基于应用程序的外部攻击
在这个场景中，入侵者使用应用程序级的协议来访问应用程序，也许是通过 Web 浏览器或 EJB 客户端，并使用该访问试图超出正常的应用程序用途来做不适当的事情。关键是使用 J2EE 定义的 API 和协议进行攻击。入侵者不一定是来自于公司外部，更恰当的说，应该是从应用程序自身的外部执行代码。
-
基于应用程序的内部攻击
这种情况涉及到欺诈程序的危害。在该场景中，多个应用程序共享相同的 WebSphere Application Server 基础架构，我们不能完全信任每一个应用程序。虽然完美的安全性是不可能达到的，但是有一些技术可以限制每个应用程序能够做出的危害。
我们没有考虑一种其他形式的技术攻击：拒绝服务（Denial of Service，DoS）攻击。尽管这很重要，但是它超出了本文的范围。防止 DoS 攻击需要完全不同的技术。
Total System View: the details matter
在一点一点的研究详细建议之前，我们打算花一些时间来概括创建安全系统的基础技术。基础的观点是着眼于每个系统边界或共享点，并检查哪些参与者访问这些边界或共享的组件。更确切的说，就是给出这些现有的边界（我们假设子系统比较可靠），入侵者如何侵入这些边界？或者，给出共享的内容，入侵者是否可以不合理的共享某些内容？大多数边界是清晰可见且实际存在的：网络连接、流程到流程通信、文件系统、操作系统接口等等，但是有些边界就更加微妙。例如，如果一个应用程序在 WebSphere Application Server 中使用 J2C 资源，您必须考虑某些其他应用程序试图访问那些相同资源的可能性。这是因为第一个应用程序和 WebSphere Application Server 之间，以及第二个应用程序和 WebSphere Application Server 之间都存在系统边界。可能两个应用程序都能够访问这个通用基础架构（实际上确实是可以的）。这是不合理共享的一种可能情况。
我们防止这些多种形式攻击的方法是应用许多众所周知的技术。对于较低级别的基于网络的攻击，我们应用加密和网络过滤。我们基本不认为入侵者具备能够看到或访问他们不该看到的内容的能力。我们还依赖操作系统提供的机制来保护操作系统的资源不被滥用。例如，我们不希望普通用户级别的代码能够获取对系统总线的访问权，也不希望这些代码能够直接读取内部通信。我们还利用了大多数当今的操作系统具有对系统 API 的可靠保护这一现状。（在 WebSphere Application Server 环境中，这些操作系统保护的价值比较有限，这是由于它们基于流程识别，当考虑来自大量用户同时发出的应用程序服务器服务请求时，这是一个非常粗粒度的概念。）在高级别上，我们应用身份验证和严格授权。每个 API、每个方法、每个潜在资源都需要某种形式的授权。那就是说，对这些的访问必须严格基于需求。当然，如果没有可靠的身份验证，授权也就失去了价值。身份验证是关于分辨调用者的身份。我们加了可靠一词，这是因为如果身份验证可以很容易的伪造，那也就失去了意义。
如果适当的身份验证和授权不可用，那么我们只能采取巧妙的设计和规程以防止潜在的问题。这就是我们如何保护 J2C 资源的方法。由于 WebSphere Application Server 没有提供对访问 J2C 资源的授权，我们改为应用其他技术来削弱（基于配置）应用程序不合理访问 J2C 资源的能力。
可以想象，检查所有的系统边界和共享组件是一个困难的任务，并且实际上保护系统被认为是很复杂的。可能关于安全性的最确切的原理就是创建一个安全系统进行抽象的工作。那就是说，良好抽象的核心原理之一就是隐藏高级组件，这些高级组件是人们非常需要的。不幸的是，入侵者对我们没有那么友善。他们并不在乎我们的抽象或者我们的好设计。他们的目标是想方设法的侵入我们的系统，并且为此，他们将在我们极好的设计中寻找漏洞。因此，为了验证系统的安全性，您必须考虑抽象的每个级别：从最高的体系结构级别到最低的详细级别。需要对所有的内容进行严格的审查。
最小的错误都可能破坏整个系统的完整性。通过使用缓冲区溢出技术来控制基于 C/C++ 的系统的例子非常好的证明了这一点。从实质上说，入侵者传递进来一个大于现有缓冲区的字符串，然后附加信息覆盖运行中的程序的一部分，并导致运行时执行本不该被执行的指令。小心，这能够导致程序做几乎任何事情。作为安全性架构师，对这种攻击的识别需要深入理解 C/C++ 运行时如何管理内存以及如何执行程序。（要想获取详细信息，请参阅
缓冲区溢出 -- 什么是缓冲区溢出以及如何处理？）假设您了解缓冲区溢出问题的存在，您将不得不检查每一行代码以发现这个特殊的漏洞。目前，我们已经了解这种攻击，但是它仍然能够攻击成功，这是由于个别程序员做出了非常小的错误决策，导致危及整个系统的安全。幸运的是，这种特别的攻击在 Java 中不可行。然而，不要马上就认为其他的小错误不会导致系统受损。仔细思考安全性，这是一个不简单的工作。
加固方法
现在我们将确定各种已知的步骤，用以保护 WebSphere Application Server 基础架构和应用程序不受这四种形式的攻击。理论上，我们将把这些信息组织为四块，每块对应于一种形式的攻击。不幸的是，攻击并不完全按照那些界线来进行划分。有几种不同的保护技术有助于防御多种形式的攻击，并且有时一个单独的攻击可能利用多种形式的侵入以达到最终目标。例如，在最简单的情形中，网络嗅探（sniffing）能够用于获取密码，然后那些密码可以用于进行应用程序级的攻击。因此，我们将基于活动何时发生或者与这些问题相关人员的角色，来将这些加固技术按照逻辑结构来进行组织：
-
基础架构
为将 WebSphere Application Server 基础架构配置为最大化安全性而采取一些操作。当基础架构在外部构建并只涉及系统管理员时，通常采用这些操作。
-
应用程序配置
应用程序开发人员和管理员所采用的操作，这些操作在部署流程中是可见的。从实质上说，这是一些应用程序设计和实现决策，它们对 WebSphere Application Server 管理员可见并可作为部署流程的一部分进行检验（可能有一些难度）。本部分将有大量的技术，以进一步加强安全性的不足之处。安全性是每个应用程序设计、开发和部署人员的责任。
-
应用程序设计和实现
开发人员和设计人员在部署期间所采取的对安全性至关紧要的操作，但是这些操作难以作为部署流程的一部分而进行检验。
在每个部分中，我们按优先级顺序排列各种技术。为帮助您将这些技术与刚才提到的攻击类别相联系，我们将为每种技术使用下列图解：
这四块被涂上适当的底纹，以代表一种技术有助于防御的攻击类型（
N是基于网络的攻击，
M是基于计算机的攻击，
E是基于外部应用程序的攻击，
I是基于内部应用程序的攻击）。请牢记内部应用程序可以始终利用攻击的“外部”方法。因此，当“E”已经表示时，我们不明确的列出“I”。但是当弱点只被内部应用程序利用时，我们会列出“I”。
基于基础架构的预防性衡量
当保护基础架构时，我们首先集中于在多个组件之间对 WebSphere Application Server 通信进行加密，以及确保 WebSphere Application Server 的管理功能是安全的。在进行详细的分析之前，这有助于审查标准的 WebSphere Application Server 布局和查看网络的所有连接和协议。作为关注安全性的人员，您需要了解所有这些连接并专注于保护这些连接。我们在前面提到过，这些连接代表了粗粒度的系统边界。请参看图 7。
图 7. 网络连接图
在图 7 中，连接上的字母表示所使用的跨越那些通信连接的协议。对于每个协议，我们列出了它的用途，还提供了一些关于防火墙的信息：
-
H = HTTP 通信
- 用途：浏览器到 Web 服务、Web 服务到应用程序服务器，以及管理 Web 客户端
- 防火墙友好
-
W = WebSphere Application Server 内部通信
- 用途：管理客户端、WebSphere Application Server 内部服务器管理通信。WebSphere Application Server 内部通信使用下列几种协议之一：
- RMI/IIOP 或 SOAP/HTTP：可配置的管理客户端协议。
- File 传输服务（dmgr 到节点代理）：使用 HTTP(S)。
- DRS（内存到内存复制）：使用私有协议。
- 当使用 SOAP/HTTP 时防火墙友好
-
I = RMI/IIOP 通信
- 用途：EJB 客户端（独立的和 Web 容器的）
- 由于使用动态端口和嵌入式 IP 地址（执行网络地址转换会干扰防火墙），通常防火墙对其不友好。
-
M = MQ 协议
- 用途：MQ 客户端（实际客户端和应用程序服务器）
- 协议：专有
- 防火墙可用（有大量的端口需要考虑）。涉及 WebSphere MQ 支持 pac MA86。
-
L = LDAP 通信
- 用途：WebSphere Application Server 对注册表中用户信息的验证。
- 协议：按照 LDAP RFC 中定义的格式化 TCP 流
- 防火墙友好
-
J = 通过供应商 JDBC 驱动程序进行的 JDBC 数据库通信
- 用途：应用程序 JDBC 访问和 WebSphere Application Server session 数据库访问
- 协议：对每个数据库专有的网络协议。
- 防火墙方面取决于数据库（通常是数据库友好的）
-
S = SOAP
- 用途：SOAP 客户端
- 协议：通常是 SOAP/HTTP
- 当使用 SOAP/HTTP 时防火墙友好
在本部分的剩余部分中，我们将讨论保护基础架构所需的步骤。
1. 从浏览器使用 HTTPS
如果您的站点执行任何身份验证或者有任何应该保护的活动，需要从浏览器到 Web 服务器使用 HTTPS。如果没有使用 HTTPS，那么像密码、用户活动、WebSphere Application Server session ID 以及 LTPA 安全令牌之类的信息将可能被入侵者看到。（虽然这些令牌可以通过未加密的通道进行安全的传送，但是为了最大化安全性，最好对它们进行保护。
2. 不使用 WebSphere Application Server 将 Web 服务放到 DMZ 中
DMZ（demilitarized zone，非军事区）的一个关键原则是将尽可能少的功能放到 DMZ 中，以降低有关入侵者通过外部防火墙侵入的风险。（在典型的 DMZ 配置中，有一个外部防火墙，DMZ 网络包含尽可能少的内容，有一个内部防火墙保护产品网络）因此，一般将 Web 服务放置到 DMZ 中，并将 WebSphere 应用程序服务器放到内部防火墙内。这是比较理想的，因为这样 Web 服务器就可以包含最简单的配置，且只需要非常少的软件。此外，内部防火墙唯一必须开放的端口是用于目标应用程序服务器的 HTTP(S) 端口。这些步骤使 DMZ 对攻击者的防范非常严格。如果您将 WebSphere Application Server 放到 DMZ 内的计算机上，就必须在那些计算机上安装更多的软件（例如，JDK、X 库等等），并且为了让 WebSphere Application Server 能够访问产品网络，内部防火墙就必须开放更多的端口。这极大的破坏了 DMZ 的价值。
3. 从 intranet 分离您的产品网络
当今的大多数组织将 DMZ 的价值理解为将 Internet 上的外部人员与 intranet 分离。然而，太多的组织没有认识到许多入侵者来自内部。对于一个大公司来说，有数以千计的人员，他们中的许多人并非雇员，但是却有权限访问内部网络。所有人都可能成为入侵者，并且由于他们来自内部，他们将可以更充分的访问网络。将一台便携式电脑连入网络是再简单不过的事情。当您针对庞大而不可靠的 Internet 进行自我保护的同时，您也应该保护您的产品系统不受来自于庞大而不可信任的 intranet 的入侵。可以使用防火墙将您的产品网络与内部网络分离。这些防火墙看似比面向 Internet 的防火墙随意的多，但仍然能够防御多种形式的攻击。通过应用这些以及前面的步骤，您可以完成您的防火墙布局，如图 8 所示。
图 8. 推荐的防火墙配置
4. 启用全局安全性
WebSphere Application Server 在缺省状态下不使用安全性。这意味着所有的网络连接都不安全，并且任何有权访问部署管理器（用 HTTP 到 Web 管理控制台，或者用 SOAP/IIOP 到 JMX 管理端口）的用户都能够使用 WebSphere Application Server 管理工具来执行任何管理操作，以至于包括删除现有的服务器。毫无疑问，这带来了极大的安全风险。
因此，您至少应该在产品环境中启用 WebSphere Application Server 安全性以预防这些常见形式的攻击。一旦 WebSphere Application Server 被全局启用，则部署管理器与应用程序服务器之间的内部连接，以及从管理客户端（Web 和命令行）到部署管理器的通信都被加密并验证（参考图 7）。对于其他部分之间，这意味着在运行管理工具时，管理员需要经过验证。
需要认识到启用全局安全性不是对所有的网络连接加密，而是对大量的关键内部连接加密。我们以后将讨论保护其他的网络连接。我们还将讨论通过利用当前已经启用的 WebSphere Application Server 安全性来保护应用程序。
|
启用单点登录
当使用 LTPA 启用 WebSphere Application Server 全局安全性时，将始终启用单点登录（Single Sign-On，SSO）。这告诉 WebSphere Application Server 创建 LTPA cookie 并将它们发回到浏览器。这使 WebSphere Application Server 可以跨请求存储用户身份。如果您没有启用 SSO，WebSphere Application Server 将不创建 cookie 并且必须对用户的每一次请求都重新进行身份验证。在许多场合，这将无法实现。（对于没有 SSO 的基于表单的登录，每次登录都导致用户返回登录页面，这是因为登录后重新定向到页面不能成功。）更重要的是，这样的效率低下。由于每次请求都造成对用户重新进行身份验证，系统的性能将变得非常糟糕。
|
|
5. 修改缺省密钥文件
如前面所述，启用 WebSphere Application Server 安全性使得大多数内部通信都使用 SSL 来保护其不受各种形式网络攻击的危害。然而，为了建立 SSL 连接，服务器必须持有证书和相应的私有密钥。为简化初始安装流程，WebSphere Application Server 交付了一个包含私有密钥范例的示例密钥文件。每个版本的 WebSphere Application Server 产品都包括这个“私有”密钥，因此它也不是非常私有。密钥文件的名称 DummyServerKeyFile 表明了这一点。
要想保护您的环境，您应该为 WebSphere Application Server 通信创建自己的私有密钥和证书。所有这些都使用 iKeyman 工具来完成。请在
参考资料中查阅 IBM WebSphere 安全性手册和 WebSphere Application Server 信息中心，以获取关于如何进行此项工作的详细信息。
当我们讨论证书时，简单的转到一个关键要点：证书期满。如果 WebSphere Application Server 证书期满，WebSphere Application Server 将停止工作。任何通信都不可能进行。因此我们建议当您创建新证书时，确保您标记了终止日期。如果您使用缺省密钥（针对您的设备），请记住它们也会过期。您必须对证书期满做好准备，并在证书期满之前获取或生成新的证书。
如图 7 所示，典型的 WebSphere Application Server 配置有大量的网络连接。对连接之间的通信提供尽可能多的保护以防范入侵者，这是非常重要的。显然，很多保密信息通过应用程序进行传送，这些应用程序也应该受到保护。我们已经讨论了通过启用 WebSphere Application Server 安全性来保护许多连接，以及保护 Web 浏览器到 Web 服务的连接。现在我们将讨论其余的连接。
|
考虑修改缺省的 keyring
当修改缺省证书时，需要谨记一件重要的事情。与任何基于 SSL 的系统一样，客户端必须验证服务器提供的证书。这需要客户端为签署者（签署服务器提供的证书）保存签名证书。
当 WebSphere Application Server 捆绑时，所有的产品都为 WebSphere Application Server Java 客户端服务（IBM 提供的工具，比如管理控制台、资源解析器，以及自定义编写客户端）。然而，当您更新服务器密钥文件以使用新的私有密钥和由签署者签名的证书时，您必须确保 Java 客户端能够验证那些证书。您将需要更新客户端信任文件以包含签署者证书，它用于发布您的新服务器证书的人员。这意味着像 WebSphere Application Server 那样的任何 Java 客户端都需要新的客户端密钥文件。如果您使用著名的 CA 所发布的证书（比如 Verisign），那就没有必要，因为缺省的 WebSphere Application Server 客户端 keyring 已经包括了最通用的 CA 签名证书。（不推荐从 CA 购买证书来用于 WebSphere Application Server 内部通信。如果您只有很少的 Java 客户端，通常简单的生成自签署证书并手工更新少数客户端 keyring，这样比较方便和廉价。）
这个问题也影响 Web 服务器到应用程序服务器的通信。由于 Web 服务器插件缺省支持 HTTPS，所以 Web 服务器插件 keyring 包含了 WebSphere Application Server 范例签名证书的副本。如果您修改了缺省 keyring，请不要忘记更新 Web 服务器插件 keyring 以包含新的证书。
|
|
6. 使用 SSL 用于 Web 服务器到 WebSphere Application Server 的 HTTP 连接
WebSphere Application Server Web 服务器插件将请求从 Web 服务器传递到 WebSphere 应用程序服务器。对于 WebSphere Application Server V5.0，如果到 Web 服务器的通信是基于 HTTPS 的，那么当把请求传递到应用程序服务器时，插件将自动使用 HTTPS，从而保护通信的机密性。
更进一步，出于某些考虑，您可以将 WebSphere 应用程序服务器（包含小型嵌入式 HTTP 监听器）配置为只接受来自于已知 Web 服务器的请求。这防止了绕开 Web 服务器前或 Web 服务器内的任何安全措施而进行的暗中攻击。为此，您需要配置应用程序服务器 Web 容器 SSL 配置以使用客户端身份验证。一旦您已经确保了客户端身份验证已经投入使用，您需要限制人们对适当密钥的访问，以确保只有被信任的 Web 服务器才能够联系 Web 容器：
- 使用 iKeyman 创建两个 keyring，一个用于 Web 容器，另一个用于 Web 服务器插件。
- 从每个 keyring 中删除所有现有的签名证书。此时，两个 keyring 都不能用来验证任何证书。这是有意的。
- 在每个 keyring 中创建一个自签署证书，并只导出证书（而非私有密钥）。
- 将证书导入（从其他 keyring 导入）到每个 keyring。现在每个 keyring 仅包含一个单一的证书。这意味着每个 keyring 现在能够刚好验证一个证书，自签署证书被对等创建。
- 将新创建的 keyring 安装到 Web 容器和 Web 服务器插件。
7. 加密 WebSphere Application Server 到 LDAP 的连接
当 WebSphere Application Server 使用 LDAP 注册表时，WebSphere Application Server 使用标准的 ldap_bind 来验证用户的密码。这需要 WebSphere Application Server 将用户的密码发送到 LDAP 服务器。如果这个请求没有受到保护，黑客就可以使用网络嗅探来窃取用于 WebSphere Application Server 验证的用户密码。大部分 LDAP 目录支持 SSL 上的 LDAP，并且能够配置 WebSphere Application Server 以使用它。如果您使用自定义注册表，您将显然希望使用任何可用机制来保护该通信。
8. 保护 WebSphere Application Server 到数据库的连接
正如任何其他网络连接一样，加密信息可以从数据库写入或读出。尽管大部分数据库都支持一些形式的身份验证，但并不是所有的数据库都支持客户端（在本文中是 WebSphere Application Server 应用程序）和数据库之间的加密 JDBC 通信（请查阅您的数据库提供商的文档）。您必须认识到这个弱点并采取适当的步骤。一些形式的网络级加密，比如虚拟私有网络（Virtual Private Network，VPN），可能使用 IP 安全性协议（IP Security Protocol，IPSEC）。尽管还有其他的合理选择，但这是最显而易见的解决方案。如果您能够将数据库放置在 WebSphere Application Server 附近（从网络概念理解），各种形式的防火墙和简单的路由技巧能够极大的限制对前往数据库的网络通信的访问。这里的关键是确定该风险并适当的加以处理。
9. 加密分布式复制服务（Distributed Replication Service，DRS）网络连接
不要忘记开启 DRS 加密这一单独的手工步骤。即使启用了全局安全性，DRS 通信也没有被缺省加密。
10. 谨慎配置和使用信任关联拦截器（Trust Association Interceptor）
经常使用 TAI 来使 WebSphere Application Server 从 Web SSO 代理服务器（比如 Tivoli Access Manager，TAM）中识别出现有的身份验证信息。通常这是可行的。但是，在开发、选择和配置 TAI 时需要谨慎。TAI 扩展了 WebSphere Application Server 信任域。WebSphere Application Server 目前信任 TAI 并信任所有 TAI 信任的内容。如果 TAI 的开发或部署不合理，就可能会彻底损害 WebSphere Application Server 的安全。例如， IBM 提供了一个安全 TAI，用于将 TAM 和 WebSphere Application Server 集成。当适当配置时，这是一个高度安全的设置。然而，前面已经描述过，有一个名为 com.ibm.Websphere.security.WebSEAL.mutualSSL 的属性，该属性向 TAM TAI 表明从 Web 服务器到应用程序服务器的连接是否已经通过了安全验证。当正确使用时，一切正常。但是，如果您将该属性设置为 true 却不能确保 Web 服务到应用程序服务器的连接是安全的，那么您就使得 WebSphere Application Server 对一般形式的攻击毫无防范，这是因为 TAI 没有对连接进行验证。
如果您自定义开发了一个 TAI，请确保 TAI 仔细验证请求中传递的参数，并确保验证以安全的方式进行。我们曾经见到过 TAI 执行愚蠢的事情，比如在 HTTP 头中验证 IP 地址，这是毫无用处的，因为 HTTP 头可以伪造。
11. 创建单独的管理用户 ID
当 WebSphere Application Server 安全性配置完成，一个单独的安全性 ID 将被初始配置为安全性服务 ID。这个 ID 实际上等同于 WebSphere Application Server 中的根，它能够执行 WebSphere Application Server 的任何管理操作。由于这个 ID 非常重要，因此最好不要广泛共享它的密码。
与大多数系统一样，WebSphere Application Server 不允许多个负责人担当管理员的角色。可以简单的使用 WebSphere Application Server 管理应用程序并进入系统管理/控制台用户（或用户组）部分以指定其他应该被授予管理权限的用户（或用户组）。当您进行了授权以后，每个人在管理 WebSphere Application Server 时都能够对自己进行验证。（单元中的每个管理员都有相同的权限。WebSphere Application Server 不支持基于实例的管理授权。）对于 WebSphere Application Server V5.0.2 来说，会导致更改 WebSphere Application Server 配置的所有管理操作都需要经过部署管理程序的审查，包括做出修改的负责人的身份。显然，如果每个管理员都有独立的身份，那么这些审查纪录会更有用。审查纪录被视为重要信息，并从部署管理程序缺省发送到 SystemOut.log。
在中央管理员管理多个 WebSphere Application Server 单元的环境中，为每个单独的管理员赋予单独的管理权限会非常方便。虽然每个单元都有自己的本地“根”ID 和密码，但您可以配置所有这些 WebSphere Application Server 单元以共享通用注册表，这样管理员就能够使用相同的 ID 和密码来管理每个单元。
12. 利用管理角色
WebSphere Application Server V5 提供四种管理角色：
可以对这些角色赋予适合其需求级别的专用（或自动系统）访问权限。最有意思的角色是监控人员。通过为用户或系统赋予这种访问级别，可以使他们只具备监控系统状态的能力。不能修改状态，也不能更改配置。应该尽可能的利用这些角色。例如，如果您开发用于检查系统健康状况的监控脚本，并必须使用该脚本保存用户名和密码，可以使用监控员角色的 ID。这样即使 ID 泄密，所造成的损害也不会很严重。
13. 不要在产品中运行范例
WebSphere Application Server 捆绑了几个非常好的范例来演示 WebSphere Application Server 的不同部分。这些范例不适合在产品环境中使用。不要在那里运行范例，因为这些范例会造成很大的安全风险。特别是 showCfg 和 snoop Servlet 能够为外部人员提供大量关于您的系统的信息。这恰好是您不希望被潜在的入侵者获得的信息。通过不在产品中运行 server1（它包含了这些范例），就可以很容易的处理该问题。如果您使用的是 WebSphere Application Server Base，那么您应该从 server1 删除这些范例。
14. 启用 Java 2 安全性
到此为止，您已经很好的保护了 WebSphere Application Server 基础架构不受外部攻击的威胁。现在我们对网络通信进行了加密，以防止被监听和通信被改变。我们还对所有的管理通信进行了授权，这将防止外部入侵者破坏基础架构。然而，基础架构仍然很容易受到来自单元内部的应用程序的攻击。正如前面所讨论的，所有的 WebSphere Application Server V5 应用程序服务器都包含 WebSphere Application Server 管理基础架构，以及用于执行大部分管理操作的 API。因此，了解 API 的程序设计员能够编写应用程序来调用任何这些 API，并可能造成严重的问题。
WebSphere Application Server V5 包含对 Java 2 安全性的支持，Java 2 安全性由标准 JDK 提供。IBM 增强了对 Java 2 的支持以强化 J2EE 规范，并保护 WebSphere Application Server 内部 API 不会被未经授权访问。通过简单的启用 Java 2 安全性，这些规则将自动实施。随着 Java 2 安全性的启用，真正的附加保护被添加到运行时以防止非法的应用程序访问。我们将在稍候讨论 Java 2 安全性限制。
请注意 Java 2 安全性不是万能药。WebSphere Application Server 和我们所知道的任何 J2EE 应用程序都不是坚不可摧且隔离的安全系统。因此，尽管 Java 2 安全性能够极大增强 WebSphere Application Server 的安全性，但不要认为这将提供应用程序的完全隔离和保护。如果您不能信任运行在 WebSphere 应用程序服务器上的代码，就应该非常谨慎。
安全配置管理系统跟踪每段代码的修改并进行严格的代码审查，以确保代码的开发符合您的安全性原则。通过安全配置管理系统，与“欺诈”程序员相关的问题得到了较好的处理。
15. 选择适当的 WebSphere Application Server 流程身份
WebSphere Application Server 流程在操作系统上运行，因此必须在某个操作系统身份下运行。有三种方式可以用操作系统身份来运行 WebSphere Application Server：
- 以根的身份运行任何程序。
- 以单一用户身份运行任何程序，比如“was”。
- 以根的身份运行节点代理，并以其自己的身份运行单独的应用程序服务器。
IBM 测试并完全支持前两种方式。第三种方式看起来比较诱人，因为那样您就可以利用操作系统权限，但是这在实践中并不是非常有效，这是出于以下原因：
- 它非常难以配置，并且没有文档化的规程。许多 WebSphere Application Server 流程需要读取大量文件并写入到日志和事务目录中。
- 通过以根的身份运行节点代理，您实际上对 WebSphere Application Server 管理员赋予了根的权限。
- 该方式的主要价值是控制文件系统访问。这也可以通过使用 Java 2 权限来完成。
- 该方式造成了应用程序彼此隔离这一假象。实际情况不是这样的。WebSphere Application Server 内部安全模型基于 J2EE 和 Java 2 安全性，并且不受操作系统权限的影响。因此，如果您选择这种方法来保护自己不受“欺诈”应用程序的危害，那么您的选择是错误的。
第一种方式显然不合乎需要，这是因为作为通用的最佳实践，如果能够不以根的身份运行流程，就最好避免这样做。这就只剩下第二种方式，这种方式是完全受支持的，它易于实现，并且当在与 Java 2 安全性相关的场景中能够提供良好的安全性。因此我们推荐这种方式。
显然，一旦您已经选择了 WebSphere Application Server 流程身份，就应该通过利用操作系统文件限制来限制文件系统对 WebSphere Application Server 文件的访问。WebSphere Application Server 与任何复杂系统一样，使用并维护大量的敏感信息。通常，没有人应该拥有能够读取或写入大部分 WebSphere Application Server 信息的权限。（对这一点不要过于极端，我们曾见过非常多的案例，在开发期间，开发人员甚至不允许查看 WebSphere Application Server 日志文件。这种极端的做法完全没有必要。在开发期，最大化安全性无助于生产。在生产期，您应该尽可能的锁定 WebSphere Application Server。在开发期，应该采取更宽松的尺度。）特别是，WebSphere Application Server 配置文件（<root>/config）包含了配置信息以及密码。
16. 保护私有密钥
WebSphere Application Server 维护几组私有密钥。两个最重要的例子包括了用于内部通信的密钥库以及用于 Web 服务器和应用程序服务器之间通信的密钥库。这些私有密钥应该保持私有并且不可共享。如前面所提到的，由于它们保存在计算机文件系统中，因此那些文件系统必须妥善保护。然而，也应该注意避免偶然的共享。例如，不要在产品中使用与其他环境中相同的密钥。许多人将能够访问开发和测试计算机以及他们的私有密钥。小心保护这些产品密钥。
17. 不要将 Web 服务器的文档根目录设置为 WAR
WAR 文件包含应用程序代码和许多敏感信息。只有其中的一些信息是可服务于 Web 的内容，因此不适宜将 Web 服务器文档根目录设置为 WAR 根目录。如果您这样做了，Web 服务器将不作解释的提供 WAR 的所有内容。这将导致代码、未经处理的 JSP™ 等被提供给最终用户。
18. 证书不是万能的
当使用客户端证书身份验证时，需要认识到 Web 服务器当前不是您的信任域的一部分。Web 服务器的泄密将彻底损害 WebSphere Application Server 安全性。进一步说，当您使用客户端证书身份验证时，由于 WebSphere Application Server 当前完全信任 Web 服务器，您应该在 Web 服务器和应用程序服务器之间配置已验证的 HTTPS。否则就有可能通过绕过 Web 服务器来欺骗用户。
19. 不断进行增补和修改
与任何复杂的产品一样，IBM 会不时的发现并修改 WebSphere Application Server、IBM HTTP Server 以及其他产品中的安全性错误。您应该始终跟上这些修改，这一点尤为重要。至少您应该努力使用最新的 PTF，它包括了所有最近的安全性修改。另外，订阅您所使用的产品支持报告也是一个不错的选择。那些报告经常包含最近发现的安全性错误和修改的通知。您应该确信潜在的入侵者会很快了解那些安全性漏洞。因此，您行动的越早越好。
基于应用程序的预防性衡量：配置
到目前为止，我们已经专门介绍了安全性的基本步骤，WebSphere Application Server 架构师和管理团队可以采用这些步骤以确保创建安全的 WebSphere Application Server 基础架构。这显然是重要的一步，但是还不够。既然基础架构已经被安全配置，我们就必须检查应用程序需要做的工作以确保安全。显然，应用程序需要利用 WebSphere Application Server 提供的基础架构，但是应用程序开发人员还需要采用许多其他的操作。许多问题将在下面详细描述。
20. 仔细验证每个 Servlet 别名是否安全
WebSphere Application Server 通过 URL 保护 Servlet。每个将要保护的 URL 都必须在描述应用程序的
web.xml 文件中指定。如果 Servlet 有不止一个别名（那就是说，多个 URL 访问同一个 servlet 类）或者有许多 Servlet，就比较容易遗漏对别名的保护。这需要小心。由于 WebSphere Application Server 保护 URL，而不是基础类，所以即使只有一个 servlet URL 是不安全的，入侵者也能够绕开您的保护。为了减少这种威胁，尽可能使用通配符来保护 Servlet。如果那并不合适，就应该在部署前再次仔细检查您的
web.xml 文件。
“通过类名为 servlet 提供服务”这一功能进一步加剧了别名问题，这将我们带入了下一个推荐。
21. 不要通过类名来提供 servlet
可以通过类名或通过通用 URL 别名来提供 servlet 。通常，应用程序选择后者。换句话说就是，开发人员在
web.xml 文件中手工（或者使用一种 WebSphere Application Server 部署工具）定义从每个 URL 到每个 Servlet 类的精确的映射。
然而，WebSphere Application Server 也允许您通过类名提供 Servlet，而不是为每个 Servlet 定义一个映射，这样单个普通 URL（比如
/servlet ）可以提供所有的 Servlet。WebSphere Application Server 假设基本路径后面的组成部分是 Servlet 的类名。例如，
/servlet/com.ibm.sample.MyServlet 引用 Servlet 类 com.ibm.sample.MyServlet。
通过类名提供 Servlet 这一功能有两种完成设置的方法，一种是通过在
ibm-web-ext.xmi 文件中将 serveServletsByClassnameEnabled 属性设置为 true，另一种是使用 ASTK 在 WAR 编辑器中检查
通过类名提供 servlet。不要启用这个 WebSphere Application Server 功能。该功能使得知道任意 Servlet 名称的任何人都能够直接调用 Servlet。即使您的 Servlet URL 是受保护的，攻击者也能够绕过 WebSphere Application Server 的通常基于 URL 的安全性。进一步说，依赖于类装载器结构，攻击者将能够在您的 Web 应用程序外部调用 Servlet。
22. 不要将敏感信息放到 WAR 根目录中
WAR 文件包含可服务于 Web 的内容。WebSphere Application Server Web 容器将提供 WAR 文件根目录中的 HTML 和 JSP 文件。在您将可服务内容放在根目录中的时候，这是一个好办法。因而，你就不应该将不能显示给最终用户的内容放到 WAR 的根目录中。例如，不要把属性文件、类文件或其他重要信息放在那里。如果您必须把信息放在 WAR 中，就将这些信息放在 WEB-INF 目录中，这 Servlet 规范中是允许的。那里的信息不能接受 Web 容器的服务。
23. 考虑禁用文件服务和目录浏览
您能够通过禁用文件服务和目录浏览来进一步限制不适当内容服务所造成的风险。显然，如果 WAR 包含可服务的静态内容，文件服务将必须启用。
24. 在 J2EE 资源中使用容器管理的别名
单元中运行的任何 J2EE 应用程序都能够访问任何 J2EE 资源。这是因为这些资源有可以被任何应用程序查找的 JNDI 名称。资源访问没有授权。因此，如果应用程序 A 使用企业数据库，简单的通过将数据库定义为数据源就可以使同一单元中的应用程序 B 访问这个数据库。
当应用程序试图通过在资源工厂（比如数据源或者 JMS 连接工厂）中调用 getConnection() 来访问资源时，WebSphere Application Server 将自动为基础数据库提供身份验证信息（如果可用的话）。关于提供什么样的身份验证信息的决定依赖于身份验证模式和可用的 J2C 身份验证别名。这方面的详细信息非常复杂，但是简单的说，任何应用程序都能够在 JNDI 命名空间中查找任何资源。当这个工作完成后，将隐含的使用“应用程序”身份验证模式。这意味着 WebSphere Application Server 将使用组件身份验证别名（如果可用）。因此，使用组件别名定义的任何资源都可以被单元中的任何应用程序访问。
另一方面，如果资源中只定义了容器别名，那么欺诈应用程序将不能访问资源，这是因为欺诈应用程序只能通过全局 JNDI 访问来窃取对资源的访问权，而全局 JNDI 访问总是使用组件别名。
如果您选择使用这种方法，用容器管理别名定义所有的资源，那么就需要应用程序使用本地引用来访问资源，并将在引用中指定容器管理身份验证作为开发流程的一部分。用图例可以更清楚的加以说明。图 9 展示了 WebSphere Studio 引用编辑器，在该编辑器中我们对数据库引用指定容器管理身份验证。
图 9. 使用容器管理身份验证的数据库资源引用
25. 不要在数据源中定义缺省用户名和密码
关于前面条目的一个推论是，您不应该在数据源中定义缺省用户名和密码。如果您这样做，那么单元中的任何应用程序都能够查找资源，然后隐含的使用所提供的用户名和密码。相反，应该始终仅指定容器管理的别名。
26. 谨慎使用 J2C 资源
细心的读者可能发现有些资源不支持容器管理别名。或许它们仅支持资源定义中提供的缺省用户名和密码。如果事实如此，就应该非常小心的使用它们，并且如果有可能的话，不要提供缺省用户名和密码。在许多场合，有其他的编程方式能够提供身份验证信息。
27. 合理配置 Java 2 安全性
如前面提到的，Java 2 安全性提供了强大的方法来限制性用程序并防止各种形式的非法访问。除了防止对 WebSphere Application Server API 的非法访问，Java 2 安全性还限制了文件系统访问，这在共享环境中尤为重要。
WebSphere Application Server 缺省将应用程序限制为一组非常小的“安全”权限。如果一个应用程序需要更多的权限，就必须在 EAR 所包含的 was.policy 文件中定义那些被请求的权限。当应用程序部署后，WebSphere Application Server 将读取 was.policy 文件并将那些权限添加到标准组中。显而易见，这是一个潜在的安全漏洞。幸运的是，当应用程序请求额外的权限时，WebSphere Application Server 管理工具将警告管理员。我们的建议是：仔细审查被请求的权限。如果有任何出乎意料的情况（预期的组应该在一个经过仔细审查的交付文档中），就拒绝该应用程序。应该有一个正式的流程，即包括安全性审查以确定允许应用程序拥有什么样的权限。
审查和验证的流程比较枯燥乏味，并且没有更简单的办法来避免这项工作。然而，对于大型环境组，大部分应用程序都将需要一组常用的额外权限。如果可能的话，基础架构开发组可以将缺省权限放到 app.policy 文件中，以用于节点上所有的应用程序。这样，就只有需要非常用权限的应用程序需要进行手工验证。
基于应用程序的预防性衡量：设计与实现
在这里，我们将注意力转移到应用程序开发和设计人员为构建安全的应用程序而必须采取的操作上来。这些步骤至关重要而且经常不幸的被忽视。
28. 使用 WebSphere Application Server 安全性来保护应用程序
应用程序开发组通常能认识到他们的应用程序中需要某种程度的安全性。这经常是业务上的需求。不幸的是，许多团队开发他们自己的安全性基础架构。尽管有可能会做好，但是难度非常大，并且大部分团队都不能成功。相反，他们的系统看似很安全，但实际上系统安全性极其脆弱。安全性是一个困难且复杂的问题。有许多错综复杂的问题，像密码术（cryptography）、重放攻击（replay attack）以及各种各样其他形式的攻击都很容易被忽视。这里应该使用 WebSphere Application Server 安全性，直到它确实不能满足您的需求。而这种情况一般很少见。
也许关于 J2EE 定义的声明性安全模型的最常见的抱怨就是它没有提供足够的粒度。例如，您可以只在方法级别上保护 EJB 或 Servlet，而不是在实例级别上。（在该上下文中，Servlet 上的方法是一种 HTTP 方法：GET、POST、PUT 等等。）再如，所有的银行账号都有相同的安全性限制，但是您更希望某些用户能够对他们自己的账号拥有特定的权限。
这个问题通过 J2EE 安全性 API（isCallerInRole 和 getCallerPrincipal）来处理。通过使用这些 API，应用程序能够开发它们自己强大且灵活的授权规则，但仍然从 WebSphere Application Server 运行时的 accurate[md] 安全性属性信息驱动那些规则。
一个弱安全性的例子：
不使用 WebSphere Application Server 安全性的应用程序倾向于创建自己的安全性令牌，并在应用程序内部传递。这些令牌通常包含用户名和一些安全性属性，比如它们的组成员关系。这些安全性令牌一般没有密码验证信息。这是假设了能够基于这些令牌内的信息做出安全性决策，而这是错误的。该令牌仅仅断言用户的特权。这里的问题是，任何 Java 程序都能够伪造这些安全性对象，并可能通过后门侵入您的系统。最能说明问题的例子是当应用程序在 Servlet 层中创建这些令牌，然后将其传递到 EJB 层的时候。如果 EJB 层不安全（参见下一部分），入侵者就能够使用伪造的凭证直接调用 EJB，使应用程序的安全性无效。因此，如果没有充实的工程计划，那么唯一可靠的用户信息安全来源就是 WebSphere Application Server 基础架构。
|
与其他身份验证产品集成
WebSphere Application Server 安全性基础架构能够和其他的身份验证或授权产品进行集成。例如，Tivoli Access Manager 能够对 WebSphere Application Server 提供身份验证和授权支持。这不会减弱 WebSphere Application Server 安全性，相反，它扩展了 WebSphere Application Server 的信任域以包括那些产品。
|
|
29. 保护应用程序的每一层（特别是 EJB 层）
我们常常将 Web 应用程序以一定程度的安全性（自制的或基于 WebSphere Application Server 的）部署于 Servlet 层，但是对作为应用程序的一部分的其他层却不加以保护。这样做是基于一个错误的假设：应用程序中只有 Servlet 需要保护，因为它们是应用程序的前门。但是，就像警察对您常说的那样，您也应该关上您家的后门和窗户。有许多方法可以做到这一点，但是这种疏忽最常见于当 EJB 组件作为多层体系结构的一部分使用，而此时 Java 客户端不是应用程序的一部分的时候。在这种情况中，开发人员常常认为 EJB 组件不需要保护，因为它们在应用程序设计中不是“用户可访问的”，但这种想法是一个危险的错误。如果您不对 EJB 层实施保护，入侵者就可以绕过 Servlet 接口，直接进入 EJB 层并进行破坏。使用可用的 Java IDE 可以很容易做到这一点，这些 Java IDE 能够检查运行中的 EJB、获取它们的元数据，以及动态创建测试客户端。WebSphere Studio 有这个能力，并且如果开发人员使用集成的测试客户端，就会每天都看到这些。
通常，对于该问题的第一反应就是通过一些平常的手段保护 EJB 组件，或许是将它们标识为可被所有已授权用户访问。但是，“所有已授权用户”可能是公司中的每一个雇员，这取决于注册表。一些人更进一步的限制确定的组中成员的访问权限，这大概意味着“任何能够访问该应用程序的人”。这样更好一些，但是通常还不够，因为不是能够访问应用程序的每个人都有必要能够执行应用程序中的所有操作。请再次查阅前面的章节以了解如何对此进行处理。
30. 出于安全性考虑，不要依赖 HTTP session ID
不幸的是，一些使用自身安全性的应用程序在 WebSphere Application Server HTTP Session 的使用过程中始终跟踪用户身份验证 session。这是危险的。WebSphere Application Server session 通过 session ID（在 URL 或是 cookie 中）而被跟踪。尽管 ID 是加密生成的，但仍然容易遭受重放攻击，没有超时限制（除非闲置的时候），并能通过网络嗅探攻击窃取该 ID。应用程序使用 WebSphere Application Server 安全性时所创建的 WebSphere Application Server LTPA 令牌能够使这些类型的攻击非常难以成功。特别是，LTPA 令牌限制了生存期并使用了可靠的加密，而且 WebSphere Application Server 安全性子系统会审查接受到的非法 LTPA 令牌。
无论如何，如果 HTTP Session 用于跟踪用户，那么所有的通信都应该通过 HTTPS 来发送，以防止网络嗅探。
31. 防止交叉站点脚本（cross-site scripting）
交叉站点脚本是一种非常隐蔽的攻击，它利用了 Web 浏览器的灵活性和强大功能。大部分 Web 浏览器都能够解释各种脚本语言，比如 JavaScript。浏览器知道脚本正基于换码符（escape character）的特定顺序来查找可执行内容。Web 浏览器安全性模型存在着巨大且危险的缺陷。
入侵者通过欺骗 Web 站点来利用这个漏洞，使浏览器中显示入侵者希望站点执行的脚本。这可以在允许任意用户输入的站点上非常容易的完成，例如，如果站点包括一种输入地址的方式，入侵者就可以借此输入 JavaScript。当站点以后显示这个地址的时候，Web 浏览器就将执行这个脚本。由于这个脚本在站点的 Web 浏览器上运行，就可以访问到保密信息，比如用户的 cookie。
如果仅仅如此，这看起来还不算是很可怕的危害，但是入侵者更进一步。他们或许通过在电子邮件中给用户发送无害的 URL 来欺骗用户进入 Web 站点，并将用户数据输入到“邪恶脚本”。这样入侵者就能够使用用户身份来危害系统。（请参阅
为 Web 开发人员理解恶意的内容减少。）
这个问题实际上是关于用户输入验证的问题大类的一个特定案例。如果您允许用户输入自由形式（free-form）的文本，您就必须确保该文本不包含可能导致危害的特殊字符。例如，如果用户要输入用于查找某个索引的字符串，就需要过滤字符串中可能导致无限制查找的非法通配符，这一点很重要。在交叉站点脚本的预防中，您需要为脚本语言过滤掉换码符。
32. 安全的存储信息
要想创建安全的系统，您必须考虑信息在何处存储或显示。有时，非常严重的漏洞可以由偶然事件而引起。例如，在 HTTP Session 对象中存储高度机密的信息时需要谨慎，这是因为这些对象被序列化到数据库，因而那些信息可以从那里读取。如果入侵者有权访问您的数据库，或者甚至是对数据库卷的原始机器级别的访问，他或她就有可能能够看到 session 中的信息。毫无疑问，这样的攻击需要采用高级技巧。不幸的是，后面两种攻击几乎毫不困难。
一个微妙的问题发生于有状态 session bean。当内存不足时，这些 bean 通过 WebSphere Application Server 序列化到文件系统。这里，保密信息又会被不小心写入磁盘。
日志纪录可能是造成安全隐患的最危险区域。开发人员经常将高度情报性的消息放到日志文件中以帮助调试。不幸的是，有时这些信息是机密的。请牢记，您永远不知道谁将能够看到日志文件。一些应用程序被要求将社会保障号（social security number）纪录到文件。毫无疑问，这增加了各种可能的麻烦。这里的关键问题是为安全敏感（security-sensitive）信息谨慎审查所有的日志和其他形式的输出。
33. 使闲置用户无效
一旦您开始处理 HTTP Session 和身份验证 session，就应当使它们无效。这样做减少了闲置 session 被其他用户获得的可能性。同时也释放了 WebSphere Application Server 中的资源以用于其他的工作。
通过使用 HTTPSession.invalidate() 方法来销毁 HTTP Session。通过引导用户到
ibm_security_logout URL 来销毁 WebSphere Application Server 身份验证信息。（请参考
WebSphere Application Server 信息中心以获取详细信息。）值得注意的是，删除 session cookie 的最可靠方法是简单的退出 Web 浏览器。现在许多 Web 站点明确推荐这种方法，也许您也应该如此。
到目前为止，我们已经讨论了巩固 WebSphere Application Server 环境所需的许多步骤。显而易见，必须采取许多困难且复杂的步骤以确保您的系统的安全。当您创建复杂的 J2EE 系统时，确保计划表中有足够的时间用于处理安全性。将其添加到系统未必就能正常工作，这将我们带入最后一个主题。
故障诊断
与 WebSphere Application Server 一样，安全性子系统是被完全跟踪的。要跟踪 WebSphere Application Server 安全性，需要启用对这些包的跟踪：
com.ibm.ws.security.* 和
com.ibm.Websphere.security.* 。
一般来说，除非安全性问题影响到服务器的启动，否则最好是启动应用程序服务器，使其稳定，然后启用安全性的动态跟踪。最后运行您的测试并观察跟踪的输出结果。
确定 WebSphere Application Server 如何管理 LTPA cookie 或令牌也是很有用的。您应该启用您的 Web 浏览器关于 cookie 的警告。一旦您这样做了，当 WebSphere Application Server 返回 LTPA 令牌时，浏览器就将通知您。如果在看到身份验证成功进行之后，您没有收到这样的警告，那可能是浏览器或某些中间代理取消了 cookie。这也许是 LTPA SSO 页面中 DNS 域的设置错误或是代理服务器的配置不正确。如果 LTPA 令牌由 WebSphere Application Server 生成，然后可能丢失，那么开启 Web 服务器插件跟踪，并且有可能的话，开启 WebSphere Application Server Web 容器跟踪（
com.ibm.ws.Webcontainer.* ）来进行查看会很有帮助。
结束语
本文涉及了很多内容。尽管我们的核心主题集中于加固 WebSphere Application Server 环境，但也讨论了安全性的许多方面。希望您现在已经了解了需要用来保护您的 J2EE 系统的基本信息。
致谢
感谢我的同事 Tom Alcott 和 Bill Hines 为本文提供了有价值的建议。还要感谢 Ching-Yun (C.Y.) Chao 和 Peter Birk，他们是 WebSphere Application Server 安全性开发组的成员。
参考资料
关于作者 | 
