13 Datenresidenz bei SaaS ist von einer gelegentlichen Anfrage großer Unternehmen zu einer Standardanforderung in Ausschreibungen geworden. Europäische Kunden verlangen, dass ihre Daten in der EU oder im eigenen Land bleiben. Öffentliche Auftraggeber in Frankreich, Deutschland, dem Vereinigten Königreich, Japan und den Golfstaaten verlangen häufig ein Hosting im Inland. Regulierte Branchen wollen überall klare Antworten darauf, wo ihre Daten, Backups und Logs liegen und wer darauf zugreifen kann. Für SaaS-Anbieter ist regionale Datenresidenz heute eine Voraussetzung, um große Aufträge zu gewinnen – und die richtige Architektur entscheidet, ob sie zum Wettbewerbsvorteil oder zur betrieblichen Last wird. Dieser Artikel erklärt, wie SaaS-Anbieter regionale Datenresidenz architektonisch umsetzen, welche Daten in der Region bleiben müssen, wie sich die Anforderungen nach Land unterscheiden und wie sich mehrere Regionen effizient betreiben lassen. Das übergreifende Bild zur Dateispeicherung bietet unsere Übersicht zum Dateispeicher für SaaS. Was Kunden unter Residenz verstehen Die Anforderungen der Kunden variieren, umfassen aber typischerweise: Speicherort der Primärdaten: wo die Datensätze und Dateien des Kunden gespeichert werden. Backups und Replikate: wo Kopien liegen – was Kunden oft übersehen, bis eine Sicherheitsprüfung danach fragt. Ort der Verarbeitung: wo Daten verarbeitet werden, einschließlich Analyse- und KI-Funktionen. Metadaten und Logs: wo Nutzungslogs, Audit-Logs, Suchindizes und Telemetrie gespeichert werden. Support-Zugriff: wer von welchen Ländern aus und unter welchen Kontrollen auf Daten zugreifen kann. Unterauftragsverarbeiter: welche Dritten die Daten verarbeiten und wo. Residenz ist mit Souveränität verwandt, aber nicht dasselbe: Bei Souveränität geht es darum, welches Recht gilt und wer den Zugriff erzwingen kann. Anforderungen nach Region Europäische Union: Die DSGVO beschränkt Übermittlungen außerhalb des EWR ohne geeignete Garantien. Viele Kunden verlangen eine ausschließliche Verarbeitung in der EU als vertragliche Zusage, und manche öffentliche Stellen fordern ein nationales Hosting. Deutschland: Öffentliche und regulierte Kunden erwarten häufig ein C5-Testat des BSI und Rechenzentren in Deutschland. Frankreich: Sensible öffentliche Stellen und Betreiber kritischer Infrastrukturen können von der ANSSI nach SecNumCloud qualifizierte Dienste verlangen. Vereinigtes Königreich: Es gilt die UK GDPR, und öffentliche Auftraggeber bevorzugen oft ein Hosting im Vereinigten Königreich. Japan: Kunden erwarten mit Blick auf das APPI gegebenenfalls ein Hosting im Inland, und öffentliche Auftraggeber suchen nach ISMAP-registrierten Diensten. Naher Osten: Die VAE, Saudi-Arabien und andere verlangen für bestimmte Behörden-, Gesundheits- und Finanzdaten eine Speicherung im Land. Vereinigte Staaten: Bundeskunden verlangen zugelassene Dienste, und manche Daten müssen in den USA bleiben und von US-Personal betreut werden. Weitere Märkte: Australien, Kanada, Indien und andere haben eigene Government-Cloud-Programme und Branchenregeln. Architekturmuster Regionale Zellen Der robusteste Ansatz stellt in jeder Region eine vollständige Kopie des Anwendungs-Stacks bereit, oft Zelle oder Pod genannt: Anwendungsserver, Datenbanken, Objektspeicher, Suche, Warteschlangen und Caches. Jeder Mandant wird einer Zelle zugeordnet, und alle seine Daten bleiben dort. Die Zellen sind unabhängig voneinander, was auch den Schadensradius von Vorfällen begrenzt. Globale Control Plane, regionale Data Plane Eine kleine globale Control Plane übernimmt Registrierung, Routing und Abrechnung, während alle Kundendaten in regionalen Data Planes liegen. Die Control Plane sollte so wenige Kundendaten wie möglich halten, denn alles, was sie speichert, ist per Definition global. Mandantenbindung und Routing Jeder Mandant wird bei der Anlage an eine Region gebunden, und Anfragen werden anhand der Domain, des Logins oder eines Verzeichnisabgleichs an die richtige Region geleitet. Einen Mandanten zwischen Regionen zu verschieben wird so zu einer bewussten Migration mit Überprüfung. Regionaler Objektspeicher Die Dateien der Kunden liegen in Objektspeicher innerhalb jeder Region, mit Buckets oder Konten pro Region und Replikation nur an andere Standorte derselben Region. Mit S3-kompatiblem Speicher läuft derselbe Anwendungscode auf Hyperscaler-Regionen, bei lokalen Cloud-Anbietern oder auf der eigenen Infrastruktur des Anbieters – je nachdem, wo Regionen gebraucht werden. Daten, die leicht vergessen werden Residenzprogramme scheitern oft an Sekundärdaten: Backups, die standardmäßig auf einen anderen Kontinent repliziert werden. Logs und Telemetrie, die an eine zentrale Observability-Plattform geschickt werden. Suchindizes, die in einem zentralen Cluster aufgebaut werden. KI-Funktionen, die Inhalte an anderswo gehostete Modelle senden. Support-Tools, die Kundendaten in Tickets kopieren. Analyse-Pipelines, die Daten über Regionen hinweg aggregieren. Prüfen Sie jeden Datenfluss und legen Sie fest, was eine Region verlassen darf, wenn überhaupt. Der Blog auf scality.com behandelt Metadaten-Residenz und Datengrenzen für Speicher-Telemetrie. Woher die Regionen kommen Anbieter können Regionen auf Hyperscaler-Regionen aufbauen, bei nationalen oder Sovereign-Cloud-Anbietern, in Colocation-Einrichtungen mit eigener Infrastruktur oder in einer Kombination daraus. Hyperscaler-Regionen sind bequem, aber nicht in jedem Land verfügbar, und manche Kunden bevorzugen aus Souveränitätsgründen lokale Anbieter. Mit S3-kompatiblem Objektspeicher in Colocation-Einrichtungen können Anbieter Regionen dort eröffnen, wo Hyperscaler fehlen oder Kunden inländische Betreiber verlangen. Viele Regionen betreiben Automatisierung Jede Region sollte mit derselben Automatisierung bereitgestellt und aktualisiert werden, damit die Regionen konsistent bleiben und sich neue schnell hinzufügen lassen. Kapazitätsplanung pro Region Das Wachstum unterscheidet sich je Region. Planen Sie Speicher und Rechenleistung für jede Region getrennt und vermeiden Sie Regionen, die zu klein für einen effizienten Betrieb sind. Resilienz innerhalb der Region Kunden erwarten Residenz und Verfügbarkeit. Nutzen Sie innerhalb jeder Region mehrere Standorte oder Verfügbarkeitszonen, mit Replikation, die in der Region bleibt. Supportmodell Legen Sie Kontrollen für den Support-Zugriff fest: regionale Supportteams, Just-in-Time-Zugriff, Zustimmung des Kunden zum Zugriff und Protokollierung jeder Aktion. Kosten Jede Region verursacht Fixkosten. Bepreisen Sie Residenzoptionen entsprechend, etwa als Aufpreis für dedizierte oder inländische Regionen, und gestalten Sie gemeinsame Dienste so, dass der Overhead pro Region minimal bleibt. KI-Funktionen und Residenz Generative KI-Funktionen sind zu einer neuen Herausforderung für die Residenz geworden. Zusammenfassungs-, Such- und Assistenzfunktionen senden Kundeninhalte womöglich an Modelle, die in anderen Regionen oder von Dritten gehostet werden. Kunden mit Residenzanforderungen fragen zunehmend, wo Prompts, Dokumente und Embeddings verarbeitet und gespeichert werden und ob Daten für das Training genutzt werden. Zu den Optionen gehören Modelle in jeder Region zu hosten, regionale Endpunkte von Modellanbietern mit Zusage zur Verarbeitung in der Region zu nutzen, Mandanten das Deaktivieren von KI-Funktionen zu ermöglichen oder KI nur in Regionen anzubieten, in denen die Verarbeitung lokal bleiben kann. Aus Kundeninhalten abgeleitete Embeddings und Vektorindizes sollten denselben Residenzregeln folgen wie die Inhalte selbst. Welche Regionen angeboten werden sollten Nicht jedes Land rechtfertigt eine eigene Region. Anbieter beginnen meist mit einer kleinen Auswahl, etwa den USA, der EU und ein oder zwei großen nationalen Märkten, und fügen Regionen hinzu, wo Umsatz, Regulierung und Kundennachfrage die Fixkosten rechtfertigen. Manche bieten sehr großen oder stark regulierten Kunden statt vollständiger gemeinsamer Regionen dedizierte Single-Tenant-Bereitstellungen an. Erfassen Sie verlorene Aufträge und Ausschreibungsanforderungen nach Land, um zu entscheiden, wo die nächste Region entstehen soll. Verträge und Nachweise Kunden wollen Residenzzusagen in Verträgen und Auftragsverarbeitungsverträgen sowie Nachweise: Architekturdokumentation, Listen der Unterauftragsverarbeiter mit Standorten, Zertifizierungen und Prüfberichte. Machen Sie Residenz zu einer dokumentierten, überprüfbaren Eigenschaft der Plattform – nicht nur zu einem Versprechen. Bestandskunden migrieren Wird eine neue Region eröffnet, möchten Bestandskunden womöglich umziehen. Eine Mandantenmigration umfasst das Kopieren von Datenbanken und Dateien, die Überprüfung jedes Objekts, die Umstellung des Routings und die nachweisbare Löschung der Daten in der alten Region. Entwickeln Sie Werkzeuge für die Mandantenmigration frühzeitig; sie werden immer wieder gebraucht. Residenz testen Prüfen Sie die Residenz regelmäßig in der Praxis: Verfolgen Sie, wo Daten, Backups, Logs und Indizes eines Testmandanten tatsächlich landen, prüfen Sie den ausgehenden Netzwerkverkehr jeder Region und bestätigen Sie, dass die Logs zum Support-Zugriff der Richtlinie entsprechen. Behandeln Sie jeden unerwarteten Datenfluss als zu behebenden Vorfall. Checkliste: Datenresidenz bei SaaS Festlegen, welche Datentypen in der Region bleiben müssen, einschließlich Backups, Logs und Indizes. Regionale Zellen oder eine regionale Data Plane mit minimaler globaler Control Plane wählen. Mandanten an Regionen binden und Anfragen entsprechend leiten. Regionalen Objektspeicher mit Replikation innerhalb der Region nutzen. Sekundäre Datenflüsse, KI-Funktionen und Support-Tools prüfen. Regionen dort aufbauen, wo Kunden sie brauchen, auch über Colocation. Bereitstellung und Updates über alle Regionen automatisieren. Support-Zugriff kontrollieren und protokollieren. Residenz in Verträgen dokumentieren und Nachweise bereitstellen. Werkzeuge für die Mandantenmigration entwickeln. Zusammenfassung Datenresidenz bei SaaS funktioniert, wenn sie in die Architektur eingebaut und nicht nachträglich angeflanscht wird: regionale Zellen, Mandantenbindung, regionaler Objektspeicher und strenge Kontrolle über Backups, Logs, KI-Funktionen und Support-Zugriff. Die Anforderungen unterscheiden sich zwischen der EU, Deutschland, Frankreich, dem Vereinigten Königreich, Japan, dem Nahen Osten und den USA, doch Kunden wollen überall klare Zusagen und Nachweise. Mit S3-kompatiblem Speicher können Anbieter Regionen bei Hyperscalern, lokalen Anbietern oder auf eigener Infrastruktur mit demselben Anwendungscode eröffnen. Häufig gestellte Fragen Was ist Datenresidenz bei SaaS? Die Zusage, dass die Daten eines Kunden einschließlich Backups und Logs in einem festgelegten Land oder einer festgelegten Region gespeichert und verarbeitet werden. Wie halten SaaS-Anbieter Daten in einer Region? Durch regionale Zellen, die Bindung von Mandanten an Regionen, regionalen Speicher und die Kontrolle sekundärer Datenflüsse. Zählen Backups zur Datenresidenz? Ja. Kunden und Aufsichtsbehörden erwarten in der Regel, dass Backups und Replikate in der vereinbarten Region bleiben. Was, wenn ein Hyperscaler in einem Land keine Region hat? Anbieter können lokale Cloud-Anbieter nutzen oder S3-kompatiblen Objektspeicher in Colocation-Einrichtungen betreiben, um dort Regionen zu eröffnen. Wie weisen Anbieter Residenz nach? Mit vertraglichen Zusagen, Architekturdokumentation, Listen der Unterauftragsverarbeiter, Zertifizierungen und Prüfberichten. Weiterführende Lektüre Dateispeicher für SaaS Personal-Cloud-Speicher von Telekommunikationsanbietern Speicher für selbst gehostetes Sync and Share Speicher für Fotos und Videos von Endkunden Datensouveränität vs. Datenresidenz
