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…