使用 WebLogic Platform 8.1進行威脅防護概述

2019-11-18 12:52:57

字體：大中小

來源：轉載

供稿：網友

　　威脅防護過程
　　
　　威脅防護過程包括下面的步驟：
　　
　　1.　　識別 WebLogic Platform應用程序資產。
　　識別部署在應用程序環境中包括數據庫表、配置文件和安全機密等有價值的和敏感的資源。
　　
　　2.　　分析應用程序體系結構
　　一旦識別了應用程序體系結構，就應該很輕易將應用程序分解成更小的組件，并在更小的粒度級別上識別以下屬性：
　　
　　每個組件的外部訪問點。
　　識別每個組件和整個應用程序的訪問點時，需要知道“防護邊界”（PRotected Boundary）和“入口點（Entry Points）”。“防護邊界”的多層部署也是一種可能 (這依靠于應用程序需求)。
　　
　　數據流　必須保持組件內和跨組件的數據流的機密性和完整性。數據流是指組件內和跨組件的信道。
　　
　　特權代碼　應用程序內部可能被惡意訪問或使用的代碼。
　　
　　總的來說，上面的屬性有助于識別對整個應用程序的威脅。下例演示了分析過程
　　
　　示例體系結構如圖1所示，此體系結構包含兩個組件：域 D1和D2。我們來細致研究 D1。
　　
　　D1是一個帶有被治理的服務器的WebLogic 群集。該域的防護邊界有以下入口點：
　　
　　操作系統的開放端口。要封閉這些端口就需要一個ip 防火墻。
　　
　　內部用戶調用一個要害業務操作所需的開放SSL端口。要加速多個客戶端的握手過程，就需要一個硬件代理來進行 SSL認證。從代理端可以用一個預先建立的（pre-established）SSL連接與獨立被治理的服務器進行通信。
　　
　　外部用戶調用一個非要害業務操作（比如瀏覽目錄）所需的開放HTTP端口。
　　
　　密碼保護的客戶端只能執行非要害操作（比如目錄瀏覽），其他要害操作由SLL進行防護。
　　
　　內容驗證能力（使用xml防火墻）防止密碼保護客戶端調用要害的Web服務。
　　
　　拒絕外部T3 客戶端的訪問（使用 WebLogic 連接過濾器），因為訪問的內容無法驗證。
　　
　　兩組件 D1 和 D2之間的數據流應當使用SSL對要害業務操作進行保護。一旦代理和被治理的服務器之間的信道建立起來，它們就應當為以后的任何請求所重用。這就使SSL握手時間與常規的請求處理時間脫離關系。傳輸層的欺騙（spoofing）只能使用SSL握手進行保護，理解這一點很重要。
　　
　　組件內部的威脅與訪問特權代碼有關。無效的訪問策略與一系列的系統級別的jar有關，這些瓶頸是由于BEA可能答應了對要害資源的非法訪問造成的。下面的內容介紹了對特權代碼的不同代碼段進行防護的方法。
　　
　　代碼訪問應用程序/系統隊列
　　weblogic.jar、webservices.jar和其他WLI-specific jar應當使用java 訪問策略進行防護。否則任何非特權代碼就可以使用映射，濫用系統級別的jar，像隊列一樣來訪問受保護的資源。
　　
　　讓代碼訪問配置資源
　　weblogic.jar "webservices.jar、WLI-specific jar和 WLP-specific jar訪問配置相關的資源。這些jar應使用Java訪問策略進行防護。
　　
　　任何應用程序級別的jar都應當定義為拒絕訪問“KERNELID”的權限。使用Java策略文件在中的“weblogic.kernelPermission”可以拒絕訪問“KERNELID”的權限。
　　
　　與D1類似，D2所有與外部訪問點、數據流和訪問特權有關的細節都必須確定。下一步就是將這些信息連接起來以完成應用分析。
　　
　　3. 設計應用程序體系結構的安全概要文件。
　　所部署的任何應用程序的安全概要文件都建立在一組漏洞的基礎上。安全概要文件確定了設計和實現的方法，從而解決這些漏洞。從應用程序體系結構分析中獲得的信息為建立安全概要文件提供了正確的前后關系。
　　
　　下面總結出安全概要文件的一組強制性方面
　　
　　輸入驗證
　　
　　認證
　　
　　授權
　　
　　配置治理
　　
　　會話治理
　　
　　密碼支持
　　
　　異常報告
　　
　　審核和記錄
　　
　　參數操縱
　　
　　識別威脅
　　識別已部署應用程序受到的威脅及相關風險。要用更加結構化和可重用的方法來記錄攻擊數據，可以使用“Attack Tree”。要了解具體內容，請參考 Attack Modeling for Information Security and Reliability。
　　
　　4.　基于威脅信息來增強安全。
　　合理使用威脅信息可以增強所部署的應用程序的安全性。
　　
　　接下來的內容講述了具體的方法。
　　
　　識別Weblogic Platform應用程序資源
　　帶有WLPlatform組件的WebLogic域是由不同類型的資源組成的。很多資源都被認為是要害資源，必須進行保護。要害資源的例子包括：
　　
　　數據庫表
　　
　　系統表
　　
　　來自BEA的應用程序表
　　
　　數據庫連接池
　　
　　默認連接池
　　
　　特定于應用程序的連接池
　　
　　磁盤中的配置文件
　　
　　LDAP 存儲
　　
　　私有密鑰文件
　　
　　來自 WLI 的連接器資源
　　
　　用于WebLogic Platform 組件的JNDI資源。
　　
　　要獲得附加參考資料列表，請參閱： http://edocs.bea.com/wls/docs81/secwlres/types.Html#1209988
　　
　　分析應用程序體系結構：一個示例部署場景
　　圖1描述了一個部署場景。此應用程序由下面這兩個邏輯組件組成：
　　
　　D1：Portal 域
　　
　　D2：WLI 域
　　
　　
　　下文描述了每個域的功能和數據流：
　　
　　D1
　　
　　D1 接收 Web服務、基于瀏覽器的請求（HTTP或HTTPS）和來自因特網的T3s請求。
　　
　　D1 通過Web服務（HTTP/HTTPs）、JMS （T3和 T3s）和 EJB 調用（T3和T3s）發送和接收往來于D2的消息。
　　
　　D1 使用DB控件和自定義控件來執行要害業務操作。
　　
　　D2
　　
　　D2 接收Web服務、B2B （HTTP/HTTPS）和來自因特網的T3s請求。
　　
　　D2通過Web服務（HTTP/HTTPs）、JMS （T3和 T3s）和 EJB 調用（T3和T3s）發送和接收往來于D1的消息。
　　
　　D2 使用過程控件和自定義控件執行要害業務過程。
　　
　　注重：紅色箭頭表示通過SSL的數據流，黑色箭頭表示非SSL通信。虛箭頭表示從組件 D2到 D1的通信。
　　
　　注重以下幾點：
　　
　　每個域都與包含下列內容的 DMZ有關：
　　
　　IP 防火墻
　　
　　代理服務器
　　
　　IP 防火墻應當答應基于通信的HTTP和SSL的兩個不同的端口。由于下列原因，兩個防火墻進行了類似的配置：
　　
　　D1和D2都由危險程度相同的資源組成。
　　
　　每個組件都可以從因特網上通過HTTP進行訪問。比如：
　　
　　D1可以從Web瀏覽器和 Web服務進行訪問。
　　
　　D2 可以從 Web服務和B2B合作伙伴進行訪問。
　　
　　防止掃描空閑端口的防護也是必要的。
　　
　　每個組件都與其他的組件進行交互。假如某個組件使用了比較弱的安全約束，那么整個應用程序的一個惡意外部用戶就可能更輕易地訪問到此應用程序。由于其他組件答應從該組件進行“調用”，所以惡意的外部用戶就可以驅動調用這個組件，盡管它實在較強的外部防火墻的防護之下。此種情況可以這樣處理：
　　
　　所有組件都保留相同等級的安全防護?？梢詫⒎阑饓痛磉M行相同的配置來避免這種等級不一的問題。圖1演示了這樣的一個配置。
　　
　　或者，較弱安全防護的組件將所有客戶端信任的驗證授權給較強的安全標準。
　　
　　每個防火墻都應為每種類型的通信選擇唯一的端口。這就引出了防護的另一個層面，并減小同時暴露整個系統的風險。
　　
　　前面的實例中，由于某個特定的組件相對于其他組件而言需要保護更要害的資源，所以這里的特例可能并不適合。此時就需要一個更強的防火墻來防護對威脅比較敏感的組件，同時，禁止直接的外部訪問。具有不同防護能力的多重防火墻可以做到“縱深安全”。除防火墻的防護之外，我們還需要為試圖訪問任何應用程序組件的所有用戶提供一個集中認證服務。圖1所示進行了相同配置的代理服務器 P1和P2 正是滿足了此項目的。
　　
　　每個被治理的服務器都與一個本地XML防火墻有關。到達非SSL端口的所有消息都將繼續前往一個XML防火墻進行進一步的基于內容的過濾。這就保證了對 Web服務調用的細致訪問控制：
　　
　　密碼保護客戶端只能執行非要害操作，比如目錄瀏覽，而其他要害操作卻通過SSL保護。
　　
　　內容驗證能力防止了密碼保護客戶端調用要害的 Web服務。
　　
　　任何外部T3的客戶端訪問都被拒絕，因為內容無法通過驗證。外部T3連接可以使用一個連接過濾器來拒絕。
　　
　　代理服務器（比如圖1中的P1和P2）分別用443和444端口配置為基于SSL的認證。使用端口80和84配置為基于口令的認證。一旦通過認證，就應當使用安全標記（比如基于SAML的標記）將安全ID傳給被治理的服務器。HTTP和T3 流量的負載均衡也通過代理來完成。
　　
　　所有其他入站端口（inbound port）都應通過防火墻來封閉。出站端口（Outbound port）應保留開放狀態，以支持到因特網客戶端的回調操作（ Web服務）。類似NAT這樣的技術可防止直接暴露內部端口。
　　
　　代理應當配置為SSL 以處理443和444端口的任何請求。
　　
　　所有外部T3端口都不答應訪問，但外部 T3s客戶端卻是答應的。
　　
　　
　　注重：任何群集域都必須用適當防火墻技術進行防護。
　　使用 WebLogic Platform 8.1進行威脅防護概述