Arquitectura multitenencia: patrones, aislamiento y análisis

La arquitectura multitenant es un diseño en el que una aplicación y su infraestructura dan servicio a muchos clientes, denominados «tenants», mientras que cada tenant solo ve sus propios datos. IBM describe a un tenant como, por lo general, un grupo de usuarios —por ejemplo, la organización de un cliente— al que da servicio una única instancia del software. Lo difícil no es compartir los servidores, sino demostrar que el inquilino A nunca puede leer las filas del inquilino B, ni en la aplicación, ni en la base de datos, ni en los paneles de control que se muestran a los clientes.

Esta guía aborda los tres patrones de datos principales, cómo aislar a los inquilinos, qué hay que probar y cómo encaja el análisis de datos. Creamos paneles de control para equipos de SaaS, por lo que también tratamos el tema delicado que la mayoría de las guías omiten: el análisis de datos a nivel de inquilino.

dashrendrapp.dashrendr.comIncorpora el análisis por inquilino a tu productoCrea paneles personalizables a partir de datos conectados o de tu API REST y, a continuación, incrústalos para que los clientes de SaaS vean sus propios datos.Prueba el entorno de pruebas

Resumen

• La multitenencia significa que los clientes comparten algunos o todos los recursos. «Silo», «bridge» y «pool» son los tres patrones habituales de bases de datos, que equilibran el aislamiento con el coste.
• El aislamiento es un mecanismo independiente, distinto del inicio de sesión y los permisos. Debe aplicarse en todas las rutas que toquen los datos de los inquilinos, incluidos los informes y los paneles de control.
• La mayoría de los productos SaaS combinan varios patrones. Es habitual compartir recursos de computación con almacenamiento específico para cada cliente, y los niveles pueden variar.
• Prueba el aislamiento desde el exterior, con un rol limitado al inquilino, e incorpora las pruebas a la integración continua (CI).
• dashrendr es una plataforma de análisis para equipos de SaaS. Los planes empiezan en 6 $ al mes, con una prueba gratuita de 14 días y sin necesidad de tarjeta de crédito.

Índice

• Qué significa realmente la arquitectura multitenencia
• Silo, puente y grupo: los tres modelos de datos
• Cómo funciona el aislamiento de inquilinos en la práctica
• Pruebas y supervisión de los límites de los inquilinos
• Dónde encaja el análisis multitenant
• Nuestra perspectiva
• Cómo poner los paneles de control de los inquilinos a disposición de los clientes con dashrendr
• Los errores que vemos con más frecuencia
• Preguntas frecuentes
• Fuentes

Qué significa realmente la arquitectura multitenencia

Un inquilino es una organización cliente, no un usuario individual. La multitenencia describe cómo los inquilinos comparten recursos. AWS la define como la gestión y el funcionamiento colectivo de los inquilinos, en el que los recursos pueden ser compartidos o dedicados. También destaca un aspecto que conviene recordar: el SaaS es más un modelo de negocio que una estrategia de arquitectura. La venta de suscripciones no determina cómo está estructurada tu base de datos.

Las razones habituales para compartir son el coste y las operaciones. OWASP señala que dar servicio a muchos clientes desde una infraestructura, un código y, a menudo, unas bases de datos compartidas favorece la eficiencia en los costes y simplifica las operaciones. Esa misma frase encierra la trampa: el aislamiento de los inquilinos se convierte en un requisito de seguridad fundamental.

El modelo de inquilino único se sitúa en el extremo opuesto. Cada cliente dispone de su propia implementación. Es fácil de entender, pero caro de mantener, ya que hay que aplicar parches, supervisar y actualizar cada copia.

Los cuatro pilares

AWS enumera cuatro pilares fundamentales de una arquitectura SaaS multitenant:

1. Identidad del inquilino: cada solicitud incluye un contexto de inquilino verificado.
2. Aislamiento de datos: el almacenamiento está particionado de modo que un inquilino no pueda acceder a los datos de otro.
3. Capacidad de cálculo y tiempo de ejecución: procesamiento compartido o dedicado, con límites en cuanto al consumo de cada inquilino.
4. Operaciones: incorporación, supervisión e implementación que funcionan por inquilino y de forma global para todos ellos.

Si estás en una fase inicial, lo primero es la identidad. Todo lo demás depende de saber, de forma fiable, a qué inquilino pertenece una solicitud.

Silo, puente y grupo: los tres modelos de datos

La guía de AWS para arquitecturas multitenant menciona tres modelos de capa de base de datos. Aquí los vemos comparados.

