NIST RBAC 模型 —— 向统一标准化的努力（5）

[b]第5节 Constrained RBAC[/b]

Constrained RBAC 是在hierarchical RBAC模型的基础上添加了约束，如图6和7所示。这些约束可能是作用在用户-角色的关联关系中（图6，静态约束），也可能是在用户会话的角色激活中（图7，动态约束）。组织可能采用某些策略去避免用户获得超越自己职位所应获得的合理授权，对分离功能的需求正是为了是这些策略落到实处。

职责分离(Separation of duty)将任务和关联的权力分散到不同角色中，以避免单个用户获得过多的权力。这样，除非多个用户相互勾结，否则欺诈和其他错误无法发生，在RBAC系统里，分离的概念体现在了最小权力原则里。

最小权力(Least privilege)是指管理者在分配权限时，只分配给用户他们执行工作所必需的权限。这个原则避免了个人除了完成自己的工作之外，还可以进行非必要而且可能有害的活动。许可（或特权）其实是授予个人用户在一定范围内活动的权力，但不能超出该范围。RBAC保护机制提供的分离边界支持，而最小权力为分离边界的设置提供了一个很好的指引。

NIST 模型允许静态或动态的职责分离，但没有明确哪种必须支持和如何支持。

[b]5.1 Static Seperation of Duty[/b]

在基于角色的系统中，冲突可能由于用户获得原本属于对立角色的许可而产生。一种解决方式就是通过静态的职责分离(SSD)，即在为用户添加角色的时候进行约束。当一个用户拥有了一个角色，那么他将不能在拥有另外一个角色。例如，一个用户被分配 Billing Clerk(会计)角色，那么他可能就不能再被分配 Accounts Receivable(AR) Clerk(出纳)角色，如图8所示。因为角色会计和出纳是互斥的。实际应用中，可以将SSD定为一个基本策略，然后在具体的角色中实施。

约束可以在角色层级中传递。例如，如果 Accounts Receivable Supervisor(出纳主管) 继承 Accounts Receivable Clerk(出纳)，而“出纳”和“会计”有着 SSD 关系，那么“出纳主管”和“会计”也有着 SSD 关系。从另一个角度理解，一个“出纳主管”同样是一个“出纳”，因此“会计”和“出纳”的 SSD 约束同样也对“出纳主管”有效。

由于继承与被继承角色的特殊关系（前者包含后者的利益），他们之间不可能有 SSD 关系。在前一个例子里，“出纳主管”和“出纳”之间是无法建立 SSD 关系，因为他们之间没有利益冲突。因此，包含关系所传递的隐性特性不能与外部的显性特性相冲突。

[b]5.2 Dynamic Seperation of Duty[/b]

RBAC 为管理员提供了动态的职责分离(DSD)以支持组织的相关策略。SSD 可以在为用户分配角色时，明确组织内不同角色之间的潜在利益冲突。而 DSD 允许用户被分配多个单独行使并不冲突的角色，但同时使用形管角色将会受到一定策略的约束。例如，一个用户被分配了“收款员”和“收款主管”的角色，“收款主管”可以确认一个“收款员”的收款箱内金额的变更。如果一个“收款员”角色的用户尝试转换到“收款主管”的角色，RBAC会要求他先放弃“收款员”的角色，强迫关闭收款箱，之后他的“收款主管”的角色才生效。只要同一个用户不能同时使用两个角色，那么利益冲突的情况就不会出现。尽管相同效果也可以通过 SSD 达到，但 DSD 显然提供了操作上更好的灵活性。

读者可能会注意到，与 SSD 关系中的角色不同，DSD 关系中的角色可以有上下级的关联。这得益于 DSD 对角色的同时激活有着相关限制，并且角色层级被看为用户的显性或隐性的角色授权。从而，授权和激活可以分开单独处理和看待。

职责分离的某些方面其实可以用 Flat RBAC 或者简单的基于组的机制来实现。NIST 模型把角色层级的支持作为职责分离的系统的先决条件，因为 RBAC 大部分特性都与层级支持密不可分。职责分离的实现如果缺少层级的支持，将会在灵活性和功能性方面受到很大限制。

很多研究人员都对 RBAC 的职责分离作了很多的研究。这里讨论的内容大部分来源于 Ferraiolo etal 的研究。