RBAC: qué es el control de acceso basado en roles

Cuando entras a un hotel, no puedes acabar en la lavandería ni tirarte a la piscina desde la recepción. No es educación: es que al llegar te asignan un rol. Como huésped entras a tu habitación; como visitante, a la sala de espera; como comensal, al restaurante. Nadie te da una llave maestra. Eso, llevado a los sistemas informáticos, es exactamente el control de acceso basado en roles.

Mi tesis de arranque: el problema de los permisos no es técnico, es de escala. Dar permiso a una persona es fácil; hacerlo con doscientas y que ninguno tenga más de lo que necesita, no. RBAC existe para resolver eso con una idea muy simple: no gestionas permisos por persona, los gestionas por rol. Y cuando alguien cambia de puesto, cambias su rol y ya está.

Qué es RBAC

RBAC son las siglas de Role-Based Access Control, o control de acceso basado en roles. Es un modelo de seguridad en el que los permisos se asignan a roles (administrador, contable, comercial, auditor…) y son los usuarios quienes reciben esos roles, no los permisos directamente.

La ventaja es evidente en cuanto hay movimiento: si entra alguien nuevo a contabilidad, le asignas el rol «contabilidad» y hereda exactamente lo que necesita. Si se va, se lo quitas. Nadie tiene que repasar cien permisos uno por uno.

No es una ocurrencia reciente ni un invento de marketing. El modelo lo formalizaron David Ferraiolo y Rick Kuhn en 1992, y el NIST lo adoptó como estándar ANSI/INCITS 359 en 2004, con una revisión en 2012. Ese modelo RBAC del NIST es la referencia que siguen casi todas las implementaciones que te vas a encontrar.

Antes de RBAC se usaban las ACL (listas de control de acceso), que asignan permisos usuario a usuario. El primer sistema en usarlas fue Multics, en 1965, uno de los hitos de la historia de los sistemas operativos. Funcionan, pero a escala se vuelven un laberinto: cada persona y cada recurso exige su propia entrada, y mantenerlo al día es un trabajo sin fin. La agrupación de usuarios fue el paso previo a los roles.

Y el asunto importa más de lo que parece: el control de acceso roto encabeza la lista del OWASP Top 10 de 2021, donde es el riesgo con más apariciones en los datos recogidos. RBAC no arregla eso por sí solo, pero es la base sobre la que se apoya casi todo lo demás.

Roles y permisos no son lo mismo

La confusión más habitual al empezar es tratar «rol» y «permiso» como sinónimos. No lo son, y mezclarlos es la forma más rápida de montar un modelo que no sirve. Un permiso es la autorización concreta para hacer una operación sobre un recurso: leer un pedido, editar una factura, borrar un usuario. Un rol es un paquete de permisos que corresponde a una función real del negocio: atención al cliente, contabilidad, administración.

La cadena es siempre la misma: el usuario recibe uno o varios roles, y cada rol agrupa permisos. Nunca se concede un permiso suelto a una persona. Eso es lo que hace que el modelo aguante el crecimiento, porque cuando cambian las funciones de un puesto se retoca el rol una vez y quedan actualizados todos los que lo tienen. De ahí sale un trabajo que suele infravalorarse, el role engineering: decidir qué roles existen de verdad y qué permisos lleva cada uno. Es análisis del negocio, no configuración.

Cómo funciona: los cuatro elementos

RBAC se apoya en cuatro piezas que conviene tener claras:

• Usuarios: quien accede. Puede ser una persona, un servicio o incluso un dispositivo.
• Roles: el conjunto de funciones. Un usuario puede tener varios a la vez si su trabajo lo exige.
• Permisos: qué puede hacerse sobre qué recurso. Se asignan al rol, no a la persona.
• Sesiones: el momento en que un usuario activa uno de sus roles para trabajar.

La sesión es la pieza que más se olvida: un mismo usuario activa un rol distinto según lo que hace, sin arrastrar la suma de todos sus permisos.

Un ejemplo: cómo se ve sobre el papel

Con esto ya se puede montar un modelo pequeño. Imagina una tienda con tres roles y tres recursos. La tabla de permisos sería algo así:

Rol	Pedidos	Devoluciones	Usuarios
Cliente	Ver los suyos	Solicitar	Editar su perfil
Soporte	Ver todos	Tramitar	Ver
Administrador	Ver y editar	Ver y editar	Crear y borrar

