Defender for Cloud dejó a Contoso Airlines con una lista de recomendaciones y una grieta evidente: detecta después. Alguien crea una máquina virtual enorme en una región equivocada y sin etiquetas, el recurso existe, factura y aparece expuesto; días más tarde una recomendación avisa y alguien tiene que ir a arreglarlo. Peor aún, quien lo hizo tenía todo el derecho: era Colaborador de la suscripción, que es exactamente el permiso que necesita para trabajar. RBAC no puede resolver esto, porque RBAC solo responde a quién. Lo que falta es un sistema que responda a qué, y ese es Azure Policy: las reglas del juego, aplicadas en el momento de crear el recurso, con independencia de quién lo cree. Con esta lección se cierra el módulo de seguridad y la plataforma pasa de estar asegurada a estar gobernada.

Aviso importante: las políticas de gobernanza y cumplimiento tienen efectos inmediatos y amplios —una política con efecto Deny mal delimitada puede detener despliegues legítimos en producción, y un Modify mal escrito puede alterar recursos en masa—. Además, el cumplimiento normativo real (PCI DSS, RGPD, ENS) va mucho más allá de lo que una herramienta evalúa. Antes de aplicar cualquier iniciativa de gobernanza en producción, debe revisarla un profesional de seguridad o el equipo de compliance de tu organización.

1. RBAC frente a Policy: quién puede frente a qué se puede
2. Anatomía de una definición de política
3. Los efectos y cuándo usar cada uno
4. Asignación, ámbito, exclusiones y recursos ya existentes
5. Iniciativas y las integradas de cumplimiento
6. El conjunto de políticas de Contoso
7. Evaluación de cumplimiento y tareas de corrección
8. Grupos de administración: la raíz de la gobernanza
9. De Blueprints a especificaciones de plantilla y zonas de aterrizaje
10. El coste de la gobernanza frente al de no tenerla
11. Policy e infraestructura como código
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

El ejemplo que lo explica todo. Diego Salas es Colaborador de rg-contoso-reservas-dev, un permiso perfectamente legítimo que le concedió Marta en 04-02. Con él crea una máquina virtual Standard_E64s_v5 en East US para una prueba de rendimiento, sin etiquetas. Nada de lo que ha hecho viola RBAC: tenía permiso para crear recursos.

El resultado, en cambio, es un problema en cuatro frentes: coste (unos 3.500 € al mes que nadie ha presupuestado), facturación (sin centro-coste, no se puede imputar a nadie), cumplimiento (datos que podrían acabar fuera de la UE) y operación (un recurso en una región que el equipo no monitoriza).

Se complementan y no se sustituyen: RBAC decide si puedes pulsar el botón; Policy decide qué es aceptable que salga de pulsarlo. Nótese la asimetría del modelo por defecto: en RBAC no puedes nada hasta que te lo conceden; en Policy puedes todo hasta que alguien lo restringe.

Elemento a elemento:

• mode: Indexed evalúa solo los tipos de recurso que admiten etiquetas y ubicación —es el correcto para regiones y etiquetas—; All incluye además grupos de recursos y suscripciones. Usar All cuando toca Indexed provoca falsos incumplimientos en recursos que no tienen ubicación real.
• parameters: hacen la política reutilizable. La lista de regiones se decide al asignar, no al definir, de modo que la misma política sirve para producción y para un futuro entorno en otra geografía.
• policyRule.if: las condiciones, combinables con allOf (Y) y anyOf (O), y anidables. Los operadores habituales son equals, notEquals, in, notIn, like, exists y contains.
• Las dos exclusiones del ejemplo no son adorno: muchos recursos tienen ubicación global (Front Door, Traffic Manager, DNS) y bloquearlos rompería la plataforma; y los grupos de recursos se excluyen porque su ubicación solo indica dónde se guardan sus metadatos.
• then.effect: qué hacer cuando la condición se cumple.

Dos diferencias que conviene grabar. Append frente a Modify: Append solo actúa al crear y no toca lo existente; Modify puede corregir recursos ya creados mediante tareas de corrección, y por eso es el que se usa para etiquetas. Deny frente a DeployIfNotExists: el primero rechaza y obliga a quien despliega a arreglarlo; el segundo acepta y arregla por su cuenta. Usa Deny para lo que no debe existir jamás y DeployIfNotExists para lo que siempre debe acompañar al recurso.

Los efectos Modify y DeployIfNotExists necesitan una identidad administrada en la asignación, porque Azure Policy tiene que actuar en tu nombre, y esa identidad necesita los roles correspondientes. Es la causa número uno de tareas de corrección que fallan.

Una definición no hace nada hasta que se asigna a un ámbito: grupo de administración, suscripción o grupo de recursos. La asignación se hereda hacia abajo, igual que RBAC, y admite exclusiones de subámbitos concretos.

El punto que más confusión genera: qué pasa con los recursos que ya existen.

• Un efecto Deny no elimina ni bloquea lo que ya está creado. Solo actúa sobre creaciones y modificaciones futuras. Un recurso preexistente que la incumple aparece como no conforme, y saltará el bloqueo la próxima vez que alguien intente modificarlo (efecto secundario que sorprende: una actualización rutinaria empieza a fallar).
• Los efectos Audit y AuditIfNotExists evalúan todo lo existente y lo reportan.
• Modify y DeployIfNotExists pueden arreglar lo existente, pero solo si se lanza una tarea de corrección explícita (apartado 7).

De ahí la secuencia de despliegue correcta, análoga a la del WAF en 04-04: asignar en Audit, medir el incumplimiento real, corregir lo existente, comunicar la fecha y solo entonces cambiar el efecto a Deny.

Una iniciativa (o conjunto de directivas) agrupa políticas que se asignan y se miden juntas. Ventajas: una sola asignación, parámetros compartidos y una única vista de cumplimiento. Contoso crea la iniciativa "Base de gobernanza de Contoso" con las seis políticas del apartado siguiente.

Azure trae iniciativas integradas para estándares completos: Microsoft Cloud Security Benchmark (asignada por defecto), PCI DSS 4.0, ISO 27001, CIS Azure Foundations, NIST SP 800-53 y el ENS español. Son la contrapartida del panel de cumplimiento de Defender de la lección anterior: allí veías el resultado, aquí está el mecanismo que lo evalúa. Casi todas sus políticas son de tipo Audit, precisamente porque un estándar sirve para medir, no para bloquear despliegues.

Tres comentarios sobre este bloque. La política de etiquetas obligatorias se asigna cuatro veces porque la integrada acepta una etiqueta por asignación; el orden importa: la de herencia (Modify) debe evaluarse antes que la de exigencia, o los despliegues sin centro-coste serían rechazados en lugar de completados automáticamente. La asignación de herencia crea una identidad administrada con --mi-system-assigned y le da el rol Colaborador en el ámbito: sin eso, la política se asigna correctamente y la corrección falla siempre.

Faltan dos políticas más. La de tamaños de VM en desarrollo se asigna solo a la suscripción de desarrollo, porque en producción las restricciones son otras:

Y la de diagnóstico automático, el caso canónico de DeployIfNotExists, que resuelve de raíz la recomendación número 7 de Defender (04-05): en lugar de configurar catorce recursos a mano, la política los configura y configura también todos los futuros.

Azure Policy evalúa en tres momentos, y conviene conocerlos porque explican casi todas las dudas del tipo "he asignado la política y no pasa nada":

• Al crear o modificar un recurso: inmediato. Es cuando actúan Deny, Append y Modify.
• Al asignar o cambiar una política: se dispara una evaluación en unos 30 minutos.
• Ciclo periódico: cada 24 horas se reevalúa todo.

La corrección es lo que arregla lo ya existente. Solo aplica a Modify y DeployIfNotExists, y no es automática: hay que crear una tarea que recorre los recursos no conformes y les aplica el cambio usando la identidad administrada de la asignación.

Si failedDeployments es mayor que cero, la causa es casi siempre la misma: la identidad administrada de la asignación no tiene los permisos suficientes en algún subámbito. Se comprueba con az role assignment list --assignee <principalId de la asignación>.

Asignar políticas suscripción por suscripción no escala: cada suscripción nueva nace sin gobierno y alguien tiene que acordarse. Los grupos de administración son contenedores por encima de las suscripciones que permiten asignar políticas y RBAC una sola vez, heredándose hacia abajo.

El reparto que hace Contoso, y su lógica:

• En mg-contoso: lo innegociable para todo el mundo —regiones permitidas, etiquetas obligatorias, sin acceso público en almacenamiento, HTTPS y diagnóstico automático—. Nadie, en ninguna suscripción presente o futura, puede saltárselo.
• En mg-contoso-plataforma: reglas propias de la infraestructura compartida, como exigir que toda subred tenga NSG asociado.
• En mg-contoso-cargas: reglas de las aplicaciones, y bajo él la restricción de tamaños de VM que solo aplica a la suscripción de desarrollo.