Modelo	Cómo funciona	Aislamiento	Coste y complejidad
Silo	Pila de aplicaciones y base de datos dedicadas por cliente	Más sólida	Más alto
Puente	Pila de aplicaciones y instancia de base de datos compartidas, esquema dedicado por cliente	Intermedio	Intermedio
Pool	Pila, instancia y tablas compartidas, con seguridad a nivel de fila que separa a los clientes	El más débil por defecto	El más bajo

El modelo «Silo» es para aquellos clientes que exigen contractualmente su propio entorno. El modelo «Pool» es el punto de partida de la mayoría de los productos en fase inicial, ya que un esquema equivale a una migración. El modelo «Bridge» se sitúa entre ambos: un único servidor de base de datos, pero cada cliente tiene su propio conjunto de tablas.

No es necesario elegir uno

AWS señala que los diferentes servicios de un mismo producto pueden utilizar distintos patrones de tenencia: computación y almacenamiento compartidos, computación compartida con almacenamiento específico para cada cliente, o computación específica para cada cliente con almacenamiento compartido. El riesgo de «vecinos ruidosos», los niveles de precios y las necesidades de aislamiento varían en cada caso. Una división habitual es un modelo agrupado para planes pequeños y un silo para un cliente empresarial que lo solicite.

Una forma aproximada de elegir

• Muchos inquilinos pequeños, sensibles al coste: modelo agrupado, con políticas estrictas a nivel de fila y buenas pruebas.
• Unos pocos inquilinos grandes con requisitos de cumplimiento normativo: silo o, como mínimo, un modelo puente.
• Una combinación de ambos: modelo agrupado por defecto, con una vía de actualización a recursos dedicados para los niveles premium.

IBM expone claramente el dilema: los desarrolladores deben equilibrar las necesidades de aislamiento de datos de los clientes con un diseño que se amplíe de forma rápida y asequible a medida que crece el tráfico. No existe ningún modelo que cumpla ambos requisitos.

Cómo funciona el aislamiento de inquilinos en la práctica

La autenticación indica quién eres. La autorización determina lo que puedes hacer. El aislamiento de inquilinos, tal y como lo define AWS, es un conjunto independiente de mecanismos explícitos que controlan estrictamente el acceso a los recursos y bloquean el acceso entre inquilinos. Un usuario puede estar plenamente autenticado y autorizado en su propio inquilino y, aun así, acceder a los datos de otro inquilino a través de un error de seguridad. El aislamiento es la capa que lo impide.

OWASP afirma que los datos de los inquilinos pueden aislarse mediante bases de datos independientes, esquemas separados o tablas compartidas con políticas a nivel de fila, o bien mediante una solución híbrida, elegida en función de las necesidades de seguridad, cumplimiento normativo, operativas y de costes. También señala que el contexto del inquilino debe verificarse y aplicarse en todas las rutas de acceso que le pertenecen. «Todas las rutas» es precisamente donde los equipos cometen errores: la API principal está protegida, pero una tarea de exportación, un proceso en segundo plano o una consulta de generación de informes no lo están.

Seguridad a nivel de fila en PostgreSQL

En los modelos agrupados de PostgreSQL, la seguridad a nivel de fila (RLS) restringe las filas a las que puede acceder una consulta, en función del usuario actual o de una variable de tiempo de ejecución. La documentación de PostgreSQL describe CREATE POLICY como el comando que define una política de seguridad a nivel de fila para una tabla. La regla general es sencilla: la base de datos aplica el filtro, por lo que una cláusula WHERE olvidada en el código de la aplicación no provoca fugas de datos.

Para los diseños de tablas compartidas, OWASP exige cuatro requisitos: propiedad del inquilino aplicable a cada fila, cobertura completa de la política, roles de solicitud restringidos y pruebas de rutas negativas. Analizamos los mecanismos en nuestro artículo sobre seguridad a nivel de fila para paneles de control y en un análisis más detallado sobre el aislamiento de datos de inquilinos en bases de datos compartidas.

Los «vecinos ruidosos» también suponen un problema de aislamiento

El aislamiento no se limita a las lecturas. Un inquilino que ejecute un informe pesado puede ralentizar a todos los demás. Las directrices de AWS sobre implementaciones agrupadas indican que un aislamiento eficaz requiere la limitación del ancho de banda en las capas compartidas, y el ejemplo que se ofrece allí son las cargas de trabajo de los agentes, pero el principio se aplica a cualquier API compartida o capa de consultas. Los límites de tasa específicos para cada inquilino son un seguro económico.

Pruebas y supervisión de los límites de los inquilinos

