WebSphere Application Server 常見問題及解答:安全

CloudSpace發表於2008-07-11
WebAPPServer
1. 我希望通過啟用 WAS 全域性安全性保護系統管理，但是我的應用程式本身並沒有應用 J2EE 安全。我能夠做些什麼呢？

答：
我們強烈建議所有的 WAS 使用者使用全域性安全。如果沒有做這些，就意味著將應用伺服器公開給眾多種類的攻擊。通常情況下，簡單啟用全域性安全對於應用程式並沒有任何負面的影響。然而，有一些可測量的效能指標和一些 API，比如 request.getRemoteUser()，在使用安全的情況下會表現出不同的行為。如果應用程式依賴 request.getRemoteUser() 來返回 Web CGI 變數 REMOTE_USER 的值，在應用伺服器啟用安全的情況下它將崩潰。應用伺服器將返回空值，除非使用者具備認證屬性。我們強烈推薦應用程式利用 J2EE 安全，並且不要禁用伺服器級別的安全。

有關 WAS 安全性的更多資源，請參閱 developerWorks 中國站點文章《專家訪談：KeysBotzum 談 WebSphere 安全性》。
 
2. 當在 WAS 中實現自定義使用者登錄檔的時候，都需要考慮哪些問題？

答：
自定義使用者登錄檔（UserRegistry 介面的一個實現，簡稱CUR）使客戶使用他們自己的自定義登錄檔，而不是 WebSphere Application Server 中本來提供的兩個：作業系統和 LDAP。首先，我們推薦如果您能避免的話儘量不要使用 CUR，因為這將限制同其他使用 LDAP 的應用程式的互操作性。然而，如果需要的話，您也可以編寫一個 CUR。請注意，您自己的自定義登錄檔實現可能沒有依賴任何 WebSphere Application Server J2EE 元件，諸如資料來源，企業 Bean 等等。這是因為在啟動時，安全是在其他大多數 WebSphere Application Server 元件之前初始化和可用的。如果您以前的實現使用這些元件，則需要做一個更改來消除依賴。比如，如果您的應用以前用資料來源來連線一個資料庫，那麼現在用 Java database connectivity（JDBC）來連線到資料庫。注意在小心謹慎的情況下（和對初始化過程的良好理解），在 CUR 中使用 DataSource 也是可能的，但是僅僅在一個應用伺服器內部（不是節點代理），並且僅僅在初始化結束以後。
3. 在非 admin 使用者（Windows 平臺）或非 root 使用者（Unix 平臺）的環境中，如何為 WAS 設定安全特性？

答：
在非admin使用者（Windows平臺）/非root使用者（Unix平臺）環境中執行WAS時，在全域性安全（global security）特性被啟用的前提下，使用者的登錄檔（registry）必須是LDAP或一個特定的登錄檔（自定義登錄檔）。

如果想使用本地作業系統的登錄檔，執行WAS的使用者必須有管理員/root使用者的許可權來呼叫本地系統的認證或收集使用者/組資訊的API。
4. 共享一個 WAS cell 的 J2EE 應用程式需要注意哪些安全方面的問題？

答：

從根本上說，執行在同一個Cell中的應用程式有如下特點：
  • 管理操作是共同的，通過管理控制檯；
  • 資源在JNDI中可見，因此可以被其他應用程式訪問到，除非總是使用容器認證和別名；
  • 某些WAS子系統，如DynaCache，在內部安全上沒有什麼規定，因此可被不明應用程式訪問；
  • 應用程式可訪問WAS JMS基礎結構，執行任何管理操作，包括改變其他應用程式或cell本身（Java2禁止這種操作）；
  • 即使啟用了Java 2安全特性，應用程式也可以利用其知名的弱點而繞過Java 2安全檢查；

還有很多沒列出來的問題。總之，WAS不是被設計成從安全的角度考慮來隔離應用程式的。

5. 在使用基於表單登入的 WAS 應用程式中，為什麼必須使用單點登入？

答：
原因是非常簡單的。通過使用單點登入（Single sign-on，SSO），WebSphere Application Server 在 Web 請求之間保留使用者狀態為 LTPA cookie。如果沒有使用單點登入，每個單獨的請求都需要認證。如果您選擇基於表單的登入，一旦表單完成了使用者的認證，它將重定向回原始請求的 URL。沒有單點登入，使用者的認證將丟失並且這些認證將失敗。當使用基本的認證時並不會出現這種情況，因為認證資訊包含在每個 HTTP 請求中，並且 WebSphere Application Server 在任何需要的時候都可以使用它（這並不影響安全和效能）。
問題：在將本地系統用作 Windows? 上的安全登錄檔時，WebSphere Application Server 為何需要“Act as part of the operating system”許可權？

