Gestione scalabile delle patch delle macchine virtuali Windows

Questo articolo descrive l'approccio consigliato per rendere operativi gli aggiornamenti del sistema operativo in Windows macchine virtuali all'interno del carico di lavoro. Questo processo offre una soluzione di gestione delle patch coerente, scalabile e regolamentata nella flotta di macchine virtuali Windows nel carico di lavoro. L'approccio consente di convalidare gli aggiornamenti negli ambienti di preproduzione prima di promuoverli nell'ambiente di produzione.

La gestione efficace delle patch si estende oltre l'installazione degli aggiornamenti. Una strategia di gestione delle patch richiede anche una governance coerente per garantire che le macchine virtuali vengano caricate nella soluzione di gestione delle patch, configurate in base agli standard del carico di lavoro e monitorate continuamente per la conformità.

Nota

Questo articolo è incentrato sulle Macchine virtuali di Azure. Anche se Gestore aggiornamenti di Azure supporta anche i server abilitati per Arc, gli scenari ibridi hanno considerazioni aggiuntive e non sono trattati qui.

Usa Gestore aggiornamenti di Azure

L'approccio consigliato per la gestione degli aggiornamenti del sistema operativo Windows in Macchine virtuali Windows in Azure consiste nell'usare Gestore aggiornamenti di Azure. Questo servizio offre pianificazione centralizzata, report di conformità e la possibilità di eseguire distribuzioni di aggiornamenti del sistema operativo a fasi per le macchine virtuali. Gestore aggiornamenti di Azure funziona mediante un'estensione sidecar della VM di Azure installata su ogni VM del carico di lavoro. Gestione aggiornamenti non ospita o distribuisce le patch. È responsabile del controllo e dell'attivazione dell'agente di Windows Update nativo in ogni macchina virtuale.

Gestore aggiornamenti di Azure offre al team del carico di lavoro una visualizzazione centrale dello stato delle patch delle macchine virtuali all'interno dell'ambiente. È possibile impostare le destinazioni di applicazione di patch e le cadenza e supportare l'implementazione di patch su richiesta.

Tip

Gestore aggiornamenti di Azure installa gli aggiornamenti Windows usando l'API Windows Update Agent. Poiché questi aggiornamenti ignorano il flusso di lavoro dell'agente di orchestrazione Windows Update usato dall'app Impostazioni Windows, potrebbero non essere visualizzati in Impostazioni>Windows Update>Cronologia aggiornamenti. Questo comportamento è previsto. Per verificare l'installazione degli aggiornamenti, esaminare gli eventi WindowsUpdateClient in Windows Visualizzatore eventi.

Organizzazione delle risorse di Azure

Gestore aggiornamenti di Azure non è una risorsa Azure. Non lo distribuisci nelle sottoscrizioni del tuo carico di lavoro. È disponibile nel portale di Azure e l'esperienza utente nel portale è basata su RBAC e indipendente dalla sottoscrizione. Tuttavia, si gestiscono le configurazioni di manutenzione, quali patch del sistema operativo applicare e quando, e la relativa associazione alle VM del carico di lavoro come risorse di Azure.

Ogni configurazione di manutenzione può avere una singola pianificazione e può avere come destinazione qualsiasi numero di risorse tramite associazioni. Le configurazioni di manutenzione sono risorse a livello di area. Usare una singola configurazione e associazioni di manutenzione per includere solo macchine virtuali all'interno della stessa area e della stessa sottoscrizione. Questo approccio significa che sono disponibili risorse di configurazione di manutenzione separate per tutti gli ambienti e potenzialmente multipli per ogni ambiente se il carico di lavoro è multiregione o ha pianificazioni di aggiornamento diverse per parti diverse del carico di lavoro.

Mantieni le risorse di configurazione per la manutenzione come parte dell'IaC del tuo carico di lavoro per tale ambiente. Questo approccio consente di eseguire processi di controllo delle modifiche, procedure di distribuzione sicure e offre un'opzione di ripristino di emergenza.

Requisiti delle macchine virtuali

Le macchine virtuali Windows devono essere un'immagine personalizzata o Azure Marketplace supportata. Indipendentemente dall'origine, è necessario configurare il sistema operativo per supportare gli aggiornamenti. Il modo consigliato consiste nell'usare l'IaC della macchina virtuale, che configura le impostazioni del sistema operativo necessarie. In particolare, assicurarsi che le macchine virtuali abbiano almeno le impostazioni seguenti:

windowsConfiguration: {
  provisionVMAgent: true
  enableAutomaticUpdates: true

  patchSettings: {
    patchMode: 'AutomaticByPlatform'  // Disables automatic updates in the OS; now platform triggers updates
    assessmentMode: 'AutomaticByPlatform' // Scans for missing updates every 24 hours

    automaticByPlatformSettings: {
      bypassPlatformSafetyChecksOnUserSchedule: true  // Allows Azure Update Management to honor defined schedules
      rebootSetting: 'IfRequired'  // Or 'Never' if required in your workload
    }
  }
}

Il Windows Guest Agent installa un'estensione di tipo sidecar denominata Microsoft.CPlat.Core.WindowsPatchExtension. Questa estensione con privilegi viene eseguita nelle macchine virtuali per ottenere la pianificazione e l'aggiornamento della configurazione. Richiama anche le API di aggiornamento del sistema operativo Windows native per eseguire gli aggiornamenti. Questa estensione non viene definita come parte dell'IaC della macchina virtuale. Update Manager lo installa automaticamente e ne gestisce il ciclo di vita.

L'estensione WindowsPatchExtension non esegue l'override delle impostazioni dell'origine di aggiornamento nel computer. Questo comportamento significa che l'utente è comunque responsabile della configurazione dell'origine dell'aggiornamento per le macchine virtuali:

Per informazioni dettagliate sulle origini supportate, vedere Origini di aggiornamento supportate, tipi, aggiornamenti delle applicazioni Microsoft e aggiornamenti non Microsoft.

Abilitare le valutazioni automatiche in modo che i report di conformità riflettano i dati correnti. Questa funzionalità consente di vedere dove ogni macchina virtuale si trova rispetto alla baseline di patch e individuare le nuove esposizione divulgate prima dell'esecuzione pianificata successiva. La valutazione riguarda solo le macchine virtuali in esecuzione; le macchine virtuali arrestate o deallocate non vengono analizzate.

Importante

Poiché Gestore aggiornamenti di Azure richiama direttamente la funzionalità nativa del sistema operativo Windows, è importante che le impostazioni del sistema operativo rimangano configurate correttamente per supportare l'applicazione di patch.

  • Assicurarsi che Criteri di gruppo, Microsoft Intune o altri strumenti di gestione della configurazione non sovrascrivano le impostazioni del sistema operativo necessarie affinché Gestore aggiornamenti di Azure funzioni correttamente nelle macchine virtuali. Per valori di configurazione specifici, vedere Configurare le impostazioni di Windows Update in Gestore aggiornamenti di Azure.
  • I firewall a livello di sistema operativo non devono bloccare il traffico di aggiornamento.

Applicazione dei criteri

Il carico di lavoro deve anche usare Criteri di Azure per imporre che le macchine virtuali rimangano configurate correttamente per Gestore aggiornamenti di Azure. Applicare i criteri di Gestore aggiornamenti di Azure predefiniti come meccanismo di prevenzione della deriva della configurazione. I criteri predefiniti supportano DINE (DeployIfNotExists) e modificano l'imposizione per correggere automaticamente le macchine virtuali non conformi.

Per un approccio basato su criteri per la gestione delle patch, vedere Abilitare la valutazione periodica e l'applicazione di patch pianificate nelle macchine virtuali Azure usando un criterio. Usare questo approccio se il carico di lavoro non usa IaC per distribuire e configurare le macchine virtuali.

Requisiti di rete

Per le VM di Azure con accesso diretto a Internet in uscita, Windows Update in genere funziona senza configurazioni aggiuntive di allow-list di rete, a condizione che l'origine degli aggiornamenti del sistema operativo guest, il DNS, il proxy, l'ispezione TLS e le impostazioni dei criteri locali consentano il traffico di Windows Update/Microsoft Update. La maggior parte dei carichi di lavoro, tuttavia, opera in reti virtuali bloccate con accesso in uscita limitato. In questi casi, è necessario consentire il traffico verso gli endpoint di Microsoft Update attraverso tutti gli NSG e i firewall da cui passa il traffico in uscita.

Gruppi di sicurezza di rete

Le origini di aggiornamento predefinite, inclusi gli aggiornamenti Windows, sono basate su DNS e non pubblicano elenchi IP statici stabili. Per le fonti di aggiornamento ospitate su Internet, questa condizione indica che l'NSG associato alla NIC della macchina virtuale o alla relativa subnet deve consentire il traffico in uscita verso Internet sulle porte TCP 443 e TCP 80. È consigliabile limitare ulteriormente l'accesso dal firewall in uscita. Se gli aggiornamenti provengono da un intervallo di indirizzi IP statici ,ad esempio un'origine locale, è necessario definire in modo esplicito tale destinazione in uscita nei gruppi di sicurezza di rete.

