WebSphere Application Server V7高級安全性增強，第1部分：（上）

安全性增強概述和方法

簡介

IBM WebSphere Application Server 的安全性在每一個版本中都有所改進。除了在新版本中 增長新功能以外，咱們還不斷加強產品的默認安全性。咱們經過改進默認設置不斷提升知足默 認安全性這一關鍵原則的程度。本文的前一個版本 主要關注 WebSphere Application Server V6 和那個版本所需的增強步驟。在後續 WebSphere Application Server 版本中，顯著減小了 增強步驟的數量，更重要的是，保留的大多數步驟不太關鍵了。所以，如今有必要用新信息更 新本文。

本文首先簡單討論安全性爲何重要以及增強系統的困難，而後討論如何增強 WebSphere Application Server 環境以解決各類安全性漏洞。由於本文主要討論增強，一些信息是歸納性 的，沒有進行詳細分析。咱們儘量提供相關詳細信息的適當參考資料，讓您可以進一步研究 相關的子主題。

儘管本文中的信息基於 IBM WebSphere Application Server V7，可是討論的大多數問題同 樣適用於 V6.1。對於某個版本特有的問題，咱們會專門指出。

爲何須要安全性？

使人欣慰的是，大多數讀者都可以認識到安全性是企業系統的一個關鍵方面。儘管如此，爲 了介紹一些考慮安全性的經常使用方法，咱們仍將簡要介紹一下安全性。

安全性的基本目的是 「阻止不懷好意的人進入您的系統」。更準確地說，安全性是一個過 程，它應用多種技術來防止未經受權的用戶（一般稱爲入侵者）對內容進行未經受權的訪問。

有許多類型的入侵者：外國間諜機構、競爭對手、黑客，甚至您本身的僱員。每一個入侵者都 有不一樣的動機、不一樣的技能和知識、不一樣的訪問入口以及不一樣的需求級別。例如：

僱員可能對公司有攻擊動機。僱員具備很是高的內部訪問級別和系統知識水平，但他們的資 源和黑客技能可能頗有限。

外部黑客也許是安全性攻擊方面的專家，可是他們對您可能 沒有攻擊動機。

外國間諜機構可能對攻擊您很感興趣（這取決於您的業務）並擁有極其 豐富的資源。

入侵者可能出於兩個緣由之一入侵您的系統：爲了獲取他們本不該該擁有 的信息，或者爲了以某種方式改變系統的正常行爲。在後一種狀況中，經過改變系統行爲，他 們能夠嘗試執行對其有利的事務，或者只是爲了用某種有意思的方式致使系統崩潰，以形成對 您的組織的損害。

要點是，有不少不一樣類型的入侵者、不少不一樣的入侵動機以及（咱們 後面將會看的）許多不一樣的攻擊類型。在規劃安全性時，必須認識到這些。

同時關注內 部和外部威脅

安全性措施不該該僅僅視爲阻擋 「外人」 的大門。那是一個 過於簡單化的觀點。當前，許多組織將他們的安全性措施徹底集中在針對組織之外的人羣，他 們錯誤地認爲只有外人才是危險的。實際上並非這樣。對於大型公司，每每有數千人可以訪 問內部網絡（其中許多人並非僱員）。這些人均可能成爲入侵者，並且因爲他們在內部，他 們訪問網絡更方便。經常只需把筆記本電腦插上網線，就可以訪問公司網絡。一些研究代表， 有將近一半的入侵是 由組織內部的僱員或者承包人形成的（或涉及到他們）。

就算您 相信網絡中的每一個人都是值得信任的，那麼也可以相信他們永遠不犯錯誤嗎？考慮到經過電子 郵件傳播的病毒如此猖獗，並且基於 JavaScript™ 的攻擊程序和其餘程序很容易經過插 入計算機的優盤和 CD 進入公司網絡並從內部發起攻擊，因此假設整個內部網絡均可以信任是 魯莽之舉 —— 不能這樣作。

安全性措施應該努力保護系統不被全部的潛在入侵者攻擊，這就是本文爲何如此之長的原 因。安全性不只僅是在網絡邊界上保護系統不受 「外部」 攻擊的防火牆。它是一組旨在儘可 能增強系統安全的複雜的操做和過程。

限制和現實情況

應該認識到沒有徹底安全的系統，這一點很重要。您的目標是在業務的約束下儘量保護系 統。在考慮安全性時，理想狀況下應該：

分析攻擊的各個方面。

考慮每種攻擊的風險。

肯定攻擊成功而致使安全性被破壞的可能性。

評估爲防止每種攻擊要付出的代價。

在估計安全性被破壞而形成的損失時，不要忘記安全性被破壞會致使系統用戶對系統失去信 心。所以，「安全性被破壞的代價」 可能包括很是高昂的間接代價（好比，失去投資者的信任 ）。

由於一些黑客入侵系統只是爲了好玩，若是建立了具備合理安全程度的環境，入侵者就會轉 向更容易的目標。

一旦完成以上列出的步驟，就能夠對風險與成本作出適當的權衡。從本質上說，目標就是要 讓入侵者爲入侵系統而付出的代價超過他們能夠得到的利益，同時確保業務可以承受運行安全 系統所付出的代價（見邊欄）。

歸根結底，須要什麼安全級別是一個業務決策，而不是技術決策。然而，做爲技術人員，我 們必須幫助全部各方理解安全性的價值和重要性。所以，除了保護內部應用程序免受攻擊外， 本文中建議的大多數安全性增強步驟的成本都至關低。大多數組織都應該都有能力實現它們。 本文沒有介紹比較複雜和昂貴的安全性方法 —— 強身份驗證、審計和入侵檢測等，它們超出 了 WebSphere Application Server 產品功能的範圍。

