Control de acceso basado en roles

En la seguridad de los sistemas informáticos, el control de acceso basado en roles (RBAC, por sus siglas en inglés) ^{[1] [2]} o seguridad basada en roles^[3] es un enfoque para restringir el acceso al sistema a usuarios autorizados y para implementar un control de acceso obligatorio (MAC) o 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 por rol, y las relaciones entre usuarios y roles, facilitan la asignación de usuarios. Un estudio realizado por el Instituto Nacional de Estándares y Tecnología (NIST) ha demostrado que RBAC satisface 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 hacer cumplir estas políticas sin ninguna complicación.

Diseño

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 los usuarios no reciben permisos directamente, sino que sólo los adquieren a través de su rol (o roles), la gestión de los derechos de los usuarios individuales se reduce a asignar los roles apropiados a la cuenta del usuario; lo que simplifica las operaciones comunes como agregar un usuario o cambiarle de departamento.

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. Junto con la regla 1, 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. Junto con las reglas 1 y 2, esta regla garantiza que los usuarios solo puedan ejercer permisos para los que están autorizados.

También pueden aplicarse restricciones adicionales, y los roles se pueden combinar en una jerarquía donde los roles de nivel superior incluyen los permisos de los sub-roles.

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

Convenciones utilizadas en el modelo RBAC

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 = 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 sujetos
• 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 posible herencia de permisos de roles opuestos, logrando así una adecuada separación de funciones. Por ejemplo, no se debe permitir que la misma persona cree una cuenta de inicio de sesión y que autorice la creación de la cuenta.

Utilizando la notación de la teoría de conjuntos:

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

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

Niveles estandarizados de RBAC

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

1. RBAC básico
2. RBAC jerárquico: Añade soporte para la herencia entre roles
3. RBAC restringido: Añade separación de funciones

Relación con otros modelos

RBAC es una tecnología de control de acceso flexible cuya flexibilidad permite implementar DAC ^[6] o MAC. ^[7] DAC con grupos (por ejemplo, como se implementa en sistemas de archivos POSIX) puede emular RBAC. ^[8] MAC puede simular RBAC si el gráfico de roles se restringe a un árbol en lugar de a 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ónimo de DAC. Estos se consideraban los únicos modelos conocidos de control de acceso: si un modelo no era BLP, se consideraba un modelo DAC, y viceversa. La investigación a finales de la década de 1990 demostró que RBAC no se encuentra en ninguna de estas categorías. ^{[10] [11]} A diferencia del control de acceso basado en contexto (CBAC), RBAC no analiza el contexto del mensaje (como el origen de una conexión). RBAC también ha sido criticado por conducir a una explosión de roles, ^[12] un problema en los sistemas empresariales grandes que requieren un control de acceso de granularidad más fina que el que RBAC puede proporcionar, ya que los roles están inherentemente asignados a operaciones y tipos de datos. Similar al CBAC, un sistema de control de acceso basado en entidad-relación (ERBAC, aunque el mismo acrónimo también se utiliza para sistemas RBAC modificados, ^[13] como el Control de Acceso Basado en Roles Extendido ^[14]) es capaz de proteger instancias de datos considerando su asociación al sujeto ejecutor. ^[15]

Comparación con las Listas de Control de Acceso (ACL)

Las listas de control de acceso (ACL) se utilizan en sistemas de control de acceso discrecional (DAC) tradicionales para afectar objetos de datos de bajo nivel. RBAC se diferencia de ACL en asignar permisos a operaciones que cambian las relaciones directas entre varias entidades (ver: ACLg a continuación). Por ejemplo, una ACL podría usarse para conceder o denegar acceso de escritura a un archivo del sistema en particular, pero no dictaría cómo podría cambiarse ese archivo. En un sistema basado en RBAC, una operación podría consistir en "crear una cuenta de crédito" en una aplicación financiera o "registrar un nivel de azúcar en sangre" en una aplicación médica. Por tanto, un rol es una secuencia de operaciones dentro de una actividad más amplia. 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 debería poder violar la seguridad mediante un doble privilegio. Por extensión, ninguna persona puede tener un rol que ejerza autoridad de auditoría, control o revisión sobre otro rol que ocupe simultáneamente. ^{[16] [17]}

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

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

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

Control de acceso basado en atributos

El control de acceso basado en atributos o ABAC es un modelo que evoluciona desde 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 está basado en políticas en el sentido de que utiliza políticas en lugar de permisos estáticos para definir qué está permitido y qué no.

Control de acceso basado en relaciones

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

La ventaja de este modelo es que permite permisos de gran precisión. Por ejemplo, en una red social donde los usuarios pueden compartir publicaciones con otros usuarios específicos. ^[19]

Uso y disponibilidad

