非基于角色的安全性?

我最近所做的与此类似的事情最终看起来像:

Person (person_id, name, etc)

Role (role_id, name [admin manager, stock manager, content manager, authorized reader, etc])

Technical_Manual (manual_id, title, etc)

Technical_Manual_Role (manual_id, person_id, role_id)

此外,在我的系统中,角色通常只是默认的权限束,特定操作(读取、编辑、移动、删除等)的用户权限可以根据角色的基线进行上下变化。

在“角色”模式中强制匹配所有内容的问题是,在这些规则非常“细粒度”的情况下,要保持完整的安全规则集的后勤/卷/工作负载。

我所说的细粒度,是指在任何一个授权决策中都存在大量潜在的识别因素的情况,对于每一个识别因素(比如,“客户申请的信贷金额”),都有很大的“价值”范围(比如,申请的信贷金额有25个不同的范围)。

假设有三个这样的区别因素,每个因素有七个可能的价值范围(7个不同的信贷金额范围)。然后您需要定义7*7*7=343个角色。然后,对于系统中的每个用户,您必须分配该用户可以执行的所有角色的完整子集。如果一个用户被授权决定500000.000的信用申请,那么很有可能(但同样,不是绝对确定!)他还被授权决定5.000.000的信用申请。

这就是为什么在我的项目中,与安全相关的设施仅限于标识(userid)和身份验证(usercertificate)。没有任何授权规定。必须通过用户定义的约束来解决这些问题。

只是想从概念的角度增加更多。尽管RBAC(基于角色的访问控制)似乎很流行,但也有很多类似于DAC、MAC的模型已经在较长时间内用于解决访问控制问题(RBAC实际上在1995年左右正式化,而其他模型已经存在更长时间并被军方使用)。您解释需求的方式我看到多个模型在使用中

1. RBAC——在您谈到的“系统角色”的情况下使用。
2. 基于属性/策略的访问控制-用于所有与手册相关的部分。
3. MAC-用于控制对基本手册的访问,即每个手册和用户都有相关的敏感度级别,他们需要根据特定标准进行匹配才能访问。

这些模型可以使用诸如XACML之类的标准(并在运行时使用策略引擎实现进行评估)来表示,这些标准可以描述策略。例如,在您的案例中,该策略看起来像是

(基于属性)

如果userid=manual.technical_content_manager,允许“所有人”编辑“手册”。

如果userid=manual.stock\u manager,允许“所有人”发送“手动”

(RBAC)

允许“帮助台”查看“手动信息”、“手动”

允许“管理员”查看、“编辑”、“发货”手动

(MAC)

如果userid.level>=manual.level,允许“所有人”查看“手动”。

基于上面的策略模型,很明显您需要跟踪用户角色映射,可以使用表完成映射,并在运行时检索到映射,以便在运行时向策略引擎提供数据。

我知道这看起来有点笨拙,但你可以这样做:

Roles(role_id, etc)

Technical_Manual(manual_id, acceptable_roles, etc) 哪里 acceptable_roles 是分隔列表

然后在程序中,拆分分隔列表。我不是说这是最好的方法,但它会奏效的。不过,我不知道这是否对军事应用是最好的。)

您可以对授权采取更基于声明的方法。

每个用户可能拥有或可能没有一些可以直接附加到角色的常规权限(例如,管理员)。我们将使用您的表来匹配他们拥有高级权限的出版物的特定用户,并为这些条目创建声明。

因此,当请求用户的授权时,您会得到一个声明集合,一些高级声明派生自角色,一些特定于发布的声明派生自表。

对混沌反应的评论:

我突然想到,“系统级”角色可以适合相同的方案,如果这样的东西的手动ID可以设置为空或一些魔力值。是的,我知道,有些人对空值有强烈的厌恶,但它在这里起作用。然后会有一个单独的“安全物品”桌子,而且都是干净的。

我确实在三个经理领域遇到了很多麻烦。我们有很多疑问,比如,“鲍勃负责什么书?”,这需要对所有三个字段进行带有大或的查询。这意味着我们需要三个索引。后来我意识到我们最好把它分成一张单独的桌子。但是把授权读者扔到同一张桌子上…很多东西都清理干净了。把系统级的东西也扔进去…我喜欢。问“玛丽·琼斯有什么权利?”以及“谁有权使用F-15航空电子设备手册?”“谁是我们所有的技术内容经理?”等。