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

27
我正在研究构建一个系统,通过基于微服务的架构提供“实体访问控制”,以根据请求用户限制对某些数据的访问。已经实现了完整的基于角色的访问控制(RBAC)系统,以限制某些操作(基于API端点),但尚未实现针对一种数据实体而非另一种数据实体限制这些操作的措施。因此,需要一个基于属性的访问控制(ABAC)系统。
考虑到该系统的要求应合适且遵循最佳安全逻辑实现实践的优先事项是保持在单个位置中,我设计了一个外部“实体访问控制”API。
我的设计的最终结果类似于我曾看过的以下图像(我认为是来自axiomatics.com)。

EAC API implementation concept

问题在于一旦涉及到响应列表结果的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系统,同时还能够处理响应包含查询过滤器、排序、顺序和限制/偏移值以实现分页的多个实体的请求。

1
所以这里有几件事情。如果你只是谈论实体类型的访问级别(例如,Mary可以看到 salesleads,而Stewart只能看到 leads),那么你只需要让EAC API返回实体类型与允许访问级别的映射,然后让你的API在不发送数据的情况下过滤数据。如果你想要每条记录的(共享)模型,比如Mary可以访问 lead1lead2,但是Stewart只能访问 lead1,那么你需要将信息存储在某个地方,然后问题就是“我们是否有比记录更多的规则”。 - zaitsman
1
如果您有更多的规则,您将发送记录。如果您有更多的记录,您将提取规则,然后过滤它们。 - zaitsman
我的使用情况绝对是“如果您想要每个记录(共享)模型,其中Mary可以访问lead1和lead2,但Stewart只能访问lead1”的情况。不确定我是否遵循了建议。 - Gary MacPherson
如果记录数量非常多,则为API提供规则...但如果规则是例如“此请求用户只能查看销售团队X拥有的客户”,这意味着我的客户API现在需要记录哪个销售团队拥有它们。虽然这并非不可行,但随着更复杂的规则,变得越来越困难,并且这意味着我用于确定ABAC控件成功/失败的任何内容都需要存储在每个API中,过滤逻辑现在也在每个API中。这现在不再是外部化控件,每个API都要负责自己的实现。 - Gary MacPherson
抱歉,显然规则必须与您正在访问的API上下文相关。例如,如果您有一个“客户”API,另一个“销售团队-客户”链接API和另一个EAC API,则除了在查询中限制页面大小(例如不超过50个客户)并让EAC处理工作外,您别无选择。在单体架构中,您需要连接这三个数据库表。 在微服务中,您需要跨三个API收集这三个表。 如果这些不经常更改,您可以将它们转储到某个内存缓存中,并且可以通过组来优化规则。 - zaitsman
但是最终这是您应用程序的业务逻辑,无论微服务如何,查询此数据的速度都会变慢,因为任何规则都是按记录基础进行评估的。另一个可能有效的缓存建议是,如果您有有限数量的用户-> 为他们预先创建这些有效载荷,并在创建新记录或添加新规则时刷新。 - zaitsman
1个回答

9
经过数十小时的研究,我们决定这是一个完全无法解决的问题,只是微服务(更重要的是隔离实体存储)的副作用。
如果您想获得可维护性(即单个外部基础设施)的实体级属性访问控制系统的好处,则需要采用单块式的实体存储方法。您无法同时获得微服务的好处。

1
分离的存储并不意味着您不能进行复制。用户和授权(甚至被过滤到目标类型)可以来自身份验证/授权服务,并且可以被复制到十几个服务中,只要授权服务能够以一种可以装饰每种存储类型的查询的方式表示这些授权(例如xSQL、Elasticsearch),以包括约束条件。 - Doug Moscrop
您可以将最佳实践框架扩展到整个系统,不仅限于引用完整性等内容,而是所有业务逻辑。 “可维护性”一词对不同的人可能有不同的含义,例如,在缩放和操作方面维护该中心部分可能很繁琐,并且在故障隔离方面使特性/功能相互隔离等。我并不是不同意您的观点,但请考虑实体存储“作为服务”的可能性,其中一个团队管理一种旋转存储并强制执行这些规则的方法。数据库只是抽象。 - Doug Moscrop
甚至可以通过服务网格实现,其中每个服务的数据库(它们本身就是“服务”)都被隔离,除了通过驱动程序/API 进行必要语句的修正以限制查询之外,一个团队维护这个。有人能够规避这个吗?当然可以,他们可以做很多有害的事情 - 其中一些是组织问题,最好不要用软件解决,而是采用流程(代码审查、其他防止操纵或配置基础设施的保护措施),但我更喜欢在一个更值得信赖的环境中工作... - Doug Moscrop
1
我认为这个问题和讨论非常出色地直接解决了我在ABAC中难以思考的问题。我喜欢“auth服务可以以一种可以装饰每种存储类型的查询(例如xSQL,Elasticsearch)以包括限制条件的方式来代表这些权利”的建议。 @DougMoscrop的建议是通过设计模式来实现这一点是有道理的,但也感觉像是一个过于基础的起点。 现在肯定有更好的授权框架可用? - James
你读过这篇文章吗?“在微服务架构中实现ABAC” https://www.identityserver.com/articles/implementing-abac-in-a-microservice-based-architecture - luenib
显示剩余5条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接