Fíjate en que nadie tiene permiso «sobre pedidos» en abstracto: cada casilla es una operación sobre un recurso concreto. Si mañana Soporte necesita ver datos de facturación, se añade el permiso al rol Soporte y lo heredan las diez personas que lo tienen. En un modelo por usuario habría que tocar diez fichas y acordarse de todas, incluidas las que están de baja.

RBAC vs ABAC (y otros modelos de acceso)

RBAC no es el único modelo, y elegir mal tiene consecuencias. Los principales:

Modelo	En qué se basa	Cuándo encaja
ACL	Usuarios y recursos, uno a uno	Sistemas pequeños o muy simples
RBAC	En el rol del usuario	Organizaciones con funciones claras
ABAC	En atributos (departamento, ubicación, hora, antigüedad…)	Reglas finas y cambiantes
MAC	En etiquetas de seguridad impuestas por el sistema	Entornos de alta seguridad (militar, gobierno)
DAC	El dueño del recurso decide quién entra	Sistemas de escritorio

La diferencia entre RBAC y ABAC (Attribute-Based Access Control) es la que más se pregunta. En RBAC decides por el rol: «los comerciales acceden a la ficha de cliente». En ABAC decides por atributos: «los comerciales de la delegación de Sevilla, en horario laboral, acceden a la ficha de cliente». ABAC es más flexible y más potente, y también bastante más difícil de diseñar bien: es una aproximación basada en reglas, cómoda de montar y complicada de mantener cuando crece.

Ojo: no son excluyentes. Muchos sistemas combinan los dos, con el rol como base y los atributos para afinar los casos concretos, que es justo lo que estudió el NIST.

Los niveles del estándar

El estándar no describe un único RBAC, sino una familia con cuatro niveles que se van apilando, y eso explica por qué dos herramientas que dicen «RBAC» no ofrecen lo mismo:

• RBAC básico (RBAC0). El mínimo: usuarios, roles, permisos y sesiones, con roles planos y sin relación entre ellos.
• RBAC jerárquico (RBAC1). Un rol puede heredar los permisos de otro, el clásico responsable que puede hacer todo lo de su equipo y algo más.
• RBAC restringido (RBAC2). Añade la separación de funciones: dos permisos incompatibles no pueden recaer en la misma persona. Quien aprueba un pago no debería poder ejecutarlo.
• RBAC simétrico (RBAC3). Combina jerarquía y restricciones, lo que acaban implementando las herramientas serias.

Casi nadie necesita RBAC3, pero casi todos necesitan RBAC2 en cuanto entran en juego dinero, datos personales o auditorías.

Dónde te lo encuentras ya implementado

RBAC rara vez hay que añadirlo por encima del sistema: suele venir dentro. Antes de diseñarlo desde cero, mira qué trae ya la plataforma. Ejemplos que probablemente ya usas sin llamarlo así:

• Sistemas operativos. En Linux, los grupos del sistema y sudoers son un RBAC rudimentario, y Solaris lleva décadas con roles, perfiles y autorizaciones propios.
• Directorio corporativo. En Active Directory, los grupos de seguridad hacen de roles: perteneces a un grupo y heredas sus permisos.
• Contenedores y nube. Kubernetes tiene objetos Role, ClusterRole y RoleBinding, y Microsoft documenta Azure RBAC como su sistema de autorización nativo sobre los recursos.
• Bases de datos. Casi todas permiten crear roles con GRANT y asignarles privilegios sobre tablas y vistas.

Ventajas de RBAC

Se implanta por cuatro razones que se notan enseguida:

• Menos riesgo. Con los roles bien definidos, cada persona tiene solo lo que necesita, y eso reduce mucho la superficie de un posible incidente, sea un atacante de fuera o un virus informático que se cuela por donde no debía.
• Menos trabajo. Las altas y bajas se resuelven asignando o retirando un rol, no repasando permisos sueltos.
• Cumplimiento. Muchas normativas de privacidad y confidencialidad exigen control de acceso; RBAC ayuda a demostrarlo ante una auditoría.
• Escalabilidad. Sirve igual para empresas pequeñas que para organizaciones grandes con cientos de funciones.

Desventajas y errores típicos

No es gratis ni automático. Estos son los problemas que aparecen una y otra vez:

