RBAC vs ABAC: ¿cuándo recurrir a cada uno en la práctica?
Respuesta breve
El RBAC concede permisos mediante roles asignados a usuarios: sencillo de razonar pero propenso a la explosión de roles a medida que se multiplican los casos límite. El ABAC evalúa políticas sobre atributos del usuario, el recurso, la acción y el entorno, por lo que escala a decisiones finas y contextuales a costa de complejidad. La mayoría de los sistemas maduros los combinan: roles para concesiones generales, atributos y políticas para los detalles condicionales.
Los modelos de control de acceso deciden quién puede hacer qué sobre qué recurso. RBAC y ABAC son los dos que te pedirán comparar, y la buena respuesta rara vez es «elige uno».
RBAC: el rol como unidad de concesión
En el control de acceso basado en roles, los permisos se agrupan en roles, y los roles se asignan a usuarios. Un rol billing-admin lleva los permisos para leer facturas y emitir reembolsos; cualquiera en ese rol los hereda. Esto es fácil de auditar («¿quién está en billing-admin?») y se mapea limpiamente a las funciones laborales.
El modo de fallo es la explosión de roles. Cada «pero este grupo de usuarios necesita casi lo mismo, salvo que...» engendra un nuevo rol. Unos pocos cientos de usuarios pueden acabar tras miles de roles solapados que nadie comprende del todo, lo que socava silenciosamente el mínimo privilegio.
ABAC: políticas sobre atributos
El control de acceso basado en atributos evalúa una política en el momento de la solicitud sobre atributos: el sujeto (departamento, habilitación, situación laboral), el recurso (clasificación, propietario, región), la acción y el entorno (hora del día, postura del dispositivo, IP de origen). Una regla como «permitir la lectura si user.department == resource.department y device.compliant == true» expresa en una sola sentencia lo que requeriría muchos roles RBAC.
El coste es la complejidad: necesitas una fuente fiable para cada atributo, las políticas se vuelven más difíciles de razonar, y «¿por qué se denegó esto?» puede no ser obvio.
En la práctica: combínalos
La mayoría de los sistemas maduros usan roles para concesiones generales y atributos/políticas para los detalles condicionales, a veces llamado PBAC o policy-as-code (p. ej. OPA/Rego, condiciones de AWS IAM). El RBAC responde a «qué trabajo haces», el ABAC responde a «en este contexto concreto, ¿está permitido?».
Lo que buscan los entrevistadores: sabes nombrar la explosión de roles y la confianza en los atributos como las verdaderas concesiones, y propones la superposición en lugar de tratarlo como una elección dogmática.
Posibles preguntas de seguimiento
- ¿Qué es la «explosión de roles» y cómo ayuda el ABAC a evitarla?
- ¿Cómo combinarías RBAC y ABAC en un mismo sistema?
- ¿Dónde almacenas y en quién confías los atributos de los que depende el ABAC?