Una landing zone de Azure que puedas mantener de verdad

Microsoft publica una landing zone de escala empresarial con decenas de grupos de administración, asignaciones de política y una red en estrella. Es una buena arquitectura y es más de lo que casi ninguna organización necesita el primer día, por lo que el resultado habitual es una versión a medio desplegar que nadie entiende y una suscripción creada a mano al lado.

Este es el subconjunto que desplegamos, en el orden en que se gana el sitio.

Grupos de administración: herencia de políticas, no organigrama

Los grupos de administración existen para que las políticas se hereden. No son un sitio donde reflejar tu estructura de reporte. Seis niveles es el máximo soportado y dos o tres es lo que quieres.

Raíz del tenant
└── org
    ├── platform          (identidad, gestión, conectividad)
    ├── landing-zones
    │   ├── corp          (interno, sin entrada pública)
    │   └── online        (expuesto a internet)
    ├── sandbox           (política laxa, tope duro de presupuesto)
    └── decommissioned    (deniega todo, suscripciones de salida)

La separación corp / online es la que la gente se salta y luego echa de menos. Te permite asignar "sin direcciones IP públicas" a una rama entera en lugar de discutirlo suscripción por suscripción.

Asigna las políticas en grupos de administración, nunca en suscripciones. Una política asignada a treinta suscripciones por separado son treinta cosas que mantener y que derivan.

Suscripciones: la frontera real

Una suscripción es el radio de explosión de Azure. Las cuotas son por suscripción y región, el RBAC se acota limpiamente a ella y la facturación se agrega desde ahí. Así que: una suscripción por carga de trabajo y entorno, no por equipo ni por departamento.

Las suscripciones de plataforma van aparte y son pequeñas: una para identidad, una para gestión (Log Analytics, automatización) y una para conectividad (la VNet hub, el firewall, las pasarelas de ExpressRoute o VPN). Tener la conectividad en su propia suscripción significa que el equipo de redes posee una frontera y no un grupo de recursos.

Los grupos de recursos van dentro de las suscripciones y deberían seguir el ciclo de vida: lo que se borra junto vive junto. Un grupo de recursos con una base de datos de producción y la VM de pruebas de alguien es un grupo de recursos que nadie puede borrar con seguridad.

Azure Policy: la parte que hace el trabajo

Aquí Azure es genuinamente fuerte, y es el motivo de que la landing zone aguante. Empieza por estas, asignadas en org o en la rama landing-zones:

• Denegar direcciones IP públicas en interfaces de red dentro de corp.
• Denegar cuentas de almacenamiento con acceso público a blobs, y exigir minimumTlsVersion 1.2 y tráfico solo HTTPS.
• Denegar servidores SQL y PostgreSQL con acceso de red público activado.
• DeployIfNotExists de la configuración de diagnóstico hacia el workspace central de Log Analytics para cada tipo de recurso que te importe. Es la política más valiosa del conjunto: hace que los recursos nuevos se registren sin que nadie se acuerde.
• DeployIfNotExists de los planes de Microsoft Defender for Cloud en cada suscripción nueva.
• Denegar la creación de recursos fuera de tus regiones permitidas.
• Exigir etiquetas environment, owner y centro-de-coste, con efecto Modify para heredarlas del grupo de recursos donde se pueda.

Despliega todas las políticas en modo Audit primero, mira el cumplimiento dos semanas y después pásalas a Deny. Una política Deny asignada sin ese paso es una caída esperando al siguiente despliegue.

Identidad: grupos de Entra ID y PIM para todo lo privilegiado

Las asignaciones de RBAC van a grupos, nunca a usuarios, y los grupos vienen de tu proveedor de identidad. Un Owner o Contributor permanente sobre una suscripción de producción no debería existir — esos roles son asignaciones elegibles en Privileged Identity Management, activadas con justificación y caducidad, con alerta al activarse.

Identidades gestionadas para cada carga, para que ninguna aplicación tenga nunca un secreto con el que autenticarse en Azure. Donde haga falta un secreto de verdad, Key Vault con RBAC (no con políticas de acceso) y protección contra purga activada.

Terraform, y las trampas específicas de Azure

Un estado por suscripción y capa, en una cuenta de almacenamiento de la suscripción de gestión, con versionado y un bloqueo de recurso sobre el contenedor. Autentica la CI con credenciales federadas OIDC sobre una identidad gestionada asignada por el usuario — sin secretos de cliente.

Dos comportamientos del proveedor que conviene saber: azurerm exige un bloque features {} y sus valores por defecto son opinados (el borrado suave y el purgado de Key Vault, en particular), y los bloqueos de recurso aplicados por política harán que tu terraform destroy falle en staging de una forma confusa la primera vez.

Aplican los mismos principios estructurales que en la landing zone de AWS; los mecanismos cambian pero la lógica del radio de explosión no. Desplegamos esto al inicio de casi todos los proyectos cloud.

Qué hacer esta semana

Abre la hoja de grupos de administración y mira dónde están asignadas tus políticas. Si la respuesta es "en suscripciones" o "en ningún sitio", el primer movimiento es una asignación en modo auditoría en la raíz que exija configuración de diagnóstico. En dos semanas te habrá dicho qué recursos son invisibles para tu logging.