Federación de identidad y arquitecturas multi-tenant
Grupos empresariales, holdings y organizaciones multiempresa: cómo diseñar la identidad cuando no hay una única compañía ni un único tenant.
El problema
Las organizaciones con estructura compleja —un holding con varias sociedades, un grupo formado por adquisiciones sucesivas, una matriz con filiales que operan con marcas distintas— rara vez tienen una arquitectura de identidad diseñada. Tienen la que ha resultado de su historia.
Lo habitual es encontrar varios tenants de Microsoft 365 creados en momentos distintos, con políticas de seguridad diferentes, con niveles de licencia dispares y sin ninguna relación entre ellos. Los usuarios de una sociedad no ven el calendario de los de otra, la documentación compartida acaba en enlaces públicos y cada tenant tiene su propio conjunto de administradores.
La pregunta que llega entonces es si conviene unificarlo todo en un tenant o mantener varios federados. No hay una respuesta única: depende de la autonomía real de cada sociedad, de los requisitos de separación de información y de cómo trabajan las personas entre ellas.
Sobre el límite de 300 puestos de los planes Business
Conviene decirlo con claridad: los planes Microsoft 365 Business están limitados por las condiciones de licenciamiento de Microsoft a un máximo de 300 puestos por organización, según la política vigente en cada momento.
Una arquitectura multi-tenant no es —ni debe plantearse como— una vía para superar ese límite repartiendo usuarios entre varios tenants. Ese uso contravendría las condiciones de licencia y expone a la organización a un incumplimiento contractual con Microsoft.
Cuando una organización supera los 300 usuarios, la respuesta correcta es el licenciamiento Microsoft 365 Enterprise, que además aporta capacidades de seguridad, cumplimiento y gestión que los planes Business no incluyen y que a ese tamaño suelen ser necesarias.
Las arquitecturas multi-tenant se justifican por razones de estructura societaria, autonomía operativa, separación de información o procesos de integración en curso. Nunca por licenciamiento.
Qué hace IT Encore
Diseñamos la arquitectura de identidad de organizaciones con estructura compleja: cuántos tenants tiene sentido mantener, cómo se relacionan entre sí, cómo se autentican los usuarios y qué información se comparte entre unidades.
En unos casos la recomendación es consolidar en un único tenant, porque la separación no aportaba nada y multiplicaba el coste administrativo. En otros es mantener tenants separados con colaboración configurada entre ellos, porque las sociedades son realmente autónomas o existen requisitos de separación que hay que respetar.
Sea cual sea la decisión, el trabajo posterior es el mismo: identidad unificada allí donde se pueda, inicio de sesión único, políticas de seguridad homogéneas y una administración que no dependa de que cada filial haga lo suyo.
Qué incluye el servicio
- Microsoft Entra ID. Diseño del directorio: dominios, usuarios, grupos, unidades administrativas y roles.
- Identidad. Modelo de identidad en la nube, híbrida o mixta, según los directorios locales existentes.
- Federación. Relaciones de confianza entre directorios y con proveedores de identidad de terceros.
- SSO. Inicio de sesión único para las aplicaciones corporativas, incluidas las que no son de Microsoft.
- Sincronización. Sincronización de directorios locales, con reglas de filtrado y control de atributos.
- Coexistencia. Encaminamiento de correo, disponibilidad de calendarios y directorio compartido entre tenants.
- Colaboración entre tenants. Acceso de invitados, compartición controlada y sincronización de directorios entre organizaciones.
- Consolidación. Unificación de tenants cuando la separación no aporta valor. Ver tenant to tenant.
- Licenciamiento adecuado. Análisis del plan que corresponde a cada perfil de usuario y a cada sociedad, sin infralicenciar.
- Seguridad homogénea. MFA, acceso condicional y política de privilegios aplicados de forma coherente en todo el grupo.
Un tenant o varios
Los criterios que aplicamos al recomendar una u otra arquitectura.
| Situación | Recomendación habitual | Motivo |
|---|---|---|
| Sociedades del mismo grupo que trabajan juntas a diario | Tenant único | La colaboración interna es mucho más sencilla y el coste administrativo mucho menor. |
| Filiales con autonomía real y equipos de TI propios | Tenants separados con colaboración | Respeta la autonomía sin renunciar a poder trabajar entre organizaciones. |
| Requisito de separación estricta de la información | Tenants separados | La separación entre tenants es la frontera más clara que ofrece la plataforma. |
| Adquisición reciente en fase de integración | Coexistencia y consolidación posterior | Permite integrar por fases sin bloquear la operación del negocio. |
| Sociedad que va a venderse o escindirse | Tenant separado | Facilita la separación futura sin tener que desenredar información compartida. |
Preguntas frecuentes
¿Se pueden repartir usuarios entre tenants para no pasar de 300 en un plan Business?
No. Sería contrario a las condiciones de licenciamiento de Microsoft y no lo planteamos como solución. Al superar ese umbral, lo correcto es pasar a licenciamiento Enterprise, que además aporta las capacidades de seguridad y cumplimiento que una organización de ese tamaño necesita.
¿Los usuarios de tenants distintos pueden usar Teams entre ellos?
Sí, mediante acceso externo y acceso de invitados, que permiten chat, reuniones y participación en equipos entre organizaciones. La experiencia no es idéntica a la de un tenant único, y esa diferencia hay que valorarla al decidir la arquitectura.
¿Hace falta un directorio local para federar?
No necesariamente. Muchas arquitecturas funcionan exclusivamente con identidad en la nube. El directorio local se mantiene cuando hay aplicaciones o servicios que dependen de él, y en ese caso se sincroniza con Entra ID.
¿Se puede consolidar más adelante?
Sí. De hecho es un camino frecuente: mantener tenants separados durante la integración de una adquisición y consolidar cuando la organización ya funciona como una sola. Conviene diseñarlo desde el principio pensando en esa posibilidad.
Servicios relacionados
Migración tenant to tenant
Fusiones, adquisiciones, escisiones y consolidación de tenants de Microsoft 365.
Ver servicioGestión y soporte de Microsoft 365
Administración diaria de Exchange Online, Teams, SharePoint, OneDrive, Entra ID y licenciamiento.
Ver servicioSeguridad de Microsoft 365
MFA, Entra ID, acceso condicional, privilegios, protección de correo y auditoría del tenant.
Ver servicioRevise su arquitectura de identidad
Un análisis de los tenants existentes, su licenciamiento y la arquitectura que conviene.