Trasferire una sottoscrizione di Azure in una directory di Microsoft Entra diversa

Le organizzazioni potrebbero avere diverse sottoscrizioni di Azure. Ogni sottoscrizione è associata a una specifica directory di Microsoft Entra. Per semplificare la gestione, è possibile provare a trasferire una sottoscrizione in una directory di Microsoft Entra diversa. Quando si trasferisce una sottoscrizione in una directory di Microsoft Entra diversa, alcune risorse non vengono trasferite nella directory di destinazione. Ad esempio, tutte le assegnazioni di ruolo e i ruoli personalizzati nel controllo degli accessi in base al ruolo di Azure vengono eliminati definitivamente dalla directory di origine e non vengono trasferiti alla directory di destinazione.

Questo articolo descrive i passaggi di base che è possibile seguire per trasferire una sottoscrizione a un'altra directory di Microsoft Entra e ricreare alcune delle risorse dopo il trasferimento.

Se invece si vuole bloccare il trasferimento delle sottoscrizioni in directory diverse nell'organizzazione, è possibile configurare un criterio di sottoscrizione. Per altre informazioni, vedere Gestire i criteri di sottoscrizione di Azure.

Nota

Per gli abbonamenti ad Azure Cloud Solution Provider (CSP), la modifica della directory di Microsoft Entra per l'abbonamento non è supportata.

Panoramica

Il trasferimento di una sottoscrizione di Azure in una directory Microsoft Entra è un processo complesso che deve essere pianificato ed eseguito con attenzione. Molti servizi di Azure richiedono che le entità di sicurezza (identità) funzionino normalmente o gestiscano persino altre risorse di Azure. Questo articolo tenta di trattare la maggior parte dei servizi di Azure che dipendono principalmente dalle entità di sicurezza, ma non è completo.

Importante

In alcuni scenari, il trasferimento di una sottoscrizione potrebbe richiedere tempi di inattività per completare il processo. È necessaria un'attenta pianificazione per valutare se saranno necessari tempi di inattività per il trasferimento.

Il diagramma seguente illustra i passaggi di base da seguire quando si trasferisce una sottoscrizione in una directory diversa.

1. Preparare il trasferimento

2. Trasferire la sottoscrizione di Azure in una directory diversa

3. Ricreare risorse nella directory di destinazione, ad esempio assegnazioni di ruolo, ruoli personalizzati e identità gestite

   

Decidere se trasferire una sottoscrizione in una directory diversa

Di seguito sono riportati alcuni motivi per cui si potrebbe voler trasferire una sottoscrizione:

• A causa di una fusione o acquisizione di una società, si vuole gestire una sottoscrizione acquisita nella directory primaria di Microsoft Entra.
• Un utente dell'organizzazione ha creato una sottoscrizione e si vuole consolidare la gestione in una determinata directory di Microsoft Entra.
• Sono disponibili applicazioni che dipendono da un determinato ID sottoscrizione o URL e non è facile modificare la configurazione o il codice dell'applicazione.
• Si è verificata una scissione di una parte dell'azienda ed è necessario spostare alcune risorse in una directory di Microsoft Entra diversa.
• Si desidera gestire alcune risorse in una directory di Microsoft Entra diversa a scopo di isolamento della sicurezza.

Approcci alternativi

Il trasferimento di una sottoscrizione richiede tempi di inattività per completare il processo. A seconda dello scenario, è possibile considerare gli approcci alternativi seguenti:

• Ricreare le risorse e copiare i dati nella directory e nella sottoscrizione di destinazione.
• Adottare un'architettura a più directory e lasciare la sottoscrizione nella directory di origine. Usare Azure Lighthouse per delegare le risorse in modo che gli utenti nella directory di destinazione possano accedere alla sottoscrizione nella directory di origine. Per altre informazioni, vedere Azure Lighthouse in scenari aziendali.

Comprendere l'impatto del trasferimento di una sottoscrizione

Diverse risorse di Azure hanno una dipendenza da una sottoscrizione o da una directory. A seconda della situazione, la tabella seguente elenca l'impatto noto del trasferimento di una sottoscrizione. Eseguendo la procedura descritta in questo articolo, è possibile ricreare alcune delle risorse esistenti prima del trasferimento della sottoscrizione.

Importante

Questa sezione elenca i servizi o le risorse di Azure noti che dipendono dalla sottoscrizione. Poiché i tipi di risorse in Azure sono in continua evoluzione, potrebbero esserci dipendenze aggiuntive non elencate qui che possono causare una modifica che causa un'interruzione dell'ambiente.

