Administración de entornos de desarrollo de aplicaciones en zonas de aterrizaje de Azure

2025-05-26

En este artículo se describe cómo los equipos de plataforma en la nube pueden implementar límites de protección para administrar entornos de aplicación en zonas de aterrizaje de Azure. También se explica cómo alinear varios entornos de desarrollo de aplicaciones con su marco de trabajo. Un aspecto clave para crear el entorno adecuado es colocar suscripciones en los grupos de administración adecuados.

Establecer la base

Los equipos de desarrollo requieren la capacidad de iterar rápidamente y los equipos de gobernanza y plataforma en la nube necesitan administrar el riesgo, el cumplimiento y la seguridad de la organización a escala. Puede administrar correctamente los entornos de aplicación centrándose en dos principios clave de diseño de zona de aterrizaje de Azure: gobernanza controlada por directivas y democratización de suscripciones. Estos principios proporcionan límites de protección fundamentales y describen cómo delegar controles a los equipos de aplicación. Los equipos de aplicaciones usan las instrucciones de Azure Well-Architected Framework para diseñar su carga de trabajo. Implementan y administran sus propios recursos de zona de aterrizaje y el equipo de la plataforma controla los recursos mediante la asignación de directivas de Azure.

Es importante proporcionar entornos de prueba para recursos parcialmente gobernados, de manera que los equipos de desarrollo de aplicaciones puedan experimentar con tecnologías y capacidades.

Cuando los propietarios de aplicaciones usan la gestión de suscripciones u otros procesos de creación de suscripciones, deben saber cómo solicitar suscripciones para varios entornos de desarrollo.

En este artículo se describe la zona de aterrizaje de Azure, incluidos los grupos de administración, las directivas y la arquitectura de plataforma compartida, y la zona de aterrizaje de la carga de trabajo o la aplicación.

Nota:

Las instrucciones de este artículo solo son para zonas de aterrizaje de aplicaciones o cargas de trabajo. Para las pruebas y segregación de entornos para la plataforma de zona de aterrizaje de Azure en sí misma, consulte Enfoque de pruebas para zonas de aterrizaje de Azure, que describe el enfoque de canario.

En la práctica, puede usar cualquier número y tipo de entorno por fases. En este artículo se hace referencia a los siguientes entornos por fases.

Medio ambiente	Descripción	Grupo de administración
Espacio aislado	El entorno que se usa para la innovación rápida de prototipos, pero no para configuraciones destinadas a producción.	Grupo de administración de sandbox
Desarrollo	El entorno utilizado para construir versiones candidatas potenciales	Grupo de administración de arquetipos, como corp o online
Prueba	El entorno que se usa para realizar pruebas, incluidas las pruebas unitarias, las pruebas de aceptación de usuarios y las pruebas de control de calidad.	Grupo de administración de arquetipos, como corp o online
Producción	Entorno que se usa para entregar valor a los clientes	Grupo de administración de arquetipos, como corp o online

Para más información, consulte los vídeos Administración de entornos de desarrollo, pruebas y producción para cargas de trabajo de aplicaciones y ¿Cuántas suscripciones debo usar en Azure?

Entornos, suscripciones y grupos de administración

Como requisito previo para esta sección, consulte Área de diseño de organización de recursos.

Debe organizar correctamente las suscripciones cuando adopte prácticas de zona de aterrizaje de Azure. Lo ideal es que cada entorno de aplicación tenga su propia suscripción. Este método proporciona controles de seguridad y directivas que mantienen aislados los entornos. Contiene problemas potenciales para un entorno específico.

Las suscripciones independientes tienen las mismas políticas a nivel de arquetipo. Si es necesario, los propietarios de aplicaciones pueden asignar directivas específicas de la suscripción para aplicar el comportamiento específico de la aplicación y del entorno.

Algunas arquitecturas de aplicaciones requieren que los servicios se compartan entre entornos. Si es así, puede usar una sola suscripción para varios entornos. Se recomienda que los propietarios de cargas de trabajo trabajen con equipos de plataforma en la nube para determinar si se necesita una sola suscripción para varios entornos.

Use una sola suscripción para varios entornos de aplicación si:

Los entornos no se pueden aislar en sus propias suscripciones.
Los entornos tienen los mismos equipos asignados a roles funcionales, como operadores de red.
Los entornos pueden usar las mismas directivas.

Si una carga de trabajo de aplicación o servicio debe estar en una sola suscripción y debe realizar cambios en las directivas que se aplican a cada entorno, puede:

Cree un nuevo grupo de administración alineado con arquetipos debajo del grupo de administración de zonas de aterrizaje. Para obtener más información, consulte Jerarquía de grupos de administración en este artículo.
Utilice suscripciones de entorno aislado para actividades de desarrollo. Los espacios aislados tienen un conjunto de directivas menos restrictivo.
Use directivas que se aplican en el nivel de suscripción en lugar del nivel de grupo de administración. Puede agregar etiquetas en las definiciones de directiva para ayudar a filtrar y aplicar directivas al entorno correcto. También puede asignar directivas a o excluirlas de grupos de recursos específicos.

