WebSphere Application Server V7 高階安全性加強，第 1 部分

簡介： 安全性不僅僅是在網路邊界上保護您不受外部攻擊的防火牆。安全性是一組旨在儘可能加強系統安全的複雜的操作和過程。本文討論安全性概念的多個方面，包括 IBM® WebSphere® Application Server 的安全性架構，討論如何增強 WebSphere Application Server 環境的安全性。本文是 以前的文章 的修訂，針對 WebSphere Application Server V6.1 和 V7 做了大量更新，只關注安全性加強方面。這是由兩部分組成的文章的第 1 部分。 本文來自於 IBM WebSphere Developer Technical Journal 中文版。

簡介

IBM WebSphere Application Server 的安全性在每個版本中都有所改進。除了在新版本中增加新功能之外，我們還不斷增強產品的預設安全性。我們通過改進預設設定不斷提高滿足預設安全性這一關鍵原則的程度。本文的前一個版本 主要關注 WebSphere Application Server V6 和那個版本所需的加強步驟。在後續 WebSphere Application Server 版本中，顯著減少了加強步驟的數量，更重要的是，保留的大多數步驟不太關鍵了。因此，現在有必要用新資訊更新本文。

本文首先簡單討論安全性為什麼重要以及加強系統的困難，然後討論如何加強 WebSphere Application Server 環境以解決各種安全性漏洞。因為本文主要討論加強，一些資訊是概括性的，沒有進行詳細分析。我們儘可能提供相關詳細資訊的適當參考資料，讓您能夠進一步研究相關的子主題。

儘管本文中的資訊基於 IBM WebSphere Application Server V7，但是討論的大多數問題同樣適用於 V6.1。對於某個版本特有的問題，我們會專門指出。如果您使用以前版本的 WebSphere Application Server，請參考 以前的文章，因為有顯著差異。

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

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

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

• 僱員可能對公司有攻擊動機。僱員具有非常高的內部訪問級別和系統知識水平，但他們的資源和黑客技能可能很有限。
• 外部黑客也許是安全性攻擊方面的專家，但是他們對您可能沒有攻擊動機。
• 外國間諜機構可能對攻擊您很感興趣（這取決於您的業務）並擁有極其豐富的資源。

入侵者可能出於兩個原因之一入侵您的系統：為了獲取他們本不應該擁有的資訊，或者為了以某種方式改變系統的正常行為。在後一種情況中，通過改變系統行為，他們可以嘗試執行對其有利的事務，或者只是為了用某種有意思的方式導致系統崩潰，以造成對您的組織的損害。

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

同時關注內部和外部威脅

安全性措施不應該僅僅視為阻擋 “外人” 的大門。那是一個過於簡單化的觀點。當前，許多組織將他們的安全性措施完全集中在針對組織以外的人群，他們錯誤地認為只有外人才是危險的。實際上並不是這樣。對於大型公司，往往有數千人能夠訪問內部網路（其中許多人並不是僱員）。這些人都可能成為入侵者，而且由於他們在內部，他們訪問網路更方便。常常只需把膝上型電腦插上網線，就能夠訪問公司網路。一些研究表明，有將近一半的入侵是 由組織內部的僱員或者承包人造成的（或涉及到他們）。

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

安全性措施應該努力保護系統不被所有的潛在入侵者攻擊，這就是本文為什麼如此之長的原因。安全性不僅僅是在網路邊界上保護系統不受 “外部” 攻擊的防火牆。它是一組旨在儘可能加強系統安全的複雜的操作和過程。

限制和現實狀況

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

1. 分析攻擊的各個方面。
2. 考慮每種攻擊的風險。
3. 確定攻擊成功而導致安全性被破壞的可能性。
4. 評估為防止每種攻擊要付出的代價。

在估計安全性被破壞而造成的損失時，不要忘記安全性被破壞會導致系統使用者對系統失去信心。因此，“安全性被破壞的代價” 可能包括非常高昂的間接代價（比如，失去投資者的信任）。

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

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

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

希望瞭解更多資訊的讀者請查閱 參考資料 部分。特別是 我的網站 提供一些應用程式安全性基本知識的概要性說明，不過有些內容是過時的。

社會工程

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

總的系統觀點：細節問題

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

大多數邊界是很明顯的：網路連線、程式與程式的通訊、檔案系統、作業系統介面等等，但是有些邊界不容易辨別。例如，如果一個應用程式使用 WebSphere Application Server 中的 J2C 資源，那麼必須考慮另一個應用程式試圖訪問這些資源的可能性。這是因為第一個應用程式和 WebSphere Application Server 之間以及第二個應用程式和 WebSphere Application Server 之間都存在系統邊界。可能這兩個應用程式都可以訪問這個資源（實際上它們確實可以）。這可能是不合理的共享。

