Gobernanza con Azure Policy: definiciones, efectos, cumplimiento e implementación segura

radio_button_uncheckedshort_text1. Azure Policy y el objetivo de gobernanza

Azure Policy convierte los estándares organizacionales en definiciones que Azure puede asignar, evaluar e informar a escala. Una definición se expresa en JSON, compara las propiedades del recurso o el contexto de la solicitud con las reglas comerciales y aplica un efecto como auditar, denegar, modificar o implementar. Esto hace que la gobernanza sea repetible en lugar de depender de una revisión manual de cada recurso.

Una iniciativa, también llamada conjunto de políticas, agrupa varias definiciones bajo un resultado. Las iniciativas simplifican la asignación y la generación de informes para objetivos como una línea base de seguridad, un etiquetado obligatorio o un marco regulatorio. Las iniciativas integradas y personalizadas se pueden superponer para crear barreras de seguridad para entornos regulados, financieros y de otro tipo, incluidos controles centrados en la soberanía y mapeos de cumplimiento.

• Asigne una política que controle los recursos creados en el futuro.
• Cree y asigne una iniciativa para que se realice un seguimiento de muchas definiciones como un objetivo de cumplimiento.
• Investigue y resuelva un recurso denegado o notificado como no conforme.
• Implemente una nueva directiva en toda la organización con exposición controlada y resultados medibles.

Azure Policy es un control técnico, no un asesoramiento legal. Cada organización sigue siendo responsable de identificar las leyes aplicables, validar su implementación y consultar a profesionales legales y de cumplimiento calificados.

radio_button_uncheckedshort_text2. Cloud Adoption Framework y gobernanza continua

El Microsoft Cloud Adoption Framework para Azure proporciona orientación, herramientas, documentación y prácticas de extremo a extremo para la estrategia, planificación, preparación, adopción, gobernanza, seguridad y gestión de la nube. En la metodología Govern, la gobernanza de la nube significa controlar el uso aceptable de la nube a través de barreras de seguridad documentadas que respaldan los resultados comerciales y al mismo tiempo reducen los riesgos regulatorios, de seguridad, operativos, de costos, de datos, de gestión de recursos y de IA.

La gobernanza no es una implementación única. La tecnología, las prioridades organizacionales, los modelos de amenazas y las regulaciones cambian. Por lo tanto, el marco establece primero la propiedad y repite la evaluación de riesgos, el mantenimiento de políticas, la aplicación y el monitoreo como un ciclo operativo continuo.

radio_button_uncheckedshort_text3. Los cinco pasos de la gobernanza de la nube

1. Cree un equipo de gobierno de la nube. Ofrezca a un equipo dedicado la responsabilidad de la propiedad, el mantenimiento, la participación de las partes interesadas, las métricas y los informes de las políticas.
2. Evalúe los riesgos de la nube. Evalúe los riesgos regulatorios, de seguridad, operativos, de costos, de datos, de recursos y de IA en el propio contexto de la organización.
3. Documente las directivas de gobernanza. Indique el uso aceptable de la nube, el alcance, la justificación, el responsable, la aplicación, las excepciones y las reglas que reducen cada riesgo importante.
4. Aplique las directivas de gobernanza. Combine barreras automatizadas con controles manuales cuando la automatización no sea adecuada y haga explícita la responsabilidad de los equipos de plataforma y de carga de trabajo.
5. Supervise la gobernanza de la nube. Establezca una línea de base de cumplimiento, detecte infracciones y desviaciones, mida la eficacia de las políticas e introduzca los hallazgos en la siguiente revisión de políticas y riesgos.

Complete los cinco pasos para establecer el modelo operativo. Después, revise periódicamente los pasos del 2 al 5. La supervisión sin un responsable de corrección produce informes, pero no gobernanza; la aplicación sin contexto de riesgo puede bloquear trabajo legítimo.

radio_button_uncheckedshort_text4. Del riesgo empresarial a las disciplinas de gobernanza

