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

Question

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

167

有人能告诉我组和角色之间的真正区别是什么吗？我一直在试图弄清楚这个问题，但我读到的信息越多，我就越觉得这只是为了混淆人们而提出来的，实际上并没有真正的区别。两者都可以完成另一个的工作。我一直使用组来管理用户及其访问权限。

最近，我遇到了一款管理软件，在其中有一群用户。每个用户可以被分配一个模块（整个系统被分成几个称为模块的部分，例如管理模块、调查模块、订单模块、客户模块）。此外，每个模块都有一个功能列表，可以允许或拒绝每个用户使用。因此，假设一个名叫John Smith的用户可以访问订单模块并编辑任何订单，但没有权利删除其中任何一个订单。

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

为什么称它为组而不是角色呢？我不知道，我只是这样感觉。对我来说，似乎这并不真正重要：] 但我仍然想知道真正的区别。

有什么建议，为什么这应该被称为角色而不是组，或者另一种方式？

- Ondrej

1

可能是什么是组和角色之间的区别？的重复问题。 - Steve Chambers

请查看上面提到的重复内容。它的前两个简短答案都比这里的任何一个更好。（技术上，组和角色的工作方式相同，只是它们的使用方式不同） - FastAl

3

我不同意@FastAl的看法，我发现这个问题的答案比重复问题的答案更好。 - Alex Oliveira

11个回答

43

“Group”是组织用户的一种方式，而“角色”通常是组织权限的一种方式。

这种方法有很多用途。例如，将分组的权限集合分配给一组或一组独立的用户时，可以使用角色。

例如，内容管理系统可能有像“读取文章”、“创建文章”、“编辑文章”之类的一些权限。编辑者角色可以阅读和编辑，但不能创建（不知道为什么！）文章。文章可以创建和阅读等等。管理人员组可能具有编辑者角色，而IT部门的某个用户，即使不在管理员组中，也可能具有编辑者角色，尽管他或她所在的组其他成员没有这个角色。

因此，尽管在简单的系统中，组和角色通常紧密相连，但并非总是如此。

- Simon Elliston Ball

如果我理解正确的话，您不能将用户分配给角色，但可以将用户分配给组。之后，您可以将角色分配给用户组。 - Ondrej

不一定是Ondrej。一个应用程序、系统或操作系统可以实现一种机制来分配用户角色（尽管这可能会很复杂）。Simon的答案非常准确，角色是管理权限的手段（而不是组作为管理主题和对象的手段）。 - luis.espinal

谢谢大家，现在我明白多了。在上述系统中，我刚刚注意到还有另一种机制来区分用户。每个分配到任何模块的用户都可以根据其作为用户、监督员和管理员的能力而更加区分，我猜这就是角色系统：] 所以再次感谢你们两个！;) - Ondrej

我很喜欢你的解释，但是出于某种原因，这里没有人写关于用户可能属于多个组的可能性......群组难道也不能属于其他群组和允许分配角色的角色吗？资源不能也属于群组吗？资源不能有角色吗？ - inor

31

"组"是用户的集合。"角色"是权限的集合。这意味着，当alpha组包含beta组时，alpha收到来自beta的所有用户，而beta收到来自alpha的所有权限。反之，您可以说beta角色包含alpha角色，同样的结论也适用。

一个具体的例子会让事情更加清晰。考虑"客户支持"和"高级客户支持"。如果你将这些集合视为组，则很明显客户支持用户"包含"高级客户支持用户。然而，如果你把它们看成角色，那么很明显高级客户支持的权限"包括"客户支持的权限。

理论上，你可以只有一种集合类型。但是，如果你说"集合alpha包含集合beta"，那就会产生歧义。在这种情况下，你无法确定alpha中的用户是否在beta中（像一个角色），还是beta中的用户在alpha中（像一个组）。为了使术语如"包含"和可视元素如树形视图不模棱两可，在大多数RBAC系统中，您需要至少在讨论中指定所涉及的集合是"组"还是"角色"。

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

- james turner

1

你的解释完美地阐述了为什么我们不能把组视为角色（正如Mileta的回答所建议的）。这是一个完美的例子。 - drizin

2

实际上，我们可以将组视为角色（正如Mileta Cekovic所说）。例如，我们可以为每个组分配一个唯一的角色（1:1关系）。但是，我们不能将组之间的关系解释为相应角色之间的关系。例如，如果“客户支持”组包括“高级客户支持”组——这并不意味着“客户支持”角色包括“高级客户支持”角色。 - ruvim

29

虽然在语义上Roles（角色）和Groups（组）有区别（在其他答案中已经描述过），但从技术上讲，Roles和Groups似乎是相同的。没有什么可以阻止您直接将权限分配给用户和组（这可以被视为精细调整访问控制）。同样地，当将用户分配给角色时，可以将其视为角色成员，就像用户成为组的成员一样。

因此，Roles和Groups之间实际上没有真正的区别。两者都可以用于对用户和/或权限进行分组。因此，不同之处仅在于语义： - 如果它在语义上用于分组权限，则为角色； - 如果它在语义上用于分组用户，则为组。从技术上讲，它们没有区别。

- Mileta Cekovic

如果您将一个组添加为另一个组的成员，并且两个组都有相关权限，则加法权限将正常工作。这就是NTFS的工作原理。然而，当我们谈论系统时，我认为用户会以“让我作为财务部门登录”、“让我作为访客登录”的方式思考，在这种情况下，我认为分层角色会令人困惑。我不会允许除顶级组以外的任何组具有相关权限。 - drizin

