Souveräne Telemetrie-Architektur

Die Begründung für souveräne Telemetrie steht an anderer Stelle in diesem Blog — Wem gehören Ihre Observability-Daten ist das Warum: Residenz ist nicht Jurisdiktion, Jurisdiktion ist nicht operative Kontrolle, und Telemetrie ist die Datenklasse, die niemand klassifiziert hat. Dieser Beitrag ist das Wie. Es ist die Referenzarchitektur, die eine Schweizer Bank, ein Versicherer, ein Spital oder ein Bundesamt einem Architekturboard vorlegen kann — jede Komponente an die Kontrolle gebunden, die sie liefert.

Sie baut auf der generischen zweistufigen Form in OpenTelemetry-Architektur für Unternehmen auf — Agents, eine Gateway-Ebene, eine Control Plane — und ergänzt, was eine Souveränitätsanforderung ändert: wo jede Ebene physisch läuft, was mit einem Datensatz passiert, bevor er hinaus darf, und welche Nachweise das Ganze erzeugt.

Der Entwurf in einem Absatz

Jeder Host betreibt einen Agent-Collector, der Datensätze klassifiziert und maskiert, bevor sie ihn verlassen. Agents senden ausschliesslich an eine Gateway-Ebene auf Schweizer Infrastruktur unter Ihrer Kontrolle, über zwei Standorte. Das Gateway routet jeden Datensatz nach seiner Klassifizierung: kundenidentifizierende und Personendaten an On-Premises-Ziele, anonyme Betriebsdaten dorthin, wo es wirtschaftlich ist — Cloud eingeschlossen. Eine selbst gehostete Control Plane konfiguriert jeden Collector, führt eine versionierte Aufzeichnung dessen, was jeder ausführen sollte, und sieht nie Telemetrie. Egress aus dem Bestand existiert nur am Gateway, nur zu den freigegebenen Zielen. Das ist das Ganze; der Rest ist Detail und Nachweis.

Ebene 1 — der Agent: klassifizieren und maskieren vor dem Egress

Die Souveränitätsentscheidung fällt am ersten Hop, denn jeder spätere Hop sieht nur, was der Agent durchgelassen hat.

• Klassifizierung als Resource-Attribut. Jede Quelle wird am Agenten mit einer Datenklasse getaggt — data.class = cid | pii | ops —, abgeleitet aus dem, was die Quelle ist (die Logs des Kernbankensystems sind per Definition cid, Node-Metriken sind ops), nicht aus dem Scannen von Inhalten. Inhaltsscanning findet PII; kundenidentifizierende Daten, die härtere Schweizer Kategorie, kann es strukturell nicht finden — PII vs CID (englisch). Nach Quelle klassifizieren, scannen als zweite Linie.
• Maskierung auf dem Host. Bekannt sensible Felder werden im Agenten maskiert, sodass der Wert nicht einmal das interne Netz zum Gateway überquert. Das ist die Kontrolle, die „die Daten haben den Host nie verlassen” zu einer wahren Aussage macht statt zu einer Hoffnung — PII in Logs maskieren.
• Kein direkter Egress. Der einzige Exporter des Agenten ist das Gateway. Er hat keine Credentials für ein Backend und keine Route ins Internet. Ein auf Anwendungsebene kompromittierter Host kann über seinen Collector nichts abfliessen lassen.

Ebene 2 — die Gateway-Ebene: in der Schweiz terminieren, nach Klasse routen

• Physisch schweizerisch, operativ Ihre. Die Gateway-Ebene läuft auf Infrastruktur, deren Betreiber, Jurisdiktion und physischen Standort Sie jeweils benennen können. Zwei Standorte, aktiv-aktiv, lastverteilt — der Verfügbarkeitsentwurf steht in Collector-High-Availability, und in einem regulierten Bestand ist er zugleich der Resilienz-Nachweis, den FINMA 2023/1 verlangt.
• Routing nach data.class. Am Gateway teilt sich der Stream: cid- und pii-Datensätze in On-Premises-Speicher; ops-Datensätze an das günstigste Ziel, das ein Cloud-Backend sein darf. Eine Pipeline, einmal klassifiziert, Ziele pro Datensatz gewählt — Route Telemetry by Attribute (englisch).
• Der einzige Egress-Punkt. Firewall-Regeln erlauben ausgehende Verbindungen nur von den Gateway-Adressen, nur zu den freigegebenen Zielendpunkten. Ein Ziel hinzuzufügen ist damit eine Firewall-Änderung mit Änderungsnachweis — nicht etwas, das ein Engineer in einer Konfigurationsdatei erledigt.
• Schwere Verarbeitung lebt hier. Tail-Sampling, Aggregation, Auffächerung — die Arbeit, die den ganzen Trace oder die ganze Flotte sehen muss — passiert einmal am Gateway und hält die Agents leicht.

Ebene 3 — Ziele: getrennt, nicht konsolidiert

Die Versuchung ist ein Backend. Der souveräne Entwurf hat bewusst zwei oder mehr:

