在WebSphere MQ 網路上規劃 SSL

T.Rob Wyatt, 高階管理顧問, IBM

在每個專欄中，“任務：訊息”討論的主題旨在鼓勵您重新檢查您對 IBM® WebSphere® MQ 及其在您的環境中的作用的看法，以及為什麼您應該定期注意它。

讓您的解決方案精益求精

這個月，我在這裡就您的 New Year 解決方案向你們提供一些幫助——當然，假定您的解決方案是在訊息傳遞網路上啟用 SSL。

隨著啟用 SSL 的商店數量的增加，我也有機會接觸許多實現了 SSL 的 WebSphere MQ 管理員，而且我注意到了以下兩種傾向：

• 第一種傾向是，雖然要檢查 SSL 配置以確保它們允許預期的連線，但是沒有足夠的檢查來確保這些連線僅是可以接受的連線。結果，許多這樣的配置會不知不覺地允許遠遠超過預期數量的連線，甚至會達到允許匿名連線的程度。
• 我注意到的第二種傾向是，許多 SSL 配置允許不適當的管理訪問權，這通常是因為不知道如何將 SSL 身份驗證應用於 WebSphere MQ API 呼叫。

本文將重點解決這兩個問題，因此，如果您剛開始實現 SSL，本文也許可以幫助您避免這些缺陷。如果您已經部署了 SSL，您可能會發現這裡的一些建議可幫助您進行嚴密的部署。

為什麼使用 SSL？

安全套接字層（通常被稱為 SSL）可提供以下三種服務：

• 使用加密提供機密性。如果有竊聽者捕獲到了流經網路的訊息，則加密可以確保無法（或者其代價高得不可接受）將該資料轉換為可用的純文字。在 WebSphere MQ 中有許多不同的加密型別，它們使用各種演算法和金鑰長度。甚至還可能在無任何加密的通道中啟用 SSL。
• 通過將訊息進行雜湊處理提供完整性。雜湊非常類似於指紋，通過構建雜湊演算法，即使是源中的最小更改也會產生完全不同和不可預知的雜湊值。當訊息到達其目的地時，雜湊可以在一定程度上保證該訊息不被篡改。完整性功能不是可選功能。當針對 WebSphere MQ 通道啟用 SSL 時，該通道上的所有訊息都會被雜湊處理和驗證。
• SSL 中使用的證書包含標識資訊，並被壓縮在一個加密的信封中以防篡改。該證書的標識資訊是 SSL 身份驗證的基礎。在 WebSphere MQ 通道啟動之前 SSL 協議使用自己的訊息交換方式，正是在此 SSL 握手期間進行伺服器（也可以是客戶端）身份驗證。在此情況下，“客戶端”用於啟動連線。它可以是連線到 WebSphere MQ 客戶端通道的應用程式或使用者，也可以是其他佇列管理器。類似地，在此上下文中是“伺服器”用於接收該連線請求。

但是，基於 SSL 證書進行身份驗證究竟意味著什麼？理解該問題答案的關鍵是使用 SSL 構建有意義安全性的關鍵。

已通過身份驗證：SSL 定義

佇列管理器有一個在進行 SSL 交換期間使用的證書資料庫。該資料庫有一部分稱為金鑰儲存區，它包含用於對要傳送的資料進行簽名的所有證書。該佇列管理器與必須在金鑰儲存區中提供的單一證書關聯。金鑰資料庫中的另一部分是信任儲存區，它包含由該佇列管理器信任的資料的所有公鑰。當建立該資料庫時，該信任儲存區由商業證書頒發機構提供的一套預設金鑰填充。目前，這些證書頒發機構包括 Entrust、Verisign、Thawte 和 RSA。

當提供證書時，用來進行身份驗證的條件非常簡單：該證書是否已由信任儲存區中的證書頒發機構簽過名？如果已簽名，則接受該證書，且該部分的 SSL 交換即告完成。

