Control de acceso: ¿vale la pena implementar RBAC en un sistema jerárquico de administración de usuarios?

Question

Últimamente he estado considerando el mejor modelo de control de acceso para usar en mi aplicación. He estado leyendo en RBAC y el concepto de función es bueno (especialmente si tiene una gran cantidad de permisos diferentes), sin embargo, no estoy seguro de qué tan aplicable es para la administración jerárquica de usuarios como la siguiente:

Every el usuario pertenece a uno o más grupos. Los grupos están organizados en un árbol (como una estructura de directorio). Tanto a los grupos como a los usuarios se les pueden asignar permisos (o roles, si hablamos de RBAC) y probablemente debería haber algún tipo de herencia (es decir, los usuarios y grupos heredan los permisos de los grupos a los que pertenecen) y la funcionalidad de anulación. El propósito de los grupos en sí no es gestión de permisos: tendrán otros usos en la aplicación.

Imagino todo lo anterior no sería demasiado problemático para diseñar y poner en práctica más si se utilizaron permisos sin papeles ("funciones" son colecciones de permisos en la terminología RBAC) desde permisos son muy granular mientras que los roles son más monolítico. La implementación de la herencia/anulación de permisos a nivel de grupo/usuario no sería demasiado difícil. Hacer lo mismo con los roles probablemente sea más complicado, pero, por otro lado, los roles son más fáciles de entender para un usuario promedio.

En este momento, me estoy inclinando más hacia el modelo de "permisos sólo" porque:

• la aplicación probablemente no tendrá más de 30 permisos diferentes;
• grupos mismos se pueden usar para establecer los permisos que ya proporciona una de las ventajas de los roles - la facilidad de gestión de permisos de múltiples usuarios
• el concepto parece claro y por lo tanto fácil de implementar

Sin embargo, si se presentó un modelo lógico y fácilmente comprensible basado en roles que tenía una ventaja sobre la de "solo permisos", la analizaría seriamente. ¿Existen modelos de RBAC bien definidos (documentos, implementaciones, etc.) ya disponibles que podrían aplicarse/adaptarse a los requisitos anteriores (los he estado buscando por algún tiempo, pero los que encontré eran demasiado restrictivos o inexistentes? tomar en cuenta la gestión jerárquica de usuarios)? ¿Cuál es su opinión general sobre el asunto? ¿RBAC vale la pena en este caso?

Answer 1

Creo que un sistema RBAC básico es tan simple como simplemente usar un sistema de permisos.

Tenga en cuenta que el término 'rol' en RBAC es algo que podría limitar la implementación. Lo que quiero decir con esto es que un sistema RBAC tradicional tiene reglas típicas como esto:

allow (a) role (to do an) action (on an) object 

En pseudocódigo que podría tener un método como este:

myRbac.allow(Member, View, Post) 

Hay, sin embargo, no hay nada que le impida de los roles de abstracción. Un rol típicamente es un nombre de cadena. Con ese nombre de cadena también puede nombrar a sus grupos y usuarios. 'Role' basado entonces permite mucho más que roles si lo usa creativamente. Llámalo basado en Objetos u otra cosa, pero esencialmente es lo mismo: permites que algo actúe sobre algo.

allow (an) object (to do an) action (on an) object 

Si se mira desde este punto de vista de su aplicación será, en mi humilde opinión, ser lo suficientemente simple como para justificar el costo de implementación. No permita que el término 'rol' limite la simplicidad que puede tener la implementación. Y si puedes implementarlo así de simple, ¿por qué no ir por eso?

Parece que sabes PHP. Si echas un vistazo a Zend Framework ACL, verás una implementación basada en roles. Quizás eso te inspire.

editar: sobre la jerarquía: No es difícil implementar la jerarquía para los roles (objeto o nombres por extensión). Compruebe si hay reglas para el objeto-acción-objeto solicitado. Si no hay ninguno, suba en la jerarquía hasta que tenga permitido o denegado. Si un usuario puede tener más de un rol (por ejemplo, el rol de miembro y está en Administradores de grupo (también conocido como el rol llamado Grupo de Administrador)) debe elegir si un denegar invalida un permiso o viceversa. Prefiero tener la ganancia permitida cuando los niveles son paralelos (por ejemplo, se permite una acción para el rol A pero se niega para el rol B, nuestro usuario tiene tanto el rol A como el B y los roles A y B no están relacionados, no en una jerarquía).

Re: su jerarquía de ejemplo. En Zend Framework ACL esto podría ser así:

$acl->addRole(new Zend_Acl_Role('Role1')) 
    ->addRole(new Zend_Acl_Role('Group1', array('Role1')) 
    ->addRole(new Zend_Acl_Role('Group2', array('Group1)); 
$acl->allow('Role1', 'someAction', 'someObject'); // permission 1 
$acl->allow('Role1', 'otherAction', 'otherObject'); // permission 2 
$acl->deny('Group2', 'someAction', 'someObject'); 

para ser honesto que ha sido un tiempo De hecho, he hecho esto en Zend_Acl ya que estoy creando mi propio sistema.

Answer 2

El desafío con el uso de grupos para permisos de aplicaciones personalizadas es la falta de cualquier relación entre los grupos y los recursos que se utilizan para proteger. p.ej. Si utilizo un grupo de AD para otorgar acceso en mi aplicación personalizada, realmente no sé a qué otro grupo puede estar otorgando acceso, si agrego un usuario al grupo pensando que estoy otorgando permiso para leer y aprobar mi aplicación. Podría estar agregándolos inadvertidamente a un grupo que otorga acceso a carpetas compartidas, otras aplicaciones, casi cualquier cosa. Si escribes tu propia aplicación, sugeriría algo así como un sistema basado en roles (incluso roles mejores como parte de un modelo de reclamos con toda la seguridad externa a tu código de aplicación) donde exista una relación restringida entre el rol y los recursos que podría ser utilizado para otorgar acceso a: de esa manera puede ver desde todas las dimensiones quién tiene acceso a qué y por qué. Los grupos representan un agujero negro desde una perspectiva de visibilidad.

Ponemos en práctica una RBAC bastante compleja en nuestro producto con funciones de negocio poliárquicas y funciones técnicas que están restringidas según el tipo de recursos que protegen - http://blog.identitymanagement.com/downloads/ de Microsoft tiene un nuevo marco de programación basado en reclamo nueva llamada Windows Identity Foundation - maneja la mayor parte de la plomería para usted

Patrick Parker