任务:消息

针对 UNIX 和 Windows 的脚本化 WebSphere MQ 密匙文件管理

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 任务:消息

敬请期待该系列的后续内容。

此内容是该系列的一部分:任务:消息

敬请期待该系列的后续内容。

脚本化密匙管理的一个案例研究

我最近进行的一个咨询工作包括一个任务,需要在两个队列管理器之间建立一些 SSL 通道。这个任务的标准操作流程是对几乎所有管理任务使用交互式工具,因此我的客户认为我们将使用 iKeyman GUI 完成钥匙环的创建和所有的证书任务。当我建议使用脚本替代时,他们还有些不愿意。

他们的主要反对理由是管理团队大多都不熟悉脚本工具。他们的潜在意思是,脚本解决方案将会提高管理证书需要的最低技术水平。相比之下,他们认为 GUI 是更容易、更恰当的解决方案。

除此之外,还有一个问题:脚本解决方案能够最有效地利用资源吗?我对我的客户说,与使用 GUI 完成相同的管理任务相比,编写脚本将花费同样多(也许更多)的时间。脚本编写在大型部署中的价值是有目共睹的,但是对于只涉及两个队列管理器的任务,他们认为进行额外投资简直是在浪费时间。

业务需求是促成这个决策的根本因素。由于 MD5 散列法已经被破坏,客户明智地规定,所有密匙必须使用 SHA-1 签名。但 GUI 工具不能公开那些支持选择证书签名算法的控件,因此默认支持 MD5 签名。修改 GUI 中的这个行为需要编辑 iKeyman 和 Java™ 配置文件。相比之下,包括 –sigalg 选项的命令行工具使得选择签名算法变得异常简单。

当我们最终开始工作后,事实证明客户的担忧根本就是杞人忧天。多数脚本都是自我归档的(self-documenting),不需要复杂的逻辑。它们只包含一个经过注释的命令列表,没有任何分支和循环。对于管理员来说,学习脚本并不比学习 GUI 困难,甚至更加容易。而且,我们需要的资源也相当少,因为我的上一个任务的一些脚本正好可以满足我们的需求。

不到三个小时的时间内我们就完成了 SSL 配置,还包括调整脚本和培训执行密匙管理任务的职员。一个月之后,队列管理器迁移到新的服务器并进行了重构。使用一个可重复的、一致的和准确的流程,管理员就能够重用这些脚本,在一个小时之内在新的队列管理器上独自建立 SSL 通道。我们的投资在第一次重用时就得到了回报。

在《任务:消息传递》系列的这个部分,我将和您一起完成使用自签名证书配置基本 SSL 通道的任务,我们将构建两个脚本。这样,当您需要建立 IBM® WebSphere® MQ SSL 通道的时候,您也能够在一小时之内使您的第一个通道配对并运行。

关于证书类型

使用 CA 签名的证书配置 SSL 与使用自签名证书类似,但创建的安全策略差别很大。

创建自签名证书时,也就创建了一个 Deny-All 策略。添加到密匙环的每一个证书都是这个策略的一个例外。授权访问需要添加一个证书。撤销访问需要删除一个证书。使用自签名证书,MQ 管理员必须采取特定的动作对一个给定的证书进行授权访问。所有访问控制决策取决于管理员。

使用由 CA 签名的证书时,一个有效的策略就是针对每个信任的 CA(认证机构)使用 Allow-All 策略。换句话说,对一个密匙环添加一个 CA 将对那个 CA 已经签名的或未来即将签名的每个证书建立一个信任策略。限制信任范围需要使用通道的 SSLPEER 属性为这个证书中的 Distinguished Name(DN,可分辨名称)字段指定可以接受的值。撤销访问需要一个 Certificate Revocation List(简称为 CRL)。当一个 CA 撤销一个证书时,撤销操作被发布给 CRL。那个 CA 的客户在内部对 CRL 执行镜像,队列管理员可以在通道启动时在内部检查这个 CRL。如果一个通道企图使用一个已撤销的证书启动,对 CRL 的本地副本的检查将生成一个错误,这个连接将被拒绝。

使用由 CA 签名的证书时,MQ 管理员只控制允许连接的 Distinguished Names (DN) 的字符串匹配模板。CA 发出的带有匹配 DN 值的任何新的证书都能够进行连接。阻止这种操作的惟一可用控件就是 CRL。使用由 CA 签名的证书时,必须维护 CRL,因为它是排除已损坏证书的惟一方法。

许多关于 SSL 的讨论都提到要根据成本或涉及的流程来选择证书类型。通常,这种方法将原型化自签名证书(因为它们可以轻松地免费生成),然后在后续阶段切换为由 CA 签名的证书。实际上,证书类型的选择应该基于理想的安全策略和企业是否准备好建立和维护一个证书撤销列表。从安全角度讲,最好先使用一个 Deny-All 策略然后再授权例外,而不是先使用一个 Allow-All 策略然后再构建一个黑名单。基于上述原因,我倾向于使用自签名证书,这也是本文将讨论的证书。

流程概述

根据本文的目的,我将使用两个队列管理器,我把它们称为 QMA 和 QMB。在较高的层次上,使用自签名证书构建一个新的 WebSphere MQ SSL 配置需要以下步骤:

  1. 为 QMA 创建一个默认的密匙环。
  2. 从这个密匙环删除默认 CA 证书。
  3. 为 QMA 生成一个自签名证书。
  4. 提取这个新证书的公共密匙。
  5. 对 QMB 重复 1-4 步。
  6. 将 QMB 的公共密匙导入 QMA 的密匙环。
  7. 发出 QMA 上的 REFRESH SECURITY TYPE (SSL)。
  8. 对 QMB 重复 6-7 步。

步骤 1-4 是任何新的队列管理器的必要步骤,也是一个单一脚本的自然选择。尽管步骤 6-7 可以写入脚本,但有时候会出现这种情况 —— 必须将许多公共密匙导入一个密匙环,但在每个公共密匙之后发送一个 REFRESH SECURITY 未必是一个好主意。因此,步骤 6 应该是一个单独的脚本。我们将编写文档说明发送 REFRESH SECURITY 命令的条件,该命令可以根据您的喜好从命令行或您钟爱的管理工具运行。但这主要是一个个人偏好问题,因此如果您愿意,可以将 REFRESH SECURITY 添加为第二个脚本的最后一步。进入脚本之后,还有几个细节问题,我将在后面进行介绍。

公共脚本头部

尽管本文只涉及密匙和证书管理任务中的很小的一块内容,但脚本编写的目的是创建可以重用的工具。因此,每个脚本将包括一个头部,您将在这个头部中设置执行命令所需的任何变量。

重用性还会影响到您将要处理密匙环文件的位置。对于一次性使用,可以更容易地在一个本地临时目录中构建密匙环,生成并交换证书,然后将完成的密匙环文件移动到它们的最终目标位置。但是您不可能在每次需要添加一个证书的时候从头开始生成一个新的密匙环,除非您拥有一个安全的部署服务器和一些真正好的自动化,否则维护一个中央密匙环资源库并在执行维护任务之后将这些密匙环推送到您的队列管理器是不切实际的。要使脚本可重复使用,您的脚本需要在密匙环实际使用的地方操纵密匙环。这需要您将几个文件和路径元素嵌入到您的公共脚本头部中。下面就让我们来研究一下这些内容。

因为将队列管理器的名称包含在证书的 Common Name 字段中是一个惯例,您需要一个变量来持有它:

QMGRNAME=QMA

要完成证书的可分辨名称,通常需要一个域:

DOMAIN=us.ibm.com

您还需要几个组织和地址字段。我把这些内容组合到一起形成一个变量,称为 ORG:

ORG=O=IBM,OU=ISSW,OU=PROD,OU=ADMIN,L=Charlotte,ST=NC,C=US

证书标签需要队列管理器名称的小写版本。队列管理器将搜寻这个小写版本,以便它能够找到在 SSL 协议期间将显示的证书。