Puede asignar directivas durante el proceso de creación de suscripciones como parte de la gestión de suscripciones.

En el caso de las directivas que implemente para ayudar a controlar los costos, aplique la definición de directiva en un nivel de suscripción cuando sea necesario. O bien, puede hacer que el propietario de la zona de aterrizaje sea responsable de los costos, lo que proporciona una verdadera autonomía. Para más información, consulte Automatización de la plataforma y DevOps.

Advertencia

A diferencia de las directivas y controles en el nivel de grupo de administración, las políticas y etiquetas basadas en suscripciones pueden ser modificadas por personas con permisos elevados para la suscripción. Los administradores con roles adecuados pueden omitir estos controles excluyendo las directivas, modificando directivas o cambiando las etiquetas de los recursos.

En consecuencia, no debería aplicar etiquetas en las definiciones de políticas orientadas a la seguridad. Además, no asigne permisos como siempre activo para las siguientes acciones:

Microsoft.Authorization/policyAssignments/*
Microsoft.Authorization/policyDefinitions/*
Microsoft.Authorization/policyExemptions/*
Microsoft.Authorization/policySetDefinitions/*

Puede controlar estas acciones mediante Privileged Identity Management (PIM).

Jerarquía de grupos de administración

Evite jerarquías de grupos de administración complicadas. Pueden requerir una modificación frecuente, no escalan eficientemente y carecen de valor. Para evitar estos posibles problemas, los grupos de administración de zonas de aterrizaje de Azure están alineados con el arquetipo de carga de trabajo. Para obtener más información, consulte Grupo de administración y organización de suscripciones.

Arquetipo alineado significa que los grupos de administración solo se crean para arquetipos de carga de trabajo específicos. Por ejemplo, en la arquitectura conceptual, el grupo de administración de landing zones tiene grupos de gestión secundarios corp y online. Estos grupos de administración infantil se alinean con distintos patrones de arquetipo para las cargas de trabajo que manejan. Los grupos de administración de menores se centran en los requisitos de conectividad híbrida (VPN/Azure ExpressRoute), como aplicaciones y servicios internas únicamente frente a de cara al público.

Excepto los entornos de espacio aislado, varios entornos de aplicación deben usar el mismo arquetipo para la implementación. Incluso si los entornos se dividen en varias suscripciones, se mantienen dentro del mismo grupo de administración único (corp o en línea), en función del arquetipo del grupo de administración y los requisitos.

Puede usar suscripciones de sandbox para el desarrollo no estructurado, como laboratorios personales o para una carga de trabajo que no tenga un arquetipo. Un equipo de carga de trabajo de aplicación o servicio usa un grupo de administración de espacio aislado para probar varios servicios de Azure para determinar qué funciona mejor para sus requisitos. Después de decidir sobre los tipos de servicio, pueden configurar una zona de aterrizaje (en el grupo de administración alineado con el arquetipo de carga de trabajo correcto en la jerarquía del grupo de administración de zonas de aterrizaje) para el equipo.

Los entornos de espacio aislado se pueden usar para aplicaciones específicas o un equipo de cargas de trabajo puede usarlos para la experimentación.

Para obtener más información, consulte:

Desafíos del grupo de administración basado en el entorno

Los grupos de administración para entornos dentro de los arquetipos pueden agregar sobrecarga de administración y proporcionar un valor mínimo.

El grupo de gestión de zonas de aterrizaje debería tener políticas universales que impongan barreras de seguridad tanto para los subgrupos corporativos como para los subgrupos en línea de gestión. Corp y online tienen directivas únicas que aplican directrices de la empresa relacionadas con cargas de trabajo públicas y privadas.

Muchas organizaciones crean grupos de administración independientes para los entornos de ciclo de vida de desarrollo de cargas de trabajo de software (SDLC) para asignar controles y directivas de entorno. En la práctica, este método crea más desafíos para los equipos de carga de trabajo de los que resuelve. Los entornos SDLC no deben tener directivas diferentes, por lo que no se recomiendan grupos de administración independientes.

Los propietarios de aplicaciones pueden cambiar la topología o la configuración de recursos de una carga de trabajo, a fin de cumplir con las directivas de varios entornos SDLC por los que pasa. Este método aumenta el riesgo. Las reglas específicas de cada entorno pueden dar lugar a una mala experiencia de desarrollo para los equipos de control de calidad y desarrollo. También pueden surgir problemas si una aplicación tiene un conjunto de pautas de seguridad que son efectivas en un entorno, y la aplicación se somete a un conjunto diferente de directivas más adelante en su ciclo de promoción. Es posible que tenga que realizar ajustes en una aplicación si los controles cambian.

Para evitar este trabajo adicional, cree directivas coherentes a lo largo de la promoción del código en entornos SDLC. No debe crear directrices para cada entorno, sino proporcionar un conjunto uniforme para todos los entornos de desarrollo, excepto los entornos sandbox.

Por ejemplo, imagine que una organización define una directiva que requiere que las cuentas de almacenamiento se configuren con reglas de firewall específicas para evitar la entrada de redes públicas. En su lugar, las cuentas de almacenamiento usan puntos de conexión privados dentro de las redes de zona de aterrizaje de Azure para la comunicación. Si el entorno de desarrollo no tiene dicha directiva, probar la carga de trabajo no encuentra una configuración incorrecta de la cuenta de almacenamiento que permite el acceso público. Las implementaciones de prueba funcionan en el entorno de desarrollo y se revisan iterativamente. Cuando la solución se promueve a otro entorno que tiene la directiva de la cuenta de almacenamiento, se produce un error en la implementación debido a la directiva aplicada.

Como resultado, el equipo de desarrollo de aplicaciones debe volver a trabajar su implementación y arquitectura, después de invertir mucho esfuerzo. En este ejemplo se muestra cómo pueden crear problemas diferentes directivas en varios entornos.

Nota:

En la ecuación siguiente se muestra por qué un grupo de administración independiente para cada entorno o carga de trabajo no se escala bien: N cargas de trabajo x grupos de administración Z = grupos de administración totales.

Si una organización tiene 30 cargas de trabajo que requieren un grupo de administración y un grupo de administración secundario para entornos de desarrollo, pruebas y producción, la organización queda con:

N = el número de cargas de trabajo o aplicaciones = 30

Z = el número de grupos de administración para la carga de trabajo y los entornos (1 para la carga de trabajo + 3 para los entornos) = 4

N (30) x Z (4) = 120 grupos de administración totales

Es posible que los propietarios de aplicaciones necesiten directivas para aplicar de forma diferente a varios entornos. Por ejemplo, los propietarios de aplicaciones pueden requerir configuraciones de copia de seguridad para entornos de producción, pero no para otros entornos.

Algunas directivas se pueden habilitar como directivas de auditoría en el nivel de grupo de administración. Los equipos de aplicaciones determinan cómo implementar el control. Este método no impide las implementaciones, pero crea reconocimiento y permite a los equipos de aplicaciones administrar sus necesidades únicas. Después, pueden crear directivas de subnivel o incorporar estos requisitos en su infraestructura como módulos de implementación de código (IaC).

En este modelo de responsabilidad compartida, el equipo de plataforma audita las prácticas y el equipo de aplicaciones administra la implementación. Este modelo puede mejorar la agilidad de las implementaciones.

Los operadores de plataforma deben trabajar con cada equipo de carga de trabajo de aplicación o servicio (propietarios de zona de aterrizaje) para comprender sus requisitos. Los operadores de plataforma pueden proporcionar suscripciones en función de los requisitos y planes de la aplicación. Los operadores de plataforma también pueden decidir designar líneas de producto para varios tipos de cargas de trabajo para que puedan crear procesos de creación de suscripciones y herramientas en función de los requisitos comunes de los equipos de carga de trabajo de aplicaciones o servicios.

Escenario: cargas de trabajo basadas en máquinas virtuales (VM)

Las primeras cargas de trabajo en zonas de aterrizaje de Azure suelen estar formadas por máquinas virtuales de Azure. Puede implementar estas cargas de trabajo en Azure o migrarlas desde centros de datos existentes.

En lugar de implementar máquinas virtuales en varios entornos en una sola suscripción, puede hacer lo siguiente:

Establezca suscripciones para cada entorno de aplicación y colóquelas todas en el mismo grupo de administración de arquetipos.
Implemente una red virtual para cada entorno de aplicación en la suscripción adecuada. Puede determinar el tamaño de la red virtual en función del tamaño del entorno de la aplicación.
Despliegue las máquinas virtuales en su suscripción correspondiente. Las máquinas virtuales pueden usar diferentes SKU y configuraciones de disponibilidad diferentes para cada entorno, si procede.

Varios recursos del entorno de aplicación están protegidos por distintos controles de acceso. Como resultado, cuando los desarrolladores de aplicaciones configuran canalizaciones de implementación, la identidad de cada canalización puede limitarse al entorno. Esta configuración ayuda a proteger los entornos de implementaciones accidentales.

Escenario: Azure App Service

Una carga de trabajo con suscripciones ambientales que usan App Service puede crear desafíos. Para los desarrolladores de aplicaciones, un procedimiento recomendado de App Service es usar ranuras de implementación para ayudar a administrar los cambios y las actualizaciones de una aplicación web.

Sin embargo, esta característica solo se puede usar con la aplicación que se encuentra en el plan de servicio de aplicación, que solo puede residir dentro de una única suscripción. Si los operadores de plataforma exigen que los propietarios de la aplicación usen suscripciones independientes para entornos de desarrollo, pruebas y producción, es posible que el ciclo de vida de implementación de la aplicación sea más difícil de administrar.

En este ejemplo, la mejor opción es una sola suscripción para la carga de trabajo de aplicación o servicio. Los propietarios de aplicaciones pueden usar el control de acceso basado en rol (RBAC) de Azure con PIM en el nivel de grupo de recursos para aumentar la seguridad.

Compartir a través de