Servizio o risorsa	Influenzato	Recuperabile	Sei interessato?	Operazione
Assegnazioni di ruolo	Sì	Sì	Elencare le assegnazioni di ruolo	Tutte le assegnazioni di ruolo vengono eliminate definitivamente. È necessario eseguire il mapping di utenti, gruppi ed entità servizio agli oggetti corrispondenti nella directory di destinazione. È necessario ricreare le assegnazioni di ruolo.
Ruoli personalizzati	Sì	Sì	Elencare i ruoli personalizzati	Tutti i ruoli personalizzati vengono eliminati definitivamente. È necessario ricreare i ruoli personalizzati e le assegnazioni di ruolo.
Identità gestite assegnate dal sistema	Sì	Sì	Elencare le identità gestite	È necessario disabilitare e riabilitare le identità gestite. È necessario ricreare le assegnazioni di ruolo.
Identità gestite assegnate dall'utente	Sì	Sì	Elencare le identità gestite	È necessario eliminare, ricreare e collegare le identità gestite alla risorsa appropriata. È necessario ricreare le assegnazioni di ruolo.
Azure Key Vault	Sì	Sì	Elencare i criteri di accesso di Key Vault	È necessario aggiornare l'ID tenant associato agli insiemi di credenziali delle chiavi. È necessario rimuovere e aggiungere nuovi criteri di accesso.
Database SQL di Azure con l'integrazione dell'autenticazione di Microsoft Entra abilitata	Sì	No	Controllare i database SQL di Azure con l'autenticazione Microsoft Entra	Non è possibile trasferire un database SQL di Azure con l'autenticazione Di Microsoft Entra abilitata in una directory diversa. Per altre informazioni, vedere Utilizzare l'autenticazione di Microsoft Entra.
Database di Azure per MySQL con l'integrazione dell'autenticazione di Microsoft Entra abilitata	Sì	No		Non è possibile trasferire un database di Azure per MySQL (server singolo e flessibile) con l'autenticazione di Microsoft Entra abilitata in una directory diversa.
Archiviazione di Azure e Azure Data Lake Archiviazione Gen2	Sì	Sì		È necessario ricreare gli elenchi di controllo di accesso.
Azure Data Lake Storage Gen1	Sì	Sì		È necessario ricreare gli elenchi di controllo di accesso.
File di Azure	Sì	Sì		È necessario ricreare gli elenchi di controllo di accesso.
Sincronizzazione file di Azure	Sì	Sì		Il servizio di sincronizzazione archiviazione e/o l'account di archiviazione possono essere spostati in una directory diversa. Per altre informazioni, vedere Domande frequenti su File di Azure
Azure Managed Disks	Sì	Sì		Se si usano set di crittografia dischi per crittografare Managed Disks con chiavi gestite dal cliente, è necessario disabilitare e riabilitare le identità assegnate dal sistema associate ai set di crittografia dischi. Inoltre, è necessario ricreare le assegnazioni di ruolo, ovvero concedere nuovamente le autorizzazioni necessarie ai set di crittografia dischi negli insiemi di credenziali delle chiavi.
Servizio Azure Kubernetes	Sì	No		Non è possibile trasferire il cluster del servizio Azure Kubernetes e le relative risorse associate in una directory diversa. Per altre informazioni, vedere Domande frequenti su servizio Azure Kubernetes (servizio Azure Kubernetes)
Criteri di Azure	Sì	No	Tutti gli oggetti Criteri di Azure, incluse definizioni personalizzate, assegnazioni, esenzioni e dati di conformità.	È necessario esportare, importare e assegnare nuovamente le definizioni. Creare quindi nuove assegnazioni di criteri ed eventuali esenzioni dei criteri necessarie.
Servizi di dominio Microsoft Entra	Sì	No		Non è possibile trasferire un dominio gestito di Microsoft Entra Domain Services in una directory diversa. Per altre informazioni, vedere Domande frequenti su Microsoft Entra Domain Services
Registrazioni app	Sì	Sì
Microsoft Dev Box	Sì	No		Non è possibile trasferire una casella di sviluppo e le relative risorse associate in una directory diversa. Una volta spostata una sottoscrizione in un altro tenant, non sarà possibile eseguire alcuna azione nella casella di sviluppo
Ambienti di distribuzione di Azure	Sì	No		Non è possibile trasferire un ambiente e le relative risorse associate in una directory diversa. Una volta spostata una sottoscrizione in un altro tenant, non sarà possibile eseguire alcuna azione nell'ambiente
Azure Service Fabric	Sì	No		È necessario ricreare il cluster. Per altre informazioni, vedere Domande frequenti sui cluster SF o Domande frequenti sui cluster gestiti sf
Bus di servizio di Azure	Sì	Sì		È necessario eliminare, ricreare e collegare le identità gestite alla risorsa appropriata. È necessario ricreare le assegnazioni di ruolo.
Area di lavoro di Azure Synapse Analytics	Sì	Sì		È necessario aggiornare l'ID tenant associato all'area di lavoro Synapse Analytics. Se l'area di lavoro è associata a un repository Git, è necessario aggiornare la configurazione Git dell'area di lavoro. Per altre informazioni, vedere Ripristino dell'area di lavoro synapse Analytics dopo il trasferimento di una sottoscrizione a un'altra directory di Microsoft Entra (tenant).
Azure Databricks	Sì	No		Attualmente Azure Databricks non supporta lo spostamento delle aree di lavoro in un nuovo tenant. Per altre informazioni, vedere Gestire l'account Azure Databricks.

