RBAC - Control de acceso basado en roles
Lectura de 2 min aprox.
RBAC (Role-Based Access Control, control de acceso basado en roles) es un modelo de control de acceso que gestiona los permisos a través de «roles» en lugar de otorgarlos directamente a los usuarios. Fue propuesto por David Ferraiolo y Richard Kuhn en el NIST en 1992 y estandarizado como ANSI/INCITS 359 en 2004. Al agrupar los permisos en roles como «gerente de ventas», «desarrollador» o «auditor» y simplemente asignar roles a los usuarios, simplifica drásticamente la gestión de permisos en grandes organizaciones. Es un concepto central de IAM y el método de implementación más adoptado para el control de acceso.
Los tres niveles del modelo RBAC del NIST
El NIST define RBAC en tres niveles ampliables de forma incremental. Se elige hasta qué nivel implementar según la escala y los requisitos de la organización.
El modelo básico. Se compone de cuatro elementos: usuarios, roles, permisos y sesiones. Los roles se asignan a los usuarios y los permisos se vinculan a los roles. Este nivel es suficiente para la mayoría de los sistemas.
Introduce relaciones jerárquicas (herencia) entre roles. Un rol de «jefe de departamento» hereda automáticamente los permisos del rol de «jefe de sección». La jerarquía organizativa puede mapearse directamente en la jerarquía de roles, eliminando definiciones de permisos redundantes.
Añade restricciones de separación de funciones (SoD: Separation of Duties). Al definir restricciones de exclusividad, como no permitir que un mismo usuario tenga asignados los roles de «contable» y «aprobador», previene de forma estructural el fraude y los errores operativos.
Comparación entre RBAC, ABAC y PBAC
RBAC no es el único modelo de control de acceso. Es importante compararlo con los modelos basados en atributos (ABAC) y basados en políticas (PBAC) y elegir el que se ajuste a tus requisitos.
| Aspecto | RBAC | ABAC | PBAC |
|---|---|---|---|
| Criterio de decisión | Rol | Atributos de usuarios, recursos y entorno | Política (motor de reglas) |
| Granularidad | Gruesa (por rol) | Fina (combinaciones de atributos) | La más flexible (condiciones arbitrarias) |
| Facilidad de adopción | Fácil | Media | Compleja |
| Coste de gestión | Proporcional al número de roles | Mantenimiento de las definiciones de atributos | Mantenimiento de la coherencia de las políticas |
| Casos adecuados | Empresas con una estructura organizativa clara | Cuando se requieren decisiones condicionales dinámicas | Reglas de negocio complejas |
| Implementaciones representativas | Roles de AWS IAM, Kubernetes RBAC | Condiciones de políticas de AWS IAM, Azure ABAC | OPA (Open Policy Agent) |
En los sistemas reales, cada vez son más comunes los enfoques híbridos que combinan RBAC y ABAC. AWS IAM es una implementación híbrida típica: tiene una estructura central basada en roles a la que se pueden añadir condiciones basadas en atributos mediante el elemento Condition.
Relación con el principio de mínimo privilegio
El principio de mínimo privilegio es un principio de seguridad fundamental que establece que se deben «otorgar solo los permisos mínimos necesarios para la tarea». RBAC puede considerarse un mecanismo para materializar este principio a nivel organizativo. Si los roles se diseñan adecuadamente, se puede eliminar de forma estructural el riesgo de otorgar permisos excesivos a usuarios individuales. Sin embargo, si el diseño de roles es demasiado tosco, pueden surgir permisos excesivos, como que «el rol de desarrollador incluya permisos de eliminación del entorno de producción». La granularidad del diseño de roles determina la eficacia del mínimo privilegio.
El problema de la explosión de roles (Role Explosion)
El mayor desafío de RBAC es la «explosión de roles», en la que el número de roles aumenta de forma explosiva a medida que la organización se vuelve más compleja. Si se crean roles a partir de combinaciones de departamento × puesto × proyecto × entorno, surgen de cientos a miles de roles y la gestión se vuelve inviable.
Para prevenir la explosión de roles, es eficaz un enfoque híbrido: limitar la granularidad de los roles a «funciones de trabajo» y gestionar las distinciones de departamento y proyecto mediante condiciones de atributos de ABAC. También son imprescindibles las revisiones periódicas de roles (auditar cómo se usan los roles y consolidar o eliminar los innecesarios).
Implementaciones de RBAC en las principales plataformas
Se adjuntan políticas (JSON) a los roles de IAM y los usuarios o servicios asumen los roles (AssumeRole). Los roles también se usan para el acceso entre cuentas.
Se definen los permisos de operación sobre los recursos con Role / ClusterRole y se vinculan a usuarios o cuentas de servicio con RoleBinding / ClusterRoleBinding. Es posible el aislamiento a nivel de espacio de nombres.
Combina roles de directorio (Global Admin, User Admin, etc.) con roles personalizados específicos de la aplicación. PIM (Privileged Identity Management) permite la concesión Just-In-Time de roles con privilegios.
RBAC también es la base de la arquitectura de confianza cero y es un elemento que siempre se verifica en las auditorías de cumplimiento. Consulta también la política de contraseñas corporativa, la lista de verificación de seguridad para startups y la seguridad de confianza cero.libros sobre control de acceso (Amazon) se recomiendan para aprender en profundidad los patrones de diseño.
¿Te resultó útil este artículo?