Una política de gobierno corporativo comienza con el riesgo empresarial y la tolerancia al riesgo, informados por la clasificación de datos y la criticidad de las aplicaciones. Las decisiones de riesgo se convierten en declaraciones de políticas inequívocas y los procesos definen cómo se detectan, escalan, corrigen, aceptan y revisan las infracciones.

El Cloud Adoption Framework actual también trata el cumplimiento normativo, las operaciones, la administración de datos, el aprovisionamiento de recursos y la IA como dominios explícitos de gobernanza. Las cinco disciplinas siguen siendo un modelo de estudio útil, pero un programa real debe cubrir toda la cartera de riesgos.

radio_button_uncheckedshort_text5. Qué puede gobernar Azure Policy

Azure Policy proporciona definiciones centralizadas, asignaciones, resultados de cumplimiento, investigación de cambios y corrección. Su panel agrega el entorno y permite profundizar por asignación, definición y recurso. Como Azure Policy está integrado en la plataforma, una barrera automatizada puede sustituir con seguridad determinados pasos de aprobación manual.

• Restrinja la implementación a regiones aprobadas e implemente barreras de residencia de datos.
• Permita solo tamaños de máquinas virtuales o tipos de recursos aprobados.
• Exija y, con el efecto correcto, agregue o herede etiquetas estandarizadas como AppName.
• Audite el cifrado, la configuración de diagnóstico, las actualizaciones, la configuración de red y las líneas base de seguridad.
• Exija que los datos de diagnóstico se envíen a un área de trabajo de Registros de Azure Monitor.
• Evalúe los recursos existentes, así como los recursos creados o redimensionados después de asignar la política.
• Conecte prácticas de directiva como código con flujos de trabajo de Azure DevOps o GitHub antes y después de la implementación.

La exportación menciona la autenticación multifactor para cuentas de suscripción como ejemplo de política. En la arquitectura actual, Acceso Condicional de Microsoft Entra es el control principal para requerir autenticación multifactor; Azure Policy gobierna principalmente las propiedades de recursos de Azure y las acciones de recursos admitidas. Utilice el plano de control correcto para cada requisito.

El diseño de directivas equilibra el control y la estabilidad con la velocidad de entrega y los resultados empresariales. Pruebe el efecto, estime el impacto operativo, proporcione mensajes de incumplimiento comprensibles y defina un proceso de exención controlado antes de una aplicación amplia.

radio_button_uncheckedshort_text6. Jerarquía, alcance y herencia de la gobernanza

Azure proporciona una jerarquía de grupos de administración, suscripciones, grupos de recursos y recursos bajo el grupo raíz de inquilino. Un recurso pertenece a un grupo de recursos; una suscripción es un límite de administración, facturación, cuota y escala; y los grupos de administración organizan suscripciones para aplicar acceso y directivas de forma coherente a escala empresarial.

Las asignaciones de un ámbito superior se aplican a los descendientes elegibles, salvo que un elemento secundario esté excluido o exento. Una directiva asignada a una suscripción puede afectar a sus grupos de recursos y recursos; una asignación en un grupo de recursos no afecta automáticamente a un grupo vecino. Los grupos de administración pueden extenderse seis niveles por debajo del grupo raíz de inquilino.

Una definición de política o iniciativa se almacena en una ubicación de definición: un grupo de administración o una suscripción. Sólo se puede asignar a ese contenedor o a sus descendientes. Coloque una definición reutilizable en la ubicación más baja que aún contenga todos los alcances de asignación previstos.

radio_button_uncheckedshort_text7. Azure Resource Manager, plano de control y plano de datos

Azure Resource Manager es la capa de implementación y administración para crear, actualizar y eliminar recursos de Azure. Microsoft Azure Portal, Azure PowerShell, CLI de Azure, las API REST y los SDK de cliente usan las API de Resource Manager, que autentican y autorizan la solicitud antes de enviarla al proveedor de recursos adecuado.