Avviso

Se si usa la crittografia dei dati inattivi per una risorsa, ad esempio un account di archiviazione o un database SQL, che ha una dipendenza da un insieme di credenziali delle chiavi che viene trasferito, può causare uno scenario irreversibile. Se si verifica questa situazione, è consigliabile adottare misure per usare un insieme di credenziali delle chiavi diverso o disabilitare temporaneamente le chiavi gestite dal cliente per evitare questo scenario irreversibile.

Per ottenere un elenco di alcune delle risorse di Azure interessate quando si trasferisce una sottoscrizione, è anche possibile eseguire una query in Azure Resource Graph. Per una query di esempio, vedere Elencare le risorse interessate durante il trasferimento di una sottoscrizione di Azure.

Prerequisiti

Per completare questi passaggi, è necessario:

• Bash in Azure Cloud Shell o interfaccia della riga di comando di Azure
• Proprietario dell'account di fatturazione della sottoscrizione da trasferire nella directory di origine
• Un account utente nella directory di origine e di destinazione per l'utente che apporta la modifica della directory

Passaggio 1: Preparare il trasferimento

Accedere alla directory di origine

1. Accedere ad Azure come amministratore.

2. Ottenere un elenco delle sottoscrizioni con il comando az account list .

   az account list --output table
   

3. Usare az account set per impostare la sottoscrizione attiva da trasferire.

   az account set --subscription "Marketing"
   

Installare l'estensione Azure Resource Graph

L'estensione dell'interfaccia della riga di comando di Azure per Azure Resource Graph, resource-graph, consente di usare il comando az graph per eseguire query sulle risorse gestite da Azure Resource Manager. Questo comando verrà usato nei passaggi successivi.

1. Usare az extension list per verificare se è installata l'estensione resource-graph .

   az extension list
   

2. Se si usa una versione di anteprima o una versione precedente dell'estensione resource-graph , usare az extension update per aggiornare l'estensione.

   az extension update --name resource-graph
   

3. Se l'estensione resource-graph non è installata, usare az extension add per installare l'estensione.

   az extension add --name resource-graph
   

Salvare tutte le assegnazioni di ruolo

1. Usare az role assignment list per elencare tutte le assegnazioni di ruolo (incluse le assegnazioni di ruolo ereditate).

   Per semplificare la revisione dell'elenco, è possibile esportare l'output come JSON, TSV o una tabella. Per altre informazioni, vedere Elencare le assegnazioni di ruolo usando il controllo degli accessi in base al ruolo di Azure e l'interfaccia della riga di comando di Azure.

   az role assignment list --all --include-inherited --output json > roleassignments.json
   az role assignment list --all --include-inherited --output tsv > roleassignments.tsv
   az role assignment list --all --include-inherited --output table > roleassignments.txt
   

2. Salvare l'elenco delle assegnazioni di ruolo.

   Quando si trasferisce una sottoscrizione, tutte le assegnazioni di ruolo vengono eliminate definitivamente in modo che sia importante salvare una copia.

3. Esaminare l'elenco delle assegnazioni di ruolo. Potrebbero essere presenti assegnazioni di ruolo che non saranno necessarie nella directory di destinazione.

Salvare ruoli personalizzati

