如何设计基于角色的访问控制?


15

我试图遵循基于角色的访问控制模型来限制用户在系统中可以执行或不能执行的操作。

到目前为止,我具有以下实体:

用户 -将使用该系统的人员。这里有用户名和密码。 角色 -用户可以拥有的角色的集合。诸如经理,管理员等 资源之类的东西-用户可以操纵的东西。像合同,用户,合同草稿等 操作 -用户可以使用资源执行的操作。像创建,读取,更新或删除。

现在,我在图中有这样关系的地方对此表示怀疑:

操作(0 .. *) 资源(0 .. *)上执行,该资源生成一个名为权限的表,该表将存储该操作资源

权限表如下所示(它的一行): ID: 1,操作:创建,资源:合同。

这意味着许可,以创建一个合同

我这样做是因为我觉得某些资源可能无法进行各种操作。例如,对于注册合同,用户可以上传文件,但是此操作不适用于注册提供商

所以,现在当管理员将被赋予权限角色,他不会有资源的清单,在系统中注册的每一个操作。

我认为每种资源都有自己的可以在他身上执行的操作的集合。

我可以澄清一下某些事情是无法理解的。

这是实施rbac的正确方法吗?

编辑

我的意思是,通过拥有一个包含操作资源权限表,我有了两个额外的表,因为我想将资源操作相关联。我本来也可以完成资源具有权限的权限,权限表将存储这些权限。

但是然后发生的是,当管理员分配资源时,某些权限甚至对于某些资源都不存在。

因此,我想从数据库设计的角度来了解具有一个列操作和另一个资源的表权限是否正确?如果这样下去我会遇到问题吗?


2
您所说的“正确”是什么意思?注意:不要以“最佳实践”这样的重言式回答。 陈述您的具体要求。
罗伯特·哈维

1
我对“正确”的定义通常是“最有效地满足您软件的功能和非功能要求的”。请注意,NIST为基于角色的安全性提供了详细的准则和最佳实践。参见csrc.nist.gov/groups/SNS/rbac
罗伯特·哈维

您可能对查看pundit项目中的完成方式感兴趣。
安塔尔·伯德

1
您应该考虑为此使用一个库。
RibaldEddie '17

有很多图书馆可以为您执行RBAC或ABAC
David Brossard

Answers:


11

您的设计似乎离我很近。只是几个建议。

用户-将使用该系统的人员。这里有用户名和密码。

精细

角色-用户可以拥有的角色的集合。经理,管理员等资料

没关系。但是,您还将需要一个“ UserRoles”实体/表,该实体/表将告诉您哪些用户具有哪些角色。给定的用户可能具有两个或多个角色。

资源-用户可以操纵的事物。像合同,用户,合同草稿等。

可能只是语义问题。我认为用户不会直接操纵资源;角色。因此,它成为用户->用户角色->角色->操作->资源

操作-用户可以使用资源进行的操作。像创建,读取,更新或删除。

是的,除了“角色”而不是“用户”

权限表如下所示(它的一行):ID:1,操作:创建,资源:合同。这意味着可以创建合同。

嗯 有两种解决方法。您可能具有所描述的权限表,但是您还需要一个附加RolePermissions表/实体,该表/实体告诉您哪个角色具有哪个权限。但是我不确定这是否必要。

一种更简单的方法是使用具有以下列/属性的权限表/实体:角色ID,操作ID,资源ID。这样,将操作x资源组合直接分配给角色,而不是加载到分配给角色的权限中。它消除了一个实体。确实不需要单独的角色不可知权限表,除非您希望预先定义允许的权限组合和不允许的权限组合。


首先,我完全同意“角色”而不是“用户”的更正。这也是我的意思。现在,我想同时将资源与操作相关联。例如:合同资源具有类似upload_file的操作。所以我不希望当管理员向角色分配权限时,upload_file操作也出现在另一个没有upload_file操作的资源中,例如providers(另一个资源)。
imran.razak

13

我不会使用或实施RBAC。相反,我将使用ABAC。让我解释...

  • RBAC或基于角色的访问控制与用户管理和角色分配有关。在RBAC中,您可以说爱丽丝是经理。您可以定义静态权限。例如,经理可以批准贷款。因此,有一个从Alice到经理的链接,以允许aroveLoan作为许可。有很多系统可以让您做到这一点,因此您无需实现自己的表。甚至LDAP也支持有限的RBAC集。只要您具有相对较小的角色和权限集,就可以。但是,如果要像您的情况那样考虑特定的权限怎么办?查看,删除,插入?如果您想考虑人际关系怎么办?
  • ABAC或基于属性的访问控制与策略驱动的细粒度授权有关。通过ABAC,您可以使用RBAC中定义的角色并编写策略,例如
    • 经理可以查看其部门中的文档
    • 员工可以编辑自己拥有的文档

在您的问题中,您实质上定义了信息模型。您的对象及其属性,例如用户(名称,密码,部门...);对象(例如合同)等等。

信息模型

因此,在ABAC中,您将使应用程序代码/逻辑与授权逻辑完全脱钩,然后使用属性将其存储为策略。权限本身直接存储在策略中(请参见上面的示例)。ABAC部署架构如下所示

基于属性的访问控制架构

关键是,如果您采用ABAC方法,则可以为ABAC编写策略(在XACML或ALFA中-有很多用于此的工具),而不必再次自定义代码或自定义实现RBAC或访问控制。


1
在您的政策示例中,经理说可以查看其部门中的文档。这是否意味着系统将已经具有预定义的权限,角色和资源类型?
imran.razak

否。这意味着您将拥有将用户(爱丽丝)与其角色(经理...)相关联的东西(LDAP?表?)。然后,您将拥有一个包含文档元数据的表(通常是您要保护的应用程序中的表)。权限本身(查看,编辑,删除)存储在策略中。
大卫·布罗萨德
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.