假定證書示例是由商業證書頒發機構頒發的。證書的完整性是使用雜湊演算法校驗的。接下來，檢查簽名 CA 的證書是否存在於本地信任儲存區中。如果是，則候選證書將被接受。注意，不必提前儲存候選證書的副本。只有給所提供證書籤名的機構是受信任機構時才需要。

就其本身而言，在 WebSphere MQ 上下文中並不是十分有用。由預設的商業 CA 之一簽名的任何證書都會被接受，從所有實際用途來看，這意味著任何人都可以進行連線。幸運的是，WebSphere MQ 提供了一些附加工具，它們縮小了可以連線的範圍。

過濾不需要的連線

證書包含幾種型別的標識資訊，其中一項就是專有名稱，即 DN。該名稱的專有性在於任何來自同一 CA 的兩個證書都沒有相同的標識。來自給定證書頒發機構的每個證書都是唯一的。此外，著名的證書頒發機構需要先驗證請求者的身份，然後才會頒發證書。CA 部分的這些前期工作提供了信任繫結到該證書的標識的基礎。該證書中的標識還被設計為計算機可讀形式。WebSphere MQ 將利用三種特徵——唯一性、可依賴性和計算機可分析性——來提供過濾機制。

DN 包含幾個欄位，其中包括通用名 (CN)、組織 (O)、組織單位 (OU) 和國家/地區 (C)。（還有更多，但是，為便於閱讀，所舉示例中僅應用這些欄位。）CN 欄位通常包括伺服器或佇列管理器名稱。O 欄位包括向其頒發證書的公司。一個或多個 OU 欄位包括公司中的限定符，如分支或業務部門。有效 DN 將如下所示：

DN="CN=VENUS,OU=ISSW,O=IBM,C=US"

通道的 SSLPEER 屬性使管理員能夠指定與 DN 內的各種欄位匹配的值，以便構建規則。可以指定各個值、萬用字元，甚至是整個 DN。根據所選擇的值，過濾的結果可以從極為任意的 DN 到能夠指定單個可接受的 DN。例如，設定 SSLPEER('C=US') 將允許在美國頒發的任何證書進行連線。較為有用的指定可能是 SSLPEER('O=IBM')，這將過濾出組織欄位不包括字串“IBM”的任何請求。注意，儘管 O=IBM 比 C=US 提供更好的過濾，但這兩種方法均太寬泛，不能視為非常有用的過濾。在實際的實現中，始終要選擇可滿足業務需求的最具限制性的過濾，從完全限定的 DN 開始，然後再從此返回。

在使用 RCVR、RQSTR 或 SVR 通道時，匹配單個證書非常有用，因為這些通道通常只與一個合作伙伴節點連線。匹配多個證書的通用過濾器對於 SVRCONN 和 CLUSRCVR 通道來說非常有用，它們通常需要接受來自各個客戶端節點的連線。

在為證書 DN 設計命名轉換時進行提前規劃非常必要。乍看上去，匹配公司名稱似乎就足夠了，但是，隨著時間的推移會出現更多的要求。例如，作為組織單位的一部分，包括諸如 DEV、TEST、QA、PROD 之類的值非常有用。如果有多個叢集，將叢集名作為一個 OU 欄位非常有用。為了匹配多個證書，這些 OU 欄位必須跨證書保持一致並按同一順序顯示。應按越來越具體的順序排列 OU 欄位，這是因為 SSLPEER 需要從左到右指定 OU 節點。例如，假定 DN 包含 U=IBM,OU=ISSW,OU=PROD，則 U=ISSW,OU=PROD 的 SSLPEER 字串將無效，但是 U=*,OU=ISSW,OU=PROD 仍有效。

證書一旦頒發，證書 DN 將無法更改。如果發生錯誤，代價會非常高，因此，要了解 SSLPEER 的工作原理，先使用自簽名證書測試您的過濾，然後再從商業 CA 那裡購買永久證書。SSLPEER 欄位允許在 z/OS 平臺上使用 256 個字元，在分散式平臺上使用 1024 個字元。另一方面，DN 可以為任意長度。如果該 DN 長度超過了 SSLPEER 欄位的容量，則需要使用萬用字元來匹配，這將為接受非預期連線開啟方便之門。

如果該 SSLPEER 屬性未提供足夠的粒度，可以使用安全出口根據任意一套規則評估 DN 和過濾器。流行的 BlockIP2 通道出口使管理員能夠提供一個由完全限定的名稱或使用萬用字元的專有名稱組成的列表，以供檢查。

再次訪問證書交換

使用 SSLPEER 或出口，SSL 握手將更加有用。但仍需要基本檢查，這意味著證書籤名者必須存在於信任儲存區中。此外，現在還有第二項檢查，目的是讓證書標識匹配某個字串，管理員已將該字串設計為過濾出除已知合法使用者之外的所有使用者。需要基於 DN 中的值（如通用名、公司名和叢集名）將 SSLPEER 值設計為匹配單個唯一 DN 或者進行一般匹配。當匹配多個證書時，需要選擇最窄的規範。

這裡必須指出的是，自簽名證書與 CA 簽名證書的工作方式完全相同。當提供自簽名證書時，將進行檢查以確保對其簽名的項存在於信任儲存區中。如果是自簽名證書，則該證書本身的公鑰必須存在於信任儲存區中。如果存在，將接受該證書，並傳遞給 WebSphere MQ 供 SSLPEER 或出口進行處理。實際上，該公鑰相當於頒發該證書的證書頒發機構。

客戶端身份驗證

到目前為止，我們討論的範圍僅限於提供證書時會發生什麼情況。有意忽略了誰提供證書這一問題，目的是為了將重點放在有關交換的詳細資訊上。當協商 SSL 連線請求時，至少發生一次（也有可能是兩次）證書交換。連線的伺服器端始終提供一個證書。而客戶端有時可能是匿名的，具體取決於伺服器的配置。如果該伺服器不強制客戶端提供證書，則不會發生第二次證書交換。

例如，在登入銀行的網站時這是可以接受的。在此情況下，伺服器端身份驗證讓您能夠知道已確實連線到了您的銀行，而不是某個貌似的釣魚網站。但是您不需要購買個人證書即可登入到您的銀行網站，而且任何瀏覽器均可登入。連線的客戶端可以是匿名的，因為將要求您在登入頁輸入另一套憑據。但使用 MQ 通道沒有輔助登入層。由客戶端提供的證書是對其進行身份驗證的唯一機會，而且依賴於管理員是否能確保進行驗證。

通過將通道的 SSLCAUTH 屬性設定為 REQUIRED，管理員可以強迫客戶端提供一個證書（請記住，本例中的“客戶端”可以是另一個佇列管理器）。與以往一樣，伺服器先提供其證書。如果客戶端接受該伺服器的證書，且 SSLCAUTH 將被設定為“REQUIRED”，則客戶端將其證書提供給該伺服器。

身份驗證流程與憑據交換的工作原理完全相同，與要驗證伺服器還是要驗證客戶端無關。現在已提供證書，其簽名者與信任儲存區中的證書匹配，如果找到了匹配項，則該 DN 可以與 SSLPEER 屬性中的值匹配或由通道安全出口處理。

配置缺陷

現在我們已經知道所有構件是如何組合在一起的，下面讓我們以使用自簽名證書的基本用例為起點，看一下如何拆分它們。

由於自簽名證書是免費的，因此在某種程度上幾乎始終會使用。但是，它們的其他優勢是自簽名證書不需要信任已經簽署了數千甚至數百萬其他證書的簽名者。自簽名證書的信任儲存區項與一個且僅與一個證書匹配。

實現帶有自簽名證書的 SSL 需要管理員執行以下操作：

