Digitale Souveränität

Fragen Sie die meisten Infrastruktur-Teams, ob ihre Observability-Daten souverän sind, und Sie erhalten einen Rechenzentrumsstandort. „Die liegen in der Region Zürich.” Diese Antwort handelt von Residenz, und Residenz ist die einfache Hälfte. Souveränität ist die härtere Frage: Wer kann Zugriff auf diese Daten erzwingen, wer betreibt das System, das sie hält, und was passiert, wenn diese Beziehung endet?

Für eine Schweizer Bank, einen Versicherer, ein Spital oder ein Bundesamt haben diese Fragen konkretes rechtliches Gewicht — und Telemetrie ist eine Kategorie, die der Prüfung meist vollständig entgeht. Niemand klassifiziert Anwendungslogs als Datenbestand, bis ein Incident-Report einen Kundennamen in einem Stack Trace zeigt, der an eine US-amerikanische SaaS-Plattform geschickt wurde.

Residenz, Jurisdiktion und operative Kontrolle

Drei verschiedene Dinge werden im Wort „Souveränität” zusammengeworfen, und sie zu trennen ist der grösste Teil der Analyse:

• Residenz — wo die Bytes physisch liegen. Am einfachsten zu erfüllen, am einfachsten zu prüfen und für sich genommen die schwächste Garantie. Eine Schweizer Region ist ein Speicherort, kein rechtlicher Schutzschild.
• Jurisdiktion — wessen Gerichte die Herausgabe der Daten erzwingen können. Das folgt der Konzernstruktur des Anbieters, nicht der Postleitzahl der Festplatte. Ein Anbieter mit US-Muttergesellschaft, der eine Schweizer Region betreibt, unterliegt für Daten unter seiner Kontrolle weiterhin dem US-Rechtsweg. Deshalb sind „in der Schweiz gehostet” und „ausserhalb ausländischen Zugriffs” nicht dieselbe Aussage.
• Operative Kontrolle — wer das System technisch lesen, ändern oder anhalten kann. Halten die Support-Engineers des Anbieters die Schlüssel zu Ihrem Workspace, liegen sie innerhalb Ihrer Vertrauensgrenze, unabhängig davon, wo der Speicher liegt.

Ein nützlicher Test: Benennen Sie für alle drei die Einheit. Können Sie es nicht, ist genau das die Feststellung.

Warum Telemetrie der blinde Fleck ist

Datenbanken werden klassifiziert. Dokumentenablagen werden klassifiziert. Telemetrie meist nicht, weil sie sich wie ein Nebenprodukt anfühlt und nicht wie Inhalt. Praktisch ist sie eine reichhaltige, schlecht regierte Kopie dessen, was Ihre Systeme tun:

• Logs enthalten, was zum Zeitpunkt der Log-Anweisung im Scope war. Exception-Handler geben Request-Bodies aus. Debug-Zeilen drucken User-Objekte. Eine URL mit einem Token im Query-String landet in einem Access-Log. Niemand hat es geplant, und es passiert fortwährend.
• Das Volumen macht eine Prüfung unpraktikabel. Sie können eine Milliarde Datensätze pro Tag nicht von Hand klassifizieren — weshalb die Kontrolle strukturell sein muss und kein Prüfprozess.
• Die regulierte Kategorie ist enger als „PII”. Im Schweizer Bankwesen ist die härtere Kategorie die kundenidentifizierende Information: Der Name eines Firmenkunden ist kein Personendatum nach revDSG, fällt aber sehr wohl unter das Bankkundengeheimnis — und kein generischer Scanner findet ihn zuverlässig. Diese Unterscheidung ist das ganze Thema von PII vs CID (englisch).

Die Frage ist also nicht nur, wo Ihr Observability-Backend läuft. Sie lautet, was Ihr Netzwerk verlassen hat, um dorthin zu gelangen.

Die Schicht, in der die Entscheidung tatsächlich fällt

Souveränität für Telemetrie entscheidet sich am Punkt des Egress, und es gibt im Grunde nur zwei Entwürfe:

Entwurf A — das Backend entscheidet. Agents schicken alles an eine Plattform; die Plattform bietet regionale Speicherung, Aufbewahrungseinstellungen und Zugriffskontrollen. Ihre Souveränitätsposition ist, was Vertrag und Architektur des Anbieters zulassen, nachträglich verhandelt — und sie beginnt bei jedem Anbieterwechsel von vorn.

Entwurf B — Sie entscheiden vor dem Egress. Eine Erfassungsschicht, die Sie betreiben, sitzt zwischen den Systemen und jedem Backend. Sensible Felder werden auf dem Host maskiert. Datensätze werden nach Klassifizierung geroutet: kundenidentifizierende Daten in On-Premises-Speicher, anonyme Betriebsmetriken dorthin, wo es am günstigsten ist. Das Backend wird zum Konsumenten bereits regierter Daten, statt der Ort zu sein, an dem Governance stattfindet.

Entwurf B ist mehr Arbeit. Er ist auch der einzige, bei dem sich die Antwort auf „wem gehören diese Daten” nicht ändert, wenn ein Anbieter übernommen wird.

Was OpenTelemetry leistet — und was nicht

OpenTelemetry ist hier relevant, aber es lohnt sich, präzise zu sein, warum; das Marketing dazu übertreibt.

Was es leistet: Erfassung und Transport werden zu einem offenen Standard statt zum Agenten eines Anbieters. Instrumentierung, die Ihnen gehört, ein Wire-Format (OTLP), das Ihnen niemand lizenziert, und ein Collector, den Sie überallhin richten können. Das ist ein echter Ausstiegspfad — und ein Ausstiegspfad ist Voraussetzung für Souveränität: Ein Stack, den Sie nicht verlassen können, ist ein Stack, den jemand anderes kontrolliert. Die ehrliche Abgrenzung steht in Das Ende des Vendor-Lock-in.

Was es nicht leistet: OpenTelemetry ist kein Governance-System. Ein Collector schickt bereitwillig unmaskierte Kundendaten an ein ausländisches SaaS-Backend; der Standard hat dazu keine Meinung. Und er betreibt sich nicht selbst — eine OTel-Flotte braucht weiterhin eine Control Plane, und wo diese Control Plane läuft, ist selbst eine Souveränitätsfrage. Eine cloudgehostete Management-Schicht, die Ihre Konfiguration und Ihr Flotteninventar hält, ist ein Dritter in Ihrer Vertrauensgrenze — auch wenn die Telemetrie technisch anderswo fliesst.

Vier Fragen für die nächste Anbieterprüfung

• Welche Rechtseinheit betreibt den Dienst, und wo sitzt deren Muttergesellschaft? Nicht die Region — das Unternehmen.
• Kann Personal des Anbieters auf unsere Daten zugreifen, und ist dieser Zugriff technisch verhindert oder vertraglich zugesichert? Das sind sehr verschiedene Kontrollen.
• Sieht die Management-Ebene unsere Telemetrie oder nur unsere Konfiguration? Für eine Control Plane sollte die ehrliche Antwort „nur Konfiguration” lauten, während die Daten direkt von Ihren Collectors zu Ihren Zielen fliessen.
• Wie sieht der Ausstieg aus? Konkret: Was instrumentieren wir bei einer Kündigung neu, was bauen wir neu, und wie lange funktioniert die Erfassungsschicht weiter? Lautet die Antwort „jeden Agenten ersetzen”, ist die Bindung strukturell.

Wo anfangen

Sie brauchen kein Souveränitätsprogramm, um voranzukommen. Drei Schritte verbessern die Position materiell:

1. Egress inventarisieren. Welche Agents schicken was, an welches Unternehmen, unter welchem Vertrag. Das ist meist eine Tagesaufgabe, die alle überrascht.
2. An der Quelle maskieren für die sensiblen Felder, die Sie bereits kennen, sodass sie die Grenze nie überschreiten — PII in Logs maskieren.
3. Den Stream nach Klassifizierung aufteilen, sodass regulierte Datensätze ein On-Premises-Ziel haben und der Rest dorthin darf, wo es wirtschaftlich ist — Route Telemetry by Attribute (englisch).

Nichts davon verlangt einen Backend-Wechsel. Es ändert, wer entscheidet. Der vollständige Referenzentwurf — Agent, Schweizer Gateway-Ebene, getrennte Ziele, selbst gehostete Control Plane — steht in Eine souveräne Schweizer Telemetrie-Architektur bauen.