訪問控制中PIP的典型流程和關(guān)鍵點(diǎn)思考

一

PIP的定位

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

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

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

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

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

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

二

PIP的定位及關(guān)鍵點(diǎn)思考

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

三

典型流程

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

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

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

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

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

四

PDP和PIP對接

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

HTTP主動(dòng)通知結(jié)合HTTP主動(dòng)查詢，

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

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

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

五

總結(jié)

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

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

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

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

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

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

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

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

審核編輯 黃宇