• 為客戶端建立金鑰資料庫並生成相應的證書。
• 為伺服器建立金鑰資料庫並生成相應的證書。
• 從每個證書中提取公鑰。
• 將客戶端的公鑰匯入到伺服器的金鑰資料庫中。
• 將伺服器的公鑰匯入到客戶端的金鑰資料庫中。
• 啟用 SSLCIPH 並在客戶端和伺服器之間的通道上設定 SSLCAUTH(REQUIRED)。

假定所有這些操作均已正確完成，客戶端和伺服器現在將會連線。但這是否就足夠了？客戶端已確實向伺服器進行了身份驗證，反之亦然。配置應允許預期允許的請求者。遺憾的是，仍有可能接納持有由任何預設的受信任證書頒發機構頒發的證書的任何人。這個問題的解決方案非常簡單和有效：從金鑰資料庫中刪除預設的證書頒發機構。如果該金鑰資料庫僅包含自簽名證書，就不可能匹配多個非預期證書。信任儲存區的作用相當於一個列舉允許連線的所有標識的列表。只需處理匹配證書就足以對該連線進行身份驗證。

現在，假設有一個使用 CA 簽名的證書的用例。信任一個證書頒發機構並不等於信任該 CA 頒發的所有證書。最好從以下角度考慮：信任繫結到該證書的標識有效，然後設定相應標準以定義允許哪些標識連線。

使用 CA 頒發的證書實現 SSL 的安裝任務包括：

• 為客戶端建立金鑰資料庫並生成證書籤名請求 (CSR)。
• 為伺服器建立金鑰資料庫並生成一個 CSR。
• 將 CSR 提交給 CA 進行身份驗證並獲取簽名的結果。
• 如果客戶端或伺服器的信任儲存區中尚沒有 CA 根證書，則匯入該證書。
• 接收進入客戶端金鑰資料庫的客戶端證書。
• 接收進入伺服器金鑰資料庫的伺服器證書。
• 啟用 SSLCIPH 並在客戶端和伺服器之間的通道上設定 SSLCAUTH(REQUIRED)。
• 將伺服器上的 SSLPEER 設定為匹配該客戶端證書的字串。
• 從信任儲存區中刪除其他所有 CA 簽名者。

注意，該伺服器不需要讓客戶端的金鑰在其信任儲存區中（反之亦然），因為該 CA 是受信任的。使用 SSLPEER 決定是接受還是拒絕給定的證書。如果 SSLPEER 指定整個專有名稱，以便僅能夠與一個證書匹配，是否就可以了？也許吧。要考慮到，這一專有名稱可以從任何受信任的 CA 請求。例如，假定您從兩個受信任的預設 CA 請求一個帶有 DN="CN=VENUS,O=IBM,OU=ISSW,C=US" 的證書。只能保證此專有名稱對每個 CA 是唯一的，因此，一個 CA 沒有理由知道或關心同一 DN 是否由其他機構頒發。如果讓五個預設 CA 全部保留在您的信任儲存區中，但是僅使用由其中一個 CA 頒發的證書，則其餘的四個將為其他人提供請求帶有匹配 DN 證書的機會，然後該證書可用來成功連線。

如果這不會造成大範圍的暴露，請考慮當供應商要求您信任其內部 CA 而不是使用商業 CA 時會如何利用它。對於面向外部的通道和其他面向內部的通道，您的 DMZ 佇列管理器將信任該供應商的 CA。該供應商的證書類似於 DN="CN=GATEWAY,O=Vendor,OU=PROD,C=US"，您的內部證書類似於 DN="CN=QMGR,O=MyCorp,OU=Retail,C=US"。您可以將通道配置為 SSLPEER，以便面向內部的通道與內部證書匹配，面向外部的通道與供應商證書匹配。不謹慎的供應商可能會頒發帶有與您的內部證書匹配的 DN 的證書，並連線到您的面向內部的通道，這是因為 SSLPEER 只看 DN 而不管是誰頒發的。由於您的佇列管理器信任該提供商的 CA，就所涉及的佇列管理器來說，具有相同 DN 的偽造證書和合法證書完全相同。儘管使用完全指定 SSLPEER 值的兩個 CA 之間意外發生此類 DN 衝突的情況不太可能出現，但向 SSLPEER 規範新增萬用字元仍會提高其機率。新增幾個萬用字元會增加這種衝突的可能性。

