小组与角色(有什么真正的区别吗?)

群体是组织用户的一种手段，而角色通常是组织权利的一种手段。

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

例如，CMS 可能具有读文章、创建文章、编辑文章等权限。一个编辑角色可能能够阅读和编辑，但不能创建(不知道为什么!).一篇文章也许可以创建和阅读等等。一组管理人员可能具有编辑角色，而 IT 中不属于管理人员组的用户也可能具有编辑角色，尽管他或她的组的其余成员不具有编辑角色。

因此，尽管在一个简单的系统中，组和角色通常是紧密一致的，但情况并非总是如此。

角色和组之间的区别来自计算机安全的概念(而不是简单的资源管理)。Ravi Sandhu 教授为角色和群体之间的语义差异提供了一个开创性的覆盖面。

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

组是具有分配给组(以及传递给用户)的给定权限集的用户的集合。角色是权限的集合，当用户在该角色下行事时，将有效地继承这些权限。

通常，您的组成员资格在登录期间保持不变。另一方面，可以根据特定条件激活角色。如果你目前的角色是“医务人员”，你可能会看到一些病人的医疗记录。然而，如果你的角色也是“医生”，你可能会看到更多的医疗信息，而不仅仅是一个“医务人员”的角色。

角色可以根据一天中的时间、访问位置来激活。角色还可以增强/与属性关联。你可能以“医生”的身份操作，但是如果你没有“主治医生”的属性或者与我的关系(一个扮演“病人”角色的用户) ，那么你就不能看到我的全部病史。

你可以在团队中做到这些，但是团队倾向于关注身份，而不是角色或者活动。而且刚才描述的安全方面的类型往往与后者比与前者更好地保持一致。

在许多情况下，对于将事物分类在一起的用法(仅此而已) ，组和角色的功能是一样的。然而，团队是基于身份的，而角色是用来划分活动的。不幸的是，操作系统倾向于模糊区分，将角色作为组来对待。

您可以更清楚地看到与应用程序或系统级角色(承载应用程序或系统特定语义(如 神使的角色))的区别，而不是在操作系统级别实现的“角色”(这通常是组的同义词)

角色和以角色为基础的存取控制模型可能存在局限性(当然任何事情都是如此) :

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

大约十年前，我看到一些关于基于属性和基于关系的访问控制的研究，它们提供了比以角色为基础的存取控制更好的粒度。不幸的是，我已经很多年没在那个领域看到什么活动了。

角色和组之间最重要的区别在于，角色通常实现一种强制访问控制(MAC)机制。您不能为自己(或他人)分配角色。角色管理员或角色工程师可以做到这一点。

这在表面上类似于 UNIX 组，其中用户可以/可能能够将自己分配给一个组(当然是通过 sudo)但是，当根据安全工程过程分配组时，区别就有点模糊了。

另一个重要特征是，真正的 RBAC 模型可以提供互斥角色的概念。相比之下，基于身份的群体是可加的——主体的身份是群体的和(或连接)。

基于真实 RBAC 的安全模型的另一个特征是，为特定角色创建的元素通常不能由不在该角色下行事的人过渡访问。

另一方面，在自主访问控制(dAC)模型(Unix 中的默认模型)下，单独使用组是无法获得这种类型的保证的。顺便说一句，这不是对组或 Unix 的限制，而是对基于身份的 DAC 模型(以及基于身份的组)的限制

希望能有帮助。

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

看到西蒙精彩的回答后，又添加了一些内容。角色帮助您管理权限。组帮助您管理对象和主题。此外，人们可以将角色视为“背景”。角色“ X”可以描述一个安全上下文，该上下文规定主题 Y 如何访问(或不访问)对象 Z。

另一个重要的区别(或理想的)是，有一个角色工程师，一个人工程师的角色，上下文，是必要的和/或明显的，在应用程序，系统或操作系统。角色工程师通常是(但不一定是)角色管理员(或系统管理员)。此外，角色工程师的真正角色(无意双关)是在安全工程领域，而不是在管理领域。

这是一个由 RBAC 形式化的新群组(即使它很少被使用) ，一个通常没有群组能力系统的群组。

尽管角色和组之间存在语义上的差异(正如上面其他答案所描述的) ，但从技术上来说，角色和组似乎是相同的。 没有什么可以阻止您将权限直接分配给用户和组(这可以被认为是一种微调访问控制)。 等效地，当用户被分配一个角色时，它可以被认为是一个角色成员，在同样的意义上，当用户成为一个组的成员。

因此，我们可以最终没有真正的差异之间的角色和组。对用户与或权限进行分组时可以同时考虑这两种权限。 因此，差异只是语义上的: ーー如果它在语义上用于对权限进行分组，那么它就是“角色”; ーー如果它在语义上用于对用户进行分组，那么它就是一个 Group。 严格来说，没有区别。

根据用户在任何系统中扮演的角色，用户被分配到不同的角色。例如，身为 Sales Manager 角色的用户可以执行某些操作，例如为产品提供附加折扣。

组用于对系统中的用户或角色进行“分组”，以便于安全管理。例如，一个名为“ Leadership Group”的组可以有来自管理者、董事和架构师以及不属于这些角色的个人用户的成员。现在您应该能够为这个组分配某些特权了。

