Groupe ou rôle (y a-t-il une réelle différence ?)

Question

Quelqu'un peut-il me dire quelle est la différence réelle entre groupe et rôle ? J'essaie d'y voir clair depuis un certain temps et plus je lis d'informations, plus j'ai l'impression que l'on en parle juste pour embrouiller les gens et qu'il n'y a pas de réelle différence. Les deux peuvent faire le travail de l'autre. J'ai toujours utilisé un groupe pour gérer les utilisateurs et leurs droits d'accès.

Récemment, je suis tombé sur un logiciel d'administration, où il y a un tas d'utilisateurs. Chaque utilisateur peut se voir attribuer un module (l'ensemble du système est divisé en plusieurs parties appelées modules, à savoir le module Administration, le module Enquête, le module Commandes, le module Clients). En plus de cela, chaque module a une liste de fonctionnalités, qui peuvent être autorisées ou refusées pour chaque utilisateur. Ainsi, disons qu'un utilisateur, John Smith, a accès au module Commandes et peut modifier n'importe quelle commande, mais n'a pas le droit d'en supprimer une.

S'il y avait plus d'utilisateurs ayant la même compétence, j'utiliserais un groupe pour gérer cela. Je regrouperais ces utilisateurs dans un même groupe et j'attribuerais au groupe les droits d'accès aux modules et à leurs fonctions. Tous les utilisateurs d'un même groupe auraient les mêmes droits d'accès.

Pourquoi l'appeler un groupe et non un rôle ? Je ne sais pas, je le ressens simplement comme ça. Il me semble que simplement cela n'a pas vraiment d'importance :] Mais j'aimerais quand même connaître la vraie différence.

Avez-vous des suggestions sur la raison pour laquelle il faudrait plutôt parler de rôle que de groupe ou l'inverse ?

Answer 1

Google est votre ami :)

Quoi qu'il en soit, la distinction entre rôle et groupe provient des concepts de sécurité informatique (par opposition à la simple gestion des ressources). Le professeur Ravi Sandhu fournit une couverture séminale de la différence sémantique entre les rôles et les groupes.

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

Un groupe est une collection d'utilisateurs avec un ensemble donné de permissions attribuées au groupe (et de manière transitive, aux utilisateurs). Un rôle est un ensemble de permissions, et un utilisateur hérite effectivement de ces permissions lorsqu'il agit sous ce rôle.

En règle générale, votre appartenance à un groupe reste valable pendant toute la durée de votre connexion. Un rôle, par contre, peut être activé selon des conditions spécifiques. Si votre rôle actuel est "personnel médical", vous pourrez peut-être consulter certains des dossiers médicaux d'un patient donné. Si, toutefois, votre rôle est également "médecin", vous pourrez consulter des informations médicales supplémentaires, au-delà de ce que peut voir une personne ayant uniquement le rôle de "personnel médical".

Les rôles peuvent être activés selon l'heure de la journée, le lieu d'accès. Les rôles peuvent également être améliorés/associés à des attributs. Vous pouvez opérer en tant que "médecin", mais si vous n'avez pas d'attribut "médecin principal" ou de relation avec moi (un utilisateur ayant le rôle de "patient"), vous ne pouvez pas voir l'intégralité de mon dossier médical.

Vous pourriez faire tout cela avec des groupes, mais là encore, les groupes ont tendance à se concentrer sur l'identité, et non sur le rôle ou l'activité. Et le type d'aspects de sécurité que nous venons de décrire tend à s'aligner davantage sur ces derniers que sur les premiers.

Dans de nombreux cas, pour l'usage de classer les choses ensemble (et rien de plus), les groupes et les rôles fonctionnent de la même manière. Les groupes, cependant, sont basés sur l'identité, alors que les rôles sont destinés à délimiter l'activité. Malheureusement, les systèmes d'exploitation ont tendance à brouiller la distinction, en traitant les rôles comme des groupes.

