Aislamiento de tenants para MSP: un tenant ID o un login no es autorización

Un tenant ID proporcionado por el cliente, una cabecera X-Tenant-ID, un login que funciona, una política de Acceso Condicional o una conexión SSO indican algo útil, pero ninguno de ellos, por sí solo, demuestra que quien llama esté autorizado a ver los datos de un cliente concreto. Esta guía es para MSP y equipos de TI que operan o compran plataformas multi-tenant: expone, mecanismo por mecanismo, dónde debe situarse realmente una verificación de autorización del lado del servidor, desde la primera solicitud hasta el día en que se da de baja una cuenta.

Un tenant ID solo selecciona un cliente, no lo autoriza

Un tenant ID proporcionado por el cliente —en el cuerpo de la solicitud, en un parámetro de consulta, o resuelto a partir de un subdominio— es un selector. Indica a la aplicación qué contexto de cliente abrir. La OWASP Multi-Tenant Security Cheat Sheet establece la regla de fondo: vincular cada solicitud a un principal autenticado, resolver la pertenencia de ese principal al tenant a partir del estado del lado del servidor, aplicar comprobaciones a nivel de objeto dentro del tenant, y mantener las rutas administrativas o de emergencia separadas del acceso ordinario al tenant. Esa comprobación debe ejecutarse en todos los puntos donde importe un límite de tenant, no solo en la puerta de entrada de la API: en lecturas y escrituras, en acciones administrativas, y en trabajos en segundo plano que retoman tareas después de que la solicitud original haya terminado. Un trabajo activado por una cola que hereda un tenant ID de un mensaje, sin reverificarlo, vuelve a abrir exactamente la brecha que la comprobación original debía cerrar.

Una cabecera X-Tenant-ID o un campo del cuerpo esconden la misma trampa

El mismo error aparece con el nombre de una cabecera. Las API multi-tenant aceptan habitualmente una cabecera X-Tenant-ID o un campo de tenant en el cuerpo de la solicitud para elegir los datos de qué cliente debe tocar una llamada, y resulta tentador tratar ese valor como suficiente en cuanto se interpreta correctamente. Las guías de OWASP señalan dos riesgos relacionados: suponer que un identificador de tenant es seguro porque es largo o difícil de adivinar, en lugar de ejecutar una comprobación de autorización real; y dejar que una ruta de código normalmente delimitada por tenant caiga silenciosamente en una consulta sin delimitar cuando falta el valor esperado o está mal formado. Cualquiera de los dos fallos permite que alguien autenticado, pero que no pertenece al tenant solicitado, acceda a datos de otra persona.

El login demuestra quién eres, no qué tenant puedes tocar

La autenticación responde a una pregunta distinta del aislamiento. La NIST Special Publication 800-210, sobre control de acceso para sistemas en la nube, trata el aislamiento de tenants como una propiedad que la propia plataforma debe aplicar en cada API y ruta de datos cuando una única instancia de software da servicio a muchos tenants, porque el cliente que usa el servicio no controla la infraestructura subyacente. El Well-Architected SaaS Lens de AWS describe dos formas en que los proveedores construyen esto: en un modelo «silo» cada tenant tiene recursos dedicados y un rol de ejecución delimitado, más simple de entender pero más difícil de operar a gran escala; en un modelo «pool» los tenants comparten infraestructura y el aislamiento debe aplicarse dentro de la lógica de la aplicación en cada solicitud. Ningún modelo es intrínsecamente más seguro. Lo que importa es si un proveedor puede mostrar, de forma concreta, cómo se vincula una solicitud al tenant de quien llama antes de tocar cualquier dato, y no que quien llama tenga un login que funcione.

El Acceso Condicional protege el inicio de sesión, no la ruta de los datos