团队和角色的目的在应用程序中有所不同，但我主要理解如下, 组(用户的集合)是静态的，而角色(权限的集合)是动态的策略，例如基于从9到6的时间，一个组或用户可能有这个角色，但不是那个。

注意-下面的胡言乱语只有当一个人试图在一个组织内部强加安全性时才有意义-也就是说，试图限制对信息的访问..。

群体是经验主义者——他们回答“什么”的问题。他们是“是”的意义上，他们反映了存在的现实访问。IT 人喜欢群体——他们非常直白，容易定义。最终，所有的访问控制权最终都会移交给回答“你属于哪个群体?”

然而，角色更具规范性——它们指导着“应该是什么”。好的管理者和 HR 喜欢“角色”——他们不会回答——他们会回答“为什么”这个问题不幸的是，角色也可能是模糊的，而“模糊性”可能会使(IT)人员发疯。

使用上面的医学例子，如果“初级保健医师”的 角色比“ X 光技师”的 角色有更多的权利(即访问更多的团体) ，这是因为人们(经理和 HR)决定了需要发生的 为什么。从这个意义上说，它们是一个组织的“集体智慧”。

让我们假设一个医生可以访问病人的财务记录(可以访问的组织的成员)。这通常在医生的“角色”之外，应该值得讨论。因此，任何人(无论多么有资格)都不应该完全接触所有群体——这会招致权力滥用。这就是为什么“角色工程”如此重要的原因——没有它，你只能像分发糖果一样分发团队访问权限。人们会收集(有时是部落)群体访问权限，而不会讨论权限过大的危险。

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

可以将角色分配给组。您可以将用户分配给组，也可以将角色分配给任何角色用户中的单个用户。意思是。Jean Doe 可以在销售部门的组中担任 ReportWriter 的角色，ReportWritter 允许从 SharePoint 打印我们的报告，但在销售部门的组中，其他人可能没有 ReportWritter 的角色。- 换句话说，角色是分配给组的特殊特权。希望这会引起骚动。

干杯! ! ！

以前的答案都很精彩。如前所述，团队与角色的概念更多的是概念性的，而不是技术性的。我们采取的立场是，Group 用于包含用户(一个用户可以在多个组中: 例如，Joe 既是 Manager 组中的用户，也是 IT 组中的用户(他是 IT 部门的经理)) ，还用于分配广泛的特权(例如,。我们的磁卡系统允许 IT 组的所有用户进入服务器机房)。角色现在用于向特定用户添加特权(即 IT 组中的人可以 RDP 到服务器，但不能分配用户或更改权限，IT 组中具有 Admin 角色的人可以分配用户和更改权限)。角色也可以由其他角色组成(Joe 有 Admin 角色来添加用户/特权，还有 DBA 角色来对服务器上的 DBMS 进行数据库更改)。角色也可以非常具体，因为我们可以创建对用户非常具体的单个用户角色(即 JoesRole)。因此，回顾一下，我们使用组来管理用户，并分配一般的角色和角色来管理特权。这也是累积的。用户所在的组可能分配了角色(或可用角色列表) ，这些角色将给予非常一般的特权(即。IT 组用户具有 ServerRDP 角色，该角色允许他们登录到服务器上) ，因此将这个角色分配给用户。然后，用户所属的任何角色都将按照它们被定义的顺序添加，最后一个角色拥有最终决定权(角色可以允许、拒绝或不应用特权，这样在应用每个角色时，它要么覆盖以前的特权设置，要么不改变它)。一旦应用了所有组级别角色和用户级别角色，就为用户创建了一个独特的安全模型，可以在整个系统中使用该模型来确定访问权限和功能。

“组”是用户的集合。“角色”是权限的集合。这意味着 当 α 组包括 β 组时、 alpha 接收来自 beta 的所有用户，beta 接收来自 alpha 的所有权限。相反，你可以说 角色 beta 包括角色 alpha和同样的结论将适用。

具体的例子让事情变得更清楚。考虑“客户支持”和“高级客户支持”。如果将这些集合视为组，那么很明显，客户支持用户“包括”高级客户支持用户。但是，如果您将它们视为角色，那么很明显，高级客户支持权限“包括”客户支持权限。

理论上，您可以只使用一种集合类型。然而，如果你说“集合 alpha 包括集合 beta”，那就含糊不清了。在这种情况下，您无法判断处于 alpha 测试阶段的用户是否处于 beta 测试阶段(比如某个角色) ，或者处于 beta 测试阶段的用户是否处于 alpha 测试阶段(比如某个群体)。为了使术语如“包含”和可视化元素如树视图明确无误，大多数 rbac 系统要求您指定有问题的集合是“组”还是“角色”，至少为了讨论起见。

一些 类比可能会有帮助。按照 集合论的框架，当组 alpha 是组 beta 的子集时，则权限 alpha 是权限 beta 的超集。与 家谱相比，如果群体像一棵子代树，那么角色就像一棵祖先树。

这对我们有用:

• 通过组管理用户策略(偶尔手动向单个用户添加其他策略)
• 通过角色管理服务策略(例如，微服务可能需要访问 S3，并且将通过角色授予权限)