Firewall di uscita

Il firewall in uscita deve consentire il traffico verso gli FQDN utilizzati dall'origine degli aggiornamenti. Se usi Firewall di Azure e un'origine di aggiornamento fornita da Microsoft, usa il tag FQDN WindowsUpdate per consentire l'accesso in uscita agli endpoint Windows Update. Per altri firewall in uscita nel percorso di rete, vedere Configurare i firewall. È consigliabile consentire questo traffico proveniente solo dalle macchine virtuali Windows e non da subnet non correlate all'interno del carico di lavoro.

Associare macchine virtuali a una configurazione di manutenzione

Sebbene sia possibile creare associazioni statiche tra una configurazione di manutenzione e le VM, è preferibile usare invece l'ambito dinamico. Gli ambiti dinamici determinano quali macchine virtuali sono associate alla configurazione di manutenzione in base a attributi quali gruppo di risorse, posizione e tag. La configurazione di manutenzione, non l'ambito dinamico, definisce gli aggiornamenti installati e quando. L'ambito dinamico include automaticamente le nuove macchine virtuali corrispondenti senza richiedere la gestione delle risorse di associazione della configurazione per singola macchina virtuale.

Quando si usano regole di ambito dinamico, attenersi alle seguenti raccomandazioni:

  • Gestisci le regole di definizione dinamica dell'ambito come Infrastructure as Code (IaC) nell'ambito del tuo carico di lavoro.
  • Includere solo le VM del proprio ambiente per evitare dipendenze tra ambienti diversi, duplicando la configurazione e le regole di ambito dinamico nei vari ambienti, secondo necessità.
  • Usare i tag come driver primario e imporre l'utilizzo tramite Criteri di Azure.

Progettare una pianificazione di applicazione di patch a fasi

Una pianificazione di applicazione di patch tipica per un carico di lavoro usa pianificazioni di distribuzione a fasi. Dopo il rilascio dell'aggiornamento mensile di Microsoft, applicate prima gli aggiornamenti alle macchine virtuali di sviluppo e test. Dopo la convalida, alzare di livello la stessa classificazione degli aggiornamenti alla preproduzione e quindi alla produzione in finestre di manutenzione separate.

Creare configurazioni di manutenzione per definire la ricorrenza, la finestra di manutenzione, le classificazioni degli aggiornamenti e il comportamento di riavvio. Quindi crea l'associazione con ambito dinamico per indirizzare le macchine virtuali nel tuo carico di lavoro ed eseguire il normale programma di applicazione delle patch.

Un calendario allineato al Patch Tuesday consente in genere alcuni giorni per la convalida prima della distribuzione in produzione. Poiché gli aggiornamenti mensili della sicurezza di Microsoft vengono in genere rilasciati il secondo martedì di ogni mese, un approccio suggerito potrebbe essere il seguente. Le macchine virtuali di destinazione vengono gestite tramite una regola di ambito dinamica usando i tag in questo esempio.

Environment Pianificazione Tag della risorsa della macchina virtuale Updates Riavvio
Development Secondo martedì
2200-0000		 PatchGroup = Backend O PatchGroup=Frontend Critico + Sicurezza Se necessario
Test Secondo mercoledì
2200-0000		 PatchGroup = Backend o PatchGroup=Frontend Critico e sicurezza Se necessario
Backend di produzione (Wave 1) Secondo sabato
2200-0100		 PatchGroup=Backend Critico + Sicurezza Se necessario
Frontend di produzione (Fase 2) Domenica successiva
2200-0100		 PatchGroup=Frontend Critico + Sicurezza Se necessario

Gestire la concorrenza degli aggiornamenti

Una configurazione di manutenzione avvia gli aggiornamenti in tutte le macchine virtuali associate contemporaneamente. Azure serializza i riavvii in base al dominio di aggiornamento solo per le macchine virtuali in un set di disponibilità comune. Le Backend e Frontend ondate in questo esempio separano la pianificazione per tier, non in base alla capacità ridondante, quindi ogni istanza di un tier potrebbe riavviarsi contemporaneamente e portare quel tier al di sotto della capacità richiesta.