防止此衝突發生不像處理自簽名證書那麼簡單。如果信任的儲存包含不止一個實體，例如兩個 CA 或一個 CA 和一些自簽名證書，就有可能發生 DN 衝突。從信任儲存區中刪除所有未使用的 CA 可減少衝突。此外，還可以利用其他 WebSphere MQ 加強技術限制連線，尤其是限制 B2B 介面的連線。

撤銷訪問權

在佇列管理器的生命週期中，訪問遲早是要被撤銷的。需要考慮以下兩種情況：撤銷授予在其他情況下合法身份的許可權和撤銷被破壞的證書。記住此區別並確保將您的實現設計為專門處理這兩種情況。

在將訪問權授予個別標識時，撤銷許可權最容易。如果訪問權基於指定完全限定的 DN 的 SSLPEER，則停止並刪除該通道將撤銷對該 DN 的訪問權。如果訪問完全基於自簽名證書，則從信任儲存區中刪除證書的公鑰將撤銷其訪問權。

撤銷許可權的更有趣的用例是 SVRCONN 或 CLUSRCVR 通道，當至少有一個 CA 受信任時，該通道必須匹配許多證書。叢集和互動式使用者身份最不穩定，最有可能需要撤銷其在某個點的訪問權。但是，SSLPEER 屬性無法提供足夠的粒度來指定允許此組的 DN，然後在此組中拒絕某些 DN。在有萬用字元 SSLPEER 的情況下，達到此級別粒度和使用 CA 頒發的證書的唯一方法是，使用能夠將某些專有名稱記錄到黑名單的安全出口。

您已經瞭解到，撤銷許可權可以在一個資源上阻止證書，同時在另一個資源上允許該證書。您還必須充分考慮到證書本身已經遭到破壞這一情況。出現這種情況時，證書很可能會由同一 DN 重新頒發。要求是統一撤銷對該特定證書的訪問權，但不必對與其關聯的 DN 這樣做。通過 SSLPEER 或出口無法解決此問題，因為它們僅在 DN 上執行。在此情況下，撤銷必須基於該證書的加密指紋，而提供此功能的機制就是證書撤銷列表 (CRL)。

WebSphere MQ 文件解釋瞭如何設定 CRL，還提供了 SupportPac (MQ01) 和一些示例，因此，這裡不再詳細介紹。概括地說，CA 提供了一個撤銷證書的源。系統定期捕獲這些證書（產品手冊建議每 12 個小時捕獲一次）並匯入到一個本地資料庫中。在 SSL 協商期間，將根據本地 CRL 檢查進行身份驗證的證書。如果找到匹配項，則連線將被拒絕。

CRL 中的證書匹配基於該證書的唯一序列號，而不是基於 DN，記住這一點非常重要。例如，如果撤銷一個專有名稱為 DN="CN=GATEWAY,O=Vendor,OU=PROD,C=US" 的證書，不會撤銷具有相同 DN 的證書，無論它們是自簽名證書還是由此 CA 或其他任何 CA 頒發的證書。該 DN 在每個上下文中仍然可行，其中包括撤銷它的 CA；只有 DN 和指紋（此證書）是無效的。

在一個通道需要允許多個證書的情況下，信任儲存區、SSLPEER 值和 CRL 之間的互動變得非常重要。最好的情況是信任儲存區包含全部自簽名證書，或者除包含受信任 CA 的單一入口之外沒有其他任何項。使用自簽名證書，信任將細化到具體的證書，並且能夠以每個證書為單位執行撤銷。使用除包含單個受信任儲存 CA 之外沒有其他任何內容的信任儲存區，CRL 提供一個等效的每 DN 撤銷功能，撤銷證書將有效撤銷訪問權。我這樣限定此說法，是因為該 CA 總是可以使用同一 DN 重新頒發該證書。CRL 本身只能保證阻止 DN，但是需要出口來保證。另外，按照慣例僅在證書遭到破壞時才撤銷它，並不僅用作撤銷許可權的手段。

繼續討論在單一通道上匹配多個證書，信任儲存區中有多個 CA 的情況會更糟。任何給定 DN 的潛在 SSLPEER 匹配項至少要與信任儲存區中 CA 的數量一樣多，如果將證書重新頒發計入在內數量會更大。CRL 根據該集合中的單個證書執行。雖然仍需要強制使用 CRL 來處理被破壞的證書，但是在用於從匹配池中刪除 DN 時會受到很大限制。在此情況下，出口是保證阻止 DN 的唯一選項。

匹配多個證書時的其他問題

使用證書頒發機構的一個值得注意的副作用是，它外化了連線到佇列管理器所需的配置。例如，假定管理員根據 O=MyCompany、OU=WidgetsDivision、OU=PROD 和 C=US 設定 SSLPEER 來過濾連線。這時，是否能夠成功連線這一問題將取決於是否擁有可以匹配該 SSLPEER 過濾的證書。而事實上，證書可能會散放在某人的工作站或移動電腦上，並且提供的物理訪問控制非常小，這進一步複雜化了該問題。如果單個證書被破壞，則 MQ 管理員就無法採取任何措施在佇列管理器中阻止它，且不影響所有其他合法使用者。唯一一種有效的方法證書撤銷列表也位於佇列管理器之外。

使用出口可以解決此問題。例如，可以提供一個包含可接受 DN 的“良好”列表。撤銷一個入口就像從該列表中刪除該項一樣簡單。類似地，入口可以結合 SSLPEER 使用。將在 SSLPEER 中定義一組允許的證書，且出口可以包含最重要的被記入黑名單的 DN。這樣，MQ 管理員可以立即直接控制誰能夠連線到該佇列管理器，誰不能連線到該佇列管理器。此級別的控制是否必要取決於應用程式。在太多的情況下，往往不能作出非常周全的決定，是因為它不容易理解。

回頁首

在叢集通道上使用出口

當使用自簽名證書時，證書與標識之間存在一一對應關係。撤銷訪問許可權和撤銷證書在功能上相當；從信任儲存區中刪除證書可同時完成這兩項任務。如果信任儲存區僅包含自簽名證書，多數情況下此功能將不需要 SSLPEER 過濾或處理帶有出口的 DN。另一方面，使用 CA 頒發的證書需要單獨的機制來執行撤銷證書和撤銷許可權這兩項任務。證書將使用 CRL 處理，許可權由基於專有名稱執行的機制授予或撤銷。在幾種情形中（如 DN 超出了 SSLPEER 長度或需要萬用字元匹配），通道出口是唯一的解決方案。

在選擇它作為您的解決方案之前，要知道在 WebSphere MQ 叢集通道上使用出口時，可能需要一個安全出口和一個通道自動定義 (CHAD) 出口。這是因為，建立通道時，接受方上的通道定義將傳播到傳送方。如果雙方通道在同一平臺上，且出口具有相同的名稱並且在同一位置，則一切工作正常且不需要 CHAD 出口。不過，此類同構叢集只是一種例外情況，而不是標準形式。CHAD 出口用來定製叢集通道定義，為本地平臺利用適當的語法指定安全出口。在大多數使用混合平臺的叢集中，較好的選擇是使用自簽名證書，編寫 CHAD 出口，或者不提供按專有名稱撤銷訪問權的功能。

回頁首

有關 FIPS 的說明

聯邦資訊處理標準 (FIPS) 的其中一條指定了在美國政府安裝中可使用的特定密碼套件。許多非政府商店也將 FIPS 用作其自己安全配置的底線。為了幫助配置 FIPS 遵從性網路，該佇列管理器有一個可以設定為 YES 或 NO 的 SSLFIPS 屬性。當設定為 YES 時，將限制 SSL 通道僅使用 FIPS 批准的加密演算法。管理員有時認識不到的是，此設定在非 SSL 通道上不會起任何作用。它們將像設定了 SSLFIPS(NO) 那樣繼續執行。