La recomendación de OWASP es realizar las pruebas utilizando el mismo rol de solicitud y la misma ruta de conexión que utiliza tu aplicación, no como superusuario de la base de datos. Un superusuario elude las políticas que estás intentando verificar. La lista de comprobación de la hoja de referencia sobre entornos multitenant:

• Confirma que se deniegan las operaciones entre inquilinos, no solo que las operaciones de tu propio inquilino se realicen con éxito.
• Comprueba la cobertura de RLS en todas las tablas que contengan datos de inquilinos, incluidas las nuevas.
• Comprueba que el contexto del inquilino se restablezca correctamente en las conexiones reutilizadas, de modo que una conexión del grupo no conserve la identidad del último inquilino.
• Aplica límites de tasa específicos para cada inquilino en los recursos compartidos.

Una prueba concreta de la guía de regresión de autorización de OWASP: ejecuta consultas de lectura amplias como un inquilino y confirma que no se devuelven datos de ningún otro inquilino. La misma guía recomienda ejecutar estas pruebas en CI/CD para que una compilación falle si un cambio filtra datos entre inquilinos.

Lo que está en juego justifica el esfuerzo. OWASP advierte de que una sola vulnerabilidad puede exponer los datos de todos los clientes, y que una configuración errónea puede provocar fugas más allá de los límites. En un entorno aislado, un error expone a un solo cliente. En un entorno compartido, puede exponerlos a todos.

Dónde encaja el análisis multitenant

La analítica es la parte de un producto multitenant en la que es más fácil cometer errores, ya que los paneles de control consultan una gran cantidad de datos y, a menudo, se desarrollan después de la aplicación principal. Bajo este término se esconden dos tareas distintas.

Análisis orientado al cliente. Cada cliente ve gráficos de sus propios datos dentro de tu producto. Aquí se aplican directamente las reglas de aislamiento mencionadas anteriormente: el panel de control solo debe consultar las filas de ese inquilino. Nuestra guía sobre paneles de control multinquilino y aislamiento de datos explica cómo funciona esto, y los tres patrones de arquitectura para el análisis integrado comparan las opciones de desarrollo.

Métricas a nivel de cliente para tu propio equipo. AWS SaaS Lens recomienda recopilar información a nivel de cliente sobre el uso de las funciones, el consumo de recursos, el estado del sistema y los costes del cliente. Según AWS, esta información le ayuda a evaluar el escalado, comprender el uso de las funciones y definir la estrategia empresarial y arquitectónica. AWS también separa la medición (datos para la facturación) de las métricas (datos para el análisis empresarial y operativo). Se necesitan ambas, y suelen encontrarse en tablas diferentes.

Consecuencias prácticas:

• Incluye un identificador de cliente en todas las tablas de análisis, no solo en las transaccionales.
• Decida qué paneles de control corresponden a un inquilino concreto y cuáles son vistas de administración para varios inquilinos. Nunca reutilice uno para el otro.
• Considera los informes programados por correo electrónico como otra vía de acceso. Un informe enviado a un cliente debe tener el mismo ámbito de aplicación que el panel de control en tiempo real.
• Elige métricas que interesen a los clientes. A continuación enumeramos cinco métricas que vale la pena mostrar a los clientes.

Nuestra perspectiva

A menudo nos hacen una variante de la misma pregunta: ¿deberíamos crear nosotros mismos los paneles de control de los clientes? Nuestra respuesta sincera es que una biblioteca de gráficos te permite crear gráficos en una tarde, pero ahí es donde empieza el verdadero trabajo. Los diseños, la seguridad por cliente, las exportaciones, los correos electrónicos programados y la personalización de la marca recaen en tu equipo. Por otro lado, las herramientas de BI empresarial están diseñadas para analistas, cuestan más de 1.000 dólares al mes en los casos con los que las comparamos y su configuración requiere un esfuerzo considerable.

Creamos dashrendr para cubrir ese vacío. Es una plataforma de análisis para equipos de SaaS: conecta tus fuentes de datos o envía datos a través de la API REST, crea paneles de control en un editor de arrastrar y soltar y, a continuación, incrústalos en tu producto, utilízalos internamente o envíalos por correo electrónico de forma programada.

Nuestra opinión sobre el aislamiento es que primero debes elegir tu modelo de tenencia, basándote en sus propias ventajas, y luego asegurarte de que tu capa de análisis lo respete, y no al revés. Elijas lo que elijas, pruébalo desde fuera, tal y como lo haría un cliente.

— Paloma

Mostrar los paneles de control de los inquilinos a los clientes con dashrendr

Los planes de dashrendr empiezan en 6 $ al mes. Los niveles publicados son «Hobby» a 6 $ al mes, «Starter» a 15 $, «Grow» a 39 $ y «Premium» a 99 $; cada miembro adicional del equipo cuesta 3 $ al mes. Los planes difieren en el número de paneles de control, miembros del equipo, marca blanca y acceso a funciones. Hay una prueba gratuita de 14 días y no se necesita tarjeta de crédito para empezar.

Si estás comparando opciones, empieza por la página de precios y averigua qué plan se ajusta a tu número de paneles. dashrendr admite seguridad multitenant, portales de marca blanca para vistas personalizadas de los clientes y informes automatizados enviados por correo electrónico. Los datos proceden de fuentes como PostgreSQL, MySQL, BigQuery, MongoDB, Google Sheets y Google Analytics, que aparecen en la sección de integraciones de datos. Si tus datos están en Postgres, consulta cómo crear un panel de métricas SaaS en PostgreSQL.

Estos mismos paneles de control también funcionan a nivel interno, para que los equipos de operaciones y de soporte técnico puedan realizar un seguimiento de sus propios KPI.

Errores más comunes

• Filtrar únicamente en la interfaz de usuario. Ocultar los datos de otros inquilinos en la interfaz no supone un aislamiento. La propia consulta debe tener un ámbito de aplicación definido.
• Olvidarse de las «puertas traseras». Las exportaciones, los webhooks, las tareas en segundo plano y los informes programados necesitan el mismo contexto de cliente que la API principal.
• Realizar pruebas como administrador. Los roles de administrador eluden las políticas, por lo que las pruebas se superan y no demuestran nada.
• Atraparse en un único patrón. Planifica un nivel premium que cuente con recursos dedicados, incluso si empiezas con recursos compartidos.
• Ignorar el coste en el almacén de análisis. Los paneles por cliente pueden multiplicar las consultas. Nuestra nota sobre la optimización de costes de BigQuery para paneles SaaS aborda un caso habitual.

Preguntas frecuentes

¿Cuál es la diferencia entre la arquitectura de inquilino único y la de múltiples inquilinos?

En la arquitectura de un solo inquilino, cada cliente dispone de una implementación independiente de la aplicación y la base de datos. En la arquitectura multinquilino, una sola instancia da servicio a muchos clientes y mantiene sus datos separados mediante controles lógicos. La arquitectura multinquilino es más económica de mantener y más fácil de actualizar, mientras que la de un solo inquilino ofrece un aislamiento más sencillo a un coste mayor.

¿Qué modelo de base de datos multitenant debería elegir?

Depende del número de inquilinos y de los requisitos de aislamiento. AWS describe los modelos «silo», «bridge» y «pool»: el modelo «silo» es el que ofrece mayor aislamiento y el más costoso, mientras que el modelo «pool» es justo lo contrario. Muchos equipos empiezan con el modelo «pool» y, más adelante, ofrecen recursos dedicados a los clientes más grandes.

¿Es suficiente la seguridad a nivel de fila para aislar a los inquilinos?

Es un control sólido para las bases de datos en «pool», pero no es la solución completa. OWASP también exige una cobertura completa de las políticas, roles de solicitud restringidos y pruebas de rutas negativas. Sin ellos, una brecha en la política de una tabla puede seguir provocando fugas de datos.

¿Cómo mantengo seguros los paneles de control de los clientes en una aplicación multitenant?

Limita el alcance de cada consulta del panel de control al inquilino en el lado del servidor y aplica el mismo alcance a las exportaciones y a los correos electrónicos programados. A continuación, realiza pruebas con un rol a nivel de inquilino para confirmar que se rechazan los datos de otros inquilinos. Nuestra guía de aislamiento de paneles de control detalla los pasos a seguir.

Fuentes

• ¿Qué es la multitenencia? | IBM
• Redefinición de la multitenencia, Fundamentos de la arquitectura SaaS de AWS
• Seguridad multitenant, serie de fichas de referencia de OWASP
• Arquitectura SaaS multitenant: 4 pilares, AWS
• Guía para arquitecturas multitenant en AWS
• Fundamentos de la arquitectura SaaS, documento técnico de AWS
• Orientación prescriptiva de AWS: multitenencia gestionada de PostgreSQL
• Documentación de PostgreSQL: CREATE POLICY
• AGENTPERF07-BP02, AWS Well-Architected
• Pruebas de regresión de autorización, serie de fichas de referencia de OWASP
• SaaS Lens, Marco de arquitectura recomendada de AWS

Recomendado

• Cuadros de mando multitenant: guía de aislamiento de datos
• Aislamiento de datos de inquilinos en bases de datos compartidas
• Arquitectura de análisis de SaaS: comparación de tres patrones
• Análisis de autoservicio: guía práctica para SaaS