我正在研究构建一个系统,通过基于微服务的架构提供“实体访问控制”,以根据请求用户限制对某些数据的访问。已经实现了完整的基于角色的访问控制(RBAC)系统,以限制某些操作(基于API端点),但尚未实现针对一种数据实体而非另一种数据实体限制这些操作的措施。因此,需要一个基于属性的访问控制(ABAC)系统。
考虑到该系统的要求应合适且遵循最佳安全逻辑实现实践的优先事项是保持在单个位置中,我设计了一个外部“实体访问控制”API。
我的设计的最终结果类似于我曾看过的以下图像(我认为是来自axiomatics.com)。
问题在于一旦涉及到响应列表结果的API,整个系统就会崩溃。
例如,客户API上的/api/customers端点接受参数,如查询过滤器、排序、顺序和限制/偏移值以实现分页,并向前端返回客户列表。那么,在微服务架构中,如何为每个实体提供ABAC呢?
迄今为止,针对上述问题的可怕解决方案包括:
1. 获取第一页结果,将所有这些结果发送到EAC API,获取响应,从响应中删除被拒绝的结果,从DB获取更多客户,检查这些客户...并重复,直到获得一页结果或者DB中没有客户为止。测试了14,000条记录(在我的情况下完全合理),对于一个没有权限查看任何客户的人,需要30秒才能获得API响应。
2. 每次请求所有客户端点时,都会向EAC API发送一个请求,以获取原始请求用户可用的每个客户的请求。测试了14,000条记录,对于有权限查看所有客户的人,响应有效载荷将超过半兆字节。我可以将其拆分成多个请求,但这只是在有效载荷大小与请求垃圾邮件之间平衡,性能惩罚并没有消失。
3. 放弃查看列表中的多个记录的能力。这完全破坏了API对客户需求的使用。
4. 在每个API中存储执行ABAC控件所需的所有数据和逻辑。这充满危险,并且基本上保证在我所处的领域中以超出我的风险承受能力的方式失败。
注意:我之所以测试了14,000条记录,只是因为它是我们当前数据状态的基准。一个API可以服务于100,000或1m条记录是完全可行的,因此任何涉及遍历整个数据集或通过电线传输整个数据集的内容都是不可持续的。
因此,问题在于如何在微服务架构(如图所示)中实现外部化的ABAC系统,同时还能够处理响应包含查询过滤器、排序、顺序和限制/偏移值以实现分页的多个实体的请求。
考虑到该系统的要求应合适且遵循最佳安全逻辑实现实践的优先事项是保持在单个位置中,我设计了一个外部“实体访问控制”API。
我的设计的最终结果类似于我曾看过的以下图像(我认为是来自axiomatics.com)。
例如,客户API上的/api/customers端点接受参数,如查询过滤器、排序、顺序和限制/偏移值以实现分页,并向前端返回客户列表。那么,在微服务架构中,如何为每个实体提供ABAC呢?
迄今为止,针对上述问题的可怕解决方案包括:
1. 获取第一页结果,将所有这些结果发送到EAC API,获取响应,从响应中删除被拒绝的结果,从DB获取更多客户,检查这些客户...并重复,直到获得一页结果或者DB中没有客户为止。测试了14,000条记录(在我的情况下完全合理),对于一个没有权限查看任何客户的人,需要30秒才能获得API响应。
2. 每次请求所有客户端点时,都会向EAC API发送一个请求,以获取原始请求用户可用的每个客户的请求。测试了14,000条记录,对于有权限查看所有客户的人,响应有效载荷将超过半兆字节。我可以将其拆分成多个请求,但这只是在有效载荷大小与请求垃圾邮件之间平衡,性能惩罚并没有消失。
3. 放弃查看列表中的多个记录的能力。这完全破坏了API对客户需求的使用。
4. 在每个API中存储执行ABAC控件所需的所有数据和逻辑。这充满危险,并且基本上保证在我所处的领域中以超出我的风险承受能力的方式失败。
注意:我之所以测试了14,000条记录,只是因为它是我们当前数据状态的基准。一个API可以服务于100,000或1m条记录是完全可行的,因此任何涉及遍历整个数据集或通过电线传输整个数据集的内容都是不可持续的。
因此,问题在于如何在微服务架构(如图所示)中实现外部化的ABAC系统,同时还能够处理响应包含查询过滤器、排序、顺序和限制/偏移值以实现分页的多个实体的请求。
sales
和leads
,而Stewart只能看到leads
),那么你只需要让EAC API返回实体类型与允许访问级别的映射,然后让你的API在不发送数据的情况下过滤数据。如果你想要每条记录的(共享)模型,比如Mary可以访问lead1
和lead2
,但是Stewart只能访问lead1
,那么你需要将信息存储在某个地方,然后问题就是“我们是否有比记录更多的规则”。 - zaitsman