Enfoque de pruebas para la zona de aterrizaje de Azure

Es posible que algunas organizaciones quieran probar la implementación, por parte del acelerador de zona de destino de la plataforma, de definiciones y asignaciones de Azure Policy, roles personalizados y asignaciones de control de acceso basado en roles (RBAC), etc. Las pruebas se pueden completar a través de la automatización mediante plantillas de Azure Resource Manager (plantillas de ARM), Terraform, Bicepo manualmente a través de Azure Portal. Esta guía proporciona un enfoque que puede utilizarse para probar cambios y su impacto en la implementación de un acelerador de zona de aterrizaje de plataforma.

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. Además, se puede combinar con las instrucciones de Adopción de barreras de protección controladas por directivas para técnicas sobre la implementación de cambios de directiva en una implementación de zona de aterrizaje de plataforma.

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 del grupo de administración de producción. La jerarquía de grupos de administración canaria se puede usar de forma independiente para desarrollar y probar implementaciones antes de desplegarlas en el entorno de producción.

Definición de plataforma

Azure guía de zona de aterrizaje le ayuda a diseñar e implementar los componentes de plataforma Azure necesarios para permitirle construir y poner en marcha zonas de aterrizaje a escala.

Los recursos de la plataforma en el ámbito de este artículo y este enfoque de prueba son:

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

Figura 1: Jerarquía del grupo de administración canario.

Como se muestra en el diagrama, toda la jerarquía de grupos de administración de producción de zona de aterrizaje de Azure está duplicada en Tenant Root Group. El término valor controlado (canary) se anexa a los nombres para mostrar y los id. de los grupos de administración. Los identificadores de grupo de administración deben ser únicos dentro de un solo inquilino de Microsoft Entra. El inquilino trata los identificadores de los grupos de administración como identificadores de referencia, por lo que deben ser distintos dentro del inquilino. Puede mantener los nombres para mostrar del grupo de administración alineados con la jerarquía del grupo de administración de producción. Añada también una distinción en la denominación de los nombres para mostrar, para que los usuarios puedan distinguir visualmente la jerarquía canary del entorno de producción al navegar por el árbol de grupos de administración.

A continuación, se usa la jerarquía de grupos de administración 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)
  • Asignaciones
• Azure Policy
  • Definiciones (integradas y personalizadas)
  • Iniciativas, también conocidas como definiciones de conjunto
  • Asignaciones

¿Qué ocurre si no quiere implementar la jerarquía de grupos de administración de valor controlado?

Si no quiere implementar toda la jerarquía de grupos de administración 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.

Figura 2: Jerarquía de grupos de administración de zonas de aterrizaje de Azure que resalta los entornos de pruebas.

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 con la que desea realizar las pruebas, como por ejemplo, una cuenta de usuario, una entidad de servicio o una identidad de servicio administrada. Esta configuración permite crear, asignar y corregir las definiciones y asignaciones de Azure Policy solo dentro del ámbito de la suscripción de espacio aislado.

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 del entorno de prueba se pueden utilizar durante el tiempo que sean necesarias y luego eliminar 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.

Guía de implementación

A continuación se ofrece orientación sobre cómo implementar y usar la jerarquía de grupos de administración canary para una zona de aterrizaje de Azure, junto con la jerarquía de grupos de administración de una zona de aterrizaje de Azure para un entorno de producción.

1. Use entidades de servicio (SPN) o identidades administradas (MI) independientes de Microsoft Entra a las que se les hayan concedido permisos sobre la jerarquía de grupos de administración de la zona de aterrizaje de Azure del entorno de producción pertinente o del entorno canary.
   • Esta guía sigue el principio de privilegios mínimos (PoLP)
2. Use carpetas independientes dentro de un repositorio, ramas o repositorios que van a contener IaC para las implementaciones de zona de aterrizaje de Azure del entorno de producción y del entorno de prueba.
   • Uso de las entidades de servicio de Microsoft Entra (SPN) o las identidades administradas (MI) pertinentes como parte de las canalizaciones de CI/CD en función de la jerarquía que se implemente.
