Come verificare dove sono archiviati i tuoi dati prima di migrare al cloud

Sapere in quale regione è archiviata una risorsa aiuta a valutare i requisiti di residenza, latenza, ridondanza e recupero. La posizione deve essere esaminata per servizio e per risorsa: in Cloud Storage, ad esempio, il tipo di posizione determina come viene replicata l'informazione.

Per una migrazione regolamentata, separa tre domande: dove sono salvati i dati principali, dove possono essere replicati o elaborati e quali entità possono accedervi. La posizione deve essere valutata per risorsa e per servizio, insieme alle condizioni applicabili all'organizzazione.

La posizione influisce anche sulle decisioni tecniche. In Google Cloud Storage, una regione, una doppia-regione e una multi-regione hanno comportamenti di ridondanza e costo distinti; posizionare l'archiviazione vicino al calcolo può aiutare le prestazioni. Scegli la posizione in base al requisito specifico, non perché il nome geografico sembra sufficiente.

In Google Cloud Storage, una regione è una posizione geografica specifica; una doppia-regione comprende due regioni e una multi-regione copre un'ampia area geografica con due o più regioni. Il tipo di posizione determina come l'informazione viene replicata e fatturata. Le opzioni specifiche dipendono dal servizio.

Non dare per scontato che un codice di regione identifichi un unico edificio. In Cloud Storage, Google distingue posizioni regionali, doppia-regionali e multi-regionali; gli oggetti di una doppia-regione vengono replicati nelle regioni che la compongono, mentre una multi-regione copre una zona geografica più ampia. La granularità configurata dal client dipende dal servizio e non deve essere confusa con la localizzazione fisica di ogni copia.

Né tutti i servizi di uno stesso progetto ereditano una posizione unica. La documentazione Firebase indica che prodotti come Cloud Firestore e Cloud Storage richiedono posizioni configurate per istanza o bucket, e che alcune funzioni hanno una regione predefinita se non ne viene specificata un'altra. Una configurazione del progetto non dimostra automaticamente dove si trovano tutte le sue risorse.

Inizia a inventariare i servizi che conterranno dati personali o confidenziali: database, bucket, dischi, backup, code, log e servizi di analytics. Per ogni elemento, annota l'identificatore della risorsa, il servizio, la regione configurata, l'account o progetto proprietario e le dipendenze che possono generare copie o elaborazione aggiuntiva. L'unità di verifica è la risorsa, non solo l'account cloud.

In Google Cloud Storage, la posizione fa parte dei metadati del bucket e può essere consultata con i permessi adeguati. La documentazione ufficiale distingue regione, doppia-regione e multi-regione, e specifica che la posizione scelta influenza la replicazione e il prezzo. In Firebase, la guida sulle posizioni descrive dove verificare la posizione di database, bucket, backend e funzioni; alcuni prodotti, come Gemini Developer API in Firebase AI Logic, sono descritti come globali.

La guida AWS DataSync indica che, per trasferire dati a un bucket Amazon S3 o da esso, viene creata una posizione di trasferimento e DataSync viene concesso l'accesso al bucket tramite un ruolo IAM. Quella configurazione descrive l'accesso necessario per il trasferimento.

Azure Portal consente di gestire le risorse e di vederle organizzate per servizio e gruppo di risorse. Per verificare la residenza, identifica la regione specifica di ogni risorsa e controlla separatamente le funzioni che la accompagnano, come la ridondanza geografica, il disaster recovery e i servizi di monitoraggio. Una regione di deployment non dimostra che tutti i dati derivati o ausiliari abbiano la stessa portata territoriale.

ISO/IEC 27001 si riferisce a un sistema di gestione della sicurezza delle informazioni entro un ambito definito; non è una mappa dei data center né una certificazione universale di residenza. Prima di attribuirgli un valore per una migrazione, identifica quale entità, servizio, regione e attività copre il certificato, oltre alla sua validità e all'ente emittente.

I fornitori pubblicano ambiti che possono variare per servizio o geografia. Ad esempio, Esri spiega che l'ambito della sua certificazione ISO 27001 per ArcGIS ISO Cloud si applica ai servizi ospitati nella sua posizione regionale europea e non si estende automaticamente all'APAC. Chiarisce anche che le certificazioni AWS o Microsoft Azure sull'infrastruttura sottostante non espandono da sole l'ambito della certificazione di Esri.

La pagina di conformità di OVHcloud distingue i servizi inclusi e segnala un perimetro specifico per i data center degli Stati Uniti. Come verifica pratica, richiedi il certificato e rivedi il suo ambito per il servizio contrattato. Una certificazione supporta i controlli inclusi in quell'ambito.

Valuta separatamente sicurezza, privacy, conformità e localizzazione. Verifica l'ambito specifico di ogni certificato o rapporto: può identificare l'entità, i servizi e le posizioni incluse. OVHcloud, ad esempio, indica che i suoi certificati e rapporti coprono i servizi ospitati nei suoi data center, con un perimetro specifico per gli Stati Uniti.

Per conoscere la posizione di una risorsa, consulta i metadati o la configurazione di posizione offerta dal servizio. In Cloud Storage, la posizione del bucket fa parte dei suoi metadati e può essere consultata con i permessi adeguati.

Un altro errore è assumere che tutti i servizi di uno stesso progetto abbiano una posizione unica. Firebase distingue risorse la cui posizione è configurata per istanza, bucket o backend, e prodotti per i quali non si può selezionare una posizione, come Gemini Developer API in Firebase AI Logic. Rivedi la posizione in base al prodotto e alla risorsa.

Infine, non confondere la disponibilità regionale con la posizione di ogni oggetto. Le opzioni di ridondanza possono implicare repliche in diverse regioni; questo può essere auspicabile per la resilienza, ma deve adattarsi alle restrizioni di residenza. Conferma quale modalità è attiva, come si comporta il recupero e se esistono restrizioni per cambiare o spostare la posizione.

Prima di approvare il trasferimento, converti il requisito legale e operativo in verifiche dimostrabili e mantenibili. Uno screenshot può servire come registro puntuale, ma non sostituisce una clausola contrattuale né una procedura di controllo dei cambiamenti. Conserva la configurazione e la sua data di revisione nell'inventario degli asset.

• Identifica ogni servizio e risorsa che archivierà, replicherà o elaborerà dati sensibili.
• Registra regione, zona se applicabile, modalità di ridondanza e posizione dei backup.
• Verifica nella console o nei metadati la posizione effettiva e chi ha i permessi per modificarla.
• Rivedi le posizioni di log, supporto, monitoraggio, analytics e servizi connessi.
• Richiedi certificati e rapporti con ambito, entità, servizio, geografia e validità identificabili.
• Contrasta residenza e trasferimenti con il contratto, i termini del servizio e l'analisi legale applicabile.
• Definisci chi rivedrà i cambiamenti di regione, le nuove repliche e le eccezioni dopo la migrazione.

La decisione finale non consiste nel scegliere un paese a partire da un'etichetta di prodotto, ma nel verificare che l'architettura soddisfi il requisito. Documenta le posizioni e le modalità di ridondanza configurate per ogni risorsa e valuta qualsiasi componente la cui posizione non puoi determinare rispetto alle esigenze del carico di lavoro.

Il risultato pratico è un fascicolo per carico di lavoro: risorse identificate, posizioni documentate, ambito contrattuale e certificazioni pertinenti, insieme a responsabili e controlli di cambiamento. Se non puoi dimostrare la posizione di una parte critica, non trattarla come equivalente alle altre né presumere che sia coperta dalla regione principale.