Microsoft describe el Acceso Condicional como un motor de políticas Zero Trust basado en lógica si-entonces: si un usuario, o cada vez más un agente de IA, intenta acceder a un recurso, entonces una condición como el cumplimiento del dispositivo, el riesgo del inicio de sesión o la ubicación debe cumplirse primero. Es una puerta realmente útil: puede impedir que una credencial comprometida inicie una sesión, o cortar una sesión que empieza a comportarse de forma sospechosa. Pero no tiene ninguna visibilidad sobre cómo decide el backend de una aplicación, una vez que existe una sesión, qué registros de qué cliente puede leer o escribir una llamada a la API concreta. Si una plataforma confía en un valor de tenant proporcionado por el cliente para tomar esa decisión, el Acceso Condicional ya ha terminado su trabajo, con éxito e irrelevantemente, en el momento en que se toma la decisión. Una puerta de inicio de sesión bien configurada delante de una API mal aislada produce la misma fuga que produciría sin esa puerta. La licencia Agent 365 de Microsoft está ampliando el Acceso Condicional a los agentes de IA, pero la misma distinción entre inicio de sesión y acceso a los datos seguirá aplicándose allí.

El SSO deja entrar a las personas; solo SCIM saca a quienes se van

La federación responde a «¿quién puede iniciar sesión ahora mismo?». El System for Cross-domain Identity Management, estandarizado como RFC 7644, responde a una pregunta distinta: qué cuentas deberían seguir existiendo. La documentación de aprovisionamiento SCIM de Microsoft describe el flujo habitual: una baja lógica en el proveedor de identidad pone en false el atributo active de un recurso de usuario, y se espera que la aplicación receptora deshabilite o archive esa plaza en respuesta. Sin una integración SCIM, el inicio de sesión único de quien se va deja de funcionar, pero su plaza —y cualquier acceso residual a la API vinculado a ella— puede persistir intacta. El lado del aprovisionamiento necesita su propio alcance: un token bearer de SCIM debería emitirse por cada tenant cliente y aceptarse solo en el endpoint SCIM de ese tenant. Compartir un único secreto SCIM multi-tenant entre varios clientes convierte un solo token filtrado en un riesgo de baja indebida y de apropiación de cuentas entre clientes distintos.

Deshabilitar la cuenta no termina la sesión ni el token

Cuando alguien se va y un administrador deshabilita su cuenta en el proveedor de identidad, es fácil suponer que el trabajo ha terminado. La propia guía de Microsoft sobre revocación de acceso dice lo contrario: deshabilitar una cuenta bloquea nuevos inicios de sesión, pero no invalida automáticamente los tokens de actualización, las sesiones activas ni las cookies del navegador ya emitidas. Cortar el acceso real exige revocar por separado sesiones y tokens y borrar las credenciales en caché, y, cuando está disponible, la Evaluación Continua de Acceso aplica el corte más rápido que esperar a que un token expire por sí solo. El borrador de la guía de gestión de sesiones del NIST plantea un punto relacionado: poseer un token de acceso válido no es prueba de que una sesión siga abierta legítimamente, y las sesiones del proveedor de identidad y las de la aplicación son independientes entre sí, así que terminar una no termina la otra. Por eso la OWASP Session Management Cheat Sheet exige la invalidación de sesión del lado del servidor con tiempos de espera tanto de inactividad como absolutos, en lugar de confiar en que el cliente descarte las credenciales.

Algunos MSP prefieren delegar este trabajo de plano de control en un proveedor dedicado en lugar de construirlo y auditarlo ellos mismos; Auris es una plataforma europea de IAM-as-a-Service para MFA adaptativa, SSO federado y registros de auditoría inmutables.

Qué hacer

• Resolver la pertenencia al tenant a partir de datos de identidad del lado del servidor en cada solicitud; no confiar nunca solo en un ID, cabecera o campo del cuerpo proporcionado por el cliente.
• Aplicar esa comprobación en cada ruta donde intervenga un límite de tenant: lecturas, escrituras, acciones administrativas y trabajos en segundo plano o activados por cola.
• Rechazar cualquier selector de tenant que no se haya confirmado frente a las pertenencias reales del llamante autenticado, en lugar de suponer que un identificador largo es seguro.
• Tratar el Acceso Condicional, el SSO y la vinculación al tenant como controles separados con modos de fallo distintos, y probarlos por separado.
• Activar SCIM junto con el SSO, delimitar cada token de SCIM a un único tenant, y confirmar que la cuenta de quien se va queda deshabilitada también en el sistema de origen, no solo en el proveedor de identidad.
• En la baja, revocar explícitamente sesiones y tokens de actualización en cada aplicación que la persona haya usado, en lugar de detenerse en «cuenta deshabilitada».

Fuentes: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — Información general sobre el Acceso Condicional, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.