Diseño de Política RBAC + ABAC para una App de Cashback

El módulo, aplicado a un sistema

Cada artículo de este módulo te entregó una pieza: el artículo de XACML te dio los cuatro componentes con los que se construye todo sistema de autorización. Políticas como código te dio tres lenguajes para escribir reglas reales. Autorización de grano fino te dio el modelo de grafo de relaciones para la compartición que no encaja en una regla plana. El artículo de granularidad te dio un marco para decidir cuánta precisión necesita realmente una decisión dada. Autorización descentralizada te dio un marco para decidir dónde corre realmente cada decisión. Este artículo hace lo que ninguno de los otros pudo: tomar una aplicación real y usar cada pieza para diseñar su autorización desde la lista de funcionalidades hasta política desplegada y probada.

La aplicación es CashBack Rewards, la plataforma de fidelización de comercios que ha usado todo este dominio para sus ejemplos trabajados — los clientes ganan cashback por sus compras, los comercios gestionan sus propios registros de transacciones, los agentes de soporte ayudan a los clientes con problemas de cuenta, y los equipos de personal de un comercio comparten informes internos de ahorros. Es deliberadamente ordinaria: nada en ella requiere una tecnología exótica, y ese es justamente el punto — la mayor parte de lo que construyas se parecerá más a esto que al grafo de compartición a escala de Google Drive, y la habilidad que enseña este artículo es reconocer qué partes, si acaso alguna, realmente necesitan esa escala.

La lista de funcionalidades

Siete funcionalidades cubren la superficie de autorización de la app que vale la pena diseñar deliberadamente:

1. Abrir el panel de recompensas — cualquier cliente con una cuenta activa debería ver su propio resumen de cashback.
2. Ver el historial de transacciones propio — un cliente ve las compras que le generaron cashback.
3. Un agente de soporte ve la cuenta de un cliente — para ayudar con un ticket de soporte.
4. Un comercio edita un registro de transacción en borrador — corrigiendo un error antes de que se liquide.
5. Ver un informe de ahorros compartido con tu equipo — el equipo interno de un comercio, compartiendo análisis entre el personal.
6. Abrir el panel de administración — personal interno de operaciones que gestiona la propia plataforma.
7. Un administrador global revisa una cuenta de comercio en cualquiera de las dos regiones — la empresa ahora opera tanto en EE. UU. como en la UE.

Nada en esta lista es inusual — es el tipo de conjunto de funcionalidades que acumula la mayoría de las aplicaciones híbridas B2B-y-consumidor dentro del primer año de lanzamiento. Esa normalidad es exactamente lo que la convierte en un buen cierre: el objetivo no es exhibir maquinaria de autorización exótica, es mostrar que la mayor parte del control de acceso de una app es simple una vez clasificado correctamente, y solo una pequeña parte necesita peso real.

Paso 1: clasifica cada funcionalidad

Antes de elegir una sola herramienta, pasa cada funcionalidad por la pregunta del artículo de granularidad: ¿la respuesta correcta depende de cuál recurso o relación específica está involucrada, para este llamador específico?

Ya salen cinco asignaciones de capa distintas de una sola tabla, antes de escribir una línea de política. Dos funcionalidades son puertas de rol puras. Tres son decisiones de atributos de recurso de complejidad variable. Una es un grafo de relaciones genuino. Una combina una puerta de rol con una preocupación de relación entre regiones que el marco del artículo de ubicación tiene que responder, no el marco de granularidad por sí solo. Este es todo el sentido de clasificar primero: las elecciones de herramienta en el resto de este artículo son consecuencias de esta tabla, no decisiones independientes tomadas funcionalidad por funcionalidad.

Paso 2: el modelo de roles RBAC

Diseña el conjunto de roles más pequeño que cubra la parte dependiente de rol de cada funcionalidad — resiste la tentación de añadir un rol por cada puesto del organigrama, que es el clásico error de explosión de roles contra el que advirtió el artículo de RBAC:

Cinco roles, no quince. Cada funcionalidad de la tabla anterior corresponde a que exactamente uno de ellos necesite el rol en absoluto — el modelo de roles responde “¿este tipo de acción siquiera está sobre la mesa para este tipo de llamador?”, y deliberadamente no responde nada sobre cuál recurso específico. Esa pregunta pertenece a los dos pasos siguientes, mantenidos separados a propósito: mezclar “los agentes de soporte pueden ver cuentas” (rol) con “este agente puede ver esta cuenta” (recurso) en una sola regla enredada es cómo los sistemas RBAC acumulan cientos de roles casi duplicados tratando de codificar excepciones específicas de recurso que nunca fue trabajo del rol expresar.

