各種權限（甚至包括 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 容器
| 1 2 |
<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
| 1 | <webAppSecurity httpOnlyCookies=’true’ /><!- – This is the default- -> |
默認情況下，HTTP 會話在 Liberty 配置文件中也被設置為 HTTP only。要在服務器的 server.xml 中顯式設置此屬性，可以包含一個具有 cookieHttpOnly 屬性的 httpSession 元素，比如清單 8 中的示例。
清單 8. 在 Liberty 中將 HTTP 會話 cookie 限制為 HTTP Only
| 1 | <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 服務器證書警告，第二部分
以下文章點擊率最高
Loading…