FOLDEDNAME=qma

您还需要知道队列管理器在文件系统中的位置。WebSphere MQ 将改变某些字符,以便创建平台可移植的文件名。例如,如果一个队列管理器名称包含一个圆点字符,则该字符将被转换为一个感叹号。如果您的队列管理器名称包含任何非字母数字的字符,您需要检查文件系统以查找被改变的名称并在这里设置该值:

MANGLEDNAME=QMA

脚本应该可用于非标准安装,特别是队列管理器是在一个高可用性硬件集群上实现的时候。PATH2QMGR 变量用于保存这个位置。

PATH2QMGR=/var/mqm/qmgrs

Windows® 系统上的同一个变量将拥有这个值(假设一个默认安装):

PATH2QMGR=C:\Program Files\IBM\WebSphere MQ

密匙环的密码作为一个用户可编辑的环境变量存储在脚本中。确保不要将存储有密码的脚本随意放置。保存和运行这个脚本的好地方是队列管理器的 SSL 目录。这个目录必须保护起来,以便只有 mqm(或其他平台上的等同物)用户 ID 能够读取这些文件。由于密匙数据库密码隐藏在这里,将脚本存储在这里也不会暴露。

PASSWORD=qK2EkyBmWU

密码期限只使用一次,但是我喜欢为它创建一个变量,并将变量与其他的用户可编辑字段放置在一起。这向脚本操作员表明,一个策略决策是在这里捕获的。这个值以天为单位,我为这个示例指定了 10 年的期限。

EXPIRY=3650

我们将在这里使用的命令是 GSKit C API 命令而不是 Java 实现。这是因为 C 版本在命令行上显示的一些选项在 Java 版本中不可用。使用 C 版本还有另外一个附带的好处,C 可执行文件的执行速度要比 Java 快得多,因为 Java 版本必须为每个命令调用构建并拆除一个 JVM。基于 C 语言的整个脚本的运行时间与在 Java 版本中执行单个命令的时间相当。要执行文件,脚本只需知道 C 二进制文件的路径。对于 UNIX® 系统,默认的位置位于 /opt 中:

PATH=/opt/IBM/gskit/bin:/opt/IBM/gskit/lib:$PATH

在 Windows 系统上,这个默认位置位于 C: 驱动器上:

PATH=C:\Program Files\IBM\gsk7\bin:C:\Program Files\IBM\gsk7\lib:%PATH%

这是最后一个用户可编辑变量。然而在运行任何命令之前,您必须告知脚本密匙环文件的名称。这个名称通过结合使用默认的 WebSphere MQ 设置和前面步骤中输入的变量构建。对于 UNIX 和 Windows,这些变量分别是:

MQSSLDB=$PATH2QMGR/$MANGLEDNAME/ssl/key.kdb

MQSSLDB=%PATH2QMGR%\%MANGLEDNAME%\ssl\key.kdb

这些位置是默认的,应该在队列管理器的 SSLKEYR 属性中显示。如果选择了另一个位置,一定要相应更新队列管理器。

上面的设置可以用于任何证书管理脚本。尽管一些命令调用需要不同的或其他参数,但是实现是相同的:将用户可编辑的变量全部放置到最前面,在那里可以将它们作为一个集合来管理。

创建密匙环并删除默认的 CA 条目

下一步是生成默认状态的密匙环,这需要一个单一 gsk7capicmd 命令调用:

gsk7capicmd -keydb -create -db "$MQSSLDB" -pw $PASSWORD -type cms -expire $EXPIRY -stash -fips