安全性是一個很大的主題，本文不可能徹底覆蓋安全性的全部方面。本文不是對安全性的介 紹或者關於如何保護系統的教程。而是對涉及 WebSphere Application Server 安全性時須要 考慮的核心技術問題的概述或檢查表。本文中的信息應該與建立安全企業的更大型工做結合起 來。

社會工程

因爲這是一篇技術性的文章，所以重點討論保護系統的技術解決方案，具體地說主要集中於 安全性難題的 WebSphere Application Server 部分。儘管如此，您應該意識到使用社會工程 技術危害系統每每更加簡單。也就是說，經過欺騙在組織中工做的人員，攻擊者能夠得到權限 以訪問他們本不該該訪問的系統和信息。從社會工程攻擊技術能夠得出的一個結論是：經過使 用社會工程，攻擊者可能來自您的網絡內部。這再次強調了前面提到的觀點：僅僅防護來自網 絡外部的攻擊者是遠遠不夠的。所以，這裏的討論集中於多個級別的安全性。每一個級別防範不 同的攻擊類型，並提供對攻擊者更有效的屏障。

總的系統觀點：細節問題

在詳細研究具體建議以前，咱們先花一些時間來概述建立安全系統的基礎技術。基本觀點是 着眼於每一個系統邊界或共享點，檢查哪些參與者訪問了這些邊界或共享的組件。也就是說，假 設這些邊界存在（假設子系統內部比較可信），那麼入侵者如何突破這些邊界呢？或者，假定 某些東西是共享的，那麼入侵者是否能夠不正當地共享某些東西呢？

大多數邊界是很明顯的：網絡鏈接、進程與進程的通訊、文件系統、操做系統接口等等，但 是有些邊界不容易辨別。例如，若是一個應用程序使用 WebSphere Application Server 中的 J2C 資源，那麼必須考慮另外一個應用程序試圖訪問這些資源的可能性。這是由於第一個應用程 序和 WebSphere Application Server 之間以及第二個應用程序和 WebSphere Application Server 之間都存在系統邊界。可能這兩個應用程序均可以訪問這個資源（實際上它們確實能夠 ）。這多是不合理的共享。

在 WebSphere Application Server 環境中，操做系統對 API 的保護的價值比較有限，因 爲它們是基於進程標識符的，因爲應用服務器同時接受數千用戶發出的請求，這是一個很是粗 粒度的概念。

要防止各類形式的攻擊，能夠應用許多衆所周知的技術。對於較低層的基於網絡的攻擊，可 以應用加密和網絡過濾。這樣能夠拒絕入侵者查看或訪問他們不該該看到的內容。還依賴操做 系統提供的機制來保護操做系統資源不被濫用。例如，不但願普通用戶級代碼可以訪問系統總 線以及直接讀取內部通訊。還利用大多數現代操做系統對系統 API 保護得至關可靠這一事實（ 見邊欄）。在高層上，嚴格應用身份驗證和受權。每一個 API、每一個方法和每一個資源均可能須要 某種形式的受權。也就是說，必須根據需求嚴格地限制對這些東西的訪問。固然，若是沒有可 靠的身份驗證，受權也就失去了價值。身份驗證所作的事情就是可靠地判斷調用者的身份。這 里加了 「可靠」 這個詞，這是由於容易被僞造的身份驗證是沒有價值的。

若是沒法採用適當的身份驗證和受權，那麼只能採起巧妙的設計和過程來防止潛在的問題。 咱們就是用這種方式來保護 J2C 資源。因爲 WebSphere Application Server 沒有爲對 J2C 資源的訪問提供受權機制，咱們只好應用其餘技術來限制（基於配置）應用程序不正當地訪問 J2C 資源的能力。

能夠想像到，檢查全部的系統邊界和共享組件這一任務很困難。另外 ，實際上，保護一個系統就須要充分考慮它的複雜性。關於安全性最困難的事情可能就是建立 一個依靠抽象工做的安全系統。也就是說，良好抽象的原則之一就是，把關注的問題對更高層 的組件隱藏起來。這是人們很是須要的，也是很是好的作法。遺憾的是，入侵者並不友善。他 們並不在意抽象或者良好的設計。他們的目標是想盡辦法入侵系統，因此他們會在您的設計中 尋找漏洞。所以，爲了驗證系統的安全性，必須在每一個抽象級別上考慮它：從最高的架構層到 最低的詳細實現層。儘管有許多應用程序掃描工具能夠幫助檢查代碼（好比 IBM Rational® AppScan®），可是即便使用掃描工具，仍然須要對全部代碼和設計決策進 行手工檢查以防止應用程序受到攻擊。須要對全部的內容進行嚴格的檢查。

最小的錯誤也可能破壞整個系統的完整性。使用緩衝區溢出技術來控制基於 C/C++ 的系統 是對此最好的例證。在本質上，入侵者傳遞一個大於現有緩衝區的字符串。那麼多出的信息會 覆蓋正在運行的程序的一部分，致使運行時執行本不該該執行的指令。注意，經過這種方法， 入侵者可讓程序作幾乎任何事情。做爲安全架構師，要想識別這種攻擊，就必須深刻理解 C/C++ 運行時如何管理內存和執行在運行的程序。即便您瞭解緩衝區溢出問題的存在，仍然必 須檢查每一行代碼以發現這個漏洞。目前，咱們已經瞭解了這種攻擊，可是它仍然可以攻擊成 功，這是由於個別程序員作出了很是小的錯誤決策，它會危及整個系統的安全。幸運的是，這 種攻擊在 Java™ 中不奏效，可是其餘小錯誤仍然可能致使系統受到威脅。

