Aplicaciones multiempresa: cómo probar el aislamiento entre clientes
Por Carlos Isidoro De Ayala Diaz ·
Aplicaciones multiempresa: cómo probar roles, objetos, API, exportaciones y procesos para evitar que un cliente acceda a datos o acciones de otro en SaaS.
Define qué pertenece a cada cliente antes de empezar las pruebas
Una aplicación multiempresa permite que varias organizaciones utilicen el mismo producto y, a menudo, parte de la misma infraestructura. Cada organización puede tener usuarios, pedidos, documentos, tarifas, integraciones y configuraciones propias. El aislamiento exige que una persona autenticada solo vea y modifique los recursos de la empresa a la que pertenece, salvo relaciones autorizadas y documentadas. Iniciar sesión correctamente no demuestra esa separación: un usuario puede estar identificado y conservar acceso indebido a un objeto de otro cliente.
La revisión comienza con un mapa de clientes, roles, recursos y acciones. Se identifican al menos dos organizaciones de prueba, perfiles equivalentes en ambas y funciones con privilegios distintos: usuario, responsable, administrador del cliente, soporte y administración global cuando existan. Para cada recurso se anota quién puede crearlo, leerlo, modificarlo, exportarlo, compartirlo y eliminarlo. También se registran las relaciones legítimas, como un proveedor que atiende a varios franquiciados o una asesoría autorizada por diferentes empresas.
El alcance necesita cuentas preparadas y datos sintéticos reconocibles. Dos usuarios con el mismo rol en clientes distintos permiten comprobar acceso horizontal; perfiles con responsabilidades diferentes permiten revisar escaladas verticales. Si se utiliza producción, las pruebas se limitan para no consultar información real ajena ni alterar operaciones. El propietario autoriza dominios, API, aplicaciones móviles, integraciones, horarios, intensidad y acciones prohibidas. Una credencial de soporte no implica permiso para probar todas las empresas alojadas.
Antes de enviar solicitudes se localiza de dónde obtiene el sistema el contexto de cliente. Puede venir de la sesión, un token, el dominio, una relación almacenada o una selección posterior. El navegador puede enviar un identificador de organización, pero el servidor debe comprobar que la identidad pertenece a ella y que la acción está permitida. La matriz de acceso se convierte en la referencia: sin una regla esperada, una respuesta diferente entre dos cuentas no permite distinguir un fallo de una función comercial prevista.
Comprueba objetos, funciones y propiedades en cada ruta del servidor
OWASP propone evaluar autorización horizontal y vertical con identidades y sesiones separadas. Para cada función se repite una solicitud válida con la cuenta del otro cliente y se modifican los identificadores relevantes. Pueden aparecer en la ruta, parámetros, cuerpo, cabeceras, GraphQL, nombres de archivo o referencias internas. Un UUID difícil de adivinar reduce la enumeración casual, pero no sustituye la autorización. El servidor debe validar la relación entre identidad, cliente, objeto y acción cada vez que usa un dato controlable por el cliente.
La lectura es solo una parte. Se prueban creación, actualización, borrado, descarga, compartición, aprobación, cambio de estado y operaciones masivas. OWASP denomina BOLA al acceso indebido a objetos mediante identificadores y diferencia ese problema de la autorización de funciones. Una cuenta puede tener permiso para abrir el endpoint de facturas y, aun así, no poder consultar una factura ajena; también puede leer sus facturas, pero no ejecutar una función administrativa sobre ellas. Ambas decisiones necesitan controles independientes.
Las propiedades requieren la misma atención. Una respuesta puede ocultar el documento completo y seguir exponiendo un correo, coste, margen, token o campo interno. Una actualización puede aceptar propiedades que la interfaz no muestra, como el identificador de cliente, el rol, el precio o el estado de aprobación. Se revisa qué campos devuelve y acepta cada endpoint y se utilizan listas explícitas de propiedades autorizadas. Quitar un botón del frontend no impide que una persona reproduzca la petición directamente.
La cobertura incluye caminos menos visibles: buscador, autocompletado, informes, exportaciones CSV o PDF, impresión, historial, notificaciones, recuperación de contraseña, invitaciones, adjuntos y enlaces compartidos. También se comparan la web, la API pública, la aplicación móvil y las versiones anteriores que sigan disponibles. Una política correcta en la pantalla principal puede faltar en una descarga o en un endpoint heredado. El inventario de rutas y roles permite informar qué se comprobó y qué quedó fuera.
Sigue el contexto del cliente por datos, colas, cachés e integraciones
El aislamiento puede construirse con infraestructura separada, recursos compartidos o una combinación. AWS señala que autenticación y autorización general no equivalen por sí solas a aislamiento de clientes: el contexto del tenant debe limitar los recursos en cada capa. En una base compartida, las consultas y escrituras necesitan una condición fiable que no dependa solo del identificador recibido. En un modelo separado, la selección de cuenta, base, contenedor o clave sigue teniendo que derivarse de una relación autorizada.
Los procesos en segundo plano deben conservar el mismo contexto. Se revisan colas, trabajos programados, generación de informes, importaciones, sincronizaciones y webhooks. El mensaje incluye un identificador de cliente validado y el consumidor vuelve a aplicar las restricciones antes de actuar. Una tarea ejecutada con una cuenta técnica global no debería confiar en que el productor ya filtró todo. Reintentos, mensajes duplicados y tareas antiguas pueden ejecutar una operación después de que un usuario haya perdido acceso.
Las cachés, índices de búsqueda, almacenamiento de archivos, miniaturas y contenido temporal también pueden mezclar resultados. La clave de caché debe distinguir clientes y permisos cuando afecten a la respuesta. Las URL firmadas caducan y se emiten después de comprobar el recurso; conocer la ruta de un archivo no debe bastar para descargarlo. Las exportaciones se generan en un espacio asociado al cliente y se retiran según la política acordada. Los logs ayudan a investigar, pero no deberían copiar datos sensibles de todas las empresas a un panel con acceso más amplio del necesario.
Las funciones de soporte y administración global merecen un flujo propio. Se comprueba quién puede seleccionar una empresa, entrar en su contexto, asumir una identidad, corregir un dato o lanzar una exportación. Estas acciones necesitan privilegio limitado, motivo, registro y una salida clara del modo de soporte. También se prueban cambios de pertenencia, bajas, fusiones, restauraciones y revocaciones: un permiso retirado debe dejar de ser válido en sesiones, cachés y decisiones distribuidas dentro del plazo definido, no solo desaparecer de la pantalla de administración.
Entrega evidencias reproducibles y vuelve a probar la frontera completa
Una prueba de aislamiento debe producir la mínima evidencia necesaria. Se conserva la cuenta de prueba, rol, cliente, solicitud, respuesta, hora y resultado esperado, ocultando tokens y datos que no aportan a la demostración. Un código 200 no acredita por sí solo una filtración y un 403 no demuestra que todas las rutas estén protegidas. La evidencia explica qué objeto o propiedad se obtuvo, qué acción se ejecutó y por qué la matriz de acceso no lo permitía. Las comprobaciones destructivas requieren autorización específica o se reproducen con datos sintéticos.
El informe separa el fallo observado de su posible alcance. Confirma la ruta y los perfiles probados, identifica otras funciones que comparten el mismo patrón y propone una corrección aplicable en el servidor. Centralizar políticas y filtros puede reducir inconsistencias, pero debe encajar con la arquitectura y evitar que una excepción comercial abra acceso general. NIST define el mínimo privilegio como conceder solo los recursos y autorizaciones necesarios; aplicado aquí, cada identidad, servicio y proceso recibe el contexto y las acciones imprescindibles.
La segunda comprobación reproduce el caso original y recorre rutas vecinas. Se verifica que el objeto ajeno ya no pueda leerse, modificarse ni inferirse y que las funciones legítimas del cliente sigan operativas. Las pruebas automatizadas de regresión crean dos organizaciones y fallan si una consulta, exportación o tarea cruza la frontera. Esa cobertura se ejecuta al cambiar permisos, repositorios, serializadores, cachés o procesos, porque una corrección puntual puede dejar otra vía abierta o bloquear operaciones válidas.
Élite Solutions Tech puede revisar desde Murcia aplicaciones multiempresa para proyectos regionales y nacionales dentro de un alcance autorizado. La propuesta concreta clientes y roles de prueba, rutas, API, integraciones, exclusiones, evidencias y si incluye retest; las recomendaciones no implican que el desarrollo correctivo esté incluido. Para una primera valoración puedes describir la función de la plataforma, número aproximado de roles y entornos disponibles en el formulario de contacto, sin enviar credenciales ni datos de clientes.