RBAC y ABAC: Los modelos de control de acceso que debes conocer

Introducción#

El control de acceso es un aspecto crítico de la seguridad en cualquier sistema. Garantiza que solo los usuarios autorizados puedan acceder a los recursos y realizar acciones. El control de acceso basado en roles (RBAC) y el control de acceso basado en atributos (ABAC) son dos de los modelos de control de acceso más populares usados en los sistemas modernos. Ambos modelos son ampliamente adoptados y pueden usarse para hacer cumplir las políticas de control de acceso de manera efectiva. Pero, ¿qué son y en qué se diferencian?

Control de acceso basado en roles (RBAC)#

El control de acceso basado en roles (RBAC) fue introducido por primera vez a principios de la década de 1990. Se atribuye la formalización del modelo a David Ferraiolo y Rick Kuhn en un documento publicado en 1992. Desde entonces, RBAC se ha convertido en uno de los modelos de control de acceso más utilizados en la industria.

En RBAC, las políticas de control de acceso se basan en roles, que son colecciones de permisos. A los usuarios se les asignan roles (por ejemplo, administrador, editor, espectador) y sus derechos de acceso se determinan por los permisos (por ejemplo, crear, editar, eliminar) para recursos específicos (por ejemplo, archivos, bases de datos, aplicaciones). Simplifica la gestión de las políticas de control de acceso agrupando a los usuarios según sus roles y asignando permisos a los roles. Es sencillo agregar o quitar usuarios de roles, y los cambios se reflejarán automáticamente en las políticas de control de acceso.

Componentes clave de RBAC#

• Recurso: Un recurso es una entidad a la que un usuario puede acceder. Los recursos pueden ser cualquier cosa, desde archivos, bases de datos, API o cualquier otra entidad del sistema que necesite ser protegida.
• Permiso: Un permiso es una acción específica que un usuario puede realizar sobre un recurso. Por ejemplo, crear, editar, eliminar, ver. La definición de permisos puede variar dependiendo del sistema. En la mayoría de los casos, los permisos se definen al nivel del recurso con una granularidad mínima.
• Rol: Un rol es una colección de permisos que define un conjunto de acciones que un usuario puede realizar. Por ejemplo, un rol de administrador puede tener permisos para crear, editar y eliminar recursos, mientras que un rol de espectador puede tener permiso para ver recursos.
• Usuario: Un usuario es una entidad a la que se le pueden asignar uno o más roles. Los usuarios obtienen acceso a los recursos basados en los permisos asociados con los roles que se les asignan.

Variantes de RBAC#

Existen varias variantes de RBAC que extienden el modelo básico para acomodar requisitos de control de acceso más complejos:

• RBAC0: El modelo básico donde se asignan roles a los usuarios y permisos a los roles.
• RBAC1: Añade el concepto de jerarquías de roles. Los roles pueden heredar permisos de otros roles. También se conoce como RBAC jerárquico.
• RBAC2: Añade restricciones a los roles. Las restricciones pueden usarse para definir condiciones adicionales que deben satisfacerse para que un usuario sea asignado a un rol. También se conoce como RBAC basado en restricciones.
• RBAC3: Combina las características de RBAC1 y RBAC2. Soporta tanto jerarquías de roles como restricciones.

Para más información sobre estas variantes, consulta Modelos RBAC y su evolución.

Ventajas de RBAC#

• Simplicidad: RBAC es fácil de entender e implementar. Asignar permisos a roles y roles a usuarios es sencillo.
• Eficiencia: Simplifica la gestión de las políticas de control de acceso agrupando a los usuarios según sus roles. Es fácil agregar o quitar usuarios de roles sin cambiar las políticas de control de acceso. Especialmente en grandes organizaciones con estructuras de permisos bien definidas, RBAC puede ser muy eficiente.
• Transparencia: RBAC proporciona un mapeo claro entre roles, permisos y usuarios. Es fácil auditar y revisar las políticas de control de acceso.

Desventajas de RBAC#

• Rigidez: RBAC puede ser rígido cuando se trata de definir políticas de control de acceso complejas. Puede no ser adecuado para sistemas donde las políticas de control de acceso necesitan ser más dinámicas y conscientes del contexto.
• Granularidad: RBAC puede carecer de la granularidad requerida para un control de acceso detallado. Las políticas de control de acceso están vinculadas a roles bien definidos, y puede requerir esfuerzo extra definir permisos a un nivel más granular.
• Explosión de roles: En grandes organizaciones con estructuras de permisos complejas, el número de roles puede crecer exponencialmente, conduciendo a una explosión de roles. Gestionar un gran número de roles puede ser un desafío.

Control de acceso basado en atributos (ABAC)#

A finales de la década de 2000, a medida que los sistemas se volvían más complejos y dinámicos, más y más organizaciones comenzaron a adoptar el control de acceso basado en atributos (ABAC) como una alternativa a RBAC. Un hito notable en la formalización de ABAC es la publicación de la Publicación Especial 800-162 del NIST en 2014.

ABAC es un modelo de control de acceso más flexible comparado con RBAC. Es un modelo de autorización que define políticas de control de acceso basado en los atributos del usuario, recurso, acción y entorno. Permite a las organizaciones definir políticas de control de acceso detalladas que pueden adaptarse a diferentes contextos y condiciones.

Componentes clave de ABAC#

• Sujeto: Un sujeto es una entidad que solicita acceso a un recurso. Puede ser un usuario, un dispositivo, una aplicación, o cualquier otra entidad que necesite acceder a recursos.
• Recurso: Al igual que en RBAC, un recurso es una entidad a la que un sujeto puede acceder. Los recursos pueden ser archivos, bases de datos, API, o cualquier otra entidad del sistema.
• Acción: Una acción es una operación específica que un sujeto puede realizar sobre un recurso. Puede ser crear, leer, actualizar, eliminar, o cualquier otra operación que necesite ser controlada.
• Entorno: El entorno es el contexto en el que se realiza la solicitud de acceso. Puede incluir atributos como hora del día, ubicación, red, dispositivo, etc.
• Atributo: Un atributo es una característica de un sujeto, recurso, acción o entorno. Los atributos pueden ser cualquier cosa, desde roles de usuario, departamento, ubicación, dirección IP, tipo de dispositivo, etc.
• Política: Una política es una regla que define las condiciones bajo las cuales se concede o niega el acceso. Las políticas se definen con base en los atributos.

Ventajas de ABAC#

• Flexibilidad: ABAC puede acomodar políticas de control de acceso complejas que se basan en múltiples atributos. Permite a las organizaciones definir políticas detalladas que pueden adaptarse a diferentes contextos y condiciones.
• Dinámico: Las políticas de ABAC pueden ser dinámicas y conscientes del contexto. Las decisiones de control de acceso pueden basarse en atributos en tiempo real como ubicación, hora del día, tipo de dispositivo, etc.
• Granularidad: ABAC proporciona control de acceso detallado al permitir que las organizaciones definan políticas con base en múltiples atributos. A diferencia de definir roles y permisos, las políticas basadas en atributos pueden ser más granulares.

Desventajas de ABAC#

• Complejidad: ABAC puede ser más complejo de implementar y gestionar comparado con RBAC. Definir atributos y políticas puede requerir más esfuerzo y experiencia. A diferencia de RBAC, donde los roles y permisos están bien estructurados, los atributos pueden ser más dinámicos y, por ende, también las políticas. Gestionar un gran número de atributos y políticas en un sistema complejo puede ser un desafío. A menudo se requiere un motor de evaluación de políticas centralizado para evaluar las políticas.
• Rendimiento: La evaluación de atributos puede impactar el rendimiento, especialmente en entornos en tiempo real. Las políticas basadas en múltiples atributos y condiciones en tiempo real pueden introducir latencia en las decisiones de control de acceso.

Tabla de comparación#

A partir de la tabla de comparación, está claro que RBAC es más adecuado para sistemas con estructuras de permisos bien definidas y donde las políticas de control de acceso son relativamente estáticas. Por otro lado, ABAC es más adecuado para sistemas donde las políticas de control de acceso necesitan ser dinámicas, conscientes del contexto y detalladas.

Ejemplos#

Escenario: Un sistema hospitalario que necesita gestionar el acceso a los registros de pacientes para diferentes miembros del personal.

• Personal: Médicos, Enfermmeras, Administradores
• Recursos: Registros de pacientes
• Permisos: Leer, Escribir, Eliminar

Caso 1#

Las políticas de control de acceso son relativamente simples:

1. Los médicos pueden leer y escribir registros de pacientes.
2. Las enfermeras pueden leer registros de pacientes.
3. Los administradores pueden leer, escribir y eliminar registros de pacientes.

Modelo RBAC#

En este caso, RBAC es simple y efectivo. Podemos definir roles para médicos, enfermeras y administradores, y asignar los permisos apropiados a cada rol.

La evaluación de control de acceso es sencilla:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

Modelo ABAC#

En este caso, ABAC podría ser excesivo, pero aún puede usarse para definir políticas detalladas basadas en atributos como departamento, rol, etc.

Atributos:

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

Políticas:

• Política 1: Permitir acceso de lectura con base en user.role y resource.name
  • subject: Usuario con rol doctor, nurse, admin
  • resource: Recurso con nombre patient-record
  • action: read
  • effect: permitir
  • rationale: "Permitir acceso de lectura a registros de pacientes para todos los roles"
• Política 2: Acceso de edición para médicos y administradores
  • subject: Usuario con rol doctor, admin
  • resource: Recurso con nombre patient-record
  • action: write
  • effect: permitir
  • rationale: "Permitir acceso de escritura a registros de pacientes para médicos y administradores"
• Política 3: Acceso de eliminar para administradores
  • subject: Usuario con rol admin
  • resource: Recurso con nombre patient-record
  • action: delete
  • effect: permitir
  • rationale: "Permitir acceso de eliminación a registros de pacientes para administradores"

