簡介
IBM WebSphere Application Server 的安全性在每個版本中都有所改進。除了在新版本中增加了一些新功能之外，我們還不斷增強產品的默認安全性。我們通過改進默認設置不斷提高滿足默認安全性這一關鍵原則的程度。本文的前一個版本 主要關注 WebSphere Application Server V6 和那個版本所需的加強步驟。在後續 WebSphere Application Server 版本中，顯著減少了加強步驟的數量，更重要的是，保留的大多數步驟變得不那麼關鍵了。那篇文章的修訂版 主要關注 WebSphere Application Server V6.1 以及針對 V7.0 的更新。因為 V6.1 與後續版本之間存在重大的差別，這些差別會使討論復雜化，所有我們覺得從內容中刪除 V6.1 的細節對更高版本的用戶會有所幫助。現在，WebSphere Application Server 8.0 和 8.5 版已減少了必要的加強步驟，而增加的一些新功能會更改（或支持額外的）加強需求。因此，是時候用最新的信息來更新本文了。
本文首先簡單討論安全性為什麼如此重要以及加強系統的困難，然後討論如何加強 WebSphere Application Server 環境來解決各種安全性漏洞。因為本文主要討論加強，所以一些信息是概括性的，沒有進行詳細分析。我們盡可能提供相關詳細信息的適當參考資料，讓您能夠進一步研究相關的子主題。
盡管本文中的信息基於 IBM WebSphere Application Server V8.5 和 V8.0，但是討論的大多數問題同樣適用於 V7.0，但在某些情況下，WebSphere Application Server V8.0 對默認安全性設置進行了更改。對於某個版本特有的問題，我們會專門指出這些地方。隨著時間的推移，我們對主要的 WebSphere Application Server 版本進行了產品更改，如果您使用的是 WebSphere Application Server V6 或更低版本，一定要參考 歸檔的文章，如果您使用的是 WebSphere Application Server V6.1，請參考 以前的文章。
配置文件備注
如果熟悉 V8.5 之前的 WebSphere Application Server，您就會知道必須要創建一個或多個配置文件。該配置文件可能是一個 Application Server（或 Base）配置文件、一個 Deployment Manager 配置文件等。在本文的剩余部分中，這些配置文件將稱為 “完整” 配置文件。進行這樣的區分是為了將這些配置文件與 V8.5 中新增的配置文件（Liberty 配置文件）進行對比。本文還提供了特定於新的 Liberty 配置文件的一些建議。
為什麼需要安全性？
令人欣慰的是，大多數讀者都能夠認識到安全性是企業系統的一個關鍵方面。盡管如此，為了介紹一些考慮安全性的常用方法，我們仍將簡要介紹一下安全性。
安全性的基本目的是 “阻止不懷好意的人進入您的系統”。更准確地說，安全性是一個過程，它應用多種技術來防止未經授權的用戶（通常稱為入侵者）對內容進行未經授權的訪問。
有許多類型的入侵者：外國間諜機構、競爭對手、黑客，甚至是您自己的雇員。每個入侵者都有不同的動機、不同的技能和知識、不同的訪問入口以及不同的需求級別。例如：
雇員可能對公司有攻擊動機。雇員具有非常高的內部訪問級別和系統知識水平，但他們的資源和黑客技能可能很有限。
外部黑客也許是安全性攻擊方面的專家，但是他們對您可能沒有攻擊動機。
外國間諜機構可能對攻擊您很感興趣（這取決於您的業務）並擁有極其豐富的資源。
入侵者可能出於兩個原因入侵您的系統：為了獲取他們本不該擁有的信息，或者為了以某種方式改變系統的正常行為。在後一種情況中，通過改變系統行為，他們可以嘗試執行對其有利的事務，或者只是為了用某種有意思的方式導致系統崩潰，從而造成對您的組織的損害。
關鍵在於，有很多不同類型的入侵者、很多不同的入侵動機以及（我們後面將會看的）許多不同的攻擊類型。在規劃安全性時，必須認識到這些。
同時關注內部和外部威脅
不應該僅將安全措施視為阻擋 “外人” 的大門。這是一種過於簡單的觀點。當前，許多組織將他們的安全措施完全集中在針對組織以外的人群，他們錯誤地認為只有外人才是危險的。實際上並非如此。對於大型公司，往往有數千人能夠訪問內部網絡（其中許多人並不是雇員）。這些人都可能成為入侵者，而且由於他們在內部，所以他們訪問網絡會更方便。常常只需把筆記本電腦插上網線，就能夠訪問公司網絡。一些研究表明，有將近一半的入侵是 由組織內部的雇員或者承包人（或涉及他們的人）造成的。
就算您相信網絡中的每個人都是值得信任的，您能夠相信他們永遠不會犯錯嗎？考慮到通過電子郵件傳播的病毒如此猖獗，而且基於 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 通信流、MQ 通信流、JDBC 通信流、WebSphere 消息引擎之間通過 SIBus 傳輸的消息流、J2C 和 SOAP 通信流。SSL 需要使用公鑰/私鑰對，對於 WebSphere Application Server，這些密鑰存儲在密鑰存儲庫中。因為 SSL 對於保護基礎架構具有重要作用，所以我們暫時離開本文的主線，介紹 SSL 的一些與 WebSphere Application Server 相關的重要方面。（本文特意做了簡單介紹，只討論正確配置 SSL 所需的關鍵點。）
公鑰密碼術 (Public Key Cryptography) 從根本上講是基於公鑰/私鑰對的。這兩個密鑰在密碼學意義上是相關聯的。關鍵的問題是這些密鑰是非對稱的；使用一個密鑰加密的信息可以使用另一個密鑰來解密。私鑰自然是私有的。也就是說，您必須始終保護私鑰。如果其他任何人能夠訪問私鑰，那麼接下來他們就可以用該私鑰來 “證明” 其身份，並以您的名義進行活動；私鑰很像密碼，只是更安全，更改比較困難。持有私鑰就是身份的證明。公鑰是密鑰對的一部分，它可以與其他人分享。
只要有一種安全的方法可以將公鑰分發給各方，這就足夠了。由於沒有這樣一種全球公認的技術，所以公鑰密碼術引入了簽名公鑰的概念。簽名公鑰有數字簽名（非常類似於人工簽名）來表明簽署者對公鑰的擔保。簽署者保證與簽名公鑰相對應的私鑰持有者就是由密鑰識別的群體。這些簽名公鑰被稱為證書。眾所周知的簽署者被稱為證書授權方 (CA)。也可以使用相應的私鑰簽署公鑰。這些被稱為自簽名 (self-signed) 證書。自簽名證書的安全性不亞於由證書授權方簽署的證書，只是乍看起來，它們顯得不易於管理。
圖 1 顯示了使用 CA 創建和分發證書的基本過程；對於本例，證書用於通過 SSL 執行服務器身份驗證。也就是說，服務器持有一個證書，用於向客戶端表明其身份。客戶端不持有證書，因此對 SSL 是匿名的。
在通過配置客戶端讓其信任 CA 頒發的所有證書之前，提前執行第 1-3 步。第 4-6 步提前在服務器上執行，使它能夠在客戶端中利用這種 CA 信任關系。當客戶端啟動一個對服務器的連接時，將執行第 7 步和第 8 步。
圖 1. 服務器 SSL 身份驗證：證書創建和分發
在查看此圖時，請注意客戶端必須持有簽署服務器生成的公鑰所用的證書。這是信任的關鍵部分。由於客戶端信任它擁有的任何證書（在本例中包括 CA 證書），所以它信任 CA 簽署的所有有效的證書。證明可能包括確保發放者是受信任的（如圖 1 所示），檢查證書是否過期（超過有效期），檢查證書中定義的用途是否與它的實際用途匹配，以及檢查證書是否已被撤銷。
我們使用一種類比法來解釋證明與驗證之間的區別，可將證書想象為駕駛員的駕照。它們由各個省/州/國家發放。官員可通過檢查發放國家（它是否一個受信任的省/州/國家？）來驗證駕駛員的駕照，確認它沒有被篡改（數字簽名證明類似於物理檢查），檢查它是否過期，驗證性別是否與持有人相符，持有人是否正將驗證駕照用於與之對應的車輛類型（性別和類型：汽車、摩托車和卡車類似於證書擴展屬性），最後檢查持有人是否擁有未結算的支付款，類似於撤銷檢查。另一方面，驗證駕駛員駕照是為了確認駕照上的照片（身份）與使用它的人相符。
值得注意的是，如果使用自簽名證書，則需要手工地將這些自簽名證書分發到每個客戶端，而不是依靠可能已經在客戶端中構建的眾所周知的 CA 證書。這並非不安全，但是，如果有許多客戶端，則需要將所有這些簽名證書（每個服務器對應一個）分發到所有客戶端，這會變得非常難以管理。只分發一個簽署了許多證書的 CA 證書要容易得多；這些 CA 證書通常具有更長的壽命，客戶端應用程序（比如浏覽器）通常會在過期之前自動推出更新或替換證書。
信任強大的 CA 頒發的所有證書有一個重大缺陷。如果某個 CA 遭到破壞，那麼很可能會導致嚴重的信任損失。2011 年，一家為大約 25% 的互聯網站頒發證書的 CA (Comodo) 遭到攻擊，此 CA 頒發的證書現在已值得懷疑。另一家 CA (Diginotar) 也遭到攻擊，這導致該公司關閉；Diginotar 使用的所有證書現在已毫無用處。
對於使用 SSL 的服務器身份驗證來說更是如此。在完成最初的握手階段之後，SSL 實際上將改為使用在握手期間生成的機密密鑰執行加密，通過這種方法保護通信通道，但具體的細節與本文無關。
當客戶端向服務器驗證其自身的身份時，雖然角色相反，但過程與此相似。為了讓服務器對客戶端進行身份驗證（這通常稱為客戶端證書身份驗證，在與服務器身份驗證一起使用時稱為雙向 SSL 或 Mutual SSL），客戶端必須持有一個私鑰和相應的證書，而服務器必須持有相應的簽名證書或客戶端證書的副本。這對於它來說是舉手之勞。請注意哪些內容是不必要的：SSL 證書身份驗證僅確定證書的有效性，不會驗證該證書代表誰。驗證是 SSL 後處理的責任。這有著重要的意義，稍後我們將會看到。
總之，因為 SSL 使用證書身份驗證，所以 SSL 連接的每一端都必須在密鑰存儲文件中持有適當的密鑰。在配置 SSL 密鑰存儲庫時，需要考慮哪一群體需要遵守哪些密鑰的基本規則。通常，這會讓您知道自己需要什麼。
查看本欄目
只使用 SSL 限制訪問
正如剛剛提到的，一旦 SSL 檢驗過證書，從 SSL 的角度來看，身份驗證過程已經結束了。接下來理想的情況應該是讓另一個組件查看證書中的身份，然後使用該身份制定授權決策。授權決策可以是讓客戶端確認服務器是可信的（Web 浏覽器只要核實證書中的名稱與 Web 服務器的主機名稱相同，就可以確認服務器是可信的），也可以是讓服務器提取用戶名，然後使用它為以後的授權決策創建證書（WebSphere Application Server 在對用戶進行身份驗證時采取的就是這種方式）。遺憾的是，並非所有的系統都有這樣的功能。對於這樣的系統，可以利用流行的 SSL 技巧：限制有效的證書。
在前面涉及客戶端身份驗證的場景中，客戶端提供了一個證書，然後服務器可以根據可信的證書簽署者集對其進行檢驗。一旦檢驗通過，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 和更高版本的設計原則是遵守默認情況下的安全性的安全性原則。盡管這個目標尚未完美實現，但已經針對該目標發布了一個產品，在大多數常見的配置環境和更簡單的環境中，該產品默認情況下具有合理的安全水平。顯然，復雜的環境會產生難以預料到的獨特問題，但是對於比較簡單的環境，我們的目標是讓默認的安裝和配置能夠提供合理的系統安全水平；沒有完全安全的系統，因為這樣的東西是不可能存在的。我們也不會試圖消除每個漏洞，因為許多漏洞的風險很小，而且在默認情況下封閉它們會顯著增加應用程序開發、管理或兼容性的復雜程度。但是，如果我們認為，對於大多數客戶端，可以采用某種方式合理地消除某個漏洞，我們就是會怎樣做的。
管理安全和 Liberty 配置文件
第一次（或者可能第二次）查看 Liberty 配置文件時，您可能會注意到，我們沒有啟用管理安全。WebSphere Application Server 產品在以前的版本中竭盡全力從默認不安全模式改進為默認安全模型（從 V6.1 開始）。乍看起來，Liberty 配置文件安全狀態看起來可能是一大退步。但是，Liberty 配置文件與完整配置文件（Base 和 Network Deployment）之間存在著一項重要、關鍵的區別。完整的 WebSphere Application Server 配置文件被設計為通過管理控制台、wsadmin、JMS 訪問和一個完整配置文件中存在的各種服務器間通信路徑進行遠程管理。
V8.5 Liberty 配置文件管理模型基於運行配置文件的服務器上的文件的 OS 級讀/寫訪問（請注意，如果您擁有對完整 WebSphere Application Server 配置文件的類似的 OS 級訪問權，那麼您會擁有單元的總體管理控制權；通過編輯 security.xml 文件，可以更改其他所有設置）。通過添加一個 JMX 連接器功能，可以啟用 Liberty 配置文件中的遠程管理訪問：
localConnector-1.0 功能要求 JMX 客戶端應用程序在同一個主機上使用同一個 OS 用戶 ID 運行。
可啟用 restConnector-1.0 功能，讓 JMX 客戶端能夠遠程訪問服務器。
在啟用 restConnector-1.0 功能時，ssl-1.0 和 appSecurity-1.0 功能都會動態啟用，以確保遠程訪問是默認安全的，這類似於完整配置文件。此外，當啟用其中一個連接器時，必須向 Liberty 配置文件配置中添加一個管理用戶，否則連接器無法驗證和連接 Liberty。
基於基礎架構的預防措施
在保護基礎架構時，首先必須了解要保護的組件。與任何漏洞分析一樣，我們從確定組件及其外部通信路徑開始。（這一分析不會揭示內部應用程序漏洞，但會揭示其他大多數漏洞。）這有助於檢查標准的 WebSphere Application Server 拓撲（完整配置文件），並了解所有網絡鏈接和協議（參見圖 2）。方框中帶陰影的項是與 Liberty 配置文件相關的組件。作為關注安全性的人員，您需要了解所有這些鏈接並專注於保護它們。這些鏈接代表前面提到的粗粒度系統邊界。
圖 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 配置有大量網絡鏈接。WebSphere Application Server V8.5 包含按需路由器 (ODR)，以前僅在 IBM WebSphere eXtreme Scale 中提供。ODR 引入了一些必須考慮的新網絡鏈接。
盡可能地保護每個鏈接上的通信流以防范入侵者，這是非常重要的。在這部分剩下的內容中，將討論保護剛剛描述的基礎架構所需的步驟。下面的列表按優先級次序列出每個步驟。最重要（最關鍵）的措施列在最前面。靠後的措施重要性逐漸降低。由您決定您的組織應該完成這個列表中的哪些措施。
將 Web 服務器放在 DMZ 中，但是不放置 WebSphere Application Server
將生產網絡與內部網隔離開
不要將 ODR 放在 DMZ 中
對浏覽器訪問使用 HTTPS
保持補丁和修復最新
啟用應用程序安全性
使用 ldapRegistry 代替 quickStartSecurity 或 basicRegistry
限制對 WebSphere MQ 消息傳遞的訪問
加強 Web 服務器和主機
刪除 Web 服務器和插件安裝程序遺留的 JRE
加強代理
謹慎地配置和使用信任關聯攔截器 (trust association interceptor)
謹慎地使用證書身份驗證
考慮對 Web 服務器到 WebSphere Application Server 的 HTTP 鏈接進行身份驗證
不要在生產環境中運行示例
選擇合適的進程身份
保護配置文件和私鑰
加密從 WebSphere Application Server 到 LDAP 的鏈接
確保只通過 HTTPS 傳輸 LTPA cookie
確保定期改變 LTPA 加密密鑰
不要在命令行上指定密碼
為基於文件的 VMM 密碼增加附加數據
為生成的證書使用更長的密鑰
創建單獨的管理用戶 ID
利用管理角色
考慮加密 Web 服務器到 Web 容器的鏈接
加密 WebSphere MQ 消息傳遞鏈接
加密 Distribution and Consistency Services (DCS) 傳輸鏈接
保護從應用服務器到數據庫的鏈接
考慮把 cookie 限制為 HTTP Only
通過培訓讓用戶正確地理解證書警告
考慮限制 HTTP 數據的大小
謹慎地限制可信的簽署者
強制 CSIv2 傳輸使用 SSL
考慮端口過濾
考慮 SSL 主機名驗證
禁用不使用的端口
考慮禁用密碼緩存
考慮啟用 FIPS 140-2 或 SP800-131 遵從性
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. 不要將 ODR 放在 DMZ 中
WebSphere Application Server V8.5 包含按需路由器 (ODR)，以前僅在 WebSphere eXtreme Scale 中提供。ODR 是一個基於 Java 的系統，具有上一個主題中提及的所有問題。使用 ODR 的安全拓撲如圖 4 所示。而且，不支持將 ODR 放在 DMZ 中。
圖 4. 按需路由器放置
圖 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 中啟用應用程序安全性
<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 服務器端實現自己的自定義 WMQ 身份驗證插件，對 WebSphere Application Server 發送的用戶 ID 和密碼進行驗證。第二種（可能更簡單的）方法是，將 WebSphere MQ 配置為使用 SSL 進行客戶端身份驗證，然後確保只有 WebSphere Application Server 服務器持有用於連接 WebSphere MQ 的證書。（本文有點兒過時，但相同的原理和技術也適用於這兩個產品的新版本。在實現其中提到的技術時，應該考慮到產品的變化。）
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 管理服務器。盡管這是一種比采用基於 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 是通過三個單獨的非常重要的步驟配置的：
必須把 WebSEAL 配置為使用 SSL 與 WebSphere Application Server 進行通信，而且該 SSL 配置必須包含只有 WebSEAL 才知道其私鑰的客戶端證書。
必須配置應用服務器 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 支持所有這些技術，但是都需要配置。一定要執行相應的配置步驟。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 中忽略來自客戶端的證書頭
<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 中新增的。
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 對等方來限制具有訪問權限的群體。具體地說，需要執行以下操作：
為 Web 容器創建一個密鑰存儲庫和信任存儲庫，為 Web 服務器插件創建一個密鑰存儲庫。
從所有密鑰存儲庫（包括信任存儲庫）刪除所有現有的簽名證書。此時，不能使用任何密鑰存儲庫來檢驗證書。這樣做是有意的。
在這兩個密鑰存儲庫中創建自簽名證書，並只導出該證書（而不是私鑰）。一定要記錄這些證書的到期時間。當插件證書到期之後，它就不能再聯系 Web 容器了！將從 Web 容器密鑰存儲庫中導出的證書導入插件密鑰存儲庫中。將插件證書導入到 Web 容器信任存儲庫中。現在，每一端都只包含一個簽名證書。這意味著只能使用它們檢驗一個證書——為對方創建的自簽名證書。
將新創建的密鑰存儲庫安裝到 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)，它既包含配置信息，也包含密碼。
在 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
如果使用一個自定義注冊表，您一定想要使用所提供的機制保護此通信流。
要對 Liberty 配置文件啟用 LDAP SSL，可將一些元素包含在服務器的 server.xml 中，類似於清單 3 中加粗的元素示例。
<featureManager>
<feature>ssl-1.0</feature>
</featureManager>
<sslid="ldapSSLConfig"keyStoreRef="ldapTrustStore"
trustStoreRef="ldapTrustStore" />
<keyStoreid="ldapTrustStore"
location="ldapTrustStore.jks"type="JKS"password="123456" />
<ldapRegistryid="IBMDiretoryServerLDAP"realm="SampleLdapIDSRealm"
host="host.domain.com"port="389"ignoreCase="true"
baseDN="o=domain,c=us"
ldapType="IBM Tivoli Directory Server"
idsFilters="myidsfilters"
sslEnabled="true"
sslRef="ldapSSLConfig" />
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
查看本欄目
要在 Liberty 配置文件中將 LTPA cookie 限制為僅使用 SSL，可以將一個 webAppSecurity 元素包含在服務器的 server.xml 文件中，該文件還包含 ssoRequiresSSL 屬性，如清單 4 中的示例所示。
清單 4. 在 Liberty 中啟用應用程序安全性
<webAppSecurity ssoRequiresSSL=’true’ />
通過在會話管理面板上指定相似的設置，還可以將 HTTP Session（默認情況下是 JSESSION） cookie 限制為只使用 SSL。
要在 Liberty 配置文件中將 HTTP Session cookie 限制為僅使用 SSL，可將一個 httpSession 元素包含在服務器的 server.xml 中，該文件還包含 cookieSecure 屬性，如清單 5 中的示例所示。
清單 5. 在 Liberty 中啟用 HTTP Session cookie SSL
<httpSession cookieSecure=’true’ />
警告：在安裝修復包 7.0.0.9 之前，Requires SSL 標志在 WebSphere Application Server V7 中無效。一定要安裝它。
20. 確保定期改變 LTPA 加密密鑰
WebSphere Application Server 使用 LTPA 加密密鑰加密各種用戶令牌（包括 LTPA cookie）。與任何密碼術密鑰一樣，應該定期改變這些密鑰。根據 WebSphere Application Server 和補丁級別不同，可能在默認情況下啟用了自動密鑰生成，也可能關閉了該功能；版本越新，默認情況下它關閉的可能性就越大。為了避免可能的宕機，請確保此功能已關閉，如圖 9 所示。
在首次對某個 Liberty 服務器啟用安全性時，會生成 LTPA 密鑰。
應該確保會定期更改 LTPA 加密密鑰。對於完整配置文件，可以啟用自動 LTPA 密鑰替換（參見圖 9），也可以手工地重新生成密鑰（參見圖 10），或者通過 AdminTask.generateKeyForKeySetGroup 命令執行。
對於 Liberty 配置文件，可以創建一個新配置文件，啟用安全性，啟動服務器，然後復制新生成的 ${server.config.dir}/resources/security/ltpa.keys 文件。
一定要考慮 LTPA 密鑰不一致的問題：
首先，如果計算單元中的某些節點在一段時間內一直停機（而且密鑰更改兩次），那麼它們可能會喪失通信能力。
第二，如果與其他組件（比如另一個計算單元或 WebSphere DataPower）共享 LTPA 密鑰，那麼在更改密鑰時，需要在所有地方更新它們，這通常會造成停機。
因此，可以規劃在計劃的宕機期間更改您的 LTPA 密鑰。將新密鑰分發給計算單元中的所有節點，並在這個宕機窗口中將新密鑰分發給所有外部系統/計算單元。
圖 9. 不啟用自動 LTPA 密鑰更新
圖 10. 手工生成新的 LTPA 密鑰
21. 不要在命令行上指定密碼
一旦啟用了安全性，WebSphere Application Server 管理工具就會要求您僅在通過身份驗證的情況下使用它。執行身份驗證的明確方法是在命令行中指定用戶 ID 和密碼，將其作為參數傳遞給該工具。請不要這樣做。這會向在您身邊窺探的任何人暴露您的管理密碼。而且在許多操作系統中，任何可以看到進程列表的人都可以看到命令行上的參數。另外，以前的命令可在命令歷史中看到，包括密碼參數。相反，應該確保通過管理工具提示輸入用戶 ID 和密碼。請注意，在所有當前支持的 WebSphere Application Server 版本中，這是默認設置，所以無需執行任何顯式操作來確保發生此行為。
如果覺得命令行工具以圖形方式提示輸入用戶 ID 和密碼非常煩人，可以改變此行為，讓工具使用基於文本的簡單提示。要實現這一點，應該通過編輯適當的配置文件，將 loginSource 從 prompt 更改為 stdin。在默認情況下，管理工具使用 SOAP，因此應該編輯 soap.client.props 文件。如果使用的是 RMI，則編輯 sas.client.props。請在適當的文件中查找 loginSource 屬性，並更改它以指定 stdin。
這一項不適用於 V8.5 中的 Liberty 配置文件。
22. 考慮在基於文件的 Federated Repository 注冊表中增加附加數據
如果在使用 Federated Repository 注冊表的同時還使用了該注冊表中內置的文件存儲庫，那麼該注冊表中的用戶會將他們的用戶 ID 和密碼存儲在計算單元 config 目錄中的 fileregistry.xml 文件中。這些密碼經過了單向哈希計算，這意味著您無法從哈希值獲得實際的密碼。哈希值可借助一些密碼學上的附加數據來計算。在 WebSphere Application Server V8.0 和 8.5 中，可以指定附加數據的長度和使用的哈希算法。此文件應由 OS 定義的訪問控制列表來保護，以便只有特權 OS 用戶才能讀取該文件。要預防通過彩虹表的密碼破解攻擊，可以考慮增加附加數據量或使用更強的哈希函數。
這一項不適用於 V8.5 中的 Liberty 配置文件。
23. 考慮為生成的證書使用更長的密鑰長度
在 WebSphere Application Server V8.0 中，生成的證書所使用的默認密鑰長度從 1024 更改為 2048。從 V7.0 開始，在通過 wsadmin 生成密鑰時，可指定比 1024 更長的密鑰長度。從 V8.0 開始，管理控制台（圖 11） 支持選擇密鑰長度。
這一項不適用於 V8.5 中的 Liberty 配置文件。
圖 11. 在管理控制台中選擇密鑰長度
支持的密鑰長度范圍為 512-16384（必須是 8 的倍數）。
這一項不適用於 V8.5 中的 Liberty 配置文件。
24. 創建單獨的管理用戶 ID
主管理 ID 與用於服務器到服務器通信的安全服務器 ID 並不相同。從 V6.1 開始，注冊表中不再需要具有這個身份，甚至不必有相關聯的密碼。它在默認情況下只用於內部通信。如果需要的話，可以指定服務器 ID 和密碼，但是不建議這麼做，除非絕對必要——比如使用包含不同版本的計算單元（包括 V6.0 和更低版本），或者涉及 V6.0 或更低版本的跨計算單元 SSO。
當為 WebSphere Application Server V6.1 和更高版本配置安全性時（Liberty 配置文件除外），在開始時會配置一個主管理 ID（參見邊欄）。這個 ID 實際上等同於 WebSphere Application Server 中的 root 用戶，它能夠執行任何管理操作（包括下一節提到的所有管理角色）。由於這個 ID 很重要，所以最好不要隨便共享其密碼。理想情況下，在最初配置之後不應該再使用這個 ID。出於安全原因，在 V8.5 中，默認情況下並未啟用 Liberty 配置文件。
與大多數系統一樣，WebSphere Application Server 允許多個主體擔任管理員。只需使用管理應用程序並進入系統管理控制台用戶（或用戶組）部分，指定應該授予管理權限的其他用戶或用戶組。在進行這樣的授權之後，當管理 WebSphere Application Server 時，每個人都可以以自己的身份進行身份驗證。會導致更改 WebSphere Application Server 配置的所有管理操作都需要經過部署管理器的審核，包括執行更改的主體的身份。從 V7 開始，引入了一個新的審計框架，它可以提供更詳細的管理操作審計信息。顯然，如果每個管理員有單獨的身份，這些審計記錄會更有用。
在由中心管理員管理多個 WebSphere Application Server 計算單元的環境中，為每個管理員授予單獨的管理訪問權限會非常方便。雖然每個計算單元都有自己的本地 “根” ID 和密碼，但是可以配置所有這些計算單元來共享公共注冊表，這樣管理員就可以使用相同的 ID 和密碼來管理每個計算單元。
查看本欄目
25. 利用管理角色
根據版本不同，WebSphere Application Server 的完整（非 Liberty 配置文件）允許采用不同的管理角色：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 可以更改配置，但是無法 “掩蓋” 操作痕跡，因為他無法禁用審計。
這一項不適用於 V8.5 中的 Liberty 配置文件。Liberty 配置文件只有一個管理員安全角色可綁定多個主體。
26. 考慮加密 Web 服務器到 Web 容器的鏈接
即使不對從 Web 服務器到 Web 容器的鏈接進行身份驗證，也可能希望考慮對它進行加密。Web 服務器插件通過 HTTP 把來自 Web 服務器的信息傳輸到 Web 容器。如果到達 Web 服務器的請求使用的是 HTTPS，那麼在默認情況下插件使用 HTTPS 轉發請求。如果到達的請求使用的是 HTTP，那麼插件使用 HTTP。這些默認行為對於大多數環境是合適的。但是，有一種例外情況。
在某些環境中，當請求到達您的網絡之後，就會在其中添加敏感信息。例如，一些身份驗證代理服務器（比如 WebSEAL）會在請求中添加密碼信息。Web 服務器中的自定義代碼可能做相似的事情。如果是這種情況，應該采取額外步驟保護從 Web 服務器到 Web 容器的通信流。要想迫使從此插件發出的所有通信流都使用 HTTPS，只需在每個應用服務器上的 Web 容器中禁用 HTTP 傳輸，然後重新生成和部署插件。必須同時禁用 WCInboundDefault 和 HttpQueueInboundDefault 傳輸鏈（圖 12）。現在，此插件只能使用 HTTPS，所以無論通信流如何到達 Web 服務器，它都會使用 HTTPS 執行轉發。
圖 12. 確保只使用 HTTPS
要在 Liberty 配置文件中確保僅使用 HTTPS 連接 Web 容器，可將一個 httpEndpoint 元素包含在服務器的 server.xml 文件中，該文件還包含一個 httpsPort 屬性，但不包含 httpPort 屬性（如清單 6 中的示例所示）。
清單 6. 在 Liberty 中確保僅使用 HTTP 連接到 Web 容器
<httpEndpoint id="defaultHttpEndpoint" host="localhost"
httpsPort="9443" />
27. 加密 WebSphere MQ 消息傳遞鏈接
如果您使用的是 WebSphere MQ 而非默認的消息傳遞提供者，當然應該對 WebSphere MQ 使用 SSL。在 WebSphere Application Server V7 中，WebSphere MQ 客戶端 SSL 配置是第一類構造，可以像其他 SSL 配置一樣通過管理控制台設置。
這一項不適用於 V8.5 中的 Liberty 配置文件。
28. 加密 Distribution and Consistency Services (DCS) 傳輸鏈接
核心組依賴於 DCS，它使用可靠的多播消息 (RMM) 系統來進行傳輸。RMM 可以使用幾種有線傳輸技術之一。根據環境不同，可以通過 DCS 傳輸敏感信息。例如，使用 DCS 傳輸 DynaCache 和安全性主題緩存中的數據。為了確保這一點，需要選擇一種通道框架傳輸類型，並選擇 DCS-Secure 作為每個核心組的通道鏈（圖 13）。
圖 13. 配置 DCS 以使用受保護的鏈接
請注意，當啟用全局安全性時，DCS 始終對消息進行身份驗證。在加密傳輸之後，就有了一個高度安全的通道。
一旦做到這一點，所有依賴於 DCS 的服務都將使用加密且經過身份驗證的傳輸。這些服務是 DynaCache、內存到內存會話復制、核心組、Web 服務緩存和有狀態會話 bean 持久化。
29. 保護從應用服務器到數據庫的鏈接
與其他任何網絡鏈接一樣，可以將機密信息寫入數據庫或從數據庫中讀取機密信息。大多數數據庫都支持某種形式的身份驗證，您應該利用這一點。
這裡是一個 IBM DB2 示例。
這一項不適用於 V8.5 中的 Liberty 配置文件。
30. 考慮將 cookie 限制為 HTTP Only
如果黑客能夠通過在浏覽器中插入惡意的 JavaScript 攻破 Web 應用程序（這通常稱為跨站點腳本攻擊），就可以執行許多惡意操作，應用程序實際上完全被攻破了。他們可以執行的惡意操作之一是竊取 LTPA cookie 等敏感的 cookie。大多數現代 Web 浏覽器都支持 HTTP Only 概念。
WebSphere Application Server 提供了兩種確保 LTPA cookie 被標記為 HTTP Only 的方法。第一種方法是將安全性自定義屬性 com.ibm.ws.security.addHttpOnlyAttributeToCookies 設置為 true。此功能通過修復包 7.0.0.9 添加。
該功能只使用 HTTP Only 標志保護 LTPA cookie。對於以正確方式編寫的使用 Java EE 安全性並啟用會話安全性（稍後討論）的應用程序，這應該足夠用了。
第二個功能（也在修復包 7.0.0.9 中發布）支持在任意 cookie 上設置 HTTP Only 標志。此功能比第一個功能更可取，因為它更加靈活且更加完整。借助此 APAR，要保護的 cookie 由一個 Web 容器屬性 com.ibm.ws.webcontainer.httpOnlyCookies 控制。該屬性是要保護的 cookie 的一個逗號分隔列表（使用 * 表示所有 cookie）。在 V7.0 中（應用了 7.0.0.9），這個功能默認情況下是禁用的。要使用它，則必須顯式設置該屬性。在 8.0 和 8.5 版中，此屬性默認情況下已對 LtpaToken2、JSESSIONID 和 WASReqUrl cookie 啟用，無需執行進一步的操作，除非您希望將它應用於其他 cookie。請注意，由於默認行為中的這一更改，從更早版本遷移來的用戶可能會遇到應用程序破壞問題。
默認情況下，LtpaToken2 (SSO) 和e WASReqURL cooki 在 Liberty 配置文件中設置為 HTTP only。要在服務器的 server.xml 文件中顯式設置此屬性，可以包含一個具有 httpOnlyCookies 屬性的 webAppSecurity 元素，比如清單 7 中的示例。
清單 7. 在 Liberty 中將 LTPA 會話 cookie 限制為 HTTP Only
<webAppSecurity httpOnlyCookies=’true’ /><!- - This is the default- ->
默認情況下，HTTP 會話在 Liberty 配置文件中也被設置為 HTTP only。要在服務器的 server.xml 中顯式設置此屬性，可以包含一個具有 cookieHttpOnly 屬性的 httpSession 元素，比如清單 8 中的示例。
清單 8. 在 Liberty 中將 HTTP 會話 cookie 限制為 HTTP Only
<httpSession cookieHttpOnly=’true’ /><!- - This is the default- ->
警告：盡管這些功能看起來是防御跨站點腳本攻擊的解決方案，但它不是。如果黑客可以在您的浏覽器中執行任意代碼，那麼他們造成的危害就遠遠不只是竊取 cookie。他們實際上可以看到浏覽器屏幕上的所有內容，可以捕獲每次擊鍵，這比竊取 cookie 嚴重得多。
查看本欄目
31. 通過培訓讓用戶正確地理解證書警告
當使用 SSL 進行通信時，安全地交換信息的關鍵之一是根據客戶端信任存儲庫檢驗服務器的證書。如果由於信任存儲庫中沒有相應的簽署者而導致服務器提供的證書不可信，那麼大多數客戶端（Web 浏覽器、SSH、wsadmin 等）會提示用戶決定應該怎麼做。這些客戶端通常會向用戶警告這是一個未知的證書，並提供證書的指紋（通常是 SHA），詢問 should I trust this?。遺憾的是，大多數用戶會盲目地單擊 yes。這是一個可怕的決定。如果這麼做，那麼您就不會知道自己將與什麼樣的服務器通信。對於 WebSphere Application Server 管理客戶端，下一步是將管理用戶 ID 和密碼發送到未知的服務器。
相反，管理員應該檢查指紋信息，判斷它是否是正確的指紋（理想情況下最終用戶也應該這麼做）。管理工具提供了查看證書指紋的方法。在管理控制台中選擇一個個人證書，顯示它的指紋。
圖 14. 證書指紋
用戶（尤其是管理員）應該了解指紋信息，當客戶端（無論是 Web 浏覽器，參見圖 15 和圖 16，還是 wsadmin，參見清單 9）。
圖 15. Web 服務器證書警告，第一部分
圖 16. Web 服務器證書警告，第二部分
清單 9. wsadmin 證書警告
./wsadmin.bat
*** SSL SIGNER EXCHANGE PROMPT ***
SSL signer from target host localhost isnot found intrust store
C:/IBM/WebSphere/AppServer/profiles/AppSrv02/etc/trust.p12
Here isthe signer information (verify the digest value matches what
isdisplayed 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)
即使您不采納這個建議，至少應該在第一次遇到警告時將證書導入客戶端信任存儲庫。如果再次看到這類消息，一定要查明原因！在證書發生更改之前，提示應該不會再次出現。如果出乎意外地出現提示，一定存在很嚴重的錯誤。
32. 考慮限制 HTTP 數據的大小
一種常見的拒絕服務 (DOS) 工具是向應用程序發送非常大的 HTTP 頭、很多 HTTP 頭或很大的請求正文。我們非常支持進行深度防御。理想情況下，一個入侵檢測系統、一個防火牆、一個 WebSphere DataPower SOA Appliance，甚至是應用服務器前面的 Web 服務器，都應該保護您的 WebSphere Application Server，使它們遠離這些基於規模的 HTTP 攻擊。WebSphere Application Server 中還有一些控件可保護它們遠離這些攻擊類型。
任何單個 HTTP 頭的默認最大大小為 32768 字節。可以將它設置為不同的值。
HTTP 頭的默認最大數量為 50。可以將它設置為不同的限制值。
另一種常見的 DOS 攻擊是發送一個請求，這個請求會導致一個長期運行的 GET 請求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 屬性可限制任何請求的重試數量。這可以降低這種長期運行的請求的影響。
如果您希望限制任何請求正文的最大大小，也可以對其進行設置。
查看本欄目
33. 謹慎地限制可信的簽署者
在使用證書身份驗證（客戶端或服務器）時，需要了解信任存儲庫中的每個簽署者都代表一個可信的身份信息（證書）提供者。您信任的簽署者應該盡可能少。否則，兩個簽署者頒發的證書有可能映射到同一個用戶身份。這會在架構中造成嚴重的安全漏洞。
應該檢查客戶端和服務器上的信任存儲庫，刪除任何不需要的簽署者。在默認情況下，信任存儲庫包含的可信簽署者比以前的版本少得多，這有助於提高默認情況下的安全性。但是，仍然有幾個簽署者問題可能需要解決：
在 V7 中，默認的計算單元信任存儲庫和 CMS 密鑰環文件包含一個 WebSphere DataPower 簽名證書，這意味著所有 DataPower 計算機都可以頒發應用服務器所信任的證書。為了提高安全性，應該刪除它。在安裝最新的修復包後創建的 Truststore 和 CMS 密鑰環文件無需 DataPower 簽名證書即可創建。您應在 truststore 或密鑰環文件中檢查這個不必要的 DataPower 簽名文件，如果存在該文件則刪除它。
在 V8.0 和 V8.5 中，DataPower 簽名證書已從生成的 truststore 和 CMS 密鑰環文件刪除。
34. 強制 CSIv2 傳輸使用 SSL
（這一項默認情況下已在 V8 中解決，這是一項行為更改。因此，從更早的 WebSphere Application Server 版本遷移且未啟用 CSIv2 SSL 的用戶應該知道，SSL 身份驗證失敗可能在 V8 中引起問題。）
當 WebSphere Application Server 服務器和客戶端使用 CSIv2 IIOP 進行通信時，它們會就傳輸安全性進行協商，選擇對雙方來說都可以接受的形式。一般來說，這是可行的，但應該注意一個潛在的漏洞。WebSphere Application Server 支持 CSIv2 over SSL 或明文。在默認情況下，雙方通常會協商使用 SSL，確保建立一個經過加密的通信通道。然而，如果在協商中有任意一方請求使用明文，則將使用明文。您甚至可能不會意識到通信流是以明文方式發送的！這種問題是有可能出現的，例如，如果某個客戶端配置出錯的話。如果想要（也應該）保證通信流是加密的，更保險的做法是確保始終使用 SSL。
通過在 CSlv2 入站傳輸面板中指明 SSL 是必需的而不是可選的，確保對 IIOP 使用 SSL。對 CSIv2 出站傳輸也應該這樣做（圖 17）。
圖 17. 配置只使用 SSL
這一項不適用於 V8.5 中的 Liberty 配置文件，因為沒有提供對 EJB 或 CSIv2 的支持。
35. 考慮端口過濾
有時候，希望根據網絡信息限制誰可以連接。盡管這樣的配置對於安全性不一定有價值，但是為了提供完整的說明，這裡仍將對它們進行討論。WebSphere Application Server 中的大多數傳輸（IIOP 除外）使用 Channel Framework，因此可以使用包含或排除列表，根據 IP 地址或 DNS 名稱來過濾入站通信流。
圖 18. 端口過濾
警告：偽造 IP 地址是相當容易的，所以依靠 IP 地址保證安全性是不明智的。在應用層上根據 IP 地址進行過濾尤其不明智。更好的做法是裝備防火牆和交換機，識別來自無效 IP 地址的數據包。它們還可以檢查 MAC 地址。
36. 考慮在傳出 SSL 連接上執行主機名驗證
當一個 SSL 客戶端打開一個與 SSl 服務器的 SSL 連接時，服務器將它的證書發送給客戶端。預期結果是 SSL 服務器的證書將在它的常用名中包含主機名。一些客戶端會確認所提供的證書上的常用名是否與 URL 中的主機名匹配（比如 Web 浏覽器會執行此檢查）。這稱為主機名驗證。
在某些情況下，此驗證的一次失敗可能表明存在 SSL 中間人攻擊：
當證書由於是自簽名證書而受信任時，沒有必要執行主機名驗證。SSL 握手不會通過，除非提供的證書與受信任的證書完全匹配。
當證書由於是由一個受信任 CA 頒發而受信任時，MITM 攻擊者可以返回同一個受信任 CA 為它頒發的合法證書來代替真正的證書。假設 CA 沒有頒發多個具有相同 CN 的證書，那麼主機名驗證就可以檢測到 MITM 攻擊者。
要啟用主機名驗證，必須設置一個安全自定義屬性 com.ibm.ssl.performURLHostNameVerification=true。
RFC 2818 Section 3.1 Server Identity 中要求執行主機名驗證。總體來講：
如果 URI 被指定為一個 IP 地址，而不是主機名，那麼認證可在證書中使用 iPAddress subjectAltName 執行，並且必須與 URI 中的 IP 准確匹配。
如果 URI 是使用一個給定的 DNS 名稱指定的，那麼驗證可使用證書的 dNSName 類型的 subjectAltName 擴展（如果存在）來執行。否則，（最明確的方法）將使用證書的 Subject 字段中的 Common Name 字段。盡管現在的做法是使用 Common Name，但已不推薦使用它，建議證書頒發機構使用 dNSName。
匹配使用 RFC2459 所指定的匹配規則來執行。如果證書中存在多個具有給定類型的證書（例如，多個 dNSName 名稱），那麼任何集合中的匹配值均被視為可接受。）
設置此屬性時的考慮因素：
此屬性會影響計算單元中所有基於 URL 的通信流，包括 IIOP 和 WebSphere Application Server 內部通信。
在創建 WebSphere Application Server 配置文件期間，可以為配置文件配置節點的主機名。您可以覆蓋配置文件創建工具所確定的值。請確保它與主機名匹配。
如果您的系統是多宿主的，則具有多個主機名，請記住只會返回 SSL 配置的密鑰庫的默認證書的單個主機名。可以使用替代的主機名創建一個證書；在從一個 CA 獲取證書時，就可以這麼做。
換句話說，盡管啟用此屬性可加強針對中間人攻擊的安全防御，您的 SSL 證書和主機名解析必須是無瑕疵的。如果不是，那麼您的計算單元將無法再通過 SSL 進行通信，因為內部通信可能使主機名驗證失敗。
查看本欄目
37. 禁用不使用的端口
加強安全性的基本原則是使潛在攻擊的攻擊面最小化。當給定的服務沒有已知的安全問題時尤其應該這樣。如果該服務對系統的正常運轉是不必要的，則應該將其刪除，從而盡可能地降低攻擊者在將來的某個時候利用這個多余的功能進行攻擊的可能性。查看圖 20，您會看到典型的 WebSphere Application Server 應用服務器正在監聽大量端口。
圖 19. Network Deployment 應用服務器的默認端口
如果給定的服務不是必需的，則可以禁用其監聽的端口。查看此列表，可以考慮禁用的端口包括：
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS：用於與 WebSphere Application Server V4 和更早版本進行兼容。這是舊的 IIOP 安全性協議。從 V5 開始，CSIv2 替代它了。
SIB_ENDPOINT_*：供內置的消息傳遞引擎使用。如果沒有使用消息傳遞，則不需要使用它們。
SIB_MQ_*：供消息傳遞引擎與 WebSphere MQ 連接時使用。
SIP_*：這些端口供 SIP 容器使用。
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_* 端口，所以不需要對它們采取措施。
除非啟動了 SIP 應用程序，否則不會啟動 SIP_* 端口，所以不需要對它們采取措施。
警告：在決定要禁用哪些端口時以及在實際禁用它們時，應該特別謹慎。否則，可能無意間禁用管理端口，這樣做會禁用管理進程的機制，導致無法刪除和重新創建進程（例如服務器）定義。
38. 考慮禁用密碼緩存
在執行基於密碼的身份驗證時，運行時會以單向散列的形式緩存密碼，供以後檢驗時使用。因為這個散列是不可逆的，所以密碼沒有被截獲（甚至包括通過內存轉儲截獲）的危險，但是這個緩存對安全性有影響。如果以後到達的請求要求身份驗證，而且這些請求使用了相同的用戶 ID 和密碼組合，則會使用緩存的密碼數據（和用戶信息）。這意味著，即使注冊表中的用戶密碼更改了，他仍然能夠使用舊的密碼通過身份驗證，直到緩存到期為止（默認情況下是 10 分鐘）。
一些人認為這是一個安全漏洞（作者並不認同）。如果您擔心這個問題，可以通過設置 JVM 級屬性 com.ibm.websphere.security.util.authCacheEnabled = BasicAuthDisabled 禁用密碼緩存。進行這樣的設置之後，就不再緩存密碼，對於所有密碼身份驗證，都要查詢注冊表。請記住，這對性能有明顯的消極影響。如果使用每個請求都要求身份驗證的無狀態協議（比如使用 UserNameTokens 的 WS-security），這會產生很大的注冊表身份驗證通信流。
39. 考慮啟用 FIPS、SP800-131 或 Suite B 遵從性
在執行加密時，有多種密碼學算法可供選擇。另外，在建立 SSL 連接時，實際上有三個選擇：SSL V2（在默認情況下禁用）、SSL V3 和 TLS。美國政府已經定義了與計算機安全性有關的標准 (Federal Information Processing Standards)，該標准涵蓋許多領域。這個標准稱為 FIPS 140-2。在這些標准中，認證了符合 FIPS 標准的密碼技術，還認證了 TLS（但是沒有認證 SSL V3）。
美國國家標准和技術研究所 (NIST) 定義了一個新標准 SP800-131 來取代當前的 FIPS 140-2。類似地，國家安全局 (NSA) 也開發了一個名為 Suite B 的新標准。這些新標准進一步限制了使用的密碼選擇並要求使用 TLS 1.2；而 FIPS 140-2 禁止使用 SSL V3，SP800-131 禁止使用 TLS 1.0 和 TLS 1.1。
如果用戶希望將應用程序限制為只使用符合 FIPS 140-2 的密碼技術和 TLS，那麼可以手工配置每個端點，也可以使用管理工具啟用 FIPS 遵從性。啟用 FIPS 之後，就只能使用 符合 FIPS 的密碼技術。
WebSphere Application Server V8.5（以及修復包 8.0.0.3 和 7.0.0.23）引入了對 SP800-131 和 NSA Suite B 的遵從性。類似於 FIPS 遵從性，可以轉換整個計算單元，以遵從 SP800-131 和 Suite B。啟用之後，只有支持 SP800-131 的客戶端能夠連接到該計算單元。目前，支持 SP800-131 和 TLS 1.2 的客戶端應用程序很少。向此標准的遷移可能很耗時且需要規劃。
結束語
這篇分兩部分的文章的第 1 部分討論了安全性的幾個方面，主要關注加強 WebSphere Application Server 環境的核心方案。希望這些信息能夠向您提供切實保護 Java EE 環境所需的基礎知識。
第 2 部分 將討論更廣泛的主題，包括基於應用程序的預防措施、計算單元信任、跨計算單元信任、管理和應用程序隔離、身份傳播、桌面開發安全性等等。
如果希望進一步了解 WebSphere Application Server 安全性，請聯系 IBM Software Services for WebSphere，參加關於 WebSphere Application Server 安全性的自定義的現場課程。這個課程將深入講解安全性加強、自定義身份驗證、集成、單點登錄和其他各種相關主題。