要防止各種形式的攻擊，可以應用許多眾所周知的技術。對於較低層的基於網路的攻擊，可以應用加密和網路過濾。這樣可以拒絕入侵者檢視或訪問他們不應該看到的內容。還依賴作業系統提供的機制來保護作業系統資源不被濫用。例如，不希望普通使用者級程式碼能夠訪問系統匯流排以及直接讀取內部通訊。還利用大多數現代作業系統對系統 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）是 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 配置有大量網路鏈路。儘可能地保護每個鏈路上的通訊流以防範入侵者，這是非常重要的。在本部分剩下的內容中，將討論保護剛剛描述的基礎設施所需的步驟。下面的列表按優先順序次序列出每個步驟。最重要（最關鍵）的措施列在最前面。靠後的措施重要性逐漸降低。由您決定您的組織應該完成這個列表中的哪些措施。

1. 將 Web 伺服器放在 DMZ 中，但是不放置 WebSphere Application Server
2. 將生產網路與內部網隔離開
3. 對瀏覽器訪問使用 HTTPS
4. 配置安全檔案傳輸
5. 保持補丁和修復最新
6. 啟用應用程式安全性
7. 限制對 WebSphere MQ 訊息傳遞的訪問
8. 保護訊息傳遞引擎之間的通訊流
9. 加強 Web 伺服器和主機
10. 刪除 Web 伺服器和外掛安裝程式遺留的 JRE
11. 加強代理
12. 謹慎地配置和使用信任關聯攔截器 (trust association interceptor)
13. 謹慎地使用證照身份驗證
14. 考慮對 Web 伺服器到 WebSphere Application Server 的 HTTP 鏈路進行身份驗證
15. 不要在生產環境中執行示例
16. 選擇合適的程式身份
17. 保護配置檔案和私鑰
18. 加密從 WebSphere Application Server 到 LDAP 的鏈路
19. 確保只通過 HTTPS 傳輸 LTPA cookie
20. 確保定期改變 LTPA 加密金鑰
21. 不要在命令列上指定密碼
22. 建立單獨的管理使用者 ID
23. 利用管理角色
24. 考慮加密 Web 伺服器到 Web 容器的鏈路
25. 只使用新的 LTPA cookie 格式
26. 加密 WebSphere MQ 訊息傳遞鏈路
27. 加密 Distribution and Consistency Services (DCS) 傳輸鏈路
28. 保護從應用伺服器到資料庫的鏈路
29. 考慮把 cookie 限制為 HTTP Only
30. 通過培訓讓使用者正確地理解證照警告
31. 謹慎地限制可信的簽署者
32. 限制為強密碼
33. 強制 CSIv2 傳輸使用 SSL
34. 考慮埠過濾
35. 禁用不使用的埠
36. 考慮禁用密碼快取
37. 考慮啟用 FIPS 遵從性

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

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 所示的防火牆拓撲。（有關 WebSphere Application Server 防火牆埠分配的更多資訊，請參閱 WebSphere Application Server V5 中的防火牆埠分配。）

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

圖 3. 推薦的防火牆配置

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

3. 對瀏覽器訪問使用 HTTPS

如果站點要執行任何身份驗證或者有任何應該保護的活動，則需要對從瀏覽器到 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. 保持補丁和修復最新

與其他複雜產品一樣，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 伺服器端實現自己的定製 WMQ 身份驗證外掛來對 WebSphere Application Server 傳送的使用者 ID 和密碼進行驗證。第二種（可能更簡單的）方法是將 WebSphere MQ 配置為使用 SSL 來進行客戶機身份驗證，然後確保只有 WebSphere Application Server 伺服器持有用於連線 WebSphere MQ 的證照。（更多資訊參見 保證 WebSphere Application Server 和 WebSphere MQ 之間連線的安全；這篇文章有點兒過時了，但是相同的原理和技術也適用於這兩個產品的新版本。在實現其中提到的技術時，應該考慮到產品的變化。）

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

（在 V7 中預設情況下已經解決。）

在 V7 之前，SIBus 在預設情況下提供客戶機的身份驗證和授權，但是不要求訊息傳遞引擎相互驗證身份。這是一個安全性漏洞，因為入侵者可能可以偽裝成訊息傳遞引擎並截獲匯流排通訊流。在匯流排安全性皮膚上指定身份驗證別名，就可以配置引擎間身份驗證（和隱式授權），見圖 5。

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

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 的情況下。這種方式不可接受的原因有兩點：
  • 首先，節點代理是計算單元的一個全功能成員，因此它有完全的管理許可權。如果它在 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 是通過三個單獨的非常重要的步驟配置的：

  1. 必須把 WebSEAL 配置為使用 SSL 與 WebSphere Application Server 進行通訊，而且該 SSL 配置必須包含只有應用伺服器 Web 容器才知道的客戶機證照。
  2. 必須配置應用伺服器 Web 容器以執行客戶機證照身份驗證。還必須更改其信任儲存庫，使之只包含 WebSEAL 正在使用的客戶機證照。這個步驟至關重要，因為只有這樣才能保證對應用伺服器 Web 容器的請求僅來自 WebSEAL，而非某個入侵者（僅僅使用相互身份驗證的 SSL 是不夠的）。還必須將非 HTTPS 傳輸從 Web 容器中刪除，以確保在與伺服器聯絡時只使用相互身份驗證的 SSL。
  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 宣告這個證照不再可信了。為了讓證照撤消起作用，證照的接受者必須檢查它是否仍然有效。許多人忽視了這一點。如果不適當地支援撤消，那麼使用證照執行身份驗證是很愚蠢的。可以使用多種技術（這裡不詳細討論）；簡單地說，可以選用以下技術：

  • 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。

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 技巧來限制具有訪問許可權的群體。具體地說，需要執行以下操作：

