圖 4 顯示了基於 Java 的 ODR 服務器的放置，這與 IBM DataPower SOA Appliances 的應用程序優化 (AO) 功能所提供的按需路由功能截然不同。儘管 Java ODR 不應放在 DMZ 中，但 DataPower SOA 設備是一個適合放在 DMZ 中的加強的設備。
4. 對瀏覽器訪問使用 HTTPS
雖然可以通過未加密的通道發送 LTPA 令牌，但是為了最大程度地保護它們，最好通過加密鏈接發送它們。如果 LTPA 令牌被成功截獲，那麼竊取者可以冒充該用戶的身份，直到令牌到期為止。
如果站點要執行任何身份驗證或者有任何應該保護的活動，則需要對從瀏覽器到 Web 服務器的訪問使用 HTTPS。如果不使用 HTTPS，那麼密碼、用戶活動、WebSphere Application Server 會話 cookie 和 LTPA 安全令牌（參見邊欄）等信息可能被入侵者看到，因為通信流要穿過外部網絡。
對於在執行身份驗證之前允許 HTTP 通信流的應用程序，一定要密切注意 cookie。如果某個 cookie（比如 JSESSIONID）是在使用 HTTPS 之前設置的，那麼在使用 HTTPS 之後，該 cookie 可能帶來風險，因為入侵者可能已經修改或捕獲了它。這正是 WebSphere Application Server 對經過身份驗證的用戶使用單獨的 cookie 的原因。另一種更狡猾的攻擊方式是，入侵者可以修改通過 HTTP 返回的任何頁面——甚至包括頁面中嵌入的 URL。因此，用戶可能會單擊頁面上看似安全的 URL，但他實際上會被轉到入侵者的站點上。
5. 保持補丁和修復最新
本文假設您已應用了最新的補丁包（在撰寫本文時，最新的補丁包是 7.0.0.25、8.0.0.4 和 8.5.0.0，請參閱 最新的 WebSphere Application Server 修復包），以及最近發佈的所有安全 APAR。這些補丁包和 APAR 解決或堵住了本文未提到的其他漏洞，所以要確保系統處於最新的修復級別並確認應用了所有已知漏洞的補丁，這非常重要。當然，隨着時間的推移，應該經常關注新發佈的安全修復。毫無疑問，以後還會不斷發現新問題。
與其他複雜產品一樣，IBM 會不時地發現和修復 WebSphere Application Server、IBM HTTP Server 和其他產品中的安全性 bug。保持這些修復最新非常重要。建議訂閱您使用的產品的支持公告板，對於 WebSphere Application Server，需要經常訪問您的版本的 安全公告網站。這些公告板常常包含最近發現的安全性 bug 和修復通知。可以肯定的是，潛在的入侵者會很快得知那些安全性漏洞。您越早採取行動越好。
在 WebSphere Application Server 安全 頁面上，可以找到關於 WebSphere Application Server 安全性的一般性信息，包括對加強 WebSphere Application Server 基礎架構的建議。
6. 啟用應用程序安全性
在默認情況下，WebSphere Application Server 完整配置文件的定義中啟用了管理安全性。因此，在大多數情況下，基礎架構會在默認情況下為管理通信流提供合理的身份驗證、授權和加密。在啟用管理安全性時，部署管理器和應用服務器之間的 WebSphere Application Server 內部鏈接以及從管理客戶端（Web 和命令行）到部署管理器的通信流是經過加密和身份驗證的（參見圖 3）。這意味着，在運行管理工具時，需要對管理員進行身份驗證。後面會討論一些例外情況。
除了在管理方面利用應用服務器的安全性之外，強烈建議在應用程序安全性方面利用它。這樣做可以讓應用程序能夠訪問強大、健壯且基於標準的安全基礎架構。在沒有利用應用服務器安全性的應用程序中，常常會發現很嚴重的安全性漏洞。設計和實現安全的分佈式基礎架構並不容易。
要想啟用應用程序安全性，應該進入全局安全性面板，並選擇 Enable application security（不需要啟用 Java 2 安全性；正如後面討論的，它通常不適用），參見圖 6。
圖 5. 應用程序安全性
在 V8.5 Liberty 配置文件中，通過將清單 1 中所示的元素包含在配置文件的 server.xml 文件中來啟用應用程序安全性。
清單 1. 在 Liberty 中啟用應用程序安全性
|
1 2 3 |
<featureManager> <feature>appSecurity-1.0</feature> </featureManager> |
警告：僅僅啟用應用程序安全性並不能確保應用程序是安全的。這只是讓應用程序能夠利用應用服務器提供的安全特性（包括 Java EE 安全性）。後面會進一步討論這個主題。
7. 使用 ldapRegistry 代替 quickStartSecurity 或 basicRegistry 元素
Liberty 配置文件在設計時採用了極簡理念。為了給希望測試其應用程序是否兼容安全性的開發人員提供輕鬆支持，可以使用一個包含單個用戶 ID 和密碼的 quickStartSecurity 註冊表。basicRegistry 允許定義多個用戶和組。這兩個安全註冊表都包含在 server.xml 內。
上述兩個簡單的註冊表在開發人員的個人環境中已經夠用。在測試環境外，這些 Liberty 配置文件應配置為使用 ldapRegistry 功能。
8. 限制對 WebSphere MQ 消息傳遞的訪問
如果使用 WebSphere MQ 作為消息傳遞提供者，則需要通過其他技術來提供隊列授權。在使用客戶端/服務器模式時（綁定模式依賴於計算機中的進程到進程身份驗證），默認情況下 WebSphere MQ 不會執行任何用戶身份驗證。事實上，當您在連接工廠上為 WebSphere MQ 指定用戶 ID 和密碼時，這些值會被 WebSphere MQ 忽略。
WebSphere MQ 安全警告
因為本文主要關注 WebSphere Application Server 安全性，所以這一節只討論如何保護從應用服務器到 WebSphere MQ 的鏈接。這並不能保證 WebSphere MQ 本身是安全的。關於如何正確地保護 WebSphere MQ，請參閱 WebSphere MQ 安全性炙手可熱。
解決這個問題的一種方法是，在 WebSphere MQ 服務器端實現自己的自定義 WMQ 身份驗證插件，對 WebSphere Application Server 發送的用戶 ID 和密碼進行驗證。第二種（可能更簡單的）方法是，將 WebSphere MQ 配置為使用 SSL 進行客戶端身份驗證，然後確保只有 WebSphere Application Server 服務器持有用於連接 WebSphere MQ 的證書。（有關的更多信息，請參閱 保證 WebSphere Application Server 和 WebSphere MQ 之間連接的安全；本文有點兒過時，但相同的原理和技術也適用於這兩個產品的新版本。在實現其中提到的技術時，應該考慮到產品的變化。）
9. 加強 Web 服務器和主機
如果採用 步驟 1 中推薦的標準拓撲，那麼 Web 服務器是在 DMZ 中運行的。因為 DMZ 是防範潛在入侵者的第一道防線，所以必須特別注意加強此服務器。
本文不討論加強 Web 服務器 的具體方法，但您應該在操作系統加強、限制裝載的 Web 服務器模塊和其他 Web 服務器配置步驟上下足功夫。（有關的更多信息，請參閱 Apache hardening information 和圖書 Building Secure Servers with LINUX。）
在加強 Web 服務器時，有一個 WebSphere Application Server 特有的問題需要考慮。通過 WebSphere Application Server 管理基礎架構來管理 Web 服務器是有可能的。雖然它便於使用看似是一件好事，但這卻帶來了嚴重的安全問題。有兩種方式可以管理 Web 服務器：
使用託管節點要求在 Web 服務器（通常位於 DMZ 中）上放置一個節點代理，而且要求使用該代理作為 WebSphere Application Server 計算單元的一部分。這從安全角度來看是完全不可接受的，因此不應該使用，除非在極少數不需要 DMZ 的情況下。這種方式不可接受的原因有兩點：
o 首先，節點代理是計算單元的一個全功能成員，因此它有完全的管理權限。如果它在 DMZ 中遭到攻破，那麼整個計算單元都會受到侵害。
o 第二，WebSphere Application Server 是一個強大的大型產品，因此很難加強安全性，這樣的產品不應該放在 DMZ 中。
第二種方式要求使用 IBM HTTP Server 和配置 HTTP 管理服務器。在這種情況下，部署管理器將管理請求發送給在 Web 服務器主機上運行的 HTTP 管理服務器。儘管這是一種比採用基於 Java 的節點代理更好的方法，但是許多人仍然認為這種做法存在風險，最好根本不在 DMZ 中提供管理功能。
10. 刪除 Web 服務器和插件安裝程序遺留的 JRE
在安裝 IBM HTTP Server 時，安裝程序會遺留一個 JRE。應該刪除此 JRE，因為它提供的功能是 Web 服務器或插件在正常情況下所不需要的。請記住，這樣做之後，將不能在此 Web 服務器上運行 ikeyman 等工具。我們不認為這個問題很重要，因為在 DMZ 中運行這樣的工具並不合適。
當使用 IBM 安裝程序安裝 WebSphere Application Server HTTP Server 插件時，也會遺留一個 JRE。同樣，在完成安裝後，應該刪除此 JRE。
如果您決定刪除 JRE，那麼應該做一下備份，以防將來使用。一種方法是對該 JRE 執行 zip 或 tar，並在以後需要時將它放回原處（例如，在應用補丁時，WebSphere Application Server 更新安裝程序需要它），然後對其執行 zip/tar，並在過程結束時再次將其刪除。
11. 加強代理
如果把安全代理服務器放在 DMZ 中，替代 Web 服務器（或與 Web 服務器共存），那麼前面的建議也適用於這個代理，但是這裡並不打算提供具體細節，因為具體的加強方法與代理相關。
關於 WebSphere DataPower 的一個要點是：Web 安全代理通常並不適用於代理 Web 服務通信流，因為它們無法阻止在傳輸 XML 時可能出現的威脅。要提供安全的 Web 服務（或任何基於 XML 的協議），可 使用 XML 防火牆，比如 WebSphere DataPower。
12. 謹慎地配置和使用信任關聯攔截器 (trust association interceptor)
TAI 經常用於讓 WebSphere Application Server 能夠識別來自 Web SSO 代理服務器（例如 Tivoli Access Manager WebSEAL）的現有身份驗證信息。這通常沒什麼問題。然而，在開發、選擇和配置 TAI 時需要特別注意。TAI 會擴展信任域。目前 WebSphere Application Server 信任 TAI 以及 TAI 所信任的所有內容。如果 TAI 開發或配置不正確，就有可能徹底危害 WebSphere Application Server 的安全性。如果您自行開發 TAI，則需要確保 TAI 仔細檢驗請求中傳遞的參數，並確保以可靠的方式進行檢驗。我們曾經見過 TAI 做蠢事，比如直接接受 HTTP 頭中的用戶名。這是沒用的，除非確保 WebSphere Application Server 收到的所有通信流都是通過身份驗證代理髮送的。例如，使用 前面 描述的技術。這樣身份驗證代理總是會覆蓋客戶端設置的 HTTP 頭，因為可以偽造 HTTP 頭。
WebSEAL TAI 配置
為了說明仔細配置的重要性，本文將詳細討論 IBM 提供的遺留 WebSEAL TAI，但任何 TAI 都需要認真設計和配置才能獲得安全性。對 WebSphere Application Server 和 Tivoli Access Manager WebSEAL 之間的信任關係進行合理的配置是創建安全配置的關鍵。要創建安全配置，就必須對 WebSphere Application Server 和 WebSEAL 都執行一些步驟。在 WebSphere Application Server 中，必須對 Web 容器配置和 WebSEAL TAI 配置都進行合理的設置。
這兩種產品之間的信任關係是很重要的，因為 WebSphere Application Server 中的 WebSEAL TAI 接受來自 WebSEAL 的身份斷言。如果可以攻破該鏈接，入侵者就可以斷言任何身份，並徹底破壞基礎架構的安全性。WebSphere Application Server 和 WebSEAL 之間的信任關係可以通過以下兩種機制之一建立：相互 SSL 身份驗證和基於密碼的身份驗證。這兩種機制在安全的環境中都適用。然而，每一種機制都必須進行合理的配置，否則可能會出現嚴重的安全問題。在每種機制中，WebSEAL 都將最終用戶的用戶 ID 作為 iv-user 頭在 HTTP 請求中發送。這兩種配置的區別在於 WebSEAL 嚮應用服務器證明自身的方式。
WebSEAL 密碼配置
在使用密碼身份驗證時，WebSEAL 會將其用戶 ID 和密碼作為基本的 auth 頭在 HTTP 請求中發送（該用戶的用戶 ID 位於 iv_user 頭）。基於密碼的身份驗證在兩個地方配置。首先，對於要配置的匯合點，必須配置 TAM WebSEAL，以便將其用戶 ID 和密碼發送給應用服務器。當然，此密碼是機密的，必須小心保護。WebSEAL TAI 在收到密碼時會根據註冊表對其進行檢驗。
然而，這一點很不起眼，容易被忽視。如果在 WebSEAL TAI 屬性中沒有設置 LoginId 屬性，TAI 就會檢驗從 WebSEAL 發送出來的用戶 ID 和密碼組合；如果它是任何有效的用戶 ID 和密碼組合，則會信任它。這種配置是不安全的，因為這意味着知道任何有效用戶 ID 和密碼組合的任何人都可以連接到 WebSphere Application Server，並斷言任何用戶的身份。在指定 LoginId 屬性時，WebSEAL TAI 會忽略基本 auth 頭中的入站用戶 ID，並檢驗 LoginId 和 WebSEAL 密碼組合。在這種情況下，能夠從 WebSEAL 發出的有效密碼只有一個（大概接近於受保護的機密）。當然，應該配置從 WebSEAL 到應用服務器的 SSL，以確保該機密密碼不會以明文形式發送。
WebSEAL mutualSSL 配置
Mutual SSL 是通過三個單獨的非常重要的步驟配置的：
1. 必須把 WebSEAL 配置為使用 SSL 與 WebSphere Application Server 進行通信，而且該 SSL 配置必須包含只有 WebSEAL 才知道其私鑰的客戶端證書。
2. 必須配置應用服務器 Web 容器，以便執行客戶端證書身份驗證。還必須更改其信任存儲庫，使之僅包含 WebSEAL 正在使用的客戶端證書。這個步驟至關重要，因為只有這樣才能保證對應用服務器 Web 容器的請求僅來自 WebSEAL，而非某個入侵者（僅僅使用相互身份驗證的 SSL 是不夠的）。還必須將非 HTTPS 傳輸從 Web 容器中刪除，確保在與服務器聯繫時只使用相互身份驗證的 SSL。
以下文章點擊率最高
Loading…