All'interno di ogni livello di produzione, suddividere il patching in ondate che preservano la capacità, allineate alle zone di disponibilità, ai domini di aggiornamento o ai gruppi di istanze definiti dal carico di lavoro. Usare un valore di tag distinto e una configurazione di manutenzione per ogni onda.

Prendere in considerazione la coerenza dell'implementazione

Update Manager esegue una valutazione aggiornata a ogni esecuzione. Ciò significa che le pianificazioni basate sulla classificazione possono selezionare kB diversi nelle onde successive. Se ogni onda deve installare il set di aggiornamento convalidato esatto, configurare inclusioni di KB esplicite invece di basarsi solo sulle classificazioni.

Questa operazione può essere automatizzata usando l'API REST di Gestione aggiornamenti per eseguire query sui risultati della valutazione dal primo ciclo e quindi aggiornare la configurazione di manutenzione per le successive onde.

Il compromesso che si ottiene per ottenere la coerenza completa dell'onda è una notevole complessità di orchestrazione. Se il carico di lavoro può tollerare il rischio che un'ondata successiva installi un KB diverso da quello della prima ondata, usa la pianificazione basata sulla classificazione.

Ridurre i riavvii con hotpatching

I riavvii sono spesso la parte più critica di un programma di applicazione delle patch. Determinano le dimensioni della finestra di manutenzione e il comportamento di riavvio nella tabella precedente. Nelle immagini supportate, hotpatching installa gli aggiornamenti della sicurezza di Windows correggendo il codice in memoria dei processi in esecuzione, quindi nella maggior parte dei mesi gli aggiornamenti vengono applicati senza riavvio. Hotpatch è un'estensione di Windows Update, quindi Gestore aggiornamenti di Azure installa hotpatches tramite le stesse configurazioni di manutenzione e l'ambito dinamico usato per le altre macchine virtuali.

Se il carico di lavoro è sensibile ai riavvii, adottare uno SKU e una progettazione del sistema operativo che supporta il hotpatching:

  • Hotpatch è disponibile solo in immagini di Windows specifiche. Non è possibile abilitare hotpatch in un'immagine personalizzata arbitraria.

  • Solo gli aggiornamenti di sicurezza di Windows vengono aggiornati tramite hotpatch. Gli aggiornamenti non di sicurezza, gli aggiornamenti .NET e gli aggiornamenti del driver o del firmware richiedono comunque un riavvio nei mesi in cui vengono rilasciati. Le baseline trimestrali degli hotpatch e qualsiasi baseline non pianificata che Microsoft rilascia per correggere una vulnerabilità zero-day richiedono anch'esse un riavvio. Mantenere una finestra di manutenzione in grado di assorbire un riavvio.

Gestire le questioni "prima" e "dopo"

Gestore aggiornamenti di Azure valuta e installa gli aggiornamenti del sistema operativo, ma un processo di applicazione di patch riuscito può includere attività prima e dopo la finestra di manutenzione per gestire correttamente i riavvii necessari o problemi specifici dell'applicazione. Update Manager fornisce eventi pre e post da utilizzare nell'automazione del carico di lavoro. I gestori eventi vengono aggiunti all'architettura del carico di lavoro, ad esempio una funzione Azure, che rispondono alle notifiche di Griglia di eventi di Azure prima e dopo l'esecuzione pianificata delle patch.

Utilizzare le attività preliminari all'applicazione delle patch di Update Manager per eseguire operazioni quali:

  • Avviare una macchina virtuale arrestata o deallocata. Le macchine virtuali arrestate o deallocate non sono in grado di applicare patch e vengono ignorate.
  • Verificare che i punti di ripristino di backup siano disponibili.
  • Convalidare l'integrità della macchina virtuale e dell'applicazione.
  • Eliminare temporaneamente gli avvisi di monitoraggio per evitare falsi positivi durante la finestra di manutenzione.

Dopo l'installazione degli aggiornamenti, utilizzare le attività successive all'applicazione delle patch per eseguire operazioni quali:

  • Ripristinare il monitoraggio.
  • Eseguire controlli di integrità delle applicazioni e dei servizi.
  • Inviare un avviso a un canale Microsoft Teams.

Considerare Griglia di eventi di Azure e il calcolo del gestore eventi come risorse del carico di lavoro. Distribuirli con IaC e isolarli tra ambienti.

Preparare gli aggiornamenti su richiesta