La distinction est beaucoup plus nette avec les rôles au niveau de l'application ou du système, qui comportent une sémantique propre à l'application ou au système (comme dans le cas de la fonction Rôles d'Oracle ) - par opposition aux "rôles" mis en œuvre au niveau du système d'exploitation (qui sont généralement synonymes de groupes).

Il peut y avoir des limites aux rôles et aux modèles de contrôle d'accès basés sur les rôles (comme pour tout, bien sûr) :

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

Il y a une dizaine d'années, j'ai vu des recherches sur le contrôle d'accès basé sur les attributs et les relations, qui offrent une bien meilleure granularité que le contrôle d'accès basé sur les rôles. Malheureusement, je n'ai pas vu beaucoup d'activité dans ce domaine depuis des années.

La différence la plus importante entre les rôles et les groupes est que les rôles mettent généralement en œuvre un mécanisme de contrôle d'accès obligatoire (MAC). Vous ne pouvez pas vous affecter (ou affecter d'autres personnes) à des rôles. Un administrateur de rôle ou un ingénieur de rôle s'en charge.

Cela ressemble superficiellement aux groupes UNIX où un utilisateur peut/peut être en mesure de s'assigner à un groupe (via sudo bien sûr.) Lorsque les groupes sont assignés selon un processus d'ingénierie de sécurité, la distinction s'estompe un peu, cependant.

Une autre caractéristique importante est que les véritables modèles RBAC peuvent fournir le concept de rôles mutuellement exclusifs. En revanche, les groupes basés sur l'identité sont additifs - l'identité d'un principal est la somme (ou la conjonction) des groupes.

Une autre caractéristique d'un modèle de sécurité basé sur un vrai RBAC est que les éléments créés pour un rôle particulier ne peuvent généralement pas être accédés de manière transitive par quelqu'un qui n'agit pas sous ce rôle.

D'autre part, dans le cadre d'un modèle de contrôle d'accès discrétionnaire (DAC) (le modèle par défaut dans Unix), vous ne pouvez pas obtenir ce type de garantie avec les groupes seuls. BTW, il ne s'agit pas d'une limitation des groupes ou d'Unix, mais d'une limitation des modèles de DAC basés sur l'identité (et de manière transitive, avec les groupes basés sur l'identité).

J'espère que cela vous aidera.

\=======================

J'en rajoute après avoir vu la réponse bien construite de Simon. Les rôles vous aident à gérer les permissions. Les groupes vous aident à gérer les objets et les sujets. En outre, on peut considérer les rôles comme des "contextes". Un rôle "X" peut décrire un contexte de sécurité qui régit la façon dont le sujet Y accède (ou n'accède pas) à l'objet Z.

Une autre distinction importante (ou idéal) est qu'il existe un ingénieur de rôle, une personne qui conçoit les rôles, les contextes, qui sont nécessaires et/ou évidents dans une application, un système ou un OS. Un ingénieur de rôle est généralement (mais pas nécessairement) également un administrateur de rôle (ou sysadmin). De plus, le véritable rôle (sans jeu de mots) d'un ingénieur de rôle se situe dans le domaine de l'ingénierie de la sécurité, et non de l'administration.

Il s'agit d'un nouveau groupe formalisé par RBAC (même s'il est rarement utilisé), qui n'est généralement pas présent dans les systèmes à capacité de groupe.

Answer 2

Un groupe est un moyen d'organiser les utilisateurs, alors qu'un rôle est généralement un moyen d'organiser les droits.

Cela peut être utile à plusieurs égards. Par exemple, un ensemble d'autorisations regroupées dans un rôle peut être attribué à un ensemble de groupes, ou à un ensemble d'utilisateurs indépendamment de leur groupe.

Par exemple, un CMS peut avoir des permissions telles que Read post, Create post, Edit post. Un rôle d'éditeur peut être en mesure de lire et de modifier, mais pas de créer (je ne sais pas pourquoi !). Un article peut être autorisé à créer et à lire, etc. Un groupe de gestionnaires peut avoir le rôle d'éditeur, tandis qu'un utilisateur du service informatique, qui ne fait pas partie du groupe des gestionnaires, peut également avoir le rôle d'éditeur, même si le reste de son groupe ne l'a pas.

Ainsi, si dans un système simple, les groupes et les rôles sont souvent étroitement alignés, ce n'est pas toujours le cas.

Answer 3

Bien qu'il existe une différence sémantique entre les rôles et les groupes (comme décrit ci-dessus par d'autres réponses), techniquement les rôles et les groupes semblent être les mêmes. Rien ne vous empêche d'attribuer des permissions directement aux utilisateurs et aux groupes (cela peut être considéré comme un contrôle d'accès plus fin). De manière équivalente, lorsqu'un utilisateur se voit attribuer un rôle, il peut être considéré comme un membre du rôle, de la même manière qu'un utilisateur devient membre d'un groupe.

