用于资源列表的微服务架构中的基于属性的访问控制 (ABAC)

Question

我正在研究构建一个系统的选项，以在基于微服务的架构中提供“实体访问控制”，以根据请求用户限制对某些数据的访问。已经实施了完整的基于角色的访问控制 (RBAC) 系统来限制某些操作（基于 API 端点），但是没有实施任何措施来限制针对一个数据实体的这些操作而不是另一个数据实体。因此需要基于属性的访问控制 (ABAC) 系统。

考虑到系统要求适合用途以及我自己的优先事项，以遵循安全逻辑实现的最佳实践以保持在一个位置，我设计创建了一个外部化的“实体访问控制”API。

我设计的最终结果类似于我看到的下图（我认为来自 axiomatics.com）

问题在于，当您开始谈论以结果列表作为响应的 API 的那一刻，整个事情就失败了。

例如。客户 API 上的 /api/customers 端点，它接受查询过滤器、排序、顺序和限制/偏移值等参数以促进分页，并将客户列表返回到前端。那么，您如何在微服务环境中为每个实体提供 ABAC？

到目前为止测试的上述问题的可怕解决方案：

• 获取第一页结果，将所有结果发送到 EAC API，获取响应，删除响应中被拒绝的结果，从数据库中获取更多客户，检查这些......并重复，直到获得页面结果或数据库中的客户用完。测试了 14,000 条记录（在我的情况下绝对在合理范围内）需要 30 秒才能为具有零权限查看任何客户的人获得 API 响应。
• 对于所有客户端点的每个请求，都会向原始请求用户可用的每个客户的 EAC API 发送一个请求。经测试，对于 14,000 条记录，对于有权查看所有客户的人来说，响应负载将超过半兆字节。我可以将其拆分为多个请求，但是您只是在平衡有效负载大小与请求垃圾邮件，而性能损失不会去任何地方。
• 放弃在列表中查看多条记录的能力。这完全打破了 API 用于客户需求。
• 在每个 API 中存储执行 ABAC 控制所需的所有数据和逻辑。这充满危险，考虑到我在其中工作的领域，基本上保证会以超出我的风险偏好的方式失败。

注意：我测试了 14,000 条记录，因为它是我们当前数据状态的基准。一个 API 可以服务 100,000 或 1m 条记录是完全可行的，因此任何涉及迭代整个数据集或通过网络传输整个数据集的事情都是完全不可持续的。

那么，问题就在这里......你如何在微服务架构中实现一个外部化的 ABAC 系统（如图所示），同时还能够通过查询过滤器、排序、排序和限制来处理响应多个实体的请求/offset 值以方便分页。

Answer 1

经过几十个小时的研究，最终确定这是一个完全无法解决的问题，只是微服务（更重要的是，隔离实体存储）的副作用。

如果您想要一个可维护的（如在单个外部化基础设施中）实体级属性访问控制系统的好处，则需要一种实体存储的整体方法。您无法同时获得微服务的好处。