其目的是啟用混合環境，其中一些通道使用 FIPS 批准的 SSL，另一些可能會使用出口。還有一些情況，現有的網路被遷移到了 SSL，並在一段時間內同時包含 SSL 和非 SSL 通道。在此情況下，設定 SSLFIPS(YES) 可確保這些通道直接遷移至遵守 FIPS 的通道，即使舊的通道在沒有 SSL 的情況下繼續執行。

回頁首

加密增強

正如前面所提到的那樣，訊息和證書使用加密雜湊來驗證完整性。當前使用的兩種雜湊型別是 MD5 和 SHA1。儘管 WebSphere MQ 中的工具支援這兩種型別，仍應該只使用 SHA 雜湊。安全調查人員最近證明，利用 MD5 演算法允許他們偽造可用的證書。為防止此類攻擊，基於 MD5 雜湊的根證書和簽名者證書不應受信任。如果信任儲存區中有此類證書，應將其刪除。此外，建議的做法是選擇 SHA1 來生成自簽名證書、證書籤名請求，且作為該通道密碼套件的雜湊元件。

金鑰大小是決定加密可靠性的另一個因素。金鑰越大，可能值的數量就越大，使用蠻力技術破解它就越難。確保選擇的金鑰長度為 1024 位或更多。

回頁首

與非 SSL 配置引數互動

在該通道上啟用 SSL 本身不會合理地保護佇列管理器。為了使 SSL 保護有意義，必須實現幾種其他配置。這方面我有一個非常好的示例，我將在演示 WebSphere MQ 加強時介紹它。

這是一個有關財務清算系統的故事，該系統使用 WebSphere MQ 連線到數十個大型金融機構。每個機構都有自己的專用通道並且每個通道都有完全指定的 SSLPEER 值。結果是，能夠安全地連線到每個客戶端機構，並可確保不同的客戶端都不會劫持彼此的通道。一天，一個客戶端報告了一個通道問題。當供應商趕去調查時，他們非常驚訝地發現，有一名不認識的管理員登入到了 WebSphere MQ Explorer。客戶端機構的管理員等得不耐煩了，決定看看 WebSphere MQ Explorer 是否可以連線到供應商的佇列管理器，以便檢視個究竟。確實不可思議可以登入，且具有管理許可權。

這裡得到的教訓是，僅在佇列管理器的某些通道上啟用 SSL 還遠遠不夠。為了進行有效控制，佇列管理器上的每個入站通道都需要啟用或者禁用 SSL。這包括 RCVR、RQSTR、CLUSRCVR、SVR 和 SVRCONN 之類的所有通道，尤其是那些名為 SYSTEM.DEF.* 或 SYSTEM.AUTO.* 的通道，因為它們完全可用並具有眾所周知的名稱。

在 MCAUSER 屬性中，不用於支援管理佇列管理器的任何通道都具有低許可權使用者 ID，這一點也很重要。這包括上面提到的所有通道型別（SVR 通道除外）。如果允許遠端管理，該管理應使用配置為僅接受 MQ 管理組成員證書的專用通道。所有其他訪問，無論是來自互動式使用者還是其他佇列管理器，都應該使用受低許可權 MCAUSER 保護的通道。這樣做的原因是，經過 SSL 交換驗證的標識不會傳播給該 MQ API。除非被 MCAUSER 覆蓋，否則通過 SVRCONN 通道到達的連線可以斷言任何使用者 ID，其中包括管理 ID。SSL 不限制斷言 ID 的能力。其他入站通道型別 RCVR、RQSTR 和 CLUSRCVR 始終使用管理許可權執行，但被 MCAUSER 覆蓋的情況除外。MCAUSER 可以在通道定義中設定，也可以由出口動態設定。如果使用了出口，則通道定義應包含 MCAUSER('nobody')，因此在出口出現故障時，該通道將進入不可操作狀態。

