Groupe vs rôle (Une réelle différence?)
Quelqu'un peut-il me dire quelle est la vraie différence entre groupe et rôle? J'essaie de comprendre cela depuis un certain temps maintenant et plus je lisais d'informations, plus j'avais l'impression que tout cela était évoqué simplement pour dérouter les gens et qu'il n'y avait 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, qui regroupe de nombreux utilisateurs. Chaque utilisateur peut se voir attribuer un module (le système entier est divisé en plusieurs parties appelées modules, c.-à-d. Module Administration, module Enquête, module Commandes, module Client). De plus, chaque module contient une liste de fonctionnalités pouvant être autorisées ou refusées pour chaque utilisateur. Donc, disons, un utilisateur John Smith peut accéder aux ordres du module et peut éditer n’importe quel ordre, mais n’a pas le droit de les supprimer.
S'il y avait plus d'utilisateurs partageant la même compétence, j'utiliserais un groupe pour gérer cela. Je voudrais regrouper ces utilisateurs dans le même groupe et attribuer des droits d'accès aux modules et leurs fonctions au groupe. Tous les utilisateurs du même groupe auraient les mêmes droits d'accès.
Pourquoi appeler cela un groupe et non un rôle? Je ne sais pas, je me sens juste comme ça. Il me semble que cela n'a pas d'importance, simplement]: Mais j'aimerais quand même connaître la vraie différence.
Des suggestions pour lesquelles ceci devrait s'appeler plutôt rôle que groupe ou l'inverse?
Google est ton ami :)
Quoi qu’il en soit, la division entre le rôle et le groupe provient des concepts de sécurité informatique (par opposition à la simple gestion des ressources). Le professeur Ravi Sandhu fournit une couverture fondamentale de la différence sémantique entre les rôles et les groupes.
http://profsandhu.com/workshop/role-group.pdf
Un groupe est un ensemble d'utilisateurs avec un ensemble donné d'autorisations attribuées au groupe (et de manière transitoire aux utilisateurs). Un rôle est une collection d'autorisations, et un utilisateur hérite effectivement de ces autorisations lorsqu'il agit sous ce rôle.
En règle générale, votre appartenance à un groupe reste en place pendant la durée de votre connexion. Un rôle, en revanche, peut être activé en fonction de conditions spécifiques. Si votre rôle actuel est celui de "personnel médical", vous pourrez peut-être consulter certains dossiers médicaux d'un patient donné. Si, toutefois, votre rôle est également de "médecin", vous pourrez peut-être voir des informations médicales supplémentaires, au-delà de ce qu'une personne avec juste un rôle de "personnel médical" peut voir.
Les rôles peuvent être activés par heure de la journée, lieu d'accès. Les rôles peuvent également être améliorés/associés à des attributs. Vous opérez peut-être en tant que "médecin", mais si vous n'avez pas d'attribut de "médecin principal" ni de relation avec moi (un utilisateur avec le rôle de "patient"), vous ne pouvez pas voir l'intégralité de mes antécédents médicaux.
Vous pouvez faire tout cela avec des groupes, mais encore une fois, les groupes ont tendance à se concentrer sur l'identité, pas sur le rôle ou l'activité. Et les types de sécurité que nous venons de décrire tendent à s’aligner mieux avec les derniers que avec les premiers.
Dans de nombreux cas, 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émarquer l'activité. Malheureusement, les systèmes d'exploitation ont tendance à estomper la distinction, en traitant les rôles comme des groupes.
Vous constatez une distinction beaucoup plus nette entre les rôles au niveau de l’application ou du système - comportant une sémantique spécifique à l’application ou au système (comme dans rôles Oracle ) - par opposition aux "rôles" implémentés au niveau du système d’exploitation (qui sont généralement utilisés). synonyme de groupes.)
Il peut y avoir des limitations aux rôles et aux modèles de contrôle d'accès basés sur les rôles (comme avec n'importe quoi bien sûr):
http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
Il y a environ une décennie, j'ai assisté à des recherches sur le contrôle d'accès basé sur les attributs et les relations, qui fournissent une granularité bien supérieure au 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 implémentent généralement un mécanisme de contrôle d'accès obligatoire (MAC). Vous n'obtenez pas vous-même (ou d'autres) attribuer des rôles. Un administrateur de rôle ou un ingénieur de rôle fait cela.
Ceci est superficiellement similaire aux groupes UNIX dans lesquels un utilisateur peut/pourrait être capable de s’affecter lui-même à un groupe (via Sudo bien sûr). Lorsque des groupes sont affectés en fonction d’un processus d’ingénierie de la sécurité, la distinction est toutefois un peu floue.
Une autre caractéristique importante est que les vrais 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é du principal est la somme (ou la conjonction) des groupes.
Une autre caractéristique d'un modèle de sécurité basé sur un contrôle RBAC réel est que les éléments créés pour un rôle particulier ne peuvent généralement pas être accessibles de manière transitoire par une personne qui n'agit pas sous ce rôle.
D'autre part, sous un modèle de contrôle d'accès discrétionnaire (DAC) (le modèle par défaut sous Unix), vous ne pouvez pas obtenir ce type de garantie avec des groupes uniquement. En passant, ce n’est pas une limitation de groupes ou Unix, mais une limitation de modèles DAC basés sur l’identité (et de manière transitoire avec des groupes basés sur l’identité).
J'espère que ça aide.
========================
Ajoutant un peu plus après avoir vu la réponse bien posée de Simon. Les rôles vous aident à gérer les autorisations. Les groupes vous aident à gérer les objets et les sujets. De plus, les rôles pourraient être considérés comme des "contextes". Un rôle 'X' peut décrire un contexte de sécurité qui détermine comment le sujet Y accède (ou non) à l'objet Z.
Une autre distinction importante (ou idéale) est la présence d’un ingénieur des rôles, une personne qui conçoit les rôles, les contextes nécessaires et/ou évidents dans une application, un système ou un système d’exploitation. Un ingénieur de rôle est généralement (mais ne doit pas nécessairement être) également un administrateur de rôle (ou administrateur système). De plus, le véritable rôle (sans jeu de mots) de l'ingénieur rôle est dans le domaine de l'ingénierie de la sécurité, pas de l'administration.
Il s'agit d'un nouveau groupe formalisé par RBAC (même s'il est rarement utilisé) et qui n'a généralement pas été présent avec des systèmes capables de gérer des groupes.
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 autorisations telles que Lire un article, Créer un article, Modifier un article. Un rôle d’éditeur peut être capable de lire et d’éditer, mais pas de créer (je ne sais pas pourquoi!). Un poste peut créer et lire, etc. Un groupe de gestionnaires peut avoir le rôle d’éditeur, tandis qu’un utilisateur informatique qui n’appartient pas au groupe des gestionnaires peut également avoir le rôle d’éditeur, même si le reste de ses fonctions est activé. pas le groupe.
Ainsi, dans un système simple, les groupes et les rôles sont souvent étroitement alignés, mais ce n'est pas toujours le cas.
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 autorisations directement aux utilisateurs et aux groupes (cela peut être considéré comme un contrôle d'accès optimisé). De manière équivalente, lorsqu'un rôle est attribué à un utilisateur, celui-ci peut être considéré comme un membre du rôle, au même sens lorsque l'utilisateur devient membre d'un groupe.
Nous pouvons donc nous retrouver sans réelle différence entre les rôles et les groupes. Les deux peuvent être pris en compte pour regrouper les utilisateurs ET/OU les autorisations. Ainsi, la différence n’est que sémantique: - si elle est utilisée sémantiquement pour regrouper des autorisations, 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.
Un "groupe" est un ensemble d'utilisateurs. Un "rôle" est une collection d'autorisations. Cela signifie que lorsque le groupe alpha comprend le groupe bêta, alpha reçoit tous les utilisateurs de la bêta et bêta reçoit toutes les autorisations de alpha. Inversement, vous pourriez dire le rôle bêta comprend le rôle alpha et les mêmes conclusions s’appliqueraient.
Un exemple concret rend les choses plus claires. Considérez "support client" et "support client senior". Si vous considérez ces collections comme des groupes, il est clair que les utilisateurs du support client "incluent" les utilisateurs principaux du support client. Toutefois, si vous les considérez comme des rôles, il est clair que les autorisations de support client supérieur "incluent" les autorisations de support client.
En théorie, vous pourriez simplement avoir un type de collection. Cependant, il serait ambigu si vous disiez que "collection alpha inclut collection beta". Dans ce cas, vous ne pouvez pas savoir si les utilisateurs en alpha sont en version bêta (comme un rôle) ou si les utilisateurs en bêta sont en alpha (comme un groupe). Afin de rendre les termes tels que "inclut" et les éléments visuels tels que les vues d'arborescence non ambigües, la plupart des systèmes rbac vous demandent de préciser si la collection en question est un "groupe" ou un "rôle", du moins aux fins de la discussion.
Quelques analogies pourraient aider. Encadré en termes de théorie des ensembles, lorsque le groupe alpha est un sous-ensemble du groupe bêta, les autorisations alpha constituent un sur-ensemble d'autorisations bêta. Comparé à généalogie, si les groupes ressemblent à un arbre de descendants, les rôles ressemblent à un arbre d'ancêtres.
Les réponses précédentes sont toutes merveilleuses. Comme il a été dit, le concept de groupe vs rôle est plus conceptuel que technique. Nous avons adopté la position selon laquelle les groupes sont utilisés pour contenir des utilisateurs (un utilisateur peut appartenir à plusieurs groupes: par exemple, Joe fait partie du groupe des gestionnaires ainsi que du groupe informatique [il est un responsable informatique]) et pour l'attribution de privilèges étendus. (Par exemple, notre système de carte à puce permet à tous les utilisateurs du groupe informatique d'accéder à la salle des serveurs). Les rôles étaient désormais utilisés pour ajouter des privilèges à des utilisateurs spécifiques (c.-à-d. Que les personnes du groupe informatique peuvent RDP sur les serveurs mais ne peuvent pas affecter d'utilisateurs ni modifier les autorisations, les personnes du groupe informatique dotées du rôle Admin peuvent affecter des utilisateurs et modifier les autorisations). Les rôles peuvent également être composés d'autres rôles (Joe a le rôle d'administrateur pour ajouter des utilisateurs/privilèges et le rôle d'administrateur de base de données pour modifier la base de données du SGBD sur le serveur). Les rôles peuvent également être très spécifiques car nous pouvons créer des rôles individuels (par exemple, JoesRole) pouvant être très spécifiques pour un utilisateur. Ainsi, pour récapituler, nous utilisons des groupes pour gérer les utilisateurs et attribuer des rôles généraux et des rôles pour gérer les privilèges. C'est aussi cumulatif. Des rôles peuvent être attribués au groupe dans lequel se trouve l'utilisateur (ou une liste des rôles disponibles) qui donneront des privilèges très généraux (c'est-à-dire que les utilisateurs du groupe informatique ont le rôle ServerRDP qui leur permet de se connecter aux serveurs) afin d'être attribué à l'utilisateur. Tous les rôles auxquels l'utilisateur appartient seront ajoutés dans l'ordre dans lequel ils ont été définis, le dernier rôle ayant le dernier mot (les rôles peuvent autoriser, refuser ou ne pas appliquer les privilèges, de sorte que chaque rôle appliqué remplace les paramètres précédents pour un privilège. ou ne pas le changer). Une fois que tous les rôles de groupe et d'utilisateur ont été appliqués, un modèle de sécurité distinct est créé pour l'utilisateur. Il peut être utilisé dans tous nos systèmes pour déterminer l'accès et les fonctionnalités.
NOTE - Les divagations suivantes n’ont de sens que si l’on essaie d’imposer la sécurité au sein d’une organisation, c’est-à-dire de limiter l’accès à l’information ...
Les groupes sont empiriques - ils répondent à la question de "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 littéraux et faciles à définir. Finalement, tout contrôle d’accès revient finalement (comme nous l’avons tous appris à l’école intermédiaire ...) à répondre à la question "À quel groupe appartenez-vous?"
Les rôles, cependant, sont plus normatifs - ils guident ce que "devrait être". Les bons gestionnaires et les ressources humaines adorent les "rôles" - ils ne répondent pas - ils demandent la question de "Pourquoi?" Malheureusement, les rôles peuvent également être vagues et ce "flou" peut rendre fou (IT) les gens.
Pour utiliser l'exemple médical ci-dessus, si le rôle de "médecin de soins primaires" a plus de droits (accès à plus de groupes) que le rôle d'un "technicien en radiologie ", c’est parce que les gens (gestionnaires et RH) ont décidé pourquoi que cela devait arriver. En ce sens, ils sont "la sagesse collective" d'une organisation.
Supposons qu'un médecin ait accès (accès à un groupe avec accès) aux archives financières des patients. Ceci est normalement en dehors du "rôle" du médecin et devrait être débattu. Donc, personne (peu importe sa qualification) ne devrait avoir un accès complet à tous les groupes - cela invite les abus au pouvoir. C'est pourquoi "l'ingénierie des rôles" est si importante - sans cela, vous disposez simplement d'un accès de groupe distribué comme autant de bonbons. Les gens vont collecter (et parfois regrouper) l'accès au groupe sans discussion sur les dangers d'un excès de pouvoir.
Pour conclure, la sagesse de rôles bien définis contribue à atténuer les dangers d'un accès de groupe incontrôlable. Toute personne dans une organisation peut demander l'accès à un groupe particulier. Mais une fois que cet accès est fourni, il est rarement abandonné. L'ingénierie des rôles (ainsi que les meilleures pratiques telles que des descriptions de groupe bien définies et des gestionnaires d'accès de groupe habilités) peut limiter les conflits d'intérêts au sein d'une organisation, décentraliser la prise de décision et aider à rendre la gestion de la sécurité plus rationnelle.
Les utilisateurs sont affectés à des rôles en fonction de la responsabilité qu'ils jouent dans n'importe quel système. Par exemple, les utilisateurs du rôle Sales Manager peuvent effectuer certaines actions, telles que l’offre d’une remise supplémentaire pour un produit.
Les groupes sont utilisés pour "grouper" des utilisateurs ou des rôles dans un système afin de faciliter la gestion de la sécurité. Par exemple, un groupe nommé "groupe de direction" peut être composé de responsables, de directeurs et d'architectes, ainsi que d'utilisateurs individuels ne faisant pas partie de ces rôles. Vous devriez maintenant pouvoir attribuer certains privilèges à ce groupe.
La fonction des groupes et des rôles varie selon les applications, mais ce que j’ai compris comme suit est généralement la suivante: les groupes (ensemble d’utilisateurs) sont statiques, tandis que les rôles (ensemble d’autorisations) sont dynamiques avec des stratégies, basées par exemple sur le temps (9 à 6) a groupe ou utilisateur peut avoir ce rôle mais pas celui.
Vous pouvez affecter un rôle à un groupe. Vous pouvez affecter un utilisateur à un groupe et un rôle à un utilisateur individuel. Sens. Jean Doe peut être dans Group of SalesDeptartment avec le rôle de ReportWritter, ce qui permet d’imprimer nos rapports à partir de SharePoint. Toutefois, dans le groupe SalesDepartment, d’autres peuvent ne pas avoir le rôle de ReportWritter. - En d'autres termes, les rôles sont des privilèges spéciaux avec les groupes attribués. J'espère que cela fait des scènes.
À votre santé!!!