On peut donc se retrouver sans réelle différence entre les rôles et les groupes. Les deux peuvent être considérés pour regrouper des utilisateurs ET/OU des autorisations. La différence n'est donc que sémantique : - s'il est sémantiquement utilisé pour regrouper des permissions, il s'agit alors d'un rôle ; - s'il est utilisé sémantiquement pour regrouper des utilisateurs, il s'agit alors d'un groupe. Techniquement, il n'y a pas de différence.

Answer 4

REMARQUE - les divagations suivantes n'ont de sens que si l'on tente d'imposer la sécurité au sein d'une organisation - c'est-à-dire de limiter l'accès aux informations...

Les groupes sont empiriques - ils répondent à la question du "quoi". Ils sont le "est" dans le sens où ils reflètent la réalité existante de l'accès. Les informaticiens adorent les groupes - ils sont très concrets et faciles à définir. En fin de compte, tout contrôle d'accès se résume (comme nous l'avons tous appris à l'école primaire...) à répondre à la question "À quel groupe appartenez-vous ?".

Les rôles, en revanche, sont plus normatifs - ils guident ce qui "devrait être". Les bons managers et les RH aiment les "rôles" - ils ne répondent pas - ils demandez à la question du "Pourquoi ?" Malheureusement, les rôles peuvent aussi être vagues et ce "flou" peut rendre les gens (de l'informatique) fous.

Pour reprendre l'exemple médical ci-dessus, si le rôle de "médecin de soins primaires" a plus de droits (c'est-à-dire qu'il a accès à plus de groupes) que le rôle d'un "technicien en radiologie", c'est parce que des personnes (managers et RH) ont décidé pourquoi qui devait se produire. En ce sens, ils sont "la sagesse collective" d'une organisation.

Disons qu'un médecin a accès (en tant que membre d'un groupe y ayant accès) aux dossiers financiers de ses patients. Cela ne fait normalement pas partie du "rôle" d'un médecin et devrait être débattu. Ainsi, personne (aussi qualifié soit-il) ne devrait avoir un accès complet à tous les groupes - cela favorise les abus de pouvoir. C'est pourquoi l'"ingénierie des rôles" est si importante - sans elle, l'accès aux groupes est distribué comme un bonbon. Les gens vont collectionner (et parfois horde) l'accès aux groupes sans aucune discussion sur les dangers d'un trop grand pouvoir.

En conclusion, la sagesse de rôles bien définis permet de modérer les dangers d'un accès fugitif au groupe. N'importe qui dans une organisation peut demander l'accès à un groupe particulier. Mais une fois que cet accès est accordé, il est rarement abandonné. L'ingénierie des rôles (ainsi que les meilleures pratiques telles que des descriptions de groupes bien définies et des gestionnaires d'accès aux groupes habilités) peut limiter les conflits d'intérêts au sein d'une organisation, décentraliser la prise de décision et contribuer à rendre la gestion de la sécurité plus rationnelle.

Answer 5

Les utilisateurs sont affectés à des rôles en fonction de la responsabilité qu'ils assument dans un système. Par exemple, les utilisateurs ayant le rôle de directeur des ventes peuvent effectuer certaines actions telles que l'octroi d'une remise supplémentaire pour un produit.

Les groupes sont utilisés pour "regrouper" les utilisateurs ou les rôles dans un système afin de faciliter la gestion de la sécurité. Par exemple, un groupe nommé "Leadership Group" peut compter parmi ses membres des gestionnaires, des directeurs et des architectes, ainsi que des utilisateurs individuels n'ayant pas ces rôles. Vous devriez maintenant être en mesure d'attribuer certains privilèges à ce groupe.