it-swarm-es.com

Modelo RBAC: dilema de acceso de usuario en dos roles

Estoy implementando el sistema de seguridad del modelo de control de acceso basado en roles (RBAC) y tengo un dilema: un Usuario1 está en Role1 y está en Role2. Role1 permite el acceso al Resource1 y Role2 niega el acceso al mismo. Es un problema bien conocido. Alguien podría ayudarme, cómo resolverlo, quizás algunas explicaciones. Cómo explicarle al Usuario1 por qué no tiene acceso a algún recurso. Hay alguna solución para superarlo inteligentemente.

Gracias.

10
garik

Parece que está fusionando entre RBAC y DAC (Control de acceso discrecional): ¡Denegar acceso no se emplea normalmente en RBAC, sino que proviene del mundo DAC. F.e. es común ver una ACL NTFS (Lista de control de acceso) con DENY en ella.

Es posible que esté intentando implementar un modelo combinado (consulte el ejemplo en mi respuesta aquí ) - p. Ej. la construcción de una ACL con ACE (Entrada de control de acceso) apuntando a roles. P.ej. usar grupos para otorgar acceso a carpetas ...

Hay dos posibles soluciones que puede usar, tal vez incluso mix'n'match, dependiendo de lo que tenga sentido para su sistema (he construido y usado ambas, en diferentes contextos):

  • ACL ordenada: es decir, la ACL no es una gran pila de ACE, pero están en un orden específico: más arriba en la lista tiene prioridad, siga evaluando ACE hasta que encuentre un PERMIT ACE, o un DENY ACE para ese usuario. Lo que sea primero en la lista, gana.
  • DENY ACE anula todas las demás ACE. Es decir, si el usuario tiene acceso a través de Role1, escanee la ACL en busca de cualquier DENY que se aplique al usuario, y luego Role2 bloqueará el acceso pase lo que pase.

Tenga en cuenta que es posible que no esté implementando esto con un modelo de ACL estándar, sino que realmente solo verifique los roles de usuario; eso aún está bien, lo anterior aún se aplica (solo que es más difícil de visualizar y explicar).

La verdadera pregunta que debe resolver es: ¿Qué tiene sentido para su sistema? ¿Está intentando implementar SoD (Segregation/Separation of Duty)? Si es así, está claro que DENY debe anular cualquier PERMISO. Si desea que el usuario configure esto (en cuyo caso su DAC, no RBAC), la primera opción brinda la mayor flexibilidad, ya que hay IS una forma de evitarlo.

7
AviD

No estoy seguro de que sea un problema conocido. Si su posición predeterminada es denegar a todos, y debería serlo, entonces las reglas solo deberían indicar lo que cada función puede hacer. Si un usuario/rol tiene acceso a un recurso bajo cualquier regla, creo que debería estar permitido.

Es posible que deba reconsiderar la forma en que se establecen sus roles. Creo que en los conflictos ganaría el priv más alto. Las herramientas pueden manejar esto de diferentes maneras. Es importante entender exactamente cómo su entorno funciona funciona, no cómo debería funcionar.

4
pboin

Puede que me esté perdiendo algo, pero ¿no es una solución bastante simple utilizar un concepto como un "rol activo"?

En otras palabras, el usuario elige su rol activo de la lista de roles a los que está asignado y luego usted solo verifica las ACL con ese rol único.

2
Van Gale

Es posible que desee considerar el uso de lo que he escuchado que se conoce como seguridad de acceso híbrida basada en reclamos. En este modelo, básicamente, cada tarea se desglosa y se usa como un perfil para mantener la seguridad más fácil de administrar (aunque más difícil de implementar inicialmente).

Básicamente, configurar tablas similares a:

Users --> Groups --> Profiles --> Rights
 |         |_______________________^
 |____________________^
 |_________________________________^

Tabla de usuarios, cada usuario puede tener uno o más grupos Los usuarios también pueden tener uno o más Perfiles (también conocidos como subgrupos de derechos para una tarea) Los usuarios también pueden tener uno o más derechos Los grupos tienen uno o más Perfiles Los grupos pueden tener uno o más Los perfiles de derechos pueden tener uno o más derechos


La desventaja proviene de la capa adicional de grupos que están orientados a tareas, sin embargo, es más fácil para la mayoría de los no desarrolladores poder conceptualizar este diseño.

También puede utilizar un sistema puro basado en reclamaciones, pero es difícil mantener algo así a largo plazo, en mi opinión. Probablemente estaría mejor con RBAC estándar (no RB-RBAC) y usar un conjunto consistente de reglas como conflictos = denegación de acceso.

1
Dave