Por qué RBAC por sí solo no basta en sistemas financieros multi-tenant

Roles comprimen policy pero pierden context

RBAC funciona bien con permission sets estables. Falla cuando policy depende del objeto o del entorno: una Finance role puede refundar para una entidad pero no otra, o hasta cierto threshold.

Tenant isolation debe formar parte de authorization

No basta preguntar si el role puede refundar. Debes comprobar que el payment pertenece a un tenant/account que el actor puede operar y enforcearlo server-side.

Attributes y relationships añaden precisión

NIST ABAC evalúa subject, object, operation y environmental attributes contra policy. En financial systems, role puede ser baseline y entity, amount, channel, ownership o risk state refinan la decisión.

La decisión debe ser explicable

Registra policy version y decision context suficiente para auditoría sin exponer reglas internas sensibles al cliente.

Separa role assignment de authorization evaluation

Roles son útiles para capacidades amplias como finance operator, support agent o administrator. El authorization engine debe evaluar cada request con esos roles más resource y environmental context. Así evitas crear un rol nuevo para cada combinación de tenant, amount threshold, región y ownership.

Role explosion indica que RBAC está cargando policies que no expresa bien. Cientos de roles casi duplicados son difíciles de revisar y fáciles de asignar mal. Mantén roles comprensibles y añade contextual policy cuando haga falta.

Haz que tenant boundaries no puedan saltarse accidentalmente

Tenant context debe venir de relaciones autenticadas server-side, no solo de un tenant ID enviado por el cliente. Query scopes, policy checks y service boundaries deben hacer que cross-tenant access falle por defecto. Un role check correcto con tenant scope incorrecto sigue siendo fallo de autorización.

También aplica a background jobs y service accounts. Machine identities necesitan authority scoped; credenciales internas amplias pueden saltarse permisos de usuario si service-to-service access no se modela.

Usa attributes para financial constraints

Acciones financieras dependen a menudo de amount, legal entity, currency, country, risk state, ownership, account status o second approval. Una policy estilo ABAC combina esos hechos con roles para permitir trabajo rutinario y exigir autoridad adicional en acciones high-value o cross-entity.

Elige attributes authoritative y estables para security decisions. Labels del cliente o valores cached stale no deberían convertirse en policy inputs sin control. Authorization es tan fiable como los datos usados para evaluarla.

Modela relationships donde ownership importa

Algunas policies se expresan mejor como relaciones: user pertenece a organization, organization posee merchant account, merchant account posee payment. Relationship checks complementan roles y attributes respondiendo si actor está conectado al resource por una ruta permitida.

En práctica puedes combinar modelos. RBAC da permisos comprensibles de job, relationships aplican ownership y attributes contexto financiero. El objetivo no es pureza ideológica de modelo, sino policy que corresponda al negocio y siga siendo revisable.

Audita la decisión, no solo la acción

Cuando una acción sensible se permite o deniega, conserva suficiente contexto para explicar authorization: actor, resource, tenant, policy version y key attributes. Es especialmente útil cuando policies cambian; debes saber qué rule estaba activa entonces, no aplicar la de hoy al evento de ayer.

Los denial messages para usuario pueden ser limitados para no exponer detalles de policy. La evidencia interna puede ser más rica que la response al caller.