So prüfen Sie, wo Ihre Daten gespeichert werden, bevor Sie in die Cloud migrieren

Zu wissen, in welcher Region eine Ressource gespeichert ist, hilft bei der Bewertung von Anforderungen an Residenz, Latenz, Redundanz und Wiederherstellung. Der Standort muss nach Dienst und Ressource überprüft werden: Bei Cloud Storage bestimmt beispielsweise der Standorttyp, wie Informationen repliziert werden.

Für eine regulierte Migration trennen Sie drei Fragen: Wo werden die Hauptdaten gespeichert, wo können sie repliziert oder verarbeitet werden und welche Entitäten können darauf zugreifen. Der Standort muss nach Ressource und Dienst bewertet werden, zusammen mit den auf die Organisation anwendbaren Bedingungen.

Der Standort beeinflusst auch technische Entscheidungen. In Google Cloud Storage haben eine Region, eine Dual-Region und eine Multi-Region unterschiedliche Redundanz- und Kostenverhaltensweisen; die Speicherung in der Nähe der Berechnung kann die Leistung verbessern. Wählen Sie den Standort anhand der konkreten Anforderung, nicht weil der geografische Name ausreichend scheint.

In Google Cloud Storage ist eine Region ein spezifischer geografischer Ort; eine Dual-Region umfasst zwei Regionen und eine Multi-Region deckt eine weite geografische Zone mit zwei oder mehr Regionen ab. Der Standorttyp bestimmt, wie Informationen repliziert und abgerechnet werden. Die konkreten Optionen hängen vom Dienst ab.

Gehen Sie nicht davon aus, dass ein Regionscode ein einzelnes Gebäude identifiziert. In Cloud Storage unterscheidet Google regionale, dual-regionale und multi-regionale Standorte; Objekte in einer Dual-Region werden in den Regionen repliziert, die sie bilden, während eine Multi-Region eine breitere geografische Zone abdeckt. Die vom Client konfigurierte Granularität hängt vom Dienst ab und sollte nicht mit der physischen Lage jeder Kopie verwechselt werden.

Auch erben nicht alle Dienste eines Projekts einen einzigen Standort. Die Firebase-Dokumentation zeigt, dass Produkte wie Cloud Firestore und Cloud Storage Standorte erfordern, die pro Instanz oder Bucket konfiguriert werden, und dass einige Funktionen eine Standardregion haben, wenn keine andere angegeben wird. Eine Projektkonfiguration beweist nicht automatisch, wo sich alle ihre Ressourcen befinden.

Beginnen Sie damit, die Dienste zu inventarisieren, die personenbezogene oder vertrauliche Daten enthalten werden: Datenbanken, Buckets, Disks, Backups, Warteschlangen, Protokolle und Analytikdienste. Notieren Sie für jedes Element die Ressourcenkennung, den Dienst, die konfigurierte Region, das eigene Konto oder Projekt und Abhängigkeiten, die Kopien oder zusätzliche Verarbeitung erzeugen können. Die Einheit der Überprüfung ist die Ressource, nicht nur das Cloud-Konto.

In Google Cloud Storage ist der Standort Teil der Bucket-Metadaten und kann mit entsprechenden Berechtigungen konsultiert werden. Die offizielle Dokumentation unterscheidet Region, Dual-Region und Multi-Region und legt fest, dass der gewählte Standort die Replikation und den Preis beeinflusst. In Firebase beschreibt der Standortleitfaden, wo der Standort von Datenbanken, Buckets, Backends und Funktionen überprüft wird; einige Produkte, wie Gemini Developer API in Firebase AI Logic, werden als global beschrieben.

Der AWS DataSync-Leitfaden zeigt, dass für die Übertragung von Daten in einen Amazon S3-Bucket oder aus diesem eine Übertragungsstandort erstellt und DataSync über eine IAM-Rolle Zugriff auf den Bucket gewährt wird. Diese Konfiguration beschreibt den für die Übertragung erforderlichen Zugriff.

Azure Portal ermöglicht die Verwaltung von Ressourcen und deren Ansicht nach Dienst und Ressourcengruppe organisiert. Um die Residenz zu überprüfen, identifizieren Sie die konkrete Region jeder Ressource und prüfen Sie separat die begleitenden Funktionen, wie geografische Redundanz, Disaster Recovery und Überwachungsdienste. Eine Bereitstellungsregion beweist nicht, dass alle abgeleiteten oder Hilfsdaten denselben territorialen Umfang haben.

ISO/IEC 27001 bezieht sich auf ein Informationssicherheitsmanagementsystem innerhalb eines definierten Umfangs; es ist keine Karte von Rechenzentren noch eine universelle Residenzzertifizierung. Bevor Sie ihm für eine Migration Wert beimessen, identifizieren Sie welche Entität, welchen Dienst, welche Region und welche Aktivitäten das Zertifikat abdeckt, zusätzlich zu seiner Gültigkeit und dem Herausgeber.

