¿Ese parche de seguridad que ignoraste el mes pasado? Es el que acaba de usar un atacante para acceder a sus máquinas virtuales de producción. Sabes que debes aplicar parches con regularidad. Su equipo de cumplimiento sabe que debe aplicar parches con regularidad. Ese informe de auditoría de hace tres meses definitivamente sabe que debes aplicar parches con regularidad.

El problema no es la conciencia, sino la ejecución. La aplicación de parches manuales no supera una docena de máquinas virtuales, y la antigua Azure Automation Update Management requería un espacio de trabajo de Log Analytics, una cuenta de automatización y más paciencia que la que poseen la mayoría de los equipos de TI.

Administrador de actualizaciones de Azure elimina esas dependencias. Es un servicio nativo de Azure que maneja la evaluación, programación e implementación de parches sin el impuesto de complejidad. Aquí se explica cómo configurarlo.

Lo que realmente estás construyendo

Antes de profundizar en los comandos, comprenda qué hace Azure Update Manager. Es un servicio centralizado que organiza la aplicación de parches en máquinas virtuales de Azure, servidores locales (a través de Arco Azul), e incluso máquinas AWS o Google Cloud. El servicio ejecuta análisis de cumplimiento periódicos cada 24 horas, almacena los resultados en Gráfico de recursos de Azure para consultas y respeta las ventanas de mantenimiento personalizadas que usted defina.

A diferencia de la solución heredada, Update Manager opera a través de extensiones: agentes livianos que interactúan con el administrador de paquetes nativo de su sistema operativo (Windows Update en Windows, apt/yum/zypper en Linux). No los instalas manualmente. Update Manager los implementa automáticamente cuando activa su primera evaluación o operación de parche.

Requisitos previos

Necesitas:

• Máquinas virtuales de Azure que ejecutan Windows Server 2012 R2 o posterior, o distribuciones de Linux compatibles (Ubuntu, RHEL, SUSE)

• CLI de Azure instalada localmente

• Acceso de colaborador a la suscripción de destino

• Para servidores locales: Agente de Azure Arc instalado (Update Manager cobra aproximadamente $5/servidor/mes para máquinas habilitadas para Arc a menos que esté ejecutando Defender for Servers Plan 2, Azure Local o actualizaciones de seguridad extendidas habilitadas por Azure Arc)

Verifique el acceso a la CLI de Azure:

az account show

Si eso devuelve los detalles de tu suscripción, estás listo.

Consejo profesional: Windows Server 2012/R2 requiere actualizaciones de seguridad extendidas (ESU) habilitadas a través de Azure Arc para soporte continuo de parches. Si todavía está ejecutando 2012, incorpórese primero a Arc.

Habilitar evaluación periódica

Evaluación periódica escanea sus máquinas virtuales cada 24 horas para informar parches faltantes sin instalarlos. Esto le brinda visibilidad del estado de cumplimiento en toda su flota.

Habilítelo en una VM específica:

az vm assess-patches \
  --resource-group myResourceGroup \
  --name myVM

Esto desencadena una evaluación inmediata. Los resultados aparecen en Azure Portal en la hoja Update Manager de la máquina virtual, pero el verdadero poder son las consultas a escala a través de Azure Resource Graph.

Para aplicar evaluaciones periódicas automáticamente en todas las máquinas virtuales que utilizan Política de Azure:

az policy assignment create \
  --name 'Enable-Periodic-Assessment' \
  --scope '/subscriptions/YOUR_SUBSCRIPTION_ID' \
  --policy '/providers/Microsoft.Authorization/policyDefinitions/59efceea-0c96-497e-a4a1-4eb2290dac15' \
  --params '{
    "assessmentMode": {
      "value": "AutomaticByPlatform"
    }
  }'

Esta política incorporada (59efceea-0c96-497e-a4a1-4eb2290dac15) configura el modo de evaluación en máquinas virtuales que no lo tienen configurado. Déle entre 15 y 30 minutos para evaluar y remediar. Las nuevas máquinas virtuales se evalúan automáticamente.