1. 為 Web 容器建立一個金鑰儲存庫和信任儲存庫，為 Web 伺服器外掛建立一個金鑰儲存庫。
2. 從所有金鑰儲存庫（包括信任儲存庫）刪除所有現有的簽名證照。此時，不能使用任何金鑰儲存庫來檢驗證照。這樣做是有意的。
3. 在這兩個金鑰儲存庫中建立自簽名證照，並只匯出該證照（而不是私鑰）。一定要記錄這些證照的到期時間。當外掛證照到期之後，它就不能聯絡 Web 容器了！將從 Web 容器金鑰儲存庫中匯出的證照匯入到外掛金鑰儲存庫中。將外掛證照匯入到 Web 容器信任儲存庫中。現在，每一端都只包含一個簽名證照。這意味著只能使用它們檢驗一個證照 —— 為對方建立的自簽名證照。
4. 將新建立的金鑰儲存庫安裝到 Web 容器和 Web 伺服器外掛中。

15. 不要在生產環境中執行示例

WebSphere Application Server 附帶了幾個非常好的示例，它們演示 WebSphere Application Server 的各個部分。這些示例不是為在生產環境中使用準備的。不要在生產環境中執行它們，因為它們會帶來嚴重的安全風險。特別是 showCfg 和 snoop Servlet 會向外部人員提供大量關於您的系統的資訊。這正是您不希望潛在的入侵者獲得的資訊。只要不在生產環境中執行 server1（它包含這些示例），就很容易解決這個問題。如果使用的是 WebSphere Application Server Base，實際上應該從 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 許可權。
• 這種方法的主要價值在於控制應用程式對檔案系統的訪問。但是，使用 Java 2 許可權也可以實現這一點。
• 這種方法會造成應用程式互相隔離的錯覺。其實不是。WebSphere Application Server 內部安全模型基於 J2EE 和 Java 2 安全性，不受作業系統許可權的影響。因此，如果選擇使用這種方法來保護自己免受 “惡意” 應用程式的侵害，則方法的方向錯了。

第一種方法明顯是不可取的，因為作為一般的最佳實踐，如果可以的話，最好避免以 root 身份執行任何程式。這樣就只剩下第二種方法，它是完全受支援的。在某些很少見的情況下，並不關心應用程式隔離，但是希望以不同的作業系統身份執行應用程式以便審計，那麼可以使用第三種方法。這從安全性的角度來看沒有價值，而且實際上會略微增加風險，但是有可能使用作業系統級審計。

17. 保護配置檔案和私鑰

應該利用作業系統檔案許可權來限制對 WebSphere Application Server 檔案的檔案系統訪問。與任何複雜的系統一樣，WebSphere Application Server 使用和維護大量敏感資訊。一般來講，不應該有人對大多數 WebSphere Application Server 資訊具有讀或寫許可權（見邊欄）。特別是 WebSphere Application Server 配置檔案 (/config)，它既包含配置資訊，也包含密碼。

另外，應該注意避免不小心共享金鑰。例如，不要在生產環境中使用與其他環境中相同的金鑰。許多人對開發和測試計算機及他們自己的金鑰有訪問許可權。應該謹慎地保護生產環境用的金鑰。

如果不謹慎地控制誰對檔案系統有寫訪問許可權，使用者只需手工編輯配置檔案，就可以破壞產品的安全性控制（比如審計）。

18. 加密從 WebSphere Application Server 到 LDAP 的鏈路

當使用 LDAP 登錄檔時，WebSphere Application Server 會使用標準的 ldap_bind 來驗證使用者密碼。這要求 WebSphere Application Server 將使用者密碼傳送到 LDAP 伺服器。如果該請求沒有加密，則黑客可以使用網路嗅探器來竊取用於身份驗證的使用者密碼（包括管理密碼！）。大多數 LDAP 目錄都支援 LDAP over SSL，並且可以把 WebSphere Application Server 配置為使用它。在 LDAP 使用者登錄檔皮膚中（請參見圖 7），選中 SSL enabled 選項，然後配置適合您的 LDAP 目錄的 SSL 配置。很可能需要將用於 LDAP 伺服器證照的簽名金鑰（證照）放在信任儲存庫中。最好是建立只供 LDAP 使用的新的 SSL 配置，以避免給當前使用 SSL 的其他領域造成問題。

圖 7. 啟用 LDAP SSL

如果使用定製的登錄檔，顯然需要使用任何可用的機制來保護該通訊流。

19. 確保只通過 HTTPS 傳輸 LTPA cookie

