Anche questo mese torna la mia rubrica dedicata all’evoluzione dei servizi di management e security in ambito Azure, con uno sguardo attento agli scenari ibridi e multicloud abilitati da Azure Arc e potenziati dall’utilizzo dell’Intelligenza Artificiale.
Questa serie di articoli mensili si propone di:
- offrire una panoramica delle novità più rilevanti introdotte da Microsoft;
- condividere consigli operativi e best practice raccolti dal campo, per aiutare architect e responsabili IT a gestire con efficacia ambienti complessi e distribuiti;
- seguire l’evoluzione verso un modello di gestione centralizzato, proattivo e basato sull’AI, in linea con la visione di Microsoft dell’AI-powered Management.
Gli ambiti principali affrontati in questa rubrica, accompagnati dagli strumenti e servizi di riferimento, sono descritti in questo articolo.
Hybrid and multicloud environment management
Azure Arc
Extended Security Updates per Windows Server 2016 tramite Azure Arc
Microsoft ha reso disponibili gli Extended Security Updates per Windows Server 2016 attraverso Azure Arc, offrendo alle organizzazioni un percorso semplificato per continuare a proteggere i sistemi che non potranno essere aggiornati o migrati entro la fine del supporto esteso del sistema operativo, prevista per il 12 gennaio 2027.
Collegando i server Windows Server 2016 ad Azure Arc-enabled Servers, è possibile attivare direttamente dal portale Azure l’adesione al programma ESU e continuare a ricevere gli aggiornamenti di sicurezza classificati da Microsoft come Critical e Important. La copertura potrà essere mantenuta per un massimo di tre anni dopo la fine del supporto, dal 12 gennaio 2027 fino a gennaio 2030. Gli ESU non introducono nuove funzionalità né correzioni non legate alla sicurezza, ma rappresentano un ponte temporaneo per i workload e le applicazioni business-critical che richiedono più tempo per essere modernizzati o migrati.
L’utilizzo degli ESU tramite Azure Arc introduce inoltre un modello operativo più flessibile rispetto ai tradizionali meccanismi di licensing. La fatturazione avviene secondo un modello pay-as-you-go mensile e può essere interrotta quando un server viene migrato, aggiornato o dismesso, evitando di sostenere costi per periodi di copertura non più necessari. La spesa viene fatturata attraverso Azure, può contribuire al consumo degli eventuali impegni Microsoft Azure Consumption Commitment (MACC) esistenti ed è monitorabile tramite Microsoft Cost Management and Billing.
Azure Arc semplifica anche la gestione su larga scala della copertura ESU. Dal portale Azure è possibile verificare centralmente l’inventario dei server, lo stato di enrollment e individuare rapidamente eventuali sistemi non ancora protetti. La distribuzione degli aggiornamenti è inoltre keyless: non è necessario acquistare, distribuire e attivare manualmente chiavi ESU sui singoli server.
La disponibilità degli Extended Security Updates attraverso Azure Arc rafforza quindi il ruolo del servizio come livello di gestione per infrastrutture ibride e multicloud. Oltre a estendere governance e sicurezza ai server eseguiti al di fuori di Azure, Arc consente di gestire in modo centralizzato anche una fase delicata del ciclo di vita dei sistemi operativi, mantenendo protetti i workload legacy mentre viene pianificato il percorso di aggiornamento o migrazione.
Security posture across hybrid and multicloud infrastructures
Microsoft Defender for Cloud
Nuova modalità di accesso ai dettagli CVE tramite Azure Resource Graph
Microsoft Defender for Cloud ha aggiornato il modello con cui vengono esposti e interrogati tramite Azure Resource Graph i dettagli relativi alle vulnerabilità CVE rilevate dai processi di vulnerability assessment. Le informazioni continuano a essere disponibili, ma le proprietà di dettaglio vengono ora rese accessibili attraverso il resource type microsoft-security/cvedetails.
La modifica è stata introdotta per migliorare le prestazioni delle query, la scalabilità del servizio e la gestione di volumi di dati più elevati. Il nuovo modello consente infatti di separare maggiormente i dettagli delle CVE dai record principali di vulnerability assessment, rendendo più efficiente l’accesso alle informazioni nei contesti caratterizzati da un numero elevato di risorse e vulnerabilità.
Le organizzazioni che utilizzano API, query Azure Resource Graph, workbook, script o automazioni per recuperare i dettagli delle CVE devono verificare le implementazioni esistenti e aggiornarle affinché utilizzino la nuova risorsa. Le query che continuano a leggere tali proprietà direttamente dai precedenti record di vulnerability assessment potrebbero infatti non restituire più tutte le informazioni attese.
La modifica richiede quindi particolare attenzione negli ambienti in cui i dati di Defender for Cloud vengono integrati con processi esterni di reporting, remediation o vulnerability management. È consigliabile censire le query e le automazioni esistenti e adeguarle al nuovo modello prima che eventuali dipendenze producano risultati incompleti.
Ritiro delle API classiche di Defender for SQL
Microsoft ha annunciato il ritiro delle API classiche di Defender for SQL utilizzate per la configurazione delle funzionalità di Vulnerability Assessment e Advanced Threat Protection. Le API interessate verranno dismesse il 16 agosto 2027.
Le organizzazioni che utilizzano ancora queste interfacce devono migrare verso il modello di configurazione attualmente supportato e aggiornare entro tale data eventuali script, pipeline Infrastructure as Code, strumenti di provisioning o automazioni che dipendono dalle API legacy.
Il periodo di transizione consente di pianificare l’adeguamento con anticipo, ma il cambiamento merita particolare attenzione negli ambienti Azure gestiti su larga scala, dove la configurazione di Defender for SQL viene spesso automatizzata attraverso template, script o strumenti di governance centralizzata.
È quindi opportuno includere la verifica delle dipendenze dalle API classiche nelle attività di lifecycle management e technical debt, così da evitare interruzioni nei processi di deployment o nella gestione della postura di sicurezza in prossimità della data di retirement.
Scansione malware on-demand mirata in Microsoft Defender for Storage
Microsoft Defender for Storage amplia le capacità di scansione malware on-demand introducendo la possibilità di analizzare elementi specifici, senza dover necessariamente eseguire la scansione dell’intero storage account.
È ora possibile limitare l’analisi a un singolo blob o file, a uno specifico container o file share oppure a tutti gli oggetti corrispondenti a un determinato prefisso di percorso. La selezione degli elementi da analizzare viene effettuata tramite filtri definiti nel corpo delle richieste REST API. In assenza di filtri, il comportamento rimane invariato e la scansione interessa l’intero storage account.
Questa maggiore granularità rende la funzionalità particolarmente utile negli scenari di incident response, nelle verifiche successive al caricamento di file sospetti o nei processi di validazione selettiva di dataset e repository di grandi dimensioni. È possibile concentrare l’analisi sulle sole risorse di interesse, riducendo l’ambito operativo della scansione e rendendo più efficienti le attività di verifica.
La novità consente inoltre di integrare più facilmente le scansioni malware in workflow automatizzati, nei quali un evento o un processo applicativo può attivare l’analisi esclusivamente degli oggetti coinvolti, rafforzando l’utilizzo di Defender for Storage come componente di sicurezza integrato nei processi operativi.
Modifica alle valutazioni delle identità con privilegi eccessivi in AWS e Google Cloud
Microsoft Defender for Cloud modifica il funzionamento delle valutazioni relative alle identità con privilegi eccessivi negli ambienti AWS e Google Cloud. Per migliorare le prestazioni e la scalabilità nella generazione delle raccomandazioni, le informazioni relative alle azioni non utilizzate non verranno più considerate nel calcolo delle valutazioni di overprovisioning.
Di conseguenza, la lista Unused actions non verrà più visualizzata nelle raccomandazioni relative alle identità AWS e Google Cloud. Eventuali processi, workflow o automazioni che utilizzavano questa informazione all’interno delle funzionalità Cloud Infrastructure Entitlement Management di Defender for Cloud dovranno quindi essere rivisti.
La modifica non elimina la possibilità di verificare l’effettivo utilizzo delle autorizzazioni, ma sposta questa attività sugli strumenti nativi dei rispettivi cloud provider. Per AWS è possibile utilizzare le informazioni sull’attività e sull’ultimo accesso disponibili in AWS Identity and Access Management, mentre per Google Cloud le verifiche possono essere effettuate attraverso gli strumenti IAM e Cloud Asset Inventory.
Microsoft ha quindi scelto di non acquisire e presentare più direttamente questi segnali nelle raccomandazioni multicloud, lasciandone la gestione ai servizi che ne costituiscono la fonte autoritativa. Per le organizzazioni che utilizzano Defender for Cloud come piattaforma centralizzata di CIEM, il cambiamento richiede di rivedere i processi di analisi delle permission e, dove necessario, integrare le informazioni provenienti direttamente da AWS e Google Cloud.
Backup & Resilience
Azure Site Recovery
Bring Your Own NIC in Azure Site Recovery
Azure Site Recovery supporta ora il modello Bring Your Own NIC (BYON) negli scenari Azure-to-Azure, consentendo di utilizzare e associare una Network Interface Card già esistente e pre-provisionata nella region di destinazione durante le operazioni di test failover e failover.
La funzionalità offre un maggiore controllo sulla configurazione di rete dell’ambiente di Disaster Recovery, permettendo di predisporre in anticipo le NIC necessarie e mantenerne le impostazioni già definite. Questo approccio risulta particolarmente utile negli ambienti in cui la configurazione di rete della region secondaria deve rispettare requisiti precisi di indirizzamento, sicurezza o integrazione con altri servizi.
Tra i principali vantaggi rientra la possibilità di riservare preventivamente gli indirizzi IP nella region di destinazione e di mantenere configurazioni di rete già validate, riducendo la necessità di ricreare o modificare tali impostazioni durante un evento di failover. Questo consente di rendere il processo di recovery più prevedibile e di limitare il rischio di differenze tra la configurazione progettata per il Disaster Recovery e quella effettivamente utilizzata durante l’attivazione.
Il supporto BYON contribuisce quindi a migliorare la preparazione degli scenari di continuità operativa, soprattutto nelle architetture Azure più complesse, dove il networking rappresenta spesso uno degli elementi più critici del piano di Disaster Recovery. La possibilità di predisporre e controllare in anticipo le interfacce di rete della destinazione consente di eseguire test di failover più aderenti alle condizioni reali e di aumentare il livello di determinismo delle procedure di ripristino.
Monitoring
Azure Monitor
Metriche del control plane AKS con Azure Monitor Managed Service for Prometheus
Microsoft ha reso disponibile la raccolta delle metriche del control plane di Azure Kubernetes Service tramite Azure Monitor Managed Service for Prometheus. La funzionalità offre una visibilità nativa sui principali componenti gestiti del piano di controllo AKS, migliorando le capacità di osservabilità e analisi operativa dei cluster Kubernetes.
Le metriche raccolte includono componenti chiave come API server, etcd, kube-scheduler, kube-controller-manager, cluster autoscaler e node auto-provisioning. Questi segnali permettono ai team di piattaforma di comprendere meglio il comportamento del control plane e di analizzare nel tempo il modo in cui workload, controller, meccanismi di automazione e processi di scaling interagiscono con i servizi gestiti da AKS.
La disponibilità di queste informazioni consente di individuare più facilmente eventuali anomalie, colli di bottiglia o condizioni operative che possono influenzare il comportamento del cluster. Diventa inoltre possibile correlare l’attività applicativa con eventi di scheduling, autoscaling e provisioning dei nodi, ottenendo una visione più completa delle dinamiche interne dell’ambiente Kubernetes.
L’integrazione con Azure Monitor Managed Service for Prometheus consente infine di utilizzare un modello di monitoraggio coerente con le metriche Prometheus già adottate per workload e componenti applicativi. Questo rafforza l’approccio centralizzato all’observability di AKS, mettendo a disposizione dei team operativi un insieme più completo di dati per troubleshooting, capacity planning e analisi delle prestazioni.
Conclusioni
Le novità di agosto confermano un’evoluzione sempre più orientata alla maturità operativa degli ambienti ibridi e multicloud, dove gestione del ciclo di vita, sicurezza, resilienza e observability devono essere affrontate come elementi di un unico modello operativo.
Da questo punto di vista, Azure Arc continua ad assumere un ruolo centrale: la possibilità di gestire gli Extended Security Updates di Windows Server 2016 direttamente attraverso Azure rappresenta un esempio concreto di come il servizio stia diventando il livello di controllo anche per workload legacy e infrastrutture distribuite. Allo stesso tempo, gli aggiornamenti di Defender for Cloud evidenziano quanto sia importante mantenere sotto controllo non soltanto la postura di sicurezza, ma anche le dipendenze operative da API, query e automazioni, includendole nei normali processi di lifecycle management e gestione del technical debt.
Interessanti anche gli sviluppi sul fronte operativo: la scansione malware selettiva di Defender for Storage introduce maggiore granularità nei processi di security automation, mentre il supporto Bring Your Own NIC di Azure Site Recovery rende più deterministici gli scenari di Disaster Recovery. Sul fronte monitoring, infine, l’esposizione delle metriche del control plane AKS tramite Managed Prometheus riduce ulteriormente i blind spot negli ambienti Kubernetes e permette analisi più complete delle dinamiche del cluster.
Il messaggio che emerge è quindi chiaro: centralizzare la gestione non significa soltanto avere una console comune, ma costruire processi coerenti, automatizzati e misurabili lungo l’intero ciclo di vita dell’infrastruttura. È su questo terreno che servizi come Azure Arc, Defender for Cloud, Azure Monitor e Azure Site Recovery continuano progressivamente a convergere, creando le basi per un modello di gestione sempre più proattivo e, nel tempo, sempre più supportato dall’AI.