Verifique los resultados de la evaluación en todas las máquinas virtuales:

az graph query -q "patchassessmentresources | where type == 'microsoft.compute/virtualmachines/patchassessmentresults' | project vmName = split(id, '/')[8], status = properties.status, criticalPatchCount = properties.availablePatchCountByClassification.critical, securityPatchCount = properties.availablePatchCountByClassification.security"

Esa consulta extrae datos de evaluación de Azure Resource Graph, que es donde Update Manager almacena el estado de cumplimiento, no de Log Analytics, ni de algún espacio de trabajo que olvidó que existía. Si una máquina virtual muestra parches críticos, sabrá que necesita atención.

Configurar el modo de orquestación de parches

Este paso determina si Azure controla la aplicación de parches o usted. Para programaciones personalizadas, debe configurar las máquinas virtuales para Horarios gestionados por el cliente modo.

Configure una máquina virtual en el modo Programaciones administradas por el cliente:

az vm update \
  --resource-group myResourceGroup \
  --name myVM \
  --set osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform \
       osProfile.windowsConfiguration.patchSettings.automaticByPlatformSettings.bypassPlatformSafetyChecksOnUserSchedule=true

Para máquinas virtuales Linux, reemplace windowsConfiguration con linuxConfiguration.

Eso bypassPlatformSafetyChecksOnUserSchedule=true flag le dice a Azure: “Soy dueño de esta programación. No aplique parches fuera de mi ventana”. Sin él, Azure podría aplicar parches automáticamente durante su horario comercial porque cree que está siendo útil. Que no es.

Verificación de la realidad: si omite este paso e intenta crear un programa de mantenimiento, Azure lo ignorará. El modo Horarios administrados por el cliente es obligatorio para que la programación funcione.

Crear una configuración de mantenimiento

A configuración de mantenimiento define cuándo se aplica el parche y qué se instala. Es un recurso ARM que especifica la hora de inicio, la duración, la recurrencia y las clasificaciones de parches.

Cree una configuración de mantenimiento para la aplicación de parches mensuales el segundo martes (martes de parches más una semana para la validación):

az maintenance configuration create \
  --resource-group myResourceGroup \
  --resource-name MaintenanceConfig-ProdServers \
  --location eastus \
  --maintenance-scope InGuestPatch \
  --start-date-time "2026-02-10 02:00" \
  --duration "03:00" \
  --time-zone "Eastern Standard Time" \
  --recur-every "Month Second Tuesday" \
  --windows-classifications-to-include Critical Security UpdateRollup \
  --reboot-setting IfRequired

Parámetros clave explicados:

• --maintenance-scope InGuestPatch: Le dice a Azure que esto es para parchear el sistema operativo, no para mantener el host.

• --duration "03:00": Ventana de mantenimiento de tres horas. Update Manager reserva los últimos 10 minutos (Windows) o 15 minutos (Linux) para reinicios, por lo que el tiempo de instalación efectivo es de 2 horas y 50 minutos en Windows.

• --recur-every "Month Second Tuesday": Se ejecuta mensualmente el segundo martes de cada mes.

• --reboot-setting IfRequired: Sólo se reinicia si un parche lo requiere. Valores alternativos: Always (reiniciar independientemente) o Never (deje las máquinas virtuales en estado pendiente de reinicio, lo que anula el propósito de aplicar parches)

La lógica de la ventana de mantenimiento es más importante de lo que piensas. Antes de instalar cada parche, Update Manager calcula: (current time + expected install time + reboot buffer). Si eso excede el tiempo de finalización de la ventana, el parche no se instala. Traducción: si su actualización acumulativa de Windows demora 50 minutos y solo le queda una hora en la ventana, Update Manager la omite en lugar de arriesgarse a dejar su máquina virtual en un estado de actualización parcial. Es por eso que Microsoft recomienda períodos de 90 minutos como mínimo, y mucho más si está parcheando máquinas virtuales que no se han actualizado en meses.

Verifique la configuración:

az maintenance configuration show \
  --resource-group myResourceGroup \
  --resource-name MaintenanceConfig-ProdServers

Asignar máquinas virtuales a la configuración de mantenimiento

Puede asignar máquinas virtuales de forma estática (selección manual) o dinámicamente (criterios basados ​​en consultas). El alcance dinámico es el único enfoque que va más allá de un puñado de servidores.

Asignación estática

Asigne una máquina virtual específica:

az maintenance assignment create \
  --resource-group myResourceGroup \
  --location eastus \
  --resource-name myVM-assignment \
  --maintenance-configuration-id "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/myResourceGroup/providers/Microsoft.Maintenance/maintenanceConfigurations/MaintenanceConfig-ProdServers" \
  --resource-id "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM"

Eso funciona para una VM. Para 50 máquinas virtuales, debe copiar y pegar. Para 500 VM, está reconsiderando sus elecciones profesionales.

Alcance dinámico

Alcance dinámico Asigna máquinas virtuales según criterios evaluados en tiempo de ejecución: suscripción, grupo de recursos, ubicación, etiquetas. Etiquetar una máquina virtual con PatchGroup: Production cinco minutos antes de que se ejecute el programa y se incluye automáticamente. Retire la etiqueta y quedará excluida. No hay actualizaciones manuales de las listas de tareas.

Cree un alcance dinámico para las máquinas virtuales de producción etiquetadas con Environment: Production:

az maintenance assignment create \
  --resource-group myResourceGroup \
  --location eastus \
  --resource-name DynamicScope-Production \
  --maintenance-configuration-id "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/myResourceGroup/providers/Microsoft.Maintenance/maintenanceConfigurations/MaintenanceConfig-ProdServers" \
  --filter-resource-types "Microsoft.Compute/virtualMachines" \
  --filter-tags "Environment=Production" \
  --filter-locations "eastus" "westus2"

Este alcance incluye todas las máquinas virtuales en el Este de EE. UU. o el Oeste de EE. UU. 2 con la Environment: Production etiqueta. Cuando se activa la ventana de mantenimiento, Update Manager consulta estos criterios en tiempo real y parchea las máquinas virtuales que coinciden.

Un único ámbito dinámico admite hasta 1000 asociaciones de recursos. Puede adjuntar varios ámbitos a una configuración de mantenimiento si necesita un control más granular.

Ganancia rápida: use Azure Policy para etiquetar automáticamente nuevas máquinas virtuales con identificadores de entorno. Sus ámbitos dinámicos los recogerán automáticamente sin que nadie recuerde asignarlos manualmente a los programas de parches.

Implementar parches basados ​​en anillos

Aplicar parches a todo simultáneamente es la forma de descubrir que un parche interrumpe su aplicación a las 3 a. m. Los lanzamientos por etapas (anillos) reducen el riesgo al validar parches que no están en producción antes de tocar cualquier cosa que esté de cara al cliente.

Cree tres configuraciones de mantenimiento con parámetros idénticos excepto --start-date-time:

# Ring 0: Dev/Test - Second Tuesday of month
az maintenance configuration create \
  --resource-group myResourceGroup \
  --resource-name MaintenanceConfig-Ring0 \
  --location eastus \
  --maintenance-scope InGuestPatch \
  --start-date-time "2026-02-10 02:00" \
  --duration "03:00" \
  --time-zone "Eastern Standard Time" \
  --recur-every "Month Second Tuesday" \
  --windows-classifications-to-include Critical Security UpdateRollup \
  --reboot-setting IfRequired

# Ring 1: Pre-Prod - Third Tuesday of month
az maintenance configuration create \
  --resource-group myResourceGroup \
  --resource-name MaintenanceConfig-Ring1 \
  --location eastus \
  --maintenance-scope InGuestPatch \
  --start-date-time "2026-02-17 02:00" \
  --duration "03:00" \
  --time-zone "Eastern Standard Time" \
  --recur-every "Month Third Tuesday" \
  --windows-classifications-to-include Critical Security UpdateRollup \
  --reboot-setting IfRequired