Dos avisos prácticos. El grupo raíz del inquilino existe siempre y asignar ahí afecta a absolutamente todo, incluidas suscripciones que aún no existen; se toca con cuidado extremo y hace falta el rol de Administrador de grupos de administración. Y las exclusiones deben ser escasas y documentadas: una jerarquía llena de excepciones no gobierna nada.

Azure Blueprints fue el intento de empaquetar en un artefacto único plantillas ARM, asignaciones de políticas y asignaciones de rol. Está en desuso y no debe usarse en diseños nuevos. Su sustituto son dos piezas separadas y mejores:

• Especificaciones de plantilla: plantillas ARM o Bicep versionadas y almacenadas como recurso de Azure, compartibles con RBAC.
• Zonas de aterrizaje de Azure: la implementación de referencia del Cloud Adoption Framework, que despliega la jerarquía de grupos de administración, las políticas, la topología de red y la identidad como un conjunto coherente. Es hacia donde evoluciona lo que has montado hoy a mano, y se trata en la lección 09-04.

Azure Policy es gratuito: no se paga por definición, asignación, evaluación ni corrección. Lo que cuesta es el tiempo de diseñarlo y el rozamiento inicial cuando un despliegue se rechaza.

Frente a eso, el coste de no tenerla, con las cifras del ejemplo del apartado 1: la VM Standard_E64s_v5 en East US cuesta unos 3.500 € al mes y, sin centro-coste, no se imputa a nadie, con lo que aparece en el reparto general y nadie la reclama. Súmale el coste real de un incidente: una cuenta de almacenamiento con acceso público es una brecha de datos personales, y las sanciones del RGPD se miden en porcentaje de facturación. Toda la sección de gobernanza cuesta cero euros al mes; el primer recurso mal creado que evita paga con creces el tiempo invertido. Es, con diferencia, la mejor relación coste/beneficio del módulo, y por eso Nuria Peña la reclamará desde el módulo 8: sin centro-coste en cada recurso, no hay análisis de costes posible.

Podría parecer que si toda la infraestructura se define en Bicep con las etiquetas y las regiones correctas, Policy sobra. No es así, y la razón es la que ha aparecido todo el módulo: la plantilla protege lo que despliega la canalización, la política protege todo lo demás. Alguien creará un recurso desde el portal para "probar una cosa", una herramienta de terceros aprovisionará algo por su cuenta, o una canalización mal revisada desplegará en la región equivocada. Policy es la red de seguridad que no depende de la disciplina de nadie.

La forma correcta de combinarlos es en capas: la plantilla define la intención y hace fácil lo correcto; la política impide lo incorrecto venga de donde venga; y las propias definiciones y asignaciones de política se gestionan como código, versionadas en el repositorio y desplegadas por la canalización, no a golpe de portal. Cómo se hace eso con Bicep y Azure Pipelines es el contenido de las lecciones 05-03 y 05-06.

• Asignar Deny directamente en producción. Empieza en Audit, mide el incumplimiento, corrige, comunica y después bloquea.
• Olvidar la identidad administrada en Modify y DeployIfNotExists. La asignación se crea sin error y todas las correcciones fallan.
• Esperar que Deny limpie lo existente. Solo actúa sobre creaciones y modificaciones; lo existente se corrige con tareas de corrección.
• Impacientarse. La evaluación tarda unos 30 minutos tras asignar, y el ciclo completo 24 horas.
• Exigir etiquetas sin la política de herencia. Cada despliegue empieza a fallar y el equipo acaba pidiendo que se quite la política.
• Bloquear la ubicación global. Front Door, Traffic Manager y DNS dejan de poder crearse. Excluye siempre global y los grupos de recursos.
• Usar Blueprints en un diseño nuevo. Está en desuso; usa especificaciones de plantilla y zonas de aterrizaje.
• Llenar la jerarquía de exclusiones. Cada excepción es una grieta; documenta y revisa las pocas que sean inevitables.
• Consejo: prueba cada política nueva en rg-contoso-reservas-dev antes de subirla al grupo de administración. El radio de daño de una política mal escrita en la raíz es toda la empresa.
• Consejo: agrupa tus políticas propias en una iniciativa desde el principio. Diez asignaciones sueltas se vuelven inmanejables; una iniciativa se asigna, se parametriza y se mide de una vez.

"Contoso Millas" (centro-coste=CC-2077) tendrá su propia suscripción. Requisitos: solo West Europe; las cuatro etiquetas obligatorias con centro-coste heredado del grupo de recursos; ninguna base de datos accesible desde internet; diagnóstico enviado a log-contoso-pro; y VMs limitadas a Standard_D4s_v5 como máximo.

