谁能告诉我，小组和角色之间真正的区别是什么？我一直试图弄清楚这一段时间，而且我阅读的信息越多，我就越觉得这只是为了让人迷惑而且没有真正的区别。两者都能做到对方的工作。我总是使用一个小组来管理用户及其访问权限。
最近，我遇到了一个管理软件，其中有很多用户。每个用户都可以分配一个模块（整个系统分为几个部分，称为模块，即管理模块，调查模块，订单模块，客户模块）。最重要的是，每个模块都有一个功能列表，每个用户都可以允许或拒绝这些功能。因此，假设用户John Smith可以访问模块订单并可以编辑任何订单，但是没有权利删除任何订单。
如果有更多用户具有相同的能力，我会使用一个小组来管理它。我会将这些用户聚合到同一个组中，并将模块及其功能的访问权限分配给该组。同一组中的所有用户都具有相同的访问权限。
为什么称它为一个群体而不是角色？我不知道，我只是觉得那样。在我看来，这根本不重要：]但我仍然想知道真正的区别。
为什么这应该被称为角色而不是群体或反过来？
答案 0 :(得分：121)
Google是你的朋友：）
无论如何，角色和群体之间的鸿沟来自计算机安全的概念（而不仅仅是资源管理）。 Ravi Sandhu教授对角色和群体之间的语义差异进行了开创性的报道。
http://profsandhu.com/workshop/role-group.pdf
组是具有分配给组（并且传递给用户）的给定权限集的用户的集合。角色是权限的集合，用户在该角色下行动时有效地继承了这些权限。
通常，您的群组成员资格会在您登录期间保留。另一方面，可以根据具体条件激活角色。如果您当前的角色是“医务人员”，您可能会看到某位患者的某些医疗记录。但是，如果您的角色也是“医生”，您可能会看到除了“医务人员”角色的人可以看到的其他医疗信息。
角色可以按时间，访问位置激活。角色也可以增强/与属性相关联。您可能是“医生”，但如果您没有“主要医生”属性或与我（具有“患者”角色的用户）的关系，那么您将看不到我的整个病史。
您可以通过群组完成所有这些工作，但同样，群体倾向于关注身份，而不是角色或活动。刚才描述的安全方面的类型往往更好地与后者相比更好。
对于许多情况，对于将事物一起分类的使用（仅此而已），组和角色的功能相同。但是，组基于身份，而角色则用于划分活动。不幸的是，操作系统往往模糊了区别，将角色视为组。
您会看到与应用程序或系统级角色更明确的区别 - 承载应用程序或系统特定的语义（如Oracle roles） - 而不是在操作系统级别实现的“角色”（通常是同义词）小组。）
角色和基于角色的访问控制模型可能存在限制（当然也有任何限制）：
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正式化的新小组（即使它很少被使用），这个小组通常没有出现在具有群组能力的系统中。
答案 1 :(得分：21)
群组是组织用户的一种手段，而角色通常是组织权利的一种手段。
这在许多方面都很有用。例如，可以将分组到角色中的一组权限分配给一组组，或者一组独立于其组的用户。
例如，CMS可能具有一些权限，如阅读帖子，创建帖子，编辑帖子。编辑器角色可能能够读取和编辑，但不能创建（不知道为什么！）。帖子可能能够创建和阅读等。一组管理员可能具有编辑角色，而不在管理员组中的IT用户也可能具有编辑角色，即使他或她的其余部分也是如此小组没有。
因此，在简单的系统中，组和角色通常是紧密对齐的，但情况并非总是如此。
答案 2 :(得分：18)
虽然角色和组之间存在语义差异（如上面其他答案所述），但技术上角色和组似乎是相同的。 没有什么可以阻止您直接向用户和组分配权限（这可以被视为微调访问控制）。 同样地，当为用户分配角色时，可以将其视为角色成员，就像用户成为群组成员一样。
因此，我们最终可能没有角色和群组之间的真正区别。两者都可以考虑对用户和/或权限进行分组。 因此差异只是语义： - 如果它在语义上用于分组权限，则它是一个角色; - 如果它在语义上用于对用户进行分组，那么它就是一个组。 从技术上讲，没有区别。
答案 3 :(得分：13)
A＆＃34; group＆＃34;是一组用户。 A＆＃34;角色＆＃34;是一组权限。这意味着当群组alpha包含群组测试版时，alpha会收到来自测试版的所有用户，而测试版会从alpha获得所有权限。相反，你可以说角色beta包括角色alpha ，并且适用相同的结论。
具体示例使事情变得更加清晰。考虑＆＃34;客户支持＆＃34;和＃34;高级客户支持＆＃34;。如果您将这些集合视为组，那么很明显，客户支持用户＆＃34;包括＆＃34;高级客户支持用户。但是，如果您将它们视为角色，那么很明显，高级客户支持权限包括＆＃34;客户支持权限。
理论上，您可以只使用一种集合类型。但是，如果您要说＆＃34;收集alpha包括收集测试版＆＃34; ，那将是不明确的。在这种情况下，您无法判断alpha中的用户是处于测试阶段（如角色）还是处于测试阶段的用户处于alpha状态（如组）。为了使术语像＆＃34;包括＆＃34;大多数rbac系统都要求你指明有争议的集合是否是一个＆＃34; group＆＃34;或者角色＆＃34;至少是为了讨论。
一些类比可能有所帮助。以集合论为框架，当组alpha是组beta的子集时，权限alpha是权限beta的超集。与族谱相比，如果群体就像一个后代树，那么角色就像一棵祖先的树。
答案 4 :(得分：3)
注意 - 如果一个人试图在组织内部施加安全性，那么下列漫游才有意义 - 也就是说，试图限制对信息的访问......
群体是经验性的 - 他们回答“什么”的问题。从某种意义上说，它们反映了现有的访问现实。 IT人员喜欢群体 - 他们非常直接，易于定义。最终，所有访问控制最终都会（正如我们在中学时学到的那样......）回答“你属于哪个群体？”这个问题。
然而，角色更具规范性 - 它们指导“应该”。优秀的经理和人力资源部门喜欢“角色” - 他们没有回答 - 他们问问题“为什么？”不幸的是，角色也可能含糊不清，“模糊”可能会让人们变得疯狂。要使用上述医学示例，如果“初级保健医生”的角色拥有比“x的角色更多的权利（即访问更多群组） -ray技术员“，这是因为人们（经理和人力资源部门）决定为什么需要发生。从这个意义上讲，它们是组织的“集体智慧”。
假设医生可以获得患者财务记录的访问权限（可访问的组的成员资格）。这通常不在医生的“角色”之内，应该进行辩论。因此，没有人（无论多么合格）应该可以完全访问所有群组 - 它会滥用权力。这就是为什么“角色工程”如此重要 - 如果没有它，你只需要像这么多糖果一样分发群组。人们将收集（有时是部落）群体访问，而不讨论太多权力的危险。
总而言之，定义明确的角色的智慧有助于缓解失控群体访问的危险。组织中的任何人都可以争取访问特定组。但是一旦提供了访问权限，就很少放弃。角色工程（以及明确定义的组描述和授权组访问管理器等最佳实践）可以限制组织内的利益冲突，分散决策并帮助使安全管理更加合理。
答案 5 :(得分：3)
以前的答案都很精彩。如上所述，群体与角色的概念更具概念性而非技术性。我们采取的态度是组用于包含用户（用户可以在多个组中：即Joe在Managers组和IT组[他是IT经理]）以及分配广泛权限（即我们的磁卡系统允许IT组中的所有用户访问服务器机房）。角色现在用于向特定用户添加权限（即IT组中的人员可以RDP到服务器但无法分配用户或更改权限，具有Admin角色的IT组中的人员可以分配用户和更改权限）。角色也可以由其他角色组成（Joe具有Admin角色以添加用户/权限，并且还具有DBA角色以对服务器上的DBMS进行数据库更改）。角色也可以非常具体，因为我们可以为用户创建非常具体的用户角色（即JoesRole）。因此，回顾一下，我们使用Groups来管理用户并分配一般角色和角色来管理权限。这也是累积的。用户所在的组可能已分配角色（或可用角色列表），这些角色将提供非常一般的权限（即IT组用户具有允许他们登录服务器的角色ServerRDP），以便分配给用户。然后，用户所属的任何角色将按其定义的顺序添加，最后一个角色具有最终发言权（角色可以允许，拒绝或不应用权限，以便在应用每个角色时，它将覆盖以前的特权设置或不改变它）。一旦应用了所有组级角色和用户级别角色，就会为用户创建一个独特的安全模型，可以在整个系统中使用这些模型来确定访问和功能。
答案 6 :(得分：1)
根据用户在任何系统中的职责分配角色。例如，角色Sales Manager中的用户可以执行某些操作，例如为产品提供额外折扣。
组用于在系统中“分组”用户或角色，以便于管理安全性。例如，一个名为“领导小组”的小组可以让其成员来自“管理者”，“导演”和“管理人员”。不属于这些角色的建筑师和个人用户。现在，您应该能够为该组分配特定权限。
答案 7 :(得分：1)
组和角色的目的在应用程序中有所不同，但主要是我所理解的如下， 组（用户组）是静态的，而角色（权限集）是动态的策略，例如，基于时间从（9到6）组或用户可能具有此角色但不是。
答案 8 :(得分：0)
您可以将角色分配给组。您可以将用户分配到组，并且可以在任何角色用户中为单个用户分配角色。含义。 Jean Doe可以在SalesDeptartment Group中使用ReportWritter的角色，它允许从SharePoint打印我们的报告，但在SalesDepartment组中，其他人可能没有ReportWritter的角色。 - 换句话说，角色是具有指定组的特权。希望这会产生任何场景。
干杯!!!