RBAC 角色与业务功能

Question

我敢肯定这个问题以前被问过很多次了。我已经在互联网上搜索了很多天，但每次我都越来越困惑。我已经阅读了 359-2012 标准和书籍，但仍然如此。

RBAC 的真正作用是什么？我看到很多混淆，人们倾向于将用户可能拥有的业务角色命名为角色，例如安全分析师或人力资源助理。据我了解，这不是角色。角色是在系统中有意义的东西。例如，我是一名 InfoSec 分析师，这是我的业务角色。对于 RBAC，我的角色将分配给每个系统案例。 IE。在数据库中，我可能扮演 Database_Admin 的角色，在另一个系统中，我可能扮演 System_User 的角色，在 CRM 中，我可能扮演 CRM_PowerUser 的角色，以访问 [=27] 上的文件=]服务器我可能担任FTP_ReadOnly的角色。因此，我有多个 system/application/resource 特定的角色。

在业务方面我们可以说我是一名InfoSec Analyst，是一名安全部门的员工，也是一名普通员工。每一个 "inherits" 它之前的那个。这些业务角色中的每一个都可以访问 systems/applications/resources。

总而言之，我有 InfoSec Analyst -> Security employee -> general employee 的业务功能，这些业务功能中的每一个都允许我访问特定角色（如上所述）。

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

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是分开的，他们都是从hierarchy ladder上分开的。这是有道理的：

- 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.

以此类推

整个系统可能会变得复杂，但它可以相当准确地模拟大多数公司的需求。对于小公司来说，这可能远远超过要求。

这基本上就是我的interpretation/implementation RBAC。它仅支持附加权限，例如继承总是添加权限，但不会删除任何权限。

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

另见

RBAC 角色与业务功能

RBAC Roles vs Business functions

roles

rbac