6

注意：以下的胡言乱语只有在试图在组织内实施安全性时才有意义——也就是说，试图限制对信息的访问...

组是经验主义的——它们回答了“什么”这个问题。从某种意义上说，它们代表着现有访问实际情况中的“存在”。IT人员喜欢组——它们非常明确且易于定义。最终，所有访问控制最终都会退化（正如我们在中学时学到的那样...）到回答“你属于哪个组？”这个问题。

然而，角色更加规范化——它们指导“应该是什么”。好的管理者和人力资源部门喜欢“角色”——它们不回答问题——它们提出“为什么？”这个问题。不幸的是，角色也可能模糊不清，这种“模糊性”可能会让（IT）人感到疯狂。

使用上面的医学例子，如果“初级医疗保健医生”的角色比“X光技师”的角色拥有更多的权利（即访问更多的组），那是因为人们（管理者和人力资源部门）决定了为什么需要这样做。从这个意义上说，它们是组织的“集体智慧”。

假设一位医生被授予访问患者财务记录的权限（成为具有访问权限的组的成员）。这通常超出了医生的角色，应该进行讨论。因此，没有人（无论多么合格）应该拥有对所有组的完全访问权限——这会引发滥用权力的行为。这就是为什么“角色工程”非常重要——如果没有它，你只会像分发糖果一样分发组访问权限。人们会收集（有时会囤积）组访问权限，而不会讨论过多的权力带来的危险。

总之，定义良好的角色的智慧有助于调节失控组访问的危险。组织中的任何人都可以争取访问特定的组。但是一旦提供了这种访问权限，它很少会放弃。角色工程（以及最佳实践，例如定义明确的组描述和赋予组访问管理员权限）可以限制组织内利益冲突，分散决策，并帮助使安全管理更加理性。

- TJ Evert

4

之前的回答都很好。正如已经说明的那样，组与角色的概念更多地是概念性的而非技术性的。我们认为，组用于包含用户（一个用户可以在多个组中：例如，Joe既在经理组中，也在IT组中[他是IT部门的经理]），并分配广泛的特权（例如：我们的磁卡系统允许IT组中的所有用户进入服务器房间）。角色用于向特定用户添加特权（例如：IT组中的人可以RDP到服务器，但无法分配用户或更改权限，拥有Admin角色的IT组中的人可以分配用户和更改权限）。角色也可以由其他角色组成（Joe具有管理员角色来添加用户/特权，并且还具有DBA角色来对服务器上的DBMS进行数据库更改）。角色也可以非常具体，因为我们可以创建个别用户角色（例如：JoesRole），这些角色可以针对特定用户非常具体。因此，总之，我们使用组来管理用户和分配一般的角色，使用角色来管理特权。这也是累积的。用户所在的组可能已分配了角色（或可用角色列表），这将给予非常一般的特权（例如：IT组用户拥有ServerRDP角色，该角色让他们登录到服务器），因此被分配给用户。然后，用户所属的任何角色都将按照定义顺序添加，最后一个角色拥有最终决定权（角色可以允许、拒绝或不应用特权，因此每个角色被应用时，它要么覆盖先前的特权设置，要么不更改它）。一旦应用了所有组级别角色和用户级别角色，就会为用户创建独特的安全模型，可用于确定访问和功能。

- Steve Smith

+1 因为您提供了一个非常真实的例子，因为这些概念的重叠意味着除了特定实现之外，没有真正的区别。然而，它并没有很清楚地说明您增加角色所获得的优势：您提到的 IT 用户拥有管理员角色的示例可以通过将用户放入 IT 用户和管理员_组_中来轻松完成。隐含“权限”“允许 RDP 到”和“角色”之间没有真正的区别：“可以分配用户”。此外，您说角色可以由其他角色组成，但您的示例是 Joe 有两个角色，而不是组合其他角色的角色。 - Rhubarb

1

在应用程序中，组和角色的目的各不相同，但我理解的主要如下：组（用户集合）是静态的，而角色（权限集合）是动态的，并具有策略，例如基于时间段（从9点到6点），一个组或用户可能具有这个角色，但没有那个角色。

- Salahuddin Khan

1

根据用户在系统中扮演的职责，将其分配到相应角色。例如，在销售经理角色下的用户可以执行某些操作，例如为产品提供额外折扣。

组用于在系统中“分组”用户或角色，以便更轻松地管理安全性。例如，“领导小组”可以由来自经理、总监和架构师角色的成员以及不属于这些角色的个人用户组成。现在，您应该能够为此组分配特定的权限。

- Saju Mathew

0

除了所有解释了什么是“组”和“角色”的好答案之外，我认为使用“组”而不是直接将“角色”分配给“用户”的一个好理由是在软件演进时更新“角色”更容易。

与为每个用户单独执行相同操作相比，更新“组”的“角色”将更加容易。

- SayeedHussain

0

你可以给组分配角色。你可以将用户分配到组中，还可以在任何角色用户中将角色分配给个人用户。意思是，Jean Doe可以在销售部门组中担任报表编写员的角色，从SharePoint打印我们的报表，但在销售部门组中，其他人可能没有报表编写员的角色。换句话说，角色是在分配的组内特殊的特权。希望这样可以理解。

干杯！

- Chirag Patel

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- luis.espinal · Accepted Answer

角色和组之间的区别来自于计算机安全概念（而不仅仅是资源管理）。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正式形成的一种新型组，尽管它很少被使用，但通常在具备组功能的系统中并不存在。