要對安全性進行認真的考慮；這是很難的。

安全性增強概述

J2EE 規範和 WebSphere Application Server 提供了一種用於實現安全系統的強大的基礎設施。遺憾的是， 許多人沒有意識到建立基於 WebSphere Application Server 的安全系統的各類相關問題。這 些信息有許多自由度和許多不一樣的來源，因此一些用戶每每會忽視安全性問題，部署的系統不 夠安全。爲了不這種狀況，本節對最關鍵的問題進行總結。

安全性增強指的是經過配 置 WebSphere Application Server、開發應用程序和配置其餘各類相關組件，儘量提升安全 性 —— 其本質就是防止、阻礙或減輕各類形式的攻擊。要想使安全性獲得有效加 強，瞭解攻擊的形式是很重要的。攻擊應用服務器有四種基本方法：

基於網絡的攻擊 ：這些攻擊依賴於對網絡數據包的低層訪問，試圖經過修改通訊流或者發現這些數據包中的信 息來危害系統。

基於計算機的攻擊：在這種狀況中，入侵者已經能夠訪問運行 WebSphere Application Server 的計算機。對於這種狀況，咱們的目標是限制入侵者損害配置或者看到不該該看到的內 容的能力。

基於應用程序的外部攻擊：在這種狀況下，入侵者使用應用級的協議（HTTP、IIOP、JMX、 Web 服務等等）來訪問應用程序，可能經過 Web 瀏覽器或者其餘類型的客戶機。入侵者使用這 種訪問方式來試圖超越應用程序的正常使用方法，作一些不正當的事情。關鍵是入侵者是使用 定義良好的 API 和協議來進行攻擊的。入侵者並不必定在公司外部，但他們是從應用程序自身 的外部執行代碼的。這些攻擊類型是最危險的，由於它們須要的技能每每不多，而且只要有可 用的 IP 鏈接，就能夠從很遠的距離實施攻擊。

基於應用程序的內部攻擊（也稱爲應用程序隔離）：在這種狀況下，咱們關心的是惡意應用 程序的危害性。在這種狀況下，多個應用程序共享相同的 WebSphere Application Server 基 礎設施，咱們不能徹底信任每個應用程序。

爲了幫助您將保護技術與這些攻擊類別聯繫起來，每種技術使用如下圖形表明這些漏洞：

N：基於網絡的攻擊

M：基於計算機的攻擊

E：基於應用程序的外部攻擊

I: 基於應用程序的內部攻擊

對於每種技術，適當的方塊將加上底紋，表示這種技術有助於防範的攻擊類型。請記住，內 部應用程序老是能夠利用外部攻擊方法進行攻擊。所以，當已經標出 E（外部）時，就再也不明 確地標出 I（內部）。

請注意，這裏沒有考慮另外一種技術攻擊形式：拒絕服務 (Denial of Service, DoS) 攻擊。 儘管它很重要，可是 DoS 攻擊超出了本文的範圍。防範 DoS 攻擊須要很不同的技術，這超 出了應用服務器所能提供的範圍。爲了防範 DoS 攻擊，須要考慮網絡通訊量監視器、速率限制 器、入侵檢測工具等等。

增強方法

咱們來討論一下要保護 WebSphere Application Server 基礎設施和應用程序免受這四種形 式的攻擊應該採起的各類已知的步驟。（這裏說 「已知的」 步驟固然是由於可能有其餘漏洞 尚未被發現。）理想的狀況下，能夠將這些信息分紅四個部分，每一個部分對應於一種形式的 攻擊。遺憾的是，攻擊並不徹底按照那些界線來劃分。有幾種不一樣的保護技術能夠防範多種形 式的攻擊，而有時一次攻擊可能利用多種入侵形式來達到最終目標。例如，在最簡單的狀況下 ，網絡嗅探可以用於獲取密碼，而後這些密碼能夠用於進行應用級攻擊。於是，咱們根據活動 發生的時間或問題相關人員的角色來將安全增強技術組織成符合邏輯的結構：

基礎設施：爲經過配置 WebSphere Application Server 基礎設施儘量提升安全性而採起 的操做。當基礎設施已經構建完成並只涉及系統管理員時，一般採起這些措施。

應用程序配置：應用程序開發人員和管理員所採用的操做，這些操做在部署過程當中是可見的 。本質上說，這些是應用程序設計和實現決策，它們對 WebSphere Application Server 管理 員可見並能夠在部署過程當中檢驗（可能有一些難度）。這一部分將介紹大量技術，以進一步加 強安全性的不足之處；安全性是每一個參與應用程序設計、開發和部署的人員的責任。

應用程序設計和實現：開發人員和設計人員在開發期間所採起的對安全性相當緊要的操做， 可是這些操做可能對部署過程沒有影響。

應用程序隔離：這將單獨進行詳細討論，由於它涉及到的問題比較複雜。

在每一個部分中，都按優先級順序排列各類技術。固然，優先級是主觀的，可是咱們嘗試使用 這種方法大體肯定每一個領域中威脅的優先級：

基於計算機的威脅比網絡威脅的可能性小，由於生產環境中的計算機一般是限制訪問的。如 果您的環境中不是這種狀況，那麼這些威脅頗有可能會出現，應該首先限制對這些計算機的訪 問。

最嚴重的攻擊是隻使用 IP 鏈接執行的遠程攻擊。這意味着全部通訊都必須是通過身份驗證 的。

