级别： 中级 Keys Botzum, 高级顾问 , IBM
2006 年 2 月 06 日 安全性不仅仅涉及到在网络边缘保护您不受外部攻击的防火墙。它是一组费力且复杂的操作和过程，旨在尽可能地加强您的系统。本文涉及一般安全性概念的很多方面，详细讨论了 IBM® WebSphere® Application Server 安全性体系结构，并讨论了如何加强 WebSphere Application Server 环境。这是由两部分组成的文章中的第 2 部分。
摘自 IBM WebSphere 开发者技术期刊。
本文是以 IBM WebSphere: Deployment and Advanced Configuration 一书的安全性章节为基础编写的。本文内容已针对 WebSphere Application Server V6 进行了大幅度更新，并经过编辑，只讨论安全性加强方面的内容。该文本已进行过编辑和排版以作为独立的文章发表。虽然本文基于 WebSphere Application Server V6，但这里的大多数问题也同样适用于 V5 和 V5.1。其中有一个问题是 V6 特有的，我们会特别指出。除此之外，几乎所有其他内容都适合这三个主要版本，不过屏幕截图和示例均来自 V6。
接第 1 部分
本文是 WebSphere Application Server V6 高级安全性加强，第 1 部分：安全性加强概述和方法的续篇。
高级注意事项
现在，我们将继续讨论一些与安全性加强相关的高级问题。我们将讨论以下内容：
- 跨计算单元的信任
- 应用程序隔离
- 标识传播
- WebSphere Application Server 安全性中的局限
在很多情况下，我们都不会提出具体的建议，而是提供一些重要的信息，以帮助您维护和管理安全的基础设施。
计算单元信任和隔离
WebSphere Application Server 计算单元不应越过信任边界。如果不能完全信任别人，则不要让他们管理您的计算单元或管理您的计算单元内的计算机。WebSphere Application Server 管理基础设施在计算单元范围内使用了一个粗粒度共享信任模型。每个应用服务器都将其包含在管理基础设施中，包括内部 API。就正面而言，这样就消除了控制的公共点，使得应用服务器具有很高的独立性和稳定性。不过，它也会对隔离有负面影响。采用此方法则隐式地包含以下内容：
-
WebSphere Application Server 计算单元中的每个应用服务器都对整个计算单元具有完全的管理权限。如果任何应用服务器被破坏，则所有应用服务器都会被破坏。
-
物理计算机边界（独立的计算机、LPAR、节点等等）几乎对计算单元安全性没有任何影响。计算单元中的信任单位是所有节点上的所有应用服务器。
-
进程边界对计算单元安全性几乎没有影响。将应用程序放置在独立的应用服务器 JVM 中对增强其计算单元内的安全角度的隔离性并没有太大用处。
-
独立的操作系统标识对计算单元的安全性几乎没有影响。由于应用服务器使用各种协议与计算单元的其他部分进行通信，而这些协议却不是由操作系统进行管理的，因此正常的操作系统投影的效果甚乎其微。
-
每个管理员对于整个计算单元都具有相同的管理权限（在其分配的管理角色内：管理员、配置人员、操作员或监视人员）。
这就提出了两个关键主题：管理隔离和应用程序隔离。
管理隔离
对于 WebSphere Application Server，所有管理员都对整个计算单元具有管理权限。不可能将不同应用程序、不同应用服务器或不同节点的各个不同权限单独进行分配。
如果您关心管理隔离，则可以马上就采取一些措施来满足这方面的需要。首先，可以利用 WebSphere Application Server 中不同的管理角色。
其次，可以为最常见的管理操作（应用程序更新、服务器重新启动等等）创建自定义管理工具。您可以根据管理员和应用程序限制这些常见工具的使用。有两个处理这方面的可行方法。第一个方法是编写自定义 wsadmin 脚本，并使用操作系统权限对其进行保护，以确保每个管理员只能为其所属的服务器运行这些脚本。第二个方法是编写小型 Web 应用程序来使用 J2EE™ 安全性对管理员进行身份验证，然后允许管理员根据其访问权限执行特定的受限操作。应用程序本身可以使用 JMX API 来管理计算单元。这两种方法均得到了 IBM 客户的成功应用。
应用程序隔离
现在我们将注意力转向或许是本文中最难的一部分。在此上下文中的应用程序隔离基本上是关于如何防止一个应用程序的非法操作对另一个应用程序造成伤害。此类攻击很难避免。事实是，基础设施软件产品（如 J2EE 应用服务器）尚未达到多用户操作系统的成熟水平。它们不能提供操作系统通常在多用户间提供的可靠隔离。
这影响我吗？
首先，也是最重要的，此处讨论的缺陷均只是内部缺陷。只有安装到您的计算单元的应用程序才能利用这些缺陷。在 IBM 的经验中，绝大部分 WebSphere Application Server 用户（甚至包括处于共享基础设施中的那些）都不受这些问题影响。这是因为，他们认识到了其共享基础设施位于企业内部，运行的是得到企业认可的代码。因此，他们通常不要求应用程序实现完全的安全隔离。
受到此处的问题困扰的 WebSphere Application Server 用户通常具有非常严格的安全措施，例如：
-
具有正式的策略，要求应用程序即使在共享基础设施中运行也不能具有其他应用程序的数据的访问权限。
-
对于早于 WebSphere Application Server 的系统，每个应用程序在共享服务器上的独立用户 ID 下运行的要求详细地列出了关于文件系统权限的规则，每个应用程序都具有专用进程，并严格限制执行这些要求的审核过程。
-
具有严格的企业安全指南，并得以严格执行来确保这些指南得到了遵从，包括应用程序体系结构和代码检查。如果没有代码检查，开发人员可能会插入违反企业策略的代码。
-
它们也可能十分关注远程工具，此类远程工具可能在破坏了一个应用程序后，然后利用其来破坏其他应用程序。
如果不属上述之列，这些问题对您不适用，则可以跳过这一部分的其余内容。
我可以采取何种缓和措施？
如果您担心应用程序会影响其他应用程序的安全性，则可以马上就采取一些措施来满足这方面的需要：
-
对所有应用程序代码执行严格的代码检查。另外，最好将源代码管理系统与之配合使用。这样，对于每次代码更改，将跟踪进行更改的人员，且针对每次代码更改计划代码检查和跟踪。此时，单个程序员不可能将恶意代码插入到您的系统中。相反，进行任何破坏都需要多人合作。
-
如果您选择购买运行于 WebSphere Application Server 之上的商业应用程序，请确保仅从可靠的、值得信任的供应商处进行购买。首先对应用程序进行细致的测试和监视，然后再进行生产部署，并在生产环境中对其进行监视。
-
如果确实有必要，就将应用程序部署到专用 WebSphere Application Server 计算单元中。您可以考虑根据风险和信任对不同的业务单位或其他组织单位使用不同的计算单元。为了限制硬件成本，完全可以在单个计算机或 LPAR 上运行来自多个计算单元的多个节点。直接使用不同的操作系统用户 ID、不同的加密密钥和不同的管理密码运行每个计算单元即可。从安全性角度而言，这将提供完全的隔离。
如果这些方法都不可接受，则可以对基础设施应用应用程序隔离加强技术。需要知道，这些技术都要求进行大量的工作。更重要的是，它们不能保证提供隔离。在同一个计算单元中的应用程序（即使启用了全局安全性和 Java™ 2 安全性）可能会通过访问其他应用程序的资源或改变计算单元配置，从而潜在地破坏同一计算单元中的其他应用程序。从来不会报告此类破坏情况。通过单个计算单元的配置，不可能保证不会出现此类破坏。
尽管我们对此提出了警告，但我们现在仍将继续讨论可以用于大幅度提高计算单元内的应用程序安全隔离的操作。与第 1 部分一样，将按照优先级顺序列出这些操作。为了帮助您将本文所提供的加强技术与第 1 部分中讨论的攻击类别对应起来，我们为每种技术加注了以下图标：
这四个方块加了适当的底纹，以代表这种技术有助于防范的攻击类型：
-
N = 基于网络
-
M = 基于计算机
-
E = 基于外部应用程序
-
I = 基于内部应用程序
47. 不要在 J2EE 资源上指定组件管理的别名
任何在计算单元内运行的 J2EE 应用程序都可以潜在地访问任何 J2EE 资源。这是因为资源具有 JDNI 名称，而此名称可以由任何应用程序进行查询，并且资源访问上没有授权机制。因此，如果应用程序 A 使用企业数据库，直接将该数据库定义为数据源，则同一计算单元中的应用程序 B 就可以访问此数据库。
当应用程序试图通过对资源工厂（如数据源或 JMS 连接工厂）调用 getConnection() 来访问资源时，如果对应的基础资源可用，WebSphere Application Server 将隐式地提供该基础资源的身份验证信息。要提供何种身份验证信息取决于身份验证模式和可用的 J2C 身份验证别名。具体的细节非常复杂，但简单来说，任何应用程序都可以查找 JNDI 名称空间中的任何资源。完成此工作后，将隐式地使用“应用程序”的身份验证模式。而这又意味着 WebSphere Application Server 将使用组件身份验证别名（如果可用）。因此，计算单元中的任何应用程序都可以访问任何使用组件别名定义的资源。请注意，在不同的范围内定义资源对安全性并没有影响。资源范围仅为方便管理而存在。
另一方面，如果只在资源上定义了容器别名（或者没有指定别名），则恶意应用程序就不能访问此资源，因为当在全局 JNDI 名称空间中访问资源时，将使用应用程序身份验证，从而会使用组件别名。如果没有组件别名，则不会出现隐式身份验证。
如果您选择采用此方法，显然将仍然希望恰当的应用程序能够访问这些资源。为了实现此功能，这些应用程序必须在其部署描述符中指定用于访问相应资源的本地资源引用。然后可以在部署时将这些引用绑定到正确的资源。如果应用程序在引用上指定了容器管理的身份验证，则将隐式使用在资源本身上定义的容器管理的别名。这种情况可以使用一张图加以说明。图 16 是 IBM Rational® Application Developer 引用编辑器的图，我们正在其中指定一个 JMS 连接引用上的容器管理的身份验证。
图 16. 使用容器管理的身份验证的数据库资源引用
 | |
