Compartir a través de


Automatización de zonas de aterrizaje de Azure entre varios inquilinos

Si la organización tiene varios inquilinos de Microsoft Entra con zonas de aterrizaje de Azure (ALZ) en cada uno, una o varias veces, la automatización es clave. La automatización ayuda a operar y mantener correctamente la implementación de ALZ a gran escala en todos los inquilinos. Hay muchos enfoques para automatizar las implementaciones de ALZ en varios inquilinos. El enfoque que tome dependerá 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. Se reduce el riesgo de que una operación o implementación afecte al otro inquilino, ya sea de manera intencionada o por error.

En las secciones siguientes se proporcionan diagramas e instrucciones sobre los enfoques que puede adoptar. Elija el enfoque más adecuado en función de los requisitos, consideraciones y recomendaciones para automatizar las implementaciones de las zonas de aterrizaje de Azure al controlar varios 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: 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.

Los dos enfoques se proporcionan como ejemplos e inspiración. Puede mezclar los enfoques de las implementaciones en función de los requisitos de la 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 tenga la 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 los siguientes:

  • 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.

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the complete isolation automation approach.

En este enfoque, hay más componentes para administrar que se duplican por cada inquilino de Microsoft Entra. Es posible que algunas organizaciones tengan controles de cumplimiento normativo aplicados que exigen este tipo de segregación y aislamiento.

Nota

Si en la organización solo se permite el uso de identidades administradas para la automatización de la plataforma, debe usar este enfoque, o bien uno que inicie sesión en cada inquilino individualmente. Las identidades administradas no admiten escenarios entre inquilinos. Para obtener más información, consulte las Preguntas más frecuentes.

Identidades para administradores y desarrolladores de plataformas: Enfoque 1

En este enfoque, las identidades también se deben aislar en cada inquilino de Microsoft Entra, lo que significa que cada administrador de plataforma o desarrollador necesita 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 herramientas para desarrolladores, como GitHub o Azure DevOps, para cada uno de los inquilinos. Tenga en cuenta con atención los efectos de la productividad del administrador y del desarrollador al seguir este enfoque.

Se puede usar Microsoft Entra B2B o Azure Lighthouse, pero esta opción cuestiona el razonamiento de tener inquilinos de Microsoft Entra independientes.

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 inquilino de Microsoft Entra que quiera administrar, se crea un nombre de entidad de seguridad de servicio (SPN), en función del registro de aplicación. Esta acción permite a los trabajos que ejecutan las tareas de canalización y los pasos iniciar sesión en cualquiera de los inquilinos 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.

Diagram of multiple Microsoft Entra tenants with Azure landing zones deployed using the shared application registration (multi-tenant) with multiple service principals automation approach.

Importante

En este enfoque, el registro de una sola aplicación y las aplicaciones empresariales asociadas (entidades de servicio) se deben supervisar en busca de 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, potencialmente, tomar medidas de manera automática, en función de la gravedad de la alerta.

En el ejemplo anterior, hay un registro de aplicación único en el inquilino contoso.onmicrosoft.com de Microsoft Entra y una aplicación empresarial en cada uno de los inquilinos de Microsoft Entra que están vinculados al registro de la aplicación. Esta configuración permite que una canalización se autentique y autorice a todos los inquilinos de Microsoft Entra mediante el registro de una sola aplicación. Para más información, vea Creación de la aplicación multiinquilino.

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 controlar varios entornos, como los de desarrollo, prueba o producción, se pueden controlar de la misma manera mediante el uso de los mismos registros de aplicación o aplicaciones empresariales con canalizaciones, o bien otros independientes.

Puede optar por tener canalizaciones independientes para cada inquilino de Microsoft Entra o usar una única canalización. Debe elegir en función de los requisitos.

Nota

Azure Lighthouse funciona de forma similar a este enfoque, pero no permite la asignación del propietario de RBAC, el administrador de acceso de usuarios y los roles con permisos DataActions. 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 zonas de aterrizaje de Azure. Este requisito descarta a Azure Lighthouse como opción para todo el aspecto de implementación de la automatización de plataforma de las zonas de aterrizaje de Azure, pero sigue siendo útil en algunos escenarios. Para más información, vea 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 inquilino de administració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 mediante Microsoft Entra B2B o Azure Lighthouse. Usan su misma cuenta del inquilino de administración, o bien pueden tener cuentas independientes, como en el ejemplo del primer enfoque.

Pasos siguientes