Crear una aplicación multiinquilino puede ser desafiante, con muchos aspectos a considerar. Este artículo compila todas nuestras publicaciones de blog anteriores sobre el entendimiento de prácticas multiinquilinas y organizacionales. Para comenzar rápidamente y ahorrar tiempo, simplemente revisa este artículo, ¡incluye todo lo que necesitas! Las pautas generales están esbozadas en los siguientes pasos: 1. Entender la arquitectura multiinquilina 2. Mapear los casos de uso de tu aplicación multiinquilino 3. Lograr el aislamiento de inquilinos 4. Definir cómo deseas gestionar las identidades 5. Elegir los modelos de autorización apropiados ## Entender la arquitectura multiinquilina La multiinquilinidad en software es una [arquitectura de software](https://es.wikipedia.org/wiki/Arquitectura_de_software) en la cual una única [instancia]() de [software](https://es.wikipedia.org/wiki/Software) se ejecuta en un servidor y atiende a múltiples inquilinos. Los sistemas diseñados de esa manera son "compartidos" (en lugar de "dedicados" o "aislados"). Un inquilino es un grupo de usuarios que comparten acceso común con privilegios específicos a la instancia de software. multi-tenant

Una de las claves del pensamiento multiinquilino es “compartido”. En la definición más amplia de multiinquilinidad, ser una aplicación multiinquilino no implica que **cada** componente en una solución sea compartido. Más bien, implica que al menos **algunos** componentes de una solución son reutilizados por múltiples inquilinos. Entender este término de manera amplia puede ayudarte mejor a empatizar con las necesidades de tu cliente y de dónde vienen. Una vez que entiendas la arquitectura multiinquilina, el siguiente paso es aplicar tu aplicación a escenarios del mundo real, enfocándote en necesidades específicas de productos y negocios. ## Mapear los casos de uso de tu aplicación multiinquilino ### SaaS Las aplicaciones multiinquilinas a menudo encuentran su lugar en soluciones de negocio a negocio (B2B) como herramientas de productividad, software de colaboración y otros productos de software como servicio (SaaS). En este contexto, cada "inquilino" típicamente representa un cliente de negocio, que podría tener múltiples usuarios (sus empleados). Además, un cliente de negocio podría tener múltiples inquilinos para representar organizaciones distintas o divisiones de negocio. ![SaaS](https://uploads.strapi.logto.io/1/saas_product_d63c736650.webp) ### Casos de uso genéricos B2B Las aplicaciones B2B van más allá de los productos SaaS y a menudo implican el uso de aplicaciones multiinquilinas. En contextos B2B, estas aplicaciones sirven como una plataforma común para varios equipos, clientes de negocio y empresas asociadas para acceder a tus aplicaciones. Por ejemplo, considera una empresa de servicios de transporte compartido que proporciona tanto aplicaciones B2C como B2B. Las aplicaciones B2B atienden a múltiples clientes de negocio, y emplear una arquitectura multiinquilino puede ayudar a administrar a sus empleados y recursos. Para ilustrar, si la empresa desea mantener un sistema de identidad de usuario unificado, puede diseñar una arquitectura como el siguiente ejemplo: Sarah tiene tanto una identidad personal como una identidad de negocio. Ella utiliza el servicio de transporte compartido como pasajera y también trabaja como conductora en su tiempo libre. En su rol profesional, también administra su negocio y usa esta identidad de negocio para ser socia con el Negocio 1.

