Control de acceso basado en roles

La introducción de este artículo puede ser demasiado breve para resumir adecuadamente los puntos clave . Considere ampliar la introducción para brindar una descripción general accesible de todos los aspectos importantes del artículo. ( Mayo de 2012 )

En seguridad de sistemas informáticos, el control de acceso basado en roles ( RBAC ) ^{[1] [2]} o seguridad basada en roles ^[3] es un enfoque para restringir el acceso al sistema a usuarios autorizados y para implementar el control de acceso obligatorio (MAC) o el control de acceso discrecional (DAC).

El control de acceso basado en roles es un mecanismo de control de acceso neutral en cuanto a políticas definido en torno a roles y privilegios. Los componentes de RBAC, como los permisos de roles, las relaciones rol-usuario y rol-rol, simplifican la realización de asignaciones de usuarios. Un estudio realizado por NIST ha demostrado que RBAC aborda muchas necesidades de organizaciones comerciales y gubernamentales. ^[4] RBAC se puede utilizar para facilitar la administración de la seguridad en grandes organizaciones con cientos de usuarios y miles de permisos. Aunque RBAC es diferente de los marcos de control de acceso MAC y DAC, puede aplicar estas políticas sin ninguna complicación.

Dentro de una organización, se crean roles para diversas funciones laborales. Los permisos para realizar determinadas operaciones se asignan a roles específicos. Dado que a los usuarios no se les asignan permisos directamente, sino que solo los adquieren a través de su rol (o roles), la gestión de los derechos de cada usuario se convierte en una cuestión de simplemente asignar los roles adecuados a la cuenta del usuario; esto simplifica las operaciones comunes, como agregar un usuario o cambiar el departamento de un usuario.

Se definen tres reglas principales para RBAC:

1. Asignación de roles: un sujeto puede ejercer un permiso solo si ha seleccionado o se le ha asignado un rol.
2. Autorización de roles: el rol activo de un sujeto debe estar autorizado para el sujeto. Con la regla 1 anterior, esta regla garantiza que los usuarios solo puedan asumir roles para los que están autorizados.
3. Autorización de permisos: un sujeto puede ejercer un permiso solo si el permiso está autorizado para el rol activo del sujeto. Con las reglas 1 y 2, esta regla garantiza que los usuarios solo puedan ejercer los permisos para los que están autorizados.

También se pueden aplicar restricciones adicionales y los roles se pueden combinar en una jerarquía donde los roles de nivel superior subsumen los permisos que pertenecen a los roles secundarios.

Con los conceptos de jerarquía de roles y restricciones, se puede controlar RBAC para crear o simular un control de acceso basado en red (LBAC). Por lo tanto, RBAC puede considerarse un superconjunto de LBAC.

Al definir un modelo RBAC, las siguientes convenciones son útiles:

• S = Sujeto = Una persona o agente automatizado
• R = Rol = Función laboral o título que define un nivel de autoridad
• P = Permisos = Una aprobación de un modo de acceso a un recurso
• SE = Sesión = Un mapeo que involucra S, R y/o P
• SA = Asignación de asignatura
• PA = Asignación de permisos
• RH = Jerarquía de roles parcialmente ordenada. RH también se puede escribir: ≥ (La notación: x ≥ y significa que x hereda los permisos de y).
  • Un sujeto puede tener múltiples roles.
  • Un rol puede tener múltiples sujetos.
  • Un rol puede tener muchos permisos.
  • Se puede asignar un permiso a muchos roles.
  • A una operación se le pueden asignar muchos permisos.
  • Se puede asignar un permiso a muchas operaciones.

Una restricción impone una regla restrictiva sobre la herencia potencial de permisos de roles opuestos. Por lo tanto, se puede utilizar para lograr una separación adecuada de funciones . Por ejemplo, no se debe permitir que la misma persona cree una cuenta de inicio de sesión y autorice la creación de la cuenta.

Así, utilizando la notación de teoría de conjuntos :

• ${\displaystyle PA\subseteq P\times R}$y es una relación de asignación de roles de permiso de muchos a muchos.
• ${\displaystyle SA\subseteq S\times R}$y es una relación de muchos a muchos sujeta a asignación de roles.
• ${\displaystyle RH\subseteq R\times R}$

Un sujeto puede tener múltiples sesiones simultáneas con/en diferentes roles.

El estándar RBAC NIST/ANSI/ INCITS (2004) reconoce tres niveles de RBAC: ^[5]

1. núcleo RBAC
2. RBAC jerárquico, que agrega soporte para herencia entre roles
3. RBAC restringido, que añade separación de funciones

RBAC es una tecnología de control de acceso flexible cuya flexibilidad le permite implementar DAC ^[6] o MAC . ^[7] DAC con grupos (por ejemplo, como se implementa en los sistemas de archivos POSIX) puede emular RBAC. ^[8] MAC puede simular RBAC si el gráfico de roles está restringido a un árbol en lugar de un conjunto parcialmente ordenado . ^[9]

Antes del desarrollo de RBAC, el modelo Bell-LaPadula (BLP) era sinónimo de MAC y los permisos del sistema de archivos eran sinónimos de DAC. Se consideraba que estos eran los únicos modelos conocidos para el control de acceso: si un modelo no era BLP, se consideraba un modelo DAC, y viceversa. La investigación de finales de los años 90 demostró que RBAC no entra en ninguna de las dos categorías. ^{[10] [11]} A diferencia del control de acceso basado en contexto (CBAC), RBAC no analiza el contexto del mensaje (como la fuente de una conexión). RBAC también ha sido criticado por conducir a una explosión de roles, ^[12] un problema en los grandes sistemas empresariales que requieren un control de acceso de mayor granularidad que la que RBAC puede proporcionar, ya que los roles se asignan inherentemente a operaciones y tipos de datos. De manera similar al CBAC, un sistema de control de acceso basado en relaciones entre entidades (ERBAC, aunque también se utiliza el mismo acrónimo para sistemas RBAC modificados, ^[13] como el control de acceso basado en roles extendido ^[14] ) es capaz de proteger instancias de datos al considerar su asociación con el sujeto que los ejecuta. ^[15]

Las listas de control de acceso (ACL) se utilizan en los sistemas tradicionales de control de acceso discrecional (DAC) para afectar a los objetos de datos de bajo nivel. RBAC se diferencia de ACL en que asigna permisos a operaciones que cambian las relaciones directas entre varias entidades (consulte: ACLg a continuación). Por ejemplo, una ACL podría utilizarse para otorgar o denegar acceso de escritura a un archivo de sistema en particular, pero no dictaría cómo se podría cambiar ese archivo. En un sistema basado en RBAC, una operación podría ser la transacción de "crear una cuenta de crédito" en una aplicación financiera o "completar un registro de prueba de nivel de azúcar en sangre" en una aplicación médica. Por lo tanto, un rol es una secuencia de operaciones dentro de una actividad más grande. Se ha demostrado que RBAC es particularmente adecuado para los requisitos de separación de funciones (SoD), que garantizan que dos o más personas deben participar en la autorización de operaciones críticas. Se han analizado las condiciones necesarias y suficientes para la seguridad de SoD en RBAC. Un principio subyacente de SoD es que ningún individuo debe poder provocar una violación de la seguridad a través de un privilegio dual. Por extensión, ninguna persona puede desempeñar un cargo que ejerza autoridad de auditoría, control o revisión sobre otra función que ocupe simultáneamente. ^{[16] [17]}

Por otra parte, un "modelo RBAC mínimo", RBACm , se puede comparar con un mecanismo ACL, ACLg , donde solo se permiten grupos como entradas en el ACL. Barkley (1997) ^[18] demostró que RBACm y ACLg son equivalentes.

En las implementaciones modernas de SQL , como las ACL del marco de trabajo CakePHP , las ACL también administran grupos y herencia en una jerarquía de grupos. En este aspecto, las implementaciones específicas de "ACL modernas" se pueden comparar con las implementaciones específicas de "RBAC modernas", mejor que las implementaciones "antiguas (del sistema de archivos)".

Para el intercambio de datos y para "comparaciones de alto nivel", los datos de ACL se pueden traducir a XACML .

El control de acceso basado en atributos o ABAC es un modelo que evoluciona a partir de RBAC para considerar atributos adicionales además de roles y grupos. En ABAC, es posible utilizar atributos de:

• el usuario, por ejemplo, ciudadanía, autorización,
• el recurso, por ejemplo, clasificación, departamento, propietario,
• la acción, y
• el contexto, por ejemplo, tiempo, ubicación, IP.

ABAC se basa en políticas en el sentido de que utiliza políticas en lugar de permisos estáticos para definir qué está permitido o qué no.

El control de acceso basado en relaciones o ReBAC es un modelo que evoluciona a partir del RBAC. En ReBAC, el permiso de un sujeto para acceder a un recurso se define por la presencia de relaciones entre esos sujetos y los recursos.

La ventaja de este modelo es que permite permisos de granularidad fina; por ejemplo, en una red social donde los usuarios pueden compartir publicaciones con otros usuarios específicos. ^[19]

El uso de RBAC para gestionar los privilegios de los usuarios (permisos informáticos) dentro de un único sistema o aplicación se acepta ampliamente como una práctica recomendada. Un informe de 2010 preparado para el NIST por el Research Triangle Institute analizó el valor económico de RBAC para las empresas y estimó los beneficios por empleado a partir de la reducción del tiempo de inactividad de los empleados, un aprovisionamiento más eficiente y una administración más eficiente de las políticas de control de acceso. ^[20]

En una organización con una infraestructura de TI heterogénea y requisitos que abarcan docenas o cientos de sistemas y aplicaciones, el uso de RBAC para gestionar suficientes roles y asignar membresías de roles adecuadas se vuelve extremadamente complejo sin la creación jerárquica de roles y asignaciones de privilegios. ^[21] Los sistemas más nuevos amplían el antiguo modelo RBAC de NIST ^[22] para abordar las limitaciones de RBAC para implementaciones en toda la empresa. El modelo NIST fue adoptado como estándar por INCITS como ANSI/INCITS 359-2004. También se ha publicado un análisis de algunas de las opciones de diseño para el modelo NIST. ^[23]

La interferencia en el control de acceso basado en roles es un problema relativamente nuevo en las aplicaciones de seguridad, donde múltiples cuentas de usuario con niveles de acceso dinámicos pueden generar inestabilidad en la clave de cifrado, lo que permite que un usuario externo aproveche la debilidad para obtener acceso no autorizado. Las aplicaciones de uso compartido de claves en entornos virtualizados dinámicos han demostrado cierto éxito en la solución de este problema. ^[24]

• David F. Ferraiolo; D. Richard Kuhn; Ramaswamy Chandramouli (2007). Control de acceso basado en roles (2.ª ed.). Artech House. ISBN 978-1-59693-113-8.

• Preguntas frecuentes sobre los modelos y estándares RBAC
• Controles de acceso basados ​​en roles en NIST
• Perfil de control de acceso basado en roles jerárquicos y núcleo XACML
• Instituto de Seguridad Cibernética de la Universidad de Texas en San Antonio
• Experiencias prácticas en la implementación de RBAC