3

ReBAC:兼容DDD的下一代授权模型

 8 months ago
source link: https://www.jdon.com/71283.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

ReBAC:兼容DDD的下一代授权模型 - 极道

ReBAC是一种基于关系的访问控制模型,与传统的RBAC和ABAC模型相比具有更高的表现力、细粒度和灵活性。
它能够更准确地定义和管理用户的权限和角色,并且可以根据不同的业务领域进行定制。

在Agicap选择ReBAC的原因是为了提高安全性,并避免重复造轮子的情况发生。

特点:

  • ReBAC是一种新的授权管理范例,通过定义参与者和资源之间的关系来定义访问权限。
  • ReBAC具有灵活性、粒度细、领域驱动等特点,可以根据需要定义精确的授权。
  • ReBAC是一种集中化、安全的授权管理系统,可以快速有效地采取行动以应对漏洞和规则更改。

权限与角色定义:

  • 将“权限permissions”和“授权authorizations”视为同义词。
  • 在文献中,“permissions”通常用于指代更细粒度的权利,而“authorizations”则用于表征一组权利(更粗粒度)。
  • “角色”是permissions (细粒度)的分组(粗粒度)

因此,我们通常指的是定义和验证permissions权限的授权authorization 模型(有时使用角色的概念)。

ReBAC定义
ReBAC是基于关系的访问控制的缩写。这是一种新模型,其中参与者访问资源的授权是通过这些参与者和资源之间存在的关系来定义的

表现力:由于所有授权都基于定义关系的元组这一简单概念,例如('user:alice', 'editor', 'document:budget') - 意味着用户 "alice "可以编辑名为 "document:budget "的资源(或者,换句话说,用户 "alice "和资源 "document:budget "之间存在 "editor "关系),因此具有无限的灵活性,尤其是关系名称为简单字符串时。

领域驱动:ReBAC 概念的简单性和低仪式感(一只手就能数完)使我们能以非常直接的方式表达我们领域中对授权管理有用的概念。授权模型和领域之间不存在阻抗失配。我们不再需要适应通用的、技术性的、"一刀切 "的安全术语,其他授权模型及其组、角色、ACL 等概念往往就是这种情况。

精细:与以前的 RBAC 模型(基于角色的访问控制)中的 "角色 "概念不同,ReBAC 的灵活性及其关系(如所需数量)允许定义非常精细和精确的授权。与角色不同的是,ReBAC 允许细粒度的授权。虽然这允许更精确的访问,但可能意味着应用程序需要执行更多的授权检查。这有问题吗?不会,实现方法就是为此目的而设计和优化的。

可组合性和通用性:使用 ReBAC 完全可以构建基于角色的系统(RBAC)(取决于想要创建的授权模型)。ReBAC 甚至是实现 RBAC 的最佳方式(稍后我们将了解原因)。

极其精确,表现力极强:其强大的语法允许对关系进行分层、反式处理,并可使用对关系的代数运算(如联合、交叉和差分)建立更复杂的模型。

集中化:目前所有的 ReBAC 实现都是集中式的(同时仍具有弹性和冗余性)。如果需要撤销授权、删除访问权限或在检测到漏洞时更改规则,这样就能快速有效地采取行动。这与修改分散在不同地点或代码中的授权管理系统形成鲜明对比。

安全:与所有现代安全系统一样,ReBAC 基于 "执行最小权限 "和 "默认拒绝 "原则。虽然可以表达相反的意思(不鼓励),但默认情况下不会授予任何访问权限或权利。

ReBAC从哪里来?
ReBAC的概念源于Carrie Gates博士在2006年发表的一篇研究论文,题为“ Web 2.0安全和隐私的访问控制要求”。随后,谷歌采用了这一概念,创建了名为“Zanzibar”的授权系统。Zanzibar 是Google 用于管理其所有产品(包括 YouTube、Google Docs、Google Drive、Google Cloud 等)访问权限的系统。

ReBAC之前是如何处理授权的?
在ReBAC之前,我们行业还有其他授权模式,例如:

  • RBAC(基于角色的访问控制) :这是基于角色、权限和用户的粗粒度访问控制基于角色的模型在概念上仍然很有趣,但RBAC实现更加有限,因为它们不允许授权中的细粒度精度。这通常会导致每个角色背后的代码中存在隐式权限,或者需要额外的数据库或系统来单独存储细粒度的授权。
  • ABAC(基于属性的访问控制):ABAC,也称为基于策略的访问控制,定义了一种访问控制范例,其中基于使用结合属性向用户授予访问权限(想想这些作为标签)。ABAC允许表达一组复杂的规则,以根据属性的存在或不存在来评估访问。虽然丰富,但它比ReBAC更复杂且更少领域驱动,这意味着它是一个更以通用术语为中心的规范模型,需要适应不同的业务领域。
  • NIH(非此处发明综合症):这是指人们喜欢重新发明轮子并手动处理本地关系数据库。一般来说,强烈建议不要重新发明安全措施,授权管理也不例外。

开源项目:https://github.com/openfga

OpenFGA 是一个高性能且灵活的授权/许可引擎,专为开发人员构建,并受到Google Zanzibar的启发。它将强大的基于关系的访问控制 (ReBAC)和基于属性的访问控制 (ABAC)概念与特定于领域的语言相结合,可以轻松地制定授权和许可解决方案,这些解决方案可以针对任何规模的任何用例进行扩展和发展。

OpenFGA最初由Auth0/Okta开发,并 于2022年9月14日捐赠给云原生计算基金会,目前处于毕业的Sandbox级别。

为什么集中授权很重要?
将您的授权逻辑和决策集中到单个服务中,该服务可以灵活地处理不同产品的用例,从而为您带来明显的优势:

  • 更快地交付:您将能够更快地交付功能和产品,因为系统应该可以轻松扩展以满足新的需求。
  • 简化授权策略审核:明确的授权规则更容易被内外部各方审核。
  • 简化访问控制审核:授权服务为所有开箱即用的操作(读取和写入)生成日志
  • 降低运营成本:拥有单一授权系统使管理更简单。
  • 切换团队更简单:开发人员可以使用相同的授权概念和 API,无论他们在哪个团队工作。

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK