• Cloud, Guide, Sicurezza
• 11 Luglio 2026

Le macchine virtuali Azure utilizzano alcuni servizi infrastrutturali per comunicare con la piattaforma. Tra i più importanti vi sono Azure Instance Metadata Service (IMDS) (169.254.169.254) e WireServer (168.63.129.16). Questi endpoint consentono alla VM di ottenere informazioni di configurazione e di utilizzare funzionalità della piattaforma; IMDS, inoltre, permette di richiedere i token associati alle Managed Identity.

In passato, il modello di sicurezza presupponeva che i processi in esecuzione all’interno della VM fossero implicitamente attendibili. Di conseguenza, qualsiasi workload presente nella macchina virtuale poteva tentare di accedere ai servizi di metadata.

Questo approccio non è più sufficiente negli ambienti moderni, dove una singola VM può ospitare applicazioni, container, agent, runner CI/CD o altri componenti con livelli di fiducia differenti. Se uno di questi workload viene compromesso, ad esempio a causa di una vulnerabilità applicativa, potrebbe tentare di utilizzare IMDS per ottenere un token della Managed Identity e accedere alle risorse Azure per cui tale identità dispone di autorizzazioni.

Per mitigare questo rischio, Microsoft ha introdotto il Metadata Security Protocol (MSP). MSP protegge l’accesso ai servizi di metadata introducendo un modello basato su autenticazione, autorizzazione e sul principio default-closed, secondo il quale l’accesso è consentito solo ai workload esplicitamente autorizzati.

Il concetto alla base di MSP è semplice: l’appartenenza di un processo alla macchina virtuale non deve essere considerata sufficiente per autorizzarne l’accesso ai servizi infrastrutturali di Azure. In questo modo il confine di trust non coincide più con l’intera VM, ma viene limitato ai soli workload autorizzati, riducendo il rischio che processi compromessi possano sfruttare IMDS o WireServer.

Un modo semplice per capire MSP

Possiamo utilizzare l’analogia di un edificio. La VM è l’edificio. All’interno dell’edificio lavorano molte persone.

IMDS e WireServer sono locali tecnici contenenti sistemi importanti. Nel vecchio modello, il fatto di trovarsi dentro l’edificio poteva essere sufficiente per raggiungere la porta dei locali tecnici.

La sicurezza dipendeva principalmente dal fatto che nessuno non autorizzato riuscisse a entrare nell’edificio.

MSP introduce un controllo aggiuntivo. Essere dentro l’edificio non è più sufficiente. Per entrare nei locali tecnici occorre essere identificati e autorizzati.

Il confine di sicurezza si sposta quindi dalla VM nel suo complesso a specifici workload autorizzati all’interno della VM.

Configurazione di Metadata Security Protocol durante la creazione della VM

La configurazione di Metadata Security Protocol (MSP) può essere effettuata direttamente durante la creazione di una nuova macchina virtuale dal portale di Azure.

Dopo aver configurato le impostazioni principali della VM, spostatevi nella scheda Management. Nella sezione Metadata Security Protocol potete abilitare separatamente la protezione per Instance Metadata Service (IMDS) e per WireServer.

Io ho scelto di abilitare MSP per entrambi i servizi utilizzando la modalità Inline configuration, che permette di definire direttamente nel modello della macchina virtuale il comportamento del Guest Proxy Agent.

Per ciascun servizio potete selezionare la modalità di enforcement da utilizzare:

• La modalità Audit permette di osservare le richieste verso i servizi di metadata senza bloccare quelle che non rispettano le policy configurate ed è quindi utile per valutare la compatibilità dei workload esistenti.
• La modalità Enforce, invece, applica effettivamente i controlli previsti da MSP e impedisce l’accesso ai servizi di metadata alle richieste non autorizzate. Selezionando Disabled, MSP non viene applicato al servizio interessato.

Nella configurazione mostrata nella figura sotto ho selezionato Enforce sia per IMDS sia per WireServer. In questo modo le richieste verso entrambi gli endpoint vengono sottoposte ai controlli del Guest Proxy Agent e devono rispettare le regole di autorizzazione configurate.

Se state introducendo MSP in un ambiente esistente o non conoscete tutte le dipendenze delle applicazioni da IMDS e WireServer, vi consiglio di iniziare dalla modalità Audit. Dopo aver analizzato il comportamento dei workload e verificato che le applicazioni legittime continuino ad accedere correttamente ai servizi necessari, potete passare alla modalità Enforce.

Figura 1: Configurazione di Metadata Security Protocol (MSP) per IMDS e WireServer durante la creazione di una Azure VM dal portale di Azure

Abilitazione di Metadata Security Protocol su una VM esistente

Se avete creato una macchina virtuale senza abilitare Metadata Security Protocol (MSP), potete configurare successivamente la funzionalità, purché la VM e il sistema operativo utilizzato soddisfino i requisiti previsti.

Dal portale di Azure aprite la macchina virtuale e selezionate Configuration. Nella parte superiore della pagina è disponibile il pulsante Reset Metadata Security Protocol, evidenziato nella figura.

Il nome del comando può risultare poco intuitivo. L’operazione di reset avvia infatti il processo necessario per predisporre nuovamente la configurazione di MSP sulla macchina virtuale. Nel caso di una VM sulla quale MSP non era stato configurato durante la creazione, questa procedura permette di avviare la configurazione del Guest Proxy Agent e dei componenti necessari alla protezione dell’accesso a IMDS e WireServer.

Prima di procedere vi consiglio di verificare la compatibilità del sistema operativo e la presenza del Guest Proxy Agent. Questo aspetto è particolarmente importante sulle VM Linux, dove l’abilitazione di MSP su una macchina esistente richiede che l’agente sia installato e correttamente configurato.

Figura 2: Accesso al comando Reset Metadata Security Protocol nella pagina Configuration di una Azure VM esistente

Dopo aver selezionato Reset Metadata Security Protocol, nella pagina Configuration vengono rese disponibili le impostazioni di MSP per la macchina virtuale esistente.

Potete configurare separatamente IMDS e WireServer, scegliendo per ciascun servizio la modalità Inline configuration oppure Advanced configuration e il relativo Enforcement mode.

Nella configurazione mostrata nella figura sotto MSP risulta inizialmente Disabled sia per IMDS sia per WireServer. Per abilitarlo dovete selezionare Audit oppure Enforce dal menu relativo al servizio che volete proteggere.

Completata la configurazione, selezionate Apply per applicare le modifiche alla macchina virtuale.

Figura 3: Configurazione delle modalità Audit ed Enforce di Metadata Security Protocol per IMDS e WireServer su una Azure VM esistente

Se state configurando MSP su una macchina virtuale che ospita già applicazioni in produzione, vi consiglio ovviamente di utilizzare inizialmente la modalità Audit. In questo modo potete verificare quali processi accedono ai servizi di metadata e individuare eventuali dipendenze prima di applicare il blocco delle richieste non autorizzate.

Dopo aver completato le verifiche potete modificare la configurazione selezionando Enforce. Da questo momento il Guest Proxy Agent applicherà effettivamente i controlli previsti da MSP alle richieste dirette al servizio configurato.

Figura 4: Applicazione della configurazione di Metadata Security Protocol in modalità Audit per IMDS e WireServer su una Azure VM esistente

Una volta che l’ho abilitato, di fatto come lo uso?

Questa è probabilmente la domanda più importante della guida, perché la risposta è: nella maggior parte dei casi non dovete modificare le vostre applicazioni.

MSP non sostituisce IMDS, né introduce una nuova API. Le applicazioni continuano a interrogare Azure Instance Metadata Service utilizzando il consueto endpoint http://169.254.169.254 oppure richiedono i token della Managed Identity esattamente come hanno sempre fatto.

Quello che cambia è chi può effettuare la richiesta.

Modalità Audit

Quando abilitate MSP in modalità Audit, il Guest Proxy Agent intercetta tutte le richieste verso IMDS e WireServer, le analizza e registra quali processi stanno accedendo ai servizi di metadata.

Dal punto di vista dell’applicazione non cambia nulla: le richieste continuano ad essere autorizzate.

Questa modalità serve esclusivamente per capire se l’ambiente è pronto per applicare restrizioni più severe.

Modalità Enforce

Quando passate alla modalità Enforce, il Guest Proxy Agent continua a intercettare le richieste, ma questa volta applica le policy configurate.

Le richieste autorizzate vengono inoltrate normalmente verso IMDS o WireServer. Le richieste non autorizzate vengono invece bloccate prima di raggiungere il servizio di metadata.

In altre parole, MSP diventa completamente trasparente per le applicazioni autorizzate, mentre impedisce ai processi non autorizzati di utilizzare i servizi di metadata.

Quando diventa realmente interessante

La modalità Inline configuration che abbiamo utilizzato finora abilita la protezione ma non introduce regole granulari sui singoli processi.

Il vero valore di MSP emerge quando utilizzate la Advanced configuration.

In questo scenario potete definire esattamente quali processi possono accedere a IMDS e WireServer.

Pensate ad esempio a una VM che esegue:

• un’applicazione Web;
• un agente di backup;
• un software di monitoraggio;
• uno script PowerShell.

Con la configurazione avanzata potete decidere che solo l’applicazione Web possa richiedere token tramite la Managed Identity, mentre tutti gli altri processi vengono bloccati.

È proprio questo il principio del least privilege applicato ai servizi di metadata.

Quindi cosa cambia operativamente?

Per una VM tradizionale con una sola applicazione, probabilmente non noterete alcuna differenza.

Per una VM che esegue più workload, invece, MSP permette di impedire che un processo compromesso possa utilizzare la Managed Identity della macchina virtuale per ottenere token di accesso ad altri servizi Azure.

È questo il motivo per cui Microsoft consiglia di introdurre inizialmente MSP in modalità Audit, verificare quali applicazioni utilizzano realmente IMDS e successivamente passare alla modalità Enforce, applicando eventualmente anche la Advanced configuration per autorizzare soltanto i processi che devono realmente accedere ai servizi di metadata.

Configurazione avanzata di Metadata Security Protocol

La Inline configuration è sufficiente per abilitare Metadata Security Protocol, ma il vero vantaggio della soluzione si ottiene, come ho già scritto prima, utilizzando la Advanced configuration. Questa modalità permette di definire in modo granulare quali processi possono accedere agli endpoint di IMDS e WireServer, applicando il principio del least privilege direttamente all’interno della macchina virtuale.

A differenza della configurazione inline, le regole non vengono definite direttamente nella VM, ma sono contenute in un InVMAccessControlProfile, una nuova risorsa di Azure che viene pubblicata all’interno di una Azure Compute Gallery. Ogni profilo può contenere una o più versioni della configurazione e può essere associato a una o più macchine virtuali.

Il file di configurazione è in formato JSON e definisce quattro elementi fondamentali:

• Privileges, che identificano gli endpoint di IMDS o WireServer che si desidera proteggere.
• Roles, che raggruppano uno o più privilegi.
• Identities, che descrivono i processi autorizzati utilizzando informazioni quali utente, gruppo, nome del processo e percorso dell’eseguibile.
• Role Assignments, che associano le identità ai ruoli definiti.

Una volta creato il file JSON, dovete pubblicarlo come nuova versione di un InVMAccessControlProfile nella vostra Azure Compute Gallery e successivamente associarlo alla macchina virtuale. Il Guest Proxy Agent provvederà automaticamente a scaricare la configurazione e ad applicarla secondo la modalità selezionata (Audit oppure Enforce), senza che sia necessario copiare manualmente alcun file all’interno della VM.

Qui di seguito un esempio di file di regole:

Trovate tutte le indicazioni alla pagina Advanced Configuration for MSP – Azure Virtual Machines | Microsoft Learn

La fase più delicata consiste nell’identificare correttamente i processi che devono poter accedere ai servizi di metadata. Per questo motivo Microsoft consiglia di abilitare inizialmente MSP in modalità Audit, raccogliere i log prodotti dal Guest Proxy Agent e utilizzare tali informazioni per costruire automaticamente l’allowlist da utilizzare nella configurazione avanzata.

La procedura dettagliata per generare automaticamente il file rules.json partendo dai log raccolti in modalità Audit è descritta nella documentazione Microsoft:

Convert Audit Logs to an Allowlist – Azure Virtual Machines | Microsoft Learn

Seguendo questo approccio potete creare una configurazione basata sul comportamento reale delle vostre applicazioni, riducendo il rischio di bloccare processi legittimi durante il passaggio alla modalità Enforce.

Conclusioni

Metadata Security Protocol (MSP) rappresenta un importante passo avanti nella protezione delle Azure Virtual Machine, introducendo un modello di sicurezza che consente di controllare in modo puntuale l’accesso ai servizi di metadata della piattaforma.

L’abilitazione della funzionalità è semplice e può essere effettuata sia durante il provisioning della macchina virtuale sia su VM già esistenti. Il mio consiglio è di iniziare sempre dalla modalità Audit, così da analizzare il comportamento dei workload senza interrompere il funzionamento delle applicazioni. Dopo aver verificato gli accessi ai servizi di metadata, potrete passare alla modalità Enforce con la certezza di applicare policy coerenti con il vostro ambiente.

Per gli scenari più complessi, in cui una VM ospita più applicazioni, agent o workload appartenenti a domini di trust differenti, la Advanced configuration permette di implementare efficacemente il principio del least privilege, autorizzando esclusivamente i processi che devono realmente accedere a IMDS e WireServer.

Anche se si tratta di una funzionalità relativamente recente, consiglio di iniziare a sperimentarla fin da subito, soprattutto negli ambienti che utilizzano Managed Identity per l’accesso ai servizi Azure. Ridurre la superficie di attacco verso gli endpoint di metadata rappresenta infatti un ulteriore livello di difesa che può contribuire a limitare l’impatto di vulnerabilità applicative o dell’esecuzione di codice non autorizzato all’interno della macchina virtuale.