XA 恢复别名不是问题
不要将组件管理的别名与资源上指定的 XA 恢复别名混淆。XA 恢复别名仅在涉及到事务故障的特定恢复场景中使用。如果 Java 2 安全性未启用，而使用缺省权限，则应用程序通常不用访问该别名。
|
|
对于此方法，有两个问题。首先，容器管理的别名已被启用，但却能正常工作。更重要的是，您可能已经注意到，并非所有的资源都允许指定容器管理的别名，如 JMS 工厂。在这种情况下，一定不能在资源上提供缺省身份验证信息。而必须像在部署期间一样，在应用程序中执行每个资源引用的身份验证信息（此时身份验证方法并不重要）。此工作非常单调乏味，可以使用 wsadmin 实现此过程的自动化。至少对于 MDB，可以在活动规范中指定身份验证信息。
48. 不要在资源上定义缺省用户 ID 和密码
前一项的一个推论是，不应在资源上定义缺省用户 ID 和密码。如果这样做，计算单元内的任何应用程序就都可以查找该资源，然后将隐式地使用提供的用户 ID 和密码。
49. 启用 Java 2 安全性
正如在前面讨论的，所有应用服务器均包含 WebSphere Application Server 管理基础设施，因而也包含用于执行大部分管理操作的 API。学习了这些 API 的应用程序程序员可以编写调用其中任何 API 的应用程序，因而实质上可以执行任何管理操作。此外，文件系统配置存储库包含大量的敏感信息（如密码）。任何应用程序都可以使用普通 Java I/O 来读取这些文件。
WebSphere Application Server 包括对标准 JDK 提供的 Java 2 安全性的支持。IBM 具有增强的 Java 2 支持，用于执行 J2EE 规范和保护 WebSphere Application Server 内部 API 不被非授权访问。直接启用 Java 2 安全性，就会自动执行这些规则。因此，通过启用 Java 2 安全性，就可为运行时添加很多额外的保护，从而防止非法应用程序访问。
一旦启用了 Java 2 安全性，缺省情况下，应用程序就被限制为仅使用很小的一部分“安全”权限集。如果应用程序需要更多的权限，它通常必须在 EAR 内包含的 was.policy 文件中定义这些被请求的权限。应用程序在运行时，会读取 was.policy 文件，并将这些权限添加到标准集中。非常明显，这是一个潜在的安全漏洞。幸运的是，WebSphere Application Server 管理工具会在应用程序请求其他权限时向管理员发出警告。我们的建议是，对所请求的权限进行仔细的复查。如果有意外情况（应该在一个经过仔细复查的应用程序交付文档中包含预期的权限集），则拒绝该应用程序。应该配备正式的流程，其中应包含安全复查，以确定应用程序将被允许使用哪些权限。
安装的复查和验证过程可能会十分单调乏味。不过，可以采用另一种方法。首先，对于很多环境而言，大部分应用程序都将需要一个公共的附加权限集。如果不可能这样做，基础设施团队可以在 app.policy 文件中设置该节点上所有应用程序的缺省权限集。只有需要不常见权限的应用程序才需要将所需权限放置在 was.policy 中并需要进行额外的验证。甚至可以进一步进行限制，禁止使用 was.policy 并要求由管理团队将所有权限添加到 app.policy 中。采用同样的方式（编辑一个公共文件），这会使得部署变得复杂起来，但可以减少应用程序获得不恰当的权限的风险。
50. 利用安全连锁委托
应用服务器的好处之一就是会自动在系统层间和应用程序间发送用户标识信息。这样就实现了透明的单点登录。不过，这有一个可能非常危险的副作用：不恰当的模拟。
此处的问题是，当用户为了使用应用程序 A 而进行身份验证时，应用程序 A 可能将对应用程序 B 进行远程 EJB 调用。然后，应用程序 B 就将看到原始用户的凭据。通常，这没有什么问题。但是，如果应用程序 A 不可信呢？那么，访问应用程序 A 的用户就可能担心该应用程序会通过模拟来以此用户的名义访问应用程序 B。设想一下，假如应用程序 A“不重要”，因此是采用临时的方式开发的；而应用程序 B 是管理保密信息的高度敏感应用程序。此处的问题是应用程序 B，因为它与应用程序 A 共享一个公共安全域，因此必须信任应用程序 A。这非常不好。
好消息是，有办法解决此问题。我们可以使用 WebSphere Application Server 中的一项新功能，此功能被概略地描述为“安全连锁委托”。通过使用 WSSecurityHelper.getCallerList() 或 getServerList()，应用程序 B 可以确定请求经过了哪些应用程序和服务器。API 不仅返回最终用户标识，而且也返回中间服务器的信息。如果应用程序 B 是高度敏感的应用程序，它可能要求该列表为空——表示该应用程序由用户直接使用。请参阅 WebSphere Application Server 信息中心，以获得关于 WSSecurityHelper 的更多信息。
51. 保护 TAM WebSEAL TAI 密码
当在 Tivoli® Access Manager WebSEAL 和 WebSphere Application Server 之间配置了 SSO 时，WebSEAL 会为每个请求在 HTTP Header 中发送其保密的密码，以确保 TAI 在调用时能正常工作。虽然由于连接应使用 SSL 进行加密，所以通常这不是什么问题，但这样的确会向 WebSphere Application Server 中运行的 Web 应用程序公开 WebSEAL 密码。
如果运行在 WebSphere Application Server 中的某个 Web 应用程序不受信任，该应用程序可能会获取此密码，然后打开到某个应用服务器的 HTTP 连接并断言任何用户的标识。这样，精心编写的“恶意”应用程序就可能代表任何人进行操作了。
如果您担心这种类型的攻击（可以通过代码检查轻松地加以防止），则可以阻止任何不受信任的客户端连接到 Web 容器。要完成此任务，直接在 Web 容器上配置一个共同的经过身份验证的 HTTPS 侦听器即可。随后，应用程序就不能打开到 Web 容器的 HTTPS 连接了，因为它们没有正确的私钥（只有 WebSEAL 或 Web 服务器具有此私钥）。
52. 注意自定义 JMX 代码的提升权限
对于 Mbean，您需要注意，要使用它们，需要提升 Java 2 安全性权限。如果应用程序以编程的方式向应用服务器运行时注册 Mbean，您必须向调用代码授予 RuntimePermission Admin Permission，以让该代码能够执行任何管理操作。进行此操作时需格外小心。一个不错的方法是创建一个专门用于注册 Mbean 的独立模块，并仅授予所需的权限。
第二种加载 MBean 的方法是以管理方式将其指定为扩展 Mbean (Extension Mbean)（此方法是推荐采用的方法）。这样就消除了必须显式授予应用程序代码管理权限的问题，但是又出现了一个新问题。MBean 现在由相当底层的 WebSphere Application Server 类加载器进行加载，此类加载器的信任度更高。因此，与采用普通用户代码方式相比，您的 MBean 将具有更多访问 WebSphere Application Server API 的权限。
如果您选择开发自定义 Mbean，我们强烈建议您仔细对代码及其使用进行复查，以确保不会给系统带来安全漏洞。请参阅 IBM WebSphere:Deployment and Advanced Configuration，以获得有关此内容的更多信息。
53. 谨慎地使用 dynaCache
DynaCache 为 WebSphere Application Server 应用程序提供了强大的高性能分布式共享缓存。不过，DynaCache 上并没有访问控制机制。任何运行在应用服务器中的应用程序都可以访问给定应用服务器具有访问权限的任何缓存。更准确地说，如果缓存从服务器可见，可以看到（或修改）其所有内容，则任何应用程序都可以查找 JNDI 中的缓存。
幸运的是，不能查找远程服务器中的缓存，因此应用程序只能看到复制到其服务器上的缓存。为了限制此风险，应该进行两项工作。首先，在可能的情况下，不要将敏感信息放置到缓存中。其次，将应用程序放置在属于独立复制域的独立应用服务器上，以确保它们不能访问彼此的缓存。
54. 小心地使用所有资源
很多其他 WebSphere Application Server 资源（如工作区）并不提供应用程序级别的授权。对于 DynaCache，您需要小心地使用这些资源。我们尚未在考虑到这一点的情况下对每个 WebSphere Application Server 组件进行研究。如果您关心应用程序隔离，则应小心地对每个使用场景进行评估，并查找潜在的漏洞，并据此采取相应措施。
跨计算单元的信任
通常，WebSphere Application Server 计算单元并不彼此信任，因此不可能实现跨计算单元的单点登录（Single Sign On，SSO）。不过，可以对计算单元进行配置，使其支持跨计算单元 SSO。进行此工作有许多很好的理由，但进行此工作时，实际上是在扩展计算单元的信任域，需要注意对安全的潜在影响。需要考虑三个问题：共享 LTPA 密钥、跨计算单元主题传播和 CSIv2 标识断言。
共享 LTPA 密钥
对于透明参与 SSO 域的两个计算单元，它们必须共享相同的域，共享相同的 LTPA 加密密钥和使用兼容的 SSL Keyring（供服务器用于通信）。通常，域是与注册表完全相同的，但是 WebSphere Application Server 6.0.2 允许通过设置 com.ibm.websphere.security.ldap.logicRealm 属性来对此加以改变。请参阅 WebSphere Application Server 信息中心，以获得更多信息。
| |
产品说明
如果您共享相同的 LTPA 加密密钥仅是为了在不共享自定义主题的情况下创建 Web SSO，可以通过使用身份验证代理服务器（如 Tivoli Access Manager WebSEAL）在不共享 LTPA 加密密钥的情况下达到相同的结果。
|
|
兼容 SSL Keyring 表示调用服务器必须具有对签名证书（与任何 SSL 通信中的接收服务器的证书对应）的访问权限。
一旦确保两个计算单元共享相同的 LTPA 加密密钥后，就创建了一个特殊的环境，在此环境中的每个计算单元都可以为其他计算单元创建凭据。因此，如果一个计算单元被破坏，则两个计算单元都会被破坏。如果使用多个计算单元来实现安全方面的应用程序隔离，则需要启用 Java 2 安全性来限制对 WebSphere Application Server 内部 API 的访问。
CSIv2 标识断言
如果要进行跨计算单元的 IIOP 调用，但希望避免共享 LTPA 加密密钥，则完全可以实现。不过，您必须使用 CSIv2 标识断言（当与非 WebSphere Application Server EJB 服务器进行联系时，这也有用）。让我们看一个简单的场景。假定有两个计算单元，计算单元 A 和计算单元 B，其中均包含多个服务器。假定计算单元 A 中服务器需要对计算单元 B 中的服务器进行 RMI/IIOP 调用，但不会进行相反的调用。为了实现此功能，我们将配置 CSIv2 标识断言。计算单元 A 中的服务器将断言计算单元 B 中服务器的标识。我们将不会描述如何配置 CSIv2 标识断言，只讨论这样做所带来的隐含效果。
对于计算单元 B 中接受标识断言的服务器，计算单元 A 中的上游服务器必须首先对自身进行身份验证。可以采用两种方式来对 CSIv2 进行此操作：基本身份验证——上游服务器将发送其用户 ID 和密码（服务器用户 ID 和密码）；客户端证书身份验证——上游服务器使用自己的证书进行身份验证。WebSphere Application Server 支持这两种方法。
一旦身份验证完成，接受服务器将验证上游服务器是否受信任，可以执行标识断言。这是在 CSIv2 配置面板中进行配置的。随后，上游服务器将向下游服务器发送目标用户的标识信息。
让我们看一下此方法在信任方面的隐含效果。显然，计算单元 B 中服务器从计算单元 A 中接受标识断言，因此是信任计算单元 A 的。如果计算单元 A 被破坏，则计算单元 B 也会被破坏，但对于计算单元 A 有何隐含效果呢？
总之，为了让计算单元 A 对计算单元 B 进行标识断言，计算单元 B 必须信任计算单元 A。这非常明显。如果不希望计算单元 A 信任计算单元 B，则请在服务器身份验证步骤中为服务器使用证书身份验证，而不是采用基本身份验证。
主题传播回调
如果在使用跨计算单元主题传播（请参阅 Advanced Authentication in WebSphere Application Server），则必须了解这意味着计算单元之间存在大量的信任关系。除了满足共享 LTPA 加密密钥的要求外，计算单元级别的服务器标识最终会导致存在大量跨计算单元边界的权限。
为了使这一点更为清楚一些，让我们看一个例子。假定有两个服务器共享 SSO 域。某个用户使用 Web 浏览器访问服务器 A 并获得了一个身份验证会话（在浏览器中使用 LTPA Cokie 表示）。该用户随后访问服务器 B。服务器 B 将试图从服务器 A 获取该用户的主题。这称为主题传播。如果这些服务器位于相同 DynaCache 复制域中，则可以正常地完成此操作。如果不位于相同的域中，则将使用 JMX 回调来获取主题。显然，不同计算单元中的服务器不处于相同的 DynaCache 复制域中。具体来说，服务器 B 将对服务器 A 进行安全 JMX 调用，以获取用户的主题。
对于任何管理调用，JMX 调用都要求进行身份验证和授权。在这种情况下，服务器 B 会将其服务器用户 ID 和密码发送到服务器 A。服务器 A 将随后验证该密码，并确保该用户 ID 对其计算单元具有管理权限。
这有非常大的潜在影响。这意味着，为了使跨计算单元 Web 层（称为水平的）主题传播工作，需要：
最终的结果是，这两个计算单元都完全信任彼此。每个计算单元都对另一个计算单元具有管理权限。在计算单元内的传播也存在同样的行为，但由于计算单元内的服务器已经彼此信任，且共享一个公共管理标识，因此不存在问题。
请注意，这并不适用于出现使用 IIOP 的下游传播时。在出现这种情况时，上游服务器会直接将主题发送到下游服务器。不需要进行 JMX 回调。
标识传播
虽然此主题与安全性加强并不直接相关，但却是一个出现在系统设计中且并没有尽早加以考虑的常见问题。您必须始终非常谨慎地对何处建立标识以及如何进行传播（如果可以传播）进行跟踪。我们已经见到太多的设计直接假设标识为已知，而实际技术却使得这变得不可行。请确保对在应用程序中传递的标识进行了仔细的分析，以防止在后面的开发周期发生灾难。以下我们将给出涉及到外部资源的有关 WebSphere Application Server V6 用户和解决方案的两种常见情况。
数据库与 WebSphere Application Server 身份验证
企业系统的主要挑战之一就是恰当地实现强系统安全控制。简单来说，关键数据需要采用恰当的授权进行保护。使得此挑战对于多层次 J2EE 系统（其中的 J2EE 应用程序代码会访问数据库——使用 JDBC、SQLJ 或 CMP Bean）特别困难的是，最终用户的标识信息通常会被丢失。对于“最终用户”，我们指的是运行的应用程序代表其进行操作的用户——即，如果 Bob 使用标准 J2EE 安全性针对应用程序进行了身份验证，则 Bob 就是最终用户。
在典型的基于 J2EE 的系统中，容器将维护一个经过身份验证的连接池。每个最终用户都会经过应用服务器的身份验证（使用若干种 J2EE 身份验证机制中的一种），但用户的标识信息对数据库却不可用。这是因为所有数据库访问都是使用连接池中的若干公共共享连接之一执行的。从历史的角度而言，这导致了应用程序不得不在应用层内重新进行现有的数据库级别的授权和审核功能。处理得当时，这很浪费资源，而处理不得当时，则很可能非常不安全。
对于 WebSphere Application Server V6，有一个处理此问题的完美解决方案。有关此主题的详细说明，请参阅 WebSphere Application Server V6 中的数据库标识传播。
MDB 不在排队器的标识下运行
当消息排队到消息传递系统时，原始调用方的标识通常并不会与其相关。即，消息传递引擎将根据我们前面讨论的连接标识对此队列进行访问授权。队列通常甚至不会记录最终用户的标识。
当消息离开队列时（在 J2EE 中通常由 MDB 将消息从队列取出），原始调用方的标识将不可用。而且，即使此信息可用，也将被忽略。MDB 在匿名 J2EE 标识或静态 run-as 标识下运行。它们不会在消息排队器的标识下执行。
WebSphere Application Server 中没有用于处理此问题的直接支持。不过，和处理数据库标识保护一样，如果您愿意编写一些自定义代码，就可以实现此功能。对于 WebSphere Application Server V6.0.2，WebSphere Application Server 现在支持服务器端标识断言。即，服务器端代码可以在不提供密码的情况下使用 JAAS 更改其 J2EE run-as 标识。它将直接断言用户标识信息。很明显，这存在严重的安全隐患，因此该功能在缺省情况下是禁用的，但可以将其用于向应用程序代码授予所需的 Java 2 安全权限和编写恰当的 JAAS 登录模块。这在 WebSphere Application Server 信息中心的 Identity Assertions and Trust Validation 部分进行了讨论。
WebSphere Application Server 限制
通过仔细地进行配置，您可以使用 WebSphere Application Server 创建高度安全的可靠环境。不过，您应该注意，一些通常很小的、不太明显的限制可能会对您有所影响。
CRL 未经检查
如果您希望使用客户端身份验证证书，则应该注意 WebSphere Application Server 并不提供证书吊销列表（Certificate Revocation List，CRL）检查。因此，如果您的客户端证书被破坏，则不能对其进行吊销。从实践的角度来看，这就使得证书身份验证不可行，使用自签署证书和服务器来进行服务器通信的特殊情况除外。
通常，这并不是严重问题，因为证书很可能会用于 Web 浏览器身份验证。在此场景中，证书实际上是由 Web 服务器（而不是 WebSphere Application Server）进行验证的，而 IBM HTTP Server 并不包含 CRL 检查。
请注意，在 Web 服务层和/或自定义 UserRegistry（其中包括一个检查证书的调用）包含了足够的代码，就可以采用自定义方式构建您自己的 CRL 检查功能。
目标标识未经验证
安全系统的一个较为微妙的方面是验证请求目标的概念。通常，提到身份验证时，我们会想到服务器对客户端进行身份验证，但客户端是否对服务器进行身份验证呢？客户端如何知道服务器实际上就是所期望使用的服务器呢？我们大部分人都没有认识到这一点，但 Web 浏览器每天都会隐式地执行此项检查。当使用 HTTPS 时，Web 浏览器将验证 Web 服务器的主机名是否与其证书中的 Web 服务器的主题相同。这样可以确保服务器实际上是用户所希望使用的服务器（假定用户知道他们使用的主机名称——很多人并不这样细心）。
不太明显的是，Web 服务器执行的检查并不是 SSL 固有的一部分，而是在 SSL 外执行的特定于浏览器的检查。发起方（调用服务器）必须明确地对证书执行此检查。不过，WebSphere Application Server 并不执行此检查。因此，当应用服务器（或客户端）打开到服务器的 SSL 连接时，它并不能确信该服务器就是希望使用的服务器。可以破坏您的内部 DNS 或网络的黑客有可能（尽管几率很小）随后在 WebSphere Application Server 计算单元中插入一个窃贼服务器，以窃取信息。这将是一项异常困难的攻击（很多攻击要简单得多）。但应当注意这个可能性。
您可以从应用服务器信任存储文件中删除任何不需要的签名密钥，以防止出现这种情况。只有使用受信任的签署方发放的证书才能发起此攻击。在 SSL 握手期间，客户端将拒绝无法验证的服务器端证书。如果受信任列表很小（或许仅包含自签署证书），则发起此类攻击将很困难。
保护您的桌面开发环境
考虑安全性加强时，人们习惯于将注意力集中在生产系统上，生产系统无疑是最重要的。不过，您也应该花一些时间来确保其他计算机（包括您的桌面系统）也具有合理的安全性。
对于这些运行 Rational Application Developer（或早期 WebSphere Studio）的计算机，这是一个非常重要的问题。桌面 IDE 包含了一个功能齐全的嵌入式 WebSphere Application Server 运行时环境。此应用服务器具有开放端口，易于受到本文前面描述的各种方式的远程访问攻击。您需要对此进行处理。
加强嵌入式应用服务器
我们建议，至少在嵌入式应用服务器测试环境中嵌入全局安全性。这样可以防止最恶劣的攻击类型（入侵者可能使用内置管理基础设施来将恶意应用程序部署到您的桌面上）。如果您使用管理权限来运行 Rational Application Developer，这就相当重要。您还可能希望利用本文中提到的其他加强步骤，不过确保管理基础设施的安全是最为重要的步骤。
如果启用全局安全性，则将需要一个注册表。WebSphere Application Server 支持两种即时可用的技术选项：LocalOS 和 LDAP。您可能会发现，从桌面工作站使用任何注册表类型都比较困难。如果这样，最好的替代方法是配置一个自定义文件注册表。IBM 提供了一个适合桌面使用的示例文件注册表。您可以在 WebSphere Application Server 信息中心找到其源代码格式。
作为加强嵌入式应用服务器的替代方法，您可能希望转而选择安装桌面防火墙产品，以阻止对您计算机的访问。如果配置得当，此类方法可能非常有效。信任整个内部企业网络的防火墙在此环境中几乎没有价值。
加强代理控制器
Rational Application Developer 包括一个称为代理控制器的组件，用于对应用服务器进行监视。不过，此工具的缺省配置非常不安全。它会在不进行身份验证的情况下接受来自任何主机的请求。您可以通过此工具读取计算机上的任何文件。首次安装代理控制器时，请将其配置为仅接受来自“这台计算机”的请求，或将其配置为对请求进行验证。如果使用此控制器只是为了监视嵌入式应用服务器（通常情况），请将此控制器配置为仅接受来自“这台计算机”的请求是最好的方法。
如果您已经安装了代理控制器，可以按照如下内容，仅接受本地的请求，从而修复安装。编辑文件 <RAC_INSTALL>\config\serviceconfig.xml，并查找 Hosts 配置节。并进行如下修改：即将
<Hosts configuration="default">
<Allow host="ALL"/>
</Hosts> |
更改为：
<Hosts configuration="default">
<Allow host="LOCAL"/>
</Hosts> |
结束语
这篇由两部分组成的文章涉及到大量的内容。虽然我们将重点放在加强 WebSphere Application Server 环境这一核心主题上，但我们还讨论了有关安全性的很多方面。我们衷心地希望您已经获得了保证 J2EE 系统安全所需的基本信息。虽然我们不在本文中进行关于如何加强基础设施的其他部分的讨论，但您应当从其他信息源查找这些相关信息。WebSphere Application Server 仅相当于冰山一角，更多的东西有待我们进一步去发现。
最后，您可以使用一个称为 IBM Security Scanner for WebSphere Application Server 的自动化工具对本文中所描述的各个项的子集进行检查。
致谢
我要感谢我的同事 Cameron Martin、Bill Hines、Paul Ilechko 和 Tom Alcott 提供的宝贵素材和帮助。我还要感谢 WebSphere Application Server 安全开发团队的成员 Ching-Yun (C.Y.) Chao 和 Peter Birk。
参考资料
关于作者
对本文的评价
| 
