Question

这是一个没有实际意义的问题，因为我不再参与这个项目，但它仍然让我感到烦恼。我想知道是否有人对未来的参考和一般良好的编程实践有更好的想法。

教科书的安全方法是“基于角色的安全”。每个屏幕，报告或其他任务都附加到一个或多个角色;每个用户都被分配到一个或多个角色;然后每个用户都可以锻炼与他的角色相匹配的屏幕等等。正确？

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

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

除此之外，还有更多例行系统级权限：我们有几个系统管理员有权更新systeem中的任何内容，帮助台人员几乎可以查看任何数据但不会更新等等。

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

人（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表和用户表。但是......我们能做得更干净吗？有更好的想法吗？

Answer 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)

此外，在我的系统中，角色大多只是默认权限包，并且可以使特定操作（读取，编辑，移动，删除等）的用户权限与其角色的基线相比有所不同。< / p>

Answer 2

将所有内容强制适应“角色”模式的问题是物流/数量/工作量，以便在这些规则非常“细粒度”的情况下保持完整的安全规则集。

通过细粒度，我的意思是在任何authorazation决定中存在许多潜在的歧视因素，并且对于每个区别因素（例如，“客户申请的信用额”），可能存在大范围的“价值”（例如，有25个不同的信贷额度适用范围）。

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

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

Answer 3

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

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

这些模型可以使用XACML等标准表示（并在运行时使用策略引擎实现进行评估），这些标准可以描述策略。例如，在您的情况下，该政策将沿着

（基于属性）

如果userId = manual.technical_content_manager
，请允许“所有人”“编辑”“手动”
如果userId = manual.stock_manager
允许“所有人”“运送”“手动”

（RBAC）

允许“HelpDesk”“查看”“手册信息”，“手动”

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

（MAC）

如果userId.level＆gt; = manual.level
，请允许“所有人”“查看”“手动”

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

Answer 4

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

Roles(role_id, etc)

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

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

Answer 5

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

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

因此，当请求用户的授权时，您将获得一系列声明，一些源自角色的高级声明，以及一些源自表格的特定于发布的声明。

Answer 6

评论混沌的回应：

如果对于这样的事情的manual_id可以设置为null或某个魔术值，那么“系统级别”角色可以适合相同的方案。是的，我知道，有些人对空值有强烈厌恶，但它在这里有效。然后会有一个“安全的东西”表，而且一切都很干净。

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

非基于角色的安全性？

6 个答案: