Security-Plattformen verarbeiten besonders sensible Informationen: Identitäten, Geräteinformationen, Zugriffsentscheidungen, Richtlinien, Alarme, Metadaten und Protokolle. Deshalb klingt die Forderung zunächst einfach: „Die Lösung muss in Europa gehostet werden.“ Doch der Standort eines Rechenzentrums beantwortet nur einen Teil der Frage.
Ein Dienst kann Daten in Deutschland speichern und trotzdem von nicht transparenten Supportwegen, externen Administrationskonten, proprietären Exportformaten oder einer schwer auflösbaren Lieferkette abhängen. Umgekehrt kann eine global betriebene Security-Plattform konkrete Möglichkeiten für regionale Verarbeitung, Log-Speicherung und kundenseitige Kontrolle bieten. Eine belastbare Entscheidung braucht daher mehr als ein Herkunftslabel.
Souveränität entsteht, wenn ein Unternehmen weiß, welche Daten wo verarbeitet werden, wer technisch darauf zugreifen kann, wer den Betrieb kontrolliert und wie sich die Abhängigkeit später wieder auflösen lässt.
Security-Daten sind kein gewöhnlicher Cloud-Workload
Bei einer Office-Anwendung steht oft die Speicherung von Dokumenten im Vordergrund. Eine Security-Architektur besitzt zusätzliche Datenflüsse. Zscaler verarbeitet beispielsweise Internet- und Zugriffsverkehr, Richtlinienentscheidungen und Transaktionslogs. CrowdStrike bewertet Geräte- und Sicherheitszustände und liefert Telemetrie für Erkennung und Reaktion.
Für die Souveränitätsprüfung sollten deshalb mindestens fünf Datenklassen getrennt werden:
- Inhaltsdaten, die während einer Sicherheitsprüfung verarbeitet werden,
- Transaktions- und Verbindungsmetadaten,
- Identitäts- und Gerätekontext,
- Sicherheitsalarme und Untersuchungsergebnisse,
- Konfigurations-, Audit- und Administrationsdaten.
Jede Klasse kann einen anderen Speicherort, eine andere Aufbewahrungsfrist und einen anderen Betreiberpfad haben. Eine allgemeine Aussage wie „EU-hosted“ ersetzt diese Zuordnung nicht.
Kontrollfeld 1: Datenstandort und tatsächliche Verarbeitung
Die erste Frage lautet nicht nur „Wo liegen die Daten?“, sondern „Wo werden sie gespeichert, verarbeitet, gesichert und wiederhergestellt?“ Dazu gehören Primärsysteme, Backups, Telemetrie, Diagnosepakete und Support-Exporte.
Zscaler beschreibt für europäische Kunden regionale Verarbeitungs- und Log-Optionen. Kunden können laut Anbieter europäische Infrastruktur wählen und den Speicherort ihrer Logs steuern. Das ist eine wichtige Grundlage, muss aber für den konkreten Tenant und die tatsächlich lizenzierten Dienste bestätigt werden.
Für ein ergänzendes Hosting- oder Betriebsmodell muss dokumentiert sein, welche Komponenten auf welcher Infrastruktur laufen und welche Daten weiterhin in den jeweiligen Hersteller-Clouds verbleiben.
Kontrollfeld 2: Schlüssel und kryptografischer Zugriff
Verschlüsselung ist notwendig, aber allein noch kein Beweis für Souveränität. Entscheidend ist, wer Schlüssel erzeugt, verwaltet, rotiert und im Ausnahmefall verwenden kann. Die Europäische Kommission nennt die wirksame Kontrolle des Kunden über kryptografischen Datenzugriff ausdrücklich als Souveränitätskriterium.
Ein Architekturbrief sollte daher zeigen:
- welche Daten im Transport und im Ruhezustand verschlüsselt sind,
- welche Partei die Schlüssel kontrolliert,
- ob kundenseitige Schlüssel oder getrennte Schlüsselbereiche möglich sind,
- wie Rotation, Sperrung und Wiederherstellung funktionieren,
- welche Notfallzugriffe existieren und wie sie protokolliert werden.
Kontrollfeld 3: Betrieb und privilegierte Zugriffe
Viele Risiken liegen nicht im normalen Datenpfad, sondern im Betrieb. Wer darf Konfigurationen ändern? Wer kann Supportpakete einsehen? Welche Rollen besitzen der Hersteller, der Hosting-Anbieter, der Managed-Service-Partner und das Kundenteam?
Ein souveränes Betriebsmodell braucht eine überprüfbare RACI: Wer ist verantwortlich, wer führt aus, wer gibt frei und wer wird informiert? Privilegierte Zugriffe sollten zeitlich begrenzt, nachvollziehbar und auf den konkreten Auftrag beschränkt sein. Für kritische Änderungen sind Vier-Augen-Freigaben und eine vollständige Auditspur wichtiger als ein pauschales Versprechen.
Kontrollfeld 4: Rechtsraum und Lieferkette
Der Sitz des Rechenzentrums ist nicht automatisch identisch mit dem Rechtsraum aller Beteiligten. Deshalb gehören Anbieter, verbundene Unternehmen, Unterauftragnehmer, Supportstandorte und Herstellerabhängigkeiten in die Bewertung.
STACKIT positioniert sich als europäische Cloud mit Rechenzentren in Deutschland und Österreich und betont offene Technologien sowie die Vermeidung wirtschaftlicher Migrationsbarrieren. Für einen konkreten Security-Service muss daraus jedoch ein vertraglich und technisch prüfbarer Scope werden: Welche Komponente läuft tatsächlich dort? Welche bleibt ein globaler Herstellerservice? Welche Partei schuldet welche Leistung?
Kontrollfeld 5: Portabilität und Exit
Souveränität zeigt sich spätestens beim Wechsel. Können Konfigurationen, Logs, Regeln und Nachweise in dokumentierten Formaten exportiert werden? Wie lange dauert die Übergabe? Welche Daten werden anschließend gelöscht? Wie wird die Löschung belegt?
Ein guter Exit-Plan entsteht vor Vertragsabschluss. Er beschreibt Datenexport, Konfigurationsübergabe, Schlüsselwechsel, Abschaltung privilegierter Zugriffe und einen realistischen Parallelbetrieb. Die europäischen Regeln zum Cloud-Wechsel stärken die Portabilität, ersetzen aber keinen technischen Migrationsplan.
Kontrollfeld 6: Resilienz und Notbetrieb
Lokale Datenhaltung ist wenig wert, wenn eine Störung den Security-Betrieb handlungsunfähig macht. Für Zscaler- und CrowdStrike-nahe Betriebsleistungen müssen deshalb Wiederanlauf, Ersatzkommunikation, Konfigurationssicherung, Verantwortlichkeiten und Abhängigkeiten von Herstellerzugängen dokumentiert sein.
Die richtige Frage lautet: Welche Security-Funktion bleibt bei einem Ausfall erhalten, welche fällt kontrolliert zurück und wer darf den Notbetrieb aktivieren? Diese Antworten gehören in Runbooks und Tests, nicht nur in Vertragsanhänge.
Aus einem Label wird ein prüfbares Betriebsmodell
Eine sinnvolle Souveränitätsentscheidung endet nicht mit „deutsches Rechenzentrum“. Sie verbindet Datenflüsse, Rechtsraum, Schlüssel, Betriebsrollen, Supportzugriffe, Portabilität und Resilienz.
Für Zscaler und CrowdStrike ist das besonders wichtig, weil die Plattformen unterschiedliche Aufgaben und Datenarten abdecken. Ein ergänzendes Hosting- und Betriebsmodell darf diese Realität nicht verwischen. Es muss sichtbar machen, welche Kontrollen der Hersteller bereitstellt, welche Verantwortung beim Kunden bleibt und welche Leistungen ein Partner übernimmt.
So entsteht ein Ergebnis, das Security, Datenschutz, Einkauf und Betrieb gemeinsam bewerten können: keine diffuse Souveränitätsbehauptung, sondern eine Architektur mit nachweisbaren Kontrollpunkten.