地点:

  • 第一个 gsk7capicmd 参数是需要执行的操作类型,这里是密匙数据库操作。
  • 第二个参数始终为要在这个操作类型中执行的动作。这里,我们打算创建一个新的密匙数据库,该数据库通过完全限定的 –db 选项指定。
  • 数据库类型指定为 cms,因为队列管理器需要这种类型。
  • –stash 选项创建一个带有密码的隐藏文件。这是队列管理器在没有人类干预的情况下访问密匙数据库的方式。
  • 最后指定的选项是 –fips。该选项不仅生成一个与 Federal Information Processing Security (FIPS) 标准兼容的密匙数据库,它还确保在运行命令时使用的库和算法是 FIPS 兼容的。我不知道指定使用与 FIPS 兼容的命令有什么负面影响,但是这种命令的确有一点好处:它们已经各自经过了认证。除非可以充分地证明不应在所有情况使用它们,否则我的策略就是总是指定 FIPS。

密匙环刚刚创建时,它将使用几个默认的 CA 签名者证书加载。目前,这些证书包括来自 Entrust、Verisign、Thawte 和 RSA 的根证书。如前所述,这些根证书的出现将为 CA 已经发送或将来即将发送的每个证书创建一个 Allow-All 策略。因为我们现在只使用自签名证书,所有这些根证书代表对我们的队列管理器的不恰当的访问授权。因此,下一步就是删除所有这些默认的 CA 证书。

证书列表随着时间而改变。这里使用的特定证书来自 V6.0 队列管理器。根据您的版本和补丁包的不同,您看到的这个列表可能有些不同。为了确保所有的 CA 证书已被删除,您需要将一个显示密匙环中的所有证书的命令添加到脚本末尾。

删除一个证书的命令如下所示:

gsk7capicmd -cert -delete -label "Entrust.net Global Secure Server Certification Authority" -db "$MQSSLDB" -pw $PASSWORD -fips

–label 选项通过一个人类可读的字符串识别证书。这个标签在一个密匙环内必须是惟一的,它在证书创建或导入时设置。同一个证书在不同的密匙环中可能有不同的标签。在这个示例中,这个标签识别将要删除的特定证书。

我在这里只列举了一个示例。这个 完整脚本列表 包含 24 个其他命令,这些命令删除各种供应商的根证书和中间证书。

生成本地队列管理器的证书

下一步是为本地队列管理器生成新的证书。队列管理器根据标签定位它的证书,标签必须总是由固定字符串 ibmwebspheremq 加上队列管理器的小写名称组成。在下面的示例中,这个标签的组成方式为连接标签的固定部分和在脚本头部中设置的 $FOLDEDNAME 变量:

gsk7capicmd -cert -create -db "$MQSSLDB" -pw $PASSWORD -label "ibmwebspheremq$FOLDEDNAME" -dn "CN=$QMGRNAME.$DOMAIN,$ORG" -fips

这个命令引入了另一个新选项 —— 证书的可分辨名称(Distinguished Name),缩写为 DN。这个 DN 是一个全局惟一的名称,代表由证书表示的实体。它包含几个子字段:

  • CN=公共名称
  • O=组织
  • OU=组织单位
  • L=位置
  • ST=州,省
  • C=国家

这里应该注意的是,“全局惟一” 是针对每个发布者而言的。两个或多个证书机构使用相同的 DN 元素是完全有效的。对于自签名证书这种情况,每个证书都是自己的根证书,全局惟一性的惟一实施办法就是您围绕用来发布和管理证书的人工流程构建的控件。

队列管理器的公共名称通常是队列管理器名称加上其驻留的域名。例如,QMA.us.ibm.com 就是我们的 QMA 队列管理器的一个有效 CN。一个证书可能包含多个组织单位(Organization Unit,OU)条目。仔细选择 OU 命名方式有助于创建有意义的 SSLPEER 值。例如,如果一个 OU 条目是 PROD 或 DEV,那么可以创建一个 SSLPEER,阻止在生产和开发队列管理器之间进行相互连接。(这个通道的 SSLPEER 属性和可分辨名称已在一月份的《任务:消息传递》 在 WebSphere MQ 网络上进行 SSL 规划 中详细讨论过)。

提取新的证书

为了使新的证书在一个 SSL 协议中有用,远程队列管理器必须访问该证书的公共密匙。为此,需要将这个证书提取到一个文件,将文件复制到远程节点,然后将它导入到驻留在那里的密匙环。提取证书将是当前脚本的最后一批任务之一,然后您将构建第二个脚本,以将证书文件导入到远程密匙环中。