回頁首

適用性

儘管此處的討論主要著眼於一般的 SSL 規則，但本文仍特定於 WebSphere MQ，因此不適用於其他環境。例如，我在討論證書 DN 時假定僅有一個該證書。這與撰寫本文時 WebSphere MQ 手冊中如何處理該主題是一致的。事實上，標準 X.509 證書包含更多的標識資訊，其中包括頒發證書的證書頒發機構的 DN。本文中提到的 DN 更適合稱為 subjectDN。有些產品會向管理員公開更多的證書標識。例如，熟悉 IBM WebSphere Application Server 的讀者可能想知道，為什麼不直接在 SSLPEER 過濾或出口的匹配條件中包括 issuerDN。總之，issuerDN 和 subjectDN 的組合在所有可能的 DN 池中應該是完全唯一的，並且可以解決此處介紹的許多 DN 匹配問題。答案就是 WebSphere MQ 僅將 subjectDN 公開給管理員或出口。issuerDN（甚至證書指紋）既不會在管理命令中暴露，也不會在低階別出口介面中暴露。這將導致在 WebSphere MQ 中對 CA 的處理稍微不同於在其他產品中的處理，並要求使用 CA 頒發的證書時信任儲存區除包括該 CA 之外不包含任何內容。對於一對自定義通道安全出口而言，可以查詢證書資料庫以獲取和交換更多的證書標識資訊，但這不在本文的討論之列。

回頁首

總結

本文解決了兩個反覆出現的 SSL 問題。第一個問題是混雜連線，此情形是通道接受除預定連線之外的大量連線。第二個問題是無意允許管理許可權的 SSL 身份驗證的連線。

還提供了一些具體建議，以幫助解決下列問題：

• 從信任儲存區中刪除所有未使用的證書頒發機構。
• 如果信任儲存區中包括一個證書頒發機構，則使用 SSLPEER 或出口（或同時使用二者）過濾出不需要的連線。
• 將受信任的 CA 的數量限制為（理想）不超過一個。
• 使用 SSLCAUTH(REQUIRED) 確保該客戶端經過身份驗證。
• 通過為包含有用的組織單位欄位的證書專有名稱設計命名規則，估計是否需要精細的 SSLPEER 過濾。
• 在設定命名規則之前，先使用自簽名證書練習 DN 過濾。
• 如果需要將多個 DN 與完全限定的名稱匹配，則使用自簽名證書或出口。
• 如果 DN 超過了 SSLPEER 長度或者在 SSLPEER 使用萬用字元匹配時，需要使用出口。
• 在混合平臺的叢集中，需要通道自動定義出口在叢集通道上實現安全出口。
• 提前制定策略，以便根據專有名稱和具體證書撤銷訪問。
• 在使用 CA 頒發的證書時強制使用證書撤銷列表。
• 如果 FIPS 遵從性是一個問題，則設定 SSLFIPS(YES)，但要知道這不會禁用非 SSL 通道。
• 通過設定 MCAUSER('nobody') 禁用所有未使用的通道，如名為 SYSTEM.DEF.* 和 SYSTEM.AUTO.* 的通道。
• 確保不允許管理訪問的所有入站通道都在 MCAUSER 屬性中包括一個值。

有大量文件介紹瞭如何設定 SSL，還有大量的幫助工具。其中有許多都在“參考資料”部分中，可幫助您入門。儘管我在此處提供了一個清單，我還是鼓勵您構建一對測試佇列管理器並練習 SSL 通道，直到您充分體驗到 SSLPEER 的功能並知道如何撤銷訪問，以及如何授予訪問權。下載 BlockIP2 並進行練習。最後，熟悉證書撤銷列表和更新它們的流程。然後，在您準備開始 SSL 實現或糾正專案時，您將瞭解到構建完整的實現計劃並能夠避免某些常見缺陷時所需的知識。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-610850/，如需轉載，請註明出處，否則將追究法律責任。