1. 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，并将这些策略存储在适当的策略库中。

2. PIP 的定位及关键点思考

1，PIP 应属于支撑平台的一个组件，不直接面向客户

2，PIP 能统一的处理各方面的数据，当数据源和 PIP 对接时，尽量减少数据源的改动，降低对数据源的要求，而把主要工作负荷都放到 PIP 里

3，PIP 的工作不是简单的收集存储数据源的属性，而应该具备数据清洗，关联，统计分析并产生新的属性的能力

4，数据源和 PIP 的分工边界：数据源需要上报只有其才可以拿到的固有属性，比如：账号，IP，设备码，运行的软件，打开的端口等，不建议让数据源上报复杂的统计分析类属性，比如：1 小时登录的次数，是否运行了违规软件，登录过的地点等。PIP 在接收数据源上报的基础属性以后，可以对属性进行加工，关联，并通过运算产生如上新的属性

5，未来 PIP 占用系统资源数量级会远超系统其他模块

3. 典型流程

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

1，其中消息中间件，数据处理，数据存储均可以分离部署，并均可采用分布式部署。

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

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

4. PDP 和 PIP 对接

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

1，HTTP 主动通知结合 HTTP 主动查询，即 PIP 计算出最新的数据后主动通知 PDP，或 PDP 需要用到某些属性时主动找 PIP 查询。该方式实时性较好，但会严重降低 PDP 乃至整个系统的性能，不推荐。

2，共享 Redis 结合共享数据库，PIP 运行时会把数据在数据库和 Redis 里都存放一份，数据库和 Redis 均为异步更新，数据库更新周期远大于 Redis。PDP 启动后从数据库或 Redis 加载数据到自己内存，并周期性从 Redis 更新数据到内存，决策过程中只读内存。该方案优势在于性能较高，但 PDP 实时性会降低，推荐该方案。

5. 总结

1，基于目前的资源分配情况及需要处理的数据量，暂时无需额外引入其他开源框架（比如 flink 或其他文档数据库），这些开源框架本身也要占用系统资源，在数据量并不大的情况下反而会导致资源占用不均衡（比如框架占用了 4g 内存，本身处理只占用 2g 内存）

2，该方案内所涉及功能组件已经在实际使用，经过了长期运行证明可以适应目前的业务，而从零开发性价比太低并且没有任何业务驱动。

3，该方案已经实现了数据的统一收集，过滤，分析统计，存储等一系列流程，并且可以实现灵活配置处理规则（业界大多数做法都是写死的）实现了和 pdp 的闭环对接，在数据量并不大的情况下无需引入新的流程。

4，未来如果数据量大到一定程度则可以在该架构上持续改造（比如把 flink 结合进来）

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

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

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

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