要保護通訊流，應該對其進行加密，但對 WebSphere Application Server 內部通訊流進行 加密不如對出入 WebSphere Application Server 的通訊流進行加密那麼重要。這是由於後一 種通訊流可能會穿越更多的節點，黑客能夠在這些節點上窺探通訊流。

SSL/TLS 概述

在本文的餘下部分提到 SSL 或 TLS 時，都使用 SSL。在可使用 SSL 的全部地方，也可 以使用 TLS；實際上若是鏈接的兩端都支持 TLS，在默認狀況下會使用 TLS。

SSL/TLS（後面統稱爲 SSL）是 WebSphere Application Server 安全性架構的一個關鍵組 件，普遍用於安全通訊。SSL 用於保護 HTTP 通訊流、IIOP 通訊流、LDAP 通訊流和 SOAP 通 信流。SSL 須要使用公鑰/私鑰對，對於 WebSphere Application Server，這些密鑰存儲在密 鑰存儲庫中。由於 SSL 對於保護基礎設施具備重要做用，因此咱們暫時離開本文的主線，介紹 SSL 的一些與 WebSphere Application Server 相關的重要方面。（這一討論有意只作簡要介 紹，只討論正確配置 SSL 所需的關鍵點。）

公鑰密碼術 (Public Key Cryptography) 從根本上講是基於公鑰/私鑰對的。這兩個密鑰在 密碼學意義上是相關聯的。關鍵的問題是這些密鑰是非對稱的；使用一個密鑰加密的信息能夠 使用另外一個密鑰來解密。私鑰天然是私有的。也就是說，您必須始終保護私鑰。若是其餘任何 人可以訪問私鑰，他們接下來就能夠用它來 「證實」 身份，並以您的名義進行活動；私鑰很 像密碼，只是更安全，更改比較困難。持有私鑰就是身份的證實。公鑰是密鑰對的一部分，它 能夠與其餘人分享。

若是有一種安全的方法能夠將公鑰分發給可信任的羣體，這就足夠了。然而，公鑰密碼術更 進一步，它引入了簽名公鑰的概念。簽名公鑰有數字簽名（很是相似於人工簽名）來代表簽署 者對公鑰的擔保。簽署者保證與簽名公鑰相對應的私鑰持有者就是由密鑰識別的羣體。這些籤 名公鑰被稱爲證書。衆所周知的簽署者被稱爲證書受權方 (CA)。也可使用公鑰簽署其自身。 這些被稱爲自簽名 (self-signed) 證書。自簽名證書的安全性不亞於由證書受權方簽署的證書 。它們只是乍看起來不易於管理。

圖 1 顯示使用 CA 建立和分發證書的基本過程；對於本例，證書用於經過 SSL 執行服務器 身份驗證。也就是說，服務器持有一個證書，用於向客戶機代表其身份。客戶機不持有證書， 所以對 SSL 是匿名的。

圖 1. 服務器 SSL 身份驗證：證書建立和分發

在查看此圖時，請注意客戶機必須持有簽署服務器生成的公鑰所用的證書。這是信任的關鍵 部分。因爲客戶機信任它擁有的任何證書（在本例中包括 CA 證書），因此它信任 CA 簽署的 證書。若是您使用自簽名證書，這沒有什麼價值，由於您須要手工地將這些自簽名證書分發到 每一個客戶機，而不是依靠可能已經在客戶機中構建的衆所周知的 CA 證書。這並不是不安全，但 若是您有許多客戶機，要將全部這些簽名證書（每一個服務器對應一個）分發到全部客戶機將會 變得很是難以管理。只分發一個簽署了許多證書的 CA 證書容易得多。

對於使用 SSL 的服務器身份驗證來講更是如此。在最初的握手階段以後，SSL 實際上將改 爲使用在握手期間生成的機密密鑰執行加密，以此保護通訊通道，但其細節與本討論無關。

當客戶機向服務器驗證其自身的身份時，雖然角色相反，但過程與此類似。爲了讓服務器對 客戶機進行身份驗證（這一般稱爲客戶機證書身份驗證，在與服務器身份驗證一塊兒使用時稱爲 雙向 SSL），客戶機必須持有一個私鑰和相應的證書，而服務器必須持有相應的簽名證書或客 戶機證書的拷貝。這對它來講是舉手之勞。請注意什麼不是必需的：SSL 證書身份驗證僅僅確 定證書的有效性，而不關心該證書表明誰。這是 SSL 後處理的責任。這有着重要的意義，稍後 咱們將會看到。

總之，由於 SSL 使用證書身份驗證，因此 SSL 鏈接的每一端都必須在密鑰存儲文件中持有 適當的密鑰。在配置 SSL 密鑰存儲庫時，須要考慮哪一羣體須要哪些密鑰的基本規則。一般， 這將讓您知道您須要什麼。

只使用 SSL 限制訪問

正如剛剛提到的，一旦 SSL 檢驗過證書，從 SSL 的角度來看身份驗證過程就結束了。接下 來理想的狀況應該是另外一個組件查看證書中的身份，而後使用該身份作出受權決策。受權決策 能夠是客戶機確認服務器是可信的（Web 瀏覽器只要覈實證書中的名稱與 Web 服務器的主機名 稱相同，就能夠確認服務器可信），也能夠是服務器提取用戶名，而後使用它爲之後的受權決 策建立證書（WebSphere Application Server 在對用戶進行身份驗證時採起的就是這種方式） 。遺憾的是，並不是全部的系統都有這樣的功能。對於這樣的系統，能夠利用流行的 SSL 技巧： 限制有效的證書。