1. Usare az role definition list per elencare i ruoli personalizzati. Per altre informazioni, vedere Creare o aggiornare ruoli personalizzati di Azure con l'interfaccia della riga di comando di Azure.

   az role definition list --custom-role-only true --output json --query '[].{roleName:roleName, roleType:roleType}'
   

2. Salvare ogni ruolo personalizzato necessario nella directory di destinazione come file JSON separato.

   az role definition list --name <custom_role_name> > customrolename.json
   

3. Creare copie dei file di ruolo personalizzati.

4. Modificare ogni copia per usare il formato seguente.

   Questi file verranno usati in un secondo momento per ricreare i ruoli personalizzati nella directory di destinazione.

   {
     "Name": "",
     "Description": "",
     "Actions": [],
     "NotActions": [],
     "DataActions": [],
     "NotDataActions": [],
     "AssignableScopes": []
   }
   

Determinare i mapping di utenti, gruppi e entità servizio

1. In base all'elenco di assegnazioni di ruolo, determinare gli utenti, i gruppi e le entità servizio a cui si eseguirà il mapping nella directory di destinazione.

   È possibile identificare il tipo di entità esaminando la principalType proprietà in ogni assegnazione di ruolo.

2. Se necessario, nella directory di destinazione creare utenti, gruppi o entità servizio necessari.

Elencare le assegnazioni di ruolo per le identità gestite

Le identità gestite non vengono aggiornate quando una sottoscrizione viene trasferita in un'altra directory. Di conseguenza, tutte le identità gestite assegnate dal sistema o assegnate dall'utente saranno interrotte. Dopo il trasferimento, è possibile riabilitare qualsiasi identità gestita assegnata dal sistema. Per le identità gestite assegnate dall'utente, sarà necessario ricrearle e collegarle nella directory di destinazione.

1. Esaminare l'elenco dei servizi di Azure che supportano le identità gestite per tenere presente dove è possibile usare le identità gestite.

2. Usare az ad sp list per elencare le identità gestite assegnate dal sistema e assegnate dall'utente.

   az ad sp list --all --filter "servicePrincipalType eq 'ManagedIdentity'"
   

3. Nell'elenco delle identità gestite determinare quali sono assegnate dal sistema e quali sono assegnate dall'utente. Per determinare il tipo, è possibile utilizzare i criteri seguenti.

   Criteri	Tipo di identità gestita
   alternativeNames include proprietà isExplicit=False	Assegnata dal sistema
   alternativeNames la proprietà non include isExplicit	Assegnata dal sistema
   alternativeNames include proprietà isExplicit=True	Assegnata dall'utente

   È anche possibile usare az identity list per elencare solo le identità gestite assegnate dall'utente. Per altre informazioni, vedere Creare, elencare o eliminare un'identità gestita assegnata dall'utente usando l'interfaccia della riga di comando di Azure.

   az identity list
   

4. Ottenere un elenco dei objectId valori per le identità gestite.

5. Cercare nell'elenco delle assegnazioni di ruolo per verificare se sono presenti assegnazioni di ruolo per le identità gestite.

List key vaults

Quando si crea un insieme di credenziali delle chiavi, viene automaticamente associato all'ID tenant predefinito di Microsoft Entra per la sottoscrizione in cui viene creata. All'ID tenant vengono associate anche tutte le voci dei criteri di accesso. Per altre informazioni, vedere Spostamento di un'istanza di Azure Key Vault in un'altra sottoscrizione.

Avviso

Se si usa la crittografia dei dati inattivi per una risorsa, ad esempio un account di archiviazione o un database SQL, che ha una dipendenza da un insieme di credenziali delle chiavi che viene trasferito, può causare uno scenario irreversibile. Se si verifica questa situazione, è consigliabile adottare misure per usare un insieme di credenziali delle chiavi diverso o disabilitare temporaneamente le chiavi gestite dal cliente per evitare questo scenario irreversibile.

• Se si ha un insieme di credenziali delle chiavi, usare az keyvault show per elencare i criteri di accesso. Per ulteriori informazioni, vedere Assegnare un criterio di accesso di Key Vault.

  az keyvault show --name MyKeyVault
  

Elencare i database SQL di Azure con l'autenticazione Microsoft Entra

• Usare az sql server ad-admin list e l'estensione az graph per verificare se si usano i database SQL di Azure con l'integrazione dell'autenticazione di Microsoft Entra abilitata. Per altre informazioni, vedere Configurare e gestire l'autenticazione di Microsoft Entra con SQL.

  az sql server ad-admin list --ids $(az graph query -q "resources | where type == 'microsoft.sql/servers' | project id" --query data[*].[id] -o tsv)
  

