Lista de verificación de aislamiento entre clientes en un SaaS

El aislamiento en un SaaS significa que una organización cliente no puede leer ni modificar recursos de otra mediante ninguna ruta del producto. Agregar una columna de organización a las tablas es apenas el inicio. Las exportaciones, tareas en segundo plano, descargas y herramientas de soporte necesitan el mismo límite.

Una revisión útil sigue los datos fuera de la base de datos, especialmente donde el código suele asumir que alguien ya validó el contexto.

Establecé el contexto y verificá dónde se usa

Obtené la organización activa desde las membresías autorizadas del usuario autenticado. El navegador puede solicitar un cambio de cuenta, pero el servidor debe validarlo. Un identificador enviado selecciona una organización; no demuestra permiso.

La guía de aislamiento de AWS explica que la estrategia depende del despliegue y del contexto del negocio. Tanto la infraestructura separada como la compartida requieren diseño explícito. Esta lista no reemplaza esa elección.

Identificá los recursos que pertenecen a cada cliente y los que son realmente globales. Documentá cualquier intercambio permitido. Una tabla o ruta de almacenamiento sin clasificar es una decisión pendiente, no una excepción que el código deba adivinar.

Revisá los límites fuera de las solicitudes habituales

Superficie	Pregunta de revisión	Prueba negativa
Lecturas y escrituras API	¿Se verifica la organización propietaria del objeto?	Enviar el identificador de un objeto ajeno
Tareas en segundo plano	¿El trabajador valida el contexto persistido?	Ejecutar una tarea con recursos de otra organización
Archivos	¿Se valida el acceso antes de descargar?	Solicitar una exportación ajena
Caché y búsqueda	¿Claves y filtros tienen el alcance correcto?	Repetir la misma consulta entre cuentas
Soporte	¿El acceso privilegiado es explícito y queda registrado?	Probar credenciales ordinarias en rutas de soporte

Las restricciones de la base de datos también deben impedir relaciones accidentales entre organizaciones. Que existan un proyecto y un cliente no significa que puedan vincularse. Revisá operaciones masivas y scripts administrativos por separado.

Los registros y adjuntos de diagnóstico también pueden contener datos del cliente. Limitá su acceso y evitá copiar cargas completas en paneles internos de uso general. La revisión incluye a quienes operan la plataforma.

Ejemplo hipotético: una exportación expuesta

Un SaaS de planificación tiene dos organizaciones que llaman a su reporte “Actividad mensual”. El endpoint verifica correctamente la membresía y pone la exportación en cola.

El trabajador guarda ambos resultados con un nombre compartido, derivado únicamente del título. La descarga entrega el último archivo escrito. Todas las consultas tenían filtro por organización; el límite falló en el almacenamiento.

Usá claves de archivo distintas por organización y guardá quién es dueño de cada exportación. Volvé a validar el acceso al descargar. Si usás enlaces firmados temporales, definí su vigencia y posibilidad de compartirlos: no asumás que reflejan continuamente cambios de membresía.

Convertí el aislamiento en criterio de lanzamiento

Creá dos organizaciones de prueba con nombres parecidos e identificadores locales coincidentes. Probá creación, búsquedas, descargas, eliminación, restauración y reintentos. Incluí una persona con acceso a ambas cuentas para verificar los cambios de organización.

Un botón oculto no demuestra una denegación. Llamá directamente al endpoint y revisá respuesta y efectos. Cualquier acceso entre cuentas sin explicación debe bloquear el lanzamiento.

Empezá la próxima revisión siguiendo una exportación completa, incluido almacenamiento y soporte. Ese ejercicio acotado permite a un equipo de software a la medida convertir límites abstractos en pruebas que luego puede extender al resto del producto.