(Anteprima) Aggiornare le macchine virtuali di Azure Gen1 esistenti all'avvio attendibile

Si applica a: ✔️ MACCHINA virtuale ✔️ ✔️ Windows vm Linux generazione 1

Azure Macchine virtuali supporta l'aggiornamento di macchine virtuali di prima generazione alla seconda generazione eseguendo l'aggiornamento al tipo di sicurezza Avvio attendibile.

L'Avvio attendibile è un modo per abilitare la sicurezza di calcolo di base nelle VM di seconda generazione di Azure e protegge da tecniche di attacco avanzate e persistenti, ad esempio bootkit e rootkit. A tale scopo, combinare tecnologie dell'infrastruttura come avvio protetto, virtual Trusted Platform Module (vTPM) e il monitoraggio dell'integrità di avvio nella VM.

Importante

Il supporto per l'aggiornamento delle macchine virtuali gen1 esistenti all'avvio attendibile è attualmente in anteprima. L'aggiornamento di macchine virtuali gen1 a Gen2 senza abilitare l'avvio attendibile non è supportato.

Prerequisiti

• La sottoscrizione viene inserita nella funzionalità Gen1ToTLMigrationPreview di anteprima nello Microsoft.Compute spazio dei nomi . Vedere Configurare le funzionalità di anteprima nella sottoscrizione di Azure
• La macchina virtuale di Azure è configurata con:
  • Famiglia di dimensioni supportate per l'Avvio attendibile.
  • Versione del sistema operativo supportata dall'avvio attendibile (escluso Windows Server 2016, Debian, Azure Linux). Per le immagini o i dischi del sistema operativo personalizzati, l'immagine di base deve essere compatibile con l'Avvio attendibile.
• La macchina virtuale di Azure non usa funzionalità attualmente non supportate con l'avvio attendibile.
• Backup di Azure se abilitato per le VM deve essere configurato con i criteri di Backup avanzato. Il tipo di sicurezza Avvio attendibile non può essere abilitato per le macchine virtuali configurate con la protezione di backup dei criteri Standard.
  • È possibile eseguire la migrazione del backup di VM di Azure esistenti dal criterio Standard a quello Avanzato. Seguire la procedura contenuta in Eseguire la migrazione di backup di VM di Azure da criteri standard a criteri avanzati (anteprima).
• Aggiornare una macchina virtuale gen1 di test all'avvio attendibile e determinare se sono necessarie modifiche per soddisfare i prerequisiti prima di aggiornare le macchine virtuali Gen1 associate ai carichi di lavoro di produzione all'avvio attendibile.
• Disabilitare qualsiasi crittografia del volume del sistema operativo Windows, incluso BitLocker prima dell'aggiornamento, se abilitata. Tutte le crittografia del volume del sistema operativo Windows devono essere riabilitate dopo l'aggiornamento riuscito. Questa azione non è necessaria per i dischi dati o per il volume del sistema operativo Linux.

Configurazioni di macchine virtuali gen1 non supportate

L'aggiornamento della macchina virtuale da generazione 1 a avvio attendibile non è supportato se la macchina virtuale Gen1 è configurata con:

• Carichi di lavoro di produzione: la funzionalità di anteprima deve essere usata solo per il test, la valutazione e il feedback. I carichi di lavoro di produzione non sono consigliati.
• Sistema operativo: Windows Server 2016, Azure Linux, Debian e qualsiasi altro sistema operativo non elencato in Versione del sistema operativo supportata dall'avvio attendibile. Solo per Windows Server 2016, la soluzione alternativa consiste nell'aggiornare il sistema operativo guest a Windows Server 2019 o 2022.
• Dimensioni macchina virtuale: macchina virtuale gen1 configurata con dimensioni della macchina virtuale non elencate in Famiglie di dimensioni supportate per l'avvio attendibile. Come soluzione alternativa, aggiornare le dimensioni della macchina virtuale in Famiglia di dimensioni della macchina virtuale supportate per l'avvio attendibile.
• Backup di Azure: macchina virtuale Gen1 configurata con Backup di Azure usando i criteri Standard. Come soluzione alternativa, eseguire la migrazione dei backup di macchine virtuali Gen1 dai criteri Standard a Avanzati.
• BitLocker o crittografia equivalente: il volume del sistema operativo guest della macchina virtuale Windows Gen1 viene crittografato usando BitLocker o la tecnologia di crittografia equivalente. Come soluzione alternativa, disabilitare la crittografia del volume del sistema operativo Windows prima dell'aggiornamento e riabilitare dopo il completamento corretto dell'aggiornamento dell'avvio attendibile.

Procedure consigliate

• Creare punti di ripristino per le macchine virtuali di Azure associate ai carichi di lavoro di produzione prima di abilitare il tipo di sicurezza Avvio attendibile. È possibile usare i punti di ripristino per ricreare i dischi e la macchina virtuale con lo stato noto precedente.
• Esaminare i problemi noti prima di eseguire l'aggiornamento dell'avvio attendibile.
• Non sarà possibile estendere il volume del sistema operativo Windows dopo MBR to GPT conversion l'aggiornamento. È consigliabile estendere il volume di sistema per un futuro prima dell'aggiornamento all'avvio attendibile.
• Il volume del disco del sistema operativo Windows deve essere deframmentato tramite il comando Defrag C: /U /V. La deframmentazione del volume del sistema operativo riduce il rischio di errori di conversione MBR (record di avvio master) in GPT (tabella di partizione GUID) liberando la fine delle partizioni. Fare riferimento alla deframmentazione.

Aggiornare il volume del sistema operativo guest

Le macchine virtuali di seconda generazione richiedono un volume del sistema operativo guest con le configurazioni seguenti:

• Layout del disco GPT: il volume del sistema operativo guest delle macchine virtuali Gen1 è principalmente impostato su MBR e richiede l'aggiornamento a GPT
• Partizione di sistema EFI: il volume del sistema operativo guest delle macchine virtuali Gen1 non include principalmente questa partizione.

Completare l'aggiornamento del volume del sistema operativo con la configurazione necessaria prima di aggiornare la macchina virtuale di Azure Gen1 all'avvio attendibile.

Importante

• Lo script di orchestrazione basato su PowerShell viene pubblicato come materiale sussidiario che orchestra tutti i passaggi di aggiornamento, inclusa la convalida MBR2GPT per Windows e Linux e la conversione per il sistema operativo Windows. È possibile accedere allo script di linee guida insieme alla documentazione necessaria nel repository GitHub per l'aggiornamento della macchina virtuale di avvio attendibile di Azure Gen1 a Gen2
• Aggiornare una macchina virtuale gen1 di test all'avvio attendibile e determinare se sono necessarie modifiche per soddisfare i prerequisiti prima di aggiornare le macchine virtuali Gen1 associate ai carichi di lavoro di produzione all'avvio attendibile.

Windows

Usando l'utilità MBR2GPT.exe predefinita, è possibile abilitare GPT il layout del disco e aggiungere EFI system partition obbligatorio per l'aggiornamento di Gen2.

Attenzione

Non sarà possibile estendere il volume del sistema operativo Windows dopo MBR to GPT conversion. È consigliabile estendere il volume di sistema per un futuro prima di eseguire l'aggiornamento.

Nota

Windows Server 2016 non supporta MBR2GPT.exe. La soluzione alternativa consiste nell'aggiornare il sistema operativo guest a Windows Server 2019 o 2022 e quindi eseguire MBR to GPT conversion. Vedere Aggiornamento sul posto per le macchine virtuali che eseguono Windows Server in Azure.

1. RDP o connettersi in remoto alla macchina virtuale Windows Gen1 per l'esecuzione della conversione.

2. Eseguire il comando MBR2GPT /validate /allowFullOS e assicurarsi che Disk layout validation venga completato correttamente. Non procedere se l'oggetto Disk layout validation ha esito negativo. Fare riferimento a Problemi noti per l'elenco delle cause comuni e della risoluzione associata per l'errore. Per altre informazioni e risoluzione dei problemi, vedere MBR2GPT risoluzione dei problemi.

3. Eseguire il comando MBR2GPT /convert /allowFullOS per eseguire la conversione MBR in GPT. Esempio di output riuscito:

   If conversion is successful the disk can only be booted in GPT mode.
   These changes cannot be undone!
   
   MBR2GPT: Attempting to convert disk 0
   MBR2GPT: Retrieving layout of disk
   MBR2GPT: Validating layout, disk sector size is: 512 bytes
   MBR2GPT: Trying to shrink the OS partition
   MBR2GPT: Creating the EFI system partition
   MBR2GPT: Installing the new boot files
   MBR2GPT: Performing the layout conversion
   MBR2GPT: Migrating default boot entry
   MBR2GPT: Adding recovery boot entry
   MBR2GPT: Fixing drive letter mapping
   MBR2GPT: Conversion completed successfully
   MBR2GPT: Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!
   

Linux

Importante

L'aggiornamento delle macchine virtuali Linux di Azure Gen1 esistenti all'avvio attendibile è supportato solo per le macchine virtuali create usando immagini del sistema operativo supportate pubblicate in Azure Marketplace (escluso Debian, Azure Linux).

Le macchine virtuali Linux di Azure Gen1 create con le distribuzioni approvate (Canonical, RHEL, SUSE) pubblicate in Azure Marketplace non richiedono alcuna modifica nel volume del sistema operativo guest. Ovvero, hanno GPT già il layout del disco e EFI system partition sono configurati. Per altre macchine virtuali Linux di Azure Gen1 che richiedono questo supporto per l'aggiornamento, tra cui Azure Linux e Debian, inviare la registrazione in Linux Gen1 al supporto per l'aggiornamento dell'avvio attendibile.

Convalidare l'idoneità del volume del sistema operativo guest per l'aggiornamento dell'avvio attendibile con i comandi seguenti. NON procedere con l'aggiornamento dell'avvio attendibile se uno dei passaggi di convalida ha esito negativo.

1. Ssh o connettersi in remoto alla macchina virtuale Linux Gen1 per l'esecuzione di comandi di convalida.

2. Identificare il dispositivo di avvio e archiviare la variabile.
   bootDevice=$(echo "/dev/$(sudo lsblk -no pkname $(sudo df /boot | awk 'NR==2 {print $1}'))")

3. Controllare il tipo di disco del dispositivo di avvio. L'output del comando deve restituire gpt.
   sudo blkid $bootDevice -o value -s PTTYPE

4. Verificare se EFI system partition è disponibile nel volume di avvio. L'output del comando deve restituire una partizione specifica, ad esempio \dev\sda3.
   sudo fdisk -l $bootDevice | grep EFI | awk '{print $1}'

5. Verificare che il punto di montaggio EFI sia configurato. L'output del comando deve restituire /boot/efi present in /etc/fstab
sudo grep -qs '/boot/efi' /etc/fstab && echo '/boot/efi present in /etc/fstab' || echo '/boot/efi missing in /etc/fstab'

Aggiornare la macchina virtuale Gen1 all'avvio attendibile

Nota

• Dopo aver abilitato l'Avvio attendibile, attualmente non è possibile eseguire il rollback delle VM al tipo di sicurezza Standard (configurazione di Avvio non attendibile).
• vTPM è abilitato per impostazione predefinita.
• È consigliabile abilitare l'avvio protetto, se non si usano driver o kernel non firmati personalizzati. Non è abilitata per impostazione predefinita. L'Avvio protetto mantiene l'integrità dell'avvio e abilita la sicurezza di base per le VM.

PowerShell

Assicurarsi di aver installato la versione più recente di Azure PowerShell e di aver effettuato l'accesso a un account Azure con Connect-AzAccount.

Importante

Lo script di orchestrazione basato su PowerShell viene pubblicato come materiale sussidiario che orchestra tutti i passaggi di aggiornamento, inclusa la conversione MBR2GPT. È possibile accedere allo script di linee guida insieme alla documentazione necessaria nel repository GitHub per l'aggiornamento della macchina virtuale di avvio attendibile di Azure Gen1 a Gen2

Seguire la procedura per aggiornare la macchina virtuale Gen1 esistente a Gen2 e abilitare l'avvio attendibile usando Azure PowerShell.

1. Accedere alla sottoscrizione di Azure della VM.

   Connect-AzAccount -SubscriptionId 00000000-0000-0000-0000-000000000000
   

2. Deallocare la VM.

   Stop-AzVM -ResourceGroupName myResourceGroup -Name myVm
   

3. Abilitare Avvio attendibile impostando -SecurityType su TrustedLaunch.

   Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm `
       | Update-AzVM -SecurityType TrustedLaunch `
           -EnableSecureBoot $true -EnableVtpm $true
   

4. Convalidare securityProfile nella configurazione aggiornata della VM.

   # Following command output should be `TrustedLaunch`
   
   (Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm `
       | Select-Object -Property SecurityProfile `
           -ExpandProperty SecurityProfile).SecurityProfile.SecurityType
   
   # Following command output should return `SecureBoot` and `vTPM` settings
   (Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm `
       | Select-Object -Property SecurityProfile `
           -ExpandProperty SecurityProfile).SecurityProfile.Uefisettings
   
   

5. Avviare la VM.

   Start-AzVM -ResourceGroupName myResourceGroup -Name myVm
   

6. Avviare la VM di Avvio attendibile aggiornata. Verificare che sia possibile accedere alla VM usando RDP (per le VM Windows) o SSH (per le VM Linux).

CLI

Seguire la procedura per aggiornare la macchina virtuale Gen1 esistente a Gen2 e abilitare l'avvio attendibile usando l'interfaccia della riga di comando di Azure.

Assicurarsi di aver installato la versione più recente dell'interfaccia della riga di comando di Azure e di aver effettuato l'accesso a un account Azure con az login.

1. Accedere alla sottoscrizione di Azure della VM.

   az login
   
   az account set --subscription 00000000-0000-0000-0000-000000000000
   

2. Deallocare la VM.

   az vm deallocate \
      --resource-group myResourceGroup --name myVm
   

3. Abilitare Avvio attendibile impostando --security-type su TrustedLaunch.

   az vm update \
       --resource-group myResourceGroup --name myVm \
       --security-type TrustedLaunch \
       --enable-secure-boot true --enable-vtpm true
   

4. Convalidare l'output del comando precedente. Verificare che la configurazione securityProfile venga restituita con l'output del comando.

   {
     "securityProfile": {
       "securityType": "TrustedLaunch",
       "uefiSettings": {
         "secureBootEnabled": true,
         "vTpmEnabled": true
       }
     }
   }
   

5. Avviare la VM.

   az vm start \
       --resource-group myResourceGroup --name myVm
   

6. Avviare la VM di Avvio attendibile aggiornata. Verificare che sia possibile accedere alla VM usando RDP (per le VM Windows) o SSH (per le VM Linux).

Modello

Seguire la procedura per abilitare l'Avvio attendibile in una VM di Azure Generation 2 esistente usando un modello di ARM.

Un modello di Azure Resource Manager è un file JSON (JavaScript Object Notation) che definisce l'infrastruttura e la configurazione del progetto. Il modello utilizza la sintassi dichiarativa. Si descrive la distribuzione prevista senza scrivere la sequenza di comandi di programmazione necessari per creare la distribuzione.

1. Esaminare il modello.

   {
       "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
       "contentVersion": "1.0.0.0",
       "parameters": {
           "vmsToUpgrade": {
               "type": "object",
               "metadata": {
                   "description": "Specifies the list of Azure virtual machines to be upgraded to Trusted launch."
               }
           },
           "vTpmEnabled": {
               "type": "bool",
               "defaultValue": true,
               "metadata": {
                   "description": "Specifies whether vTPM should be enabled on the virtual machine."
               }
           }
       },
       "resources": [
           {
               "type": "Microsoft.Compute/virtualMachines",
               "apiVersion": "2022-11-01",
               "name": "[parameters('vmsToUpgrade').virtualMachines[copyIndex()].vmName]",
               "location": "[parameters('vmsToUpgrade').virtualMachines[copyIndex()].location]",
               "properties": {
                   "securityProfile": {
                       "uefiSettings": {
                           "secureBootEnabled": "[parameters('vmsToUpgrade').virtualMachines[copyIndex()].secureBootEnabled]",
                           "vTpmEnabled": "[parameters('vTpmEnabled')]"
                       },
                       "securityType": "TrustedLaunch"
                   }
               },
               "copy": {
                   "name": "vmCopy",
                   "count": "[length(parameters('vmsToUpgrade').virtualMachines)]"
               }
           }
       ]
   }
   