提取证书的命令是:

gsk7capicmd -cert -extract -db "$MQSSLDB" -pw $PASSWORD -label "ibmwebspheremq$FOLDEDNAME" -target $PATH2QMGR/$MANGLEDNAME/ssl/$FOLDEDNAME.crt -format ascii -fips

这里,您对密匙环、证书标签和密码重用了之前的值。–target 选项识别包含提取的证书的文件的名称和位置。文件名中的 .crt 扩展名匹配 –format ascii 选项,并将使您能够稍后导入证书。

整理

到此,脚本工作结束,操作员需要验证结果。您需要显示密匙环中的证书并要求操作员确定没有默认的 CA 证书保留下来。这个步骤的目的是为了捕获不同的 GSKit 发行版之间的更改,GSKit 将更新默认证书的清单。

gsk7capicmd -cert -list -db "$MQSSLDB" -pw $PASSWORD -fips

第二个脚本:将证书添加到密匙环

最后一步是在 QMA 和 QMB 之间交换证书。您将构建第二个脚本,该脚本将读取先前创建的那个 .crt 文件并将它添加到一个队列管理器的密匙环。这个脚本的前面部分将重用您之前使用的多个变量。惟一的区别是 $FOLDEDNAME 变量现在引用远程队列管理器而不是本地队列管理器。将证书添加到密匙环的命令是:

gsk7capicmd -cert -add -db "$MQSSLDB" -pw $PASSWORD -label "ibmwebspheremq$FOLDEDNAME" -file $FOLDEDNAME.crt -format ascii –fips

注意,这个脚本期望文件名匹配队列管理器的小写名称且文件位于当前目录中。它还使用相同的标准证书标签,尽管这不是必须的。WebSphere MQ 只在需要队列管理器定位自己的证书时要求标签使用特定的格式。我选择使用相同的标签表示所有密匙环中的特定证书,因为一致性有助于管理员更容易地识别和管理证书。

和第一个脚本一样,密匙环的内容被显示出来以确认操作已经成功完成。

结束语

本文提供的脚本 是连接两个队列管理器所需的最少脚本示例。设计思想如下:第一个脚本可以在任何队列管理器上重用以初次创建密匙环。第二个脚本可以重复用于从任何远程 MQ 节点添加证书。这两个脚本中的命令足够用于连接一个任意大小的网络。

当然,通过替换脚本中的适当命令,可以从这些示例轻松构建其他脚本。在您尝试创建自己的脚本时,建议您包含一个删除证书的脚本,一个列出密匙环内容的独立脚本,以及一个打印任意证书细节的脚本。最后,您可能需要一个脚本来更改密匙数据库的密码,具体情况取决于您的公司的密码有效期限。所有这些脚本都可以通过对现有的某个脚本进行少许修改而创建。

我使用的脚本故意保持了简单性。只需少许工作,脚本中的许多字段都可以从队列管理器的 ini 文件和 Windows 的注册表中获取和解析。但作为一名顾问,我需要能够在尽可能广泛的环境中使用的工具,这些工具不能够进行太多的假设。如果您拥有一个固定的职位,您可能想花点时间使您的脚本更易用、更健壮。您可以考虑添加一些改进措施,比如包含一些逻辑以解析文件系统中的队列管理器的位置等信息,或者实现更好的错误处理能力。用户输入的内容越少,导致人工错误的可能性就越低。诊断性能越好,操作员错过一条错误信息并继续使用一个错误的密匙环的机会就越少。我将乐于在 t-rob.net 上讨论您遇到的任何问题,如果您愿意与我分享的话。

但是,无论您使用简单的脚本还是增强的脚本,自动化都将帮助您快速、轻松和一致地实现 SSL。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, Information Management
ArticleID=422458
ArticleTitle=任务:消息: 针对 UNIX 和 Windows 的脚本化 WebSphere MQ 密匙文件管理
publish-date=08262009