Azure Landing Zone Review
Lo que cuesta una excepción
Una Landing Zone se diseña una vez y se amplía durante la operación, y ahí es donde empieza su historia real. El primer proyecto con una fecha límite inamovible consigue su Subscription fuera de la jerarquía porque el Policy Review habría durado más que el sprint. El proveedor que un viernes por la tarde no podía avanzar con permisos de Contributor recibe Owner en el Management Group y lo conserva, porque tras el go-live nadie vuelve a pensarlo. Y cuando el firewall del Hub limita el rendimiento de un Spoke, ese Spoke obtiene su peering directamente, saltándose el Hub. Cada una de esas decisiones fue razonable en su momento, y todas siguen vigentes hoy.
Las consecuencias son concretas. Una Subscription fuera de la jerarquía no hereda ninguna Policy y, por tanto, la Policy tampoco la protege. Un Owner a nivel de Management Group se propaga en silencio a todas las Subscriptions que haya por debajo, incluidas las que aún no existían entonces. Un peering sin ruta hacia el firewall es un camino de red que vuestro SOC no ve. El Azure Landing Zone Review superpone el diseño original al estado actual a lo largo de las ocho Design Areas del Cloud Adoption Framework y ordena las desviaciones por sus consecuencias, no por su antigüedad.
Las ocho Design Areas del Cloud Adoption Framework
Microsoft ha organizado las decisiones de una Landing Zone en ocho Design Areas porque, de lo contrario, la mayoría de los errores se ocultan en los espacios entre equipos: el equipo de red construye el Hub, el equipo de identidad asigna los roles, y quien aprobó la excepción de la Policy no aparece en ninguno de los dos registros. Las revisamos todas, cada una con la misma pregunta: qué estaba previsto, qué se ha construido y qué implica la diferencia.
Azure Billing y Entra ID Tenant
Enrollment, jerarquía de facturación y el tenant sobre el que descansa todo. Un segundo tenant proveniente de una adquisición rara vez supone un problema hasta que alguien tiene que unificar licencias, identidades y facturas.
Identity y Access Management
Roles a nivel de plataforma, Service Principals y PIM. Un Owner en el Root Management Group se hereda silenciosamente en cada Subscription que se cree después.
Resource Organization
Jerarquía de Management Groups, diseño de Subscriptions, nombres y etiquetas. Los workloads en el Management Group equivocado heredan las Policies incorrectas, y eso solo se detecta cuando llega una auditoría.
Network Topology y Connectivity
Hub-and-Spoke o Virtual WAN, conectividad híbrida, DNS, firewall, Private Endpoints. Un peering que evita el Hub es técnicamente correcto e invisible para el SOC.
Security
Defender for Cloud, cifrado, Key Vaults y todo lo que reside en la plataforma en lugar de en el workload. Un plan de Defender activo solo en parte de las Subscriptions protege exactamente esa parte.
Management
Monitoring, logging, backup y recovery. Los Diagnostic Settings que faltan no se echan en falta durante la operación, sino en el incidente, cuando se necesitan los logs que nunca se escribieron.
Governance
Azure Policy, iniciativas, excepciones y control de costes. Una Exemption tiene fecha de caducidad si alguien la fijó. La mayoría no tienen ninguna.
Platform Automation y DevOps
Infrastructure as Code, pipelines, Azure Verified Modules. Una plataforma que se modifica desde el portal tiene dos verdades: la del repositorio y la de Azure. Prevalece la segunda.
Cómo funciona
- Entrevistar al equipoEntrevistar al equipoEmpezamos por las personas que operan la plataforma, no por la herramienta: arquitectura, herramientas, procesos operativos, estrategia. La mayoría de los hallazgos que arroja un scan posterior tienen una historia previa, y quien la conoce los valora correctamente. Una decisión consciente es algo distinto a un parche olvidado.
- Analizar el entornoAnalizar el entornoA continuación analizamos el entorno con herramientas: Management Groups, Policies y Exemptions, asignaciones de roles, rutas de red, Diagnostic Settings, costes. De forma automatizada y contrastando con el estado actual del Cloud Adoption Framework, no con el de hace tres años.
- Priorizar los hallazgosPriorizar los hallazgosLa herramienta encuentra la desviación, la entrevista la explica, y solo ambas juntas determinan la prioridad. Encabezan la lista lo que propaga permisos o bloquea logs; al final, lo que infringe un esquema de nombres. Un hallazgo sin consecuencias es una anotación, no una tarea.
- Revisar el informe juntosRevisar el informe juntosRecibiréis el informe con el nivel de madurez por Design Area, los hallazgos y las recomendaciones, y lo repasamos juntos. No para que conozcáis cien hallazgos, sino para que el lunes sepáis por cuál empezar.
Un informe con orden de prioridad
Recibiréis un informe que sitúa vuestra Landing Zone a lo largo de las ocho Design Areas: nivel de madurez por área, hallazgos priorizados y recomendaciones que un equipo de plataforma puede implementar sin necesidad de consultarnos. Además, incluye la distinción que ningún escáner ofrece: qué desviación del framework fue una decisión y cuál fue un descuido. Está pensado para equipos de plataforma y responsables de TI que llevan años operando una Landing Zone y quieren saber qué ha cambiado desde entonces, tanto en el entorno como en el framework. Quien está ante una migración hace mejor en revisar los cimientos que la mudanza en sí. Quien ha heredado la plataforma de un proveedor necesita un segundo par de ojos que no haya construido lo que evalúa. La implementación no está incluida. Se ejecuta como un proyecto independiente, con nosotros, con un partner o con vuestro equipo.
Y después
Lo que nos preguntan antes de empezar
Las preguntas que surgen en las primeras conversaciones, respondidas tal como las respondemos allí.
¿Necesitamos una Landing Zone de glueckkanja para esto?
No. Revisamos cualquier Landing Zone, ya sea creada desde el Enterprise Scale Template, por otro proveedor o construida manualmente en el portal. El criterio es el Cloud Adoption Framework, no nuestra Azure Foundation. Que la recomendemos si el informe lo justifica no es ninguna sorpresa, pero tampoco es un requisito.
¿En qué se diferencia el review del Modul Azure der Preventive Services?
En la pregunta que se formula. El Modul Azure pregunta cómo puede llegar un atacante desde una Subscription al plano de control, y concluye con una roadmap de hardening. El Landing Zone Review pregunta si la plataforma en su conjunto es sólida: organización, red, governance, operación, automatización, costes. Security es ahí una de las ocho Design Areas. Quien quiere ambas cosas empieza por el review, porque es el que proporciona el mapa sobre el que el módulo traza los caminos.
¿Qué permisos necesitáis?
Solo de lectura. Para el análisis basta con un rol de Reader en el Management Group raíz, complementado con permisos de lectura sobre Cost Management. No modificamos nada, y los accesos se eliminan una vez concluido el review. El hecho de que el review pueda realizarse con permisos de Reader es en sí mismo ya un hallazgo: una Landing Zone en la que eso no es posible ha encontrado su primer tema.
¿También revisáis los costes?
Sí, porque en una Landing Zone tienen las mismas causas que los hallazgos de governance. Sin etiquetas no se puede asignar una factura a ningún equipo, sin alertas de presupuesto una VM olvidada solo aparece a fin de mes, y una reserva que nadie mantiene paga capacidad que nadie usa. Lo que se detecta en ese análisis queda recogido en el informe, con cifras.
¿Cuánto dura el review?
La entrevista y el análisis requieren pocos días. Por vuestra parte, implica una sesión de entrevista, la concesión de los permisos de lectura y la reunión en la que repasamos el informe juntos. La parte más laboriosa es lo que hagáis después con la lista, y esa os pertenece a vosotros.
¿Está incluida la implementación?
No, deliberadamente. Un review que priorizara sus propios proyectos de seguimiento no sería un review. Recibiréis el orden de prioridad y las recomendaciones; la implementación se ejecuta como un proyecto independiente, con nosotros, con un partner o con vuestro equipo. Quien quiera reconstruir la Landing Zone después encontrará el camino en la Azure Foundation.
