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.