Las implementaciones de plantillas, control de acceso basado en rol de Azure (RBAC de Azure), auditoría, monitoreo, etiquetado y evaluación de Azure Policy en modo Administrador de recursos participan en el plano de control. RBAC de Azure se evalúa antes que Azure Policy: si la persona que llama no está autorizada para realizar la operación, la solicitud falla antes de la evaluación de la política.

El plano de datos maneja datos de servicio directamente, como cargar un blob, consultar una base de datos o leer un secreto de Azure Key Vault. Estas llamadas utilizan puntos finales de servicio y RBAC específicos del servicio o listas de control de acceso en lugar de pasar por el plano de control de Resource Manager. Los modos de política del proveedor de recursos extienden Azure Policy a planos de datos de servicio seleccionados.

radio_button_uncheckedshort_text8. Modos de proveedor de recursos y escenarios de plano de datos admitidos

A menos que la documentación indique explícitamente lo contrario, los modos de proveedor de recursos solo admiten definiciones integradas y no admiten exenciones a nivel de componente. El estado del producto puede cambiar, así que verifique el modo y el soporte de efectos antes de diseñar un control.

radio_button_uncheckedshort_text9. Flujos de evaluación de Greenfield y Brownfield

En un flujo Greenfield, o policy-first, ya existe una asignación cuando se crea o actualiza un recurso. Después de la autorización, Azure Policy evalúa el estado previsto. Si una actualización contiene solo un delta, el servicio lee el recurso actual, combina ese estado con los cambios solicitados y evalúa el estado de destino resultante.

En un flujo Brownfield, o resource-first, los recursos ya existen cuando se introduce una asignación. Un examen de cumplimiento lee los recursos aplicables y registra su estado. Una directiva deny que solo permita Oeste de Europa no elimina recursos existentes en otras ubicaciones; los marca como no conformes y bloquea posteriores solicitudes incompatibles de creación o actualización.

radio_button_uncheckedshort_text10. Los seis tipos de recursos de Azure Policy

radio_button_uncheckedshort_text11. Iniciativas, asignaciones y controles de implementación

Los proveedores de recursos de Azure ofrecen definiciones e iniciativas integradas. Las personalizadas cubren requisitos sin un elemento integrado adecuado. Microsoft for Sovereignty publica iniciativas y asignaciones de cumplimiento adicionales que una organización puede combinar con elementos integrados después de validar sus propias obligaciones.

Las asignaciones se pueden crear mediante el portal, una API, Azure PowerShell o CLI de Azure. Además del ámbito y la definición de destino, una asignación puede incluir parámetros, versión de definición, selectores de recursos para exposición progresiva, invalidaciones de efecto o versión, enforcementMode, ámbitos excluidos en notScopes, mensajes de incumplimiento e identidad administrada para la corrección con modify o deployIfNotExists.

• Los selectores de recursos incluyen gradualmente recursos por propiedades como ubicación o tipo sin cambiar el alcance de la asignación.
• Las anulaciones cambian un efecto permitido o una versión de definición para referencias seleccionadas sin editar la iniciativa subyacente.
• Una exclusión elimina a un descendiente del alcance de la asignación; una exención es un recurso secundario independiente que documenta una excepción aprobada.
• Los parámetros permiten que la misma definición aplique diferentes valores comerciales en diferentes asignaciones.
• La identidad administrada asignada por el sistema o por el usuario proporciona los permisos necesarios para los efectos de corrección.

radio_button_uncheckedshort_text12. Exenciones, atestaciones y corrección

Una exención se crea después de la asignación y puede abarcar una jerarquía o un recurso. El elemento exento permanece en los resultados agregados, pero la asignación no lo evalúa. Use Mitigated cuando otro control satisfaga la intención de la directiva y Waiver cuando se acepte temporalmente el incumplimiento. Registre responsable, justificación, vencimiento y control compensatorio.