在前面涉及客戶機身份驗證的場景中，客戶機提供一個證書，而後服務器根據可信的證書籤 署者集對其進行檢驗。一旦檢驗經過，SSL 握手就完成了。若是限制服務器上可信的簽署者， 就能夠限制誰能完成 SSL 握手。在自簽名證書的極端狀況下，能夠建立只有一個簽署者的情形 ：只有一份自簽名證書。這意味着只有一個有效的客戶機私鑰能夠用於鏈接此 SSL 端點：也就 是在建立自簽名證書時生成的私鑰。經過這種方式能夠輕鬆地限制誰能經過 SSL 鏈接到系統， 即便服務器端組件不提供受權。能夠將這看做是在網絡層上建立安全的可信隧道。假設一切都 已正確配置完成，那麼只有特定的可信客戶機才能夠經過這一通道鏈接。這在 WebSphere Application Server 中的幾種狀況下很是有用，這一點咱們後面將會討論。

管理 SSL

正如咱們已經看到的，WebSphere Application Server 在密鑰存儲文件中管理密鑰。有兩 種類型的密鑰文件：密鑰存儲庫和信任存儲庫。根據約定，信任存儲庫只不過是僅僅包含可信 的簽署者的密鑰存儲庫。所以，應該將 CA 證書和其餘簽名證書放入信任存儲庫中，並將私有 信息（包含私鑰的我的證書）放入密鑰存儲庫中。

遺憾的是，這個簡單的系統存在一個問題。大多數 WebSphere Application Server 都使用 PKCS12 格式。（事實上，WebSphere Application Server SSL 配置支持三種現代密鑰數據庫 格式：JKS、JCEKS 和 PKCS12。）IBM HTTP Server 和 WebSphere Application Server Web 服務器插件使用一種比較老的密鑰格式，KDB 格式（或更準確地說是 CMS 格式）。這兩種格式 在功能上類似，但在格式上不兼容。所以，必須注意不能將它們弄混。

WebSphere Application Server SSL 配置

從 WebSphere Application Server V6.1 開始，產品中爲 管理證書和 SSL 提供了健壯的 基礎設施。本文的其他部分假設您熟悉這些基礎設施。

增強 WebSphere Application Server

WebSphere Application Server V6.1 和更高版本的設計原則是確保默認狀況下的安全性。 目標是在最多見的配置和比較簡單的環境中，這個產品在默認狀況下具備合理的安全水平，盡 管這個目標尚未完美地實現。顯然，複雜的環境會產生難以預料到的獨特問題，可是對於比 較簡單的環境，咱們的目標是讓默認的安裝和配置可以提供合理的系統安全水平；沒有徹底安 全的系統，由於這樣的東西是不可能存在的。咱們也不試圖消除每一個漏洞，由於許多漏洞的風 險很小，並且在默認狀況下封閉它們會顯著增長應用程序開發、管理或兼容性的複雜程度。但 是，若是咱們認爲對於大多數客戶機能夠以某種方式合理地消除某一漏洞，咱們就這麼作。

基於基礎設施的預防措施

在保護基礎設施時，首先必須理解要保護的組件。與任何漏洞分析同樣，咱們從肯定組件及 其外部通訊路徑開始。（這一分析不會揭示內部應用程序漏洞，但會揭示其餘大多數漏洞。） 這有助於檢查標準的 WebSphere Application Server 拓撲並瞭解全部網絡鏈路和協議（圖 2 ）。做爲關注安全性的人員，您須要瞭解全部這些鏈路並專一於保護它們。這些鏈路表明前面 提到的粗粒度系統邊界。

圖 2. 網絡鏈路圖

在圖 2 中，鏈路上的字母表示在那些通訊鏈路上使用的協議。對於每一個協議，咱們列出其 用途並提供一些關於防火牆友好性的信息，由於這對於後面的討論很重要。協議以下：

H = HTTP 通訊流

用途：瀏覽至 Web 服務器、從 Web 服務器到應用服務器的通訊以及管理 Web 客戶機。

防火牆友好。

W= WebSphere Application Server 內部通訊

用途：管理客戶機和 WebSphere Application Server 內部服務器管理通訊流。WebSphere Application Server 內部通訊使用如下幾種協議之一：

RMI/IIOP 或 SOAP/HTTP：管理客戶機協議是可配置的。

文件傳輸服務（dmgr 到節點代理）：使用 HTTP(S)。

DCS (Distributed Consistency Service)：使用專有協議。用於內存到內存複製、有狀態 會話 EJB、動態緩存和高可用性管理器。

SOAP/HTTP 防火牆友好。DCS 能夠是防火牆友好的。

I = RMI/IIOP 通訊

用途：EJB 客戶機（獨立的客戶機和 Web 容器）。

因爲使用動態端口和嵌入式 IP 地址（這會影響防火牆執行網絡地址轉換），因此一般防火 牆對其不友好。

M = SIB 消息傳遞協議

用途：從 JMS 客戶機到消息傳遞引擎的通訊。

協議：專有協議。

防火牆友好，由於能夠指定使用的端口。防火牆極可能對 NAT 不友好。

MQ = WebSphere MQ 協議

用途：MQ 客戶機（真實客戶機和應用服務器）。

協議：專有協議。

防火牆可用（有大量端口可供考慮）。請參閱 WebSphere MQ support pac MA86。

L = LDAP 通訊

用途：WebSphere Application Server 對註冊表中的用戶信息進行驗證。

協議：按照 LDAP RFC 中的定義進行格式化的 TCP 流。

防火牆友好。

J = 經過廠商 JDBC 驅動程序進行的 JDBC 數據庫通訊