El uso de RBAC para gestionar privilegios de usuario (permisos informáticos) dentro de un único sistema o aplicación es ampliamente aceptado como una buena práctica. Un informe de 2010 preparado para NIST por el Research Triangle Institute analizó el valor económico de RBAC para las empresas y estimó los beneficios por empleado de la reducción del tiempo de inactividad de los empleados, un aprovisionamiento más eficiente y una administración de políticas de control de acceso más eficiente. ^[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 rol adecuadas se vuelve extremadamente complejo sin la creación jerárquica de roles y asignaciones de privilegios. ^[21] Los sistemas más recientes amplían el modelo NIST RBAC anterior ^[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 del modelo NIST. ^[23]

Vulnerabilidades potenciales

La interferencia del 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 conducir a la inestabilidad en la clave de cifrado, permitiendo que un usuario externo aproveche la debilidad del acceso no autorizado. Las aplicaciones para compartir claves dentro de entornos virtualizados dinámicos han mostrado cierto éxito al abordar este problema. ^[24]

Véase también

• Access control list

Referencias

1. Ferraiolo, D.F.; Kuhn, D.R. (October 1992). «Role-Based Access Control». 15th National Computer Security Conference: 554-563.
2. Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (August 1996). «Role-Based Access Control Models». IEEE Computer 29 (2): 38-47. doi:10.1109/2.485845.
3. ABREU, VILMAR; Santin, Altair O.; VIEGAS, EDUARDO K.; STIHLER, MAICON (2017). «A multi-domain role activation model». 2017 IEEE International Conference on Communications (ICC). IEEE Press. pp. 1-6. ISBN 978-1-4673-8999-0. doi:10.1109/ICC.2017.7997247.
4. «An examination of federal and commercial access control policy needs». National Computer Security Conference, 1993 (16th) Proceedings: Information Systems Security: User Choices. DIANE Publishing. 1995. p. 107. ISBN 9780788119248.
5. Alberto Belussi; Barbara Catania; Eliseo Clementini; Elena Ferrari (2007). Spatial Data on the Web: Modeling and Management. Springer. p. 194. ISBN 978-3-540-69878-4.
6. Ravi Sandhu; Qamar Munawer (October 1998). «How to do discretionary access control using roles». 3rd ACM Workshop on Role-Based Access Control: 47-54.
7. Sylvia Osborn; Ravi Sandhu; Qamar Munawer (2000). «Configuring role-based access control to enforce mandatory and discretionary access control policies». ACM Transactions on Information and System Security: 85-106.
8. Brucker, Achim D.; Wolff, Burkhart (2005). «A Verification Approach for Applied System Security». International Journal on Software Tools for Technology Transfer 7 (3): 233-247. doi:10.1007/s10009-004-0176-3.
9. D.R. Kuhn (1998). «Role based access control on MLS systems without kernel changes». Proceedings of the third ACM workshop on Role-based access control. pp. 25-32. ISBN 978-1-58113-113-0. doi:10.1145/286884.286890.
10. «Role Based Access Control – FAQs». csrc.nist.gov. Computer Security Research Center. 21 de noviembre de 2016. Consultado el 15 de agosto de 2018.
11. Ferraiolo, David; Kuhn, Richard (13 de octubre de 1992). Role-Based Access Controls. p. csrc.nist.gov |página= y |páginas= redundantes (ayuda). Consultado el 15 de agosto de 2018.
12. A. A. Elliott; G. S. Knight (2010). «Role Explosion: Acknowledging the Problem». Proceedings of the 2010 International Conference on Software Engineering Research & Practice.
13. «ERBAC – Enterprise Role-Based Access Control (computing) – AcronymFinder». www.acronymfinder.com. Consultado el 15 de agosto de 2018.
14. «Dr. Bhavani Thuraisingham and Srinivasan Iyer (PPT)». Consultado el 15 de agosto de 2018.
15. Korhonen, Kalle. «tapestry-security-jpa». www.tynamo.org. Consultado el 15 de agosto de 2018.
16. D.R. Kuhn (1997). «Mutual exclusion of roles as a means of implementing separation of duty in role-based access control systems». Proceedings of the second ACM workshop on Role-based access control - RBAC '97. pp. 23-30. ISBN 0897919858. doi:10.1145/266741.266749.
17. Li, Ninghui; Bizri, Ziad; Tripunitara, Mahesh V. (2004). «On mutually-exclusive roles and separation of duty» (PDF). Proceedings of the 11th ACM conference on Computer and communications security. pp. 42-51. ISBN 978-1581139617. doi:10.1145/1030083.1030091.
18. «CiteSeerX». CiteSeerX (en inglés). Consultado el 3 de octubre de 2024.
19. Gates, Carrie (2007). «Access control requirements for web 2.0 security and privacy». IEEE Web 2: 12-15.
20. A.C. O'Connor; R.J. Loomis (March 2002). Economic Analysis of Role-Based Access Control. Research Triangle Institute. p. 145.
21. Systems, Hitachi ID. «Beyond Roles: A Practical Approach to Enterprise IAM». www.idsynch.com. Consultado el 15 de agosto de 2018.
22. Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). «The NIST model for role-based access control». Proceedings of the fifth ACM workshop on Role-based access control. pp. 47-63. ISBN 158113259X. doi:10.1145/344287.344301.
23. Ferraiolo, D.F., Kuhn, D.R., and Sandhu, R. (Nov–Dec 2007). «RBAC Standard Rationale: comments on a Critique of the ANSI Standard on Role-Based Access Control». IEEE Security & Privacy 5 (6): 51-53. doi:10.1109/MSP.2007.173. Archivado desde el original el 17 de septiembre de 2008.
24. Marikkannu, P (2011). «Fault-tolerant adaptive mobile agent system using dynamic role based access control». International Journal of Computer Applications 20 (2): 1-6. Bibcode:2011IJCA...20b...1M. doi:10.5120/2409-3208.

Enlaces externos

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