El efecto manual depende de atestaciones. Cada recurso aplicable necesita una atestación por asignación manual, por lo que la definición debe dirigirse a un ámbito cuyo límite coincida con el modelo de evidencia y propiedad.

Una tarea de corrección lleva recursos existentes al cumplimiento mediante modify o deployIfNotExists. Los recursos aplicables nuevos o actualizados se pueden corregir automáticamente; los existentes requieren detección y una tarea. La identidad de la asignación ejecuta las operaciones, por lo que solo debe recibir los roles necesarios. Una tarea deployIfNotExists puede iniciarse incluso cuando enforcementMode es DoNotEnforce.

radio_button_uncheckedshort_text13. Anatomía de una definición de Azure Policy

En los modos de Resource Manager, all evalúa suscripciones, grupos de recursos y todos los tipos de recurso. Indexed solo evalúa tipos que admiten etiquetas y ubicación. El export describe incorrectamente ambos modos de la misma manera; la guía actual recomienda all en la mayoría de los casos e indexed principalmente para reglas de etiqueta o ubicación. Si la regla se dirige a suscripciones o a los propios grupos de recursos, use all y pruebe explícitamente el tipo correspondiente.

Una versión de definición usa Major.Minor.Patch. Una versión principal puede introducir cambios incompatibles; una secundaria puede agregar comportamientos o valores compatibles; y un parche normalmente cambia textos o metadatos. Considere los indicadores preview y deprecated antes de asignar en producción.

radio_button_uncheckedshort_text14. Regla de directiva, alias, operadores lógicos y condiciones

El bloque if puede inspeccionar un campo mediante un alias de Azure Policy, comparar un valor calculado o contar miembros de una matriz. Los campos comunes incluyen name, fullName, kind, type, location, id, identity.type, tags, etiquetas con nombre y alias específicos del proveedor. Los alias de matriz y las expresiones count permiten evaluar cada miembro relevante.

Un error de función o expresión puede hacer que la evaluación falle y puede producir una denegación implícita durante la evaluación en el momento de la solicitud. Pruebe con enforcementMode deshabilitado, valide tipos y valores vacíos y mantenga legibles las expresiones complejas.

{
  "properties": {
    "displayName": "Limit workload regions",
    "mode": "Indexed",
    "parameters": {
      "approvedRegions": { "type": "Array" }
    },
    "policyRule": {
      "if": {
        "allOf": [
          { "field": "location", "notIn": "[parameters('approvedRegions')]" },
          { "field": "location", "notEquals": "global" }
        ]
      },
      "then": { "effect": "deny" }
    }
  }
}

Este ejemplo original mantiene los recursos ubicados globalmente fuera del control regional. Una definición de producción también debe tener en cuenta los tipos de recursos cuya semántica de ubicación difiere y debe probarse con recursos representativos.

radio_button_uncheckedshort_text15. Funciones de directiva

Las reglas pueden usar muchas funciones de plantilla de Azure Resource Manager, pero las funciones definidas por el usuario y determinadas excepciones específicas no están disponibles. En Azure Policy, utcNow() se puede usar fuera de defaultValue y devuelve la marca de tiempo UTC actual en formato ISO 8601.

radio_button_uncheckedshort_text16. Efectos y orden de evaluación

En solicitudes de Resource Manager, Azure Policy comprueba disabled primero; después procesa efectos que cambian la solicitud, como append y modify; y luego deny, audit y los demás efectos aplicables. auditIfNotExists y deployIfNotExists se ejecutan después de que el proveedor de recursos responde correctamente. Varias asignaciones se evalúan de forma independiente, y el resultado combinado es acumulativo y normalmente el más restrictivo.

audit, deny y modify o append suelen compartir una definición parametrizada. auditIfNotExists y deployIfNotExists son alternativas que se combinan con frecuencia. manual no es intercambiable, mientras que disabled puede desactivar cualquier efecto parametrizado.

radio_button_uncheckedshort_text17. Desencadenantes y momento de la evaluación

