谁能告诉我，组和角色之间的真正区别是什么？一段时间以来，我一直在试图弄清楚这一点，我阅读的信息越多，我就越觉得这只是为了混淆人们而提出的，并没有真正的区别。两者都可以做对方的工作。我一直使用组来管理用户及其访问权限。
最近，我遇到了一个管理软件，其中有一堆用户。每个用户都可以分配一个模块（整个系统分为几个部分，称为模块，即管理模块、调查模块、订单模块、客户模块）。最重要的是，每个模块都有一个功能列表，可以允许或拒绝每个用户。因此，假设用户 John Smith 可以访问模块 Orders 并可以编辑任何订单，但没有授予删除任何订单的权限。
如果有更多具有相同能力的用户，我会使用一个组来管理它。我会将这些用户聚集到同一个组中，并将模块的访问权限及其功能分配给该组。同一组中的所有用户将具有相同的访问权限。
为什么称它为组而不是角色？我不知道，我就是这么觉得。在我看来，这并不重要:] 但我仍然想知道真正的区别。
有什么建议为什么应该将其称为角色而不是组或相反？
谷歌是你的朋友 :)
无论如何，角色和组之间的区别来自计算机安全的概念（而不是简单的资源管理）。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 模型的限制（以及基于身份的组的传递。）
希望能帮助到你。
========================
在看到西蒙的好回应后添加了更多内容。角色可帮助您管理权限。组可帮助您管理对象和主题。此外，可以将角色视为“上下文”。角色“X”可以描述一个安全上下文，该上下文规则主体 Y 如何访问（或不访问）对象 Z。
另一个重要的区别（或理想）是角色工程师，即设计角色、上下文的人，这些角色在应用程序、系统或操作系统中是必要的和/或明显的。角色工程师通常是（但不一定是）角色管理员（或系统管理员）。此外，角色工程师的真正角色（不是双关语）是在安全工程领域，而不是管理领域。
这是一个由 RBAC 形式化的新组（即使它很少被使用），通常不会出现在具有组功能的系统中。
组是组织用户的一种方式，而角色通常是组织权限的一种方式。
这可以在许多方面有用。例如，可以将分组为角色的一组权限分配给一组组，或者独立于其组的一组用户。
例如，CMS 可能具有一些权限，例如阅读帖子、创建帖子、编辑帖子。编辑角色可能能够阅读和编辑，但不能创建（不知道为什么！）。帖子可能能够创建和阅读等。一组经理可能具有编辑角色，而不在经理组中的 IT 用户也可能具有编辑角色，即使他或她的其余部分组没有。
因此，虽然在一个简单的系统中，组和角色通常是紧密结合的，但情况并非总是如此。
尽管角色和组之间存在语义差异（如上面其他答案所述），但从技术上讲，角色和组似乎是相同的。没有什么可以阻止您将权限直接分配给用户和组（这可以被视为微调访问控制）。等价地，当用户被分配一个角色时，它可以被认为是一个角色成员，就像当用户成为一个组的成员时一样。
所以我们最终可以在角色和组之间没有真正的区别。两者都可以考虑用于对用户和/或权限进行分组。因此差异只是语义上的：——如果它在语义上用于分组权限，那么它就是一个角色；— 如果它在语义上用于对用户进行分组，那么它就是一个组。从技术上讲，没有区别。
“组”是用户的集合。“角色”是权限的集合。这意味着当组 alpha 包括组 beta 时，alpha 接收来自 beta 的所有用户，而 beta 接收来自 alpha 的所有权限。相反，您可以说角色 beta 包括角色 alpha，同样的结论也适用。
一个具体的例子让事情变得更清楚。考虑“客户支持”和“高级客户支持”。如果您将这些集合视为组，那么很明显客户支持用户“包括”高级客户支持用户。但是，如果您将它们视为角色，那么很明显，高级客户支持权限“包括”客户支持权限。
理论上，您可以只拥有一种集合类型。但是，如果您说“collection alpha 包括 collection beta”，那将是模棱两可的。在这种情况下，您无法判断 alpha 中的用户是处于 beta 中（如角色）还是 beta 中的用户处于 alpha 中（如组）。为了使诸如“包含”之类的术语和诸如树视图之类的视觉元素明确，大多数 rbac 系统要求您至少为了讨论而指定所讨论的集合是“组”还是“角色”。
一些类比可能会有所帮助。根据集合论，当组 alpha 是组 beta 的子集时，权限 alpha 是权限 beta 的超集。与家谱相比，如果说群体就像一棵后代树，那么角色就像一棵祖先树。
注意 - 只有当一个人试图在组织内强加安全性时，以下杂乱无章才有意义 - 也就是说，试图限制对信息的访问......
群体是经验主义的——他们回答“什么”的问题。它们是“是”，因为它们反映了现有的访问现实。IT 人员喜欢群体——他们非常直接且易于定义。最终，所有访问控制最终都转移到（正如我们在中学时都学到的那样......）回答“你属于哪个群体？”这个问题。
然而，角色更具规范性——它们指导“应该是”什么。优秀的经理和 HR 喜欢“角色”——他们不会回答——他们会问“为什么？” 不幸的是，角色也可能是模糊的，而且“模糊性”会让 (IT) 人发疯。
使用上面的医学示例，如果“初级保健医生”的角色比“X 射线技术员”的角色拥有更多的权利（即访问更多的群体），这是因为人们（经理和 HR）决定了为什么这样做需要发生。从这个意义上说，它们是一个组织的“集体智慧”。
假设医生有权访问（成为有权访问的组的成员）访问患者的财务记录。这通常超出了医生的“角色”，应该进行辩论。因此，任何人（无论多么有资格）都不应该拥有对所有群体的完全访问权限——这会导致滥用权力。这就是为什么“角色工程”如此重要的原因——没有它，你只会像糖果一样分发群组访问权限。人们会收集（有时是部落）群组访问权限，而不会讨论过多权力的危险。
总而言之，定义明确的角色的智慧有助于缓和失控组访问的危险。组织中的任何人都可以争取访问特定组。但是，一旦提供了访问权限，就很少会放弃。角色工程（以及定义明确的组描述和授权组访问管理器等最佳实践）可以限制组织内的利益冲突，分散决策制定并有助于使安全管理更加合理。
前面的答案都很精彩。如前所述，组与角色的概念更多的是概念性而非技术性。我们采取的立场是，组用于包含用户（一个用户可以在多个组中：即 Joe 属于 Managers 组和 IT 组[他是 IT 部门的经理]）并分配广泛的权限（即我们的磁卡系统允许IT组中的所有用户访问服务器机房）。角色现在用于向特定用户添加权限（即 IT 组中的人员可以 RDP 到服务器但不能分配用户或更改权限，具有管理员角色的 IT 组中的人员可以分配用户和更改权限）。角色也可以由其他角色组成（Joe 具有管理员角色来添加用户/权限，并且还具有 DBA 角色来对服务器上的 DBMS 进行数据库更改）。角色也可以非常具体，因为我们可以为用户创建非常具体的个人用户角色（即 JoesRole）。因此，回顾一下，我们使用组来管理用户并分配一般角色和角色来管理权限。这也是累积的。用户所在的组可能分配了角色（或可用角色列表），这些角色将赋予非常一般的权限（即 IT 组用户具有允许他们登录服务器的 ServerRDP 角色）以便分配给用户。然后，用户所属的任何角色都将按照定义的顺序添加，最后一个角色拥有最终决定权（角色可以允许、拒绝或不应用权限，以便在应用每个角色时，它会覆盖以前的权限设置或不改变它）。应用所有组级别角色和用户级别角色后，
用户根据他们在任何系统中所扮演的职责被分配到角色。例如，角色销售经理的用户可以执行某些操作，例如为产品提供额外折扣。
组用于对系统中的用户或角色进行“分组”，以便于安全管理。例如，一个名为“Leadership Group”的组可以拥有来自角色经理、董事和架构师的成员以及不属于这些角色的个人用户。现在您应该能够为该组分配某些权限。
组和角色的目的在应用程序中有所不同，但主要我理解如下，组（用户集）是静态的，而角色（权限集）是动态的策略，例如基于从（9 到 6）的时间组或用户可能有这个角色，但不是那个。
您可以为组分配角色。您可以将用户分配给组，并且可以将角色分配给任何角色用户中的单个用户。意义。Jean Doe 可以在 SalesDeptartment 组中，其角色为 ReportWritter，允许从 SharePoint 打印我们的报告，但在 SalesDepartment 组中，其他人可能没有 ReportWritter 角色。- 换句话说，角色是分配给组的特权。希望这能让任何场景。
干杯！！！