Control de acceso basado en roles

En seguridad de la información , 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. Se trata de un mecanismo de control de acceso informático independiente de políticas, definido en torno a roles y privilegios. Los componentes de RBAC, como los permisos de rol, las relaciones usuario-rol y rol-rol, simplifican la asignación de usuarios. RBAC puede utilizarse para facilitar la administración de la seguridad en grandes organizaciones con cientos de usuarios y miles de permisos.

Si bien el control de acceso basado en roles (RBAC) difiere de los marcos de control de acceso obligatorio y de control de acceso discrecional (DAC), puede aplicar estas políticas. Su enfoque también difiere del control de acceso basado en contexto y de las listas de control de acceso . El control de acceso basado en atributos y el control de acceso basado en relaciones son modelos que se basan en el concepto de RBAC.

Un estudio de la década de 1990 realizado por el NIST demostró que el RBAC satisface muchas necesidades de las organizaciones comerciales y gubernamentales. ^{[ 4 ]} El RBAC todavía se considera comúnmente una buena práctica en la gestión de la seguridad de la información , incluida la implementación de estándares de seguridad de la información relacionados con el control de acceso.

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

Se definen tres reglas principales para el RBAC:

1. Asignación de rol: Un sujeto solo puede ejercer un permiso 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 dicho sujeto. Con la regla 1 anterior, esta regla garantiza que los usuarios solo puedan asumir los roles para los que están autorizados.
3. Autorización de permisos: Un usuario solo puede ejercer un permiso si este está autorizado para su rol activo. 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 engloban los permisos que poseen los subroles.

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

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

• S = Sujeto = Una persona o agente automatizado
• R = Rol = Función o título del puesto 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 asignatura
• PA = Asignación de permisos
• RH = Jerarquía de roles parcialmente ordenada. RH también se puede escribir como: ≥ (La notación: x ≥ y significa que x hereda los permisos de y).
  • Un sujeto puede desempeñar múltiples roles.
  • Un rol puede tener múltiples temas.
  • Un rol puede tener muchos permisos.
  • Se puede asignar un permiso a varios roles.
  • Una operación puede estar asociada a varios permisos.
  • Se puede asignar un permiso a varias operaciones.

Una restricción impone una regla limitante sobre la posible herencia de permisos entre roles opuestos. De este modo, puede utilizarse para lograr una separación de funciones adecuada . Por ejemplo, una misma persona no debería tener permitido crear una cuenta de inicio de sesión y, al mismo tiempo, autorizar su creación.

Por lo tanto, utilizando la notación de la teoría de conjuntos :

• ${\displaystyle PA\subsetequ P\times R}$y es una relación de asignación de roles 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 varias sesiones simultáneas con/en diferentes roles.

RBAC es una tecnología de control de acceso flexible cuya flexibilidad le permite implementar control de acceso discrecional (DAC) ^{[ 6 ]} o control de acceso obligatorio (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 grafo 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ónimo de DAC. Estos se consideraban los únicos modelos conocidos para el control de acceso: si un modelo no era BLP, se consideraba un modelo DAC, y viceversa. Investigaciones de finales de la década de 1990 demostraron que RBAC no pertenece a ninguna de las dos categorías. ^{[ 10 ] [ 11 ]} A diferencia del control de acceso basado en contexto (CBAC), RBAC no considera 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 grandes sistemas empresariales que requieren un control de acceso con una granularidad más fina que la que RBAC puede proporcionar, ya que los roles se asignan inherentemente a las operaciones y los tipos de datos. De manera similar a CBAC, un sistema de control de acceso basado en entidades-relaciones puede proteger instancias de datos considerando su asociación con el sujeto que las ejecuta. ^{[ 13 ]}

El uso de RBAC para gestionar los privilegios de usuario (permisos informáticos) dentro de un mismo sistema o aplicación es ampliamente aceptado como una buena práctica . Un informe de 2010 elaborado para el NIST por el Research Triangle Institute analizó el valor económico de RBAC para las empresas y estimó los beneficios por empleado derivados de la reducción del tiempo de inactividad de los empleados, un aprovisionamiento más eficiente y una administración más eficaz de las políticas de control de acceso. ^{[ 18 ]}

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. ^{[ 19 ]} Los sistemas más recientes extienden el modelo RBAC NIST anterior ^{[ 20 ]} para abordar las limitaciones de RBAC para implementaciones a nivel empresarial. El modelo NIST fue adoptado como estándar por INCITS como ANSI/INCITS 359-2004. También se ha publicado una discusión sobre algunas de las decisiones de diseño para el modelo NIST. ^{[ 21 ]}

La publicación especial 800-53 del NIST , un estándar de seguridad de la información utilizado por agencias federales estadounidenses y otras organizaciones, incluye el control de acceso basado en roles en sus controles de aplicación de acceso bajo AC-3(7). ^{[ 22 ]}

Las implementaciones de los Controles CIS , un conjunto de mejores prácticas, a menudo incorporan el control de acceso basado en roles como parte del cumplimiento del Control 6, Gestión del Control de Acceso. ^{[ 23 ]}

Las regulaciones de la Ley de Portabilidad y Responsabilidad del Seguro Médico de EE. UU. (HIPAA) requieren la implementación del control de acceso como parte de las salvaguardas técnicas para la información de salud protegida electrónicamente ( 45  CFR 164.312 ), y el control de acceso basado en roles es un enfoque típico en la industria. ^{[ 24 ]}

El Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) exige a los implementadores que "limiten el acceso a los componentes del sistema y a los datos de los titulares de tarjetas únicamente a aquellas personas cuyo trabajo requiera dicho acceso", lo que incluye garantizar que "la asignación de privilegios se base en la clasificación laboral y la función de cada persona" (Requisito 7), una forma de control de acceso basado en roles. ^{[ 25 ]}

• RSBAC
• Seguridad basada en capacidades
• Autenticación basada en riesgos
• AGDLP (recomendaciones de Microsoft para la implementación de RBAC)
• Redes basadas en la identidad (IDN)
• PERMIS
• Fortaleza Apache
• Principio del mínimo privilegio

• 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 modelos y estándares RBAC
• Controles de acceso basados ​​en roles en el NIST
• Perfil de control de acceso basado en roles jerárquico y del núcleo de XACML