Domande frequenti sulle macchine virtuali riservate di Azure

Le macchine virtuali riservate sono una soluzione IaaS per i 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 lo lasciano mai.
• L'attestazione host consente di verificare l'integrità completa e la conformità del server prima dell'inizio dell'elaborazione dei dati.
• Il modulo di protezione hardware (HSM) può essere collegato per proteggere le chiavi dei dischi di macchine virtuali riservate, 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 macchine virtuali riservate offrono protezioni elevate per i dati dei clienti 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.

edizione Standard V-SNP è l'acronimo di Secure Encrypted Virtualization-Secure Nested Paging. Si tratta di una tecnologia T edizione Enterprise Trusted Execution Environment (T edizione Enterprise) 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 rollback del firmware, protezione avanzata del canale laterale e restrizioni sul comportamento di interruzioni 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 macchine virtuali riservate sfrutta AMD edizione Standard V-SNP con tecnologie di Azure, ad esempio la crittografia a 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. Con le funzionalità di attestazione di Azure predefinite, è possibile stabilire un trust indipendente nella sicurezza, nell'integrità e nell'infrastruttura sottostante delle macchine virtuali riservate.

Intel TDX è l'acronimo di Intel Trust Domain Extensions (Intel TDX) It a Trusted Execution Environment (T edizione Enterprise) tecnologia fornita da Intel e offre più protezioni: Intel TDX usa estensioni hardware per gestire e crittografare la memoria e protegge sia la riservatezza che l'integrità dello stato della CPU. Intel TDX consente inoltre di rafforzare l'ambiente virtualizzato negando l'hypervisor, altri codici di gestione host e gli amministratori possono accedere 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 T edizione Enterprise basate su hardware, ad esempio AMD edizione Standard V-SNP 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 funzionalità di attestazione completa, la crittografia completa del disco del sistema operativo e i moduli della piattaforma trusted virtuale protetta dall'hardware, lo stato permanente è protetto in modo che le chiavi private e il contenuto della memoria non siano 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 maggiore sicurezza, è possibile abilitare la crittografia a livello di guest (ad esempio 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

Le macchine virtuali riservate di Azure in SEV-SNP AMD vengono sottoposte all'attestazione come parte della fase di avvio. Questo processo è opaco per l'utente e viene eseguito nel sistema operativo cloud con i servizi Microsoft attestazione di 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 Microsoft attestazione di 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 in Intel TDX originale. Per accedere alla funzionalità, visitare il ramo di anteprima. Inoltre, supportiamo Intel® Trust Authority per le aziende che hanno bisogno di attestazioni indipendenti dall'operatore. Il supporto per l'attestazione completa in guest, simile a AMD edizione Standard V-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 eseguire una compilazione 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 di vTPM (tramite TPM.msc per le macchine virtuali Windows). Se lo stato non è pronto per l'uso, è consigliabile riavviare le macchine virtuali prima di bloccare segreti/chiavi a vTPM.

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. Le organizzazioni che lo usano o forniscono servizi con esso sono in controllo della TCB e le responsabilità che vengono insieme a esso.
• Questa esperienza ignora i servizi nativi di Azure, consentendo di usare la propria soluzione 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 vTPM non viene salvato in modo permanente tramite riavvii, ovvero questa soluzione è eccellente per carichi di lavoro temporanei e organizzazioni che vogliono separare il 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 usi un'immagine di Windows, assicurati 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 6.2.0-1011-azureminima del kernel .

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 facoltativa full-disk, i dischi del sistema operativo crittografati comportano 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. Una correzione a lungo termine è disponibile a breve. 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