Control de acceso basado en roles

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 9 de diciembre de 2019; las comprobaciones requieren 2 ediciones .

El control de acceso basado en roles (RBAC ) es el desarrollo de una política de  control de acceso selectivo , mientras que los derechos de acceso de los sujetos del sistema a los objetos se agrupan teniendo en cuenta las especificidades de su aplicación, formando roles . [1] [2]

La formación de roles tiene por objeto definir reglas claras y comprensibles para el control de acceso de los usuarios de un sistema informático . El control de acceso basado en roles hace posible implementar reglas de control de acceso flexibles que cambian dinámicamente durante la operación de un sistema informático.

Dicho control de acceso es un componente de muchos sistemas informáticos modernos. Como regla general, este enfoque se utiliza en los sistemas de protección DBMS y los elementos individuales se implementan en los sistemas operativos de red . El enfoque basado en roles se usa a menudo en sistemas para los cuales los usuarios tienen un alcance claramente definido de sus deberes y responsabilidades laborales.

A pesar de que un Rol es un conjunto de derechos de acceso a los objetos de un sistema informático, el control de acceso basado en roles no es en modo alguno un caso especial de control de acceso selectivo, ya que sus reglas determinan el procedimiento para otorgar acceso a los sujetos de un sistema informático. sistema, dependiendo de los roles que tenga (o no tenga) en cada momento del tiempo, lo cual es típico de los sistemas de control de acceso obligatorio . Por otro lado, las reglas del control de acceso basado en roles son más flexibles que con el enfoque obligatorio para el control de acceso.

Dado que los privilegios no se asignan directamente a los usuarios y solo los adquieren a través de su función (o funciones), la gestión de los derechos individuales de un usuario se reduce esencialmente a asignarle funciones. Esto simplifica operaciones como agregar un usuario o cambiar departamentos por parte de un usuario.

Historia

Las formas elementales del modelo RBAC se han implementado en una variedad de formas especiales en muchos sistemas desde la década de 1970 . El control de acceso basado en roles actualmente en uso se deriva del modelo propuesto por Ferraiolo y  Kuhn ( 1992 ) y como modelo  ejemplar posteriormente refinado por Sandhu , Coyne, Feinstein y Yeoman ( 1996 ).  

• Documento de 1992  de Ferraiolo y Kuhn que define RBAC accediendo solo a través de roles, jerarquías y restricciones. modelo formal;
• 1994  - Prototipo RBAC basado en DTOS, basado en el modelo prototipo propuesto por Ferraiolo, Kuhn, Gavrila ( Ing.  Gavrila )
• 1994 El artículo de Nyanchama y Osborn define un modelo;
• 1994 - IBM presenta (en Europa) la primera solicitud de patente en el campo de RBAC, citando a Ferraiolo y Kuhn;
• 1995  - Ferraiolo, Cugini ( inglés  Cugini ), Kuhn amplió el modelo formal al introducir la definición de formas de separación de funciones;
• 1996  - Método de Sandy para hacer MAS basado en RBAC;
• 1997 - 1998  - Sybase, Secure Computing, Siemens anuncia productos RBAC descritos como basados ​​directamente en el modelo
• 1997: Secure Computing incorpora el modelo Ferriolo-Kuhn RBAC en el Sistema de control y comando global del Departamento de Defensa de EE. UU.; Se publica artículo de Kuhn sobre el tema separación de funciones, condiciones necesarias y suficientes para la seguridad de la separación;
• 1997 - Artículo de Osborne basado en la relación entre RBAC y la seguridad multinivel del modelo de política de seguridad obligatoria; anotación de rol que vincula RBAC y seguridad en capas
• 1998 - RBAC - Método de Kuhn para implementar RBAC en un sistema MAC;
• 1999  : Barkley , Ferraiolo  y Kuhn abren el prototipo inicial de RBAC para servidores web avanzados;
• 2000  - Sandi, Ferraiolo, Kuhn publican un documento que define un modelo RBAC unificado y proponen un estándar RBAC;
• 2004  - El Instituto Nacional Estadounidense de Estándares y el Comité Internacional de Estándares de Tecnología de la Información (ANSI/INCITS) adoptan el modelo RBAC propuesto por Sandy, Ferraiolo y Kuhn como un estándar único.

