Domande frequenti sulle macchine virtuali riservate di Azure

Le VM riservate sono una soluzione IaaS per tenant con requisiti di sicurezza e riservatezza elevati. Offerta di macchine virtuali riservate:

• Crittografia per i “dati in uso", inclusi lo stato del processore e la memoria della macchina virtuale. Le chiavi vengono generate dal processore e non possono essere rimosse.
• L'attestazione host consente di verificare l'integrità completa e la conformità del server prima dell'inizio dell'elaborazione dei dati.
• Per proteggere le chiavi, di proprietà esclusiva del tenant, è possibile collegare il modulo di protezione hardware (HSM), di cui il tenant è proprietario esclusivamente.
• Nuova architettura di avvio UEFI che supporta il sistema operativo guest per le impostazioni e le funzionalità di sicurezza avanzate.
• Un modulo TPM (Trusted Platform Module) virtuale dedicato certifica l'integrità della macchina virtuale, fornisce la gestione delle chiavi avanzata e supporta casi d'uso come BitLocker.

Le VM riservate rispondono alle preoccupazioni dei clienti relative allo spostamento di carichi di lavoro sensibili off-premise nel cloud. Le VM riservate offrono protezioni elevate per i dati dei clienti provenienti dall'infrastruttura sottostante e dagli operatori cloud. A differenza di altri approcci e soluzioni, non è necessario adattare i carichi di lavoro esistenti in base alle esigenze tecniche della piattaforma.

SEV-SNP è l'acronimo di Secure Encrypted Virtualization-Secure Nested Paging. Si tratta di una tecnologia TEE (Trusted Execution Environment) fornita da AMD e offre più protezioni: ad esempio, crittografia della memoria, chiavi CPU univoche, crittografia per lo stato del registro del processore, protezione dell'integrità, prevenzione del ripristino dello stato precedente del firmware, rafforzamento del canale laterale e restrizioni sul comportamento di interrupt ed eccezioni. Nel loro insieme, le tecnologie AMD SEV rafforzano le protezioni guest per negare all'hypervisor e ad altro codice di gestione host l'accesso alla memoria e allo stato della macchina virtuale. Le VM riservate integrano tecnologie AMD SEV-SNP e Azure come la crittografia completa del disco e il modulo di protezione hardware gestito di Azure Key Vault. È possibile crittografare i dati in uso, in transito e inattivi con chiavi sotto il proprio controllo. Con le funzionalità di attestazione di Azure integrate, è possibile stabilire in modo indipendente l'attendibilità della sicurezza, dell'integrità e dell'infrastruttura sottostante delle VM riservate.

Intel TDX è l'acronimo di Intel Trust Domain Extensions (Intel TDX) Si tratta di una tecnologia Trusted Execution Environment (TEE) fornita da Intel e offre diverse protezioni: Intel TDX usa estensioni hardware per la gestione e la crittografia della memoria e protegge sia la riservatezza che l'integrità dello stato della CPU. Inoltre, Intel TDX consente di rafforzare l'ambiente virtualizzato negando all'hypervisor, ad altro codice di gestione host e agli amministratori l'accesso alla memoria e allo stato della macchina virtuale. Le macchine virtuali riservate combinano tecnologie Intel TDX e Azure, ad esempio la crittografia del disco completo e il modulo di protezione hardware gestito di Azure Key Vault. È possibile crittografare i dati in uso, in transito e inattivi con chiavi sotto il proprio controllo.

