訪問控制中PIP的典型流程和關鍵點思考

一

PIP的定位

企業ABAC中訪問控制機制的部署實施有幾個重要的功能“點”，用于檢索和管理策略的服務節點，其中包含了用于處理策略上下文或工作流、以及檢索和評估屬性的一些邏輯組件。下圖給出了這些功能點：策略執行點（PEP）、策略決策點（PDP）、策略信息點（PIP）和策略管理點（PAP）。這些組件處于同一環境中，相互配合以實現訪問控制決策和策略執行。

策略決策點（PDP）：通過評估適用的DP和MP來計算訪問決策。PDP的主要功能之一是根據MP調節或消除DP間的沖突。

PEP執行PDP做出的策略決策：策略執行點（PEP）：以執行策略決策的方式響應主體對受保護客體的訪問請求；訪問控制決策由PDP生成。

PDP和PEP功能可以是分布式的或集中式的，并且可以在物理和邏輯上彼此分離。例如，企業可以建立一個集中控制的企業決策服務，該服務評估屬性和策略，生成策略決策并傳遞給PEP。這種方式方便對主體屬性和策略進行集中管理和控制?；蛘?，企業內的本地組織可以利用集中的DP存儲庫，實現獨立的PDP。ACM組件的設計和部署需要一個管理單元來協調ABAC的各組件功能。

要計算策略決策，PDP必須具有有關屬性的信息，這些信息由PIP提供。本文件中的PIP定義為：策略信息點（PIP）：作為屬性或策略評估所需數據的檢索源，提供PDP做出決策所需的信息。

在執行這些策略決策之前，必須對它們進行徹底的測試和評估，以確保它們滿足預期的需要，這些功能由PAP執行。PAP可定義為：策略管理點（PAP）：提供一個用戶接口，用于創建、管理、測試和調試DP和MP，并將這些策略存儲在適當的策略庫中。

二

PIP的定位及關鍵點思考

●PIP應屬于支撐平臺的一個組件，不直接面向客戶?！馪IP能統一的處理各方面的數據，當數據源和PIP對接時，盡量減少數據源的改動，降低對數據源的要求，而把主要工作負荷都放到PIP里?！馪IP的工作不是簡單的收集存儲數據源的屬性，而應該具備數據清洗，關聯，統計分析并產生新的屬性的能力?！駭祿春蚉IP的分工邊界：數據源需要上報只有其才可以拿到的固有屬性，比如：賬號，IP，設備碼，運行的軟件，打開的端口等，不建議讓數據源上報復雜的統計分析類屬性，比如：1小時登錄的次數，是否運行了違規軟件，登錄過的地點等。PIP在接收數據源上報的基礎屬性以后，可以對屬性進行加工，關聯，并通過運算產生如上新的屬性?！裎磥鞵IP占用系統資源數量級會遠超系統其他模塊。

三

典型流程

PIP系統處理流程等同于典型的ETL數據處理流程，先從各種數據源收集各種數據，再通過統一的數據處理流程，將多維度的數據統一過濾整合，最后統一存儲，一個標準的流程架構(PIP)如下圖：

其中消息中間件，數據處理，數據存儲均可以分離部署，并均可采用分布式部署。

數據處理部分通常是根據不同的業務選用不同的處理方式，目前業界綜合使用最多的是基于Flink的流式處理。目前基于文件的處理框架（比如hadoop+hbase）不太流行了，流式處理框架里主流的flink相對比storm具備更好的吞吐量（也就是性能更好），并且自身支持批處理及狀態記錄，這些優勢導致其目前成為流式處理的主流框架，具體如下圖（比較重要指標是：

延遲，滑動窗口，吞吐量，狀態，流批一體）

數據存儲方面，目前業界綜合使用最多的是ES，或ES結合某個列式存儲數據庫比如Hbase，或文檔數據庫比如mangoDB。Es結合其他數據庫的方式只用于海量數據的查詢檢索，如果數據量未到該量級（比如單次查詢的數據量約小于1億條記錄）則無需這么做

四

PDP和PIP對接

PDP和PIP對接可以采用2種對接方案，如下圖：

HTTP主動通知結合HTTP主動查詢，

即PIP計算出最新的數據后主動通知PDP，或PDP需要用到某些屬性時主動找PIP查詢。該方式實時性較好，但會嚴重降低PDP乃至整個系統的性能，不推薦。

共享Redis結合共享數據庫，

PIP運行時會把數據在數據庫和Redis里都存放一份，數據庫和Redis均為異步更新，數據庫更新周期遠大于Redis。PDP啟動后從數據庫或Redis加載數據到自己內存，并周期性從Redis更新數據到內存，決策過程中只讀內存。該方案優勢在于性能較高，但PDP實時性會降低，推薦該方案。

五

總結

基于目前的資源分配情況及需要處理的數據量，暫時無需額外引入其他開源框架（比如flink或其他文檔數據庫），這些開源框架本身也要占用系統資源，在數據量并不大的情況下反而會導致資源占用不均衡（比如框架占用了4g內存，本身處理只占用2g內存）。

該方案內所涉及功能組件已經在實際使用，經過了長期運行證明可以適應目前的業務，而從零開發性價比太低并且沒有任何業務驅動。

該方案已經實現了數據的統一收集，過濾，分析統計，存儲等一系列流程，并且可以實現靈活配置處理規則（業界大多數做法都是寫死的）實現了和pdp的閉環對接，在數據量并不大的情況下無需引入新的流程。

未來如果數據量大到一定程度則可以在該架構上持續改造（比如把flink結合進來）

注意，這種改造的好處是可以將PDP和PIP分離，分不同的進程甚至部署到不同的服務器上，但在目前硬件資源有限的情況下沒有實際意義，這么配置會帶來2方面負面作用：

●雖然PDP的資源占用大幅減少，但其一大半工作被PIP分擔，PIP同樣會占用硬件資源，啟動2個服務肯定比單個服務占用更多的資源，同時增加了額外的數據交互開銷（比如原來用戶信息和設備信息等直接通過登錄請求攜帶過來，但流程分離后需要在PIP里單獨開啟用戶和設備數據同步流程）。

●本來PDP和PIP在一個進程全部讀寫內存效率最高，分離后至少也要用Redis做數據同步，處理性能和實時性兩者必有一個會嚴重下降。

綜合評估，大數據處理是建立在大量硬件資源的前提上，采用硬件換取效率，在資源不夠的情況下，整個系統還是交互越少效率越高。

審核編輯 黃宇