组与角色(任何真正的区别？)

Question

任何人都可以告诉我,小组和角色之间的真正区别是什么？我一直试图弄清楚这一段时间,而且我阅读的信息越多,我就越觉得这只是为了让人迷惑而且没有真正的区别.两者都能做到对方的工作.我总是使用一个组来管理用户及其访问权限.

最近,我遇到了一个管理软件,其中有一堆用户.每个用户都可以分配一个模块(整个系统分为几个部分,称为模块,即管理模块,调查模块,订单模块,客户模块).最重要的是,每个模块都有一个功能列表,每个用户都可以允许或拒绝这些功能.因此,假设用户John Smith可以访问模块订单并可以编辑任何订单,但是没有权利删除任何订单.

如果有更多用户具有相同的能力,我会使用一个组来管理它.我会将这些用户聚合到同一个组中,并将模块及其功能的访问权限分配给该组.同一组中的所有用户都具有相同的访问权限.

为什么称它为一个群体而不是角色？我不知道,我只是觉得那样.在我看来,这根本不重要:]但我仍然想知道真正的区别.

任何建议为什么这应该被称为角色而不是组或反过来？

Answer 1

谷歌是你的朋友:)

无论如何,角色和群体之间的鸿沟来自计算机安全的概念(而不仅仅是资源管理).Ravi Sandhu教授对角色和群体之间的语义差异进行了开创性的报道.

http://profsandhu.com/workshop/role-group.pdf

组是具有分配给组(并且可传递给用户)的给定权限集的用户的集合.角色是权限集合,用户在该角色下执行操作时会有效地继承这些权限.

通常,您的群组成员资格会在您登录期间保留.另一方面,可以根据具体条件激活角色.如果您当前的角色是"医务人员",您可能会看到某位患者的某些医疗记录.但是,如果您的角色也是"医生",您可能会看到除了"医务人员"角色的人所能看到的其他医疗信息.

角色可以按时间,访问位置激活.角色也可以增强/与属性相关联.您可能是"医生",但如果您没有"主要医生"属性或与我(具有"患者"角色的用户)的关系,那么您无法查看我的整个病史.

你可以用群组完成所有这些,但同样,群体往往关注身份,而不是角色或活动.刚才描述的安全方面的类型往往更好地与后者相比更好.

对于许多情况,对于将事物一起分类的使用(仅此而已),组和角色的功能相同.但是,组基于身份,而角色则用于划分活动.不幸的是,操作系统往往模糊了区别,将角色视为组.

您可以看到与应用程序或系统级角色更明确的区别 - 承载应用程序或系统特定的语义(如Oracle角色) - 而不是在操作系统级别实现的"角色"(通常是组的同义词).

角色和基于角色的访问控制模型可能存在限制(当然,与任何事情一样):

http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx

大约十年前,我看到了一些基于属性和基于关系的访问控制的研究,它提供了比基于角色的访问控制更好的粒度.不幸的是,多年来我没有看到很多关于这个领域的活动.

角色和组之间最重要的区别是角色通常实现强制访问控制(MAC)机制.您无法将自己(或其他人)分配给角色.角色管理员或角色工程师会这样做.

这表面上类似于UNIX组,用户可以/可能将自己分配给一个组(当然是通过sudo.)当根据安全工程过程分配组时,区别会稍微模糊.

另一个重要特征是真正的RBAC模型可以提供互斥角色的概念.相反,基于身份的群体是相加的 - 委托人的身份是群体的总和(或连接).

基于真实RBAC的安全模型的另一个特征是,为特定角色创建的元素通常不能由不在该角色下行动的人传递访问.

另一方面,在自主访问控制(DAC)模型(Unix中的默认模型)下,您无法单独使用组来获得该类型的保证.顺便说一句,这不是群组或Unix的限制,而是基于身份的DAC模型的限制(并且传递上,基于身份的群组.)

希望能帮助到你.

=======================

在看到Simon的良好反应之后再添加一些.角色可帮助您管理权限.组可帮助您管理对象和主题.此外,人们可以将角色视为"背景".角色"X"可以描述规则主体Y如何访问(或不访问)对象Z的安全上下文.

另一个重要的区别(或理想)是有一个角色工程师,一个在应用程序,系统或操作系统中设计角色,上下文,必要和/或明显的人.角色工程师通常(但不一定)也是角色管理员(或系统管理员).此外,角色工程师的真正角色(没有双关语)属于安全工程领域,而不是管理领域.

这是一个由RBAC形式化的新小组(即使它很少被使用),这个小组通常不具有支持组的系统.

Answer 2

组是组织用户的一种手段,而角色通常是组织权利的一种手段.

这在许多方面都很有用.例如,可以将分组到角色中的一组权限分配给一组组,或者一组独立于其组的用户.

例如,CMS可能具有一些权限,如阅读帖子,创建帖子,编辑帖子.编辑器角色可能能够读取和编辑,但不能创建(不知道为什么!).帖子可能能够创建和阅读等.一组管理员可能具有编辑角色,而不在管理员组中的IT用户也可能具有编辑角色,即使他或她的其余部分也是如此小组没有.

因此,在简单的系统中,组和角色通常是紧密对齐的,但情况并非总是如此.

Answer 3

尽管角色和组之间存在语义差异(如上文其他答案所述),但技术上角色和组似乎是相同的.没有什么可以阻止您直接向用户和组分配权限(这可以被视为微调访问控制).同样地,当为用户分配角色时,可以将其视为角色成员,在用户成为组成员的情况下也是如此.

因此,我们最终可能没有角色和群组之间的真正区别.两者都可以考虑对用户和/或权限进行分组.因此差异只是语义: - 如果它在语义上用于分组权限,那么它就是一个角色; - 如果它在语义上用于对用户进行分组,那么它就是一个组.从技术上讲,没有区别.

Answer 4

"组"是用户的集合."角色"是权限的集合.这意味着当组alpha包含组beta时,alpha会从beta获得所有用户,而beta会从alpha获得所有权限.相反,你可以说角色beta包括角色alpha,同样的结论也适用.

一个具体的例子使事情更清楚.考虑"客户支持"和"高级客户支持".如果您将这些集合视为组,那么很明显,客户支持用户"包括"高级客户支持用户.但是,如果将它们视为角色,则很明显高级客户支持权限"包括"客户支持权限.

从理论上讲,您可以只使用一种集合类型.但是,如果你说"集合alpha包括集合测试版",那将是模棱两可的.在这种情况下,您无法判断alpha中的用户是否处于测试阶段(如角色),或者测试版中的用户是否处于alpha状态(如组).为了使术语像"包含"和视觉元素(如树视图)明确无误,大多数rbac系统要求您至少为了讨论而指定有争议的集合是"组"还是"角色".

一些类比可能有所帮助.根据集合论的框架,当组alpha是组beta的子集时,权限alpha是权限beta的超集.与家谱相比,如果群体就像一棵后代树,那么角色就像一棵祖先的树.

Answer 5

注意 - 只有当一个人试图在组织内实施安全时，以下杂乱无章才有意义 - 也就是说，试图限制对信息的访问......

群体是经验性的——它们回答“什么”的问题。它们是“是”，因为它们反映了现有的访问现实。IT 人员喜欢群体——他们非常字面化且易于定义。最终，所有访问控制最终都会转向（正如我们在中学时学到的那样……）来回答“您属于哪个群体？”的问题。

然而，角色更加规范——它们指导“应该是什么”。优秀的管理者和人力资源部门喜欢“角色”——他们不会回答——他们会问“为什么？” 不幸的是，角色也可能是模糊的，这种“模糊性”会让（IT）人员发疯。

以上面的医学为例，如果“初级保健医生”的角色比“X 射线技术人员”的角色拥有更多的权利（即接触更多群体） ，这是因为人们（经理和 HR）决定了为什么需要发生。从这个意义上说，它们是一个组织的“集体智慧”。

假设医生有权访问患者的财务记录（有权访问的团体的成员资格）。这通常不属于医生的“角色”，应该进行辩论。因此，任何人（无论多么有资格）都不应完全接触所有群体——这会导致滥用权力。这就是为什么“角色工程”如此重要 - 没有它，您就只能像糖果一样获得组访问权限。人们会收集（有时是聚集）团体访问权，而不会讨论权力过多的危险。

总而言之，明确角色的智慧有助于减轻失控的群体访问的危险。组织中的任何人都可以争取进入特定群体的权利。但一旦提供了这种访问权限，就很少会放弃。角色工程（以及良好定义的组描述和授权的组访问管理员等最佳实践）可以限制组织内的利益冲突，分散决策并帮助使安全管理更加合理。