用途：應用程序 JDBC 訪問和 WebSphere Application Server 會話數據庫訪問。

協議：每一個數據庫專有的網絡協議。

防火牆方面取決於數據庫（一般是防火牆友好的）。

S = SOAP

用途：SOAP 客戶機。

協議：一般爲 SOAP/HTTP。

當使用 SOAP/HTTP 時防火牆友好。

如圖 2 所示，典型的 WebSphere Application Server 配置有大量網絡鏈路。儘量地保 護每一個鏈路上的通訊流以防範入侵者，這是很是重要的。在本部分剩下的內容中，將討論保護 剛剛描述的基礎設施所需的步驟。下面的列表按優先級次序列出每一個步驟。最重要（最關鍵） 的措施列在最前面。靠後的措施重要性逐漸下降。由您決定您的組織應該完成這個列表中的哪 些措施。

將 Web 服務器放在 DMZ 中，可是不放置 WebSphere Application Server

將生產網絡與內部網隔離開

對瀏覽器訪問使用 HTTPS

配置安全文件傳輸

保持補丁和修復最新

啓用應用程序安全性

限制對 WebSphere MQ 消息傳遞的訪問

保護消息傳遞引擎之間的通訊流

增強 Web 服務器和主機

刪除 Web 服務器和插件安裝程序遺留的 JRE

增強代理

謹慎地配置和使用信任關聯攔截器 (trust association interceptor)

謹慎地使用證書身份驗證

考慮對 Web 服務器到 WebSphere Application Server 的 HTTP 鏈路進行身份驗證

不要在生產環境中運行示例

選擇合適的進程身份

保護配置文件和私鑰

加密從 WebSphere Application Server 到 LDAP 的鏈路

確保只經過 HTTPS 傳輸 LTPA cookie

確保按期改變 LTPA 加密密鑰

不要在命令行上指定密碼

建立單獨的管理用戶 ID

利用管理角色

考慮加密 Web 服務器到 Web 容器的鏈路

只使用新的 LTPA cookie 格式

加密 WebSphere MQ 消息傳遞鏈路

加密 Distribution and Consistency Services (DCS) 傳輸鏈路

保護從應用服務器到數據庫的鏈路

考慮把 cookie 限制爲 HTTP Only

經過培訓讓用戶正確地理解證書警告

謹慎地限制可信的簽署者

限制爲強密碼

強制 CSIv2 傳輸使用 SSL

考慮端口過濾

禁用不使用的端口

考慮禁用密碼緩存

考慮啓用 FIPS 聽從性

1. 將 Web 服務器放在 DMZ 中，可是不放置 WebSphere Application Server

在典型的 DMZ 配置中，有一個外部防火牆、一個組件儘量少的 DMZ 網絡以及一個保護內 部生產網絡的內部防火牆。

DMZ （見邊欄）有三個基本原則須要考慮：

來自外 部的入站網絡通訊流必須終止於 DMZ 中。網絡傳輸負載平衡器（例如 Network Dispatcher） 自身並不知足這種需求。

從 DMZ 到內部網的通訊流類型和開放端口數量必須進行限制 。

必須對在 DMZ 中運行的組件進行增強，並遵循最少功能和最低複雜度的原則。

所以，通常將 Web 服務器放在 DMZ 中，將 WebSphere Application Server 應用服務 器放在內部防火牆內。這是比較理想的，由於這樣作可使 Web 服務器有很是簡單的配置，需 要的軟件不多。DMZ 的另外一個做用是終止入站請求。最後，內部防火牆上必須開放的唯一端口 是用於目標應用服務器的 HTTP(S) 端口。這些步驟使 DMZ 對攻擊者的防範很是嚴格。若是願 意，也能夠把安全的代理服務器放在 DMZ 中，替代 Web 服務器或與 Web 服務器共存。

若是把 WebSphere Application Server 放在 DMZ 中的計算機上，則必須在那些計算機上 安裝更多的軟件，而且必須在內部防火牆上開放更多的端口，以使 WebSphere Application Server 能夠訪問生產網絡。這極大地下降了 DMZ 的價值。

能夠在 DMZ 中放置 Web 服 務器以外的其餘組件。把安全代理放在 DMZ 中也是合理的，好比 IBM Tivoli® Access Manager WebSEAL、WebSphere Application Server V7 安全代理或 IBM WebSphere DataPower® 等增強了安全保護的組件。關鍵是放在 DMZ 中的組件必須不是複雜的應用服 務器，必須增強了安全保護，還必須終止入站鏈接。

2. 將生產網絡與內部網隔離開

如今，大多數組織都理解 DMZ 將 Internet 上的外人與內部網隔離開的價值。然而，很是 多的組織沒有意識到許多入侵者是來自內部的。正如前面提到的，須要同時防範來自內部和外 部的威脅。正如保護本身免受來自大量不可信的 Internet 用戶攻擊同樣，您也應該保護生產 系統免受大量不可信的內部網用戶攻擊。

可使用防火牆將生產網絡與內部網絡隔離開。這些防火牆看似比面向 Internet 的防火牆 隨意得多，但仍然可以防護許多形式的攻擊。經過應用這一步驟和前一步驟，應該能夠創建圖 3 所示的防火牆拓撲。

注意，咱們在防火牆的邊緣放置了 wsadmin。這樣作是爲了試圖說明，雖然最好只讓 wsadmin 在生產網絡內（受保護的區域內）運行，但也能夠把 wsadmin 訪問限制爲與管理員桌 面對應的特定地址，從而很是容易地穿過防火牆訪問 wsadmin。圖 3 還在邊緣上顯示 EJB 客 戶機，由於它們可能位於防火牆的任一側。

