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

[b]第3节 Flat RBAC[/b]

Flat RBAC如图1所示。Flat RBAC所要求的特性对于任何一个RBAC实现来说是必不可少，并且显而易见的。对于Flat RBAC来说，讨论的重点仿佛应当是那些被排除在外的特性了。

Flat RBAC 主要从传统操作系统中广泛使用的基于组的访问控制中，以新一个角度提取了相关特性。有的人可能觉得这些特性不足以诠释RBAC这个概念。NIST RBAC模型之所以以传统的基于组的访问控制

作为第一个级别的RBAC，是因为其广泛使用而且非常相似。这种做法充分认识到两者的共同点，而将关于角色与组区别的无意义讨论放一边。同时，通过定义更复杂的RBAC高级别模型，也说明了RBAC并不止是传统基于组的访问控制的另一个代名词。

对于Flat RBAC来说，多对多的用户角色关联支持是很重要的。现实中每个系统对一个用户所关联的角色个数都有一定限制。同时产品应当在这方面的扩展性有一定考量。目前某些系统对用户关联的角色数量有很严格的限制，如16或32。而其他系统则可能提供大得多的支持，如100甚至1000。NIST模型没有对这方面有一个量化的要求。而对于一个可操作的模型来说，这方面的量化要求可能是很必须的。RBAC模型中还是有很多相似扩展性的的方面会涉及到。这点在第7节会进一步讨论。

用户通过角色来获取许可，这是RBAC中很重要的一点。但Flat RBAC不排除用户通过其他方式来获取许可，如许可直接关联到用户，或通过其他安全标签的形式。

图1中显示了三种实体：用户(U)，角色(R)，和许可(P)。这个模型中，一个用户可能是一个人，或者是一个匿名的代理，如一个进程或计算机。一个角色则是组织内的一个工作职能或者职位名称，这些从字眼上可能与相关授权和责任有关联。一个许可代表允许对系统内一个或多个对象的某种形式访问。授权，访问权限，特权这些词语经常用于描述许可。许可通常是正向的，描述许可所有者可以在系统内进行某些操作。许可的性质很大程度上取决于系统的性质和实现细节。因此，一个通用的访问控制模型应当将许可某种程度上看作是一个不可解析的符号。Flat RBAC对许可的具体性质没有明确规定，留待读者去确定。

Flat RBAC有两种多对多的关联：用户-角色关联(UA)和许可-角色关联(PA)。这是RBAC的一个很重要方面。会话的概念并不是RBAC的一部分。一个会话应该是对应用户登录系统进行某些操作的一个特定场景。对于会话的含义，每个系统都有很大区别。某些情况下，一个用户关联的所有角色会全被激活并在会话内生效。而其他情况，用户可能有选择的激活会话内生效的角色。这杨，用户就可以根据当前执行的任务去更灵活的控制权限。对于那些具有很高权限的角色，一开始可以进行屏蔽，直到有需要时才激活，以保证安全性。某些系统限制用户一个会话只能激活一个角色。NIST模型没有要求支持所有的角色激活方式，但要求支持在同一会话中能同时激活多个角色。这就排除了那些一个会话只能激活一个激活角色的产品。这个个性被某些人认为是过于严苛。

Flat RBAC要求支持用户-角色关系的查询，以方便确定一个用户具有哪些角色，以及一个角色拥有哪些用户。通常认为，许可-角色关系的类似查询也是RBAC中固有的一部分。许可-角色关系查询能有助于确定一个角色有哪些许可，以及一个许可分配了给哪些角色。一些人可能提出，对许可-角色关系查询的支持是角色区别于组的一个重要特征。在NIST模型中，由于许可-角色关系的查询在大型分布式系统中的实现有一定难度，所以只在第4级模型中进行要求。

Flat RBAC模型将RBAC很多实现中需要明确的问题留待读者去确定和解决。角色，用户，许可等的支持规模上，都没有作数目上的明确要求。许可的性质和角色激活方式的支持上已只做了部分的规定。当一个用户失去一个角色或者一个许可从一个角色撤回，就要进行权限回收。但具体回收动作什么时候发生，特别是对于正在进行的活动有何影响，这都没有明确规定。从某种程度上，这是一个效果保证问题。角色管理也是另外一个没有明确的方面。角色管理涉及到谁去为用户添加角色，为角色授权许可。Flat RBAC中对此不做规定有两方面原因：一方面，在一个标准模型中去规定某些特性的实现细节并不合适。应当由厂商或者市场去决定如何实现，以获得最好的效果。另一方面，在团体内很难达成一致意见去决定一个具体的方案作为标准的一部分。这些问题在第7节将会作进一步的讨论。