小组与角色（有什么真正的区别吗？）

谁能告诉我，团队和角色之间的真正区别是什么？我一直在努力弄清楚这一点，阅读的信息越多，我越能感觉到这是为了使人们感到困惑而产生的，并且没有真正的区别。两者都能胜任对方的工作。我一直使用一个小组来管理用户及其访问权限。

最近，我遇到了一个管理软件，其中有很多用户。每个用户可以分配一个模块（整个系统分为几个部分，称为模块，即管理模块，调查模块，订单模块，客户模块）。最重要的是，每个模块都有一个功能列表，可以为每个用户允许或拒绝。假设用户约翰·史密斯（John Smith）可以访问订单模块并可以编辑任何订单，但没有授予删除任何订单的权利。

如果有更多具有相同能力的用户，我将使用一个小组来进行管理。我会将这些用户聚合到同一组中，然后将对模块及其功能的访问权限分配给该组。同一组中的所有用户将具有相同的访问权限。

为什么称其为团体而不是角色？我不知道，我就是这样。在我看来，这根本不重要：]但是我仍然想知道真正的区别。

有什么建议为什么应该将此称为角色而不是组或相反？

Google是您的朋友：)

无论如何，角色和组之间的区分来自于计算机安全性的概念（与简单的资源管理相对）。Ravi Sandhu教授对角色和群体之间的语义差异进行了开创性的报道。

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

组是具有给定权限集的用户的集合，该组权限分配给该组（以及可传递地分配给用户）。角色是权限的集合，并且用户在该角色下操作时可以有效地继承这些权限。

通常，您的组成员身份将在您登录期间保持不变。另一方面，可以根据特定条件激活角色。如果您当前的角色是“医疗人员”，则可以查看给定患者的一些病历。但是，如果您的角色也是“医师”，则您可能会看到仅具有“医疗人员”角色的人所能看到的其他医疗信息。

可以通过一天中的时间，访问位置来激活角色。角色也可以增强/与属性相关联。您可能以“医师”的身份工作，但是如果您没有与我的“主要医师”属性或与我的关系（具有“患者”角色的用户），那么您将看不到我的全部病史。

您可以使用小组来完成所有这些工作，但是小组再次倾向于集中于身份，而不是角色或活动。刚刚描述的安全方面的类型倾向于使后者与前者更好地保持一致。

在许多情况下，为了将事物分类在一起（仅此而已），组和角色的功能是相同的。但是，组是基于身份的，而角色是用于划分活动的。不幸的是，操作系统倾向于模糊区分，将角色视为组。

您将看到应用程序或系统级别角色的区别更加清晰-承载应用程序或系统特定的语义（例如在Oracle角色中）-与在OS级别实现的“角色”（通常是组的同义词）相对。

角色和基于角色的访问控制模型可能会受到限制（当然与其他任何东西一样）：

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

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

角色和组之间最重要的区别是角色通常实现强制性访问控制（MAC）机制。您无法将自己（或其他人）分配给角色。角色管理员或角色工程师可以做到这一点。

这从表面上类似于UNIX组，在该组中，用户可以（也许通过sudo）将自己分配给组（当然，也可以通过sudo）。但是，根据安全工程流程分配组时，区别有点模糊。

另一个重要的特征是，真正的RBAC模型可以提供互斥角色的概念。相反，基于身份的组是加性的-主体的身份是组的总和（或合集）。

基于True-RBAC的安全模型的另一个特征是，为特定角色创建的元素通常不能由不担任该角色的人员来传递访问。

另一方面，在自由访问控制（DAC）模型（Unix中的默认模型）下，您不能仅凭组获得这种类型的保证。顺便说一句，这不是组或Unix的限制，而是基于身份（以及可传递的，基于身份的组）的DAC模型的限制。

希望能帮助到你。

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

在看到Simon的好评后，再添加一些内容。角色可帮助您管理权限。组可以帮助您管理对象和主题。此外，人们可以将角色视为“上下文”。角色“ X”可以描述一个安全上下文，该上下文确定主体Y如何访问（或不访问）对象Z。

另一个重要的区别（或理想情况）是，有一个角色工程师，一个工程师在应用程序，系统或OS中必需和/或显而易见的角色，上下文。角色工程师通常也是（但不一定是）角色管理员（或sysadmin）。此外，角色工程师的真正角色（无双关语）是在安全工程领域，而不是管理领域。

这是由RBAC正式化的一个新颖的小组（即使很少使用），该小组通常不存在于具有小组功能的系统中。

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

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

例如，CMS可能具有一些权限，例如“阅读帖子”，“创建帖子”，“编辑帖子”。编辑者角色可能能够读取和编辑，但无法创建（不知道为什么！）。帖子可能能够创建和阅读等。一组经理可能具有编辑者角色，而IT中的用户（不在管理者组中）也可能具有编辑者角色，即使他或她的其他人组不。

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

尽管角色和组之间存在语义差异（如上文其他答案所述），但从技术上讲，角色和组似乎是相同的。没有什么可以阻止您直接将权限分配给用户和组（可以将其视为微调的访问控制）。同样，当为用户分配角色时，可以将其视为角色成员，与用户成为组成员相同。

因此，我们最终可以在角色和组之间没有任何实际区别。都可以考虑将用户AND / OR权限分组。因此，差异仅是语义上的：—如果在语义上将其用于对Permissions进行分组，则它就是角色；—如果在语义上用于对用户进行分组，则为组。从技术上讲，没有区别。

“组”是用户的集合。“角色”是权限的集合。这意味着，当组alpha包括组beta时，alpha从beta接收所有用户，而beta从alpha接收所有权限。相反，您可以说角色beta包含角色alpha，并且适用相同的结论。

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

从理论上讲，您可以只拥有一种收集类型。但是，如果您要说“集合alpha包括集合beta”，那将是模棱两可的。在这种情况下，您无法确定alpha用户（例如角色）还是beta用户（例如组）。为了使诸如“ includes”之类的术语与诸如“ treeview”之类的视觉元素明确，大多数rbac系统至少在讨论中要求您指定所讨论的集合是“组”还是“角色”。

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

注意-只有在试图强加组织内部的安全性时-以下杂乱无章才有意义-也就是说，试图限制对信息的访问...

团体是经验主义者-他们回答“什么”的问题。从某种意义上说，它们是“存在”，反映了访问的现有现实。IT人员喜欢团体-它们非常直白，易于定义。最终，所有访问控制最终都转移到了（正如我们在中学时代所学到的那样）回答“您属于哪个组？”这一问题。

但是，角色更规范-它们指导“应该”。优秀的经理和人力资源人员喜欢“角色”-他们不回答-他们问 “为什么？”的问题 不幸的是，角色也可能含糊不清，并且“模糊性”可能使（IT）人员发疯。

使用医疗上面的例子中，如果角色的“初级保健医生”比更多的权利（即多组访问）角色的“X射线技术”，这是因为人（经理和人力资源）决定为什么说需要发生。从这个意义上讲，它们是组织的“集体智慧”。

假设某位医生被授予访问患者财务记录的权限（成为具有访问权限的组的成员）。这通常超出了医生的“角色”，应该对此进行辩论。因此，任何人（无论资格如何）都不应拥有对所有群体的完全访问权限-它会导致滥用权力。这就是为什么“角色工程”如此重要的原因-如果没有它，您就可以像访问很多糖果一样分发组访问权限。人们将收集（有时成群结队）集体访问，而无需讨论过多权力的危险。

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

先前的答案都很棒。如前所述，“组与角色”的概念比技术更具概念性。我们已经采取了以下立场：组用于包含用户（一个用户可以在多个组中：即Joe在Managers组以及IT组中（他是IT的经理））并用于分配广泛的特权（即，我们的磁卡系统允许IT组中的所有用户访问服务器机房）。角色现在用于向特定用户添加特权（即，IT组中的人员可以将RDP发送到服务器，但不能分配用户或更改权限，具有Admin角色的IT组中的人员可以分配用户和更改权限）。角色也可以由其他角色组成（Joe具有管理员角色以添加用户/特权，还具有DBA角色来对服务器上的DBMS进行数据库更改）。角色也可以非常具体，因为我们可以为用户创建单个用户角色（即JoesRole）。因此，总而言之，我们使用组来管理用户，并分配常规角色和角色来管理特权。这也是累积的。用户所在的组可能已分配了角色（或可用角色列表），该角色将提供非常一般的特权（即IT组用户具有角色ServerRDP，使他们能够登录到服务器），因此已分配给该用户。然后，用户所属的任何角色都将按照定义的顺序添加，最后一个角色具有最终发言权（角色可以允许，拒绝或不应用特权，因此在应用每个角色时，角色将覆盖先前的特权设置）或不更改它）。一旦应用了所有组级别角色和用户级别角色，

根据用户在任何系统中扮演的职责，将其分配给角色。例如，具有角色Sales Manager的用户可以执行某些操作，例如为产品提供额外的折扣。

组用于对系统中的用户或角色进行“组”，以轻松管理安全性。例如，名为“领导力小组”的组可以让其成员来自角色经理，董事和架构师以及不属于这些角色的个人用户。现在，您应该能够为该组分配某些特权。

组的目的和角色在应用程序中会有所不同，但据我了解，主要是，组（用户集）是静态的，而角色（权限集）是随策略动态变化的，例如基于（9到6）的时间。组或用户可能具有此角色，但没有此角色。

您可以将角色分配给组。您可以将用户分配给组，也可以将角色分配给任何角色用户中的单个用户。含义。Jean Doe可以位于SalesDeptartment组中，而角色的ReportWritter可以从SharePoint中打印我们的报告，但是在SalesDepartment组中，其他人可能没有ReportWritter的角色。-换句话说，角色是具有分配的组的特殊特权。希望这能带来任何场面。

干杯！！！