答：
這個問題的回答實際上是確定的，不過在此我還得使用視情況而定 進行回答。

在任何作業系統上，如果使用者登錄檔儲存在本地，WebSphere Application Server 就需要執行本地作業系統呼叫，用於對底層使用者登錄檔進行認證。對於 Windows，必須有“Act as part of the operating system”許可權才能執行特定於 Windows 的本地作業系統呼叫。（說一點題外話，要在 UNIX? 上使用本地呼叫，您必須以 root 使用者身份執行 WebSphere Application Server，因為 root 是可以查詢登錄檔來獲得系統上所有使用者 ID 的唯一使用者 ID。）我認為，作業系統限制對密碼檢查 API 進行訪問的原因是，如果不加限制，任何使用者都可以使用任何使用者級程式呼叫它們，而且有可能使用字典攻擊來試圖獲取使用者的密碼。強制使用者首先獲得 root（或作為作業系統的一部分）訪問許可權來限制此類風險的發生。當然，這種方法不是完美的，但還是有一些幫助。別忘了，這不是“WebSphere 要求”，而只是底層作業系統的要求。

因為作業系統各有特點，所以一般建議將 LDAP 用作安全登錄檔。這樣，在使用不同的作業系統進行部署、測試和生產時，就不必考慮作業系統之間的差異。使用 LDAP 的另一個優點是，在 WebSphere Application Server 使用 LDAP 伺服器（通過 LDAP 繫結）進行認證時，您不需要使用 LDAP 管理使用者 ID；LDAP 目錄中的任何有效的使用者 ID 和密碼都可以這樣使用。另一個方法是使用自定義使用者登錄檔，該登錄檔在開發環境中使用具有使用者 ID 和密碼的檔案。

因此，除了沒有許可權的使用者外，如果取消授予作業系統許可權的要求，則 LDAP 和使用者自定義登錄檔都是不錯的選擇。

本答案，來自IBM WebSphere 開發者技術期刊中的來自 Tom Alcott 的評論:欲言又止的 WebSphere Application Server 的相關問題
問題：WebSphere Applicaitona Server V6.1 在安全方面有哪些增強功能？

答：
A，預設安全設定

在WAS V6.1 中，很多基本安全配置步驟現在已設定為預設設定--這樣做是為了符合預設安全 原則。其中的一些例子包括：
  • 在安裝期間自動啟用管理安全性。
  • 預設情況下，會對所有內部傳輸進行身份驗證。
  • 預設情況下，會對大部分內部傳輸進行加密。預設情況下，DCS（通常在計算單元內執行）保持未加密狀態，但可以為其啟用加密。
  • 不使用預設加密金鑰，會自動建立計算單元特定的金鑰集。
  • 預設情況下，JNDI 對所有人都是隻讀的（而不是讀/寫）。

預設情況下，訊息傳遞將連線僅限制於授予了匯流排連線角色的經過身份驗證的使用者。預設情況下，AllAuthenticated 不再具有此角色。

B，證照、私鑰和加密金鑰管理

信任儲存區和金鑰儲存區的管理現在作為第一類構造進行處理。這包括管理金鑰儲存區中的證照和金鑰，以及管理整個計算單元內這些金鑰的複製。提供了大量小增強功能，這些功能在易用性方面得到了很大的提高。

C，更為複雜的註冊中心配置支援

包括支援檔案註冊中心、可以將多個 LDAP 目錄組合為一個邏輯註冊中心、直接支援 LDAP 故障轉移等。

D，隔離各個管理員

在 V6.1 前，管理授權是在整個計算單元範圍內進行的。如果針對個體授予了管理許可權，則對計算單元中的每個節點、伺服器和應用程式都有管理許可權。而通過使用 V6.1，現在可以更精細地對管理許可權作用範圍進行劃分。

E，提供從 Windows 桌面到內部網應用程式的單點登入

WebSphere Application Server V6.1 支援 SPNEGO 信任管理直譯器（Trust Association Interceptor，TAI），該直譯器允許將 Windows 桌面的 Kerberos 憑據從瀏覽器傳送到 WebSphere Application Server，然後將其作為標識訪問 WebSphere 資源。以前釋出的 IBM Software Services for WebSphere 提供了一個稍有些不同的 SPNEGO TAI 版本，但現在通過使用 V6.1，我們可獲得受到全面支援的產品解決方案。

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

相關文章