Paso 3: los atributos ABAC

Tres de las siete funcionalidades necesitan más que un rol para decidir correctamente. Enumera los atributos que esas decisiones realmente consumen, divididos a la manera de XACML — sujeto, recurso, entorno — porque esa división es lo que hace legibles las políticas del siguiente paso:

Nueve atributos, la mayoría reutilizados en más de una funcionalidad, es una superficie de Punto de Información de Política manejable — lo bastante pequeña para que un equipo pueda nombrar, obtener y mantener actualizado cada uno, que es exactamente la pregunta operativa que planteó el artículo de XACML sobre los PIP y que planteó el artículo de autorización de grano fino sobre los datos de relaciones: un atributo o una tupla es tan confiable como el sistema que lo mantiene al día.

Paso 4: escribe la política, funcionalidad por funcionalidad

Funcionalidades 1 y 6: puertas de rol puras

Abrir el panel y abrir el panel de administración no necesitan nada más que una comprobación de rol — sin ida y vuelta al PDP, sin consulta de atributos, solo un claim ya presente en el token de sesión del llamador. En un servicio con Casbin embebido, esto es casi el matcher más simple que el lenguaje puede expresar:

[request_definition]
r = sub, act
 
[policy_definition]
p = sub, act
 
[matchers]
m = r.sub == p.sub && r.act == p.act

p, customer, open_dashboard
p, merchant, open_dashboard
p, admin, open_admin_panel
p, global-admin, open_admin_panel

Sin columna obj en absoluto — estas dos funcionalidades no tienen un recurso sobre el que razonar, que es precisamente lo que las hace de capa módulo y no de capa recurso. Recurrir aquí a un motor más pesado sería el error de sobremodelado que nombró directamente el artículo de granularidad.

Funcionalidad 2: ver transacciones propias

La primera decisión de atributos de recurso — el llamador debe ser dueño del registro de transacción que pide ver. La forma permit/forbid de Cedar, deliberadamente restringida para seguir siendo analizable, expresa una condición de propiedad con claridad:

permit (
  principal,
  action == Action::"viewTransaction",
  resource
) when {
  resource.owner_id == principal.user_id
};

Funcionalidad 3: un agente de soporte ve una cuenta

El ejemplo de la fintech que recorrió conceptualmente el artículo de XACML, ahora como una política real: el rol de un agente de soporte permite el tipo de acción, pero esta vista específica exige un ticket abierto y asignado durante horario laboral:

permit (
  principal in Role::"support-agent",
  action == Action::"viewAccount",
  resource
) when {
  resource.customer_id in principal.assigned_ticket_customer_ids &&
  context.current_time.hour >= 9 &&
  context.current_time.hour < 18
};

Aquí es donde la capa de recurso justifica su costo: el mismo rol support-agent del Paso 2 es necesario pero no suficiente, y las dos condiciones de atributo adicionales son exactamente la diferencia entre “cualquier agente, cualquier cuenta, cualquier momento” y el comportamiento de mínimo privilegio que el negocio realmente exige. Cambia el escenario a fuera de horario o a un ticket sin asignar, y la misma política deniega correctamente, sin necesitar una segunda regla que mantener.

Funcionalidad 4: un comercio edita una transacción en borrador

Propiedad de nuevo, más una condición adicional — una transacción liquidada nunca debería ser editable, sin importar quién sea su dueño. Suficientemente pequeña para quedarse en el modelo embebido de Casbin en lugar de recurrir a Cedar, ya que esta comprobación no tiene ninguna necesidad de salir del servicio que posee los datos de la transacción:

[request_definition]
r = sub, obj_owner, obj_status, act
 
[policy_definition]
p = act, allowed_status
 
[matchers]
m = r.sub == r.obj_owner && r.act == p.act && r.obj_status == p.allowed_status

p, edit_transaction, draft