### ¿Por qué deberías emplear multiinquilinidad en un producto SaaS? #### Escalando con multiinquilinidad Para las empresas, la multiinquilinidad es la llave para cumplir efectivamente con sus requisitos de disponibilidad, gestión de recursos, gestión de costos y seguridad de datos. A nivel técnico, adoptar un enfoque multiinquilino agiliza tus procesos de desarrollo, minimiza los desafíos técnicos y promueve una expansión sin problemas. #### Crear una experiencia unificada Al examinar las raíces de los productos SaaS, es similar a un edificio que alberga varios apartamentos. Todos los inquilinos comparten servicios comunes como agua, electricidad y gas, sin embargo, mantienen un control independiente sobre la gestión de su propio espacio y recursos. Este enfoque simplifica la gestión de propiedades. #### Asegurando la seguridad a través del aislamiento de inquilinos En una arquitectura multiinquilino, se introduce el término "inquilino" para crear límites que separen y aseguren los recursos y datos de diferentes inquilinos dentro de una instancia compartida. Esto asegura que los datos y operaciones de cada inquilino se mantengan distintos y seguros, incluso si están utilizando los mismos recursos subyacentes. ## Lograr el aislamiento de inquilinos Cuando se discuten aplicaciones multiinquilinas, siempre es necesario lograr **el aislamiento de inquilinos**. Esto significa mantener los datos y recursos de diferentes inquilinos separados y seguros dentro de un sistema compartido (por ejemplo, una infraestructura en la nube o una aplicación multiinquilino). Esto previene cualquier intento no autorizado de acceder a los recursos de otro inquilino. Aunque la explicación puede parecer abstracta, usaremos ejemplos y detalles clave para explicar más a fondo la mentalidad de aislamiento y la mejor práctica para lograr el aislamiento de inquilinos. ### El aislamiento de inquilinos no va en contra de la mentalidad "compartida" de la multiinquilinidad Eso se debe a que el aislamiento de inquilinos no es necesariamente un constructo a nivel de recursos de infraestructura. En el ámbito de la multiinquilinidad y el aislamiento, algunos ven el aislamiento como una división estricta entre los recursos de infraestructura reales. Esto generalmente lleva a un modelo donde cada inquilino tiene bases de datos, instancias de computación, cuentas o nubes privadas separadas. En escenarios de recursos compartidos, como las aplicaciones multiinquilinas, la forma de lograr el aislamiento puede ser un constructo lógico. El aislamiento de inquilinos se enfoca exclusivamente en usar el contexto del “inquilino” para limitar el acceso a los recursos. Evalúa el contexto del inquilino actual y usa ese contexto para determinar qué recursos son accesibles para ese inquilino. ### La autenticación y la autorización no son iguales a “aislamiento” Usar la autenticación y autorización para controlar el acceso a tus entornos de SaaS es importante, pero no es suficiente para un aislamiento completo. Estos mecanismos son solo una parte del rompecabezas de seguridad. Las personas a menudo preguntan si pueden usar soluciones de autorización general y control de acceso basado en roles para lograr el aislamiento de inquilinos. Aquí está la cuestión: puedes construir una aplicación multiinquilino, pero no puedes decir que lograste y empleaste estrategias de aislamiento de inquilinos como una mejor práctica. Generalmente no lo recomendamos porque El aislamiento de inquilinos es separado de la autenticación y la autorización. Para ilustrar, considera una situación donde has configurado la autenticación y autorización para tu sistema SaaS. Cuando los usuarios inician sesión, reciben un token que contiene información sobre su rol, dictando lo que pueden hacer en la aplicación. Este enfoque aumenta la seguridad, pero no asegura el aislamiento. ### Usa “organización” para representar al inquilino del producto SaaS, para lograr el aislamiento de inquilinos Confiar únicamente en la autenticación y autorización no impedirá que un usuario con el rol adecuado acceda a los recursos de otro inquilino. Por lo tanto, necesitamos incorporar un contexto de “inquilino”, como un ID de inquilino, para restringir el acceso a los recursos. Aquí es donde entra en juego el aislamiento de inquilinos. Usa identificadores específicos de inquilinos para establecer límites, de manera similar a paredes, puertas y cerraduras, asegurando una separación clara entre inquilinos. ## Identidades en aplicaciones multiinquilinas Discutimos el aislamiento de inquilinos, pero ¿qué hay de las identidades? ¿Cómo decides si tus identidades deben estar “aisladas” o no? A menudo hay confusión en torno al concepto de "aislamiento de identidad". Podría referirse a situaciones donde un usuario del mundo real tiene dos identidades en el entendimiento general de las personas. 1. Ambas identidades pueden existir dentro de un único sistema de identidad. Por ejemplo, Sarah podría tener un correo electrónico personal registrado junto con un correo corporativo conectado a través de un inicio de sesión único (SSO). 2. Los usuarios mantienen dos identidades distintas dentro de sistemas de identidad separados, representando productos completamente separados. Estos productos son totalmente independientes entre sí. A veces, estos escenarios son referidos como "Identidad aislada". Sin embargo, esta etiqueta podría no ayudar en la toma de decisiones. En lugar de determinar si necesitas "aislamiento de identidad", considera si tú o un segmento de tu negocio o producto necesita mantener sistemas de identidad separados Esta respuesta puede guiar el diseño de tu sistema. Para una respuesta breve respecto a una aplicación multiinquilino, En la mayoría de los casos, en aplicaciones multiinquilinas, las identidades son compartidas mientras los recursos de cada inquilino están aislados. En aplicaciones multiinquilinas, las identidades, a diferencia de los recursos y datos específicos del inquilino, son compartidas entre múltiples inquilinos. Imagínate a ti mismo como el administrador del edificio; no querrías mantener dos listas de nombres separadas para gestionar las identidades de tus inquilinos. Cuando se busca el aislamiento de inquilinos, podrías haber observado el énfasis recurrente en el término "organización", a menudo considerado una mejor práctica para construir aplicaciones multiinquilinas. Empleando la noción de "organización", puedes lograr el aislamiento de inquilinos en tu aplicación multiinquilino al tiempo que mantienes un sistema de identidad unificado. ## Elegir los modelos de autorización para un mejor control de acceso ### Elegir y diseñar el modelo de autorización apropiado Al seleccionar el modelo de autorización adecuado, considera estas preguntas: 1. ¿Estás desarrollando un producto B2C, B2B, o una combinación de ambos tipos? 2. ¿Tu aplicación tiene una arquitectura multiinquilino? 3. ¿Existe la necesidad de un cierto nivel de aislamiento en tu aplicación, según lo determinado por la unidad de negocio? 4. ¿Qué permisos y roles necesitan definirse dentro del contexto de la organización, y cuáles no? ### Entender los diferentes modelos de autorización en Logto #### Control de acceso basado en roles RBAC (Control de Acceso Basado en Roles) es un método para otorgar permisos a los usuarios en función de sus roles, permitiendo una gestión efectiva del acceso a los recursos. Esta técnica común sustenta el control de acceso y es un componente clave de las características de autorización de Logto. Como plataforma integral de gestión de identidades, Logto ofrece soluciones personalizadas para diferentes capas y entidades, atendiendo a desarrolladores y negocios para diversas arquitecturas de productos. #### Control de acceso basado en roles para API Para proteger los recursos de API generales que no son específicos de ninguna organización y no necesitan restricciones de contexto, la característica **_API RBAC_** es ideal. Simplemente registra la API y asigna permisos a cada recurso. Luego, controla el acceso a través de la relación entre roles y usuarios. Los recursos de API, roles y permisos aquí están “democratizados” bajo un sistema de identidad unificado. Esto es bastante común en el producto B2C con menos jerarquía y no necesita un nivel de aislamiento muy profundo. #### Control de acceso basado en roles de la organización En el entorno B2B y multiinquilino, el aislamiento de inquilinos es necesario. Para lograr esto, las organizaciones se utilizan como contexto para el aislamiento, lo que significa que RBAC es efectivo solo cuando un usuario pertenece a una organización específica. El RBAC de organización se enfoca en controlar el acceso a nivel de la organización en lugar del nivel de la API. Esto proporciona una flexibilidad significativa para la autogestión a nivel de organización a largo plazo, pero aún dentro de un sistema de identidad unificado. Una característica clave del RBAC de organización es que los roles y permisos son generalmente los mismos en todas las organizaciones por defecto, lo que hace que el “template de organización” de Logto sea extremadamente significativo para mejorar la eficiencia del desarrollo. Esto se alinea con la filosofía compartida de las aplicaciones multiinquilinas, donde las políticas de control de acceso e identidades son componentes de infraestructura comunes a todos los inquilinos (inquilinos de la aplicación), una práctica común en los productos SaaS. ## Cierre Este artículo proporciona todo lo que necesitas para comenzar a preparar y configurar aplicaciones multiinquilinas. Prueba Logto hoy y comienza a aplicar las mejores prácticas para el desarrollo de aplicaciones multiinquilinas con organizaciones. Prueba Logto Cloud gratis