2. Modificare il file JSON parameters con le VM da aggiornare con il tipo di sicurezza TrustedLaunch.

   {
       "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
       "contentVersion": "1.0.0.0",
       "parameters": {
           "vmsToUpgrade": {
               "value": {
                   "virtualMachines": [
                       {
                           "vmName": "myVm01",
                           "location": "westus3",
                           "secureBootEnabled": true
                       },
                       {
                           "vmName": "myVm02",
                           "location": "westus3",
                           "secureBootEnabled": true
                       }
                   ]
               }
           }
       }
   }
   

   Definizione del file dei parametri

   Proprietà	Descrizione della proprietà	Valore di esempio del modello
   vmName	Nome della macchina virtuale di Azure.	myVm
   location	Posizione della macchina virtuale di Azure.	westus3
   secureBootEnabled	Abilitare l'Avvio protetto con tipo di sicurezza Avvio attendibile.	true

3. Deallocare tutte le macchine virtuali di Azure da aggiornare.

   Stop-AzVM -ResourceGroupName myResourceGroup -Name myVm01
   

4. Eseguire la distribuzione del modello di ARM.

   $resourceGroupName = "myResourceGroup"
   $parameterFile = "folderPathToFile\parameters.json"
   $templateFile = "folderPathToFile\template.json"
   
   New-AzResourceGroupDeployment `
       -ResourceGroupName $resourceGroupName `
       -TemplateFile $templateFile -TemplateParameterFile $parameterFile
   

   

   

5. Avviare la VM di Avvio attendibile aggiornata. Verificare che sia possibile accedere alla VM usando RDP (per le VM Windows) o SSH (per le VM Linux).

Problemi noti

L'avvio di Windows 11 non riesce dopo l'aggiornamento dell'avvio attendibile della macchina virtuale Windows 10

La macchina virtuale Windows 10 Gen1 viene aggiornata correttamente all'avvio attendibile seguito dall'aggiornamento sul posto di Windows 11. Tuttavia, l'avvio di Windows 11 ha esito negativo dopo che la macchina virtuale di Azure è stata arrestata e avviata con l'errore visualizzato.

Risoluzione: questo problema è stato risolto con la build 24H2 26100.2314.

[Windows] La conversione da MBR a GPT non riesce con errore Non è possibile trovare spazio per la partizione di sistema EFI

Questo errore si verifica per uno dei motivi seguenti:

• Non è disponibile spazio disponibile nel volume di sistema
• Il volume di sistema è danneggiato. È possibile convalidare provando a compattare il volume di pochi MB nella console di gestione dischi. Usare il comando chkdsk C:/v/f per ripristinare il volume di sistema.
• Virtual Disk il servizio non è in esecuzione o non è in grado di comunicare correttamente. Il tipo di avvio del servizio deve essere impostato su Manual.
• Optimize Drives il servizio non è in esecuzione o non è in grado di comunicare correttamente. Il tipo di avvio del servizio deve essere impostato su Manual.
• Il disco del volume di sistema è già configurato con quattro partizioni MBR (massimo supportato dal layout del disco MBR). È necessario eliminare una delle partizioni per liberare spazio per la partizione di sistema EFI.
  1. Eseguire ReAgentc /info per identificare attivamente la partizione usata dal ripristino. Esempio: Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
  2. Eseguire il cmdlet Get-Partition -DiskNumber 0 di PowerShell per identificare le partizioni correnti configurate.
  3. Eseguire il cmdlet Remove-Partition -DiskNumber 0 -PartitionNumber X di PowerShell per rimuovere qualsiasi partizione di ripristino aggiuntiva non usata attivamente dal servizio di ripristino, come indicato nel passaggio 1.

[Windows] MbR a GPT non è riuscito ad aggiornare ReAgent.xml

Per alcune versioni del sistema operativo Windows come Windows 10, MBR2GPT genera un errore pass-through MBR2GPT: Failed to update ReAgent.xml, please try to manually disable and enable WinRE.

L'avviso indica che MBR2GPT.exe non è stato possibile aggiornare il GUID della partizione di ripristino in C:\Windows\System32\Recovery\ReAgent.xml. Questo problema non dovrebbe causare problemi con la funzionalità del sistema operativo guest o altre operazioni di aggiornamento come l'aggiornamento di Windows 11 per avere esito positivo o Windows 11 per funzionare correttamente dopo l'aggiornamento. ReAgent.xml viene aggiornato con il GUID corretto dopo l'aggiornamento di Windows 11, ovvero se non si esegue alcuna azione tra MBR2GPT conversione e aggiornamento di Windows 11, il valore GUID in ReAgent.xml viene sincronizzato con la configurazione di ripristino di Windows.

Per correggere manualmente l'avviso, puoi disabilitare e riabilitare WinRE post MBR2GPT conversione o post-gen1 all'aggiornamento dell'avvio attendibile prima dell'aggiornamento di Windows 11 usando i passaggi elencati, questi passaggi forzano la sincronizzazione del GUID WinRE in ReAgent.xml

1. Completa Gen1 -> Aggiornamento dell'avvio attendibile.
2. Eseguire reagentc /disable
3. Eseguire reagentc /enable
4. Eseguire reagentc /info
5. Aprire C:\Windows\System32\Recovery\ReAgent.xml e convalidare il GUID BCD nel file xml corrisponde all'output del passaggio 4.

[Windows] Unità D assegnata all'aggiornamento post-aggiornamento riservato del sistema

L'assegnazione temporanea della lettera di unità di archiviazione 'D' viene modificata in 'E' con la lettera precedente assegnata alla macchina virtuale Riservata dal sistema dopo l'aggiornamento della macchina virtuale Gen1. Eseguire i passaggi seguenti manualmente dopo l'aggiornamento per risolvere il problema:

Dopo l'aggiornamento, controllare i dischi nel server, se la partizione riservata del sistema ha la lettera D, eseguire le azioni seguenti:

1. Riconfigurare il file di pagina da D: a C:
2. Riavviare la macchina virtuale
3. Rimuovere la lettera D: dalla partizione
4. Riavviare la macchina virtuale per visualizzare il disco di archiviazione temporaneo con D: lettera

Il riferimento all'immagine della macchina virtuale non cambia dopo l'aggiornamento dell'avvio attendibile

Dopo l'aggiornamento della macchina virtuale di Azure Gen1 all'avvio attendibile, il riferimento all'immagine riflette ancora l'origine come immagine del sistema operativo Gen1. Il riferimento all'immagine non aggiornato è una limitazione nota e verrà risolto con la versione di disponibilità generale di Gen1 al supporto per l'aggiornamento della macchina virtuale di avvio attendibile.

Domande frequenti

Cosa accade se sono presenti macchine virtuali di prima generazione, che non soddisfano i prerequisiti per l'avvio attendibile?

Per una macchina virtuale di prima generazione che non soddisfa i prerequisiti per l'aggiornamento all'avvio attendibile, vedere come soddisfare i prerequisiti. Ad esempio, se si usano dimensioni di macchina virtuale non supportate, cercare le dimensioni supportate di avvio attendibili equivalenti che supportano l'avvio attendibile.

Perché l'aggiornamento alla generazione 2 è solo (senza avvio attendibile) non supportato?

L'avvio attendibile abilita la sicurezza di calcolo di base nelle macchine virtuali di prima generazione di Azure senza costi aggiuntivi associati. Inoltre, le macchine virtuali di avvio attendibili sono principalmente in parità con le macchine virtuali di seconda generazione. Di conseguenza, non esiste alcun vantaggio aggiuntivo per l'aggiornamento solo alla macchina virtuale di seconda generazione senza abilitare l'avvio attendibile.

Contenuto correlato

• Per abilitare l'avvio attendibile nelle nuove distribuzioni di macchine virtuali e set di scalabilità, vedere Deploy Trusted launch virtual machines (Distribuisci macchine virtuali di avvio attendibile per abilitare l'avvio attendibile nelle nuove distribuzioni di macchine virtuali e set di scalabilità).
• Vedere Monitoraggio dell'integrità di avvio per abilitare il monitoraggio dell'integrità dell'avvio e monitorare l'integrità della macchina virtuale usando Microsoft Defender per il cloud.
• Altre informazioni su Avvio attendibile e le domande frequenti.