如果使用一个自定义注册表，您一定想要使用所提供的机制保护此通信流。
要对 Liberty 配置文件启用 LDAP SSL，可将一些元素包含在服务器的 server.xml 中，类似于清单 3 中加粗的元素示例。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<featureManager> <feature>ssl-1.0</feature> </featureManager> <ssl id=”ldapSSLConfig” keyStoreRef=”ldapTrustStore” trustStoreRef=”ldapTrustStore”/><keyStore id=”ldapTrustStore” location=”ldapTrustStore.jks” type=”JKS” password=”123456″ /> <ldapRegistry id=”IBMDiretoryServerLDAP” realm=”SampleLdapIDSRealm” host=”host.domain.com” port=”389″ ignoreCase=”true” baseDN=”o=domain,c=us” ldapType=”IBM Tivoli Directory Server” idsFilters=”myidsfilters” sslEnabled=”true” sslRef=”ldapSSLConfig” /> |
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 发送。
图 8. 将 LTPA cookie 限制为只使用 SSL
要在 Liberty 配置文件中将 LTPA cookie 限制为仅使用 SSL，可以将一个 webAppSecurity 元素包含在服务器的 server.xml 文件中，该文件还包含 ssoRequiresSSL 属性，如清单 4 中的示例所示。
清单 4. 在 Liberty 中启用应用程序安全性
|
1 |
<webAppSecurity ssoRequiresSSL=’true’/> |
通过在会话管理面板上指定相似的设置，还可以将 HTTP Session（默认情况下是 JSESSION） cookie 限制为只使用 SSL。
要在 Liberty 配置文件中将 HTTP Session cookie 限制为仅使用 SSL，可将一个 httpSession 元素包含在服务器的 server.xml 中，该文件还包含 cookieSecure 属性，如清单 5 中的示例所示。
清单 5. 在 Liberty 中启用 HTTP Session cookie SSL
|
1 |
<httpSession cookieSecure=’true’/> |
警告：在安装修复包 7.0.0.9 之前，Requires SSL 标志在 WebSphere Application Server V7 中无效。一定要安装它。
20. 确保定期改变 LTPA 加密密钥
WebSphere Application Server 使用 LTPA 加密密钥加密各种用户令牌（包括 LTPA cookie）。与任何密码术密钥一样，应该定期改变这些密钥。根据 WebSphere Application Server 和补丁级别不同，可能在默认情况下启用了自动密钥生成，也可能关闭了该功能；版本越新，默认情况下它关闭的可能性就越大。为了避免可能的宕机，请确保此功能已关闭，如图 9 所示。
在首次对某个 Liberty 服务器启用安全性时，会生成 LTPA 密钥。
应该确保会定期更改 LTPA 加密密钥。对于完整配置文件，可以启用自动 LTPA 密钥替换（参见图 9），也可以手工地重新生成密钥（参见图 10），或者通过 AdminTask.generateKeyForKeySetGroup 命令执行。
对于 Liberty 配置文件，可以创建一个新配置文件，启用安全性，启动服务器，然后复制新生成的 ${server.config.dir}/resources/security/ltpa.keys 文件。
一定要考虑 LTPA 密钥不一致的问题：
首先，如果计算单元中的某些节点在一段时间内一直停机（而且密钥更改两次），那么它们可能会丧失通信能力。
第二，如果与其他组件（比如另一个计算单元或 WebSphere DataPower）共享 LTPA 密钥，那么在更改密钥时，需要在所有地方更新它们，这通常会造成停机。
因此，可以规划在计划的宕机期间更改您的 LTPA 密钥。将新密钥分发给计算单元中的所有节点，并在这个宕机窗口中将新密钥分发给所有外部系统/计算单元。
图 9. 不启用自动 LTPA 密钥更新
图 10. 手工生成新的 LTPA 密钥
21. 不要在命令行上指定密码
一旦启用了安全性，WebSphere Application Server 管理工具就会要求您仅在通过身份验证的情况下使用它。执行身份验证的明确方法是在命令行中指定用户 ID 和密码，将其作为参数传递给该工具。请不要这样做。这会向在您身边窥探的任何人暴露您的管理密码。而且在许多操作系统中，任何可以看到进程列表的人都可以看到命令行上的参数。另外，以前的命令可在命令历史中看到，包括密码参数。相反，应该确保通过管理工具提示输入用户 ID 和密码。请注意，在所有当前支持的 WebSphere Application Server 版本中，这是默认设置，所以无需执行任何显式操作来确保发生此行为。
如果觉得命令行工具以图形方式提示输入用户 ID 和密码非常烦人，可以改变此行为，让工具使用基于文本的简单提示。要实现这一点，应该通过编辑适当的配置文件，将 loginSource 从 prompt 更改为 stdin。在默认情况下，管理工具使用 SOAP，因此应该编辑 soap.client.props 文件。如果使用的是 RMI，则编辑 sas.client.props。请在适当的文件中查找 loginSource 属性，并更改它以指定 stdin。
这一项不适用于 V8.5 中的 Liberty 配置文件。
22. 考虑在基于文件的 Federated Repository 注册表中增加附加数据
如果在使用 Federated Repository 注册表的同时还使用了该注册表中内置的文件存储库，那么该注册表中的用户会将他们的用户 ID 和密码存储在计算单元 config 目录中的 fileregistry.xml 文件中。这些密码经过了单向哈希计算，这意味着您无法从哈希值获得实际的密码。哈希值可借助一些密码学上的附加数据来计算。在 WebSphere Application Server V8.0 和 8.5 中，可以指定附加数据的长度和使用的哈希算法。此文件应由 OS 定义的访问控制列表来保护，以便只有特权 OS 用户才能读取该文件。要预防通过彩虹表的密码破解攻击，可以考虑增加附加数据量或使用更强的哈希函数。
这一项不适用于 V8.5 中的 Liberty 配置文件。
23. 考虑为生成的证书使用更长的密钥长度
在 WebSphere Application Server V8.0 中，生成的证书所使用的默认密钥长度从 1024 更改为 2048。从 V7.0 开始，在通过 wsadmin 生成密钥时，可指定比 1024 更长的密钥长度。从 V8.0 开始，管理控制台（图 11）
支持选择密钥长度。
这一项不适用于 V8.5 中的 Liberty 配置文件。
图 11. 在管理控制台中选择密钥长度
支持的密钥长度范围为 512-16384（必须是 8 的倍数）。
这一项不适用于 V8.5 中的 Liberty 配置文件。
24. 创建单独的管理用户 ID
主管理 ID 与用于服务器到服务器通信的安全服务器 ID 并不相同。从 V6.1 开始，注册表中不再需要具有这个身份，甚至不必有相关联的密码。它在默认情况下只用于内部通信。如果需要的话，可以指定服务器 ID 和密码，但是不建议这么做，除非绝对必要——比如使用包含不同版本的计算单元（包括 V6.0 和更低版本），或者涉及 V6.0 或更低版本的跨计算单元 SSO。
当为 WebSphere Application Server V6.1 和更高版本配置安全性时（Liberty 配置文件除外），在开始时会配置一个主管理 ID（参见边栏）。这个 ID 实际上等同于 WebSphere Application Server 中的 root 用户，它能够执行任何管理操作（包括下一节提到的所有管理角色）。由于这个 ID 很重要，所以最好不要随便共享其密码。理想情况下，在最初配置之后不应该再使用这个 ID。出于安全原因，在 V8.5 中，默认情况下并未启用 Liberty 配置文件。
与大多数系统一样，WebSphere Application Server 允许多个主体担任管理员。只需使用管理应用程序并进入系统管理控制台用户（或用户组）部分，指定应该授予管理权限的其他用户或用户组。在进行这样的授权之后，当管理 WebSphere Application Server 时，每个人都可以以自己的身份进行身份验证。会导致更改 WebSphere Application Server 配置的所有管理操作都需要经过部署管理器的审核，包括执行更改的主体的身份。从 V7 开始，引入了一个新的审计框架，它可以提供更详细的管理操作审计信息。显然，如果每个管理员有单独的身份，这些审计记录会更有用。
在由中心管理员管理多个 WebSphere Application Server 计算单元的环境中，为每个管理员授予单独的管理访问权限会非常方便。虽然每个计算单元都有自己的本地 “根” ID 和密码，但是可以配置所有这些计算单元来共享公共注册表，这样管理员就可以使用相同的 ID 和密码来管理每个计算单元。
25. 利用管理角色
根据版本不同，WebSphere Application Server 的完整（非 Liberty 配置文件）允许采用不同的管理角色：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 角色本身没有这个权限。现在，可以向用户授予
以下文章点击率最高
Loading…