非基于角色的安全性？答案

【问题标题】：Non-role based security?非基于角色的安全性？
【发布时间】：2009-08-29 11:36:01
【问题描述】：

这是一个没有实际意义的问题，因为我不再参与这个项目，但它继续困扰着我。我想知道是否有人对未来的参考和一般的良好编程实践有更好的想法。

教科书式的安全方法是“基于角色的安全”。每个屏幕、报告或其他任务都附加到一个或多个角色；每个用户都被分配一个或多个角色；然后每个用户都可以使用与他的角色相匹配的屏幕等，仅此而已。对吧？

几年前，我带领一个团队开发了一个管理军事技术手册的系统。每本手册都有一个“技术内容管理员”，负责编写或编辑它； “库存经理”，负责跟踪副本并将其运出；还有一个“行政经理”，负责预算，因此他决定了这本书多久修改一次，印多少本等等。当然，每本书都有一群人会订购副本并阅读它。（因为这是军队，你必须获得授权才能拿到书、安全许可等等。）我们通常不担心实际的读者，而是担心每个基地管理图书馆的人，但这在这里并不重要。

所以...这些都是显而易见的“角色”，但角色与特定的书相关联。一个人可能是 A 书的技术内容经理，B 书的行政经理，以及其他 50 本书的读者。所以我们不能真的说用户有“角色”。每个用户对每本书都有不同的角色。

除此之外，还有更多常规的系统级权限：我们有几个系统管理员被授权更新系统中的任何内容，服务台人员可以看到几乎所有数据但不能更新，等等。

我最终创建了一个这样的数据库。（为了避免进入我们的一些奇怪的术语，我将在这里更改一些字段和表名，想法是一样的。）

人员（person_id、姓名等）

Technical_Manual（manual_id、title、admin_manager_person_id、stock_manager_person_id、content_manager_person_id 等）

Authorized_Reader（manual_id、person_id 等）

用户（user_id、admin_role 等）

我对这个方案并不满意，因为这意味着安全性被分成三个表：technical_manual 表、authorized_reader 表和 user 表。但是......有没有一种更清洁的方式我们可以做到这一点？有更好的想法吗？

【问题讨论】：

标签： database security

【解决方案1】：

我最近做的事情与这个有点相似的方式最终看起来像：

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)

此外，在我的系统中，角色大多只是默认权限包，特定操作（读取、编辑、移动、删除等）的用户权限可以根据其角色的基线上下变化。

【讨论】：

这可能是这种安全性最简单的形式。这很容易理解，并且允许一个人为不同的书扮演不同的角色，或者为同一本书扮演多个角色。
嗯，这很有潜力。我的评论没有空间作为评论，请参阅下面的新帖子。

【解决方案2】：

将所有内容强制装配到“角色”模式中的问题在于，在这些规则非常“细粒度”的情况下，要保持完整的安全规则集保持后勤/数量/工作量。

我所说的细粒度是指在任何授权决策中都有很多潜在的区别因素的情况，并且对于每个区别因素（例如，“客户申请的信用额度”），都有一个潜在的大范围的“价值”（例如，有 25 个不同的信用额度申请范围）。

假设存在三个这样的区分因素，每个因素都有七个可能值的范围（7 个不同的信用额度范围）。然后你必须定义 7*7*7 = 343 个角色。然后，对于系统的每个单独用户，您必须分配该用户可以执行的所有角色的完整子集。如果用户被授权决定 50.000.000 的信用申请，那么他很可能（但又不是绝对肯定！）他也被授权决定 5.000.000 的信用申请。

这就是为什么在我的项目中，与安全相关的设施仅限于识别（userid）和身份验证（usercertificate）。没有任何授权条款。这些必须通过用户定义的约束来解决。

【讨论】：

我基本同意。我坚信在工具有用时使用工具的原则，但没有声明因为某个工具对解决最后一个问题很有用，因此它是任何人在剩下的时间里都应该使用的唯一工具。也就是说，基于角色的安全性是一个很好的模型，通常灵活且易于使用，所以如果我可以通过少许调整使其工作，我愿意。如果您无法在不创建数千个角色的情况下使您的应用正常运行，那么它可能不是该应用的正确解决方案。

【解决方案3】：

只是想从概念的角度添加更多内容。尽管 RBAC（基于角色的访问控制）似乎很流行，但有很多模型（如 DAC、MAC）可用于解决访问控制问题的时间更长（RBAC 实际上已在 1995 年左右的某个时候正式化，而其他模型已经存在了更长的时间并被军方使用）。您解释要求的方式我看到多个模型在使用中

RBAC - 用于您所说的“系统角色”。
基于属性/策略的访问控制 - 用于所有与手册相关的部分。
MAC - 用于控制对基本手册的访问，即每个手册和用户都有关联的敏感度级别，他们需要根据特定标准进行匹配才能访问。

这些模型可以使用可以描述策略的 XACML 等标准来表达（并在运行时使用策略引擎实现进行评估）。例如，在您的情况下，政策看起来类似于

（基于属性）

如果 userId = manual.technical_content_manager，则允许“所有人”“编辑”“手册”

如果 userId = manual.stock_manager，则允许“每个人”“运送”“手册”

(RBAC)

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

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

(MAC)

如果 userId.level >= manual.level，则允许“所有人”“查看”“手册”

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

【讨论】：

【解决方案4】：

我知道这可能看起来有点笨拙，但你可以这样做：

Roles(role_id, etc)

Technical_Manual(manual_id, acceptable_roles, etc) 其中acceptable_roles 是一个分隔列表

然后在您的程序中，拆分分隔列表。我并不是说这是最好的方法，但它会起作用。虽然，我不知道它是否最适合军事应用:)

【讨论】：

+1 表示反对。 . .它会起作用，只是不是最好的实施方式。

【解决方案5】：

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

每个用户可能拥有或不拥有一些一般权限（即管理员），这些权限可以直接附加到角色。我们将使用您的表格来匹配特定用户对他们拥有高级权限的出版物，并为这些条目创建声明。

因此，当请求用户授权时，您会获得一组声明，一些来自角色的高级声明，以及一些来自您的表的发布特定声明。

【讨论】：

这基本上就是我们所做的。问题只是我们最终在三个地方获得了授权信息——系统级内容的角色表、“手动管理器”内容的 tech_manual 表和“手动阅读器”内容的订阅表。看起来很麻烦。

【解决方案6】：

评论混沌的回应：

在我看来，“系统级”角色可能适合相同的方案，如果这些事情的 manual_id 可以设置为 null 或某个神奇的值。是的，我知道，有些人对空值有强烈的反感，但它在这里有效。然后会有一个单一的“安全资料”表，而且都是干净的。

我确实在三个经理字段方面遇到了很多麻烦。我们有许多查询，例如“Bob 负责哪些书？”，这需要一个带有大 OR 的查询来针对所有三个字段。这意味着我们需要三个索引。后来我意识到我们最好把它分成一个单独的表。但是把授权的读者扔到同一张桌子上……很多事情都清理干净了。把系统级的东西也扔进去......我喜欢它。很容易问“玛丽·琼斯有什么权利？”以及“谁拥有 F-15 航空电子手册的权利？”、“我们所有的技术内容经理是谁？”等等

【讨论】：