安全性加強概述和方法
簡介
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 <profilehome>\bin
wsadmin.bat -user <wasadminuser> -password <waspassword>
wsadmin>source ../../../bin/redeployFileTransfer.jacl
wsadmin>fileTransferAuthenticationOn <your cell name> <dmgr node name> 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。
