Diseño de una arquitectura multiinquilino para grandes instituciones

Se recomienda una arquitectura de inquilino único para instituciones más pequeñas. Sin embargo, para las organizaciones que tienen más de un millón de usuarios, se recomienda una arquitectura multiinquilino para mitigar los problemas de rendimiento y las limitaciones de inquilino, como las cuotas y suscripciones de Azure, y Microsoft Entra límites y restricciones del servicio.

Principios de diseño

Al diseñar la arquitectura multiinquilino, tenga en cuenta los siguientes principios de diseño para reducir los costos y aumentar la eficacia y la seguridad:

• Reducción de costos

  • Reduzca la dependencia de la infraestructura local y de varios proveedores de identidades.

  • Permitir que los usuarios desbloqueen su cuenta o restablezcan contraseñas mediante autoservicio (por ejemplo, Microsoft Entra autoservicio de restablecimiento de contraseña).

• Aumento de la eficacia

  • Estandarizar la arquitectura, las configuraciones y los procesos entre inquilinos para minimizar los problemas administrativos.

  • Minimizar la necesidad de que los usuarios pasen de un inquilino a otro

• Aumento de la seguridad

  • Céntrese en garantizar que los datos de los alumnos sean seguros.

  • Siga el principio de privilegios mínimos: conceda solo los privilegios necesarios para realizar las tareas necesarias e implemente el acceso Just-In-Time (JIT).

  • Habilite el acceso de usuarios externos solo a través de la administración de derechos o Microsoft Entra colaboración B2B.

  • Delega la administración de tareas específicas a usuarios específicos con Just Enough Access (JEA) para realizar el trabajo.

Motivos comunes para varios inquilinos

Se recomienda encarecidamente que las organizaciones con menos de un millón de usuarios creen un único inquilino a menos que otros criterios indiquen la necesidad de varios inquilinos. Para las organizaciones con un millón o más de objetos de usuario, se recomiendan varios inquilinos mediante un enfoque regional.

La creación de inquilinos independientes tiene los siguientes efectos en el entorno EDU.

• Separación administrativa

  • Puede limitar los impactos de un error operativo o de seguridad administrativa que afecte a los recursos críticos.

  • Puede limitar el impacto de las cuentas de administrador o usuario en peligro.

  • Los informes de uso y los registros de auditoría se encuentran dentro de un inquilino.

• Separación de recursos

  • Privacidad de los estudiantes. Los objetos de usuario student solo se pueden detectar dentro del inquilino en el que reside el objeto.

  • Aislamiento de recursos. Los usuarios y administradores de otros inquilinos no pueden detectar ni enumerar los recursos de un inquilino independiente.

  • Superficie de objeto. Las aplicaciones que escriben en Microsoft Entra ID y otros servicios de Microsoft Online a través de Microsoft Graph u otras interfaces de administración solo pueden afectar a los recursos del inquilino local.

  • Cuotas. El consumo de cuotas y límites de Azure para todo el inquilino está separado del de los demás inquilinos.

• Separación de configuración

  • Proporciona un conjunto independiente de opciones de configuración de todo el inquilino que pueden dar cabida a recursos y aplicaciones de confianza que tienen requisitos de configuración diferentes.

  • Habilita un nuevo conjunto de servicios de Microsoft Online, como Office 365.

Además de tener más de un millón de usuarios, las siguientes consideraciones pueden dar lugar a varios inquilinos.

• Consideraciones administrativas

  • Usted opera bajo regulaciones que restringen quién puede administrar el medio ambiente en función de criterios como el país de ciudadanía, el país de residencia o el nivel de autorización.

  • Tiene requisitos de cumplimiento, como la privacidad de los datos de los alumnos, que requieren la creación de identidades en regiones locales específicas.

• Consideraciones sobre los recursos

  • Tiene recursos, quizás para investigación y desarrollo, que debe proteger de la detección, enumeración o adquisición por parte de los administradores existentes por motivos normativos o críticos para la empresa.

  • Ciclo de desarrollo de aplicaciones personalizadas que pueden cambiar los datos de los usuarios con MS Graph o API similares a escala (por ejemplo, las aplicaciones a las que se concede Directory.ReadWrite.All)

• Consideraciones de configuración

  • Recursos que tienen requisitos que entran en conflicto con las posturas de seguridad o colaboración existentes en todo el inquilino, como los tipos de autenticación permitidos, las directivas de administración de dispositivos, la capacidad de autoservicio o la corrección de identidades para identidades externas.

Determinación del enfoque multiinquilino

En esta sección consideramos una universidad ficticia llamada Escuela de Bellas Artes con 2 millones de estudiantes en 100 escuelas a lo largo de la Estados Unidos. En todas estas escuelas, hay un total de 130 000 profesores y 30 000 empleados y personal a tiempo completo.

Se recomienda un enfoque regional al implementar varios inquilinos como se indica a continuación:

1. Comience dividiendo la comunidad de estudiantes y educadores por regiones geográficas donde cada región contiene menos de un millón de usuarios.

2. Cree un inquilino de Microsoft Entra para cada región.

   

3. Aprovisionar personal, profesores y alumnos en su región correspondiente para optimizar las experiencias de colaboración.

   

¿Por qué usar regiones?

Se recomienda un enfoque regional para minimizar el número de usuarios que se mueven entre inquilinos. Si ha creado un inquilino para cada nivel escolar (por ejemplo, escuelas primarias, secundarias y secundarias), tendría que migrar usuarios al final de cada año escolar. Si en su lugar los usuarios permanecen en la misma región, no es necesario moverlos entre inquilinos a medida que cambian sus atributos.

Otras ventajas de un enfoque regional incluyen:

• Colaboración óptima dentro de cada región

• Se necesita un número mínimo de objetos invitados de otros inquilinos

Cuando un inquilino tiene más de un millón de usuarios, las experiencias de administración y las herramientas tienden a degradarse con el tiempo. Del mismo modo, algunas experiencias del usuario final, como el uso del selector de personas, se volverán complicadas y poco confiables.

Las organizaciones más pequeñas que deciden implementar varios inquilinos sin una razón atractiva aumentarán innecesariamente su sobrecarga de administración y el número de migraciones de usuarios. Para ello, también se requerirán pasos para garantizar las experiencias de colaboración entre inquilinos.

Colaboración entre inquilinos mediante Microsoft Entra colaboración B2B

Microsoft Entra colaboración B2B permite a los usuarios usar un conjunto de credenciales para iniciar sesión en varios inquilinos. En el caso de las instituciones educativas, los beneficios de la colaboración B2B incluyen:

• Equipo de administración centralizada que administra varios inquilinos

• Colaboración de profesores entre regiones

• Incorporación de padres y tutores con sus propias credenciales

• Asociaciones externas como contratistas o investigadores

Con la colaboración B2B, se invita a una cuenta de usuario creada en un inquilino (su inquilino principal) como usuario invitado a otro inquilino (un inquilino de recursos) y el usuario puede iniciar sesión con las credenciales de su inquilino principal. Los administradores también pueden usar la colaboración B2B para permitir que los usuarios externos inicien sesión con sus cuentas sociales o empresariales existentes mediante la configuración de la federación con proveedores de identidades como Facebook, cuentas de Microsoft, Google o un proveedor de identidades empresariales.

Miembros e invitados

Los usuarios de un inquilino de Microsoft Entra son miembros o invitados en función de su propiedad UserType. De forma predeterminada, los usuarios miembros son los que son nativos del inquilino. De forma predeterminada, se agrega un usuario de colaboración B2B Microsoft Entra como usuario con UserType = Guest. Los invitados tienen permisos limitados en el directorio y las aplicaciones. Por ejemplo, los usuarios invitados no pueden examinar información del inquilino más allá de su propia información de perfil. Sin embargo, un usuario invitado puede recuperar información sobre otro usuario proporcionando el nombre principal de usuario (UPN) o objectId. Un usuario invitado también puede leer las propiedades de los grupos a los que pertenecen, incluida la pertenencia a grupos, independientemente de que los permisos de los usuarios invitados sean de configuración limitada .

En algunos casos, es posible que un inquilino de recursos quiera tratar a los usuarios del inquilino principal como miembros en lugar de invitados. Si es así, puede usar Microsoft Entra API del Administrador de invitaciones B2B para agregar o invitar a un usuario del inquilino principal al inquilino del recurso como miembro. Para obtener más información, vea Propiedades de un usuario de colaboración B2B de Microsoft Entra.

Administración centralizada de varios inquilinos

Incorporación de identidades externas mediante Microsoft Entra B2B. A continuación, se pueden asignar roles con privilegios a las identidades externas para administrar Microsoft Entra inquilinos como miembros de un equipo de TI centralizado. También puede usar Microsoft Entra B2B para crear cuentas de invitado para otros miembros del personal, como administradores en el nivel regional o de distrito.

Sin embargo, los roles específicos del servicio, como administrador de Exchange o administrador de SharePoint, requieren una cuenta local que sea nativa de su inquilino. ​

Los siguientes roles se pueden asignar a cuentas B2B.

• Administrador de la aplicación

• Desarrollador de la aplicación

• Administrador de autenticación

• Administrador del conjunto de claves de IEF de B2C

• Administrador de directivas de IEF B2C

• Administrador de directivas de IEF de la aplicación en la nube B2C

• Administrador de directivas de IEF de dispositivo en la nube B2C

• Administrador de acceso condicional

• Administradores de dispositivos

• Unión a dispositivos

• Usuarios del dispositivo

• Lectores de directorio

• Escritores de directorios

• Cuentas de sincronización de directorios

• Administrador de flujo de usuario de id. externo

• Administrador de atributos de flujo de usuario de id. externo

• Proveedor de identidades externo

• Administrador de grupos

• Invitador

• Administrador del servicio de asistencia

• Administrador de identidades híbridas

• Administrador del servicio de Intune

• Administrador de licencias

• Administrador de contraseñas

• Administrador de autenticación con privilegios

• Administrador de roles con privilegios

• Lector de informes

• Usuario invitado restringido

• Administrador de seguridad

• Lector de seguridad

• Administrador de cuentas de usuario

• Unión a dispositivos de Workplace

Los roles de administrador personalizados en Microsoft Entra ID exponen los permisos subyacentes de los roles integrados, de modo que pueda crear y organizar sus propios roles personalizados. Este enfoque permite conceder acceso de forma más granular que los roles integrados, siempre que se necesiten.

Este es un ejemplo que ilustra cómo funcionaría la administración para los roles administrativos que se pueden delegar y usar en varios inquilinos.

La cuenta nativa de Susie se encuentra en el inquilino de la región 1 y Microsoft Entra B2B se usa para agregar la cuenta como administrador de autenticación al equipo de TI central en los inquilinos de la región 2 y la región 3.

Uso de aplicaciones entre varios inquilinos

Para mitigar los problemas asociados con la administración de aplicaciones en un entorno multiinquilino, debe considerar la posibilidad de escribir aplicaciones multiinquilino. También deberá comprobar cuál de las aplicaciones SaaS admite varias conexiones IdP. Las aplicaciones SaaS que admiten varias conexiones IDP deben configurar conexiones individuales en cada inquilino. Las aplicaciones SaaS que no admiten varias conexiones IDP pueden requerir instancias independientes. Para obtener más información, vea How to: Sign in any Microsoft Entra user using the multi-tenant application pattern (Cómo: Iniciar sesión en cualquier usuario Microsoft Entra mediante el patrón de aplicación multiinquilino).

Nota: Los modelos de licencia pueden variar de una aplicación SaaS a otra. consulte con el proveedor para determinar si se necesitarán varias suscripciones en un entorno multiinquilino.

Administración por inquilino

La administración por inquilino es necesaria para los roles específicos del servicio. Los roles específicos del servicio requieren tener una cuenta local que sea nativa del inquilino. además de tener un equipo de TI centralizado en cada inquilino, también tendrá que tener un equipo de TI regional en cada inquilino para administrar cargas de trabajo como Exchange, SharePoint y Teams.

Los roles siguientes requieren cuentas nativas para cada inquilino.

• Administrador de Azure DevOps

• Administrador de Azure Information Protection

• Administrador de facturación

• Administrador del servicio CRM

• Administrador de cumplimiento

• Administrador de datos de cumplimiento

• Aprobador de acceso a caja de seguridad del cliente

• Administrador de Análisis de escritorio

• Administrador de Exchange

• Administrador de Insights

• Líder empresarial de Insights

• Administrador de Kaizala

• Administrador de servicios de Lync

• Lector de privacidad del Centro de mensajes

• Lector del Centro de mensajes

• Administrador de impresoras

• Técnico de impresora

• Administrador de búsqueda

• Buscar Editor

• Operador de seguridad

• Administrador de soporte técnico de servicio

• Administrador de SharePoint

• Administrador de comunicaciones de Teams

• Ingeniero de soporte en comunicaciones de Teams

• Especialista de soporte en comunicaciones de Teams

• Administrador de servicios de Teams

Administradores únicos en cada inquilino

Si tiene un equipo de TI nativo de cada región, podría tener uno de esos administradores locales que administre la administración de Teams. En el ejemplo siguiente, Charles reside en el inquilino de la región 1 y tiene el rol de administrador de servicios de Teams. Alice e Ichiro residen en las regiones 2 y 3 respectivamente, y tienen el mismo rol en sus regiones. Cada administrador local tiene una sola cuenta nativa de su región.

Administración roles entre inquilinos

Si no tiene un grupo de administradores locales en cada región, puede asignar el rol Administrador de servicios de Teams a un solo usuario. En este escenario, como se muestra a continuación, puede hacer que Bob del equipo de TI central actúe como administrador de servicios de Teams en los tres inquilinos mediante la creación de una cuenta local para Bob en cada inquilino.

Delegación de roles de administrador dentro de un inquilino

Las unidades administrativas (AU) deben usarse para agrupar lógicamente Microsoft Entra usuarios y grupos. Restringir el ámbito administrativo mediante unidades administrativas es útil en organizaciones educativas formadas por diferentes regiones, distritos o escuelas.

Por ejemplo, nuestra escuela ficticia de Bellas Artes está distribuida en tres regiones, cada una de las cuales contiene varias escuelas. Cada región tiene un equipo de administradores de TI que controlan el acceso, administran usuarios y establecen directivas para sus respectivas escuelas.

Por ejemplo, un administrador de TI podría:

• Cree una AU para los usuarios de cada una de las escuelas de la Región 1, para administrar todos los usuarios de esa escuela. (no en la imagen)

• Cree una AU que contenga a los profesores de cada escuela, para administrar las cuentas de los profesores.

• Cree una AU independiente que contenga a los alumnos de cada escuela, para administrar las cuentas de los alumnos.

• Asigne a los profesores de la escuela el rol Administrador de contraseñas para la AU Students, para que los profesores puedan restablecer las contraseñas de los alumnos, pero no restablecer las contraseñas de otros usuarios.

Los roles que se pueden limitar a unidades administrativas incluyen:

• Administrador de autenticación

• Administrador de grupos

• Administrador del servicio de asistencia

• Administrador de licencias

• Administrador de contraseñas

• Administrador de usuarios

Para obtener más información, consulte Asignación de roles con ámbito a una unidad administrativa.

Administración entre inquilinos

La configuración se configura en cada inquilino individualmente. Configure entonces como parte de la creación de inquilinos siempre que sea posible para ayudar a minimizar la necesidad de volver a consultar esa configuración. Aunque algunas tareas comunes se pueden automatizar, no hay ningún portal de administración entre inquilinos integrado.

Administración de objetos a escala

Microsoft Graph (MS Graph) y Microsoft Graph PowerShell le permiten administrar objetos de directorio a escala. También se pueden usar para administrar la mayoría de las directivas y configuraciones del inquilino. Sin embargo, debe comprender las siguientes consideraciones de rendimiento:

• MS Graph limita la creación de usuarios, grupos y cambios de pertenencia a 72 000 por inquilino y hora.

• El rendimiento de MS Graph puede verse afectado por acciones controladas por el usuario, como acciones de lectura o escritura dentro del inquilino.

• El rendimiento de MS Graph puede verse afectado por otras tareas de administración de TI en competencia dentro del inquilino.

• PowerShell, SDS, Microsoft Entra Connect y soluciones de aprovisionamiento personalizadas agregan objetos y pertenencias a través de MS Graph a diferentes velocidades

Pasos siguientes

Si no ha revisado Introducción a Microsoft Entra inquilinos, es posible que desee hacerlo. A continuación, consulte:

• Diseño de una estrategia de configuración de inquilinos
• Diseño de una estrategia de cuenta