El sistema de permisos de casi cualquier proyecto empieza igual: un campo llamado rol, con dos valores, admin y usuario. Funciona perfectamente durante meses.
Después llega la primera excepción. Un usuario que necesita ver los informes pero no modificarlos. Un colaborador externo que solo debe acceder a su propio proyecto. Alguien de soporte que puede consultar pedidos pero no los datos de pago. Y cada excepción se resuelve añadiendo un caso especial en el sitio donde apareció.
Al cabo de un año, la respuesta a quién puede hacer qué está repartida en cuarenta condiciones dispersas por el código, nadie la conoce entera y nadie se atreve a tocarla. Este artículo trata de los dos modelos que evitan llegar ahí.
Lo que se está decidiendo en realidad
Antes de comparar conviene separar dos cosas que se confunden constantemente y que fallan por motivos distintos.
Autenticación es saber quién eres. Es el inicio de sesión, la contraseña, el token. Responde a la pregunta de si eres quien dices ser.
Autorización es saber qué puedes hacer una vez identificado. Es de lo que trata este artículo, y es donde se producen la mayoría de las filtraciones de datos que no vienen de un ataque sofisticado, sino de que alguien pudo ver algo que no le correspondía.
La distinción importa porque la autenticación se resuelve una vez, casi siempre con una librería o un servicio, y se olvida. La autorización, en cambio, aparece en cada pantalla, en cada consulta y en cada operación del sistema, para siempre.
Los dos modelos, en una imagen
Las dos formas establecidas de organizar esto responden a la misma pregunta con estrategias distintas.
RBAC agrupa permisos en roles y asigna roles a personas. La decisión se toma mirando una sola cosa: qué rol tiene quien pide. Es sencillo de entender, fácil de auditar y suficiente para la gran mayoría de las aplicaciones.
ABAC evalúa atributos en el momento de decidir: quién pide, qué pide, cuándo y desde dónde. Permite expresar reglas que RBAC no puede, a cambio de que la respuesta ya no se pueda leer de un vistazo.
Por qué RBAC debería ser el punto de partida
Conviene decirlo sin rodeos porque la tentación de empezar con algo más flexible es fuerte: para casi todos los proyectos, RBAC bien hecho es la respuesta correcta.
La razón principal es que un sistema de permisos tiene que poder revisarse. Alguien debe poder responder qué puede hacer exactamente una persona, y con roles esa pregunta tiene una respuesta corta. Con reglas que dependen de media docena de atributos, responderla exige simular cada caso.
La segunda razón es que los permisos cambian con el tiempo y alguien tiene que mantenerlos. Un modelo que solo entiende quien lo escribió es un modelo que se degrada, porque el siguiente en tocarlo va a preferir añadir una excepción antes que entender el conjunto.
Y la tercera es práctica: RBAC cubre de sobra el caso habitual, que es un puñado de tipos de usuario con capacidades distintas. Adoptar algo más complejo antes de necesitarlo añade trabajo sin resolver ningún problema existente.
Cómo se hace bien un RBAC
La diferencia entre un modelo de roles que envejece bien y uno que se vuelve inmanejable está en un detalle: qué se comprueba en el código.
El error frecuente es preguntar por el rol directamente, con condiciones del tipo si el rol es administrador. Funciona hasta que aparece un rol nuevo que también debería poder hacer eso, y entonces hay que buscar y modificar todos los sitios donde se preguntaba.
La forma que envejece bien es preguntar por el permiso concreto, no por el rol. El código comprueba si quien pide puede editar artículos, y en un único lugar se define qué roles tienen ese permiso. Añadir un rol nuevo pasa a ser una línea de configuración en vez de una búsqueda por todo el proyecto.
En vez de comprobar si el usuario es editor, se comprueba si el usuario puede publicar artículos.
Los dos funcionan igual hoy. Dentro de un año, el primero exige tocar veinte archivos para añadir un rol y el segundo, ninguno.
Conviene además nombrar los permisos por la acción y el recurso, de forma consistente. Una lista de permisos legible es la mejor documentación que puede tener un sistema de autorización, y con frecuencia es la única.
Cuándo RBAC se queda corto
Hay una señal inequívoca de que el modelo de roles no da más de sí, y conviene reconocerla porque la reacción instintiva es la equivocada.
La señal es la multiplicación de roles. Cuando aparecen nombres como editor de la región norte, o administrador solo lectura de facturación, lo que está ocurriendo es que se están codificando atributos dentro del nombre del rol. Cada combinación nueva exige un rol más, y el número crece de forma que nadie puede mantener.
La reacción instintiva es crear esos roles igualmente. La correcta es reconocer que la decisión ya no depende solo de quién es la persona, sino de una relación entre la persona y el recurso concreto.
Esa distinción es la que marca el límite real: RBAC responde bien a qué tipo de cosas puede hacer alguien, y mal a sobre cuáles de ellas.
El punto intermedio que resuelve casi todo
Antes de saltar a un modelo completo de atributos conviene conocer el término medio, que es donde vive la mayoría de las aplicaciones reales y que rara vez se menciona en las comparaciones.
Consiste en mantener los roles para decidir qué acciones son posibles, y añadir una comprobación de pertenencia para decidir sobre qué registros. El rol dice que un usuario puede editar proyectos; la comprobación dice que solo los suyos.
Esa segunda parte suele resolverse en la propia consulta, filtrando por el identificador de quien pide, que además es la forma más segura de hacerlo: si el filtro está en la consulta, no hay manera de que se olvide después.
Con roles para las acciones y pertenencia para los registros se cubre el caso de casi cualquier aplicación con varios clientes o equipos, sin pagar la complejidad de un motor de reglas.
Cuándo sí hace falta ABAC
Hay situaciones donde las condiciones no se pueden expresar de otra forma, y ahí el modelo de atributos es la herramienta adecuada.
- Reglas que dependen del contexto, como restringir cierta operación fuera del horario laboral o desde ubicaciones no habituales.
- Datos clasificados por sensibilidad, donde el permiso depende de una propiedad del documento y no solo de quién lo pide.
- Requisitos normativos explícitos, frecuentes en salud y finanzas, que exigen decidir combinando varias condiciones.
- Organizaciones grandes con jerarquías cambiantes, donde mantener la equivalencia en roles produciría cientos de ellos.
Fuera de estos casos, adoptar ABAC suele significar cambiar un problema conocido por uno más difícil de auditar. Y conviene recordar que los dos modelos conviven bien: lo habitual en sistemas maduros es RBAC como base con unas pocas reglas de atributos para los casos que lo exigen.
Dónde debe vivir la comprobación
Elegido el modelo, queda la decisión que más incidentes evita: en qué punto del sistema se comprueba el permiso.
La respuesta corta es lo más cerca posible de los datos. Una comprobación en la interfaz sirve para no mostrar botones inútiles, y no protege nada: cualquiera puede llamar directamente a la API sin pasar por la pantalla.
El sitio correcto es el punto por donde pasan todas las peticiones, antes de tocar los datos. Si además el filtro por pertenencia va dentro de la consulta, se cierra el caso de olvidarlo en un endpoint nuevo escrito con prisa.
Esto es especialmente importante cuando el cliente habla directamente con la base de datos, como ocurre en las plataformas de servicios gestionados. Ahí las reglas configuradas en el servicio son lo único que separa los datos de cualquiera con la clave pública, y dejarlas abiertas durante el desarrollo es el fallo más común y más grave.
Los permisos que nadie quita
Hay una parte del ciclo de vida de los permisos que casi ningún proyecto pequeño contempla, y que con el tiempo produce una situación incómoda: los accesos se conceden y no se retiran nunca.
Alguien entra a ayudar con una tarea concreta y recibe permisos amplios porque es lo rápido. La tarea termina, la persona sigue con el acceso. Un colaborador externo termina el contrato y su cuenta sigue activa. Alguien cambia de área y acumula los permisos del puesto anterior más los del nuevo.
El resultado, al cabo de un par de años, es que la lista de quién puede hacer qué no se parece a lo que nadie pretendía. Y no hace falta ninguna mala intención para que eso sea un problema: cada cuenta con más acceso del necesario es una cuenta cuyo robo causa más daño.
La medida que lo corrige es una revisión periódica, aunque sea una vez al año y aunque el equipo sea de tres personas: mirar la lista de usuarios con acceso, comprobar que cada uno sigue necesitándolo y quitar lo que sobra. Lleva quince minutos en un proyecto pequeño.
Ayuda mucho que conceder un permiso deje rastro de por qué se concedió. Una nota de dos palabras evita la duda posterior de si esa persona necesita eso o lo tiene por un motivo que ya no existe.
El caso especial del administrador
Merece mención aparte porque concentra un riesgo distinto al de los demás roles y suele tratarse con menos cuidado del que exige.
En casi todos los sistemas pequeños existe un rol que puede hacerlo todo, y suele usarse a diario para tareas normales, porque es la cuenta que ya está iniciada. Eso convierte cualquier descuido con esa sesión, un equipo desatendido o un enlace malicioso abierto por accidente, en un incidente de alcance total.
La práctica que reduce el riesgo sin complicar el trabajo es separar la cuenta habitual de la cuenta con privilegios amplios, aunque sean de la misma persona. Se trabaja con la primera y solo se usa la segunda cuando hace falta.
Y conviene que las acciones de esa cuenta queden registradas siempre. No por desconfianza, sino porque son las únicas operaciones capaces de cambiar los permisos de todos los demás, y cuando algo sale mal es lo primero que hay que poder reconstruir.
Qué se le escapa a una IA con esto
Pedir un sistema de permisos produce, con bastante fiabilidad, un RBAC razonable con una tabla de roles y comprobaciones en los endpoints. El código suele estar bien.
Lo que falta casi siempre es la segunda mitad: la pertenencia. Se comprueba que quien pide tiene el rol adecuado y no se comprueba que el registro solicitado le corresponda. El resultado es un sistema donde cualquier usuario autenticado puede leer los datos de otro cambiando un número en la dirección.
Ese fallo es el más frecuente en aplicaciones web y no produce ningún síntoma: todo funciona correctamente mientras cada quien pida lo suyo. Solo aparece cuando alguien prueba a pedir lo ajeno.
La forma de evitarlo es pedir explícitamente las dos comprobaciones y, sobre todo, probarlo: crear dos usuarios, iniciar sesión con uno y pedir un recurso del otro. Es una prueba de dos minutos que debería hacerse antes de publicar cualquier pantalla que muestre datos propios de alguien.