3. 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.
4. 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 de flujos de trabajo de Acciones de GitHub le ayudará a cumplir el principio de No Repetirse (DRY).
5. Tener un conjunto de suscripciones de valor controlado bajo una cuenta de facturación independiente, por ejemplo, una sección de factura de Contrato Enterprise (EA) o Contrato de cliente de Microsoft (MCA), que se puedan mover dentro de la jerarquía del grupo de administración de valor controlado según sea necesario.
   • Puede resultar beneficioso tener un conjunto de recursos siempre implementado en las suscripciones de entorno controlado para acelerar las pruebas y la validación de los cambios en el entorno controlado.
6. Disponga de un conjunto de arquitecturas de ejemplo de cargas de trabajo que pueda implementar en las suscripciones canary del entorno canary para validar los cambios de Azure Policy y RBAC con ellas. Esto le ayuda a validar los cambios antes de implementar y promover los cambios en producción.
   • Estas cargas de trabajo de ejemplo se pueden implementar con las mismas plantillas de IaC que se usan para implementar las cargas de trabajo de producción. Esto le ayudará a asegurarse de que el entorno de valor controlado está sincronizado con el entorno de producción y que los cambios que está probando son válidos y aplicables al entorno de producción.
   • Debe revisar y actualizar continuamente las cargas de trabajo de ejemplo para asegurarse de que son relevantes y actualizados con los patrones de diseño y arquitectura más recientes de su organización.
   • Si proporciona arquitecturas de referencia a los equipos responsables de las cargas de trabajo, considere implementarlas también en el entorno canary. Esto le ayuda a validar los cambios en las arquitecturas de referencia y a asegurarse de que son aplicables al entorno de producción.
7. Envíe todos los registros de actividad de Azure de todas las suscripciones de Azure, incluidas las suscripciones de cualquier entorno de canary, al área de trabajo de Azure Log Analytics del entorno de producción, según las recomendaciones de diseño de la zona de aterrizaje de Azure.
   • Esto ayuda a los equipos de seguridad y operaciones a supervisar el entorno de valor controlado en busca de cambios o problemas que puedan surgir de las pruebas de los cambios de Azure Policy y RBAC en el entorno de producció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:

• El uso de un único inquilino sigue las recomendaciones de diseño de la zona de aterrizaje de Azure para los inquilinos de Microsoft Entra.
  • En un único tenant de Microsoft Entra, puede usar los distintos grupos de Microsoft Entra tanto para los entornos de Azure landing zone de producción como para los canarios, con los mismos usuarios asignados a la jerarquía de grupos de administración correspondiente.
• Aumentan o se duplican los costes de licencias de Microsoft Entra debido a varias identidades en diferentes inquilinos de Microsoft Entra. Esto es especialmente relevante para los clientes que usan las características P1 o P2 de Microsoft Entra ID.
• Los cambios de RBAC serán más complejos tanto en entornos de valor controlado como de producción, ya que es probable que los usuarios y los grupos no sean idénticos en ambos inquilinos de Microsoft Entra.
  • Tenga en cuenta que los identificadores de usuarios y grupos no serán los mismos en todos los inquilinos de Microsoft Entra, ya que 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 podrían realizar cambios accidentales en el entorno de producción en lugar del entorno controlado, como ejemplo.
• 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 la zona de aterrizaje de Azure.

Pasos siguientes

Una vez que disponga de un entorno canary, puede empezar a probar los cambios de Azure Policy y RBAC antes de implementarlos en la jerarquía de grupos de administración de la zona de aterrizaje de Azure de producción.

Cuando haya probado los cambios en las directivas de Azure en el entorno de valor controlado, puede promoverlos al entorno de producción siguiendo el mismo enfoque que se documenta en la guía Adopción de límites de protección controlados por directivas. Esto se hace mediante la función de modo de aplicación de las asignaciones de directivas. El uso del enfoque documentado en esta guía le permite continuar con una fase de prueba adicional antes de aplicar Azure Policy en el entorno de producción en su efecto deseado, lo que le ayudará a crear confianza en los cambios de Azure Policy que está realizando.

También puede revisar los entornos de espacio aislado para que los equipos de carga de trabajo los usen para el desarrollo y las pruebas de las cargas de trabajo. Se trata de un concepto distinto del entorno canary y se utiliza para proporcionar un entorno seguro en el que los equipos responsables de las cargas de trabajo puedan desarrollar y probar sus cargas de trabajo antes de implementarlas en producción.