El control de acceso basado en roles (RBAC) es un modelo de autorización dentro de la IAM que define quién puede acceder a qué recursos en su aplicación.

El RBAC responde a la pregunta de autorización básica: “¿Qué puede hacer este usuario autenticado?”. En lugar de asignar permisos individuales a cada usuario, se agrupan los permisos en roles. A cada usuario se le asignan uno o más roles, cada uno con un conjunto definido de permisos. Este enfoque simplifica la gestión de usuarios, aumenta la seguridad y se adapta bien a las aplicaciones modernas.

El modelo de RBAC se define por la relación entre usuarios, roles y permisos.

• Usuario: Es una persona o entidad autenticada que busca acceso a un sistema.
• Permiso (o privilegio): Es el derecho granular a realizar una acción específica sobre un recurso.
  Los permisos se expresan con pares acción/recurso:
  • read:Patients
  • update:Settings
  • delete:Posts
• Rol: Es un conjunto de permisos que define una función laboral específica o un nivel de acceso dentro de la aplicación (un solo usuario puede ocupar varios roles).

¿Cómo funciona el RBAC?

El RBAC se aplica mediante tres pasos lógicos:

1. Definir permisos. Determinar el nivel más bajo de acciones que un usuario puede realizar en la aplicación (por ejemplo, create, read, update o delete para un recurso determinado).
2. Asignar permisos a los roles. Agrupar permisos en roles lógicos (por ejemplo, el rol de administrador puede tener todos los permisos, mientras que el rol de lector solo tiene permisos de lectura).
3. Asignar roles a los usuarios. Otorgar a los usuarios los roles que se ajusten a sus responsabilidades.

Cuando un usuario inicia el acceso a un recurso, el sistema comprueba los roles asignados al usuario para determinar si, en conjunto, poseen el permiso necesario.

El RBAC proporciona un equilibrio entre sencillez y seguridad para las aplicaciones impulsadas por API.

• Gestión simplificada: En lugar de gestionar permisos para miles de usuarios individuales, se gestiona un conjunto más reducido de roles. Cambiar los permisos de un rol actualiza de forma inmediata el acceso para todos los usuarios asignados.
• Claridad y preparación para auditorías: Los roles de RBAC proporcionan una asignación de privilegios de acceso que los humanos pueden leer y la máquina puede implementar, lo que facilita la auditoría y el cumplimiento del principio de seguridad de privilegio mínimo.
• Escalabilidad: A medida que una aplicación crece, es posible incorporar usuarios asignándoles roles preexistentes, en lugar de crear nuevos conjuntos de permisos complejos.

Imagina una API típica de backend de comercio electrónico con los siguientes recursos clave: productos (Products), pedidos (Orders), clientes (Customers) y análisis (Analytics).

Ejemplo de usuarios con permisos según el rol

Rol	Permisos	Ejemplo de usuario
administrador	Todos los permisos en todos los recursos	Sarah
Gerente de inventario	create:Products, read:Products, update:Products	Matteo y Priya
Agente de soporte	read:Orders, read:Customers	Liam
Analista	read:Analytics	David

Cuando Priya (gerente de inventario) intenta:

• ver una lista de productos, el acceso se concede porque el rol de gerente de inventario incluye el permiso read:Products
• editar una descripción del producto, el acceso se concede porque el rol de gerente de inventario incluye el permiso update:Products
• ver los datos personales de un cliente, el acceso se deniega porque el rol de gerente de inventario no incluye el permiso read:Customers

Este ejemplo ilustra cómo los permisos se heredan automáticamente a través del rol, lo que brinda un control de acceso detallado sin requerir una asignación directa entre usuario y permiso.

En una plataforma SaaS B2B donde varias organizaciones de clientes comparten la misma infraestructura de aplicaciones, RBAC utiliza los ámbitos de la organización. Un usuario puede desempeñar diferentes roles en distintas organizaciones.

Cuando un usuario se autentica, el sistema de autorización debe evaluar no solo el rol del usuario, sino el rol del usuario en esa organización específica. El JWT incluye tanto la identidad del usuario como un identificador de la organización, lo que garantiza que se hagan cumplir los permisos basados en roles dentro del límite correcto del inquilino. Esto evita la escalada de privilegios entre organizaciones de clientes y mantiene un estricto aislamiento de datos en arquitecturas multiinquilino.

Aunque el RBAC funciona bien para la mayoría de las aplicaciones, otros modelos de AuthZ podrían ser más adecuados para situaciones más complejas.

Modelo	Enfoque	Caso de uso	Cuándo usarlo
Control de acceso basado en roles (RBAC)	Función o rol laboral del usuario	Aplicación empresarial con grupos de usuarios estáticos y claramente definidos (administrador, editor, lector)	Más común y suficiente para aplicaciones donde los permisos son previsibles
Control de acceso basado en atributos (ABAC)	Atributos de usuario, atributos de recurso, atributos de entorno	Acceso determinado por expresiones dinámicas de políticas (por ejemplo, [if user.department == resource.department]) o factores contextuales (por ejemplo, ubicación, hora del día)	Cuando las decisiones de autorización son complejas y dependen del contexto
Control de acceso basado en relaciones (ReBAC)	Relaciones entre usuarios y recursos	Plataformas de redes sociales (p. ej., “solo el propietario de esta publicación puede eliminarla”) o aplicaciones multiinquilino	Cuando la autorización depende de la propiedad o de una relación directa entre el usuario y los datos

