Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 las definiciones y asignaciones de Azure Policy, los roles personalizados y asignaciones de RBAC (control de acceso basado en roles), entre otros, en su implementación de la plataforma de aterrizaje de Azure Policy. 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 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. Además, se puede combinar con la guía de Adopción de límites de protección controlados por directivas para técnicas sobre la implementación de cambios de directiva en una implementación de zonas de aterrizaje de Azure.
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.
Nota:
El término canario 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.
Del mismo modo, el término entorno o jerarquía de producción se usa en esta guía para hacer referencia a la jerarquía del grupo de administración de zonas de aterrizaje de Azure que su organización podría tener en su lugar que contenga las suscripciones y 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 usarán los propietarios de aplicaciones o servicios conocidos como zonas de aterrizaje, cargas de trabajo, aplicaciones o servicios. Estos se colocan y controlan dentro del entorno de producción en la jerarquía del grupo de administración de zonas de aterrizaje de Azure y la gobernanza asociada (RBAC y Azure Policy).
Para obtener instrucciones sobre desarrollo, pruebas, pruebas de aceptación de usuarios (UAT) y entornos de producción para cargas de trabajo de aplicaciones y equipos, consulte Administración de entornos de desarrollo de aplicaciones en zonas de aterrizaje de Azure.
Esta guía es solo para pruebas de nivel de plataforma y cambios en el contexto de las zonas de aterrizaje de Azure.
Las zonas de aterrizaje de Azure le ayudan a diseñar e implementar los componentes necesarios de la plataforma Azure 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:
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 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.
Importante
Esto 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 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 zonas 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 deben ser únicos dentro de cada entidad de Microsoft Entra.
Nota:
Los nombres para mostrar de los grupos de administración 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. Por este motivo, se recomienda anexar el nombre "valor controlado" (canary) a los nombres para mostrar y a sus identificadores.
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
- Tareas
¿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 con espacios aislados resaltados.
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 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 para zonas de aterrizaje de Azure 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 salgan de la sincronización 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 (IaC) para las zonas de aterrizaje de Azure, como se ha indicado anteriormente, si está 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. Para más información, consulte Uso de IaC para actualizar las zonas de aterrizaje de Azure.
- Use entidades de servicio de Microsoft Entra (SPN) independientes o identidades administradas (MI) que tengan permisos concedidos sobre el entorno de producción pertinente o la jerarquía de grupos de administración para zonas de aterrizaje de Azure de entorno de valor controlado.
- Esta guía sigue el principio de privilegios mínimos (PoLP)
- Use carpetas independientes dentro de un repositorio, 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 administradas (MI) 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 de flujos de trabajo de GitHub Actions le ayudará a cumplir el principio de No Repetirse (DRY).
- 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.
- Tenga un conjunto de arquitecturas de carga de trabajo de aplicaciones de ejemplo que puede implementar en las suscripciones de valor controlado en el entorno de valor controlado para probar los cambios de Azure Policy y RBAC. 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 la aplicación 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 de aplicaciones, considere la posibilidad de implementarlas también en el entorno controlado. Esto le ayuda a validar los cambios en las arquitecturas de referencia y a asegurarse de que son aplicables al entorno de producción.
- 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.
- 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.
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 IaC junto con un repositorio git.
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 solo inquilino sigue las Recomendaciones de diseño de zonas de aterrizaje de Azure para los inquilinos de Microsoft Entra.
- En un único inquilino de Microsoft Entra, es posible usar los distintos grupos de Microsoft Entra para entornos de producción y de zonas de aterrizaje de Azure de valor controlado, con los mismos usuarios, asignados a su jerarquía de grupos de administración pertinente.
- 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 zonas de aterrizaje de Azure.
Pasos siguientes
Una vez implementado un entorno de valor controlado, puede empezar a probar los cambios de Azure Policy y RBAC antes de implementarlos en la jerarquía del grupo de administración de zonas 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 evaluar los entornos sandbox para que los equipos de desarrollo los utilicen en el desarrollo y las pruebas de sus tareas. Se trata de un concepto independiente del entorno de valor controlado y se usa para proporcionar un entorno seguro para que los equipos de desarrollo de aplicaciones desarrollen y prueben sus cargas de trabajo antes de que se implementen en producción.