Control de acceso basado en roles (RBAC)

¿Qué es el control de acceso basado en roles (RBAC)?

El control de acceso basado en roles (RBAC, por Role-Based Access Control) es un modelo en el que los permisos se asocian a roles como administrador, editor o lector, y las personas obtienen acceso al recibir un rol. Para cambiar lo que puede hacer todo un grupo, editas un rol en lugar de cientos de cuentas. Según el NIST, el modelo formal se debe a Ferraiolo y Kuhn (1992) y se convirtió en el estándar ANSI/INCITS 359-2004.

RBAC responde a la pregunta de autorización, qué puede hacer esta identidad, una vez que la autenticación ha dicho quién es. Es uno de los modelos que se usan dentro de la gestión de identidades y accesos (IAM). El inicio de sesión único (SSO) decide quién entra; RBAC decide qué puede hacer después.

Conceptos básicos

Ejemplo: una aplicación SaaS

# Roles
admin: [users.create, users.delete, billing.view, billing.edit, settings.edit]
editor: [content.create, content.edit, content.publish]
viewer: [content.view]
billing-manager: [billing.view, billing.edit]

# Asignaciones de rol
alice@example.com: [admin]
bob@example.com: [editor, billing-manager]
carol@example.com: [viewer]

Bob puede editar contenido y gestionar la facturación porque tiene dos roles. Cuando entra un editor nuevo, le asignas un rol y los permisos le siguen.

Ejemplo: Kubernetes

Kubernetes incluye RBAC como grupo de API. Un Role indica qué verbos se permiten sobre qué recursos, y un RoleBinding concede ese Role a usuarios, grupos o cuentas de servicio. Este Role de la documentación de Kubernetes permite leer pods en el espacio de nombres default:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Dos detalles de la documentación importan en la práctica. Un Role siempre se limita a un espacio de nombres, mientras que un ClusterRole no. Y los permisos son puramente aditivos: no hay reglas de denegación, de modo que el acceso de un usuario es la unión de todos sus roles.

RBAC frente a ABAC y ACL

RBAC basta mientras los permisos dependan de lo que alguien hace y no de los datos que tiene delante. Cuando las reglas dependen del departamento, la región o la hora, añade comprobaciones basadas en atributos. Una lista de control de acceso (ACL) asigna permisos a cada recurso, lo que es flexible pero difícil de auditar a gran escala.

Buenas prácticas de RBAC

• Mínimo privilegio. Da a cada rol solo lo que necesita la función.
• Separación de funciones. Haz que las acciones sensibles requieran dos roles, como solicitante y aprobador.
• Asigna mediante grupos. Vincula los roles a grupos y no a usuarios sueltos, y la baja de una persona será un solo cambio.
• Nombra los roles por función. Los cargos cambian, las funciones duran más.
• Documenta cada rol. Anota para qué sirve, quién debería tenerlo y quién lo revisa.
• Limita las cuentas con acceso total. Muchas personas con acceso total ya son un riesgo.
• Concede acceso elevado de forma temporal. Retíralo automáticamente al terminar la tarea.
• Revisa y registra. Audita las asignaciones con regularidad y guarda quién concedió qué rol y cuándo.

Errores habituales

• Explosión de roles. Los roles se multiplican con la organización hasta que nadie sabe para qué sirven todos. Consolídalos con regularidad.
• Acumulación de permisos. Los roles van sumando permisos con el tiempo. Quita los que no se usan.
• Muy pocos roles. Un único rol de usuario deja a todos con demasiado o demasiado poco acceso.
• Asignaciones olvidadas. Un antiguo empleado que sigue siendo administrador significa que la baja no funciona.
• Comprobaciones de rol fijadas en el código. if user.role == 'admin' repartido por todo el código es difícil de cambiar. Comprueba permisos, no nombres de rol.
• Mezclar roles con ACL puntuales. Un RBAC a medias es confuso de auditar. Elige un modelo por recurso.

RBAC en los equipos de LoadFocus y en las pruebas de API

Los equipos de LoadFocus usan una versión pequeña de RBAC. Al invitar a un miembro eliges entre Admin, que puede ejecutar, editar y ver pruebas, y View-only, que solo puede verlas, y puedes limitar una invitación a productos concretos como las pruebas de carga, JMeter o la monitorización de API. Eso cubre el reparto habitual: los ingenieros ejecutan pruebas y las partes interesadas leen los resultados. Los pasos están en la guía de equipos (en inglés).

Cuando pruebes una API con permisos por rol, usa una credencial para cada rol. Un token de administrador y uno de lector pueden recorrer rutas de código distintas y mostrar otra latencia bajo carga, y una comprobación de permisos fallida debería devolver un 403 limpio, no un 500. El acceso entre máquinas suele ir con una clave de API. Consulta seguridad de API y la guía de pruebas de rendimiento de API con OAuth2 (en inglés) para ejecuciones autenticadas, y la monitorización de API para seguir comprobando los endpoints protegidos tras el lanzamiento.

Preguntas frecuentes

RBAC o ABAC: ¿cuál debo usar?

Usa RBAC cuando los permisos siguen funciones estables, lo que cubre la mayoría de las aplicaciones. Usa ABAC cuando el acceso depende de atributos como departamento, región u hora. Muchos sistemas combinan ambos: roles para lo general y atributos para las excepciones.

¿Puede un usuario tener más de un rol?

Sí. En la mayoría de los sistemas RBAC un usuario puede tener varios roles. En Kubernetes los permisos son aditivos, así que el usuario recibe la unión de todos sus roles, sin forma de restar.

¿Qué es la explosión de roles?

Es lo que ocurre cuando creas un rol nuevo para cada excepción hasta que hay demasiados para entenderlos o auditarlos. Suele indicar que necesitas reglas basadas en atributos para las excepciones o limpiar roles que se solapan.

¿RBAC sustituye a la autenticación?

No. La autenticación demuestra quién es alguien, RBAC decide qué puede hacer esa identidad. Necesitas ambas.

¿Qué roles tienen los equipos de LoadFocus?

Los miembros se invitan como Admin, que puede ejecutar, editar y ver pruebas, o como View-only, que solo puede verlas. También puedes limitar a un miembro a productos concretos de LoadFocus.