El RBAC proporciona una autorización sólida para la mayoría de las aplicaciones, especialmente cuando los permisos de usuario coinciden con los roles definidos en la organización. Para la mayoría de las aplicaciones SaaS B2B, el RBAC (potencialmente mejorado con comprobaciones básicas de atributos) proporciona un control de acceso suficiente sin añadir complejidad innecesaria.

Sin embargo, el RBAC alcanza sus límites cuando las decisiones de acceso requieren un contexto que los roles por sí solos no pueden captar. Si necesita hacer cumplir reglas como “los usuarios solo pueden editar los documentos que ellos crearon” o “el acceso está restringido fuera del horario laboral”, estas situaciones implican relaciones con recursos específicos o atributos del entorno. En estos casos, los modelos de ABAC o ReBAC se vuelven necesarios para evitar desarrollar soluciones complejas con el RBAC.

En arquitecturas modernas impulsadas por API, los tokens de acceso aplican el RBAC. Proteja sus API con protocolos como OAuth 2.0 y OpenID Connect (OIDC). (En OAuth 2.0, los ámbitos representan permisos; traduzca los roles a ámbitos o atributos personalizados según la implementación del IdP).

1. Autenticación (AuthN): El usuario inicia sesión con un proveedor de identidades (IdP).
2. Asignación de autorización: El IdP determina los roles del usuario y los permisos correspondientes en función del modelo de RBAC definido.
3. Emisión de token: El IdP genera un token de acceso web JSON (JWT). La carga útil del JWT contiene atributos, como roles, ámbitos o parámetros personalizados, que las API de etapa final emplean para hacer cumplir el RBAC.
4. Implementación de la API (AuthZ): Cuando el usuario realiza una llamada a la API, la API de backend valida el JWT. Luego, verifica los atributos de roles/permisos dentro del token para aplicar las reglas del RBAC antes de conceder acceso a un recurso o acción.

Este enfoque basado en tokens hace que la API no tenga estado. Los datos de autorización necesarios están dentro del token y están firmados criptográficamente.

Aunque los JWT ofrecen una forma escalable y sin estado de hacer cumplir el RBAC al incluir los datos de roles y permisos en el token de acceso, siga estas prácticas de seguridad para evitar vulnerabilidades:

• Principio de privilegio mínimo: Asigne solamente los roles y permisos mínimos necesarios para la función laboral de un usuario.
• Duración y revocación del token: Los tokens de acceso JWT son difíciles de revocar inmediatamente porque se validan a nivel local.
  • Recomendación: Use tokens de acceso de corta duración (por ejemplo, de 15 a 60 minutos) y haga que los tokens de actualización roten.
• Validación del lado del servidor: Valide cada JWT en cada solicitud teniendo en cuenta lo siguiente:
  • Integridad (verifique la firma del token)
  • Vencimiento (verifique el atributo exp)
  • Público (confirme que el atributo aud coincida con su aplicación)
  • Autoridad (compruebe que el atributo iss coincida con el emisor previsto)
  • Rotación de claves (valide los tokens con el conjunto de claves web JSON [JWKS] del IdP para admitir la rotación de claves y mantener la integridad de la firma)
• Almacenamiento de roles y permisos: Incluya solamente los atributos necesarios de roles y permisos, y evite datos personales confidenciales.
• Almacenamiento de tokens: Nunca almacene tokens con datos confidenciales en localStorage ni en sessionStorage, ya que esto puede provocar ataques de Cross-Site Scripting (XSS). Use cookies HttpOnly seguras o almacenamiento de sesión en backend.
• Gestione los errores de manera clara: Cuando la API reciba una solicitud, devuelva códigos de estado HTTP específicos según el tipo de error.
  • 401 - No autorizado: El usuario no pudo demostrar su identidad (error de autenticación, p. ej., el token falta o no es válido).
  • 403 - Prohibido: La identidad del usuario es conocida (se autenticó), pero sus roles/permisos (RBAC) no le permiten acceder al recurso o la acción solicitados (error de autorización).

¿Cuál es el principal beneficio del RBAC?

El RBAC permite una gestión de usuarios más sencilla y mejora la preparación para auditorías. Se gestiona un conjunto pequeño de roles en lugar de una matriz grande y compleja de permisos individuales de usuario.

¿Es el RBAC un modelo de seguridad sólido?

Sí, el RBAC es un modelo de autorización sólido y fundamental para aplicaciones donde las funciones y permisos de los usuarios son estáticos y previsibles.

¿El RBAC gestiona el acceso condicional?

No. En el caso del acceso condicional basado en factores como la hora, la ubicación o el valor del recurso, use el control de acceso basado en atributos (ABAC). El RBAC se centra en el rol asignado al usuario.

El RBAC es un excelente modelo para el control de acceso, pero es solo un componente de una estrategia completa de gestión de identidades y accesos. Explore nuestra serie de Introducción a IAM para conocer más temas relacionados con la gestión de identidades y accesos.

Más información

Estos materiales tienen únicamente fines informativos generales. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales, y no debe confiar solamente en la información suministrada aquí.