1. Indica para cada requisito el efecto adecuado y en qué ámbito de la jerarquía lo asignarías.
2. ¿Cuáles necesitan identidad administrada y qué rol le darías?
3. Describe el orden de despliegue para no bloquear al equipo el primer día.

Tras asignar la política de etiquetas obligatorias con efecto Deny en mg-contoso, la canalización nocturna de Contoso empieza a fallar con RequestDisallowedByPolicy y, además, 240 recursos preexistentes aparecen como no conformes.

1. ¿Por qué fallan los despliegues nuevos y qué falta en el diseño?
2. ¿Qué hay que hacer con los 240 recursos existentes, con los comandos?
3. Propón el orden correcto de asignación para que esto no hubiera ocurrido.

Indica el efecto (Audit, Deny, Modify, DeployIfNotExists, DenyAction) y justifícalo:

1. Toda cuenta de almacenamiento nueva debe exigir TLS 1.2 como mínimo.
2. Todo recurso debe tener la etiqueta propietario; si falta, hay que ponerla con el valor del grupo de recursos.
3. Toda base de datos SQL debe tener auditoría activada enviándola a Log Analytics.
4. Se quiere saber cuántas VMs carecen de copia de seguridad, sin cambiar nada todavía.
5. Nadie debe poder eliminar kv-contoso-pro, ni siquiera un Propietario.

Solución 1:

1. Regiones: Deny, en el grupo de administración que contenga la suscripción de Millas (o en mg-contoso si el resto de la empresa comparte la restricción; como aquí es solo West Europe, se asigna a nivel de la suscripción con su parámetro propio). Etiquetas obligatorias: Deny en la suscripción. Herencia de centro-coste: Modify en la suscripción. Bases de datos sin acceso público: Deny en la suscripción. Diagnóstico: DeployIfNotExists, mejor en mg-contoso porque aplica a toda la empresa. Tamaños de VM: Deny en la suscripción.
2. Las de Modify (herencia de etiqueta) y DeployIfNotExists (diagnóstico). Rol: Colaborador en el ámbito de la asignación, o mejor uno más estrecho —Colaborador de etiquetas para la primera y Colaborador de supervisión más Colaborador de Log Analytics para la segunda—, aplicando el mínimo privilegio de 04-02.
3. Primero las de Audit y las de Modify/DeployIfNotExists con sus tareas de corrección, para que la plataforma se ponga al día sola. Después medir el cumplimiento durante unos días. Después comunicar al equipo la fecha de entrada en vigor. Y solo entonces cambiar a Deny los efectos de regiones, etiquetas, acceso público y tamaños.

Solución 2:

1. Porque la canalización crea recursos sin la etiqueta centro-coste, y con Deny la petición se rechaza entera. Falta la política de herencia con efecto Modify, que debería completar la etiqueta desde el grupo de recursos antes de que la de exigencia evalúe; también falta haber pasado por una fase de Audit que hubiera revelado el problema sin cortar nada.
2. Los Deny no los tocan: siguen existiendo, marcados como no conformes, pero fallarán la próxima vez que alguien los modifique. Se arreglan asignando la política de herencia con identidad administrada y lanzando az policy remediation create -n corrige-etiquetas --policy-assignment hereda-centro-coste --resource-discovery-mode ExistingNonCompliant --scope /subscriptions/$SUB, y comprobando después deploymentSummary.failedDeployments. Los recursos cuyo grupo tampoco tenga la etiqueta habrá que etiquetarlos a mano o etiquetar antes los grupos de recursos.
3. (a) Asignar la de herencia (Modify) y ejecutar su corrección. (b) Asignar la de etiquetas en Audit y medir durante una o dos semanas. (c) Corregir manualmente lo que quede y avisar al equipo con fecha. (d) Cambiar el efecto a Deny. Es la misma secuencia detectar-analizar-corregir-aplicar del WAF en 04-04, y por el mismo motivo.

Solución 3:

1. Deny: es una propiedad conocida en el momento de crear, no hay razón para aceptar una cuenta insegura y el requisito es innegociable por PCI DSS. Se acompaña de una fase previa en Audit si ya hay cuentas creadas.
2. Modify: añade la etiqueta que falta y, a diferencia de Append, puede corregir los recursos existentes con una tarea de corrección. Requiere identidad administrada.
3. DeployIfNotExists: la auditoría es un recurso relacionado (una configuración de diagnóstico) que hay que crear, no una propiedad de la base. Requiere identidad administrada con permisos sobre el área de trabajo.
4. AuditIfNotExists: solo se quiere medir la ausencia de un recurso relacionado (el elemento de copia de seguridad) sin desplegar nada ni bloquear. Es la fase previa natural antes de decidir si se pasa a DeployIfNotExists.
5. DenyAction sobre la operación de eliminación, complementado con un bloqueo de recurso CanNotDelete (01-05) y con la protección contra purga del propio almacén (04-03). Tres capas para el mismo objetivo, porque perder un Key Vault con claves de cifrado es irreversible.

Con esta lección se cierra el módulo 4, y conviene ver lo que ha cambiado. Sabes distinguir lo que RBAC no puede resolver: RBAC responde a quién puede hacer algo y Azure Policy a qué se puede hacer, con modelos por defecto opuestos —RBAC deniega hasta que concedes; Policy permite hasta que restringes—. Has diseccionado una definición de política con su mode, sus parámetros, sus condiciones y sus efectos, y sabes cuándo usar cada uno: Audit para descubrir, Deny para lo innegociable, Append y Modify para completar valores —con la diferencia de que solo Modify arregla lo existente—, DeployIfNotExists y AuditIfNotExists para recursos relacionados, y Disabled para pausar. Entiendes que un Deny no limpia lo ya creado, que la evaluación tarda unos 30 minutos tras asignar y 24 horas en su ciclo completo, y que las tareas de corrección son las que ponen al día la plataforma, siempre que la asignación tenga su identidad administrada con los permisos correctos.

Has implementado el conjunto de políticas de Contoso: regiones limitadas a West Europe y North Europe, las cuatro etiquetas obligatorias con centro-coste heredado del grupo de recursos, prohibición de acceso público en el almacenamiento, HTTPS y TLS mínimo, tamaños de VM acotados en desarrollo y despliegue automático del diagnóstico hacia log-contoso-pro —que resuelve de raíz, y también para el futuro, una de las recomendaciones que Defender sacó en 04-05—. Todo ello colgando de una jerarquía de grupos de administración (mg-contoso → mg-contoso-plataforma y mg-contoso-cargas) que hace que ninguna suscripción futura nazca sin gobierno. Sabes que Blueprints está en desuso y que su lugar lo ocupan las especificaciones de plantilla y las zonas de aterrizaje del Cloud Adoption Framework (09-04), que Policy es gratuito mientras que un solo recurso mal creado cuesta miles de euros, y que la infraestructura como código y la política son capas complementarias: la plantilla hace fácil lo correcto, la política impide lo incorrecto venga de donde venga.

Recapitulando el módulo entero: la plataforma de Contoso Airlines entró con contraseñas escritas a mano y sale gobernada. Las identidades viven en Microsoft Entra ID con grupos, MFA, acceso condicional, PIM y una cuenta de emergencia excluida. Los permisos son mínimos y se asignan a grupos, con roles de datos separados del plano de gestión y un rol personalizado para operaciones. No queda un solo secreto en el código ni en el despliegue: las identidades administradas eliminaron los que podían desaparecer y kv-contoso-pro custodia los que no, con referencias @Microsoft.KeyVault(...) que la aplicación resuelve sola. El perímetro está protegido con el WAF de fd-contoso-global, sus reglas OWASP y de bots, la limitación de velocidad y un guion de respuesta ante ataques, con las decisiones de coste de DDoS argumentadas y no improvisadas. La postura se vigila sola con Defender for Cloud, su puntuación, sus recomendaciones priorizadas, sus alertas y su panel de PCI DSS. Y las reglas del juego ya no dependen de que alguien se acuerde: están escritas como política y se aplican en el momento de crear cada recurso.

Queda, sin embargo, algo que este módulo ha dejado en evidencia sin decirlo. Todo lo que has construido en cuatro módulos se ha desplegado a mano, comando a comando, desde la CLI. Funciona, pero no escala, no es reproducible, no hay forma de saber quién cambió qué ni de volver atrás si algo se rompe, y no habría manera de recrear esta plataforma en otra región tras un desastre. La misma disciplina que has aplicado hoy a la gobernanza hay que aplicarla a la entrega. En el módulo 5, Azure DevOps, montarás el ciclo completo: Azure Repos para versionar el código y también las plantillas, Azure Pipelines para construir y probar en cada cambio, despliegue continuo con entornos y aprobaciones para llegar a producción sin miedo, Azure Artifacts para los paquetes compartidos y, cerrando el círculo, infraestructura como código con Bicep, donde toda esta plataforma —redes, aplicaciones, bases de datos, políticas incluidas— deja de ser una colección de comandos ejecutados una vez y pasa a ser código revisable, versionado y repetible. Nos vemos allí.