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

第7节 RBAC的其他问题

这一节讨论 RBAC 产品中没有被 NIST RBAC 模型所涉及或者只是部分涉及的问题。RBAC是一个丰富而开放的技术。因此并不适合把所有方面都囊括在一个标准模型里。这节中的某些问题并不适合被标准化。而有些则目前还未达成足够共识去定制标准。

7.1 可扩展性

可扩展性应该是当今互联网快速增长对系统的一个重要的要求。某些产品能够满足 RBAC 第一级模型的要求，但对角色的数量却有很大限制，如16或32。有些产品则提供更大数量，如100个角色的支持。很明显，这是选购产品时的一个关键因素。

可扩展性的考虑是多维的。RBAC 中，包括对角色的数量，许可的数量，角色的层级，用户角色的关联，诸如此类都可能有扩展性的问题。一个产品可以有选择的制定自己的扩展性指标。

总的来说，我们可以采用如下的规模标准：

小规模：10-100
中规模：100-1000
大规模：1000以上

一个产品可能在支持小规模的角色数量，但对用户数量提供大型的支持。

7.2 认证

NIST RBAC 模型并没有提到认证的问题。用户应当如何认证以及如何与角色关联。某些情况下，这是影响产品易用性的重要因素之一。这已经是超出访问控制模型的范畴，应该是系统架构和机制的考虑内容。

7.3 反向许可

NIST 模型基于正向许可，即定义“谁能做什么”。但 NIST 模型并没有排除许可去定义“谁不能干什么”，我们称之为反向许可。厂商可以自由决定是否提供对反向许可的支持。但厂商或者用户注意到，反向许可可能会造成混乱，特别是在传统架构中。通常来说，用约束来实现相同效果可能更为明智。

7.4 许可的性质

NIST RBAC 模型并没有规定许可的性质。许可可以定义在很细的粒度（例如某个对象个体），也可以定义在很粗的粒度（如整个子系统）。许可也可以定义为很基本的操作，如读和写；但也可以定义为抽象的操作，如借和贷。许可更应该可以个性化的，如内科医生角色可以查看病历，但应该仅限查看该位医生所负责的病人的病历。许可的真正性质，应当是被产品的性质所决定。操作系统，数据库管理系统，工作流系统，网络管理系统各有不同种类的许可。这些许可的标准化，似乎已经超越了一个通用访问控制模型的讨论范围。

7.5 角色自主激活

NIST RBAC 模型没有明确允许用户可以在特定会话中指定要激活的角色。唯一要求是支持一个用户同时激活多个角色。这就排除了那些同时只支持激活一个角色的产品。有些现有产品无需用户选择，激活会话中的所有角色。有些则默认激活角色，然后让用户去自主决定删减。NIST RBAC 模型没有在这方面做一个要求。这可以由厂商根据自身需要决定，以此作为其产品特点。

7.6 角色工程

NIST RBAC 模型没有提供关于角色的设计，以及用户-角色，许可-角色关联关系设计的指引。这就称为角色工程。在大型系统中RBAC 的高效应用，很大程度得益于出色的角色工程。尽管如此，这个问题并不在 NIST RBAC 模型的讨论范围中。

7.7 约束

NIST RBAC 模型提出了职责分离(SOD)约束。支持 SOD 已作为第三级模型的要求。但具体形式并没有在 NIST RBAC 模型中规定。NIST 模型区分了静态和动态的 SOD。但是实际上还有其他很多类型的SOD。例如，以角色，许可，用户为中心的SOD已出现在最近的相关文档中。
SOD 是一个禁止类约束的例子，明确某些事情不能发生。RABC 也可以采用强制类约束，去要求某些事情必须发生。强制类约束这个概念可能过于新，而目前还未能采纳到标准模型中。

7.8 RBAC 管理

NIST RBAC 模型没有明确如何处理用户-角色关联，许可-角色关联和角色层次的授权问题。为了解决这个问题，多个模型已经在相关文献中出现。某些模型归根于传统的自主型访问控制，角色所有者可以处理该角色的所有权限。其他模型则将中心管理授权集中在一个安全管理员的角色上。一个基于管理角色的分散式管理模型最近被提出。但由于过多分歧，NIST RBAC 模型没有管理相关的内容。

7.9 角色变更

角色变更的具体做法并没有在 NIST RBAC 模型中规定。主要是发生角色变更时的生效时限问题。当去除用户上的一个角色，如何处理已激活该角色的会话呢？允许该用户完成会话，或者是去除的角色应当即时失效？这是一个很难处理的问题，特别在于分布式系统中，要确保某些动作及时执行是十分困难的。NIST RBAC 模型没有规定的角色变更的做法，但这是一个厂商和用户都需要关注的问题。