Le VM di Azure sono già leader del settore nell'offrire sicurezza e protezione contro altri tenant e intrusi malintenzionati. Le macchine virtuali riservate di Azure aumentano queste protezioni usando ambienti di esecuzione attendibili (TEE) basati su hardware che sfruttano SEV-SNP di AMD e Intel TDX per isolare e proteggere in modo crittografico la riservatezza e l'integrità dei dati. Nessun amministratore host o servizi host (incluso l'hypervisor di Azure) può visualizzare o modificare direttamente lo stato della memoria o della CPU della macchina virtuale riservata. Inoltre, con la capacità di attestazione completa, la crittografia completa del disco del sistema operativo e i Trusted Platform Module virtuali protetti da hardware, lo stato persistente della VM è protetto in modo tale che le chiavi private e il contenuto della memoria non siano mai esposti all'ambiente di hosting non crittografato.

Attualmente i dischi del sistema operativo per le macchine virtuali riservate possono essere crittografati e protetti. Per una sicurezza aggiuntiva, è possibile abilitare la crittografia a livello guest (come BitLocker o dm-crypt) per tutte le unità dati.

Sì, ma solo se il file pagefile.sys si trova sul disco del sistema operativo crittografato. Nelle VM riservate con un disco temporaneo, il file pagefile.sys può essere spostato nel sistema operativo crittografato Suggerimenti per spostare il file pagefile.sys nell'unità c:\.

No, questa funzionalità non esiste per le macchine virtuali riservate.

Ecco alcuni modi per distribuire una macchina virtuale riservata:

• Eseguire la distribuzione dal portale di Azure
• Eseguire la distribuzione dall'interfaccia della riga di comando di Azure
• Eseguire la distribuzione usando un modello di ARM
• Eseguire la distribuzione con VMSS e Crittografia dischi riservati

Le macchine virtuali riservate di Azure in SEV-SNP AMD vengono sottoposte all'attestazione come parte della fase di avvio. Questo processo è invisibile per l'utente e viene eseguito nel sistema operativo cloud con i servizi attestazione di Microsoft Azure e Azure Key Vault. Le VM riservate consentono inoltre agli utenti di eseguire attestazioni indipendenti per le VM riservate. Questa attestazione viene eseguita utilizzando nuovi strumenti denominati Attestazione guest di VM riservate di Azure. L'attestazione guest consente ai clienti di attestare che le macchine virtuali riservate sono in esecuzione su processori AMD con SEV-SNP abilitato.

Le macchine virtuali riservate di Azure che usano Intel TDX possono essere attestate in modo trasparente come parte del flusso di avvio per garantire che la piattaforma sia conforme e aggiornata. Il processo è opaco per l'utente e viene eseguito usando Attestazione di Microsoft Azure e Azure Key Vault. Se si vuole continuare a eseguire controlli dopo l'avvio, è disponibile l'attestazione della piattaforma guest. In questo modo è possibile verificare che la macchina virtuale sia in esecuzione su Intel TDX originale. Per accedere alla funzionalità, vedere il ramo dell'anteprima. Inoltre, supportiamo Intel® Trust Authority per le aziende che hanno bisogno di attestazioni indipendenti dall'operatore. Il supporto per l'attestazione completa guest, simile a AMD SEV-SNP, sarà presto disponibile. Ciò consente alle organizzazioni di approfondire e convalidare altri aspetti, anche fino al livello dell'applicazione guest.

Per essere eseguite su una macchina virtuale riservata, le immagini del sistema operativo devono soddisfare determinati requisiti di sicurezza e compatibilità. Ciò consente di montare, attestare e isolare in modo sicuro le VM riservate dall'infrastruttura cloud sottostante. In futuro si prevede di fornire indicazioni su come realizzare una build Linux personalizzata e applicare un set di patch open source per qualificarlo come immagine di macchina virtuale riservata.

Sì. È possibile utilizzare la Raccolta di calcolo di Azure per modificare un'immagine VM riservata, ad esempio installando applicazioni. Successivamente è possibile distribuire VM riservate in base all'immagine modificata.

Lo schema di crittografia completa del disco opzionale è il più sicuro di Azure e soddisfa i principi di Confidential Computing. Tuttavia, è possibile anche utilizzare altri schemi di crittografia del disco insieme o al posto della crittografia completa del disco. Se si utilizzano più schemi di crittografia del disco, la doppia crittografia potrebbe influire negativamente sulle prestazioni.

Ogni VM riservata di Azure ha un proprio TPM virtuale, in cui i clienti possono bloccare i propri segreti/chiavi. È consigliabile per i clienti verificare lo stato del TPM virtuale (tramite TPM.msc per le VM Windows). Se lo stato non è pronto per l'uso, è consigliabile riavviare le VM prima di bloccare segreti/chiavi sul TPM virtuale.

No. Dopo aver creato una VM riservata, non è possibile disattivare o riattivare la crittografia completa del disco, ma è necessario creare una nuova macchina virtuale riservata.

Gli sviluppatori che cercano un'ulteriore "separazione dei compiti" per i servizi TCB dal provider di servizi cloud devono usare il tipo di sicurezza "NonPersistedTPM".

• Questa esperienza è disponibile solo come parte dell'anteprima pubblica di Intel TDX. Organizzazioni che la usano o forniscono servizi con essa hanno il controllo della TCB e delle responsabilità associate.
• Questa esperienza ignora i servizi nativi di Azure, consentendo di usare una soluzione propria di crittografia del disco, gestione delle chiavi e attestazione.
• Ogni macchina virtuale ha ancora un vTPM, che deve essere usato per recuperare l'evidenza hardware, tuttavia lo stato del vTPM non viene salvato in modo permanente tra un riavvio e l'altro e questo significa che questa soluzione è eccellente per carichi di lavoro temporanei e organizzazioni che desiderano la separazione dal provider di servizi cloud.

No. Per motivi di sicurezza, è necessario creare una VM riservata fin dall'inizio.

Sì, la conversione da una macchina virtuale riservata a un'altra macchina virtuale riservata è consentita sia in DCasv5/ECasv5 che in DCesv5/ECesv5 nelle aree condivise. Se si usa un'immagine di Windows, assicurarsi di avere tutti gli aggiornamenti più recenti. Se si usa un'immagine Ubuntu Linux, assicurarsi di usare l'immagine riservata Ubuntu 22.04 LTS con la versione minima del kernel 6.2.0-1011-azure.

Assicurarsi di aver selezionato un'area disponibile per le macchine virtuali riservate. Assicurarsi di selezionare anche Cancella tutti i filtri nel selettore delle dimensioni.

No. Le VM riservate non supportano la rete accelerata. Non è possibile abilitare la rete accelerata per qualsiasi distribuzione di VM riservate o per qualsiasi distribuzione di cluster del servizio Azure Kubernetes in esecuzione su Confidential Computing.

È possibile che venga visualizzato l'errore Non è stato possibile completare l'operazione poiché comporta il superamento della quota standard approvata di core della famiglia DCasv5/ECasv5. Questo errore del modello di Azure Resource Manager (modello di ARM) significa che la distribuzione non è riuscita a causa della mancanza di core di calcolo di Azure. Le sottoscrizioni della versione di prova gratuita non hanno una quota di core sufficiente per le VM riservate. Creare una richiesta di supporto per aumentare la quota.

Le serie ECasv5 e ECesv5 sono dimensioni di macchine virtuali ottimizzate per la memoria, che offrono un rapporto memoria/CPU più elevato. Queste dimensioni sono particolarmente adatte per server di database relazionali, cache di dimensioni medio-grandi e analisi in memoria.

No. Attualmente queste VM sono disponibili solo in regioni selezionate. Per un elenco aggiornato delle aree disponibili, vedere Prodotti disponibili in base all'area (Macchine virtuali).

Azure non dispone di procedure operative per concedere ai propri dipendenti l'accesso alle macchine virtuali riservate, anche se autorizzato da un cliente. Di conseguenza, diversi scenari di ripristino e supporto non sono disponibili per le VM riservate.

No, le VM riservate attualmente non supportano la virtualizzazione annidata, come ad esempio la possibilità di eseguire un hypervisor all'interno di una VM.

La fatturazione per le macchine virtuali riservate dipende dall'utilizzo e dallo spazio di archiviazione, nonché dalle dimensioni e dall'area della macchina virtuale. Le macchine virtuali riservate utilizzano un piccolo disco VMGS (Virtual Machine Guest State) crittografato di diversi megabyte. Il VMGS incapsula lo stato di sicurezza della macchina virtuale di componenti come il TPM virtuale e il bootloader UEFI. Questo disco potrebbe essere soggetto a un corrispettivo mensile per l'archiviazione. Inoltre, se si sceglie di abilitare la crittografia del disco completo facoltativa, i dischi del sistema operativo crittografati comporta costi più elevati. Per altre informazioni sui corrispettivi per l'archiviazione, vedere la guida ai prezzi per i dischi gestiti. Infine, per alcune impostazioni di sicurezza e privacy elevate, si potrebbe scegliere di creare risorse collegate, come ad esempio un pool di moduli di protezione hardware gestito. Azure fattura tali risorse separatamente dai costi delle VM riservate.

Raramente alcune macchine virtuali serie DCesv5/ECesv5 possono riscontrare una piccola differenza di orario rispetto all'ora UTC. Presto disponibile una correzione a lungo termine. Nel frattempo ecco le soluzioni alternative per le macchine virtuali Windows e Ubuntu Linux:

sc config vmictimesync start=disabled
sc stop vmictimesync

Per le immagini Ubuntu Linux, eseguire lo script seguente:

#!/bin/bash

# Backup the original chrony.conf file
cp /etc/chrony/chrony.conf /etc/chrony/chrony.conf.bak

# check chronyd.service status
status=$(systemctl is-active chronyd.service)

# check chronyd.service status is "active" or not
if [ "$status" == "active" ]; then
  echo "chronyd.service is active."
else
  echo "chronyd.service is not active. Exiting script."
  exit 1
fi

# Comment out the line with 'refclock PHC /dev/ptp_hyperv'
sed -i '/refclock PHC \/dev\/ptp_hyperv/ s/^/#/' /etc/chrony/chrony.conf

# Uncomment the lines with 'pool ntp.ubuntu.com' and other pool entries
sed -i '/#pool ntp.ubuntu.com/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 0.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 1.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 2.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf

echo "Changes applied to /etc/chrony/chrony.conf. Backup created at /etc/chrony/chrony.conf.bak."

echo "Restart chronyd service"
systemctl restart chronyd.service


echo "Check chronyd status"
systemctl status chronyd.service