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

一

PIP的定位

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

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

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

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

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

在執(zhí)行這些策略決策之前，必須對它們進行徹底的測試和評估，以確保它們滿足預期的需要，這些功能由PAP執(zhí)行。PAP可定義為：策略管理點（PAP）：提供一個用戶接口，用于創(chuàng)建、管理、測試和調(diào)試DP和MP，并將這些策略存儲在適當?shù)牟呗詭熘小?/p>

二

PIP的定位及關鍵點思考

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

三

典型流程

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

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

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

延遲，滑動窗口，吞吐量，狀態(tài)，流批一體）

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

四

PDP和PIP對接

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

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

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

共享Redis結合共享數(shù)據(jù)庫，

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

五

總結

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

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

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

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

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

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

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

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

審核編輯 黃宇