RBAC y ABAC: diseñar la autorización

1Por qué importa

Cuando una API expone GET /pedidos/{id} y no comprueba que el pedido pertenece a quien pregunta, no hay ningún exploit sofisticado: el atacante cambia el número y lee lo ajeno. Eso es un fallo de autorización, no de autenticación. El usuario estaba perfectamente logueado; el sistema simplemente no decidió si tenía derecho a ese objeto. Año tras año, los fallos de control de acceso encabezan las listas de vulnerabilidades reales, y casi siempre por la misma razón: la decisión de acceso estaba dispersa, implícita o directamente ausente.

Diseñar la autorización bien hace tres cosas prácticas. Primero, convierte una intuición (“esto solo lo pueden ver los administradores”) en una regla que se puede leer, revisar y probar. Segundo, concentra la decisión en un sitio, de modo que añadir un endpoint no signifique reinventar quién puede llamarlo. Tercero, hace que el acceso sea auditable: si un día alguien pregunta “¿por qué este usuario pudo hacer esto?”, hay una respuesta escrita, no una arqueología de if repartidos por el código.

2Conceptos

3Explicación profunda

RBAC parte de una observación cierta: los permisos se repiten por puesto de trabajo. Un contable hace lo mismo que otro contable, así que en vez de asignar permisos a personas se asignan a un rol contable y se mete a la persona en él. Es simple, se audita de un vistazo (“¿quién es admin?”) y encaja con cómo piensan las organizaciones. Por eso es el modelo por defecto y casi siempre el punto de partida correcto.

RBAC se rompe cuando el permiso depende de datos, no solo de puesto. “Un vendedor puede ver pedidos” es un rol; “un vendedor puede ver sus pedidos, los de su región, del trimestre actual” ya no lo es. Si intentas expresarlo con roles, creas vendedor-norte-q1, vendedor-sur-q2 y así hasta el infinito: es la explosión de roles. El síntoma es un sistema con cientos de roles que nadie se atreve a tocar porque nadie sabe ya qué concede cada uno. Un catálogo de roles que no se puede auditar es control de acceso roto con buena presentación.

ABAC ataca justo ese caso. En vez de preguntar “¿qué rol tienes?”, la política compara atributos: sujeto.region == recurso.region, recurso.estado == "abierto", hora ∈ horario_laboral. La decisión se evalúa por petición, con los datos de esa petición, así que expresa relaciones que RBAC no puede. El precio es que una política de atributos mal escrita es más difícil de leer que una lista de roles, y que necesitas que esos atributos vengan de una fuente de confianza —normalmente los claims de un token verificado, que es de lo que van las tres lecciones siguientes.

En la práctica no se elige uno: se combinan. RBAC pone el trazo grueso (“solo el rol admin escribe”) y ABAC pone el fino (“y además solo en recursos de su departamento”). La política del laboratorio de esta lección hace exactamente eso, y el orden importa: primero la regla de rol, que es barata y descarta la mayoría, y luego la de atributo.

Hay una separación de la que depende que todo esto sea mantenible: la del PDP y el PEP. El PDP es el sitio que decide —una función autorizar(sujeto, accion, recurso)—, y el PEP es cada punto del código que aplica esa decisión antes de tocar el dato. Si la decisión vive en un solo PDP, añadir un endpoint es llamar a una función; si vive esparcida en if por los controladores, cada endpoint es una oportunidad nueva de olvidarse. Y sobre todo: default-deny. La función arranca negando y solo concede si una regla lo dice explícitamente. Un fallo así falla cerrado, no abierto.

4Ejemplo sencillo

# Un edificio con recepcion

AUTENTICAR   la recepcion confirma que eres quien dices (DNI)
AUTORIZAR    tu tarjeta abre SOLO las puertas que te tocan

# RBAC: la tarjeta lleva un rol impreso

rol "limpieza"   abre todas las plantas, de noche
rol "finanzas"   abre solo la planta 3
Problema: "finanzas, pero solo su propio despacho" -> ¿un rol por despacho?

# ABAC: la puerta compara atributos al vuelo

regla: puerta.planta == tarjeta.planta  Y  hora en horario
Una sola regla cubre a todos los despachos, sin inventar roles.

5Ejemplo técnico

El laboratorio lab-iam-oidc trae una política real que combina los dos modelos. Tres usuarios, dos recursos de departamentos distintos, y una función que decide:

Fíjate en los dos “denegado” de bob: uno lo para RBAC (le falta el rol para escribir) y el otro lo para ABAC (su departamento no es el del recurso). Un mismo usuario, dos motivos distintos. Devolver el motivo no es un lujo: es lo que hace la política depurable y auditable.

6Diagrama

flowchart LR
    P[peticion: sujeto+accion+recurso] --> PEP[PEP · aplica]
    PEP --> PDP[PDP · autorizar]
    RBAC[RBAC: roles] --> PDP
    ABAC[ABAC: atributos] --> PDP
    PDP --> OK[permitido]
    PDP --> NO[denegado + motivo]

7Código

Esta es la política del laboratorio, escrita como una función pura: entra sujeto, acción y recurso; sale una decisión y su motivo. Es el PDP entero, y cabe en la pantalla:

# cliente.py — el PDP del laboratorio
def autorizar(claims, accion, recurso):
    roles = set(claims.get("roles", []))
    dep = claims.get("dep")
    meta = RECURSOS.get(recurso)
    if meta is None:
        return (False, "recurso desconocido")   # default-deny
    # RBAC: primero la regla barata de rol
    if accion == "escribir" and "admin" not in roles:
        return (False, "RBAC: escribir exige rol admin")
    if accion == "leer" and not roles & {"admin", "lector"}:
        return (False, "RBAC: leer exige rol lector o admin")
    # ABAC: el atributo del sujeto debe casar con el del recurso
    if dep != meta["dep"] and "admin" not in roles:
        return (False, f"ABAC: dep '{dep}' no coincide")
    return (True, "permitido")

Lo que la hace correcta no es que sea corta: es que arranca negando, que los atributos (roles, dep) vienen de un token verificado y no de la petición, y que devuelve el motivo. Como es una función pura, probarla es trivial, y ese es el punto entero.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

if accion == "borrar":
    if "admin" not in roles:
        return (False, "RBAC: borrar exige rol admin")
    if dep != meta["dep"]:
        return (False, "ABAC: borrar solo en tu departamento")
    return (True, "permitido")

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos