RBAC vs. ABAC: ¿en qué se diferencian estos modelos de control de acceso y cuándo necesitas reglas basadas en atributos?

#RBAC: el acceso sigue al rol

El control de acceso basado en roles asigna permisos a roles, y roles a usuarios. "Editor" puede escribir documentos; "viewer" solo puede leerlos; "admin" puede hacer ambas cosas además de gestionar usuarios. La decisión de acceso es una búsqueda: ¿tiene este usuario un rol que incluya el permiso que exige la acción? Es simple de razonar, simple de auditar ("mostrame a todos los que tienen el rol admin") y simple de implementar — una tabla de unión entre usuarios y roles, más un mapeo estático de roles a permisos, cubre la mayor parte de los casos.

La limitación aparece en cuanto una regla necesita información que no sea "qué rol tiene este usuario". "Los editores pueden editar documentos, pero solo los que ellos mismos redactaron." "Los agentes de soporte pueden ver PII de clientes, pero solo de clientes en su región asignada." "Finanzas puede aprobar pagos, pero no los pagos que ellos mismos enviaron" (separación de funciones). Ninguna de estas reglas se puede expresar como "¿el usuario tiene el rol X?" — dependen de la relación entre el usuario, el recurso específico y, a veces, el momento de la solicitud.

#ABAC: el acceso sigue una política sobre atributos

El control de acceso basado en atributos reemplaza la búsqueda por rol con una política evaluada contra atributos de tres cosas: el sujeto (departamento, nivel de autorización, estado laboral), el recurso (dueño, clasificación, estado actual) y el contexto (hora del día, IP de origen, si se usó MFA en esta sesión). Una sola regla ABAC puede expresar "un usuario puede eliminar un recurso solo si su nivel de autorización supera la clasificación del recurso, la solicitud viene de la red corporativa, y no es un recurso que él mismo creó" — una regla para la que RBAC no tiene vocabulario, porque ninguno de esos datos vive en un rol.

#RBAC en código

type Role = "admin" | "editor" | "viewer";

interface User {
  id: string;
  roles: Role[];
}

const ROLE_PERMISSIONS: Record<Role, string[]> = {
  admin: ["document:read", "document:write", "document:delete", "user:manage"],
  editor: ["document:read", "document:write"],
  viewer: ["document:read"],
};

function hasPermission(user: User, permission: string): boolean {
  return user.roles.some((role) => ROLE_PERMISSIONS[role]?.includes(permission));
}

function deleteDocument(user: User, documentId: string) {
  if (!hasPermission(user, "document:delete")) {
    throw new Error("Forbidden: missing document:delete permission");
  }
  // continuar con la eliminación...
}

Esto responde "¿los usuarios con este rol pueden eliminar documentos en general?" — una pregunta gruesa, independiente del recurso. No puede responder "¿puede este usuario eliminar este documento específico?", porque documentId nunca entra en la decisión.

#ABAC en código

interface Subject {
  id: string;
  department: string;
  clearanceLevel: number;
}

interface Resource {
  ownerId: string;
  department: string;
  classification: number;
  status: "draft" | "published" | "archived";
}

interface AccessContext {
  action: "read" | "write" | "delete";
  time: Date;
  ipIsCorporateNetwork: boolean;
}

type PolicyRule = (subject: Subject, resource: Resource, ctx: AccessContext) => boolean;

const rules: PolicyRule[] = [
  // Los dueños siempre pueden leer o escribir su propio recurso.
  (subject, resource, ctx) =>
    resource.ownerId === subject.id && ctx.action !== "delete",

  // Usuarios del mismo departamento pueden leer recursos publicados.
  (subject, resource, ctx) =>
    ctx.action === "read" &&
    resource.status === "published" &&
    subject.department === resource.department,

  // Eliminar requiere un nivel de autorización mayor que la clasificación
  // del recurso, Y debe originarse desde la red corporativa.
  (subject, resource, ctx) =>
    ctx.action === "delete" &&
    subject.clearanceLevel > resource.classification &&
    ctx.ipIsCorporateNetwork,
];

function isAuthorized(subject: Subject, resource: Resource, ctx: AccessContext): boolean {
  return rules.some((rule) => rule(subject, resource, ctx));
}

Ahora cada regla recibe el recurso específico y el contexto específico como entradas. Agregar "solo en horario laboral" o "solo si se completó MFA en esta sesión" es un nuevo predicado, no una migración de esquema — no hace falta inventar un rol nuevo y reasignarlo a nadie.

#Una comparación concreta

#Cuándo RBAC solo, genuinamente, no alcanza

La señal de alerta es cuando te encontrás inventando roles como editor-equipo-alpha, aprobador-menor-a-10k o soporte-region-us-east — eso es RBAC estirado para codificar atributos (equipo, monto, región) dentro de nombres de rol, porque el modelo no tiene otro lugar donde ponerlos. Una vez que multiplicás roles por cada dimensión de la que en realidad depende una política, reinventaste ABAC, pero mal, sin su capacidad de composición.

#La respuesta práctica: combinarlos en capas

Casi ningún sistema en producción es ABAC puro — evaluar una política completa de atributos en cada solicitud es más costoso y más difícil de razonar de lo necesario para filtros gruesos como "¿este usuario siquiera tiene algún motivo para acceder al panel de administración?". El patrón común es RBAC para el filtro grueso, barato y cacheable (¿este usuario tiene algún negocio acá?), y ABAC para la decisión fina una vez adentro (¿qué registros específicos puede tocar, bajo qué condiciones?). Herramientas como OPA (Open Policy Agent) y las condition keys de AWS IAM son motores ABAC atornillados sobre sistemas que siguen usando roles como su primer filtro.

🧠 Check your understanding
0/3 · 0/3 answered
1. ¿Qué requisito RBAC es fundamentalmente incapaz de expresar sin inventar un rol nuevo por cada caso?
Si un admin tiene más permisos que un viewerSi un usuario puede leer documentos en generalSi un editor puede editar un documento solo si él mismo lo redactóSi un rol incluye una cadena de permiso dada
2. En el ejemplo de código ABAC, ¿qué determina si una eliminación está autorizada?
Solo si el usuario tiene el rol adminSi el usuario está en el mismo departamento que el recursoSi el estado del recurso es 'published'El nivel de autorización del usuario comparado con la clasificación del recurso, más si la solicitud viene de la red corporativa
3. ¿Cuál es una señal de alerta común de que un equipo está forzando RBAC más allá de sus límites útiles?
Cachear las búsquedas de rol a permisoAsignar más de un rol a un mismo usuarioTener menos de cinco roles definidosInventar roles muy específicos como editor-equipo-alpha para codificar atributos en los nombres de los roles