Web 應用程式使用 cookie 跨請求跟蹤使用者。儘管這些 cookie 本身通常不包含敏感資訊，但是它們把使用者與後端系統上使用者的現有狀態聯絡起來，如果入侵者捕獲了您的 cookie，他們就有可能使用這個 cookie 偽裝成您。因為網路通訊流常常通過不可信的網路傳輸（考慮一下您喜歡的 WiFi 熱區），資料包很容易被捕獲，所以應該使用 SSL 加密重要的 Web 通訊流。這包括重要的 cookie。顯然，如果所有請求都使用 SSL，cookie 就會得到保護。但是，許多應用程式（可能偶爾）通過 HTTP 傳送請求，而沒有使用 SSL，這就可能暴露 cookie。幸運的是，HTTP 規範允許指定瀏覽器只通過 SSL 傳送 cookie。

對於 WebSphere Application Server，最重要的 cookie 是 LTPA cookie，因此，它應該配置為只通過 SSL 傳送。

圖 8. 把 LTPA cookie 限制為只使用 SSL

通過在會話管理皮膚上指定相似的設定，還可以把 HTTP Session（預設情況下是 JSESSION） cookie 限制為只使用 SSL。

警告：在安裝 APAR PM00610 之前，Requires SSL 標誌在 WebSphere Application Server V7 中無效。一定要安裝它。

20. 確保定期改變 LTPA 加密金鑰

WebSphere Application Server 使用 LTPA 加密金鑰加密各種使用者令牌（包括 LTPA cookie）。與任何密碼術金鑰一樣，應該定期改變這些金鑰。根據 WebSphere Application Server 和補丁級別不同，自動金鑰生成在預設情況下可能啟用了，也可能關閉了；版本越新，預設情況下它關閉的可能性越大。

應該確保定期改變 LTPA 加密金鑰。可以啟用自動 LTPA 金鑰替換（見圖 9），也可以手工地重新生成金鑰（見圖 10）。無論選擇哪種方式，一定要考慮 LTPA 金鑰不一致的問題：

• 首先，如果計算單元中的某些節點在一段時間（比如金鑰壽命的兩倍）內一直停機，它們就會喪失通訊能力。
• 第二，如果與其他元件（比如另一個計算單元或 WebSphere DataPower）共享 LTPA 金鑰，那麼在改變金鑰時，就需要在所有地方更新它們，這通常會造成停機。

圖 9. 啟用自動 LTPA 金鑰更新


圖 10. 手工生成新的 LTPA 金鑰

21. 不要在命令列上指定密碼

一旦啟用了安全性，WebSphere Application Server 管理工具就要求您只有通過身份驗證才能使用它。執行身份驗證的明顯方式就是在命令列中指定使用者 ID 和密碼，將其作為引數傳遞給該工具。請不要這樣做。這會向在您身邊窺探的任何人暴露您的管理密碼。而且在許多作業系統中，任何可以看到程式列表的人都可以看到命令列上的引數。相反，應該確保由管理工具提示輸入使用者 ID 和密碼。從 WebSphere Application Server V6.0.2 起，如果在命令列上沒有提供使用者 ID 和密碼，所有管理工具會自動提示輸入。不需要其他的操作。

如果使用以前版本的 WebSphere Application Server，則可以通過讓這些工具使用 RMI（預設是 SOAP）通訊來強制它們提示輸入使用者 ID 和密碼。RMI 引擎在需要時會顯示提示。要實現這一點，只需指定：

–conntype RMI –port

下面的示例以這種方式啟動 wsadmin，連線到監聽預設埠的部署管理器：

wsadmin.sh –connectype RMI –port 9809

如果覺得命令列工具以圖形方式提示輸入使用者 ID 和密碼非常煩人，可以改變該行為，讓工具使用基於文字的簡單提示。要實現這一點，應該通過編輯合適的配置檔案，將 loginSource 從 prompt 改為 stdin。在預設情況下，管理工具使用 SOAP，因此應該編輯 soap.client.props 檔案。如果使用的是 RMI，則編輯 sas.client.props。請在適當的檔案中查詢 loginSource 屬性，並更改它以指定 stdin。

22. 建立單獨的管理使用者 ID

當為 WebSphere Application Server V6.1 和更高版本配置安全性時，在開始時會配置一個主管理 ID（見邊欄）。這個 ID 實際上等同於 WebSphere Application Server 中的根使用者，它能夠執行任何管理操作（包括下一節提到的所有管理角色）。由於這個 ID 很重要，所以最好不要隨便共享其密碼。理想情況下，在最初配置之後不應該再使用這個 ID。

與大多數系統一樣，WebSphere Application Server 允許多個主體擔任管理員。只需使用管理應用程式並進入系統管理控制檯使用者（或使用者組）部分，指定應該授予管理許可權的其他使用者或使用者組。當進行這樣的授權之後，在管理 WebSphere Application Server 時每個人都可以以自己的身份進行身份驗證。從 WebSphere Application Server 5.0.2 開始，會導致更改 WebSphere Application Server 配置的所有管理操作都需要經過部署管理器的稽核，包括執行更改的主體的身份。從 V7 開始，引入了一個新的審計框架，它可以提供更詳細的管理操作審計資訊。顯然，如果每個管理員有單獨的身份，這些審計記錄會更有用。

在由中心管理員管理多個 WebSphere Application Server 計算單元的環境中，為每個管理員授予單獨的管理訪問許可權會非常方便。雖然每個計算單元都有自己的本地 “根” ID 和密碼，但是可以配置所有這些計算單元以共享公共登錄檔，這樣管理員就可以使用相同的 ID 和密碼來管理每個計算單元。

23. 利用管理角色

根據版本不同，WebSphere Application Server 允許不同的管理角色：Administrator、Operator、Monitor、Configurator、AdminSecurityManager、iscadmins、Deployer、Auditor。這些角色使得授予個人（和自治系統）適當的訪問許可權成為可能。強烈建議儘可能利用角色。通過使用許可權較少的 Monitor 和 Operator 角色，可以限制管理員能夠執行的操作。例如，可以只授予較為低階的管理員啟動和停止伺服器的能力；只授予夜間操作員監視系統的能力（Monitor）。這些操作讓人員只具有他們需要的許可權，從而極大地限制了損害風險。

在 WebSphere Application Server Information Center 中可以找到關於角色及其擁有的許可權的完整文件。但是，應該特別注意下面三個角色：

• Monitor：授予使用者或系統這個訪問級別，就意味著他們只能監視系統狀態；不能更改狀態，也不能更改配置。例如，如果您開發用於檢查系統執行狀況的監視指令碼，並且必須用該指令碼在本地儲存使用者 ID 和密碼，則應該使用具有 Monitor 角色的 ID。即使該 ID 被竊取，所造成的損害也不會很嚴重。
• AdminSecurityManager：（V6.1 中增加的）具有此角色的使用者可以授予其他使用者管理角色。Administrator 角色本身沒有這個許可權。現在，可以向使用者授予各種許可權（甚至包括 Administrator 許可權），同時仍然確保他們無法把這些許可權再授予別人。
• Auditor：（V7 中增加的）具有此角色的使用者可以配置審計系統，但是沒有其他任何許可權。另一方面，Administrator 可以配置除審計系統之外的任何東西。這提供明確的職責分隔。Administrator 可以更改配置，但是無法 “掩蓋” 操作痕跡，因為他無法禁用審計。

24. 考慮加密 Web 伺服器到 Web 容器的鏈路

即使不對從 Web 伺服器到 Web 容器的鏈路進行身份驗證，也可能希望考慮對它進行加密。Web 伺服器外掛通過 HTTP 把來自 Web 伺服器的資訊傳輸到 Web 容器。如果到達 Web 伺服器的請求使用的是 HTTPS，那麼在預設情況下外掛使用 HTTPS 轉發請求。如果到達的請求使用的是 HTTP，那麼外掛使用 HTTP。這些預設行為對於大多數環境是合適的。但是，有一種例外情況。

在某些環境中，當請求到達您的網路之後，會在其中新增敏感資訊。例如，一些身份驗證代理伺服器（比如 WebSEAL）會在請求中新增密碼資訊。Web 伺服器中的定製程式碼可能做相似的事情。如果是這種情況，應該採取額外步驟保護從 Web 伺服器到 Web 容器的通訊流。要想迫使從此外掛發出的所有通訊流都使用 HTTPS，只需在每個應用伺服器上的 Web 容器中禁用 HTTP 傳輸，然後重新生成和部署外掛（圖 11）。現在，此外掛只能使用 HTTPS，所以無論通訊流如何到達 Web 伺服器，它都使用 HTTPS 執行轉發。

圖 11. 確保只使用 HTTPS

25. 只使用新的 LTPA cookie 格式

（在 V7 中預設情況下已經解決。）

WebSphere Application Server V5.1.1 為支援 主題傳播 引入了一種新的 LTPA cookie 格式 (LTPAToken2)。在引入新格式的同時，也解決了舊格式中一些理論上的缺點。請記住，這些缺點只是在理論上存在的；還沒有出現已知的威脅。無論如何，應該使用新的更強的格式，除非不得不使用舊格式。

新的 LTPA 令牌使用以下強加密技術：

• Random salt
• 強 AES 密碼
• 對資料簽名
• 對資料加密

出於好奇，我們使用 1024 位 RSA 金鑰對進行簽名，使用 128 位機密金鑰 (AES) 進行加密。用於加密的密碼是 AES/CBC/PKCS5Padding。

在 V7 之前，預設情況下同時支援新舊 cookie 格式，以確保在建立 LTPA cookie 時與其他系統相相容，例如較老版本的 WebSphere Application Server、IBM Lotus® Domino®（V8 以前的版本）和 Tivoli Access Manager WebSEAL（V6 以前的版本）。如果您不需要這種相容性，則應該禁用它。要禁用它，請進入 Security > Authentication Mechanisms > LTPA > SSO configuration 皮膚並取消選擇 interoperability mode（圖 12）。

圖 12. SSO 互操作模式設定

警告：在 V7 以前，不能同時禁用互操作性和安全屬性傳播（也稱為主題傳播）。如果同時禁用它們，身份驗證就會失敗。

26. 加密 WebSphere MQ 訊息傳遞鏈路

如果您使用的是 WebSphere MQ 而非預設的訊息傳遞提供者，當然應該對 WebSphere MQ 使用 SSL。有關這一點的更多資訊，請參閱 參考資料。 在 WebSphere Application Server V7 中，WebSphere MQ 客戶機 SSL 配置是第一類構造，可以像其他 SSL 配置一樣通過管理控制檯設定。

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

核心組依賴於 DCS，它使用可靠的多播訊息 (RMM) 系統來進行傳輸。RMM 可以使用幾種有線傳輸技術之一。根據環境不同，可以通過 DCS 傳輸敏感資訊。例如，使用 DCS 傳輸 DynaCache 和安全性主題快取中的資料。為了確保這一點，需要選擇一種通道框架傳輸型別，並選擇 DCS-Secure 作為每個核心組的通道鏈（圖 13）。

圖 13. 配置 DCS 以使用受保護的鏈路

請注意，當啟用全域性安全性時，DCS 始終對訊息進行身份驗證。一旦傳輸被加密，就有了一個高度安全的通道。

一旦做到這一點，所有依賴於 DCS 的服務都將使用加密且經過身份驗證的傳輸。這些服務是 DynaCache、記憶體到記憶體會話複製、核心組、Web 服務快取和有狀態會話 bean 持久化。

28. 保護從應用伺服器到資料庫的鏈路

與其他任何網路鏈路一樣，機密資訊可以被寫入資料庫或從資料庫中讀取。大多數資料庫都支援某種形式的身份驗證，您應該利用它。

這裡是一個 IBM DB2 示例。

29. 考慮把 cookie 限制為 HTTP Only

如果黑客能夠通過在瀏覽器中插入惡意的 JavaScript. 攻破 Web 應用程式（這通常稱為跨站點指令碼攻擊），就可以執行許多惡意操作，應用程式實際上完全被攻破了。他們可以執行的惡意操作之一是竊取 LTPA cookie 等敏感的 cookie。大多數現代 Web 瀏覽器都支援 HTTP Only cookie 概念。

WebSphere Application Server 提供一種確保把 LTPA cookie 標為 HTTP Only 的方法。這需要把安全性定製屬性 com.ibm.ws.security.addHttpOnlyAttributeToCookies 設定為 true。（這是最近通過 APAR PK82764（V6.0 或 V6.1）或 PM03760（V7）增加的。）

目前，這個屬性只用 HTTP Only 標誌保護 LTPA cookie。對於使用 Java EE 安全性並啟用會話安全性（稍後討論）的以正確方式編寫的應用程式，這應該足夠了。

但是，即將釋出的一個 APAR (PK98436) 將支援在任意 cookie 上設定 HTTP Only 標誌。當這個新特性推出之後，應該使用它而不是老特性，因為它更靈活更完整。這個 APAR 允許通過 Web 容器屬性 com.ibm.ws.webcontainer.httpOnlyCookies 控制要保護的 cookie。這個屬性的值是要保護的 cookie 的逗號分隔列表（* 表示所有 cookie）。

警告：儘管這個 APAR 看起來是防禦跨站點指令碼攻擊的解決方案，但它不是。如果黑客可以在您的瀏覽器中執行任意程式碼，他們能夠造成的危害遠遠不只是竊取 cookie。他們實際上可以看到瀏覽器螢幕上的所有內容，可以捕獲每次擊鍵，這比竊取 cookie 嚴重多了。

30. 通過培訓讓使用者正確地理解證照警告

當使用 SSL 進行通訊時，安全地交換資訊的關鍵之一是根據客戶機信任儲存庫檢驗伺服器的證照。如果由於在信任儲存庫中沒有相應的簽署者，伺服器提供的證照不可信，那麼大多數客戶機（Web 瀏覽器、SSH、wsadmin 等）會提示使用者決定應該怎麼做。這些客戶機通常會向使用者警告這是一個未知的證照，提供證照的指紋（通常是 SHA），並詢問 should I trust this?。遺憾的是，大多數使用者會盲目地單擊 yes。這是一個可怕的決定。如果這麼做，就不知道您將與什麼伺服器通訊。對於 WebSphere Application Server 管理客戶機，下一步就是把管理使用者 ID 和密碼傳送到未知的伺服器。

相反，管理員應該檢查指紋資訊，判斷它是否是正確的指紋（理想情況下終端使用者也應該這麼做）。管理工具提供了檢視證照指紋的方法。在管理控制檯中選擇一個個人證照，顯示它的指紋。

圖 14. 證照指紋

使用者（尤其是管理員）應該瞭解指紋資訊，當客戶機（無論是 Web 瀏覽器還是 wsadmin）提示時理想情況下應該檢驗指紋。

圖 15. Web 伺服器證照警告，第一部分


圖 16. Web 伺服器證照警告，第二部分


清單 2. wsadmin 證照警告

				
./wsadmin.bat
*** SSL SIGNER EXCHANGE PROMPT ***
SSL signer from target host localhost is not found in trust store 
	C:/IBM/WebSphere/AppServer/profiles/AppSrv02/etc/trust.p12
Here is the signer information (verify the digest value matches what 
	is displayed at the server):
Subject DN:    CN=keysbotzum, O=IBM, C=US
Issuer DN:     CN=keysbotzum, O=IBM, C=US
Serial number: 1151337276
Expires:       Tue Jun 26 11:54:36 EDT 2007
SHA-1 Digest:  53:43:75:86:A8:C3:55:15:98:35:54:E7:49:B7:15:AF:16:A9:53:6F
MD5 Digest:    29:36:B1:9C:22:5A:36:AD:78:B3:7E:FD:D3:B1:B4:19
Add signer to the trust store now? (y/n) 
            

即使您不採納這個建議，至少應該在第一次遇到警告時把證照匯入客戶機信任儲存庫。如果再次看到訊息，一定要查明原因！在證照更改之前，提示應該不會再次出現。如果出乎意外地出現提示，一定有很嚴重的錯誤。

31. 謹慎地限制可信的簽署者

在使用證照身份驗證（客戶機或伺服器）時，需要理解信任儲存庫中的每個簽署者都代表一個可信的身份資訊（證照）提供者。您信任的簽署者應該儘可能少。否則，有可能兩個簽署者頒發的證照對映到同一個使用者身份。這會在架構中造成嚴重的安全漏洞。

應該檢查客戶機和伺服器上的信任儲存庫，刪除任何不需要的簽署者。在預設情況下，信任儲存庫包含的可信簽署者比以前的版本少得多，這有助於提高預設情況下的安全性。但是，仍然有幾個簽署者問題可能需要解決：

• 在預設情況下，信任儲存庫中有 dummyclientsigner 和 dummyserversigner，它們用於與使用這些預設簽署者的以前版本相容（我們一直建議不使用它們）。在 V7 中預設情況下沒有這些簽署者。
• 在預設情況下，KDB/CMS 金鑰儲存庫包含大多數眾所周知的 CA 的簽署者。沒有合理的理由這麼做，應該刪除它們。
• 在 V7 中，預設的計算單元信任儲存庫包含一個 WebSphere DataPower 簽名證照，這意味著所有 DataPower 計算機都可以頒發應用伺服器所信任的證照。為了提高安全性，應該刪除它。

32. 限制為強密碼

（在 V7 中預設情況下已經解決。）

當通過 SSL 通訊時，通訊流會加密。為了更好地保護通訊流，應該使用強密碼。遺憾的是，在 V7 之前，預設的 SSL 強密碼選擇包含一些明顯非常弱的密碼。應該刪除這些密碼，否則客戶機可能會選用它們。正常情況下，如果 Web 伺服器支援強密碼，客戶機會隱式地選擇強密碼，但是最好確保這麼做。

圖 17. SSL 密碼

儘管這裡不詳細討論，但是還應該確保把 Web 伺服器配置為只接受使用強密碼的通訊流。

33. 強制 CSIv2 傳輸使用 SSL

當 WebSphere Application Server 伺服器和客戶機使用 CSIv2 IIOP 進行通訊時，它們之間協商傳輸安全性。選擇對雙方來說都可接受的形式。一般來說，這是可以的，但應該注意一個潛在的漏洞。WebSphere Application Server 支援 CSIv2 over SSL 或明文方式。在預設情況下，雙方通常會協商使用 SSL，從而建立加密的通訊通道。然而，如果在協商中有任意一方請求使用明文，則將使用明文。您甚至可能不會意識到通訊流是以明文方式傳送的！這種問題可能出現，例如如果一個客戶機配置錯誤的話。如果想要（也應該）保證通訊流是加密的，更保險的做法是確保始終使用 SSL。

可以通過在 CSlv2 入站傳輸皮膚中指明 SSL 是必需而不是可選的，從而確保對 IIOP 使用 SSL。對 CSIv2 出站傳輸也應該這樣做（圖 18）。

圖 18. 配置只使用 SSL

34. 考慮埠過濾

有時候，希望根據網路資訊限制誰可以連線。儘管這樣的配置對於安全性不一定有價值，但是為了完整，這裡仍然討論一下。WebSphere Application Server 中的大多數傳輸（IIOP 除外）使用 Channel Framework，因此可以使用包含或排除列表根據 IP 地址或 DNS 名稱過濾入站通訊流。

圖 19. 埠過濾

警告：偽造 IP 地址是相當容易的，所以依靠 IP 地址保證安全性是不明智的。在 WebSphere Application Server 中根據 IP 地址進行過濾尤其不明智。更好的方法是裝備防火牆和交換機，從而識別來自無效 IP 地址的資料包。它們還可以檢查 MAC 地址。

35. 禁用不使用的埠

