3. 必须在 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 声明这个证书不再可信。为了让证书撤消起作用，证书的接受者必须检查它是否仍然有效。许多人忽视了这一点。如果不适当地支持撤消，那么使用证书执行身份验证是很愚蠢的。有多种技术可供使用（这里不再详细讨论）；简单地说，您可以选用以下技术：
o Online Certificate Status Protocol (OCSP)。
o Certificate Revocation List，可以通过证书中嵌入的端点或分发点信息找到这个列表。
o 如果证书数量很少，那么只需颁发自签名证书即可。只需删除相应的签署者，就可以撤消证书。
WebSphere Application Server 支持所有这些技术，但是都需要配置。一定要执行相应的配置步骤。Liberty 配置文件不支持 OCSP 或 Certificate Revocation List。
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 容器设置为忽略来自客户端的证书头
要将 Liberty Web 容器配置为忽略来自客户端的证书头，可将 webcontainer 信任元素包含在配置文件的 server.xml 文件中，如清单 2 所示。
清单 2. 在 Liberty 中忽略来自客户端的证书头
|
1 |
<webcontainer trusted=’false’/> |
如果目标是支持向 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 信息中心。
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 隧道技巧或者确认前一节中提及的直接 SSL 对等方来限制具有访问权限的群体。具体地说，需要执行以下操作：
1. 为 Web 容器创建一个密钥存储库和信任存储库，为 Web 服务器插件创建一个密钥存储库。
2. 从所有密钥存储库（包括信任存储库）删除所有现有的签名证书。此时，不能使用任何密钥存储库来检验证书。这样做是有意的。
3. 在这两个密钥存储库中创建自签名证书，并只导出该证书（而不是私钥）。一定要记录这些证书的到期时间。当插件证书到期之后，它就不能再联系 Web 容器了！将从 Web 容器密钥存储库中导出的证书导入插件密钥存储库中。将插件证书导入到 Web 容器信任存储库中。现在，每一端都只包含一个签名证书。这意味着只能使用它们检验一个证书——为对方创建的自签名证书。
4. 将新创建的密钥存储库安装到 Web 容器和 Web 服务器插件中。
15. 不要在生产环境中运行示例
WebSphere Application Server 附带了几个非常好的示例，它们演示了 WebSphere Application Server 的各个部分。这些示例不是为在生产环境中使用而准备的。不要在生产环境中运行它们，因为它们会带来严重的安全风险。特别是 snoop Servlet 会向外部人员提供大量关于您的系统的信息。这正是您不希望潜在的入侵者获得的信息。只要不在生产环境中运行 server1（它默认包含这些示例），不在配置文件创建期间安装这些示例，或者从 server1 卸载示例应用程序，就很容易解决这个问题。
16. 选择合适的进程身份
WebSphere Application Server 进程是在操作系统上运行的，因此必须在某个操作系统身份下运行。有三种运行 WebSphere Application Server 的方式与操作系统身份有关：
以 root 身份运行一切程序。
以单一用户身份（例如 “was”）运行一切程序。
以 root 身份运行节点代理，以应用服务器自己的身份运行各个应用服务器。
IBM 测试过并完全支持前面两种方法。第三种方法看似很有吸引力，因为那样就可以利用操作系统权限，但它在实践中不是十分奏效，主要具有以下几个原因：
配置它非常困难，而且配置过程没有文档说明。许多 WebSphere Application Server 进程都需要对无数文件具有读访问权限，并对 log 和 transaction 目录具有写访问权限。
通过以 root 身份运行节点代理，实际上会向 WebSphere Application Server 管理员和在 WebSphere Application Server 中运行的任何应用程序授予 root 权限。这可能包含一个 Generic Server，它是一个非 WebSphere Application Server 进程。这可能是一个 Java 或原生可执行文件，将以 root 身份运行。
这种方法的主要价值在于控制应用程序对文件系统的访问。但是，使用 Java 2 权限也可以实现这一点。
这种方法会造成应用程序互相隔离的错觉。其实不是。WebSphere Application Server 内部安全模型基于 J2EE 和 Java 2 安全性，不受操作系统权限的影响。因此，如果选择使用这种方法来保护自己免受 “恶意” 应用程序的侵害，那么方法的方向可能弄错了。
第一种方法明显是不可取的，因为作为一般的最佳实践，如果可以的话，最好避免以 root 身份运行任何进程。这样就只剩下第二种方法，它是完全受支持的。在某些很少见的情况下，可能并不关心应用程序隔离，但是希望以不同的操作系统身份运行应用程序以便进行审计，那么可以使用第三种方法。从安全性的角度来看，这没有什么价值，而且实际上会略微增加风险，但是有可能使用操作系统级审计。
17. 保护配置文件和私钥
对于限制权限也不要过于极端。我们见过非常多这种情况：在开发期间，甚至不允许开发人员查看应用服务器日志文件。这种极端做法完全没有必要。当然，在生产期间，应该尽可能地保护 WebSphere Application Server。但是，在开发期间，没有必要实现最大的安全性，这会影响开发人员的生产力。
应该利用操作系统文件权限来限制对 WebSphere Application Server 文件的文件系统访问。与任何复杂的系统一样，WebSphere Application Server 使用和维护大量敏感信息。一般来讲，不应该有人对大多数 WebSphere Application Server 信息具有读或写权限（参见边栏）。特别是 WebSphere Application Server 配置文件 (<root>/config)，它既包含配置信息，也包含密码。
Password encryption for WebSphere 安全文件的密码加密
在 WebSphere Application Server V6.0.2 之前，即使不喜欢 WebSphere Application Server 为 J2C 资源存储密码的方式，您通常也是无能为力。您可以编写自己的自定义 J2C 登录模块，从 WebSphere Application Server 外部的来源获取密码，但这对 WebSphere Application Server 使用的其他密码没有帮助：LDAP 绑定、WebSphere Application Server 管理员等。
WebSphere Application Server V6.0.2 引入了一个接口，您可在其中实际地配置您自己的自定义密码编码器，可实现您认为合适的保护。为此，需要实现插件接口 (com.ibm.wsspi.security.crypto.CustomPasswordEncryption)，然后在 security.xml 中指定两个自定义安全属性。也可以在 PropFilePasswordEncoder.bat/sh 中设置这些属性。这两个属性是：
com.ibm.wsspi.security.crypto.
customPasswordEncryptionClass
com.ibm.wsspi.security.crypto.
customPasswordEncryptionEnabled.
有关的更多信息，请参阅信息中心文章 自定义密码加密的插入点。
尽管如此，我并不相信加密这些 WebSphere Application Server 密码会在编码的基础上提供任何有意义的保护。密码编码的设计目标是预防意外泄漏；例如，某个在后面偷窥的人可在一个文件中看到明文密码。另一方面，如果某人访问包含密码的文件，编码和加密都无法避免此人访问该密码。再一次声明，任何具有对加密的密码的文件访问权的人也能够访问原始密码。这是因为用于加密的密钥/证书必须存储在文件系统上，以便 WebSphere Application Server 进程能够在需要时解密密码，并将它发送到任何需要的地方。因此，任何能够访问文件系统的人都能访问包含（加密的）密码和密钥的文件，然后使用这些信息来解密密码。
另外，应该注意避免不小心共享密钥。例如，不要在生产环境中使用与其他环境中相同的密钥。许多人对开发和测试计算机及他们自己的密钥具有访问权限。应该谨慎地保护生产环境所用的密钥。
如果不谨慎地控制谁对文件系统有写访问权限，那么用户只需手工编辑配置文件，就可以破坏产品的安全控制（比如审计）。
18. 加密从 WebSphere Application Server 到 LDAP 的链接
在使用 LDAP 注册表时，WebSphere Application Server 会使用标准的 ldap_bind 来验证用户密码。这要求 WebSphere Application Server 将用户密码发送给 LDAP 服务器。如果该请求没有加密，那么黑客可以使用网络嗅探器来窃取用于身份验证的用户密码（包括管理密码！）。大多数 LDAP 目录都支持 LDAP over SSL，并且可以将 WebSphere Application Server 配置为使用 LDAP over SSL。在 LDAP 用户注册表面板中（请参见图 7），选中 use SSL enabled 选项，然后配置适合您的 LDAP 目录的 SSL 配置。很可能需要将用于 LDAP 服务器证书的签名密钥（证书）放在信任的存储库中。最好是创建只供 LDAP 使用的新的 SSL 配置，以避免给当前使用 SSL 的其他领域造成问题。
图 7. 启用 LDAP SSL
以下文章点击率最高
Loading…