• On-Premises für regulierte Klassen. Was immer Sie betreiben — ein Loki/Mimir/Tempo-Stack, Elastic, Splunk — für cid und pii, auf eigener Hardware oder bei einem Schweizer Anbieter, dessen Jurisdiktion und Betreiber Sie benannt haben. Aufbewahrung auf das regulatorische Minimum gesetzt und nicht länger.
• Wo immer es wirtschaftlich ist für ops. Node-Metriken, Health-Signale und Plattformlogs tragen keinen regulierten Inhalt und dürfen zu Cloud-Preisen in ein Cloud-Backend. Hier sitzt die Kostenersparnis, die den Rest finanziert.
• Nichts entscheidet am Ziel. Das Backend erhält bereits klassifizierte, bereits maskierte Daten. Seine Zugriffskontrollen sind eine zweite Linie, nie die erste.

Ebene 4 — die Control Plane: von Ihnen gehostet, blind für Daten

Das ist die Ebene, die die meisten Entwürfe vergessen — und die, nach der Prüfer zunehmend direkt fragen.

• Selbst gehostet, in der Schweiz. Das System, das die Konfiguration jedes Collectors und das Flotteninventar hält, ist selbst im Geltungsbereich. Eine SaaS-Management-Ebene ist ein Dritter in Ihrer Vertrauensgrenze, unabhängig davon, wo Telemetrie fliesst.
• Nur Konfiguration. Die Control Plane verteilt Config und empfängt Health; sie ist nie im Datenpfad. Diese Trennung ist es, die Sie „kein Dritter kann unsere Telemetrie sehen” sagen lässt und es ernst meinen — siehe wie LinkMesh Daten verarbeitet als eine konkrete Ausprägung des Modells.
• Autoritativ und auditiert. Jede Konfigurationsänderung ist versioniert mit Wer, Was und Wann, über OpAMP an die Nodes ausgerollt, und jeder Node meldet den Hash dessen, was er tatsächlich ausführt. Ein Node, der von der beabsichtigten Config abweicht — der mit der Maskierungsregel —, wird markiert, nicht von einem Prüfer entdeckt — Drift erkennen.
• Vorschau vor dem Rollout. Eine Maskierungs- oder Drop-Regel wird an einem echten erfassten Sample getestet, bevor sie flottenweit geht. Eine falsche Regex, die still ein Feld entmaskiert, ist der Fehlermodus, den dieser Entwurf verhindern soll.

Die Nachweise, die die Architektur erzeugt

Eine Architektur, die eine Aufsicht zufriedenstellt, ist eine, die Dinge zeigen kann. Diese erzeugt als Nebenprodukt des Betriebs:

Frage	Nachweis
Wo wird Telemetrie verarbeitet und durch wen?	Standorte von Gateway und Control Plane, benannte Betreiber; die Egress-Freigabeliste
Was hat das Netzwerk verlassen, und in welcher Form?	Klassifizierung pro Quelle; Maskierungsregeln in versionierter Config; Durchsatz pro Kante nach Klasse
Wer konnte ändern, was erfasst wird?	RBAC der Control Plane und der Änderungs-Audit-Trail
Was führte Node N am Datum D aus?	Versionshistorie der Config plus Hash der laufenden Config pro Node
Können wir einen Anbieter verlassen?	Instrumentierung und Erfassung sind OTLP/OpenTelemetry; Ziele sind Exporter-Änderungen

Was das nicht abdeckt

• Die Anwendungsebene. Instrumentierung, und was ein SDK auf einen Span legt, ist die Kontrolle des Anwendungsteams. Die Architektur maskiert, was den Agenten erreicht; sie kann nicht rückgängig machen, was der Code emittiert hat. Der Beitrag zum Java Agent behandelt diese Seite.
• Backup, Schlüsselverwaltung und BCM für die Ziele selbst. Das ist das Problem der Ziele, und es gilt die übliche Praxis.
• Rechtliche Festlegungen. Welche Daten für Ihr Institut unter dem Bankkundengeheimnis cid sind, entscheidet Ihre Compliance-Funktion. Die Architektur gibt ihr einen Ort, das festzuhalten (die Quellenklassifizierung), und einen Mechanismus, es durchzusetzen.

Wo anfangen

1. Quellen klassifizieren, nicht Inhalte — eine Tabelle jeder Telemetriequelle mit ihrer data.class, abgestimmt mit der Compliance. Das ist das Fundament des Entwurfs und dauert Tage, nicht Monate.
2. Die Gateway-Ebene aufbauen auf Infrastruktur, die Sie benennen können, und eine ops-Quelle Ende zu Ende hindurchführen.
3. Eine cid-Quelle ergänzen mit Maskierung am Agenten und einem On-Premises-Ziel, und die Maskierung an einem erfassten Sample verifizieren.
4. Egress schliessen, sodass nur das Gateway hinaus darf, dann die restlichen Quellen umziehen.
5. Die Control Plane hosten, bevor die Flotte so gross ist, dass Drift unsichtbar wird.