Modelo básico RBAC

Las siguientes convenciones se utilizan para definir el modelo RBAC:

• S = Sujeto ( Sujeto en inglés  ) = Agente humano o automatizado (conjunto de usuarios);
• R = Rol ( Rol en inglés  ) = Función de trabajo o nombre que se define en el nivel de autorización (muchos roles);
• P = Permisos ( Permissions en inglés  ) = Aserciones del modo de acceso al recurso (un conjunto de derechos de acceso a los objetos del sistema);
• SE = Session ( Sesión en inglés  ) = Correspondencia entre S, R y/o P
• SA = Asignación  de materias
• PA: R → 2 p  es una función que define un conjunto de derechos de acceso para cada rol; además, para todo p ∈ P, existe r ∈ R tal que p ∈ PA(r); ( Asignación de permisos en inglés  )
• RH = Jerarquía de funciones parcialmente ordenada .  RH también se puede escribir así: ≥
• Un sujeto puede tener múltiples roles.
• Múltiples actores pueden tener el mismo papel.
• Un rol puede tener varios permisos.
• Un permiso puede pertenecer a varios roles.

Los roles se asignan a los sujetos, por lo que los sujetos reciben ciertos permisos a través de los roles. RBAC requiere este tipo de asignación, y no la asignación directa de permisos a sujetos, de lo contrario, conduce a una relación difícil de controlar entre sujetos y permisos [3] .

La capacidad de heredar permisos de roles opuestos está sujeta a una regla restrictiva que permite lograr una adecuada separación de modos. Por ejemplo, es posible que no se le permita a la misma persona crear una cuenta para alguien y luego iniciar sesión en esa cuenta.

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

• , con permisos asignados a relaciones de roles en una relación de varios a varios.
• , donde los sujetos se asignan a relaciones de rol a actor en una relación de muchos a muchos.
• 

La notación: x ≥ y significa que x hereda los permisos de y.

Un sujeto puede tener muchas sesiones simultáneas con diferentes permisos.

Funciones y aplicaciones

La tecnología de control de acceso basada en roles es lo suficientemente flexible y fuerte para modelar tanto el control de acceso selectivo (DAC) [4] como el control de acceso obligatorio (MAC) [5]

Antes del desarrollo de RBAC, los únicos modelos de control de acceso conocidos eran MAC y DAC. La investigación en los años 90 mostró que RBAC no entraba en ninguna categoría.

Los roles se crean dentro de la organización para diversas funciones laborales. Ciertos roles tienen asignados permisos para realizar ciertas operaciones. A los miembros del personal (u otros usuarios del sistema) se les asignan roles fijos a través de los cuales reciben los privilegios apropiados para realizar funciones fijas del sistema. A diferencia del control de acceso basado en contexto (CBAC )  , una implementación RBAC pura no tiene en cuenta la situación actual (como, por ejemplo, desde dónde se estableció la conexión).

RBAC se diferencia de las listas de control de acceso ( ACL )  utilizadas en los sistemas de control de acceso selectivo tradicionales en que puede otorgar privilegios para operaciones complejas en datos compuestos, y no solo operaciones atómicas en objetos de datos de bajo nivel. Por ejemplo, una lista de control de acceso puede otorgar o denegar acceso de escritura a un determinado archivo del sistema, pero no puede restringir cómo se puede modificar ese archivo. Un sistema basado en RBAC le permite crear una actividad como abrir un "préstamo" en una aplicación financiera o completar una entrada de "prueba de azúcar en la sangre" en una aplicación médica. La asignación de un privilegio para realizar una operación tiene múltiples valores, ya que las operaciones son granulares dentro de una aplicación.

