Enfoque para las pruebas de zonas de aterrizaje de Azure
Nota:
Este artículo solo se aplica a Microsoft Azure y no a ninguna otra oferta de Microsoft Cloud, como Microsoft 365 o Microsoft Dynamics 365.
Es posible que algunas organizaciones quieran probar su implementación de la plataforma de zonas de aterrizaje de Azure en relación con las definiciones y asignaciones de Azure Policy, las asignaciones y los roles personalizados del control de acceso basado en rol (RBAC), etcétera. Las pruebas se pueden completar mediante la automatización empleando plantillas de Azure Resource Manager (plantillas de ARM), AzOps, Terraform, Bicep o manualmente mediante Azure Portal. Esta guía proporciona un enfoque que se puede usar para probar los cambios y su impacto en una implementación de la plataforma de zonas de aterrizaje de Azure.
Este artículo también se puede usar con la guía de automatización de la plataforma y el área de diseño crítica de DevOps en relación con los equipos y tareas de funciones centrales y PlatformOps.
Esta guía es más adecuada para las organizaciones con procesos sólidos de administración de cambios que rigen los cambios en la jerarquía de grupos de administración del entorno de producción. La jerarquía de grupos de administración de valor controlado se puede usar de forma independiente para crear y probar implementaciones antes de implementarlas en el entorno de producción.
Nota:
El término valor controlado se usa para evitar confusiones con entornos de desarrollo o entornos de prueba. Este nombre solo se utiliza para ilustración. Puede definir cualquier nombre que considere adecuado para el entorno de zonas de aterrizaje de Azure de valor controlado.
De forma similar, el término entorno de producción se usa en esta guía para hacer referencia a la jerarquía de grupos de administración que la organización podría tener en funcionamiento y que contiene las suscripciones y los recursos de Azure para las cargas de trabajo.
Definición de plataforma
Importante
Esta guía no es para entornos de desarrollo ni entornos de prueba que los propietarios de aplicaciones o servicios usarán, conocidos como zonas de aterrizaje, cargas de trabajo, aplicaciones o servicios. Se colocan y controlan dentro de la jerarquía de grupos de administración del entorno de producción y la gobernanza asociada (RBAC y Azure Policy ).
Esta guía es solo para pruebas de nivel de plataforma y cambios en el contexto de las zonas de aterrizaje de Azure.
La escala empresarial le ayuda a diseñar e implementar los componentes necesarios de la plataforma de Azure para permitirle construir y operacionalizar zonas de aterrizaje a escala.
Los recursos de la plataforma en el ámbito de este artículo y este enfoque de prueba son:
| Producto o servicio | Proveedor de recursos y tipo |
|---|---|
| Grupos de administración | Microsoft.Management/managementGroups |
| Asociación de suscripciones de grupos de administración | Microsoft.Management/managementGroups/subscriptions |
| Definiciones de directiva | Microsoft.Authorization/policyDefinitions |
| Definiciones de iniciativas de directiva o definiciones de conjuntos de directivas | Microsoft.Authorization/policySetDefinitions |
| Asignaciones de directivas | Microsoft.Authorization/policyAssignments |
| Definiciones de roles RBAC | Microsoft.Authorization/roleDefinitions |
| Asignaciones de roles RBAC | Microsoft.Authorization/roleAssignments |
| Suscripciones | Microsoft.Subscription/aliases |
Escenarios y resultados de ejemplo
Un ejemplo de este escenario es una organización que quiere probar el impacto y el resultado de una nueva instancia de Azure Policy para regular los recursos y la configuración en todas las zonas de aterrizaje, según el principio de diseño de gobernanza controlada por directivas. No quiere realizar este cambio directamente en el entorno de producción, ya que le preocupa el impacto que podría tener.
El uso del entorno de valor controlado para probar este cambio de plataforma permitirá a la organización implementar y revisar el impacto y el resultado del cambio de Azure Policy . Este proceso garantizará que satisface los requisitos de la organización antes de implementar la instancia de Azure Policy en su entorno de producción.
Un escenario similar podría ser un cambio en las asignaciones de roles RBAC de Azure y las pertenencias a grupos de Microsoft Entra. Puede requerir una forma de prueba antes de que se realicen los cambios en el entorno de producción.
Importante
Este no es un patrón o enfoque de implementación común para la mayoría de los clientes. No es obligatorio para las implementaciones de zonas de aterrizaje de Azure.
Figura 1: Jerarquía de grupos de administración de valor controlado.
Como se muestra en el diagrama, toda la jerarquía de grupos de administración del entorno de producción de zonas de aterrizaje de Azure está duplicada en Tenant Root Group. El término canary se anexa a los nombres para mostrar y los id. de los grupos de administración. Los id. deben ser únicos dentro de un solo inquilino de Microsoft Entra.
Nota:
Los nombres para mostrar de los grupos de administración de entorno de valor controlado pueden ser los mismos que los nombres para mostrar de los grupos de administración del entorno de producción. Esto puede provocar confusión para los usuarios. Debido a esto, se recomienda anexar el nombre "canary" a los nombres para mostrar, así como a sus identificadores.
A continuación, se usa la jerarquía de grupos de administración de entornos de valor controlado para simplificar las pruebas de los siguientes tipos de recursos:
- Grupos de administración
- Ubicación de la suscripción
- RBAC
- Roles (integrados y personalizados)
- Assignments
- Azure Policy
- Definiciones (integradas y personalizadas)
- Iniciativas, también conocidas como definiciones de conjunto
- Assignments
¿Qué ocurre si no quiere implementar toda la jerarquía de grupos de administración de entorno de valor controlado?
Si no quiere implementar toda la jerarquía de grupos de administración de entorno de valor controlado, puede probar los recursos de la plataforma dentro de la jerarquía de entornos de producción mediante suscripciones de espacio aislado, como se muestra en el diagrama.
Figure 2: Jerarquía de grupos de administración de escala empresarial con espacios aislados realzados.
Para probar Azure Policy y RBAC en este escenario, necesita una sola suscripción de Azure con el rol RBAC Propietario asignado a la identidad que quiere completar las pruebas como, por ejemplo, la cuenta de usuario, la entidad de servicio o la identidad de servicio administrada. Esta configuración le permitirá crear, asignar y corregir las definiciones y asignaciones de Azure Policy dentro del ámbito de la suscripción de espacio aislado únicamente.
Este enfoque de espacio aislado también se puede usar para las pruebas de RBAC dentro de la suscripción, por ejemplo, si está desarrollando un nuevo rol de RBAC personalizado para conceder permisos para un caso de uso determinado. Todas estas pruebas se pueden realizar en la suscripción de espacio aislado y probarse antes de crear y asignar roles superiores en la jerarquía.
Una ventaja de este enfoque es que las suscripciones de espacio aislado se pueden usar durante el tiempo necesario y, a continuación, eliminarse del entorno.
Sin embargo, este enfoque no le permite probar con la herencia de RBAC y las directivas de Azure de la jerarquía de grupos de administración.
Uso de un único inquilino de Microsoft Entra
Las consideraciones que se deben tener en cuenta al usar un único inquilino de Microsoft Entra son:
- Sigue las Recomendaciones de diseño de escala empresarial para inquilinos de Microsoft Entra.
- Según la guía Procedimientos recomendados de Cloud Adoption Framework de Azure: estandarización en un único directorio e identidad, los inquilinos de Microsoft Entra únicos son el procedimiento recomendado para la mayoría.
- En un único inquilino de Microsoft Entra, es posible usar los distintos grupos de Microsoft Entra para entornos de producción y entornos de zonas de aterrizaje de Azure de valor controlado, con los mismos usuarios, asignados a su jerarquía de grupos de administración pertinente dentro del mismo inquilino de Microsoft Entra.
- Aumentan o se duplican los costes de licencias de Microsoft Entra debido a varias identidades en diferentes inquilinos de Microsoft Entra.
- Este punto es especialmente relevante para los clientes que usen características de Microsoft Entra ID P1 o P2.
- Los cambios de RBAC serán más complejos tanto en entornos de valor controlado como en entornos de producción, ya que es probable que los usuarios y los grupos no sean idénticos en ambos inquilinos de Microsoft Entra.
- Además, los id. de usuarios y grupos no serán los mismos en los inquilinos de Microsoft Entra porque son únicos globalmente.
- Reduce la complejidad y la sobrecarga de administración causadas por la administración de varios inquilinos de Microsoft Entra.
- Los usuarios con privilegios que deben mantener el acceso e iniciar sesión en inquilinos independientes para realizar pruebas pueden realizar cambios en el entorno de producción accidentalmente, en lugar de realizar cambios en el entorno de valor controlado y viceversa.
- Reduce la probabilidad de errores de implementación y de desviación de la configuración.
- No requiere seguridad adicional ni la creación de procesos de acceso de emergencia o break-glass.
- Reduce la fricción y el tiempo necesario para implementar cambios en la implementación de zonas de aterrizaje de Azure.
Guía de implementación
A continuación, se proporcionan instrucciones sobre cómo implementar y usar la jerarquía de grupos de administración de valor controlado para zonas de aterrizaje de Azure junto con una jerarquía de grupos de administración de entornos de producción.
Advertencia
Si actualmente usa el portal para implementar y administrar el entorno de zonas de aterrizaje de Azure, puede ser difícil adoptar y usar el enfoque de valor controlado de forma eficaz debido a un alto riesgo de que los entornos de producción y de valor controlado se desincronicen con frecuencia y, por tanto, no proporcionen una jerarquía y un entorno de producción similares a las réplicas.
Considere la posibilidad de pasar a un enfoque de implementación de infraestructura como código para las zonas de aterrizaje de Azure, como se indicó anteriormente, si se encuentra en este escenario. O bien, tenga en cuenta los posibles riesgos de desfase de configuración entre el entorno de producción y el de valor controlado, y continúe con cuidado.
- Use entidades de servicio de Microsoft Entra (SPN) independientes o identidades de servicio administradas (MSI) que tengan permisos concedidos sobre el entorno de producción pertinente o la jerarquía de grupos de administración de entorno de valor controlado.
- Esta guía sigue el principio de privilegios mínimos (PoLP)
- Use carpetas independientes dentro de un repositorio, o ramas o repositorios independientes, para contener la infraestructura como código de las implementaciones de zonas de aterrizaje de Azure del entorno de producción y del entorno de valor controlado.
- Uso de las entidades de servicio de Microsoft Entra (SPN) o las identidades de servicios administrados (MSI) pertinentes como parte de las canalizaciones de CI/CD en función de la jerarquía que se implemente.
- Implemente directivas de rama de Git o seguridad para el entorno de valor controlado, tal como se ha implementado para el entorno de producción.
- Considere la posibilidad de reducir el número de aprobadores y comprobaciones para que el entorno de valor controlado tenga una respuesta rápida a errores.
- Use las mismas acciones de Azure Pipelines o GitHub que usan variables de entorno para cambiar la jerarquía que se está implementando. Otra opción es clonar las canalizaciones y modificar la configuración codificada de forma rígida para definir qué jerarquía se implementa.
- El uso de plantillas de DevOps de Azure Pipelines o plantillas del flujo de trabajo de Acciones de GitHub ayudará a adherirse al principio Una vez y solo una (DRY).
- Disponga de un conjunto de suscripciones de valor controlado en un departamento y cuenta de EA independientes que se puedan mover por la jerarquía de grupos de administración de valor controlado según sea necesario.
- Puede ser beneficioso tener un conjunto de recursos siempre implementados en las suscripciones de entorno de valor controlado.
- Puede resultar útil tener plantillas de infraestructura como código, como plantillas de ARM, Bicep o Terraform, que creen un conjunto de recursos que permitan la validación de cambios en el entorno de valor controlado.
- Envíe todos los registros de actividad de Azure de todas las suscripciones de Azure, incluidas las suscripciones de entorno de valor controlado, al área de trabajo de Azure Log Analytics del entorno de producción, según las recomendaciones de diseño de zonas de aterrizaje de Azure.
Sugerencia
Si ya tiene zonas de aterrizaje de Azure implementadas en producción y ahora busca agregar un entorno de valor controlado. Considere la posibilidad de clonar la implementación actual de la jerarquía del entorno de producción y modificar los nombres de los recursos para prefijarlos con el esquema de nomenclatura de valor controlado.
Esto es para asegurarse de que lo que va a implementar para habilitar el entorno de valor controlado esté sincronizado con producción desde el principio. Esto se logra fácilmente al usar una herramienta de infraestructura como código junto con un repositorio de Git.
Pasos siguientes
Aprenda a implementar entornos de espacio aislado de zona de aterrizaje.