Adaptar la arquitectura de 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 concentrador y radio tradicionales
- Base 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 las interacciones con clientes y asociados. Este conocimiento representa el «80» en la regla 80/20. Las distintas implementaciones toman posiciones en decisiones técnicas que forman parte del proceso de diseño de arquitectura.
Porque no todos los casos de uso son los mismos, ya que 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 para la adaptación.
¿Qué es un «arquetipo de zona de aterrizaje» en las 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) satisfará los requisitos de cumplimiento y entorno que se esperan en un ámbito determinado. Algunos ejemplos son los siguientes:
- Asignaciones de Azure Policy.
- Asignaciones de control de acceso basado en roles (RBAC).
- Recursos administrados centralmente como redes de trabajo.
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 solo grupo de administración 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 necesiten más procesos y herramientas para asegurarse de que una zona de aterrizaje tiene los recursos necesarios administrados centralmente. Estos son algunos ejemplos:
- Una configuración de diagnóstico para enviar datos del registro de actividad a un área de trabajo de Log Analytics.
- Una configuración de exportación continua para Microsoft Defender for Cloud.
- Una red virtual (VNet) 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 distribuido (DDoS).
Nota
En las implementaciones de referencia de la zona de aterrizaje de Azure, las directivas de Azure con los efectos DeployIfNotExists y Modify se usan para lograr la implementación de algunos de los recursos anteriores. Siguen el principio de diseño de gobernanza controlada por directivas.
Consulte Adopción de límites de protección controlados por directivas para obtener más información.
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. Tal vez desee realizar cambios en estos arquetipos o crear otros nuevos. La decisión depende de las necesidades y los requisitos de la 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 realizar 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 conectividad o conectividad híbrida con la red corporativa a través del concentrador en la suscripción de conectividad. |
| En línea | El grupo de administración dedicado para zonas de aterrizaje en línea. Este grupo es para cargas de trabajo que pueden requerir conectividad entrante y saliente directa de Internet o para cargas de trabajo que podrían no requerir una red virtual. |
| Espacio aislado | El grupo de administración dedicado para suscripciones que solo se usará 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 asignado un conjunto menos restrictivo de directivas para habilitar las pruebas, la exploración y la configuración de los servicios de Azure. |
Escenarios en los que se podría 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 la aplicación. 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 también visualizar el área de la jerarquía que le sugerimos 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 las zonas de aterrizaje y la otra está debajo de la plataforma.
Adaptar de los arquetipos de zona de aterrizaje de la aplicación
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 para 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, es posible que tenga un nuevo requisito para hospedar un conjunto de cargas de trabajo de aplicación que necesiten 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 de Zonas de aterrizaje de la jerarquía. Puede asignar más directivas, como la Microsoft Defender for Cloud iniciativa de directiva de cumplimiento normativo para PCI v3.2.1:2018 al nuevo grupo de administración PCI. Esta acción forma un nuevo arquetipo.
A continuación, puede colocar suscripciones de Azure nuevas o mover las existentes al nuevo grupo de administración PCI para que herede las directivas adicionales necesarias y formar así el nuevo arquetipo.
Otro ejemplo es Microsoft Cloud for Sovereignty, que añade grupos de administración para el proceso confidencial y está alineado para su uso en sectores regulados. Microsoft Cloud for Sovereignty proporciona herramientas, instrucciones y límites de protección para la adopción de la nube pública con controles de soberanía adecuados.
Sugerencia
Es preciso que sepa 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.
Adaptar de los arquetipos de zona de aterrizaje de la 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, podría 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 gestión Management.
Cree un nuevo grupo de administración de seguridad debajo del grupo de administración de Plataformas de la jerarquía. Puede designarle las asignaciones de Azure Policy y RBAC necesarias.
A continuación, puede colocar suscripciones de Azure nuevas o mover las existentes al nuevo grupo de administración Seguridad para que herede las directivas adicionales necesarias y formar así el nuevo arquetipo.
Ejemplo de una jerarquía de zona de aterrizaje de Azure personalizada
En el diagrama siguiente se muestra una jerarquía de zona de aterrizaje de Azure personalizada. Usa ejemplos del diagrama anterior.
Puntos que se deben tener en cuenta
Tenga en cuenta los siguientes puntos cuando piense en adaptar la implementación de arquetipos de zona de aterrizaje de Azure en la jerarquía:
No es obligatorio adaptar la jerarquía. 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 organizativa, los equipos ni los departamentos en arquetipos.
Intente siempre basarse en los arquetipos y la jerarquía existentes para satisfacer los nuevos requisitos.
Debe crear nuevos arquetipos solo cuando sean realmente necesarios.
Por ejemplo, si se requiere un nuevo requisito de cumplimiento (como PCI) solo para un subconjunto de cargas de trabajo de aplicación y no es necesario aplicarlo a todas las cargas de trabajo.
Debe crear nuevos arquetipos solo en las áreas resaltadas en los diagramas anteriores.
Evite ir más allá de una profundidad de jerarquía de cuatro capas para evitar la complejidad y las exclusiones innecesarias. Expanda los 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 de 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