圖 3. 推薦的防火牆配置

這裏只顯示單個防火牆，而不是面向內部網的整個 DMZ，由於這是最多見的拓撲。然而，完 整的 DMZ（以及內部 DMZ 中的 Web 服務器）愈來愈常見了，它們保護生產網絡免受來自非生 產內部網的攻擊。這的確是一種合理的方法。

3. 對瀏覽器訪問使用 HTTPS

雖然能夠經過未加密的通道發送 LTPA 令牌，可是爲了最大程度地加以保護，最好經過加密 鏈路發送它們。若是 LTPA 令牌被成功截獲，則竊取者能夠冒充該用戶的身份，直到令牌到期 爲止。

若是站點要執行任何身份驗證或者有任何應該保護的活動，則須要對從瀏覽器到 Web 服務 器的訪問使用 HTTPS。若是不使用 HTTPS，則密碼、用戶活動、WebSphere Application Server 會話 cookie 和 LTPA 安全令牌（見邊欄）等信息可能被入侵者看到，由於通訊流要穿 過外部網絡。

對於在執行身份驗證以前容許 HTTP 通訊流的應用程序，必定要密切注意 cookie。若是一 個 cookie（好比 JSESSIONID）是在使用 HTTPS 以前設置的，那麼在使用 HTTPS 以後它可能 帶來風險，由於入侵者可能已經修改或捕獲了它。這正是 WebSphere Application Server 對 通過身份驗證的用戶使用單獨的 cookie 的緣由。另外一種更狡猾的攻擊方法是，入侵者能夠修 改經過 HTTP 返回的任何頁面 —— 甚至包括頁面中嵌入的 URL。所以，用戶可能會單擊頁面 上看似安全的 URL，可是他實際上會被轉到入侵者的站點上。

4. 配置安全文件傳輸

（在 V7 中默認狀況下已經解決）

部署管理器使用文件傳輸協議向節點代理髮送配 置更新。在 V6.1 和之前的版本中，在默認狀況下這是未通過身份驗證的協議。更準確地說， 節點代理使用未通過身份驗證的文件傳輸服務從部署管理器獲取管理配置更新。所以，任何外 來的客戶機均可能鏈接到部署管理器並上傳任意文件。若是上傳無數大文件，操做系統會耗盡 磁盤空間，致使總體故障。理論上也能夠下載從部署管理器複製到節點的文件。然而，考慮到 這些文件的短暫特性，這種可能性不大。

爲了確保部署管理器只響應來自計算單元中可 信的服務器的文件傳輸請求，必須安裝 filetransferSecured 應用程序並替換現有的不安全的 應用程序。由於此應用程序是一個系統應用程序，因此它一般不可見，但確實存在。IBM 爲此 提供了一個腳本，參見 WebSphere Application Server Information Center。清單 1 給出安 裝 filetransferSecured 應用程序的步驟（這裏顯示的是 Windows® 示例，但 UNIX® 基本相同）。清單 1 採用 WebSphere Application Server Network Deployment；若是使用的 是 WebSphere Application Server Base，則服務器名稱多是 server1 而不是 dmgr。

清單 1. 安裝 filetransferSecured

cd　\bin　
wsadmin.bat　-user　　-password　　
wsadmin>source　../../../bin/redeployFileTransfer.jacl　
wsadmin>fileTransferAuthenticationOn　　　dmgr　
wsadmin>$AdminConfig　save　

若是沒有記住計算單元名稱和節點名稱，能夠在概要的 config 目錄中找到它們。請記住， 這個節點是部署管理器的節點，所以名稱結尾多是 「CellManager」。

5. 保持補丁和修復最新

本文假設您已經應用了最新的補丁包（到編寫本文時是 6.1.0.27 和 7.0.0.7）以及最近發 布的全部安全 APAR。這些補丁包和 APAR 解決或堵住了本文未提到的其餘漏洞，因此要確保系 統處於最新的修復級別並確認應用了全部已知漏洞的補丁，這很是重要。固然，隨着時間的推 移，應該常常關注新發布的安全修復。毫無疑問，之後會不斷髮現新問題。

與其餘複雜產品同樣，IBM 會不時地發現和修復 WebSphere Application Server、IBM HTTP Server 和其餘產品中的安全性 bug。保持這些修復最新是很重要的。建議訂閱您使用的 產品的支持公告板，對於 WebSphere Application Server，要常常訪問您的版本的 security bulletin site。這些公告板經常包含最近發現的安全性 bug 和修復通知。能夠確定，潛在的 入侵者會很快得知那些安全性漏洞。您越早採起行動越好。

在 WebSphere Application Server security 頁面上，能夠找到關於 WebSphere Application Server 安全性的通常性信息，包括對增強 WebSphere Application Server 基礎 設施的建議。

6. 啓用應用程序安全性

在默認狀況下，WebSphere Application Server 啓用管理安全性。所以，在大多數狀況下 ，基礎設施默認地爲管理通訊流提供合理的身份驗證、受權和加密。在啓用管理安全性時，部 署管理器和應用服務器之間的 WebSphere Application Server 內部鏈路以及從管理客戶機 （Web 和命令行）到部署管理器的通訊流是通過加密和身份驗證的（圖 3）。這意味着，在運 行管理工具時，須要對管理員進行身份驗證。後面會討論一些例外狀況。

除了在管理方面利用應用服務器的安全性以外，強烈建議在應用程序安全性方面利用它。這 樣作可讓應用程序可以訪問強大、健壯且基於標準的安全性基礎設施。在不利用應用服務器 安全性的應用程序中，經常會發現很嚴重的安全性漏洞。設計和實現安全的分佈式基礎設施並 不容易。