Los conceptos de jerarquía de roles y restricciones le permiten crear o modelar el control de acceso basado en celosías (LBAC )  mediante RBAC. Por lo tanto, RBAC puede ser la base y extensión de LBAC.

En organizaciones con una infraestructura de TI heterogénea que contiene docenas y cientos de sistemas y aplicaciones, ayuda el uso de una jerarquía de roles y herencia de privilegios. Sin esto, el uso de RBAC se vuelve extremadamente confuso. El artículo "Roles adicionales: un enfoque práctico para servir a los usuarios empresariales" [6] analiza estrategias alternativas a los privilegios de usuario a gran escala.

Los sistemas modernos amplían el antiguo modelo NIST [7] con las limitaciones de RBAC para la implementación en grandes empresas.

Para sistemas grandes con cientos de roles, miles de usuarios y millones de permisos, administrar roles, usuarios, permisos y sus relaciones es una tarea compleja que no es factible para un pequeño grupo de administradores de seguridad. Una oportunidad atractiva es utilizar el propio RBAC para facilitar la gobernanza descentralizada del RBAC.

RBAC se usa ampliamente para administrar los privilegios de los usuarios dentro de un solo sistema o aplicación. La lista de dichos sistemas incluye Microsoft Active Directory , SELinux , FreeBSD , Solaris , Oracle Database , PostgreSQL 8.1 , SAP R/3 , Lotus Notes y muchos otros.

Véase también

• Seguridad de información
• Autenticación

Notas

1. ↑ Ferraiolo DF, Kuhn DR (octubre de 1992). “Control de acceso basado en funciones” (PDF) . XV Jornadas Nacionales de Seguridad Informática . páginas. 554-563. Archivado (PDF) desde el original el 18 de octubre de 2011 . Consultado el 28 de julio de 2008 . Parámetro obsoleto utilizado |deadlink=( ayuda )
2. ↑ Sandhu R., Coyne EJ, Feinstein HL, Youman CE Modelos de control de acceso basados ​​en roles  (indefinido)  // IEEE Computer. - IEEE Press, 1996. - Agosto ( vol. 29 , no. 2 ). - S. 38-47 . Archivado desde el original el 5 de junio de 2011.
3. ^ División de seguridad informática del NIST - Pruebas combinatorias automatizadas para software (ACTS) . csrc.nist.gov. Consultado el 7 de julio de 2016. Archivado desde el original el 21 de junio de 2016. (indefinido)
4. ↑ . Ravi Sandhu, Qamar Munawer (octubre de 1998). “Cómo hacer control de acceso discrecional usando roles”. 3er Taller ACM sobre Control de Acceso Basado en Roles . páginas. 47-54. Parámetro obsoleto utilizado |month=( ayuda )
5. ↑ Sylvia Osborn, Ravi Sandhu, Qamar Munawer (2000). “Configuración del control de acceso basado en roles para hacer cumplir las políticas de control de acceso obligatorias y discrecionales”. ACM Transacciones sobre Seguridad de la Información y los Sistemas (TISSEC) . páginas. 85-106.
6. ↑ Más allá de los roles: un enfoque práctico para el aprovisionamiento de usuarios empresariales . Fecha de acceso: 28 de julio de 2008. Archivado desde el original el 21 de agosto de 2008. (indefinido)
7. ↑ Sandhu R., Ferraiolo DF y Kuhn DR (julio de 2000). "El modelo NIST para el control de acceso basado en roles: hacia un estándar unificado". V Taller ACM Control de Acceso Basado en Roles . páginas. 47-63. Parámetro obsoleto utilizado |month=( ayuda )

Enlaces

•  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 : estándar OASIS  XACML
• Enfoques de control de acceso: RBAC vs. ABAC  (ruso) : comparación de control de acceso basado en roles y control de acceso basado en atributos.