Azure Policy como código: el patrón de despliegue que no provoca caídas

Azure Policy puede hacer algo que las otras nubes no hacen con la misma limpieza: evaluar un recurso en el momento de su creación y rechazarlo, o desplegar automáticamente una configuración que falta. Es una ventaja real frente a detectar la mala configuración a posteriori y abrir un ticket.

También es el mecanismo con más probabilidad de romper un despliegue del viernes, porque un Deny asignado en el grupo de administración raíz se aplica a todo de inmediato, incluido el pipeline de un equipo que no ha oído hablar de ti.

Los efectos, y para qué sirve cada uno

• Audit — registra el incumplimiento, no cambia nada. Donde empieza toda política.
• Deny — bloquea la creación o actualización. Para el pequeño conjunto de cosas que nunca deben existir: acceso público a blobs, endpoints SQL públicos, recursos fuera de las regiones permitidas, recursos de producción sin etiquetar.
• DeployIfNotExists — crea un subrecurso que falta. El efecto más útil en la práctica: configuración de diagnóstico hacia el workspace central, planes de Defender en una suscripción nueva, copia de seguridad en una VM de producción.
• Modify — añade o cambia propiedades, típicamente etiquetas heredadas del grupo de recursos.
• AuditIfNotExists — audita la ausencia de un recurso relacionado. Úsalo como gemelo en modo auditoría de un DeployIfNotExists mientras evalúas.

Un error común es recurrir a Deny cuando la intención es un valor por defecto. Si quieres que todas las cuentas de almacenamiento tengan TLS 1.2 mínimo, Modify lo fija y no se bloquea a nadie. Deny bloquea el despliegue y alguien tiene que cambiar su plantilla. Ambas son legítimas; se diferencian en quién hace el trabajo.

La secuencia de despliegue

1. Escribe la política en Terraform o Bicep, en un repositorio con revisión. Las definiciones creadas en el portal son invisibles para tu proceso de cambios y derivarán.

2. Asigna en un grupo de administración, en modo Audit, en el ámbito donde la regla pertenece de verdad. Una regla sobre producción pertenece a la rama de producción, no a la raíz con treinta exclusiones.

3. Espera dos semanas y lee los datos de cumplimiento. El porcentaje de cumplimiento te dice cuán grande es el cambio. Por debajo del 90 por ciento, pasar a Deny bloqueará trabajo real; cerca del 100 por ciento significa que la regla ya es como se comportan tus equipos y la imposición sale gratis.

4. Remedia los recursos no conformes existentes. Para DeployIfNotExists y Modify, una tarea de remediación lo resuelve en masa con una identidad gestionada. Hazlo antes de imponer, para que el Deny se aplique sobre un entorno ya conforme.

5. Pasa a Deny, una política cada vez, y avisa antes a los equipos afectados. Con un camino de excepción documentado — las exenciones de Azure Policy son un objeto de primera clase con fecha de caducidad y motivo, mucho mejor que una exclusión permanente que nadie recuerda haber concedido.

6. Observa quince días y pasa a la siguiente.

Iniciativas, no políticas sueltas

Agrupa las políticas relacionadas en una iniciativa (conjunto de políticas) y asigna la iniciativa. Treinta políticas asignadas por separado producen una vista de cumplimiento que nadie puede leer y treinta cosas que mover cuando cambie el ámbito. Parte de las iniciativas integradas —el Azure Security Benchmark, CIS, ISO 27001— y añade tus definiciones propias al lado en lugar de reconstruirlas.

Usa bien los parámetros. Una iniciativa con un parámetro allowedRegions asignada de forma distinta por rama gana a cuatro iniciativas casi idénticas.

Pruebas

Las políticas tienen una historia de pruebas real y casi nadie la usa. az policy state trigger-scan fuerza una evaluación en lugar de esperar al ciclo periódico. Un despliegue what-if contra una asignación en una suscripción de pruebas te dice si una plantilla sería denegada. Y una suscripción de pruebas dedicada dentro de tu grupo de administración de producción —ejecutando tus plantillas de despliegue reales— es el entorno de pruebas de mayor valor para el trabajo de políticas, porque pilla el caso en que tu política de producción bloquea tu pipeline de producción.

Exenciones con caducidad, no exclusiones

Las exclusiones de ámbito son permanentes e invisibles. Las exenciones llevan motivo y fecha de caducidad y aparecen en los informes de cumplimiento como una decisión explícita. Usa exenciones, ponles caducidad y revísalas cada trimestre. Un entorno con veinte exenciones caducadas te está diciendo algo; uno con veinte exclusiones de ámbito no te dice nada.

Esta es la maquinaria bajo la landing zone de Azure, y es lo que marca la diferencia entre un modelo de gobernanza en una diapositiva y uno en el proveedor de recursos. También es lo que impide que las recomendaciones de Defender vuelvan después de remediarlas. Lo desplegamos como parte de un proyecto de seguridad.

Qué hacer esta semana

Elige la regla que más te gustaría que fuera cierta en todo tu entorno —probablemente "ninguna cuenta de almacenamiento permite acceso público a blobs"— y asígnala en modo Audit en tu grupo de administración de producción. En dos semanas el número de cumplimiento te dirá si imponerla es un clic o un proyecto.