Para cada solicitud de lectura/escritura/eliminación, el motor de políticas evalúa todas las políticas relevantes basadas en los atributos y toma una decisión de control de acceso.

Comparación#

En este caso, las políticas de control de acceso son simples y bien estructuradas. Solo requiere un chequeo de permiso de un solo nivel para determinar si un usuario tiene acceso a un recurso. Imagina que el sistema hospitalario tiene una estructura más compleja con múltiples departamentos, roles y permisos:

• En un modelo RBAC, el proceso de evaluación de control de acceso del recurso de registros de pacientes seguirá siendo simple y directo, ya sea que el usuario tenga el permiso de read, write o delete;
• ABAC, por otro lado, necesitaría involucrar atributos adicionales como department-id y doctor-id. ¿Qué pasa si un dispositivo IoT necesita acceder a los registros de pacientes? Requerirá la introducción de un nuevo atributo device-id en la evaluación de políticas. ¿Y si se concede el permiso de read temporalmente a un médico interno?

En conclusión, RBAC es una mejor opción. RBAC es simple y eficiente para sistemas con estructuras de permisos bien definidas y donde las políticas de control de acceso son estáticas.

Caso 2#

El mismo sistema hospitalario, ahora vamos a introducir un nuevo rol patient y un nuevo atributo patient-id.

Las políticas de control de acceso son:

1. Los médicos pueden leer y escribir registros de pacientes.
2. Las enfermeras pueden leer registros de pacientes.
3. Los administradores pueden leer, escribir y eliminar registros de pacientes.
4. Los pacientes pueden leer sus propios registros.

Modelo RBAC#

En este caso, aparte del antiguo permiso de read, necesitamos introducir un nuevo permiso read-own. Podemos definir roles para médicos, enfermeras, administradores y pacientes, y asignar los permisos apropiados a cada rol.

Ahora la evaluación de control de acceso es un poco más compleja, especialmente para la acción de read de los registros de pacientes:

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

Modelo ABAC#

Ahora actualicemos los atributos y políticas en el modelo ABAC para acomodar los nuevos requisitos.

Atributos:

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

Políticas:

• Política 1: Permitir acceso de lectura a todos los registros de pacientes
  • subject: Usuario con rol doctor, nurse, admin
  • resource: Recurso con nombre patient-record
  • action: read
  • effect: permitir
  • rationale: "Permitir acceso de lectura a registros de pacientes para todo el personal y el propio paciente"
• Política 2: Permitir acceso de escritura a todos los registros de pacientes para médicos y administradores
  • subject: Usuario con rol doctor, admin
  • resource: Recurso con nombre patient-record
  • action: write
  • effect: permitir
  • rationale: "Permitir acceso de escritura a registros de pacientes para médicos y administradores"
• Política 3: Permitir acceso de eliminación a todos los registros de pacientes para administradores
  • subject: Usuario con rol admin
  • resource: Recurso con nombre patient-record
  • action: delete
  • effect: permitir
  • rationale: "Permitir acceso de eliminación a registros de pacientes para administradores"
• Política 4: Permitir acceso de lectura a sus propios registros de pacientes
  • subject: Usuario con rol patient
  • resource: Recurso con nombre patient-record
  • action: read
  • condition: user.id === resource.patient-id
  • effect: permitir
  • rationale: "Permitir acceso de lectura a sus propios registros de pacientes"

Comparación#

En este caso, las políticas de control de acceso son más complejas y conscientes del contexto. El proceso de evaluación de control de acceso del recurso de registros de pacientes requerirá múltiples niveles de verificación de permisos para determinar si un usuario tiene acceso a un recurso.

• En un modelo RBAC, el proceso de evaluación de control de acceso del recurso de registros de pacientes requerirá múltiples niveles de verificación de permisos para determinar si un usuario tiene acceso a un recurso. Por ejemplo, para determinar si un paciente tiene acceso a sus propios registros, el sistema necesita verificar si el usuario tiene el permiso de read-own y si el id del usuario coincide con el id del paciente.
• En un modelo ABAC, el proceso de evaluación de control de acceso puede ser más directo. Las políticas pueden definirse basadas en los atributos del usuario, recurso y acción. Por ejemplo, para determinar si un paciente tiene acceso a sus propios registros, el motor de políticas puede evaluar la política basada en el id del usuario y el id del paciente.

En este caso, ABAC puede ser una mejor opción. ABAC es más adecuado para sistemas donde las políticas de control de acceso necesitan ser dinámicas, conscientes del contexto y detalladas.

Conclusión#

La elección entre RBAC y ABAC depende de los requisitos específicos del sistema. RBAC es más adecuado para sistemas con estructuras de permisos bien definidas y donde las políticas de control de acceso son estáticas. ABAC es más adecuado para sistemas donde las políticas de control de acceso necesitan ser dinámicas, conscientes del contexto y detalladas. En la práctica, las organizaciones pueden optar por usar una combinación de ambos modelos para lograr el nivel deseado de control de acceso.