Elencare gli elenchi di controllo di accesso

1. Se si usa Azure Data Lake Archiviazione Gen1, elencare gli elenchi di controllo di accesso applicati a qualsiasi file usando il portale di Azure o PowerShell.

2. Se si usa Azure Data Lake Archiviazione Gen2, elencare gli elenchi di controllo di accesso applicati a qualsiasi file usando il portale di Azure o PowerShell.

3. Se si usa File di Azure, elencare gli elenchi di controllo di accesso applicati a qualsiasi file.

Elencare altre risorse note

1. Usare az account show per ottenere l'ID sottoscrizione (in bash).

   subscriptionId=$(az account show --output tsv --query id)
   

2. Usare l'estensione az graph per elencare altre risorse di Azure con dipendenze della directory Microsoft Entra note (in bash).

   az graph query -q 'resources 
       | where type != "microsoft.azureactivedirectory/b2cdirectories" 
       | where  identity <> "" or properties.tenantId <> "" or properties.encryptionSettingsCollection.enabled == true 
       | project name, type, kind, identity, tenantId, properties.tenantId' --subscriptions $subscriptionId --output yaml
   

Passaggio 2: Trasferire la sottoscrizione

In questo passaggio si trasferisce la sottoscrizione dalla directory di origine alla directory di destinazione. I passaggi saranno diversi a seconda che si voglia trasferire anche la proprietà della fatturazione.

Avviso

Quando si trasferisce la sottoscrizione, tutte le assegnazioni di ruolo nella directory di origine vengono eliminate definitivamente e non possono essere ripristinate. Dopo il trasferimento della sottoscrizione non è possibile tornare indietro. Assicurarsi di completare i passaggi precedenti prima di eseguire questo passaggio.

1. Determinare se si vuole trasferire anche la proprietà di fatturazione a un altro account.

2. Trasferire la sottoscrizione a una directory diversa.

   • Se si desidera mantenere la proprietà di fatturazione corrente, seguire la procedura descritta nella sezione Associare o aggiungere una sottoscrizione di Azure al tenant di Microsoft Entra.
   • Se si vuole trasferire anche la proprietà di fatturazione, seguire la procedura descritta in Trasferire la proprietà della fatturazione di una sottoscrizione di Azure in un altro account. Per trasferire la sottoscrizione a una directory diversa, è necessario selezionare la casella di controllo Tenant Microsoft Entra della sottoscrizione.

3. Al termine del trasferimento della sottoscrizione, tornare a questo articolo per ricreare le risorse nella directory di destinazione.

Passaggio 3: Ricreare le risorse

Accedere alla directory di destinazione

1. Nella directory di destinazione accedere come utente che ha accettato la richiesta di trasferimento.

   Solo l'utente nel nuovo account che ha accettato la richiesta di trasferimento avrà accesso per gestire le risorse.

2. Ottenere un elenco delle sottoscrizioni con il comando az account list .

   az account list --output table
   

3. Usare az account set per impostare la sottoscrizione attiva da usare.

   az account set --subscription "Contoso"
   

Creare ruoli personalizzati

• Usare az role definition create per creare ogni ruolo personalizzato dai file creati in precedenza. Per altre informazioni, vedere Creare o aggiornare ruoli personalizzati di Azure con l'interfaccia della riga di comando di Azure.

  az role definition create --role-definition <role_definition>
  

Assegnazione di ruoli

• Usare az role assignment create per assegnare ruoli a utenti, gruppi ed entità servizio. Per altre informazioni, vedere Assegnare ruoli di Azure tramite l'interfaccia della riga di comando di Azure.

  az role assignment create --role <role_name_or_id> --assignee <assignee> --scope "/subscriptions/<subscriptionId>/resourceGroups/<resource_group>"
  

Aggiornare le identità gestite assegnate dal sistema

1. Disabilitare e riabilitare le identità gestite assegnate dal sistema.

   Servizio di Azure	Ulteriori informazioni
   Macchine virtuali	Configurare le identità gestite per le risorse di Azure in una macchina virtuale di Azure usando l'interfaccia della riga di comando di Azure
   set di scalabilità di macchine virtuali	Configurare le identità gestite per le risorse di Azure in un set di scalabilità di macchine virtuali usando l'interfaccia della riga di comando di Azure
   Altri servizi	Servizi che supportano le identità gestite per le risorse di Azure

2. Usare az role assignment create per assegnare ruoli alle identità gestite assegnate dal sistema. Per altre informazioni, vedere Assegnare un accesso a un'identità gestita a una risorsa usando l'interfaccia della riga di comando di Azure.

   az role assignment create --assignee <objectid> --role '<role_name_or_id>' --scope "/subscriptions/<subscriptionId>/resourceGroups/<resource_group>"
   

Aggiornare le identità gestite assegnate dall'utente

1. Eliminare, ricreare e collegare identità gestite assegnate dall'utente.

   Servizio di Azure	Ulteriori informazioni
   Macchine virtuali	Configurare le identità gestite per le risorse di Azure in una macchina virtuale di Azure usando l'interfaccia della riga di comando di Azure
   set di scalabilità di macchine virtuali	Configurare le identità gestite per le risorse di Azure in un set di scalabilità di macchine virtuali usando l'interfaccia della riga di comando di Azure
   Altri servizi	Servizi che supportano le identità gestite per le risorse di Azure Creare, elencare o eliminare un'identità gestita assegnata dall'utente usando l'interfaccia della riga di comando di Azure

2. Usare az role assignment create per assegnare ruoli alle identità gestite assegnate dall'utente. Per altre informazioni, vedere Assegnare un accesso a un'identità gestita a una risorsa usando l'interfaccia della riga di comando di Azure.

   az role assignment create --assignee <objectid> --role '<role_name_or_id>' --scope "/subscriptions/<subscriptionId>/resourceGroups/<resource_group>"
   

Aggiornare gli insiemi di credenziali delle chiavi

Questa sezione descrive i passaggi di base per aggiornare gli insiemi di credenziali delle chiavi. Per altre informazioni, vedere Spostamento di un'istanza di Azure Key Vault in un'altra sottoscrizione.

1. Aggiornare l'ID tenant associato a tutti gli insiemi di credenziali delle chiavi esistenti nella sottoscrizione alla directory di destinazione.

2. Rimuovere tutte le voci dei criteri di accesso esistenti.

3. Aggiungere nuove voci dei criteri di accesso associate alla directory di destinazione.

Aggiornare gli elenchi di controllo di accesso

1. Se si usa Azure Data Lake Archiviazione Gen1, assegnare gli ACL appropriati. Per altre informazioni, vedere Protezione dei dati archiviati in Azure Data Lake Storage Gen1.

2. Se si usa Azure Data Lake Archiviazione Gen2, assegnare gli ACL appropriati. Per altre informazioni, vedere Access control in Azure Data Lake Storage Gen2 (Controllo di accesso in Azure Data Lake Storage Gen2).

3. Se si usa File di Azure, assegnare gli ACL appropriati.

Esaminare altri metodi di sicurezza

Anche se le assegnazioni di ruolo vengono rimosse durante il trasferimento, gli utenti nell'account proprietario originale potrebbero continuare ad avere accesso alla sottoscrizione tramite altri metodi di sicurezza, tra cui:

• Chiavi di accesso per servizi quali Archiviazione.
• Certificati di gestione che concedono all'amministratore utente l'accesso alle risorse della sottoscrizione.
• Credenziali di accesso remoto per servizi quali macchine virtuali di Azure.

Se la finalità è rimuovere l'accesso dagli utenti nella directory di origine in modo che non abbiano accesso nella directory di destinazione, è consigliabile ruotare le credenziali. Fino a quando le credenziali non vengono aggiornate, gli utenti continueranno ad avere accesso dopo il trasferimento.

1. Ruotare le chiavi di accesso dell'account di archiviazione. Per altre informazioni, vedere Gestire le chiavi di accesso dell'account di archiviazione.

2. Se si usano chiavi di accesso per altri servizi, ad esempio database SQL di Azure o bus di servizio di Azure Messaggistica, ruotare le chiavi di accesso.

3. Per le risorse che usano segreti, aprire le impostazioni per la risorsa e aggiornare il segreto.

4. Per le risorse che usano i certificati, aggiornare il certificato.

Passaggi successivi

• Trasferire la proprietà della fatturazione di una sottoscrizione di Azure in un altro account
• Trasferire le sottoscrizioni di Azure tra sottoscrittori e CSP
• Associare o aggiungere una sottoscrizione di Azure al tenant di Microsoft Entra
• Azure Lighthouse in scenari aziendali