Una aplicación compartida puede atender eficientemente a muchas organizaciones. También debe mantener un límite fiable entre sus registros, acciones y recursos. Ese límite es fácil de describir en una conversación comercial y sorprendentemente fácil de debilitar con un filtro de consulta olvidado, un endpoint de exportación o un trabajo que pierde el contexto del cliente.
El diseño multiinquilino empieza por definir qué representa cada organización cliente y cómo se establece el acceso a ella. El almacenamiento forma parte del diseño, pero el aislamiento debe continuar en APIs, archivos, cachés, búsquedas y herramientas de soporte. La aplicación debe poder explicar por qué un usuario concreto puede realizar una operación concreta sobre la información de un cliente.
Define la pertenencia a una organización por separado de la identidad
Una cuenta de usuario y una organización cliente son conceptos distintos. Una persona puede trabajar para varias organizaciones y varias personas pertenecer al mismo cliente. Decide cómo se conceden, cambian y retiran las pertenencias, incluidos los roles dentro de cada organización.
Elige cómo se establece el cliente activo para cada solicitud. Una ruta, un subdominio o una organización seleccionada pueden indicar el contexto solicitado, pero el servidor debe comprobar que el usuario autenticado pertenece a él. Trata el identificador de cliente recibido como una entrada que validar, no como una prueba de permiso.
Incluye identidades menos evidentes, como cuentas de integración, personal de soporte y procesos en segundo plano. Su acceso necesita alcance y responsables explícitos. Una comodidad administrativa no debe conceder silenciosamente a todos los servicios capacidad para actuar sobre toda la base de clientes.
Elige el aislamiento del almacenamiento según los requisitos
Las opciones habituales incluyen tablas compartidas con identificadores de cliente, bases de datos separadas e infraestructura independiente para determinados clientes. Cada opción cambia el coste operativo, el límite de aislamiento y el trabajo de altas, actualizaciones y recuperación. La elección debe responder a requisitos reales de los clientes y de la carga.
La guía de Microsoft sobre almacenamiento y datos multiinquilino compara estos enfoques y sus compromisos. Ninguna distribución elimina la necesidad de una autorización correcta en la aplicación, incluso si los clientes tienen bases de datos separadas.
Considera las tareas operativas al comparar opciones. ¿Puede el equipo restaurar un cliente, exportar su información o trasladarlo a otra configuración? Un diseño que facilita las altas iniciales pero dificulta cada recuperación individual puede crear una carga importante de soporte.
Comprueba la propiedad al acceder a los registros
Comprueba tanto la acción solicitada como la organización propietaria del registro. Un usuario que puede consultar pedidos en una organización no debe acceder al pedido de otra cambiando un identificador en la URL. Aplica la misma regla a actualizaciones, adjuntos y referencias indirectas dentro de una solicitud.
Centraliza las comprobaciones comunes cuando reduzca las omisiones, pero entiende dónde pueden eludirse esos mecanismos. Las consultas directas, las rutas especiales de informes y las herramientas administrativas quizá no utilicen los mismos filtros que las pantallas habituales. Revisa explícitamente esas excepciones.
En una plataforma hipotética de planificación, un técnico podría actualizar trabajos asignados dentro de su organización. El servidor debe comprobar su pertenencia, la propiedad del trabajo y las reglas de asignación. Ocultar los trabajos de otro cliente en la navegación no protege el endpoint subyacente.
Conserva el contexto del cliente en el trabajo asíncrono
Un trabajo en segundo plano necesita un contexto de cliente explícito y validado. No asumas que la sesión web seguirá existiendo cuando se ejecute después. Registra la identidad o el contexto de autorización pertinente y decide qué permisos deben comprobarse de nuevo al ejecutar.
Piensa en los cambios durante la espera. Un usuario puede perder el acceso después de pedir una exportación o una cuenta puede suspenderse antes de iniciar una operación en cola. Define si el trabajo sigue autorizado y cómo comunica el sistema esa decisión.
Aísla también el estado y los resultados. Una consulta de base de datos cuidadosamente delimitada no basta si la exportación generada queda en una dirección pública. La ruta desde la solicitud hasta el resultado almacenado debe conservar el mismo límite durante todo el proceso.
Incluye cachés, búsquedas y archivos en el modelo
Utiliza claves de caché que tengan en cuenta al cliente y valida el contexto de sus valores. Una clave basada solo en el número de registro puede coincidir entre organizaciones. Las cachés compartidas requieren un diseño explícito del alcance del cliente, los datos específicos del usuario y la invalidación cuando cambian los permisos.
Aplica controles de acceso adecuados al almacenamiento documental y a los resultados de búsqueda. Un índice puede exponer información aunque las consultas de la aplicación principal sean correctas. Comprueba que fragmentos, sugerencias y resúmenes generados no revelen contenido fuera del alcance permitido.
Revisa problemas similares en registros y herramientas de soporte. Los datos operativos pueden incluir identificadores de clientes o detalles documentales, por lo que el acceso debe corresponder a su finalidad. Un panel interno no debe convertirse en una vía alternativa sin control hacia información de clientes.
Prueba los límites con más de una organización
Crea casos de prueba con al menos dos clientes y usuarios con pertenencias diferentes. Reutiliza identificadores de registro similares cuando el almacenamiento lo permita, para que las pruebas no dependan accidentalmente de valores globalmente únicos que oculten un límite ausente. Prueba lecturas, escrituras, exportaciones y resultados de trabajos.
Prueba pertenencias revocadas, roles modificados e intentos de mezclar referencias de distintos clientes en una solicitud. Un formulario puede contener un pedido autorizado y un adjunto no autorizado; validar solo el registro principal deja una brecha.
Incluye clientes no interactivos y funciones operativas. Los endpoints de integración, informes programados y funciones de suplantación para soporte suelen seguir código distinto del navegador habitual. Mantén unas pocas pruebas significativas de aislamiento en la entrega para que los cambios futuros no dependan solo de revisión manual.
Gestiona los recursos compartidos, además de la confidencialidad
Un cliente puede afectar a otro sin ver sus datos. Una exportación grande, búsquedas intensivas o una integración que falla repetidamente pueden consumir capacidad compartida. Establece cuotas, límites de concurrencia y separación de cargas donde el negocio necesite un servicio previsible.
Mide la demanda por cliente mediante identificadores operativos adecuados. Esto ayuda a localizar cargas concentradas y a decidir sobre capacidad dedicada. No asumas que todo cliente grande necesita infraestructura separada: utiliza comportamiento observado y requisitos contractuales para justificar su coste.
Worktechlabs puede ayudarte a diseñar portales de clientes y aplicaciones .NET con límites claros y reglas de acceso verificables. Combina ese trabajo con la planificación de permisos y el diseño de caché para que el aislamiento siga siendo una propiedad de toda la aplicación al crecer.
