Grupo vs rol (¿Alguna diferencia real?)


126

¿Alguien puede decirme cuál es la verdadera diferencia entre grupo y rol? He estado tratando de resolver esto por algún tiempo y mientras más información leo, más tengo la sensación de que esto se menciona solo para confundir a las personas y no hay una diferencia real. Ambos pueden hacer el trabajo del otro. Siempre he usado un grupo para administrar usuarios y sus derechos de acceso.

Recientemente, me encontré con un software de administración, donde hay un montón de usuarios. Cada usuario puede haber asignado un módulo (todo el sistema se divide en unas pocas partes llamadas módulos, es decir, módulo de administración, módulo de encuesta, módulo de pedidos, módulo de cliente). Además, cada módulo tiene una lista de funcionalidades que se pueden permitir o denegar para cada usuario. Entonces, digamos, un usuario John Smith puede acceder a las Órdenes del módulo y puede editar cualquier orden, pero no tiene derecho a eliminar ninguna de ellas.

Si hubiera más usuarios con la misma competencia, usaría un grupo para administrar eso. Agregaría dichos usuarios al mismo grupo y asignaría derechos de acceso a los módulos y sus funciones al grupo. Todos los usuarios en el mismo grupo tendrían los mismos derechos de acceso.

¿Por qué llamarlo grupo y no rol? No sé, simplemente lo siento así. Me parece que simplemente no importa:] Pero todavía me gustaría saber la verdadera diferencia.

¿Alguna sugerencia de por qué esto debería llamarse rol más que grupo o al revés?



VEA EL DUPLICADO mencionado anteriormente. Sus dos respuestas cortas superiores son mejores que cualquiera de las que se encuentran aquí. (+ técnicamente los grupos y roles funcionan de la misma manera que se usan)
FastAl

2
No estoy de acuerdo con @FastAl, encontré las respuestas a esta pregunta mejor que las del duplicado.
Alex Oliveira

Respuestas:


148

Google es tu amigo :)

De todos modos, la división entre el rol y el grupo proviene de los conceptos de seguridad informática (en oposición a la simple gestión de recursos). El Prof. Ravi Sandhu ofrece una cobertura seminal de la diferencia semántica entre roles y grupos.

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

Un grupo es una colección de usuarios con un conjunto dado de permisos asignados al grupo (y transitivamente, a los usuarios). Un rol es una colección de permisos, y un usuario efectivamente hereda esos permisos cuando actúa bajo ese rol.

Por lo general, su membresía de grupo permanece durante la duración de su inicio de sesión. Un rol, por otro lado, se puede activar de acuerdo con condiciones específicas. Si su función actual es 'personal médico', es posible que pueda ver algunos de los registros médicos de un paciente determinado. Sin embargo, si su función también es "médico", es posible que pueda ver información médica adicional más allá de lo que puede ver una persona con solo una función de "personal médico".

Los roles se pueden activar por hora del día, ubicación de acceso. Los roles también se pueden mejorar / asociar con atributos. Es posible que esté operando como 'médico', pero si no tiene un atributo o relación de 'médico primario' conmigo (un usuario con el rol de 'paciente'), entonces no puede ver mi historial médico completo.

Podría hacer todo eso con grupos, pero nuevamente, los grupos tienden a centrarse en la identidad, no en el rol o la actividad. Y el tipo de aspectos de seguridad que acabamos de describir tienden a alinearse mejor con el posterior que con el primero.

En muchos casos, para el uso de clasificar cosas juntas (y nada más), los grupos y roles funcionan de la misma manera. Los grupos, sin embargo, se basan en la identidad, mientras que los roles están destinados a demarcar la actividad. Desafortunadamente, los sistemas operativos tienden a difuminar la distinción, tratando los roles como grupos.

Verá una distinción mucho más clara con los roles de aplicación o de nivel de sistema, que llevan semántica específica de la aplicación o del sistema (como en los roles de Oracle ), en oposición a los 'roles' implementados en el nivel del sistema operativo (que generalmente son sinónimos de grupos).

Puede haber limitaciones para los roles y los modelos de control de acceso basados ​​en roles (como con cualquier cosa, por supuesto):

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

Hace aproximadamente una década, vi algunas investigaciones sobre el control de acceso basado en atributos y relaciones que proporcionan una granularidad mucho mejor que el control de acceso basado en roles. Desafortunadamente, no he visto mucha actividad en ese reino en años.

La diferencia más importante entre roles y grupos es que los roles típicamente implementan un mecanismo de control de acceso obligatorio (MAC). No puedes asignarte (u otros) a roles. Un administrador de roles o ingeniero de roles hace eso.

Esto es superficialmente similar a los grupos UNIX donde un usuario puede / podría asignarse a un grupo (a través de sudo, por supuesto). Sin embargo, cuando los grupos se asignan de acuerdo con un proceso de ingeniería de seguridad, la distinción se confunde un poco.

Otra característica importante es que los verdaderos modelos RBAC pueden proporcionar el concepto de roles mutuamente excluyentes. En contraste, los grupos basados ​​en la identidad son aditivos: la identidad de un director es la suma (o conjunción) de los grupos.

Otra característica de un modelo de seguridad basado en RBAC verdadero es que los elementos creados para un rol particular generalmente no pueden ser accedidos de manera transitiva por alguien que no actúa bajo ese rol.

Por otro lado, bajo un modelo de control de acceso discrecional (DAC) (el modelo predeterminado en Unix), no puede obtener ese tipo de garantía solo con grupos. Por cierto, esto no es una limitación de grupos o Unix, sino una limitación de modelos DAC basados ​​en identidad (y transitivamente, con grupos basados ​​en identidad).

Espero eso ayude.

=======================

Agregando un poco más después de ver la respuesta bien puesta de Simon. Los roles lo ayudan a administrar los permisos. Los grupos lo ayudan a administrar objetos y sujetos. Además, uno podría pensar en los roles como "contextos". Un rol 'X' puede describir un contexto de seguridad que determina cómo el sujeto Y accede (o no accede) al objeto Z.

Otra distinción importante (o ideal) es que hay un ingeniero de roles, una persona que diseña los roles, los contextos, que son necesarios y / o evidentes en una aplicación, sistema o sistema operativo. Un ingeniero de roles generalmente es (pero no tiene que ser) también un administrador de roles (o administrador de sistemas). Además, el verdadero rol (sin juego de palabras) de un ingeniero de roles está en el ámbito de la ingeniería de seguridad, no de la administración.

Este es un grupo novedoso formalizado por RBAC (incluso si rara vez se usa), uno que típicamente no ha estado presente con sistemas aptos para grupos.


44
Básicamente, lo que está diciendo es que: si obtiene la lista de permisos de un grupo, está viendo el rol y si obtiene la lista de usuarios de un rol, está viendo un grupo.
Natim

No. Lo que sucede es que muchos sistemas implementan roles como grupos (o peor, llaman a los grupos "roles"). Cuando eso sucede, ve la equivalencia que acaba de describir. Déjame ver si puedo explicar esto mejor con una respuesta de seguimiento.
luis.espinal

Una de las principales diferencias es que la pertenencia a un grupo permanece independientemente de su sesión (su sesión de registro). Su pertenencia a un grupo cambia solo cuando alguien (usted o alguien con privilegios suficientes) lo cambia.
luis.espinal

Un rol, no una noción grupal vendida como un "rol", sino un rol verdadero, ese rol se asocia al director (también conocido como "el rol activo") cuando el director inicia una sesión (sesión de inicio de sesión o sesión específica de la aplicación) bajo ese papel
luis.espinal

1
Analógicamente, ¿podemos decir que los grupos son como árboles y los roles son como etiquetas?
ton

26

Un grupo es un medio para organizar a los usuarios, mientras que un rol suele ser un medio para organizar los derechos.

Esto puede ser útil de varias maneras. Por ejemplo, un conjunto de permisos agrupados en un rol podría asignarse a un conjunto de grupos o a un conjunto de usuarios independientemente de su grupo.

Por ejemplo, un CMS puede tener algunos permisos como Leer publicación, Crear publicación, Editar publicación. Un rol de editor podría leer y editar, pero no crear (¡no sé por qué!). Una publicación puede crear y leer, etc. Un grupo de gerentes puede tener el rol de editor, mientras que un usuario en TI, que no está en el grupo de gerentes, también puede tener el rol de editor, aunque el resto de su personal El grupo no.

Entonces, si bien en un sistema simple los grupos y roles a menudo están estrechamente alineados, este no es siempre el caso.


Entonces, si lo entiendo bien, no puede asignar usuarios a roles, pero puede asignar usuarios a grupos. Después de eso, puede asignar roles al grupo de usuarios.
Ondrej

No necesariamente Ondrej. Una aplicación, sistema o sistema operativo puede implementar un mecanismo para asignar un usuario a un rol (sin embargo, puede ponerse difícil rápidamente). La respuesta de Simon es el clavo con papeles como medios para gestionar permisos (en oposición a grupos como medios para gestionar los sujetos y objetos.)
luis.espinal

Gracias chicos, ahora es mucho más claro para mí. En el sistema descrito anteriormente, acabo de darme cuenta, hay otro mecanismo para distinguir a los usuarios. Cada usuario asignado a cualquier módulo puede distinguirse más por su competencia como USUARIO, SUPERVISOR y ADMINISTRADOR, lo que supongo, este es el sistema ROLE:] ¡Una vez más, gracias a los dos! ;)
Ondrej

me gusta su explicación, pero por alguna razón aquí nadie escribió sobre la posibilidad de que un usuario pertenezca a más de un grupo ... ¿no es posible que los grupos pertenezcan a otros grupos y roles que permiten asignar roles, y qué acerca de los recursos? ¿No pueden los recursos pertenecer también a grupos? ¿No pueden los recursos tener roles?
desde el

19

Aunque existe una diferencia semántica entre Roles y Grupos (como se describe anteriormente en otras respuestas), técnicamente Roles y Grupos parece ser el mismo. Nada le impide asignar permisos directamente a usuarios y grupos (esto puede considerarse como un control de acceso de ajuste fino). De manera equivalente, cuando al Usuario se le asigna un Rol, se puede considerar un Rol Miembro, en el mismo sentido cuando el usuario se convierte en Miembro de un Grupo.

Entonces podemos terminar sin una diferencia real entre Roles y Grupos. Ambos pueden considerarse para agrupar Usuarios Y / O Permisos. Por lo tanto, la diferencia es solo semántica: si se usa semánticamente para agrupar permisos, entonces es un rol; - si se usa semánticamente para agrupar usuarios, entonces es un grupo. Técnicamente, no hay diferencia.


En realidad, existe una diferencia en los lenguajes de computadora, como c #, en las clases asignadas para acceder a los grupos en comparación con las de acceder a los roles. Tienen diferentes nombres de propiedades y diferentes métodos, como se espera de un rol (como un conjunto de permisos), frente a un grupo (como un conjunto de usuarios).
pashute

Si agrega un grupo como miembro de otro grupo y ambos tienen permisos asociados, los permisos aditivos funcionarían bien. Así es como funciona NTFS. Sin embargo, cuando hablamos de sistemas, creo que los usuarios piensan en términos de "déjenme iniciar sesión como financiero", "déjenme iniciar sesión como invitado", y en ese caso creo que los roles jerárquicos serían confusos. No permitiría que nada más que los grupos de nivel superior tengan permisos asociados.
drizin

18

Un "grupo" es una colección de usuarios. Un "rol" es una colección de permisos. Eso significa que cuando el grupo alfa incluye el grupo beta , alfa recibe a todos los usuarios de beta y beta recibe todos los permisos de alfa. Por el contrario, se podría decir que el rol beta incluye el rol alfa y se aplicarían las mismas conclusiones.

Un ejemplo concreto aclara las cosas. Considere "atención al cliente" y "atención al cliente senior". Si piensa en esas colecciones como grupos, está claro que los usuarios de atención al cliente "incluyen" a los usuarios senior de atención al cliente. Sin embargo, si los ve como roles, entonces está claro que los permisos de atención al cliente senior "incluyen" los permisos de atención al cliente.

En teoría, simplemente podría tener un tipo de colección. Sin embargo, sería ambiguo si dijeras que "colección alfa incluye colección beta" . En ese caso, no puede saber si los usuarios en alfa están en beta (como un rol) o si los usuarios en beta están en alfa (como un grupo). Para que la terminología como "incluye" y elementos visuales como las vistas en árbol no sean ambiguos, la mayoría de los sistemas rbac requieren que especifique si la colección en cuestión es un "grupo" o un "rol", al menos para el debate.

Algunas analogías pueden ayudar. Enmarcado en términos de teoría de conjuntos , cuando el grupo alfa es un subconjunto del grupo beta, los permisos alfa son un superconjunto de permisos beta. En comparación con la genealogía , si los grupos son como un árbol de descendientes, los roles son como un árbol de antepasados.


Su explicación cubre exactamente por qué no podemos simplemente tratar a los grupos como roles (como sugiere la respuesta de Mileta). Ejemplo perfecto.
drizin

2
En realidad, podemos tratar a los grupos como roles (como dice Mileta Cekovic ). Por ejemplo, podemos asignar un rol único para cada grupo (relación 1: 1). Pero no podemos interpretar las relaciones entre grupos como relaciones entre roles correspondientes. Por ejemplo, si el grupo "atención al cliente" incluye el grupo "atención al cliente senior", no significa que la función "atención al cliente" incluya la función "atención al cliente senior".
ruvim

3

NOTA: las siguientes divagaciones solo tienen sentido si uno está tratando de imponer seguridad dentro de una organización, es decir, tratando de limitar el acceso a la información ...

Los grupos son empíricos: responden la pregunta de "qué". Son el "es" en el sentido de que reflejan la realidad existente de acceso. Las personas de TI adoran los grupos: son muy literales y fáciles de definir. Finalmente, todo el control de acceso se convierte en última instancia (como todos aprendimos en la escuela secundaria ...) para responder la pregunta "¿A qué grupo pertenece?"

Sin embargo, los roles son más normativos: guían lo que "debería ser". Los buenos gerentes y los recursos humanos aman los "roles", no responden, hacen la pregunta "¿Por qué? Desafortunadamente, los roles también pueden ser vagos y esa "confusión" puede volver locos a las personas (TI).

Para utilizar el ejemplo médica anterior, si la función de "médico de cabecera" tiene más derechos (es decir, el acceso a más grupos) que el papel de un "técnico de rayos x", esto se debe a que las personas (directivos y HR) decidieron por eso que necesitaba suceder En ese sentido, son "la sabiduría colectiva" de una organización.

Digamos que un médico tiene acceso (membresía a un grupo con acceso) a los registros financieros de los pacientes. Esto normalmente está fuera del "papel" de un médico y debe debatirse. Por lo tanto, nadie (sin importar cuán calificado) debe tener acceso completo a todos los grupos: invita a los abusos al poder. Es por eso que la "ingeniería de roles" es tan importante: sin ella, solo tienes acceso grupal entregado como un dulce. Las personas recopilarán (y a veces hordearán) acceso grupal sin discusión sobre los peligros de tener demasiado poder.

Para concluir, la sabiduría de roles bien definidos ayuda a moderar los peligros del acceso grupal fuera de control. Cualquier persona en una organización puede solicitar el acceso a un grupo en particular. Pero una vez que se proporciona ese acceso, rara vez se renuncia. La ingeniería de roles (junto con las mejores prácticas, como descripciones de grupo bien definidas y gerentes de acceso de grupo habilitados) pueden limitar los conflictos de intereses dentro de una organización, descentralizar la toma de decisiones y ayudar a que la gestión de la seguridad sea más racional.


3

Las respuestas anteriores son todas maravillosas. Como se dijo, el concepto de Grupo vs Rol es más conceptual que técnico. Hemos tomado la postura de que los Grupos se usan para contener usuarios (un usuario puede estar en más de un grupo: es decir, Joe está en el grupo de Gerentes así como en el grupo de TI [él es un gerente en TI]) y para asignar amplios privilegios (es decir, nuestro sistema de tarjeta magnética permite a todos los usuarios del grupo de TI acceder a la sala de servidores). Ahora se usaban roles para agregar privilegios a usuarios específicos (es decir, las personas en el grupo de TI pueden RDP a los servidores pero no pueden asignar usuarios o cambiar permisos, las personas en el grupo de TI con el rol de Administrador pueden asignar usuarios y cambiar permisos). Los roles también pueden estar compuestos de otros roles (Joe tiene el rol de administrador para agregar usuarios / privilegios y también tiene el rol de DBA para realizar cambios en la base de datos al DBMS en el servidor). Los roles también pueden ser muy específicos, ya que podemos crear roles de usuario individuales (es decir, JoesRole) que pueden ser muy específicos para un usuario. Entonces, para recapitular, usamos Grupos para administrar usuarios y asignar Roles generales y Roles para administrar privilegios. Esto también es acumulativo. El Grupo en el que se encuentra el usuario puede tener Roles asignados (o una lista de Roles disponibles) que otorgarán privilegios muy generales (es decir, los usuarios del grupo de TI tienen el rol ServerRDP que les permite iniciar sesión en los servidores) para que se asigne al usuario. Luego, todos los Roles a los que pertenece el usuario se agregarán en el orden en que se definan, teniendo el último Rol el último en decir (los Roles pueden Permitir, Denegar o no aplicar privilegios, de modo que a medida que se aplique cada Rol anulará la configuración anterior para un privilegio o no cambiarlo). Una vez que se hayan aplicado todos los roles de nivel de grupo y los roles de nivel de usuario,


+1 por proporcionar un ejemplo muy real, ya que la superposición de estos conceptos significa que no hay una diferencia real excepto en implementaciones específicas. Sin embargo, no deja muy claras las ventajas que obtuvo al agregar roles: su ejemplo de usuarios de TI con el rol de administrador podría hacerse fácilmente colocando a los usuarios en los grupos de usuarios y administradores de TI . No existe una distinción real entre el "permiso" implícito permitido a RDP para "y el" rol ":" puede asignar usuarios ". También dice que los roles pueden estar hechos de otros roles, pero su ejemplo es Joe, que tiene 2 roles, no un rol que combine otros
Ruibarbo,

1

Los usuarios se asignan a Roles en función de la responsabilidad que desempeñan en cualquier sistema. Por ejemplo, los usuarios en rol de Sales Manager pueden realizar ciertas acciones, como proporcionar un descuento adicional para un producto.

Los grupos se utilizan para 'agrupar' usuarios o roles en un sistema para una fácil administración de la seguridad. Por ejemplo, un grupo llamado "Grupo de Liderazgo" puede tener sus miembros de Gerentes, Directores y Arquitectos de roles y usuarios individuales que también están fuera de estos roles. Ahora debería poder asignar ciertos privilegios a este grupo.


1

El propósito de los grupos y roles varía en las aplicaciones, pero principalmente lo que entendí es lo siguiente, los grupos (conjunto de usuarios) son estáticos, mientras que los roles (conjunto de permisos) son dinámicos con políticas, por ejemplo, basadas en el tiempo de (9 a 6) a grupo o usuario puede tener este rol pero no ese.


0

Puede asignar un rol al grupo. Puede asignar usuarios al grupo y puede asignar roles a usuarios individuales en cualquier usuario de roles. Sentido. Jean Doe puede estar en Group of SalesDeptartment con la función Off ReportWritter que permite imprimir nuestros informes desde SharePoint, pero en el grupo SalesDepartment, otros pueden no tener la función de ReportWritter. - En otras palabras, los roles son privilegios especiales dentro de los grupos asignados. Espero que esto haga alguna escena.

¡¡¡Salud!!!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.