WebSphere Application Server V7、V8 和 V8.5 中的高級安全性加強6

如果使用一個自定義註冊表，您一定想要使用所提供的機制保護此通信流。

要對 Liberty 配置文件啟用 LDAP SSL，可將一些元素包含在伺服器的 server.xml 中，類似於清單 3 中加粗的元素示例。

</featureManager>

<ssl id=”ldapSSLConfig” keyStoreRef=”ldapTrustStore”

trustStoreRef=”ldapTrustStore”/><keyStore id=”ldapTrustStore”

location=”ldapTrustStore.jks” type=”JKS” password=”123456″ />

<ldapRegistry id=”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 中啟用應用程序安全性

1	<webAppSecurity ssoRequiresSSL=’true’/>

通過在會話管理面板上指定相似的設置，還可以將 HTTP Session（默認情況下是 JSESSION） cookie 限制為只使用 SSL。

要在 Liberty 配置文件中將 HTTP Session cookie 限制為僅使用 SSL，可將一個 httpSession 元素包含在伺服器的 server.xml 中，該文件還包含 cookieSecure 屬性，如清單 5 中的示例所示。

清單 5. 在 Liberty 中啟用 HTTP Session cookie SSL

1	<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 角色本身沒有這個許可權。現在，可以向用戶授予

以下文章點擊率最高

Loading…