访问控制中PIP的典型流程和关键点思考

PIP的定位

企业ABAC中访问控制机制的部署实施有几个重要的功能“点”,用于检索和管理策略的服务节点,其中包含了用于处理策略上下文或工作流、以及检索和评估属性的一些逻辑组件。下图给出了这些功能点:策略执行点(PEP)、策略决策点(PDP)、策略信息点(PIP)和策略管理点(PAP)。这些组件处于同一环境中,相互配合以实现访问控制决策和策略执行。

访问控制中PIP的典型流程和关键点思考_第1张图片

策略决策点(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的定位及关键点思考

  1. PIP应属于支撑平台的一个组件,不直接面向客户
  2. PIP能统一的处理各方面的数据,当数据源和PIP对接时,尽量减少数据源的改动,降低对数据源的要求,而把主要工作负荷都放到PIP里
  3. PIP的工作不是简单的收集存储数据源的属性,而应该具备数据清洗,关联,统计分析并产生新的属性的能力
  4. 数据源和PIP的分工边界:数据源需要上报只有其才可以拿到的固有属性,比如:账号,IP,设备码,运行的软件,打开的端口等,不建议让数据源上报复杂的统计分析类属性,比如:1小时登录的次数,是否运行了违规软件,登录过的地点等。PIP在接收数据源上报的基础属性以后,可以对属性进行加工,关联,并通过运算产生如上新的属性
  5. 未来PIP占用系统资源数量级会远超系统其他模块


 

典型流程

PIP系统处理流程等同于典型的ETL数据处理流程,先从各种数据源收集各种数据,再通过统一的数据处理流程,将多维度的数据统一过滤整合,最后统一存储,一个标准的流程架构(PIP)如下图:

访问控制中PIP的典型流程和关键点思考_第2张图片

  1. 其中消息中间件,数据处理,数据存储均可以分离部署,并均可采用分布式部署。
  2. 数据处理部分通常是根据不同的业务选用不同的处理方式,目前业界综合使用最多的是基于Flink的流式处理。目前基于文件的处理框架(比如hadoop+hbase)不太流行了,流式处理框架里主流的flink相对比storm具备更好的吞吐量(也就是性能更好),并且自身支持批处理及状态记录,这些优势导致其目前成为流式处理的主流框架,具体如下图(比较重要指标是:延迟,滑动窗口,吞吐量,状态,流批一体

访问控制中PIP的典型流程和关键点思考_第3张图片

数据存储方面,目前业界综合使用最多的是ES,或ES结合某个列式存储数据库比如Hbase,或文档数据库比如mangoDB。Es结合其他数据库的方式只用于海量数据的查询检索,如果数据量未到该量级(比如单次查询的数据量约小于1亿条记录)则无需这么做

PDP和PIP对接

PDP和PIP对接可以采用2种对接方案,如下图:

访问控制中PIP的典型流程和关键点思考_第4张图片

  1. HTTP主动通知结合HTTP主动查询,即PIP计算出最新的数据后主动通知PDP,或PDP需要用到某些属性时主动找PIP查询。该方式实时性较好,但会严重降低PDP乃至整个系统的性能,不推荐。
  2. 共享Redis结合共享数据库,PIP运行时会把数据在数据库和Redis里都存放一份,数据库和Redis均为异步更新,数据库更新周期远大于Redis。PDP启动后从数据库或Redis加载数据到自己内存,并周期性从Redis更新数据到内存,决策过程中只读内存。该方案优势在于性能较高,但PDP实时性会降低,推荐该方案。

总结

  1. 基于目前的资源分配情况及需要处理的数据量,暂时无需额外引入其他开源框架(比如flink或其他文档数据库),这些开源框架本身也要占用系统资源,在数据量并不大的情况下反而会导致资源占用不均衡(比如框架占用了4g内存,本身处理只占用2g内存)
  2. 该方案内所涉及功能组件已经在实际使用,经过了长期运行证明可以适应目前的业务,而从零开发性价比太低并且没有任何业务驱动。
  3. 该方案已经实现了数据的统一收集,过滤,分析统计,存储等一系列流程,并且可以实现灵活配置处理规则(业界大多数做法都是写死的)实现了和pdp的闭环对接,在数据量并不大的情况下无需引入新的流程。
  4. 未来如果数据量大到一定程度则可以在该架构上持续改造(比如把flink结合进来)

注意,这种改造的好处是可以将PDP和PIP分离,分不同的进程甚至部署到不同的服务器上,但在目前硬件资源有限的情况下没有实际意义,这么配置会带来2方面负面作用:

A,虽然PDP的资源占用大幅减少,但其一大半工作被PIP分担,PIP同样会占用硬件资源,启动2个服务肯定比单个服务占用更多的资源,同时增加了额外的数据交互开销(比如原来用户信息和设备信息等直接通过登录请求携带过来,但流程分离后需要在PIP里单独开启用户和设备数据同步流程)。

B,本来PDP和PIP在一个进程全部读写内存效率最高,分离后至少也要用Redis做数据同步,处理性能和实时性两者必有一个会严重下降。

综合评估,大数据处理是建立在大量硬件资源的前提上,采用硬件换取效率,在资源不够的情况下,整个系统还是交互越少效率越高。

你可能感兴趣的:(网络安全)