Administración de entornos de desarrollo de aplicaciones en zonas de aterrizaje de Azure
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 respectivo marco de trabajo. Un aspecto clave para crear el entorno adecuado es colocar suscripciones en los grupos de administración adecuados.
Establecer las bases
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 gran 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 utilizan la guía del Marco de buena arquitectura de Azure 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 recursos de espacio aislado para recursos semirregulados; así, los equipos de aplicaciones pueden experimentar con tecnologías y funcionalidades.
Cuando los propietarios de aplicaciones utilizan venta 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. Si quiere realizar pruebas y segregar entornos para la propia plataforma de zona de aterrizaje de Azure, consulte Enfoque de pruebas para zonas de aterrizaje de Azure, donde se describe el enfoque de valor controlado.
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.
| Entorno | Descripción | Grupo de administración |
|---|---|---|
| Espacio aislado | Entorno que se usa para la rápida innovación de prototipos, pero no para configuraciones vinculadas con producción | Grupo de administración de espacio aislado |
| Desarrollo | El entorno que se usa para crear posibles candidatos de versión | Grupo de administración de arquetipos, como corp u 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 u online |
| Producción | Entorno que se usa para entregar valor a los clientes | Grupo de administración de arquetipos, como corp u 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 al adoptar 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 posibles problemas para un entorno.
Las suscripciones independientes tienen las mismas directivas en el 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 suscripción única 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 suscripción única para varios entornos.
Use una suscripción única 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 suscripción única y debe realizar cambios en las directivas que se aplican a cada entorno, puede:
Crear 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 la sección Jerarquía de grupos de administración de este artículo.
Use suscripciones de espacio aislado para las 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 añadir etiquetas en las definiciones de directiva para ayudar a filtrarlas y aplicarlas al entorno correcto. También puede asignar directivas a grupos de recursos específicos o excluirlas de dichos grupos.
Puede asignar directivas durante el proceso de creación de la suscripción como parte de venta de suscripciones.
En el caso de las directivas que implemente para ayudar a controlar los costes, 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 costes, lo que proporciona una verdadera autonomía. Para obtener más información, vea Automatización de la plataforma y DevOps.
Advertencia
A diferencia de las directivas y controles en el nivel de grupo de administración, las personas con permisos elevados pueden cambiar las directivas y etiquetas basadas en suscripciones. Los administradores con roles adecuados pueden omitir estos controles excluyendo las directivas, modificando directivas o cambiando las etiquetas de los recursos.
Como resultado, no debe aplicar etiquetas en las definiciones de directivas centradas en 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. Puede ser necesario modificarlas frecuentemente, el redimensionamiento a escala puede resultar ineficaz y pueden carecer 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 más información, consulte Organización de grupos de administración y suscripciones.
La alineación con arquetipos significa que los grupos de administración solo se crean para arquetipos de carga de trabajo diferentes. Por ejemplo, en la arquitectura conceptual, el grupo de administración de zonas de aterrizaje tiene los grupos de administración secundarios corp y online. Estos grupos de administración secundarios se alinean con distintos patrones de arquetipo para las cargas de trabajo que contienen. Los grupos de administración secundarios se centran en los requisitos de conectividad híbrida (VPN/Azure ExpressRoute), como solo interno frente a aplicaciones y servicios orientados 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 u online), en función del arquetipo del grupo de administración y los requisitos.
Puede usar suscripciones de espacio aislado 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 a fin de probar varios servicios de Azure para determinar qué funciona mejor para sus requisitos. Una vez que se deciden los servicios, se puede aprovisionar una zona de aterrizaje (en el grupo de administración alineado con el arquetipo de carga de trabajo correcto en la jerarquía de grupos 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 más información, vea:
- Grupos de administración.
- Área de diseño de la organización de recursos.
- Adaptación de la arquitectura de zona de aterrizaje de Azure para cumplir los requisitos.
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 administración de zonas de aterrizaje debería tener directivas universales que apliquen límites de protección para ambos grupos de administración secundarios corp y online. Corp y online tienen directivas exclusivas para aplicar las pautas de la empresa relacionadas con cargas de trabajo públicas y privadas.
Muchas organizaciones crean grupos de administración independientes para entornos de ciclo de vida de desarrollo de software (SDLC) de cargas de trabajo para asignar directivas y controles 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 deberían 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 para alinearse con las directivas de varios entornos SDLC a los que se promueve. 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 directivas de límite de protección que funcionan en un entorno y la aplicación se expone 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 conviene crear directivas para cada entorno, sino proporcionar un conjunto coherente para todos los entornos de desarrollo, excepto los entornos de espacio aislado.
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 ninguna configuración errónea de la cuenta de almacenamiento que permite el acceso público. Las implementaciones de prueba funcionan en el entorno de desarrollo y se iteran. 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 diferentes directivas en varios entornos pueden crear problemas.
Nota
La ecuación siguiente demuestra por qué los grupos de administración independientes para cada entorno o carga de trabajo no se escalan bien: N cargas de trabajo x Z grupos de administración = Total de grupos de administración.
Si una organización tiene 30 cargas de trabajo, de las cuales cada una requiere un grupo de administración y un grupo de administración secundario para entornos de desarrollo, pruebas y producción, la organización se queda con:
N = número de cargas de trabajo o aplicaciones = 30
Z = número de grupos de administración para cargas de trabajo y entornos (1 por carga de trabajo + 3 para entornos) = 4
N (30) x Z (4) = 120 grupos de administración en total
Es posible que los propietarios de aplicaciones necesiten directivas para aplicarlas de forma diferente a varios entornos. Por ejemplo, los propietarios de aplicaciones pueden requerir configuraciones de backup 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 genera 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 plataformas deben trabajar con cada uno de los equipos de cargas de trabajo de aplicaciones o servicios (propietarios de zonas de aterrizaje) para comprender sus requisitos. Los operadores de plataformas pueden proporcionar suscripciones en función de los requisitos y planes de la aplicación. También pueden optar por designar líneas de productos para diferentes tipos de cargas de trabajo de modo que puedan crear herramientas y procesos de creación de suscripciones en función de los requisitos comunes de los equipos de cargas 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 suscripción única, 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.
Implemente las máquinas virtuales en su suscripción adecuada. 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 de entorno que usan App Service puede suponer todo un desafío. Un procedimiento recomendado de App Service para los desarrolladores de aplicaciones consiste en usar ranuras de implementación para ayudar a administrar los cambios y las actualizaciones para una aplicación web.
Sin embargo, esta característica solo se puede usar en la aplicación que está en el plan de App Service, que solo puede residir en una suscripción única. 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 suscripción única 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.