En la seguridad de los 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 un control de acceso obligatorio (MAC) o acceso discrecional. control (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 rol, el rol de usuario y las relaciones entre roles, simplifican la realización de asignaciones de usuarios. Un estudio del 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 hacer cumplir 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 sólo los adquieren a través de su rol (o roles), la administración de los derechos de los usuarios individuales se convierte en una cuestión de simplemente asignar roles apropiados 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:
También se pueden aplicar restricciones adicionales y los roles se pueden combinar en una jerarquía donde los roles de nivel superior incluyen permisos propiedad de sub-roles.
Con los conceptos de jerarquía de roles y restricciones, se puede controlar RBAC para crear o simular un control de acceso basado en celosía (LBAC). Por tanto, se puede considerar que RBAC es un superconjunto de LBAC.
Al definir un modelo RBAC, las siguientes convenciones son útiles:
Una restricción impone una regla restrictiva sobre la posible herencia de permisos de roles opuestos. Por tanto, puede utilizarse para lograr 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 autorice la creación de la cuenta.
Así, usando la notación de la teoría de conjuntos :
Un sujeto puede tener múltiples sesiones simultáneas con/en diferentes roles.
El estándar NIST/ANSI/ INCITS RBAC (2004) reconoce tres niveles de RBAC: [5]
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 funciones está restringido 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 para control de acceso: si un modelo no era BLP, se consideraba modelo DAC, y viceversa. La investigación realizada a fines de la década de 1990 demostró que RBAC no se encuentra en ninguna de las 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 mayor granularidad que el que RBAC puede proporcionar, ya que los roles están inherentemente asignados a operaciones y tipos de datos. A semejanza de 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 sistema de control de acceso basado en roles extendido [14] ) es capaz de proteger instancias de datos. considerando su asociación al sujeto ejecutor. [15]
Las listas de control de acceso (ACL) se utilizan en los sistemas tradicionales de control de acceso discrecional (DAC) para afectar objetos de datos de bajo nivel. RBAC se diferencia de ACL en la asignación de permisos a operaciones que cambian las relaciones directas entre varias entidades (ver: ACLg a continuación). Por ejemplo, una ACL podría usarse para otorgar o denegar acceso de escritura a un archivo del 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 consistir en "crear una transacción de cuenta de crédito" en una aplicación financiera o "rellenar un registro de prueba de 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 desempeñar una función que ejerza autoridad de auditoría, control o revisión sobre otra función que desempeñe simultáneamente. [16] [17]
Por otra parte, 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 SQL modernas , como la ACL del marco CakePHP , las ACL también administran grupos y herencia en una jerarquía de grupos. Bajo este aspecto, las implementaciones específicas de "ACL moderna" se pueden comparar con implementaciones específicas de "RBAC moderno", mejor que las "implementaciones antiguas (sistema de archivos)".
Para el intercambio de datos y para "comparaciones de alto nivel", los datos 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:
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 y qué no.
El control de acceso basado en relaciones o ReBAC es un modelo que evoluciona a partir de 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 específicos; 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 de la computadora) dentro de un único sistema o aplicación es ampliamente aceptado como una mejor 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, usar RBAC para administrar 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 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 una discusión sobre algunas de las opciones de diseño para el modelo NIST. [23]
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 provocar 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]
{{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite book}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )