谁能告诉我，组和角色之间的真正区别是什么？我已经尝试弄清楚这一点有一段时间了，我阅读的信息越多，我就越觉得这只是为了迷惑人们，并没有真正的区别。双方都可以做对方的工作。我一直使用组来管理用户及其访问权限。
最近，我遇到了一个管理软件，里面有很多用户。每个用户可以分配一个模块（整个系统分为几个部分，称为模块，即管理模块、调查模块、订单模块、客户模块）。最重要的是，每个模块都有一个功能列表，可以为每个用户允许或拒绝。假设用户 John Smith 可以访问模块订单并可以编辑任何订单，但没有授予删除任何订单的权利。
如果有更多具有相同能力的用户，我会使用一个组来管理。我会将这些用户聚合到同一组中，并将模块及其功能的访问权限分配给该组。同一组中的所有用户都具有相同的访问权限。
为什么称其为组而不是角色？我不知道，我只是这么感觉。在我看来，这并不重要:]但我仍然想知道真正的区别。
有什么建议为什么应该将其称为角色而不是组，或者反之亦然？
Can anyone tell me, what's the real difference between group and role? I've been trying to figure this out for some time now and the more information I read, the more I get the sense that this is brought up just to confuse people and there is no real difference. Both can do the other's job. I've always used a group to manage users and their access rights.
Recently, I've come across an administration software, where is a bunch of users. Each user can have assigned a module (whole system is split into a few parts called modules ie. Administration module, Survey module, Orders module, Customer module). On top of it, each module have a list of functionalities, that can be allowed or denied for each user. So let's say, a user John Smith can access module Orders and can edit any order, but haven't given a right to delete any of them.
If there was more users with the same competency, I would use a group to manage that. I would aggregate such users into the same group and assign access rights to modules and their functions to the group. All users in the same group would have the same access rights.
Why call it a group and not role? I don't know, I just feel it that way. It seems to me that simply it doesn't really matter :] But I still would like to know the real difference.
Any suggestions why this should be rather called role than group or the other way round?
发布评论
评论（11）
角色和组之间的划分来自计算机安全的概念（而不是简单的资源管理）。 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 形式化的新颖组（即使很少使用），通常不存在于具有组功能的系统中。
The divide between role and group comes from concepts of computer security (as opposed to simply resource management). Prof. Ravi Sandhu provides a seminal coverage of the semantic difference between roles and groups.
http://profsandhu.com/workshop/role-group.pdf
A group is a collection of users with a given set of permissions assigned to the group (and transitively, to the users). A role is a collection of permissions, and a user effectively inherits those permissions when he acts under that role.
Typically your group membership remains during the duration of your login. A role, on the other hand, can be activated according to specific conditions. If your current role is 'medical-staff' you might be able to see some of the medical records for a given patient. If, however, your role is also 'physician', you might be able to see additional medical information beyond what a person with just a role of 'medical-staff' can see.
Roles can be activated by time of day, location of access. Roles can also be enhanced/associated with attributes. You might be operating as 'physician', but if you do not have a 'primary physician' attribute or relation with me (a user with 'patient' role), then you cannot see my entirety of medical history.
You could do all that with groups, but again, groups tend to focus on identity, not role or activity. And the type of security aspects just described tend to align themselves better with the later than with the former.
For many cases, for the usage of classifying things together (and nothing more), groups and roles function just the same. Groups, however, are based on identity, whereas roles are meant to demarcate activity. Unfortunately, operating systems tend to blur the distinction, treating roles as groups.
You see a much clearer distinction with application or system-level roles - carrying application or system-specific semantics (like in Oracle roles) - as opposed to 'roles' implemented at the OS level (which are typically synonymous to groups.)
There can be limitations to roles and role-based access control models (like with anything of course):
http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
About a decade ago I saw some research on attribute-based and relationship-based access control which provide much better granularity than role-based access control. Unfortunately, I haven't seen much activity on that realm in years.
The most important difference between roles and groups is that roles typically implement a mandatory access control (MAC) mechanism. You do not get to assign yourself (or others) to roles. A role admin or role engineer does that.
This is superficially similar to UNIX groups where a user can/might be able to assign himself to a group (via sudo of course.) When groups are assigned according to a security engineering process, the distinction blurs a bit, however.
Another important characteristic is that true RBAC models can provide the concept of mutually exclusive roles. In contrast, identity-based groups are additive - a principal's identity is the sum (or conjunction) of the groups.
Another characteristic of a true-RBAC based security model is that elements created for a particular role typically cannot be transitively accessed by someone who does not act under that role.
On the other hand, under a discretionary access control (DAC) model (the default model in Unix), you cannot get that type of guarantee with groups alone. BTW, this is not a limitation of groups or Unix, but a limitation of DAC models based on identity (and transitively, with identity-based groups.)
Hope it helps.
=======================
Adding some more after seeing Simon's well-put response. Roles help you manage permissions. Groups help you manage objects and subjects. Moreover, one could think of roles as 'contexts'. A role 'X' can describe a security context that rule how subject Y access (or does not access) object Z.
Another important distinction (or ideal) is that there is a role engineer, a person that engineers the roles, the contexts, that are necessary and/or evident in an application, system or OS. A role engineer typically is (but does not have to be) also a role admin (or sysadmin). Moreover, the true role (no pun intended) of a role engineer is in the realm of security engineering, not administration.
This is a novel group formalized by RBAC (even if it seldom gets used), one which has typically not been present with group-capable systems.
组是组织用户的一种方式，而角色通常是组织权限的方式。
这在很多方面都很有用。例如，可以将分组为角色的一组权限分配给一组组，或者独立于其组的一组用户。
例如，CMS 可能具有一些权限，例如阅读帖子、创建帖子、编辑帖子。编辑者角色可能能够读取和编辑，但不能创建（不知道为什么！）。帖子可能能够创建和阅读等。一组经理可能具有编辑者角色，而不在经理组中的 IT 用户也可能具有编辑者角色，即使他或她的其余部分也可能具有编辑者角色。组没有。
因此，虽然在简单的系统中，组和角色通常紧密结合，但情况并非总是如此。
A group is a means of organising users, whereas a role is usually a means of organising rights.
This can be useful in a number of ways. For example, a set of permissions grouped into a role could be assigned to a set of groups, or a set of users independently of their group.
For example, a CMS might have some permissions like Read post, Create post, Edit post. An Editor role might be able to Read and Edit, but not create (don't know why!). A post might be able to Create and Read etc. A group of managers might have the editor role, while a user in IT, who is not in the managers group, may also have the editor role, even though the rest of his or her group does not.
So while in a simple system groups and roles are often closely aligned, this is not always the case.
“组”是用户的集合。 “角色”是权限的集合。这意味着当 alpha 组包含 beta 组时，alpha 接收来自 beta 的所有用户，而 beta 接收来自 alpha 的所有权限。相反，您可以说角色 beta 包含角色 alpha 并且同样的结论也适用。
具体示例使事情更加清晰。考虑“客户支持”和“高级客户支持”。如果您将这些集合视为组，那么很明显客户支持用户“包括”高级客户支持用户。但是，如果您将它们视为角色，那么很明显高级客户支持权限“包括”客户支持权限。
理论上，您可以只拥有一种集合类型。但是，如果您说“集合 alpha 包含集合 beta”，那就含糊不清了。在这种情况下，您无法判断 alpha 中的用户是否处于 beta 状态（如角色）或 beta 中的用户是否处于 alpha 状态（如组）。为了使“包含”等术语和树视图等视觉元素明确无误，大多数 rbac 系统要求您指定所讨论的集合是“组”还是“角色”，至少是为了讨论。
一些类比可能会有所帮助。根据集合论，当组 alpha 是组 beta 的子集时，则权限 alpha 是权限 beta 的超集。与家谱相比，如果群体就像一棵后代树，那么角色就像一棵祖先树。
A "group" is a collection of users. A "role" is a collection of permissions. That means that when group alpha includes group beta, alpha receives all the users from beta and beta receives all the permissions from alpha. Conversely, you could say role beta includes role alpha and the same conclusions would apply.
A concrete example makes things more clear. Consider "customer support" and "senior customer support". If you think of those collections as groups, then it is clear that customer support users "includes" senior customer support users. However, if you look at them as roles, then it is clear that senior customer support permissions "includes" customer support permissions.
In theory, you could simply have one collection type. However, it would be ambiguous if you were to say that "collection alpha includes collection beta". In that case, you can't tell if the users in alpha are in beta (like a role) or the users in beta are in alpha (like a group). In order to make terminology like "includes" and visual elements like tree views unambiguous, most rbac systems require you to specify whether the collection at issue is a "group" or a "role" at least for the sake of discussion.
Some analogies might help. Framed in terms of set theory, when group alpha is a subset of group beta, then permissions alpha are a superset of permissions beta. Compared to genealogy, if groups are like a tree of descendants, then roles are like a tree of ancestors.
尽管角色和组之间存在语义差异（如上面其他答案所述），但从技术上讲，角色和组似乎是相同的。
没有什么可以阻止您直接向用户和组分配权限（这可以被视为微调访问控制）。
同样，当用户被分配角色时，它可以被视为角色成员，这与用户成为组成员时的意义相同。
因此，我们最终可以发现角色和组之间没有真正的区别。两者都可以考虑用于对用户和/或权限进行分组。
因此差异只是语义上的：
— 如果它在语义上用于对权限进行分组，那么它就是一个角色；
— 如果它在语义上用于对用户进行分组，那么它就是一个组。
从技术上讲，没有区别。
Although there is semantic difference between Roles and Groups (as described above by other answers), technically Roles and Groups seems to be the same.
Nothing prevents you to assign Permissions directly to Users and Groups (this can be considered as a fine-tuning access control).
Equivalently, when User is assigned a Role, it can be considered a role Member, in the same sense when user becomes Member of a Group.
So we can end up with no real difference between Roles and Groups. Both can be considered for grouping Users AND/OR Permissions.
Thus difference is only semantic:
— if it is semantically used for grouping Permissions, it is then a Role;
— if it is semantically used for grouping Users, it is then a Group.
Technically, there is no difference.
注意 - 只有当一个人试图在组织内施加安全性时，以下漫谈才有意义 - 也就是说，试图限制对信息的访问......
组是经验性的 - 他们回答“什么”的问题。它们是“是”，因为它们反映了现有的访问现实。 IT 人员喜欢群体——他们非常字面化且易于定义。最终，所有访问控制最终都会转向（正如我们在中学时学到的那样……）来回答“您属于哪个群体？”的问题。
然而，角色更加规范——它们指导“应该是什么”。优秀的经理和人力资源部门喜欢“角色” - 他们不会回答 - 他们问“为什么？”的问题不幸的是，角色也可能是模糊的，这种“模糊性”会让（IT）人员发疯。
以上面的医疗示例为例，如果“初级保健医生”的角色比“X 射线技术人员”的角色拥有更多的权利（即访问更多组） ”，这是因为人们（经理和人力资源部门）决定了为什么需要发生这种情况。从这个意义上说，它们是一个组织的“集体智慧”。
假设医生有权访问患者的财务记录（有权访问的团体的成员身份）。这通常不属于医生的“角色”，应该进行辩论。因此，任何人（无论多么有资格）都不应完全接触所有群体——这会导致滥用权力。这就是为什么“角色工程”如此重要 - 没有它，您就只能像糖果一样获得组访问权。人们会收集（有时是聚集）团体访问权，而不会讨论权力过多的危险。
总而言之，明确角色的智慧有助于减轻失控的群体访问的危险。组织中的任何人都可以争取进入特定群体的权利。但一旦提供了这种访问权限，就很少会放弃。角色工程（以及良好定义的组描述和授权的组访问管理员等最佳实践）可以限制组织内的利益冲突，分散决策并帮助使安全管理更加合理。
NOTE - the following ramblings only makes sense if one is trying to impose security within an organization - that is to say, trying to limit the access to information...
Groups are empirical - they answer the question of "what". They are the "is" in the sense they reflect the existing reality of access. IT people love groups - they are very literal and easy to define. Eventually, all access control ultimately devolves (as we all learned back in middle school...) to answering the question "To what group do you belong?"
Roles, however, are more normative - they guide what "should be". Good managers and HR love "roles" - they don't answer - they ask the question of "Why?" Unfortunately, roles can also be vague and that "fuzziness" can drive (IT) people nuts.
To use the medical example above, if the role of "primary care physician" has more rights (i.e. access to more groups) than the role of an "x-ray technician", this is because people (managers and HR) decided why that needed to happen. In that sense they are "the collective wisdom" of an organization.
Let's say a doctor is given access (membership to a group with access) to financial records of patients. This is normally outside the "role" of a doctor and should be debated. So, no one (no matter how qualified) should have full access to all groups - it invites abuses to power. This is why "role engineering" is so important - without it, you just have group access handed out like so much candy. People will collect (and sometimes horde) group access with no discussion as to the dangers of too much power.
To conclude, the wisdom of well-defined roles helps moderate the dangers of runaway group access. Anyone in an organization can argue for access to a particular group. But once that access is provided, it's rarely given up. Role engineering (along with best-practices like well-defined group descriptions and empowered group access managers) can limit conflicts of interest within an organization, decentralize decision-making and help make security management more rational.
前面的答案都很棒。如前所述，组与角色的概念更多的是概念性而非技术性。我们采取的立场是，组用于包含用户（一个用户可以属于多个组：即 Joe 属于 Managers 组以及 IT 组 [他是 IT 部门的经理]）并用于分配广泛的权限（即我们的磁卡系统允许IT组中的所有用户访问服务器机房）。现在使用角色为特定用户添加权限（即，IT 组中的人员可以通过 RDP 连接到服务器，但不能分配用户或更改权限，IT 组中具有管理员角色的人员可以分配用户和更改权限）。角色也可以由其他角色组成（Joe 具有用于添加用户/权限的管理员角色，并且还具有用于对服务器上的 DBMS 进行数据库更改的 DBA 角色）。角色也可以非常具体，因为我们可以为用户创建非常具体的单个用户角色（即 JoesRole）。因此，回顾一下，我们使用组来管理用户并分配常规角色和角色来管理权限。这也是累积的。用户所在的组可能分配有角色（或可用角色列表），这些角色将赋予非常一般的权限（即 IT 组用户具有允许他们登录服务器的 ServerRDP 角色），以便将其分配给用户。然后，用户所属的任何角色都将按照定义的顺序添加，最后一个角色拥有最终发言权（角色可以允许、拒绝或不应用权限，以便应用每个角色时，它将覆盖以前的权限设置或者不改变它）。应用所有组级角色和用户级角色后，将为用户创建一个独特的安全模型，可在整个系统中使用该模型来确定访问权限和功能。
The previous answers are all wonderful. As was stated, the concept of Group vs Role is more conceptual than technical. We have taken the stance that Groups are used for containing users (a user can be in more than one group: i.e. Joe is in the Managers group as well as the IT group [he is a manager in IT]) and for assigning broad privileges (i.e. Our mag card system allows all users in the IT group access to the server room). Roles were used to now add privileges to specific users (i.e. people in the IT group can RDP to servers but cannot assign users or change permissions, people in the IT group with the Admin role can assign users and change permissions). Roles can be made up of other roles as well (Joe has Admin role to add users/privileges and also has DBA role to do database changes to the DBMS on the server). Roles can be very specific as well in that we can make individual user Roles (i.e. JoesRole) that can be very specific for a user. So, to recap, we use Groups to manage users and assign general Roles and Roles to manage privileges. This is also cumulative. The Group the user is in may have Roles assigned (or a list of available Roles) that will give very general privileges (i.e. IT group users have the role ServerRDP that lets them log onto the servers) so that is assigned to the user. Then any Roles the user belongs in will be added in the order they are defined with the last Role having the final say (Roles can Allow, Deny or not apply privileges so that as each Role is applied it will either override previous settings for a privilege or not change it). Once all the Group level Roles and User level Roles have been applied, a distinct security model is created for the user that can be used throughout our systems to determine access and capabilities.
根据用户在任何系统中所扮演的职责，将用户分配给角色。例如，担任销售经理角色的用户可以执行某些操作，例如为产品提供额外折扣。
组用于对系统中的用户或角色进行“分组”，以便于安全管理。例如，名为“领导小组”的小组可以具有来自经理、董事和领导角色的成员。架构师和不属于这些角色的个人用户也是如此。现在您应该能够向该组分配某些权限。
Users are assigned to Roles based on the responsibility they play in any system. For example users in role Sales Manager can perform certain actions such as provide additional discount for a product.
Groups are used to 'group' users or roles in a system for easy management of security. For example a group named "Leadership Group" can have its members from roles Managers, Directors & Architects and individual users who are out of these roles as well. Now you should be able to assign certain privileges to this group.
组和角色的目的因应用程序而异，但我主要理解如下，
组（用户集）是静态的，而角色（权限集）是随策略动态变化的，例如，根据时间（9 到 6），组或用户可能具有此角色，但不能具有该角色。
Purpose of Groups and Roles vary in applications, but mainly what i understood is as follow,
Groups(set of users) are static while Roles(set of permissions) are dynamic with policies, for example based on time from (9 to 6) a group or user may have this role but not that.
您可以将角色分配给组。您可以将用户分配到组，也可以将角色分配给任何角色用户中的单个用户。意义。 Jean Doe 可以在 SalesDeptartment 组中，并具有 ReportWritter 角色，这允许从 SharePoint 打印我们的报告，但在 SalesDepartment 组中，其他人可能没有 ReportWritter 角色。 - 换句话说，角色是指定组内的特殊权限。希望这能产生任何场景。
干杯！！！
You can assign a role to group. You can assign user to group and you can assign role to individual user in any role user. Meaning. Jean Doe can be in Group of SalesDeptartment with role off ReportWritter which allows to print our reports from SharePoint, but in SalesDepartment group, others may not have role of ReportWritter. - In other words, roles are special privileges withing assigned groups. Hope this makes any scenes.
Cheers!!!
这对我们有用：
This works for us:
除了解释什么是
Groups和Roles的所有好答案之外，我考虑使用Groups而不是直接分配Roles 的一个很好的理由到用户是在软件发展过程中需要时可以轻松更新角色。与单独为每个用户执行相同操作相比，更新
组的角色会更容易。Besides all the good answers that explain what
GroupsandRolesare, one good reason I would consider usingGroupsinstead of directly assigningRolestoUsersis the ease of updatingRolesif required as the software evolves.It will be easier to update
RolesofGroupsas compared to doing the same for each user individually.