要想啓用應用程序安全性，應該進入全局安全性面板並選擇 Enable application security （不須要啓用 Java 2 安全性；正如後面討論的，它經常不合適），見圖 4。

圖 4. 應用程序安全性

警告：僅僅啓用應用程序安全性並不能確保應用程序是安全的。這只是讓應用程序可以利用 應用服務器提供的安全特性（包括 Java EE 安全性）。後面會進一步討論這個主題。

7. 限制對 WebSphere MQ 消息傳遞的訪問

若是使用 WebSphere MQ 做爲消息傳遞提供者，則須要經過其餘技術來提供隊列受權。當使 用客戶機/服務器模式時（綁定模式依賴於計算機中的進程到進程身份驗證），在默認狀況下 WebSphere MQ 並不執行任何用戶身份驗證。事實上，當在鏈接工廠上爲 WebSphere MQ 指定用 戶 ID 和密碼時，這些值會被 WebSphere MQ 忽略。

WebSphere MQ 安全性警告

由於本文主要關注 WebSphere Application Server 安全性，這一節只討論如何保護從應用 服務器到 WebSphere MQ 的鏈路。這並不能保證 WebSphere MQ 自己是安全的。

解決這個問題的一種方法是，在 WebSphere MQ 服務器端實現本身的定製 WMQ 身份驗證插 件來對 WebSphere Application Server 發送的用戶 ID 和密碼進行驗證。第二種（可能更簡 單的）方法是將 WebSphere MQ 配置爲使用 SSL 來進行客戶機身份驗證，而後確保只有 WebSphere Application Server 服務器持有用於鏈接 WebSphere MQ 的證書。

8. 保護消息傳遞引擎之間的通訊流

（在 V7 中默認狀況下已經解決。）

在 V7 以前，SIBus 在默認狀況下提供客戶機的身份驗證和受權，可是不要求消息傳遞引擎 相互驗證身份。這是一個安全性漏洞，由於入侵者可能能夠假裝成消息傳遞引擎並截獲總線通 信流。在總線安全性面板上指定身份驗證別名，就能夠配置引擎間身份驗證（和隱式受權）， 見圖 5。

圖 5. 消息傳遞引擎身份驗證

9. 增強 Web 服務器和主機

若是採用 步驟 1 中推薦的標準拓撲，則 Web 服務器是在 DMZ 中運行。由於 DMZ 是防範 潛在入侵者的第一道防線，因此必須特別注意增強此服務器。

本文不討論增強 Web 服務器 的具體方法，但您應該在操做系統增強、限制裝載的 Web 服 務器模塊和其餘 Web 服務器配置步驟上下足功夫。

在增強 Web 服務器時，有一個 WebSphere Application Server 特有的問題須要考慮。由 WebSphere Application Server 管理基礎設施來管理 Web 服務器是可能的。雖然它使用方便 看似好事，但這帶來了嚴重的安全問題。有兩種方式能夠管理 Web 服務器：

使用託管節點要求在 Web 服務器（一般位於 DMZ 中）上放置一個節點代理，並且要求該代 理做爲 WebSphere Application Server 計算單元的一部分。這從安全角度來看是徹底不可接 受的，所以不該該使用，除非在極少數不須要 DMZ 的狀況下。這種方式不可接受的緣由有兩點 ：

首先，節點代理是計算單元的一個全功能成員，所以它有徹底的管理權限。若是它在 DMZ 中被攻破，則整個計算單元都將受到危害。

第二，WebSphere Application Server 是一個強大的大型產品，所以很難增強安全性，這 樣的產品不該該放在 DMZ 中。

第二種方式要求使用 IBM HTTP Server 和配置 HTTP 管理服務器。在這種狀況下，部署管 理器將管理請求發送到在 Web 服務器主機上運行的 HTTP 管理服務器。這看似是一種比較好的 方法，可是許多人仍然認爲這有風險，最好在 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 防火牆。

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 配置

相互 SSL 是經過三個單獨的很是重要的步驟配置的：

必須把 WebSEAL 配置爲使用 SSL 與 WebSphere Application Server 進行通訊，並且該 SSL 配置必須包含只有應用服務器 Web 容器才知道的客戶機證書。

必須配置應用服務器 Web 容器以執行客戶機證書身份驗證。還必須更改其信任存儲庫，使 之只包含 WebSEAL 正在使用的客戶機證書。這個步驟相當重要，由於只有這樣才能保證對應用 服務器 Web 容器的請求僅來自 WebSEAL，而非某個入侵者（僅僅使用相互身份驗證的 SSL 是 不夠的）。還必須將非 HTTPS 傳輸從 Web 容器中刪除，以確保在與服務器聯繫時只使用相互 身份驗證的 SSL。

必須在 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 聲明這個證書再也不可信了。爲了讓證書撤消起做用，證書的接受者必須檢 查它是否仍然有效。許多人忽視了這一點。若是不適當地支持撤消，那麼使用證書執行身份驗 證是很愚蠢的。可使用多種技術（這裏不詳細討論）；簡單地說，能夠選用如下技術：

Online Certificate Status Protocol (OCSP)。

Certificate Revocation List，能夠經過證書中嵌入的端點或分發點信息找到這個列表。

若是證書數量不多，那麼只需頒發自簽名證書。只需刪除相應的簽署者，就能夠撤消證書。

WebSphere Application Server 支持全部這些技術，可是都須要配置。必定要執行相應的 配置步驟。

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 容器設置爲忽略來自客戶機的證書信息

若是目標是支持向 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 Information Center。