El matcher comprueba la identidad del llamador contra la propiedad del recurso directamente (r.sub == r.obj_owner, pasado por el servicio llamador en lugar de consultado por el propio Casbin) y fija el estado permitido en draft — una transacción liquidada simplemente no tiene ninguna fila de política que coincida, así que cae por defecto en denegación. La misma idea de propiedad que la funcionalidad 2, herramienta distinta, porque esta decisión vive por completo dentro de un solo servicio sin ninguna razón para pagar un salto de red hacia un PDP separado.

Funcionalidad 5: ver un informe de ahorros compartido con tu equipo

La única funcionalidad de esta lista que es genuinamente una relación, no un atributo — un informe compartido con un equipo es visible para todos en ese equipo, sin importar cómo esté estructurada la membresía del equipo, que es exactamente la forma que el artículo de autorización de grano fino construyó a OpenFGA para responder:

type user
 
type team
  relations
    define member: [user]
 
type report
  relations
    define viewer: [user, team#member]

{"user": "user:sara", "relation": "member", "object": "team:merchant-42-staff"}
{"user": "team:merchant-42-staff#member", "relation": "viewer", "object": "report:q3-savings"}

sequenceDiagram
  accTitle: Comprobando la vista de un informe compartido a través de la membresía de equipo
  accDescr: El diagrama muestra a un cliente pidiendo a OpenFGA que compruebe si Sara puede ver el informe de ahorros del tercer trimestre. OpenFGA lee la tupla viewer del informe, que nombra la relación member del equipo de personal del comercio como un userset en lugar de un usuario directo. OpenFGA expande ese userset leyendo las tuplas member del equipo y encuentra a Sara listada como miembro directo. Como se encontró un camino a través de un nivel de membresía de equipo, OpenFGA devuelve Allow al cliente.
  Client->>OpenFGA: Check(report:q3-savings, viewer, sara)
  OpenFGA->>OpenFGA: lee tupla viewer
  OpenFGA->>OpenFGA: expande tuplas member del equipo
  OpenFGA->>OpenFGA: Sara encontrada como miembro directo
  OpenFGA-->>Client: Allow (camino encontrado)

Todo lo demás en esta lista de funcionalidades pudo manejarse, y se manejó, sin un motor de relaciones. Esta no pudo — la membresía de equipo y la compartición se anidan de una forma que las reglas planas no pueden expresar con claridad — que es exactamente la disciplina por la que abogó el artículo de grano grueso vs grano fino: recurre a la herramienta más pesada solo donde la pregunta realmente es un grafo, no por defecto.

Funcionalidad 7: un administrador global entre regiones

Esta funcionalidad es una puerta de rol (global-admin) con una consecuencia de ubicación, no una forma de política nueva — la decisión interesante aquí no es qué comprobar, es dónde viven realmente los datos que lee la comprobación, algo que el siguiente paso cubre directamente.

Paso 5: dónde corre cada comprobación

Cada funcionalidad anterior ya tiene una política. Ubicarlas usa directamente el marco del artículo de autorización descentralizada:

• Las comprobaciones de rol de las funcionalidades 1 y 6 son baratas de perímetro — un claim ya presente en el token, verificable en el edge o en el primer salto del gateway, sin necesitar ninguna llamada al PDP.
• La política Cedar de la funcionalidad 2 corre en un sidecar por servicio junto al servicio de transacciones, ya que owner_id es un dato local de la aplicación sin ninguna razón para salir del límite del servicio.
• La política Cedar de la funcionalidad 3 corre de la misma forma, en un sidecar junto al backend de la consola de soporte — los datos de asignación de tickets que lee ya son locales a ese servicio.
• La comprobación Casbin de la funcionalidad 4 corre en proceso, embebida directamente en el servicio de transacciones, exactamente el despliegue para el que está construido Casbin — sin ningún sidecar, ya que es una simple llamada a función.
• El Check de OpenFGA de la funcionalidad 5 corre contra un despliegue de OpenFGA centralizado (o, según la funcionalidad 7, consciente de la región), ya que los datos de relaciones abarcan usuarios y equipos de formas que ningún servicio único posee de principio a fin.
• El caso de administrador global de la funcionalidad 7 es el que fuerza una decisión real: el propio claim de rol es barato de comprobar en cualquier lugar, pero los datos de relación y recurso que toca la solicitud de un administrador global viven en dos almacenes particionados por región. Según las opciones del artículo de autorización descentralizada, esta app acepta el costo de latencia al estilo at_least_as_fresh para la infrecuente ruta de administrador global, en lugar de pagar la latencia de escritura completa entre regiones en cada escritura regional o de particionar por completo el único rol que legítimamente necesita cruzar el límite.

sequenceDiagram
  accTitle: Una solicitud trazada a través de las capas de perímetro, módulo y relación
  accDescr: El diagrama muestra una solicitud de cliente para un informe compartido llegando primero a una comprobación de perímetro en el edge o gateway que verifica que el token sea válido. La solicitud luego llega a una comprobación de capa módulo que confirma que el llamador tiene el rol merchant, el cual permite el tipo de acción en principio. Solo después de que ambas comprobaciones baratas pasan, la solicitud llega a la capa de relación, donde OpenFGA comprueba si el informe específico se compartió con un equipo al que pertenece el llamador. Si la comprobación de relación encuentra un camino, el servicio devuelve el informe; de lo contrario, deniega.
  Client->>Gateway: GET informe (con token)
  Gateway->>Gateway: perímetro: ¿token válido?
  Gateway->>Service: reenvía (rol: merchant)
  Service->>Service: módulo: ¿el rol permite ver informes?
  Service->>OpenFGA: Check(informe, viewer, usuario)
  OpenFGA-->>Service: Allow (camino encontrado)
  Service-->>Client: contenido del informe

Paso 6: prueba todo en CI

Cada lenguaje usado arriba trae su propia forma de probarse, y la disciplina de políticas como código aplica sin importar qué herramienta escribió la regla: un cambio de autorización roto debería fallar en un pull request, no en producción.

• Las políticas Cedar de las funcionalidades 2 y 3 reciben una suite de pruebas Cedar validada contra el esquema de la app, más el conjunto de herramientas de análisis comprobando que las dos reglas permit nunca se solapen sin querer de una forma que otorgue más de lo previsto.
• Los modelos Casbin de las funcionalidades 1, 4 y 6 reciben pruebas unitarias simples en el propio framework de pruebas del lenguaje anfitrión, afirmando que tripletas (sub, obj, act) específicas resuelven en el permite o deniega esperado.
• El modelo OpenFGA de la funcionalidad 5 recibe un archivo de aserciones .fga.yaml: dadas las tuplas de Sara y su equipo, Check(informe, viewer, sara) debe ser true; con la tupla de membresía eliminada, debe ser false; para un usuario no relacionado, debe ser false desde el inicio.

flowchart LR
  accTitle: Un único pipeline de CI probando tres lenguajes de política distintos antes de publicar
  accDescr: El diagrama muestra un pull request disparando tres trabajos de prueba en paralelo, uno por cada lenguaje de política que usa esta app. El trabajo de pruebas Cedar corre el validador Cedar y el conjunto de herramientas de análisis contra las políticas Cedar. El trabajo de pruebas Casbin corre pruebas unitarias ordinarias en el lenguaje anfitrión contra los modelos Casbin. El trabajo de pruebas OpenFGA corre el comando de prueba fga contra el archivo de aserciones. Los tres trabajos deben pasar antes de que el pipeline continúe hacia publicar un nuevo paquete de política, que es lo que eventualmente extraen los sidecars y workers de edge del artículo de autorización descentralizada.
  PR[Pull request: cambio de política] --> Cedar[Validador Cedar + análisis]
  PR --> Casbin[Pruebas unitarias Casbin]
  PR --> FGA[Aserciones .fga.yaml de OpenFGA]
  Cedar --> Gate{¿Todo pasa?}
  Casbin --> Gate
  FGA --> Gate
  Gate -- sí --> Publish[Publica paquete de política]
  Gate -- no --> Block[["Bloquea el merge"]]

Errores que este diseño evitó deliberadamente

Tres patrones son lo bastante comunes en sistemas reales como para nombrarlos explícitamente, porque cada uno aparece como un atajo con apariencia plausible justo en el paso donde este artículo fue más cuidadoso:

Saltarse la clasificación y recurrir por defecto a la herramienta más nueva. Habría sido fácil modelar toda la app en OpenFGA, incluidas las dos puertas de rol puras — funciona, técnicamente, pero cada solicitud paga un recorrido de grafo de relaciones por una pregunta que siempre fue “¿el rol de este llamador es X?”, respondible solo con un claim del token. Clasificar primero es lo que evitó eso.

Codificar condiciones de recurso dentro del modelo de roles. Un atajo tentador para la funcionalidad 3 habría sido un rol support-agent-with-open-ticket, acuñado y revocado por ticket. Eso convierte una tabla de roles pensada para quedarse pequeña y estable en una que cambia con cada asignación de ticket — el modo de fallo de explosión de roles de RBAC, reintroducido al intentar que RBAC por sí solo responda una pregunta que necesitaba ABAC en capas por encima.

Probar cada lenguaje de política de forma aislada y nunca probar la estructura por capas. Un pipeline que corre pruebas de Cedar, pruebas de Casbin y pruebas de OpenFGA pero nunca confirma que la comprobación de rol de la funcionalidad 3 realmente corre antes que su comprobación de atributos — de modo que un claim de rol malformado no pueda colarse accidentalmente hacia una comprobación de recurso que asume que ya pasó un rol válido — se está perdiendo exactamente la prueba de estructura por capas que señaló como el vacío común el artículo de grano grueso vs grano fino.

Recapitulación

Una aplicación, cada marco de este módulo, en orden:

1. Clasifica antes de elegir una herramienta. Siete funcionalidades, pasadas por una sola pregunta cada una, produjeron cinco asignaciones de capa distintas antes de escribir ninguna política.
2. RBAC se mantiene pequeño a propósito. Cinco roles responden “¿este tipo de acción está sobre la mesa?”, deliberadamente sin decir nada sobre cuál recurso — eso es trabajo de la siguiente capa.
3. Los atributos ABAC son una lista corta, reutilizable y con fuente clara, no una condición hecha a medida por funcionalidad — nueve atributos cubrieron tres decisiones separadas de capa recurso.
4. El lenguaje de política sigue a la capa, no al revés — Casbin para puertas embebidas de solo-rol y de propiedad-más-estado, Cedar para decisiones de atributos de recurso analizables, OpenFGA para la única relación genuina.
5. La ubicación es una decisión separada de la propia política — la lógica de la misma política Cedar no cambia según dónde corra, pero dónde corre (edge, sidecar, en proceso, almacén consciente de la región) cambia sus propiedades de latencia y consistencia.
6. Cada lenguaje se prueba en el mismo pipeline de CI, y el pipeline solo es tan confiable como su capacidad de bloquear un merge, no solo de reportar un resultado.

Tres preguntas para ponerte a prueba

1. La funcionalidad 3 (un agente de soporte ve una cuenta) usa tanto una comprobación de rol como dos condiciones de atributo. Explica qué saldría mal específicamente — ya sea como brecha de seguridad o como tabla de roles inmanejable — si intentaras expresar esta funcionalidad usando solo RBAC, y por separado, qué saldría mal si intentaras expresarla usando solo ABAC sin ninguna comprobación de rol.
2. Explica por qué la funcionalidad 4 (un comercio edita una transacción en borrador) se implementó en Casbin en lugar de Cedar, usando el razonamiento de ubicación y granularidad de este artículo en lugar de solo “porque es más simple”.
3. Se propone una nueva funcionalidad: “los comercios pueden ver un informe agregado de cashback de todos los equipos de su región”. Usando las tres preguntas de la tabla de clasificación, determina a qué capa pertenece esta nueva funcionalidad, y nombra cuál de las herramientas existentes de esta app (o una nueva) encajaría.

Ejercicios prácticos

1. Clasifica la lista de funcionalidades de tu propia app. Elige de cinco a siete funcionalidades reales de una aplicación que uses o estés construyendo, y construye la tabla de clasificación de este artículo para ellas — solo-rol, atributo de recurso o relación — antes de decidir ninguna herramienta.
2. Escribe una política para una funcionalidad de atributos de recurso. Usando Cedar o Casbin, escribe la política real para una funcionalidad de tu ejercicio de clasificación que dependa de la propiedad o el estado de un recurso, siguiendo la forma de la funcionalidad 2 o 4 de este artículo.
3. Diseña la puerta de CI para tu política. Para la misma funcionalidad, esboza cómo se vería una prueba que pasa frente a una que falla, y describe qué debería bloquear un pipeline de CI antes de dejar que esa política llegue a producción — usando el Paso 6 de este artículo como plantilla.