Te sugerimos que pruebes esta solución en un entorno controlado antes de enviarlo a producción, saludos.
Solución:
Google es tu amigo 🙂
De todos modos, la división entre rol y grupo proviene de conceptos de seguridad informática (en contraposición a la simple administración de recursos). El profesor Ravi Sandhu ofrece una cobertura fundamental 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 determinado de permisos asignados al grupo (y, de manera transitiva, a los usuarios). Un rol es una colección de permisos, y un usuario hereda efectivamente esos permisos cuando actúa bajo ese rol.
Por lo general, la membresía de su 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 la de “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 attributes. Es posible que esté operando como ‘médico’, pero si no tiene un ‘médico de atención primaria’ attribute o relación conmigo (un usuario con el rol de ‘paciente’), entonces no puede ver mi historial médico completo.
Podrías hacer todo eso con grupos, pero nuevamente, los grupos tienden a enfocarse 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 los últimos que con los primeros.
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 y tratan los roles como grupos.
Verá una distinción mucho más clara con los roles a nivel de aplicación o sistema, que llevan la semántica específica de la aplicación o del sistema (como en los roles de Oracle), en oposición a los ‘roles’ implementados a 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 attribute-control de acceso basado en relaciones y que proporciona una granularidad mucho mejor que el control de acceso basado en roles. Desafortunadamente, no he visto mucha actividad en ese ámbito en años.
La diferencia más importante entre roles y grupos es que los roles generalmente implementan un mecanismo de control de acceso obligatorio (MAC). No puedes asignarte a ti mismo (ni a otros) roles. Un administrador de funciones o un ingeniero de funciones hace eso.
Esto es superficialmente similar a los grupos UNIX donde un usuario puede / podría ser capaz de asignarse a sí mismo 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 desdibuja un poco.
Otra característica importante es que true Los modelos RBAC pueden proporcionar el concepto de roles mutuamente excluyentes. Por el contrario, los grupos basados en la identidad son aditivos: la identidad de un principal es la suma (o conjunción) de los grupos.
Otra característica de un true-El modelo de seguridad basado en RBAC es que los elementos creados para un rol en particular normalmente 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 los grupos o Unix, sino una limitación de los modelos DAC basados en la identidad (y transitivamente, con los grupos basados en la identidad).
Espero eso ayude.
=======================
Añadiendo un poco más después de ver la respuesta bien expresada de Simon. Los roles le ayudan a administrar los permisos. Los grupos le ayudan a gestionar objetos y sujetos. Además, uno podría pensar en los roles como “contextos”. Un rol ‘X’ puede describir un contexto de seguridad que gobierna 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 funciones suele ser (pero no tiene por qué serlo) también un administrador de funciones (o administrador de sistemas). Además, el true El rol (sin juego de palabras) de un ingeniero de rol está en el ámbito de la ingeniería de seguridad, no en la administración.
Este es un grupo novedoso formalizado por RBAC (incluso si rara vez se usa), uno que generalmente no ha estado presente con sistemas con capacidad de grupo.
Un grupo es un medio para organizar a los usuarios, mientras que un rol suele ser un medio para organizar los derechos.
Esto puede resultar útil de varias formas. Por ejemplo, un conjunto de permisos agrupados en un rol podría asignarse a un conjunto de grupos, o 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. Una función de editor puede leer y editar, pero no crear (¡no sé por qué!). Una publicación puede ser capaz de Crear y Leer, etc. Un grupo de gerentes puede tener la función de editor, mientras que un usuario de TI, que no está en el grupo de gerentes, también puede tener la función de editor, aunque el resto de su el grupo no lo hace.
Entonces, aunque en un sistema simple los grupos y los roles a menudo están estrechamente alineados, este no es siempre el caso.
Aunque existe una diferencia semántica entre roles y grupos (como se describe anteriormente en otras respuestas), técnicamente los roles y los grupos parecen ser los mismos. Nada le impide asignar permisos directamente a usuarios y grupos (esto se puede considerar como un control de acceso de ajuste fino). De manera equivalente, cuando se asigna un rol al usuario, se puede considerar un miembro del rol, 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 se pueden considerar para agrupar Usuarios Y / O Permisos. Por tanto, la diferencia es sólo semántica: – si se utiliza semánticamente para agrupar Permisos, entonces es un Rol; – si se utiliza semánticamente para agrupar usuarios, entonces es un grupo. Técnicamente, no hay diferencia.
Al final de la página puedes encontrar las interpretaciones de otros programadores, tú igualmente tienes la libertad de insertar el tuyo si lo crees conveniente.