加強安全性的基本原則是使潛在攻擊的攻擊面最小化。當給定的服務沒有已知的安全問題時尤其應該這樣。如果該服務對系統的正常運轉是不必要的，則應該將其刪除，從而儘可能降低攻擊者在將來的某個時候利用這個多餘的功能進行攻擊的可能性。檢視圖 20，您會看到典型的 WebSphere Application Server 應用伺服器正在監聽大量埠。

圖 20. Network Deployment 應用伺服器的預設埠

如果給定的服務不是必需的，則可以禁用其監聽的埠。檢視此列表，可以考慮禁用的埠是：

• SAS_SSL_SERVERAUTH_LISTENER_ADDRESS：用於與 WebSphere Application Server V4 和更早版本相容。這是舊的 IIOP 安全性協議。從 V5 開始，CSIv2 替代它了。
• SIB_ENDPOINT_*：供內建的訊息傳遞引擎使用。如果沒有使用訊息傳遞，則不需要使用它們。
• SIB_MQ_*：供訊息傳遞引擎在與 WebSphere MQ 連線時使用。
• WC_adminhost*：用於管理性 Web 瀏覽器訪問。如果應用伺服器沒有部署管理器，應該確保禁用這些埠。遺憾的是，即使伺服器上沒有管理應用程式，大多數應用伺服器 Web 容器仍然要監聽兩個管理埠。這是因為伺服器常常是基於 server1 模板建立的，這個模板包含這些埠。應該在所有應用伺服器上禁用或刪除這些埠。
• WC_defaulthost*：預設的 Web 容器監聽埠。如果已經新增了定製的監聽埠，則可能不需要這些。

不同的埠需要使用不同的技術來禁用，這取決於它們的實現方式：

• 可以通過在全域性安全性皮膚中選擇 CSI 作為活動協議，將 SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 從服務中除去。在 V7 中，在預設情況下禁用 SAS，但是仍然監聽這個埠。
• WC_* 埠都是用於 Web 容器的。最好在 Web 容器傳輸鏈配置皮膚 (Application servers > servername > Web container > transport chain) 中刪除、修改或禁用它們。只需要監聽應用程式使用的那些 Web 埠。
• 除非啟用了訊息傳遞引擎，否則不會啟動 SIB_* 埠，所以不需要對它們採取措施。

警告：在決定要禁用哪些埠時以及在實際禁用它們時，應該特別謹慎。否則，可能無意間禁用管理埠，這樣就會禁用管理程式的機制，無法刪除和重新建立程式（例如伺服器）定義。

36. 考慮禁用密碼快取

在執行基於密碼的身份驗證時，執行時會以單向雜湊的形式快取密碼，供以後檢驗時使用。因為這個雜湊是不可逆的，所以密碼沒有被截獲（甚至包括通過記憶體轉儲截獲）的危險，但是這個快取對安全性有影響。如果以後到達的請求要求身份驗證，而且它們使用相同的使用者 ID 和密碼組合，就會使用快取的密碼資料（和使用者資訊）。這意味著，即使登錄檔中的使用者密碼更改了，他仍然能夠使用舊的密碼通過身份驗證，直到快取到期為止（預設情況下是 10 分鐘）。

一些人認為這是一個安全性漏洞（作者並不認同）。如果您擔心這個問題，可以通過設定 JVM 級屬性 com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled 禁用密碼快取。設定之後，就不再快取密碼，對於所有密碼身份驗證，都要查詢登錄檔。請記住，這對效能有顯著的消極影響。如果使用每個請求都要求身份驗證的無狀態協議（比如使用 UserNameTokens 的 WS-security），這會產生很大的登錄檔身份驗證通訊流。

37. 考慮啟用 FIPS 遵從性

在執行加密時，有多種密碼學演算法可供選擇。另外，在建立 SSL 連線時，實際上有三個選擇：SSL V2（在預設情況下禁用）、SSL V3 和 TLS。美國政府已經定義了與電腦保安性有關的標準 (Federal Information Processing Standards)，涵蓋許多領域。在這些標準中，認證了符合 FIPS 標準的密碼技術，還認證了 TLS（但是沒有認證 SSL V3）。

如果使用者希望把應用程式限制為只使用符合 FIPS 的密碼技術和 TLS，可以手工配置每個端點，也可以使用管理工具啟用 FIPS 遵從性。啟用 FIPS 之後，就只使用 符合 FIPS 的密碼技術。

結束語

這篇分兩部分的文章的第 1 部分討論了安全性的幾個方面，主要關注加強 WebSphere Application Server 環境的核心方案。希望這些資訊能夠向您提供切實保護 Java EE 環境所需的基礎知識。

第 2 部分將討論更廣泛的主題，包括基於應用程式的預防措施、計算單元信任、跨計算單元信任、管理和應用程式隔離、身份傳播、桌面開發安全性等等。

如果希望進一步瞭解 WebSphere Application Server 安全性，請聯絡 IBM Software Services for WebSphere，參加關於 WebSphere Application Server 安全性的定製的現場課程。這個課程深入講解安全性加強、定製身份驗證、整合、單點登入和各種其他相關主題。

原文連結:http://www.ibm.com/developerworks/cn/websphere/techjournal/1004_botzum/1004_botzum.html

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