Adaptar la arquitectura de la zona de aterrizaje de Azure para cumplir los requisitos
Como parte de la guía de la zona de aterrizaje de Azure, hay disponibles varias opciones de implementación de referencia:
- Zona de aterrizaje de Azure con Azure Virtual WAN
- Zona de aterrizaje de Azure con grupo radial tradicional
- Fundación de la zona de aterrizaje de Azure
- Zona de aterrizaje de Azure para pequeñas empresas
Estas opciones pueden ayudar a su organización a empezar a trabajar rápidamente mediante configuraciones que proporcionan la arquitectura conceptual de la zona de aterrizaje de Azure y los procedimientos recomendados en las áreas de diseño.
Las implementaciones de referencia se basan en los procedimientos recomendados y los aprendizajes de los equipos de Microsoft de interacciones con clientes y asociados. Este conocimiento representa el lado "80" de la regla 80/20. Las distintas implementaciones toman posiciones en las decisiones técnicas que forman parte del proceso de diseño de arquitectura.
Dado que no todos los casos de uso son los mismos, no todas las organizaciones pueden usar un enfoque de implementación de la manera exacta en que estaba previsto. Debe comprender las consideraciones cuando se identifica un requisito de adaptación.
¿Qué es un arquetipo de zona de aterrizaje en zonas de aterrizaje de Azure?
Un arquetipo de zona de aterrizaje describe los valores que deben ser «true» para asegurarse de que una zona de aterrizaje (suscripción de Azure) satisfaga los requisitos de cumplimiento y entorno que se esperan en un ámbito determinado. Algunos ejemplos son:
- Asignaciones de Azure Policy.
- Asignaciones de control de acceso basado en roles (RBAC).
- Recursos administrados de forma centralizada, como las redes.
Considere cada grupo de administración de la jerarquía de recursos como contribución a la salida del arquetipo de zona de aterrizaje final, por la forma en que funciona la herencia de directivas en Azure. Piense en lo que se aplica en los niveles superiores de la jerarquía de recursos al diseñar los niveles inferiores.
Hay una relación estrecha entre los grupos de administración y los arquetipos de zona de aterrizaje, pero un grupo de administración solo no es un arquetipo de zona de aterrizaje. En su lugar, forma parte del marco que se usa para implementar cada uno de los arquetipos de zona de aterrizaje en su entorno.
Puede ver esta relación en la arquitectura conceptual de la zona de aterrizaje de Azure. Las asignaciones de directivas se crean en el grupo de administración raíz intermedio, por ejemplo Contoso, para la configuración que se debe aplicar a todas las cargas de trabajo. Se crean más asignaciones de directiva en niveles inferiores de la jerarquía para requisitos más específicos.
La ubicación de la suscripción en de la jerarquía del grupo de administración determina el conjunto resultante de asignaciones de Azure Policy y el control de acceso (IAM) que se heredan y se aplican a la zona de aterrizaje determinada (suscripción de Azure).
Es posible que se requieran más procesos y herramientas para asegurarse de que una zona de aterrizaje tenga los recursos administrados centralmente necesarios. Algunos ejemplos son:
- Configuración de diagnóstico para enviar datos del registro de actividad a un área de trabajo de Log Analytics.
- Configuración de exportación continua para Microsoft Defender for Cloud.
- Red virtual con espacios de direcciones IP administradas para cargas de trabajo de aplicaciones.
- Vinculación de redes virtuales a una protección de red contra denegación de servicio distribuida (DDoS).
Nota
En las implementaciones de referencia de la zona de aterrizaje de Azure, se utilizan las directivas de Azure con los efectos DeployIfNotExists, Modify, y para lograr la implementación de algunos de los recursos mencionados anteriormente. Siguen el principio de diseño de gobernanza controlada por directivas.
Para obtener más información, consulte Adoptar salvaguardias basadas en políticas.
Arquetipos integrados para la arquitectura conceptual de la zona de aterrizaje de Azure
La arquitectura conceptual incluye arquetipos de zona de aterrizaje de ejemplo para cargas de trabajo de aplicaciones como corp y online. Estos arquetipos pueden aplicarse a su organización y cumplir sus requisitos. Es posible que quiera realizar cambios en estos arquetipos o crear otros nuevos. La decisión depende de las necesidades y requisitos de su organización.
Sugerencia
Para revisar los arquetipos de la zona de aterrizaje en el acelerador de zonas de aterrizaje de Azure consulte Grupos de administración en el acelerador de zonas de aterrizaje de Azure.
También puede crear cambios en otra parte de la jerarquía de recursos. Cuando planea la jerarquía para la implementación de las zonas de aterrizaje de Azure para su organización, siga las instrucciones de las áreas de diseño.
Los siguientes ejemplos de arquetipo de zona de aterrizaje de la arquitectura conceptual le ayudan a comprender su propósito y su uso previsto:
| Arquetipo de zona de aterrizaje (grupo de administración) | Propósito o uso |
|---|---|
| Corp | El grupo de administración dedicado para zonas de aterrizaje corporativas. Este grupo es para cargas de trabajo que requieren conexión o conectividad híbrida con la red corporativa a través del hub en la suscripción de conectividad. |
| En línea | El grupo de gestión dedicado para las zonas de aterrizaje en línea. Este grupo es para cargas de trabajo que podrían requerir conectividad directa de entrada o salida de Internet o para cargas de trabajo que podrían no requerir una red virtual. |
| Espacio aislado | Grupo de administración dedicado para suscripciones que solo se usarán para pruebas y exploración por parte de una organización. Estas suscripciones se desconectarán de forma segura de las zonas de aterrizaje corporativas y en línea. Los espacios aislados también tienen un conjunto menos restrictivo de directivas asignadas para habilitar las pruebas, la exploración y la configuración de los servicios de Azure. |
Escenarios en los que se puede requerir la adaptación
Tal como se ha mencionado, aquí se proporcionan arquetipos de zona de aterrizaje comunes en la arquitectura conceptual de la zona de aterrizaje de Azure. Son corp y online. Estos arquetipos no son fijos y no son los únicos arquetipos de zona de aterrizaje permitidos para cargas de trabajo de aplicaciones. Es posible que tenga que adaptar los arquetipos de zona de aterrizaje para satisfacer sus necesidades y requisitos.
Antes de adaptar los arquetipos de zona de aterrizaje, es importante comprender los conceptos y visualizar también el área de la jerarquía que se recomienda personalizar. En el diagrama siguiente se muestra la jerarquía predeterminada de la arquitectura conceptual de la zona de aterrizaje de Azure.
Se resaltan dos áreas de la jerarquía. Una está debajo de Zonas de aterrizaje y la otra está debajo de Plataforma.
Personalización de arquetipos de zona de aterrizaje de aplicaciones
Observe el área resaltada en azul debajo del grupo de administración Zonas de aterrizaje. Es el lugar más común y seguro en la jerarquía para agregar más arquetipos a fin de cumplir nuevos o más requisitos que no se pueden agregar como más asignaciones de directiva a un arquetipo existente mediante la jerarquía existente.
Por ejemplo, puede tener un nuevo requisito para hospedar un conjunto de cargas de trabajo de aplicaciones que necesitan cumplir los requisitos de cumplimiento del sector de tarjetas de pago (PCI). Sin embargo, este nuevo requisito no es necesario aplicar a todas las cargas de trabajo de todo el patrimonio.
Hay una manera sencilla y segura de cumplir este nuevo requisito. Cree un nuevo grupo de administración denominado PCI debajo del grupo de administración Zonas de aterrizaje de la jerarquía. Puede asignar más directivas, como la iniciativa de directiva de cumplimiento normativo de Microsoft Defender for Cloud para PCI v3.2.1:2018 al nuevo grupo de administración PCI. Esta acción forma un nuevo arquetipo.
Ahora puede colocar nuevas o mover suscripciones de Azure existentes al nuevo grupo de administración PCI para que herede las directivas necesarias y forme el nuevo arquetipo.
Otro ejemplo es Microsoft Cloud for Sovereignty, que agrega grupos de administración para proceso confidencial y se alinea para su uso en sectores regulados. Microsoft Cloud for Sovereignty proporciona herramientas, instrucciones y barreras de protección para la adopción de la nube pública con controles de soberanía adecuados.
Sugerencia
Debe saber qué tener en cuenta y qué ocurre al mover suscripciones de Azure entre grupos de administración en relación con RBAC y Azure Policy. Para más información, consulte Transición de entornos de Azure existentes a la arquitectura conceptual de la zona de aterrizaje de Azure.
Personalización de arquetipos de zona de aterrizaje de plataforma
Es posible que algunos clientes también quieran adaptar el área resaltada en naranja que está por debajo del grupo de administración Plataforma. Las zonas de esta área se conocen como zonas de aterrizaje de plataforma .
Por ejemplo, puede tener un equipo de SOC dedicado que requiera su propio arquetipo para hospedar sus cargas de trabajo. Estas cargas de trabajo deben cumplir con los requisitos de asignación de Azure Policy y RBAC diferentes a los del grupo de administración Administración.
Cree un nuevo grupo de administración Seguridad debajo del grupo de administración Plataforma de la jerarquía. Puede asignarle las asignaciones de Azure Policy y RBAC necesarias.
Ahora puede colocar nuevas suscripciones de Azure o mover las existentes al nuevo grupo de administración de Security para que herede las directivas necesarias y forme un nuevo arquetipo.
Ejemplo de una jerarquía de zona de aterrizaje de Azure adaptada
En el diagrama siguiente se muestra una jerarquía de zona de aterrizaje de Azure adaptada. Usa ejemplos del diagrama anterior.
Puntos que se deben tener en cuenta
Tenga en cuenta los siguientes puntos al pensar en adaptar la implementación de arquetipos de zona de aterrizaje de Azure en la jerarquía:
La adaptación de la jerarquía no es obligatoria. Los arquetipos y la jerarquía predeterminados que proporcionamos son adecuados para la mayoría de los escenarios.
No vuelva a crear la jerarquía, los equipos o los departamentos de la organización en arquetipos.
Intente siempre construir sobre los arquetipos y la jerarquía existentes para cumplir con los nuevos requisitos.
Solo cree nuevos arquetipos cuando sean realmente necesarios.
Por ejemplo, se requiere un nuevo requisito de cumplimiento, como PCI, solo para un subconjunto de cargas de trabajo de aplicación y no es necesario aplicar a todas las cargas de trabajo.
Cree solo nuevos arquetipos en las áreas resaltadas que se muestran en los diagramas anteriores.
Evite ir más allá de una profundidad de jerarquía de cuatro capas de para evitar la complejidad y las exclusiones innecesarias. Expanda arquetipos horizontalmente en lugar de verticalmente en la jerarquía.
No cree arquetipos para entornos como desarrollo, prueba y producción.
Para más información, consulte ¿Cómo se controlan las zonas de aterrizaje de carga de trabajo de desarrollo, pruebas y producción en la arquitectura conceptual de las zonas de aterrizaje de Azure?
Si procede de un entorno Brownfield o busca un enfoque para hospedar suscripciones en el grupo de administración de zonas de aterrizaje con directivas en modo de cumplimiento "solo auditoría", revise Escenario: Transición de un entorno duplicando un grupo de administración de zonas de aterrizaje