Anbieter veröffentlichen Umfänge, die nach Dienst oder Geografie variieren können. Zum Beispiel erklärt Esri, dass der Umfang seiner ISO-27001-Zertifizierung für ArcGIS ISO Cloud auf Dienste in seiner europäischen regionalen Lage anwendbar ist und sich nicht automatisch auf APAC erstreckt. Es stellt auch klar, dass AWS- oder Microsoft-Azure-Zertifizierungen für die zugrunde liegende Infrastruktur den Umfang der Esri-Zertifizierung nicht von selbst erweitern.

Die Compliance-Seite von OVHcloud unterscheidet die enthaltenen Dienste und weist auf einen spezifischen Perimeter für US-Rechenzentren hin. Als praktische Überprüfung fordern Sie das Zertifikat an und prüfen Sie seinen Umfang für den beauftragten Dienst. Eine Zertifizierung stützt die in diesem Umfang enthaltenen Kontrollen.

Bewerten Sie Sicherheit, Datenschutz, Compliance und Lokalisierung separat. Prüfen Sie den konkreten Umfang jedes Zertifikats oder Berichts: Es kann die Entität, die Dienste und die Standorte identifizieren, die enthalten sind. OVHcloud gibt beispielsweise an, dass seine Zertifikate und Berichte Dienste in seinen Rechenzentren abdecken, mit einem spezifischen Perimeter für die Vereinigten Staaten.

Um den Standort einer Ressource zu kennen, konsultieren Sie die Metadaten oder die Standortkonfiguration, die der Dienst bietet. In Cloud Storage ist der Bucket-Standort Teil seiner Metadaten und kann mit den entsprechenden Berechtigungen konsultiert werden.

Ein weiterer Fehler ist die Annahme, dass alle Dienste eines Projekts einen einzigen Standort haben. Firebase unterscheidet Ressourcen, deren Standort pro Instanz, Bucket oder Backend konfiguriert wird, und Produkte, für die kein Standort ausgewählt werden kann, wie Gemini Developer API in Firebase AI Logic. Prüfen Sie den Standort nach Produkt und Ressource.

Verwechseln Sie schließlich regionale Verfügbarkeit nicht mit dem Standort jedes Objekts. Redundanzoptionen können Replikate in mehreren Regionen implizieren; dies kann für Resilienz wünschenswert sein, muss aber mit den Residenzbeschränkungen übereinstimmen. Bestätigen Sie, welche Modalität aktiv ist, wie sich die Wiederherstellung verhält und ob es Beschränkungen gibt, den Standort zu ändern oder zu verschieben.

Bevor Sie den Transfer genehmigen, wandeln Sie die rechtliche und operative Anforderung in überprüfbare und erhaltbare Prüfungen um. Ein Screenshot kann als punktuelles Protokoll dienen, ersetzt aber keine Vertragsklausel noch ein Änderungssteuerungsverfahren. Bewahren Sie die Konfiguration und ihr Revisionsdatum im Asset-Inventar auf.

• Identifizieren Sie jeden Dienst und jede Ressource, die sensible Daten speichern, replizieren oder verarbeiten wird.
• Erfassen Sie Region, Zone falls anwendbar, Redundanzmodalität und Backup-Standort.
• Prüfen Sie in Konsole oder Metadaten den effektiven Standort und wer Berechtigungen hat, ihn zu ändern.
• Prüfen Sie die Standorte von Protokollen, Support, Überwachung, Analytik und verbundenen Diensten.
• Fordern Sie Zertifikate und Berichte mit identifizierbarem Umfang, Entität, Dienst, Geografie und Gültigkeit an.
• Stellen Sie Residenz und Transfers dem Vertrag, den Servicebedingungen und der anwendbaren rechtlichen Analyse gegenüber.
• Definieren Sie, wer nach der Migration Regionsänderungen, neue Replikate und Ausnahmen überprüfen wird.

Die endgültige Entscheidung besteht nicht darin, ein Land anhand eines Produktetiketts zu wählen, sondern darin zu überprüfen, dass die Architektur die Anforderung erfüllt. Dokumentieren Sie die konfigurierten Standorte und Redundanzmodalitäten für jede Ressource und bewerten Sie jede Komponente, deren Standort Sie nicht bestimmen können, gegenüber den Workload-Bedürfnissen.

Das praktische Ergebnis ist eine Akte pro Workload: identifizierte Ressourcen, dokumentierte Standorte, vertraglicher Umfang und relevante Zertifizierungen, zusammen mit Verantwortlichen und Änderungskontrollen. Wenn Sie den Standort eines kritischen Teils nicht nachweisen können, behandeln Sie ihn nicht als äquivalent zu den anderen und nehmen Sie nicht an, dass er von der Hauptregion abgedeckt ist.