Modelos de permisos que prueban que funcionan, no que solo dicen que funcionan

El control de acceso basado en roles es una frase de marketing en todo sitio de SaaS. La página de producto lista los roles. La página de precios menciona SSO empresarial. La página de trust tiene un diagrama con flechas y candados.

Si el rol que tienes de verdad te mantiene fuera de las pantallas que no deberías ver es una pregunta aparte, y la respuesta honesta que la mayoría de los proveedores puede dar es “creemos que sí”.

Nosotros elegimos dar otra respuesta. La matriz de permisos es un archivo. La prueba que fija el archivo tira el build si un rol que no es admin alguna vez llega a una superficie solo para admin. La prueba que fija el alcance de datos tira el build si un rol sin alcance ve un número distinto de cero en un dashboard que debería renderizar cero. La forma del reclamo no es “confía en nosotros”. Es “esta prueba está verde o no entregamos”.

La diferencia entre marketing de RBAC y un límite defendible en auditoría

Un reclamo de permisos tiene tres capas, y la mayoría de los productos solo entrega una.

La primera capa es “los roles existen”. El producto tiene un admin, un manager, un miembro. Esa es la capa que la página de marketing muestra. Es la capa que es verdad para casi todo producto de SaaS, incluyendo aquellos cuyo modelo de permisos tiene fugas.

La segunda capa es “las pantallas están bloqueadas”. Un usuario con el rol de manager no puede navegar a la página de configuración de admin. Esto también suele ser verdad, porque la navegación se bloquea del lado del cliente y la mayoría de los usuarios no pega URLs para tratar de saltarse el bloqueo.

La tercera capa es la que casi nadie verifica. Un usuario con el rol de manager no puede llegar a la página de configuración de admin ni siquiera si pega la URL directo. No puede llamar al endpoint API de admin con su cookie de sesión. No puede leer datos de admin a través de una herramienta de debugging. No puede ver números de admin filtrándose por un widget de dashboard que se suponía estaba escondido.

La tercera capa es la que los auditores preguntan. La forma honesta de contestar no es una captura de pantalla. Es una prueba que corre en cada release y tira si el límite tiene fuga.

La matriz de rol por superficie

El primer artefacto es docs/qa/permission-matrix.md. Es una tabla canónica. Seis roles a lo largo del lado izquierdo: Ventas, Solutions Engineering, Individual Contributor, Entrega, Finanzas, Admin. Superficies a lo largo de arriba: cada página, cada sección de admin, cada panel de configuración, cada pantalla de integración. Cada celda es “permitido” o “negado”.

La matriz es la fuente de verdad. No es una descripción de cómo se supone que funciona el producto. Es la definición de cómo el producto sí funciona, y la prueba de abajo la fija.

La excepción operativa de finanzas está documentada en la matriz, no en folklore. Finanzas llega a la página de integración con QBO y a las superficies de admin del catálogo de cuentas porque finanzas las necesita para hacer su trabajo. Ventas, SE, IC y Entrega no. Admin llega a todo porque admin es admin. La excepción es una celda en la matriz, no una conversación lateral entre el product manager y el ingeniero.

La prueba permanente es 337-permission-matrix. Lee la matriz. Para cada celda marcada como “negada”, se loguea con ese rol y asegura que la superficie devuelva un 403 o redirija. Para cada celda marcada como “permitida”, se loguea con ese rol y asegura que la superficie renderice. La prueba corre en cada release. Una nueva página solo para admin agregada sin actualizar la matriz tira la prueba, porque la página nueva no está en la matriz y la prueba no sabe qué hacer con ella. La matriz y el producto no pueden separarse.

El alcance de datos del dashboard es un problema aparte

La matriz bloquea superficies. El problema del dashboard es de grano más fino que eso.

Un dashboard podría tener permiso para renderizar para cada rol, porque el dashboard en sí no es de admin. Los números en el dashboard son la pregunta. El total de la organización para ingresos closed-won es algo que admin debería ver. Un rep de ventas sin alcance de filas debería ver cero, no el total de la organización. Un manager con el alcance de un equipo debería ver el número de su equipo. El widget del dashboard debería renderizar en los tres casos, con tres números distintos.

Aquí es donde los modelos de permisos ingenuos tienen fugas. El widget se bloquea por rol. Los números dentro del widget no. Un rep carga el dashboard y ve el total de la organización porque la consulta que alimenta el widget no respetó el alcance de filas del rep.

La prueba permanente es 338-dashboard-data-scoping. Es una prueba conductual, no una prueba de visibilidad. Se loguea como un rol sin alcance y asegura que los valores del widget sean cero. Se loguea como un manager con alcance y asegura que los valores coincidan con el alcance. Se loguea como admin y asegura que los valores coincidan con el total de la organización. La diferencia es lo que renderiza la pantalla, no si la pantalla renderiza.

Si se agrega un nuevo widget de dashboard que no respeta el alcance de filas, la prueba tira. No porque el widget sea invisible, sino porque el valor que el widget renderiza está mal para el rol que lo está viendo.

Por qué esta forma importa para una firma pequeña

El comprador que evalúa un producto pequeño de operaciones no tiene un red team disponible para verificar los reclamos del proveedor. Tiene un CFO, un líder de operaciones y un consultor externo que lee la página de trust una vez.

La página de trust que dice “RBAC soportado, SOC 2 en proceso” tiene la misma forma que la página de trust de cada competidor. El comprador no puede decir desde esa página cuáles productos hacen cumplir el límite y cuáles tienen un reclamo de marketing con un hueco atrás.

Una prueba permanente que tira el build si la matriz se rompe es otra forma de reclamo. El comprador puede leer el archivo de la matriz. El comprador puede pedirle al proveedor que muestre la corrida de CI. El proveedor tiene la prueba o no la tiene.

Lo que PartnerView entrega

Una matriz canónica de permisos de seis roles por superficie en docs/qa/permission-matrix.md. Una prueba permanente (337-permission-matrix) que tira el build si una celda negada se vuelve alcanzable. Una prueba permanente (338-dashboard-data-scoping) que tira el build si un widget de dashboard renderiza el valor incorrecto para el alcance de filas del que está viendo. La excepción operativa de finanzas es una fila en la matriz, no folklore. Las dos pruebas corren en cada release. El framing de trust en v5.5 es que el límite es la prueba, no el reclamo.

Un modelo de permisos que prueba que funciona en cada release es otro producto que un modelo de permisos que dice que funciona. Elegimos entregar del primer tipo.