Automatización de zonas de aterrizaje de Azure entre varios inquilinos
Si su organización tiene varios inquilinos de Microsoft Entra con zonas de aterrizaje de Azure (ALZ) en cada uno de ellos, una o varias veces, la automatización es clave. La automatización ayuda a operar y mantener correctamente la implementación de ALZ a escala en todos los inquilinos. Hay muchos enfoques para automatizar las implementaciones de ALZ en varios inquilinos. El enfoque que tome depende de las razones por las que su organización tiene varios inquilinos de Microsoft Entra.
Por ejemplo, puede tener varios inquilinos de Microsoft Entra si es un proveedor de software independiente. Es probable que quiera mantener separados los inquilinos corporativos y de SaaS de Microsoft Entra. El riesgo de que una operación o implementación afecte al otro inquilino, ya sea intencionado o por error, se reduce.
En las secciones siguientes se proporcionan diagramas e instrucciones sobre los enfoques que puede adoptar. Elija qué enfoque es mejor para usted en función de sus requisitos, consideraciones y recomendaciones para automatizar las implementaciones de zonas de aterrizaje de Azure al controlar varios inquilinos de Microsoft Entra.
Nota
Revise primero los artículos siguientes para obtener información general sobre los inquilinos de Microsoft Entra:
Enfoques
Hay dos enfoques para automatizar la implementación de zonas de aterrizaje de Azure en varios inquilinos de Microsoft Entra.
Enfoque 1: el aislamiento completo es el enfoque más común en escenarios multiinquilino. Este enfoque mantiene la separación y el aislamiento necesarios entre los inquilinos de Microsoft Entra, que es el requisito más común al usar un enfoque multiinquilino.
Enfoque 2: Registro de aplicaciones compartido (multiinquilino) con varias entidades de servicio, se usa normalmente en escenarios de proveedor de servicios administrados (MSP). En este enfoque, se puede usar un patrón de sellos de implementación para automatizar la implementación de una arquitectura casi idéntica en varios inquilinos a gran escala.
Ambos enfoques se proporcionan como ejemplos e inspiración. Puede combinar los enfoques en las implementaciones según los requisitos de su organización.
Importante
En este artículo se describe la automatización de la implementación y el funcionamiento de las zonas de aterrizaje de Azure como plataforma en cada inquilino de Microsoft Entra que tiene su organización. Los equipos de aplicaciones que implementan y operan sus servicios y aplicaciones en sus zonas de aterrizaje (suscripciones) no están diseñados para usar los enfoques, las recomendaciones y las consideraciones de este artículo. Para más información sobre los diferentes tipos de zonas de aterrizaje, vea Diferencias entre zonas de aterrizaje de plataforma y de aplicación.
Enfoque 1: Aislamiento completo
En este enfoque, el objetivo principal es mantener cada inquilino de Microsoft Entra aislado entre sí en todos los componentes de automatización, como:
- Un repositorio de Git.
- Acciones de GitHub o Azure Pipelines (incluidos los ejecutores autohospedados, si se usan).
- Identidades que se usan para realizar tareas desde la automatización, como identidades administradas asignadas a ejecutores autohospedados, nombres de entidad de seguridad de servicio (SPN), usuarios o administradores.
En este enfoque, hay más componentes para administrar que se duplican por cada inquilino de Microsoft Entra. Algunas organizaciones pueden tener controles de cumplimiento normativo aplicados en ellos que exijan este tipo de segregación y aislamiento.
Nota
Si su organización solo permite el uso de identidades administradas para la automatización de plataformas, debe usar este enfoque o un enfoque que inicie sesión en cada inquilino individualmente. Las identidades administradas no admiten escenarios entre inquilinos en un estado de disponibilidad general actualmente. Para obtener más información, consulte estas preguntas frecuentes.
Sin embargo, ahora está disponible en versión preliminar pública para Identidades Administradas Asignadas por el Usuario mediante la configuración de una confianza entre sí mismo y una aplicación Entra ID multiinquilino. Consulte más información sobre cómo configurar esto en Configuración de una aplicación para confiar en una identidad administrada (versión preliminar). Esto puede hacer que Enfoque 2: Registro de aplicaciones compartido (multiinquilino) con múltiples entidades de servicio sea una opción viable para la implementación.
Identidades para administradores y desarrolladores de plataformas: enfoque 1
En este enfoque, las identidades también deben aislarse en cada inquilino de Microsoft Entra, lo que significa que cada administrador de plataforma o desarrollador requiere una cuenta de usuario independiente dentro de cada inquilino para realizar operaciones dentro de ese inquilino. Estas cuentas también se usan para acceder a las herramientas de desarrollador, como GitHub o Azure DevOps, para cada uno de los inquilinos. Tenga en cuenta cuidadosamente los efectos de la productividad del administrador y del desarrollador siguiendo este enfoque.
Se puede usar Microsoft Entra B2B o Azure Lighthouse, pero esta opción pregunta el razonamiento de tener inquilinos independientes de Microsoft Entra.
Enfoque 2: Registro de aplicaciones compartido (multiinquilino) con varias entidades de servicio
En este enfoque, se crea un registro de aplicación en el inquilino de administración de Microsoft Entra. En cada tenant de Microsoft Entra que quiera administrar, se crea un nombre principal de servicio (SPN) en ese tenant, basándose en el registro de la aplicación. Esta acción permite a los trabajadores que ejecutan las tareas y los pasos del flujo de trabajo iniciar sesión en cualquiera de las entidades de Microsoft Entra con un único conjunto de credenciales.
Sugerencia
Para obtener información sobre la relación entre registros de aplicación y aplicaciones empresariales (entidades de servicio), vea Objetos de aplicación y de entidad de servicio de Microsoft Entra ID.
Importante
En este enfoque, el registro de una sola aplicación y las aplicaciones empresariales asociadas (entidades de servicio) deben supervisarse para cualquier actividad anómala en las herramientas de administración de eventos e información de seguridad (SIEM), ya que se trata de una cuenta con privilegios elevados. Debe enviar alertas y, posiblemente, tomar medidas automáticamente, en función de la gravedad de la alerta.
En el ejemplo anterior, un único registro de aplicación está en la entidad contoso.onmicrosoft.com de Microsoft Entra, y una aplicación empresarial se encuentra en cada una de las entidades de Microsoft Entra que están vinculadas al registro de aplicación. Esta configuración permite que una canalización autentique y autorice a todos los inquilinos de Microsoft Entra mediante el registro de una sola aplicación. Para obtener más información, consulte Convertir su aplicación en multiinquilino y Otorgar consentimiento de administrador a una aplicación para todo el inquilino.
Sugerencia
Las Identidades Administradas Asignadas por el Usuario, en versión preliminar pública, pueden ahora admitir escenarios multiinquilino configurando una confianza entre ellas mismas y una aplicación multiinquilino Entra ID. Consulte más información sobre cómo configurar esto en Configuración de una aplicación para confiar en una identidad administrada (versión preliminar).
Al usar una canalización centralizada, es posible que tenga que crear una pequeña tabla de asignación que contenga datos que ponen en correlación los inquilinos de Microsoft Entra y otros metadatos, como el entorno, las suscripciones asociadas, el nombre de la organización y el identificador de objeto de identidad que se usan para la autenticación y autorización. Se puede llamar a estos datos durante la ejecución de la canalización en un paso que usa cierta lógica y condiciones para controlar en qué inquilino de Microsoft Entra se implementa y con qué identidades. Los datos se pueden almacenar en servicios, como Azure Cosmos DB o Azure Table Storage.
Al gestionar múltiples entornos, como desarrollo, prueba o producción, estos se pueden administrar de manera similar utilizando los mismos registros de aplicaciones o aplicaciones empresariales independientes con canalizaciones.
Puede decidir tener canalizaciones independientes para cada inquilino de Microsoft Entra o usar una sola canalización. La elección es la suya en función de sus requisitos.
Nota
Azure Lighthouse funciona de forma similar a este enfoque, pero Azure Lighthouse no permite la asignación del propietario del rol RBAC, del administrador de acceso de usuario ni de los roles que tienen permisos para acciones de datos. Para más información, consulte Compatibilidad de roles con Azure Lighthouse.
Los roles de acceso de usuario y propietario suelen ser necesarios en todos los escenarios de implementación de la zona de aterrizaje de Azure. Este requisito quita Azure Lighthouse como opción para todo el aspecto de implementación de la automatización de la plataforma de las zonas de aterrizaje de Azure, pero sigue siendo útil en algunos escenarios. Para más información, consulte Uso de Azure Lighthouse en ALZ multiinquilino.
Identidades para administradores y desarrolladores de plataformas: enfoque 2
En este enfoque, los administradores de plataformas y los desarrolladores normalmente solo necesitan acceso al entorno de gestión de Microsoft Entra. Este acceso les concede acceso a las herramientas para desarrolladores, como GitHub o Azure DevOps, desde donde se implementan y operan todos los inquilinos.
Es posible que tengan acceso a los otros inquilinos de Microsoft Entra a través de Microsoft Entra B2B o Azure Lighthouse. Usan la misma cuenta del arrendatario administrador o pueden tener cuentas independientes, como el ejemplo de la primera aproximación.