# Ring 2: Production - Fourth Tuesday of month
az maintenance configuration create \
  --resource-group myResourceGroup \
  --resource-name MaintenanceConfig-Ring2 \
  --location eastus \
  --maintenance-scope InGuestPatch \
  --start-date-time "2026-02-24 02:00" \
  --duration "03:00" \
  --time-zone "Eastern Standard Time" \
  --recur-every "Month Fourth Tuesday" \
  --windows-classifications-to-include Critical Security UpdateRollup \
  --reboot-setting IfRequired

Cree ámbitos dinámicos para cada anillo usando etiquetas:

# Ring 0 scope
az maintenance assignment create \
  --resource-group myResourceGroup \
  --location eastus \
  --resource-name DynamicScope-Ring0 \
  --maintenance-configuration-id "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/myResourceGroup/providers/Microsoft.Maintenance/maintenanceConfigurations/MaintenanceConfig-Ring0" \
  --filter-resource-types "Microsoft.Compute/virtualMachines" \
  --filter-tags "PatchRing=Ring0"

# Ring 1 scope
az maintenance assignment create \
  --resource-group myResourceGroup \
  --location eastus \
  --resource-name DynamicScope-Ring1 \
  --maintenance-configuration-id "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/myResourceGroup/providers/Microsoft.Maintenance/maintenanceConfigurations/MaintenanceConfig-Ring1" \
  --filter-resource-types "Microsoft.Compute/virtualMachines" \
  --filter-tags "PatchRing=Ring1"

# Ring 2 scope
az maintenance assignment create \
  --resource-group myResourceGroup \
  --location eastus \
  --resource-name DynamicScope-Ring2 \
  --maintenance-configuration-id "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/myResourceGroup/providers/Microsoft.Maintenance/maintenanceConfigurations/MaintenanceConfig-Ring2" \
  --filter-resource-types "Microsoft.Compute/virtualMachines" \
  --filter-tags "PatchRing=Ring2"

Etiquete las máquinas virtuales según su anillo de implementación:

az vm update \
  --resource-group myResourceGroup \
  --name myDevVM \
  --set tags.PatchRing=Ring0

az vm update \
  --resource-group myResourceGroup \
  --name myProdVM \
  --set tags.PatchRing=Ring2

Ahora las máquinas virtuales de desarrollo se parchean el segundo martes, la preproducción el tercer martes y la producción el cuarto martes. Si Ring 0 revela un parche problemático, tienes dos semanas para responder antes de que llegue a producción. Y debido a que usó alcance dinámico con etiquetas, las nuevas máquinas virtuales se unen automáticamente al anillo correcto según su etiqueta, sin necesidad de asignaciones de programación manuales.

Consultar estado del parche

Después de que se ejecute la primera ventana de mantenimiento, verifique los resultados mediante Azure Resource Graph:

az graph query -q "patchinstallationresources | where type == 'microsoft.compute/virtualmachines/patchinstallationresults' | project vmName = split(id, '/')[8], status = properties.status, installedPatchCount = properties.installedPatchCount, failedPatchCount = properties.failedPatchCount, rebootStatus = properties.rebootStatus, lastModified = properties.lastModifiedDateTime"

Esto devuelve los resultados de la instalación para todas las máquinas virtuales: cuántos parches se instalaron, cuántos fallaron, si se produjo un reinicio y cuándo se completó la operación.

Para obtener informes de cumplimiento, consulte qué máquinas virtuales tienen parches críticos pendientes:

az graph query -q "patchassessmentresources | where type == 'microsoft.compute/virtualmachines/patchassessmentresults' | where properties.availablePatchCountByClassification.critical > 0 | project vmName = split(id, '/')[8], criticalPatchCount = properties.availablePatchCountByClassification.critical, assessmentTime = properties.lastModifiedDateTime"

Si esa consulta devuelve filas, esas máquinas virtuales no se incluyeron en un programa de mantenimiento o la ventana de mantenimiento fue demasiado corta para instalar sus parches. Verifique el modo de orquestación y la duración de la ventana de mantenimiento.

Solución de problemas de fallas comunes

Ventana de mantenimiento excedida

Síntoma: Los parches se muestran como “No iniciados” u “Omitidos” en los resultados de la instalación.

Causa: La ventana de mantenimiento es demasiado corta para la cantidad o el tamaño de las actualizaciones. Update Manager calcula si cada parche se puede completar dentro del tiempo restante. Si no, se salta el parche.

Arreglar: amplía la duración de la ventana. Para las máquinas virtuales que no han sido parcheadas en meses, comience con un período de 4 horas. Una vez que estén actualizados, reduzca a 2 o 3 horas para el mantenimiento mensual.

az maintenance configuration update \
  --resource-group myResourceGroup \
  --resource-name MaintenanceConfig-ProdServers \
  --duration "04:00"

El agente de VM no está listo

Síntoma: Update Manager informa “El agente no responde” o “No se puede conectar a la VM”.

Causa: El agente de máquina virtual de Azure o el agente de Azure Arc no se está ejecutando o no puede comunicarse con Azure.

Arreglar: Reinicie el servicio del agente:

ventanas:

Restart-Service -Name RdAgent -Force
Restart-Service -Name WindowsAzureGuestAgent -Force

linux:

sudo systemctl restart walinuxagent

Verifique que el agente se esté ejecutando:

az vm get-instance-view \
  --resource-group myResourceGroup \
  --name myVM \
  --query "instanceView.vmAgent.statuses"

Si el estado no es “Listo”, verifique la conectividad de la red según su fuente de actualización. Las máquinas virtuales de Windows necesitan acceso a los puntos finales de Windows Update. Las máquinas virtuales Linux necesitan acceso a los repositorios de su distribución (RHUI para Red Hat, repositorios estándar para Ubuntu/SUSE). Si está utilizando WSUS, asegúrese de que la VM pueda llegar a su servidor WSUS.

Fallos del servicio de actualización de Windows

Síntoma: Las máquinas virtuales de Windows no pueden evaluar ni instalar parches con errores que hacen referencia a la API de Windows Update.

Causa: A menudo causado por la configuración de la Política de grupo que apunta a un servidor WSUS inexistente o al UseWUServer clave de registro configurada incorrectamente.

Arreglar: Si utiliza WSUS, verifique que se pueda acceder al servidor. De lo contrario, deshabilite WSUS temporalmente:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" -Value 0
Restart-Service -Name wuauserv

Update Manager respeta las configuraciones de WSUS: si su cliente de Windows Update apunta a WSUS, Update Manager activa análisis e instalaciones en ese servidor WSUS, no en Microsoft Update. El servicio gestiona la programación, pero la configuración del lado del cliente controla la fuente de actualización.

Lo que acabas de configurar

Ha eliminado la aplicación de parches manuales en sus máquinas virtuales de Azure. La evaluación periódica ejecuta análisis diarios automáticamente, las configuraciones de mantenimiento definen exactamente cuándo se instalan los parches y el alcance dinámico garantiza que las nuevas máquinas virtuales reciban parches sin que nadie recuerde agregarlas a las listas estáticas. Las implementaciones basadas en anillo le brindan ventanas de validación antes de que los parches lleguen a producción.

La próxima vez que un auditor solicite el estado de cumplimiento del parche, ejecute una consulta de Azure Resource Graph en lugar de iniciar sesión en 50 máquinas virtuales para verificarlas manualmente. Y cuando cae un parche crítico de día cero, puede activar una instalación inmediata en todas las máquinas virtuales afectadas a través del parche bajo demanda de Update Manager sin esperar su período de mantenimiento mensual.

Ese parche de seguridad que ignoró el mes pasado no lo será este mes. O el mes siguiente. Porque ahora la aplicación de parches está automatizada, lo que significa que realmente ocurre.