• Se asigna recientemente una política o iniciativa o se actualiza una asignación existente.
• Un recurso se crea o actualiza a través de Azure Resource Manager, REST o un SDK compatible.
• Una suscripción se crea o mueve dentro de una jerarquía de grupos de administración cubierta por una asignación.
• Se crea, actualiza o elimina una exención.
• La configuración de la máquina envía detalles de cumplimiento actualizados.
• El ciclo de cumplimiento recurrente estándar se ejecuta, normalmente, una vez cada 24 horas.
• Un administrador o una automatización inicia un análisis bajo demanda.

El export indica que una nueva asignación puede tardar hasta 30 minutos en surtir efecto y sugiere cerrar sesión y volver a iniciarla para actualizar la caché de Resource Manager. La documentación actual ofrece expectativas más concretas: una asignación suele tardar unos cinco minutos en aplicarse antes de que comience la evaluación; el resultado de una creación o actualización puede aparecer unos 15 minutos después; y una evaluación dirigida a una suscripción puede tardar alrededor de 30 minutos. Un ámbito grande no tiene plazo fijo de finalización, y la reautenticación no es una garantía de nivel de servicio.

La complejidad de la definición, la cantidad de asignaciones, el tamaño del ámbito, la carga del sistema y la baja prioridad del examen de cumplimiento afectan la duración. Consulte el portal, Registros de Azure Monitor, Azure Resource Graph, PolicyStates y PolicyEvents en lugar de dar por terminada la evaluación solo por el tiempo transcurrido.

az policy state trigger-scan --resource-group "example-rg"
Start-AzPolicyComplianceScan -ResourceGroupName 'example-rg'

CLI de Azure y Azure PowerShell pueden iniciar exámenes a petición. GitHub Actions también puede activar un examen de cumplimiento y usar el resultado como criterio de aprobación del flujo de trabajo.

radio_button_uncheckedshort_text18. Estados y resultados de cumplimiento agregados

Los resultados agregados clasifican los estados para que prevalezca el más significativo; por eso, un resultado no conforme puede dominar varios resultados conformes dentro de una iniciativa. No registrado y No iniciado no se incluyen en estos cálculos.

El porcentaje de cumplimiento general actual se calcula como (Cumple + Exento + Desconocido + Protegido) dividido por (Cumple + Exento + Desconocido + No cumple + En conflicto + Error + Protegido). Examine siempre los recuentos y el alcance de la asignación junto con el porcentaje para que las exclusiones y los estados manuales no oculten el riesgo.

radio_button_uncheckedshort_text19. enforcementMode y una fase segura de simulación

enforcementMode es una propiedad de la asignación. Enabled se corresponde con el valor JSON Default: aplica el efecto seleccionado, admite corrección manual y puede crear entradas en el registro de actividad. Disabled se corresponde con DoNotEnforce: la definición sigue evaluando e informando el cumplimiento, pero no ejecuta el efecto ni escribe su entrada en el registro de actividad.

Esto difiere del efecto disabled. Una definición cuyo efecto sea disabled no se evalúa; una asignación con enforcementMode deshabilitado sí se evalúa como simulación. Si se omite enforcementMode, se aplica Default.

radio_button_uncheckedshort_text20. Implementación segura con anillos y políticas como código

Trate las definiciones y asignaciones como código: controle sus versiones, revise los cambios por pares, pruebe recursos representativos, automatice la validación y promueva por entornos controlados. Inicie las asignaciones de alto impacto, como deny y modify, con enforcementMode deshabilitado; después amplíe la exposición mediante anillos de implementación.

1. Cree y valide la definición en una ubicación de definición adecuada.
2. Cree una asignación con selectores de recursos para el primer anillo pequeño que no sea de producción y configure enforcementMode en DoNotEnforce.
3. Verifique tanto los resultados de cumplimiento como el estado de la aplicación; Los falsos positivos y las regresiones operativas son modos de falla separados.
4. Repita las comprobaciones para cada anillo que no sea de producción y actualice la definición o asignación cuando sea necesario.
5. Habilite la aplicación del efecto para un anillo validado y repita las comprobaciones de cumplimiento y estado.
6. Progrese a través de los anillos restantes que no son de producción.
7. Amplíe gradualmente a producción, comenzando con el subconjunto más pequeño y menos crítico.
8. Supervise los cambios de estado, las correcciones, las señales de soporte y el impacto empresarial durante toda la implementación.

Los selectores de recursos y las anulaciones de asignaciones admiten una implementación gradual sin duplicar definiciones. Mantenga un procedimiento de reversión de emergencia o anulación de efectos y documente quién puede aprobarlo.

radio_button_uncheckedshort_text21. Reacción a cambios de estado con Cuadrícula de Eventos

Azure Policy puede publicar cambios de estado mediante Cuadrícula de Eventos para que las aplicaciones reaccionen sin sondeos ineficientes. Una suscripción de Cuadrícula de Eventos administra enrutamiento, filtrado, reintentos, multidifusión y entrega en cola de mensajes fallidos al destino configurado.

Los controladores de eventos pueden incluir Azure Functions, Aplicaciones lógicas (Logic Apps), servicios Azure compatibles, escuchas HTTP personalizados y webhooks. Mantenga el controlador idempotente, autentíquelo, valide el alcance del evento, registre los datos de correlación y separe una alerta de una corrección aprobada automáticamente.

radio_button_uncheckedshort_text22. Verificación de conocimientos explicada

radio_button_uncheckedshort_text23. Resumen, recuperación activa y recursos oficiales

• Conecte las decisiones políticas con el riesgo empresarial, una propiedad clara, una aplicación, un seguimiento y un ciclo de revisión.
• Coloque definiciones y asignaciones en ámbitos que proporcionen herencia deliberada sin radios de explosión innecesarios.
• Comprenda la evaluación de solicitudes del plano de control, las extensiones del plano de datos y la diferencia entre flujos que priorizan las políticas y los recursos.
• Utilice definiciones, iniciativas, asignaciones, exenciones, atestaciones y correcciones para distintas responsabilidades de gobernanza.
• Cree reglas a partir de alias, condiciones, funciones y efectos, y pruebe errores de funciones y casos extremos.
• Observe los estados de cumplimiento actuales y los plazos en lugar de asumir que la asignación significa una evaluación completa inmediata.
• Comience con DoNotEnforce, valide el cumplimiento y el estado de las aplicaciones y promueva a través de anillos de implementación.
• Utilice Cuadrícula de Eventos para reacciones oportunas mientras conserva los controles de aprobación, identidad y auditoría.

Ejercicios de recuperación activa

• Dibuje el flujo completo de una solicitud de administración por RBAC de Azure, Azure Policy, Azure Resource Manager, un proveedor de recursos, datos de cumplimiento y corrección.
• Diseñe una iniciativa para regiones permitidas, etiquetas obligatorias, configuraciones de diagnóstico y protección contra eliminación accidental. Identifique el efecto, el alcance, los parámetros, las exclusiones y los anillos de implementación para cada definición.
• Explique la diferencia entre notScopes, exenciones, enforcementMode, effect: disabled y una atestación manual sin consultar el artículo.
• Compare las evaluaciones Greenfield y Brownfield e indique qué desencadenante actualiza el cumplimiento en cada escenario.

• ¿Qué es Azure Policy?
• Gobernanza en Cloud Adoption Framework
• Conceptos básicos de la estructura de definición de Azure Policy
• Conceptos básicos de los efectos de Azure Policy
• Estructura de asignación de Azure Policy
• Estados de cumplimiento de Azure Policy
• Obtener datos de cumplimiento de Azure Policy
• Implementación segura de asignaciones de Azure Policy
• Estructura de tareas de corrección de Azure Policy
• Eventos de cambio de estado de Azure Policy