Gestore aggiornamenti di Azure supporta l'installazione di patch su richiesta all'esterno di qualsiasi finestra di manutenzione pianificata. Questa funzionalità è utile per applicare patch di emergenza, correzioni critiche fuori ciclo o convalidare il comportamento delle patch in una singola macchina virtuale prima di un'implementazione pianificata più ampia. È possibile attivare gli aggiornamenti su richiesta direttamente dal portale di Azure o dall'API REST di Gestione aggiornamenti su una o più macchine virtuali contemporaneamente. Come team responsabile del carico di lavoro, stabilite linee guida che definiscano quando eseguire un aggiornamento fuori banda e come orchestrare tale processo nell'intero carico di lavoro.

Ripristinare gli aggiornamenti precedenti

Gestore aggiornamenti di Azure non fornisce il rollback delle patch del sistema operativo. Dopo aver applicato le patch, non è disponibile alcun meccanismo predefinito per disinstallarli direttamente tramite Gestione aggiornamenti.

Se il carico di lavoro deve supportare uno stato "ultimo valido noto", creare uno snapshot o un punto di ripristino prima di un'esecuzione di manutenzione. Automatizzare la creazione di snapshot da eseguire prima di ogni finestra di applicazione di patch per assicurarsi che un punto di ripristino esista sempre prima dell'applicazione delle patch. In alternativa, ridistribuire la macchina virtuale senza la patch, escludere la patch kb problematica dalla distribuzione e riapplicare gli aggiornamenti.

Importante

Pianificare la strategia di ripristino prima di abilitare l'applicazione di patch pianificata nell'ambiente di produzione.

Report di conformità

Update Manager esegue il push dei risultati di valutazione e installazione delle patch in Azure Resource Graph, che archivia gli aggiornamenti in sospeso per 7 giorni e i risultati dell'installazione per 30 giorni. Gestore aggiornamenti di Azure include visualizzazioni predefinite per la creazione di report di conformità e gestione che offrono visibilità sullo stato di aggiornamento nell'ambiente. Questi dashboard consentono agli amministratori di monitorare la conformità delle patch, identificare i computer che richiedono attenzione e tenere traccia dello stato di avanzamento della distribuzione degli aggiornamenti da una posizione centrale.

Le cartelle di lavoro predefinite contengono informazioni chiave nel carico di lavoro:

  • riepilogo generale dello stato e della configurazione del computer
  • una suddivisione degli aggiornamenti in sospeso in base alla gravità e alla classificazione
  • riepilogo delle pianificazioni, delle configurazioni di manutenzione e dei computer collegati a ogni pianificazione
  • una visualizzazione cronologica delle esecuzioni precedenti dell'installazione, incluse le percentuali di esito positivo e gli eventuali errori

Molte organizzazioni richiedono che i team delle applicazioni forniscano anche report di conformità. Idealmente, l'organizzazione usa già Gestore aggiornamenti di Azure per tale rilevamento, perché l'esperienza del portale Gestore aggiornamenti di Azure e le cartelle di lavoro possono funzionare oltre i limiti delle sottoscrizioni e non è necessario fornire alcuna segnalazione dello stato delle patch personalizzata nel carico di lavoro.

Se l'utente o l'organizzazione necessita di report personalizzati oltre le visualizzazioni predefinite, le cartelle di lavoro sono personalizzabili. Includere cartelle di lavoro personalizzate nei file IaC del carico di lavoro per applicare un processo di controllo delle modifiche e fornire un'opzione di ripristino di emergenza. Un'alternativa consiste nel fornire i dati di report di conformità necessari tramite Azure Resource Graph query.

Se il carico di lavoro deve conservare la cronologia delle patch più a lungo di quella fornita da Azure Resource Graph, creare un processo per esportare i dati in un archivio controllato dall'utente.

Approccio alternativo

Se decidi di non adottare l'approccio pianificato e graduale di Gestore aggiornamenti di Azure per il tuo carico di lavoro, valuta l'applicazione automatica di patch guest alle VM prima di progettare qualsiasi soluzione personalizzata. Con questa opzione, Azure gestisce l'applicazione delle patch. Tuttavia, si rinuncia a quanto segue se si sceglie:

  • Distribuzione graduale. Gli aggiornamenti non vengono promossi attraverso gli ambienti di sviluppo, test e produzione, quindi si perdono i passaggi di convalida.

  • Controllo della finestra di manutenzione. Azure decide quando l'applicazione di patch viene eseguita durante le ore di minore attività nel fuso orario di ogni macchina virtuale.

  • Aggiornare il controllo di classificazione. Vengono applicati solo gli aggiornamenti critici e della sicurezza. Le altre classificazioni non vengono installate automaticamente.

Contributori

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

  • Last updated on