Question

我确信此问题之前已被问过很多次。我一直在网上搜索很多天，但每次我都越来越困惑。我已经阅读了359-2012标准和书籍，但仍然如此。

RBAC的真正作用是什么？我已经看到很多混淆，人们倾向于将角色命名为用户可能具有的角色，例如角色。安全分析师或人力资源助理。据我所知，这不是角色。这个角色在系统中是有意义的。例如，我是InfoSec分析师，这是我的业务角色。对于RBAC，我的角色将在每个系统案例中分配。即在数据库中我可能具有Database_Admin的角色，在另一个系统中我可能具有System_User的角色，在CRM中我可能是CRM_PowerUser，用于访问FTP服务器上的文件我可能拥有FTP_ReadOnly的角色。所以，我有多个角色，即系统/应用程序/资源特定的。

在业务方面，我们可以说我是InfoSec分析师，这是一名安全部门员工，也是一名普通员工。每一个“继承”前面的那个。这些业务角色中的每一个都可以访问系统/应用程序/资源。

总结一下，我有InfoSec Analyst的业务功能 - ＆gt;安全员工 - ＆gt;一般员工和这些业务职能中的每一个都允许我访问特定角色（如上所述）。

这有意义吗？我理解错了吗？

Answer 1

当我实施RBAC系统时，可以为每个用户分配多个角色。

这很好，因为......

Subject-Roles:

Peter +---- Company3000-Employee
      |
      +---- London-Department
      |
      +---- CoreSystem-Backend-Developer

这样，您就不必为每个用户挑选每一个权限。

然后，角色可以继承多个角色。这很好，因为......

Role-Roles:

London-Department +---- London-Visitor
                  |
                  +---- London-Permament +---- London-Temporary

这样，您就可以对相关的权限组进行分组。在这里，London-Permament得出所有来自London-Temporary的权利（例如，使用主入口退出和进入，即访客应该只能退出，但不能单独进入。

最后，你有角色权限：

Role-Permissions:

London-Visitor +---- [permitted to exit building]

London-Permanent +-- [permitted to use parking deck]
                 |
                 +-- Longon-Temporary -- [permitted to enter building]

这是一个品味和要求的问题，你想要多深入它。例如，您也可以对其进行建模，以便London-Temporary来自London-Visitor（尽管这会阻止限制暂时撤销对访问者的访问权限，例如在化工厂中，只允许访问者进入）。

在此示例中，Job与Location分开，它们都与层次结构梯形图分开。这是有道理的：

- Peter should have access to his documents in his cloud-storage, never mind _where_ he is physically.
- Peter should not be able to just enter a Company3000 office in Germany without being handed a pass.

等等。

整个系统可能变得复杂，但它可以准确地模拟大多数公司的要求。对于小公司来说，它可能超出了要求。

这基本上是我对RBAC的解释/实施。它仅支持附加权利，例如继承总是添加权限，但不会删除任何。

它也不包括受约束的RBAC，即职责分离;例如原子战按钮，需要两个人的钥匙。

另见

RBAC角色与业务功能

1 个答案: