Un piano di migrazione dei progetti ti consente di valutare l'idoneità dell'organizzazione e prevenire interruzioni del servizio prima di spostare un progetto tra le risorse dell'organizzazione. Un inventario dei servizi attivi e delle dipendenze ti aiuta anche ad anticipare l'impatto della gerarchia delle risorse di destinazione sui tuoi workload.
Durante uno spostamento, l'API Cloud Resource Manager tratta il progetto e i servizi sottostanti come un'unica unità senza modifiche alla configurazione interna. Tuttavia, le policy di autorizzazione, di negazione e dell'organizzazione ereditate non vengono migrate con il progetto, mentre le policy e i service account collegati direttamente rimangono invariati. Questa modifica della gerarchia può causare comportamenti imprevisti o attivare violazioni delle policy dell'organizzazione nell'organizzazione di destinazione.
Panoramica del modulo Inventario
Utilizza Cloud Asset Inventory per creare una panoramica delle risorse in uso, incluse le policy di autorizzazione. Puoi utilizzare questa panoramica per delineare il tuo piano di migrazione.
Puoi anche utilizzare Cloud Asset Inventory per trasferire questi dati in BigQuery. In questo modo potrai eseguire query sui dati utilizzando SQL, che è più facile da leggere rispetto all'interpretazione dei dati in formato JSON. Per informazioni sull'esportazione di questi dati, consulta Esportazione in BigQuery.
Per visualizzare un elenco di tutte le policy di autorizzazione e di negazione che influiscono sull'accesso a un progetto, consulta Visualizza tutte le policy di autorizzazione e di negazione applicabili a una risorsa.
Verifica delle norme
Quando esegui la migrazione del progetto, questo non erediterà più le policy dalla sua posizione attuale nella gerarchia delle risorse e sarà soggetto alla valutazione delle policy effettive nella destinazione. Ti consigliamo di assicurarti che le policy effettive nella destinazione del progetto corrispondano il più possibile alle policy che il progetto aveva nella località di origine.
Qualsiasi policy applicata direttamente al progetto rimarrà collegata al termine della migrazione. L'applicazione delle policy direttamente al progetto è un buon modo per verificare che vengano applicate le policy corrette dal momento in cui la migrazione è completata.
Le policy di autorizzazione, di negazione e dell'organizzazione vengono ereditate tramite la gerarchia delle risorse e possono impedire il funzionamento di un servizio se non sono impostate correttamente. Determina la policy applicata alla destinazione del progetto nella gerarchia delle risorse per assicurarti che sia in linea con i tuoi obiettivi di governance.
Gestisci le chiavi criptate
Devi verificare se nel tuo progetto è abilitata una chiave di crittografia gestita dal cliente o un altro servizio Cloud Key Management Service. Le chiavi di crittografia sono di proprietà del progetto, pertanto un utente con accesso owner a quel progetto potrà gestire ed eseguire operazioni di crittografia sulle chiavi in Cloud KMS in quel progetto.
Per saperne di più, consulta Separazione dei compiti.
Funzionalità in anteprima
Puoi abilitare le funzionalità in anteprima su risorse, cartelle o progetti dell'organizzazione. Se hai attivato una funzionalità alpha o beta nel progetto di cui eseguire la migrazione, questa funzionalità dovrebbe continuare a funzionare dopo la migrazione. Se la funzionalità in anteprima è privata e non è stata aggiunta alla lista consentita per la risorsa dell'organizzazione di destinazione, non potrai apportare modifiche alla configurazione dopo il completamento della migrazione.
Identifica il nuovo account di fatturazione
Gli account di fatturazione Cloud possono essere utilizzati in tutte le risorse dell'organizzazione. Lo spostamento di un progetto da una risorsa dell'organizzazione a un'altra non influisce sulla fatturazione. Gli addebiti continuano a essere applicati al vecchio account di fatturazione. Tuttavia, la migrazione dei progetti tra risorse dell'organizzazione spesso include anche l'obbligo di eseguire la migrazione a un nuovo account di fatturazione.
Nell'ambito del piano di migrazione, stabilisci se mantenere gli account di fatturazione esistenti. Puoi anche associare i progetti a un nuovo account di fatturazione nella risorsa di organizzazione di destinazione.
Per scoprire come modificare o eseguire la migrazione di un account di fatturazione, consulta Modifica l'account di fatturazione.
Piano di rollback
Se scopri che qualcosa non funziona in uno dei progetti di cui hai eseguito la migrazione, puoi ripristinarlo nella posizione originale. Per farlo, devi disporre delle autorizzazioni IAM necessarie e impostare le policy dell'organizzazione richieste in modo da poter eseguire la migrazione del progetto al contrario.
Per un elenco delle autorizzazioni richieste, consulta Assegna le autorizzazioni. Per le policy dell'organizzazione che devi configurare per consentire la migrazione di un progetto, consulta Configura le policy dell'organizzazione.
Cartelle di importazione ed esportazione dedicate
L'ereditarietà delle policy può causare effetti indesiderati durante la migrazione di un progetto, sia nelle risorse dell'organizzazione di origine che in quelle di destinazione. Puoi mitigare questo rischio creando cartelle specifiche che contengano solo progetti per l'esportazione e l'importazione e assicurandoti che le stesse policy vengano ereditate dalle cartelle in entrambe le risorse dell'organizzazione. Puoi anche impostare su queste cartelle autorizzazioni che verranno ereditate dai progetti spostati al loro interno, contribuendo ad accelerare il processo di migrazione dei progetti.
Quando pianifichi una migrazione, valuta la possibilità di configurare prima una cartella di origine dedicata.
Per farlo, crea una cartella per ogni risorsa dell'organizzazione di destinazione in cui prevedi di esportare i progetti. Quindi, imposta una policy dell'organizzazione su queste cartelle, ciascuna con il vincolo constraints/resourcemanager.allowedExportDestinations impostato sulla singola risorsa dell'organizzazione in cui vuoi esportare i progetti.
Ad esempio, potresti configurare le cartelle Export to Marketing Org e Export to Sales Org, ciascuna con i vincoli delle policy dell'organizzazione appropriati.
Allo stesso modo, configura cartelle di importazione dedicate nella risorsa organizzazione di destinazione, una per ogni risorsa organizzazione da cui vuoi importare i progetti. Per farlo, crea una cartella per ogni risorsa dell'organizzazione di origine da cui prevedi di importare i progetti. Quindi, imposta una policy dell'organizzazione su queste cartelle, ciascuna con il vincolo constraints/resourcemanager.allowedImportSources impostato sulla singola risorsa dell'organizzazione da cui vuoi importare i progetti.
Ad esempio, puoi configurare le cartelle Import from Marketing Org e Import from App Development Org, ciascuna con i vincoli delle policy dell'organizzazione appropriati.
In ciascuna delle cartelle di importazione ed esportazione, assegna alla persona che sposterà i progetti il ruolo roles/resourcemanager.projectMover. Questo ruolo verrà ereditato da tutti i progetti contenuti in queste cartelle, consentendo all'utente di eseguire le operazioni di spostamento su qualsiasi progetto spostato in queste cartelle.
Una volta completata la migrazione del progetto, devi rimuovere queste cartelle dedicate.
Per informazioni sulla configurazione delle policy dell'organizzazione, consulta Configura le policy dell'organizzazione.
Passaggi successivi
Per assegnare ruoli e autorizzazioni di Identity and Access Management per la migrazione dei progetti tra organizzazioni, consulta Assegna ruoli e autorizzazioni di Identity and Access Management.