Die Wahl einer Cloud-Region wirkt oft wie eine Infrastrukturentscheidung: Man wählt einen Standort und stellt dort die Anwendungen bereit. Die Vorgabe, Daten in einer bestimmten Region zu halten, betrifft jedoch auch Backups, Protokolle, Support, Analysen und die Wiederherstellung nach Ausfällen. Sie kann eine notwendige Anforderung, eine geschäftliche Präferenz oder eine Maßnahme sein, die das eigentliche Risiko nicht mindert.
Um zu entscheiden, wann Sie regionale Datenresidenz benötigen, sollten Sie bei den Daten und den geltenden Anforderungen ansetzen, nicht bei einer Karte von Rechenzentren. Entscheidend ist, welche Informationen wo und unter welchen Bedingungen während welcher Phasen ihres Lebenszyklus verbleiben müssen. Anschließend gleichen Sie diese Anforderungen mit der Architektur und den tatsächlichen Kontrollmöglichkeiten des Anbieters ab.
Datenresidenz, Lokalisierung und Datensouveränität sind nicht dasselbe
Datenresidenz bezeichnet meist den geografischen Standort, an dem bestimmte Daten gespeichert werden. Lokalisierung kann konkretere Anforderungen daran beschreiben, wo Daten verarbeitet, gehostet oder aufbewahrt werden. Datensouveränität bezieht sich dagegen häufig darauf, welche Gesetze und Behörden für Daten oder für die sie kontrollierende Organisation zuständig sein können. Die Begriffe werden nicht einheitlich verwendet. Prüfen Sie daher, was sie im Vertrag und im geltenden Rechtsrahmen bedeuten.
Dass Daten in einer Region gespeichert sind, beweist für sich genommen weder, dass sie diese Region niemals verlassen, noch, dass ausschließlich lokales Personal darauf zugreifen kann. Je nach Architektur und Servicebedingungen können Supportvorgänge, Replikate, Backups oder externe Dienste andere Länder oder Rechtsordnungen einbeziehen. Umgekehrt kann eine Organisation Zugriffe und Übertragungen einschränken, ohne zu verlangen, dass sämtliche Verarbeitung an einem einzigen Standort stattfindet.
Trennen Sie deshalb die einzelnen Fragen: Wo werden Daten gespeichert, wo werden sie verarbeitet, wer kann darauf zugreifen, welche Übertragungen finden statt und welche Unternehmen erbringen die jeweiligen Dienste? Wenn eine Richtlinie lediglich geringe Latenz oder Kontinuität verlangt, ist Datenresidenz nicht zwangsläufig die passende Antwort.
Beginnen Sie mit den betroffenen Daten und Prozessen
Erstellen Sie eine überschaubare Bestandsaufnahme der Informationsflüsse Ihres Produkts. Sie müssen nicht gleich jedes Feld in jeder Datenbank klassifizieren: Gruppieren Sie Daten nach Funktion, Sensibilität, Herkunft und Verwendung. Berücksichtigen Sie etwa Kundeninformationen, Kontodaten, hochgeladene Inhalte, technische Protokolle, Telemetriedaten und für Analysen abgeleitete Daten. Gehen Sie nicht davon aus, dass Protokolle oder Backups weniger sensible Informationen enthalten als die primäre Datenbank.
Dokumentieren Sie für jede Gruppe den Weg: Wo werden die Daten erfasst, wo verarbeitet, an welche Systeme weitergegeben, wie lange aufbewahrt und wie gelöscht? Beziehen Sie Entwicklungs- und Testumgebungen ein, wenn sie echte Daten enthalten können, ebenso Exporte, Beobachtungs- und Überwachungstools sowie integrierte Anbieter. So lässt sich erkennen, ob der primäre Speicher zwar regional eingerichtet ist, eine Abhängigkeit Protokolle oder Backups aber an einem anderen Standort aufbewahrt.
Verknüpfen Sie anschließend jede Anforderung mit konkreten Daten und Prozessen. Eine vage Vorgabe wie „Alles muss im Land bleiben“ lässt sich nur schwer überprüfen. Eine operative Formulierung ist hilfreicher: Welche Kategorien sind erfasst? Umfasst die Vorgabe Verarbeitung und Backups? Welche Ausnahmen gibt es, und welche Nachweise sind erforderlich, um die Einhaltung zu belegen?
Prüfen Sie Verpflichtungen und Erwartungen, bevor Sie eine Region auswählen
Die Anforderung kann aus unterschiedlichen Quellen stammen: aus geltenden Vorschriften, einem Kundenvertrag, einer internen Richtlinie, Ausschreibungsbedingungen oder einer Markterwartung. Diese Quellen sind nicht austauschbar. Die Bewertung hängt von der Datenart, den beteiligten Parteien, den Vorgängen und den relevanten Rechtsordnungen ab. Sie lässt sich nicht allein daraus ableiten, dass sich die Nutzer in einem bestimmten Land befinden.
Beziehen Sie Rechtsberatung, Datenschutz, Sicherheit, Einkauf und die zuständigen Geschäftsverantwortlichen ein. Lassen Sie den Umfang bestätigen und eine verbindliche Pflicht von einer Präferenz unterscheiden. Prüfen Sie in Verträgen die Klauseln zu Standort, Unterauftragsverarbeitern, Supportzugriff, Übertragungen, Änderungsmitteilungen und Löschung nach Vertragsende. Ist eine Anforderung mehrdeutig, halten Sie die vereinbarte Auslegung und die zuständige Genehmigungsstelle fest, statt sie direkt in eine technisch schwer umkehrbare Entscheidung umzusetzen.
Hören Sie auch Ihren Kunden zu, ohne jede Anfrage in eine Sonderarchitektur zu verwandeln. Fragen Sie, welches Risiko sie verringern möchten und welche Nachweise sie akzeptieren würden. Manchmal geht es um unbefugte Zugriffe, Dienstkontinuität oder Latenz; für jeden Fall können andere Kontrollen erforderlich sein. Ein regionaler Speicher ersetzt weder die Prüfung von Zugriffen, Verschlüsselung und Schlüsselverwaltung noch die Bewertung von Übertragungspflichten.
Regionale Speicherung oder Zugriffskontrollen
Eine dedizierte Region kann den Nachweis vereinfachen, wo bestimmte Daten gespeichert sind, und dabei helfen, konkrete vertragliche Zusagen zu erfüllen. Sie kann auch die Latenz für Nutzer in der Nähe verringern, wobei dies vom Gesamtdesign und der Verteilung der Dienste abhängt. Dem stehen möglicherweise weniger Optionen für Redundanz, Unterschiede zwischen Regionen sowie getrennte Bereitstellungs- und Betriebsabläufe gegenüber.
Geht es vor allem darum, wer zugreifen kann, sollten Sie Identitätskontrollen, geringstmögliche Berechtigungen, Zugriffsprotokollierung, Verschlüsselung und Schlüsselverwaltung bewerten. Bei internationalen Übertragungen sollten Sie die Datenflüsse ermitteln und mit rechtlicher Unterstützung die dafür geltenden Mechanismen prüfen. Geht es um Kontinuität, planen Sie die Wiederherstellung nach Ausfällen und prüfen Sie, wo Daten wiederhergestellt werden. Keine dieser Kontrollen hebt eine ausdrückliche Residenzpflicht automatisch auf; sie können jedoch besser passen, wenn der tatsächliche Bedarf ein anderer ist.
Prüfen Sie vor einer verbindlichen Entscheidung die konkreten Fähigkeiten des gebuchten Dienstes. „Ausgewählte Region“ muss nicht alle Komponenten umfassen. Fordern Sie für jeden Dienst Unterlagen an und fragen Sie nach Möglichkeiten, Standorte, Zugriffe und Übertragungen einzuschränken. Nehmen Sie nicht an, dass der Anbieter Datenbanken, Backups, Protokolle und Supporttools nach denselben Regeln behandelt.
Bewerten Sie Abhängigkeiten und den gesamten Betrieb
Verfolgen Sie den Datenfluss über den primären Speicher hinaus. Prüfen Sie mindestens folgende Bereiche:
- Backups und Wiederherstellung: Standort von Sicherungen, Replikaten und Snapshots sowie Ziel einer Wiederherstellung. Eine Residenzrichtlinie sollte klarstellen, ob all dies einbezogen ist.
- Protokolle und Beobachtbarkeit: Standort von Logs, Metriken, Traces, Warnmeldungen und Fehler-Dumps. Prüfen Sie, ob diese Identifikatoren oder Inhalte enthalten können.
- Support und Administration: Wer kann von wo aus zugreifen, mit welcher Genehmigung und welcher Protokollierung? Regionales Hosting bedeutet nicht zwangsläufig lokalen Support.
- Analysen und Integrationen: Ziele von Exporten, verbundene Tools, Data Warehouses und weitere Anbieter.
- Aufbewahrung und Löschung: Fristen, Löschung von Sicherungskopien und Umgang mit Daten bei Kontoschließung oder Anbieterwechsel.
Eine Architektur kann im Produktionsbetrieb regelkonform wirken und bei einer Wiederherstellung, einem Export oder einer Untersuchung eines Vorfalls scheitern. Prüfen Sie die Anforderung deshalb anhand betrieblicher Szenarien und nicht nur anhand einer Anbietererklärung. Benennt die Antwort des Anbieters die Grenzen des Dienstes nicht oder beruht sie auf Annahmen, behandeln Sie dies als offene Unsicherheit, die vor dem Start geklärt werden muss.
Praktische Entscheidungshilfe: eine Region, mehrere Regionen oder hybride Architektur
Nutzen Sie diese Optionen als Ausgangspunkt, nicht als fertige Lösungen:
- Eine Region: Kann ausreichen, wenn die Anforderung klar eingegrenzt ist, der Dienst und seine Abhängigkeiten die betreffenden Daten dort halten können und die Auswirkungen auf Verfügbarkeit und Wiederherstellung akzeptabel sind.
- Mehrere Regionen: Kann für Ausfallsicherheit, Leistung oder die Präsenz in verschiedenen Märkten geeignet sein, sofern die Anforderungen Replikation zulassen und bekannt ist, wo jede Kopie landet. Redundanz zwischen Regionen kann einer territorialen Beschränkung widersprechen.
- Hybride Architektur: Kann Datenkategorien oder Funktionen trennen, sodass bestimmte Daten an einem Standort verbleiben und andere Komponenten gemeinsam genutzte Dienste verwenden. Das bringt zusätzliche Schnittstellen, Kontrollen und Tests mit sich. Sie müssen nachweisen, dass die Datenflüsse zwischen den Bereichen den festgelegten Regeln entsprechen.
Berücksichtigen Sie bei der Entscheidung sowohl die Verpflichtung als auch den Betrieb: die Kosten zusätzlicher Komplexität, Wiederherstellungsziele, Latenz, Teamkapazitäten und die Möglichkeit eines Anbieterwechsels. Gibt es keine Anforderung, die eine Trennung rechtfertigt, vermeiden Sie eine regionale Sonderlösung, die Ihr Team nicht dauerhaft betreiben kann. Gibt es eine solche Anforderung, legen Sie ausdrücklich fest, was ausgenommen ist und wie diese Ausnahmen kontrolliert werden.
Fragen an den Anbieter und Überprüfung der Entscheidung
Fragen Sie vor Vertragsabschluss oder Migration, welche Regionen für jeden Dienst verfügbar sind, welche Daten die einzelnen Komponenten verarbeiten und wo relevante Backups, Protokolle und Metadaten gespeichert werden. Lassen Sie klären, wie Support, Unteranbieter, Übertragungen und Wiederherstellung nach Ausfällen gehandhabt werden. Prüfen Sie außerdem, ob Sie überprüfbare Nachweise erhalten können und was geschieht, wenn der Anbieter seine Architektur oder Bedingungen ändert.
Dokumentieren Sie die Entscheidung zusammen mit der Anforderung, den Datenkategorien, den erfassten Datenflüssen, Ausnahmen, Kontrollen, Abhängigkeiten und verantwortlichen Personen. Halten Sie offene Fragen und Kriterien für eine erneute Prüfung fest. Überprüfen Sie die Entscheidung, wenn sich Märkte, Produkt, Anbieter, Verträge oder geltende Verpflichtungen ändern, sowie nach Vorfällen oder Wiederherstellungstests, die einen bislang nicht berücksichtigten Datenfluss aufdecken.
Zusammengefasst: Verlangen Sie regionale Datenresidenz, wenn eine Verpflichtung oder ein identifiziertes Risiko sie rechtfertigt und Sie ihren Umfang überprüfbar festlegen können. Geht es um Leistung, Zugriff oder Ausfallsicherheit, vergleichen Sie zuerst Maßnahmen, die genau auf diese Ziele ausgerichtet sind. Die beste Entscheidung erfüllt die tatsächliche Anforderung, ohne ein weitergehendes geografisches Versprechen abzugeben, als die Architektur einhalten kann.