• Explosión de roles. Si cada mínima diferencia crea un rol nuevo, acabas con cientos y vuelves al caos que querías evitar. Con muchas funciones y departamentos, el número de roles se dispara si no se diseña con cabeza.
• El diseño cuesta. Lo más difícil no es la herramienta: es traducir cómo funciona de verdad la organización a un mapa de roles. Eso es trabajo de análisis, no de configuración.
• Permisos temporales. Cuando alguien necesita un extra puntual, los roles pueden volverse una camisa de fuerza. Se resuelve con roles temporales o con atributos (ABAC) para los casos excepcionales.
• Roles heredados sin revisar. El error clásico: se monta el modelo, todo el mundo cambia de puesto, y nadie retira los roles antiguos. Con el tiempo, casi todos acaban con permisos de más.

Las tres reglas de oro

Para que RBAC funcione, hay tres reglas que se aplican en este orden:

1. Asignación de roles: solo puedes ejercer un permiso si antes se te ha asignado el rol.
2. Autorización de roles: solo puedes activar un rol si estás autorizado para él.
3. Autorización de permisos: solo puedes ejercer un permiso si ese permiso pertenece al rol que tienes activo.

Las tres juntas garantizan lo mismo: que nadie hace nada para lo que no está autorizado. Y todas parten de un principio que no es exclusivo de RBAC pero que aquí se aplica solo: el principio de mínimo privilegio, dar a cada quien lo imprescindible para su trabajo y nada más.

Buenas prácticas: cómo evitar que el modelo se pudra

Un modelo RBAC se estropea por abandono, no por mal diseño. Estas son las prácticas que marcan la diferencia entre uno que aguanta años y otro que acaba en un cementerio de roles:

• Mínimo privilegio por defecto. Se empieza sin permisos y se concede lo justo; nunca al contrario. El NIST lo recoge como control explícito en su catálogo de seguridad.
• Revisión periódica. Cada cierto tiempo se revisa quién tiene qué y se retiran los roles que ya no tocan. En entornos regulados esto se llama recertificación y no es opcional.
• Altas y bajas atadas al ciclo de vida. Cuando alguien entra se le asigna el rol; cuando sale se le retira todo. Muchos incidentes internos vienen de accesos que nadie cerró a tiempo.
• Reutilizar lo que ya existe. La plataforma suele traer RBAC. La guía de control de acceso de OWASP insiste en lo mismo: un único mecanismo, bien hecho, reutilizado en todas partes.

Preguntas frecuentes

¿Qué es RBAC y qué significa?

Role-Based Access Control, o control de acceso basado en roles. Un modelo de seguridad en el que los permisos se asignan a roles y los usuarios reciben esos roles, en lugar de permisos individuales.

¿Qué diferencia hay entre RBAC y ABAC?

RBAC decide según el rol del usuario; ABAC decide según atributos (departamento, ubicación, hora, antigüedad). ABAC permite reglas más finas, a costa de más complejidad. No son excluyentes: se pueden combinar.

¿Cuál es la diferencia entre RBAC y ACL?

Las ACL asignan permisos usuario a usuario y recurso a recurso, lo que no escala bien. RBAC agrupa permisos en roles reutilizables, de modo que gestionar el acceso no se convierte en un trabajo infinito.

¿Qué es el principio de mínimo privilegio?

Dar a cada usuario solo los permisos imprescindibles para su trabajo. Es la base sobre la que se construye cualquier modelo de control de acceso razonable, no solo RBAC.

¿RBAC es obligatorio por normativa?

No con ese nombre, pero muchas normativas de privacidad y seguridad exigen control de acceso y trazabilidad de permisos. RBAC es una forma habitual y bien vista de cumplir esos requisitos.

Conclusión

RBAC resuelve un problema muy real con una idea casi de sentido común: los permisos van con el puesto, no con la persona. Bien diseñado, reduce riesgos y ahorra un montón de trabajo administrativo. Mal diseñado (o dejado sin revisar) se convierte en un cementerio de roles que ya nadie usa y que casi nadie recuerda haber concedido.

Como casi todo en seguridad, no es un producto que se instala: es una disciplina que se mantiene. Y si quieres ver la otra cara de la moneda, la de quien intenta entrar donde no debe, aquí tienes qué es un hacker.