Single Pane of Glass: was es technisch wirklich bedeutet (und warum die meisten Anbieter daran vorbeireden)

TL;DR: "Single Pane of Glass" wird als UI-Feature verkauft, ist aber in Wahrheit ein Vertrag zwischen vier Subsystemen (einem gemeinsamen Asset-Modell, einem Event-Bus, einem Suchindex und einer föderierten Identity-Ebene), die sich einig sein müssen, was eine Sache ist, wem sie gehört, was mit ihr passiert ist und wer davon wissen darf. Sind sich diese vier uneinig, bleibt ein Portal statt einer Plattform; passen sie zusammen, schreibt sich das Dashboard fast von allein.

Jeder SOC-Anbieter behauptet einen Single Pane of Glass. Die Phrase ist abgenutzt. In der Praxis bedeutet sie meist ein Portal mit iFrames: ein Tab fürs EDR, eins für den Vulnerability-Scanner, eins fürs Asset-Inventar, jedes rendert seine eigene native UI in einem Wrapper, der nur ein Logo teilt. Der User sieht eine URL. Die Daten sind überhaupt nicht vereinheitlicht.

Dieser Beitrag handelt davon, was es wirklich braucht, auf Architekturebene, um die andere Art von Single Pane zu bauen: die, in der ein Alert vom Endpoint-Agent, ein Asset-Record aus der CMDB, eine Vulnerability vom Scanner und ein Incident-Ticket vom SOC-Analyst alle Referenzen auf dieselbe Entität sind, mit derselben Syntax abfragbar, durch dieselbe Rolle reguliert.

Es ist die Substanz hinter Krasper Suite, und der Teil, den ältere Anbieter gerne überspringen, weil ihn nachträglich auf eine Föderation zugekaufter Produkte aufzusetzen schwerer ist, als drum herum zu verkaufen.

Inhalt

1. Marketing-Version vs. Engineering-Version
2. Das gemeinsame Asset-Modell: warum die kanonische ID das ganze Spiel ist
3. Der Event-Bus: Choreografie statt Orchestrierung
4. Die Such-Oberfläche: wann Volltext wirklich zählt
5. Identity-Föderation mit OIDC: ein User, viele Subsysteme
6. Hexagonale Architektur: was alles zusammenhält
7. Ein Dutzend Services betreiben, ohne den Faden zu verlieren
8. Die Checkliste: wie man jeden Anbieter-Claim bewertet

1. Marketing-Version vs. Engineering-Version

Die Marketing-Version eines Single Pane of Glass:

"Alle Security-Tools an einem Ort."

Was sich genauso über jeden Browser mit einer Lesezeichen-Leiste sagen ließe.

Die Engineering-Version passt schwerer auf eine Folie:

Für jede Entität in der Plattform (Asset, Finding, Incident, User, Policy) muss jedes Subsystem, das sie beobachtet, sich auf ihre Identität einigen, Statusänderungen in eine gemeinsame Zeitleiste publishen, ihre Daten über eine gemeinsame Query-Oberfläche bereitstellen und Autorisierung an eine gemeinsame Identity-Ebene delegieren.

Dieser Satz beschreibt vier Verträge. Die meisten Plattformen erfüllen einen, meist die Dashboard-Ebene, und nennen es einen Tag. Der Rest wird mit nächtlichen Batch-Jobs zusammengeklebt, mit der Hoffnung, dass niemand bemerkt, dass die Join-Keys nicht ganz zueinander passen.

Halten diese Verträge, ist das Dashboard nur eine dünne Rendering-Schicht über konsistenten Daten. Rutschen sie weg, wird dasselbe Dashboard zur Tarnschicht über vier inkonsistenten Stores, in der jede übergreifende Frage, "Zeig mir jeden Host mit einem kritischen CVE, einem aktiven EDR-Alert und einem ungepatchten OS, im Besitz des Finance-Teams", einen Menschen verlangt, der vier Suchen laufen lässt und das Ergebnis von Hand zusammenflickt.

2. Das gemeinsame Asset-Modell: warum die kanonische ID das ganze Spiel ist

Das härteste Problem in einer solchen Plattform ist nicht das Alert-Volumen oder das Dashboarding. Es ist Entitätsauflösung. Der Endpoint-Agent nennt eine Maschine LAPTOP-7HD23-NEW. Der Vulnerability-Scanner nennt dieselbe Maschine bei ihrer IP, die sich wöchentlich ändert. Die CMDB führt sie als asset-id-44219. Das Ticketing-System referenziert sie per Seriennummer. Cloud-Asset-Discovery sieht sie als EC2-Instance-ID.

Konvergieren diese Identifier nicht, ist jede "Cross-Tool"-Query Rätselraten.

Die Lösung ist ein kanonisches Asset-Modell, das der Plattform gehört, nicht einer einzelnen Integration. Jede Integration ist dafür verantwortlich, ihren nativen Identifier beim Ingest in den kanonischen aufzulösen, nicht zur Query-Zeit:

Sobald jede Beobachtung dieselbe canonical_asset_id trägt, wird jede Frage zur Single-Query gegen einen Single-Index, egal welches Subsystem die Daten ursprünglich erzeugt hat. Das Asset wird zum Join-Key für die gesamte Plattform.

Die unglamouröse Wahrheit ist, dass der Großteil der Engineering-Arbeit an einer vereinheitlichten SOC-Plattform in diesen Resolver fließt: die Regeln, die Fallback-Ketten, die Konflikt-Behandlung wenn zwei Integrationen widersprechen, die Merge-Logik, wenn ein zuvor unbekanntes Asset später identifiziert wird. Abkürzen lässt sich davon nichts, und Anbieter, die diesen Schritt überspringen, enden mit parallelen Asset-Universen und überlassen den Abgleich dem Analysten im Kopf.

3. Der Event-Bus: Choreografie statt Orchestrierung

Der zweite Vertrag ist der Event-Bus. Jede Statusänderung in jedem Subsystem (ein neuer Alert, ein geschlossenes Finding, ein Asset, das online geht, eine aktualisierte Policy, ein Kommentar an einem Incident) wird als Event auf einen gemeinsamen Bus publisht. Andere Subsysteme abonnieren die Events, die sie interessieren.

Die Architektur-Entscheidung, die wir früh getroffen haben, war Choreografie statt Orchestrierung. Es gibt keine zentrale Workflow-Engine, die dem Incident-System sagt "jetzt warte auf den Vuln-Scanner". Jeder Service reagiert auf Events in seinem eigenen Tempo, in seinem eigenen Bounded Context, und publisht eigene Events bei eigenen Statusänderungen. Der Bus ist die einzige Kopplung.

Der Nutzen:

• Ein neues Subsystem kann hinzugefügt werden, ohne ein bestehendes zu ändern. Es abonniert die Events, die es braucht, und publisht seine eigenen.
• Replay ist trivial. Jeder Consumer kann zu einem Zeitpunkt zurückspulen und seinen abgeleiteten State aus dem Event-Stream neu aufbauen, nützlich für Backfills, Bugfixes und Disaster-Recovery.
• Der Audit-Trail ist ein Nebenprodukt der Architektur, kein nachträglich angesetztes Feature. Jede Statusänderung ist bereits chronologisch serialisiert.

Der Preis: Konsistenz wird eventual statt transaktional. Ein neuer Alert kann ein paar hundert Millisekunden vor dem Asset-Enrichment am Dashboard ankommen. Die Plattform muss in diesem Fenster sauber rendern. Die Disziplin, die das erzwingt, ist gesund: sie zwingt zu UIs, die zeigen, was bisher bekannt ist, statt zu blockieren auf alles, was möglicherweise bekannt sein könnte.

Ein konkretes Event-Shape, intern-namen-redigiert, sieht so aus:

Drei Dinge fallen auf: die kanonische Asset-ID ist ein First-Class-Feld, der Tenant ist explizit (kein impliziter Kontext), und das Payload ist nach Event-Typ namespaced. Diese drei Gewohnheiten eliminieren etwa 80 Prozent der Integrations-Schmerzen, die später kommen.

4. Die Such-Oberfläche: wann Volltext wirklich zählt

Sind Events und Assets vereinheitlicht, kommt die Frage, wie Analysten sie tatsächlich abfragen. Zwei Failure-Modes sind häufig:

1. Die Plattform exponiert eine separate Suchbox pro Subsystem. Analysten raten, in welche Box sie tippen sollen. Falsches Raten = leeres Ergebnis, obwohl die Antwort zwei Boxen weiter existierte.
2. Die Plattform exponiert eine Suchbox, die nur Exact-Match auf kanonischen Feldern macht. Analysten versuchen error 504 nginx finance-team und bekommen nichts, obwohl die Wörter über drei verschiedene Alert-Payloads verteilt vorkommen.

Ein vereinheitlichtes SOC braucht Volltextsuche über jeden Entitätstyp (Assets, Alerts, Findings, Incidents, Kommentare, Tickets) und respektiert strukturierte Filter in derselben Query.

Hier verdient ein dedizierter Suchindex sein Geld. Wir indexieren jede Entität in dem Moment, in dem ihr Event den Bus trifft, mit der kanonischen Asset-ID als Facette, dem Tenant als Hard-Filter und den Freitext-Payload-Feldern als durchsuchbarem Inhalt. Die Query-Sprache unterstützt beides:

Diese Query greift gleichzeitig in Incidents, Alerts und Findings, respektiert RBAC am Asset-Owner-Feld und liefert geranktе Resultate über Entitätstypen hinweg. Der Analyst muss nicht wissen, welches Subsystem welches Feld besitzt. Das ist, was "Single Pane" in der Praxis bedeutet.

Die Lektion: Suche als Plattform-Capability behandeln, nicht als Per-Service-Feature. Ein vereinheitlichter Index ist ein Kraftmultiplikator; Per-Service-Suchleisten sind eine Steuer auf jede Untersuchung.

5. Identity-Föderation mit OIDC: ein User, viele Subsysteme

Der vierte Vertrag ist Identität. Loggt sich der Analyst ins Dashboard ein, aber jedes Subsystem hält seine eigene User-Tabelle, hast du bestenfalls ein einziges Login, keine einzige Identität.

OIDC, mit einem dedizierten Identity-Broker vor jedem Subsystem, ist der unaufgeregte Weg:

Eine einzige Rollenzuweisung im Identity-Broker propagiert beim nächsten Token-Refresh in jedes Subsystem. Es gibt kein Per-Service-User-Management. Es gibt keinen out-of-band Sync-Job, der driftet. Wenn ein Mitarbeiter geht und der IdP ihn deaktiviert, verliert jedes Subsystem im selben Moment den Zugang, weil jedes Subsystem dasselbe Token verlangt, und das Token dieselbe Identität verlangt, und die Identität nicht mehr existiert.

OIDC liefert auch Tenant-Isolation auf Token-Ebene: der tenant_id-Claim ist Teil des Access-Tokens, jeder API-Request wird vom Gateway auf diesen Tenant gescoped, und ein Service, der das ignoriert, kommt nicht am Review vorbei, weil Integrationstests fehlschlagen.

Neu ist daran nichts; es ist das Standard-Muster. Worauf es ankommt, ist, es konsistent über jedes einzelne Subsystem hinweg zu nutzen, ohne Ausnahmen "weil Integration X zugekauft wurde und noch ihr eigenes User-Modell hat." Die Ausnahmen sind, wo der Single Pane aufhört, single zu sein.

6. Hexagonale Architektur: was alles zusammenhält

Der Architektur-Stil, der diese vier Verträge über Jahre statt Monate wartbar hält, ist der unter hexagonaler Architektur, Ports-and-Adapters oder Clean Architecture bekannte. Die Form ist immer dieselbe: ein Domain-Kern, der Entitäten und Business-Regeln kennt, umgeben von Ports (Interfaces), die definieren wie er mit der Außenwelt spricht, und Adaptern (Implementierungen), die diese Ports an konkrete Technologien binden.

Konkret: die Asset-Domain weiß nicht, ob Asset-Daten in PostgreSQL leben, aus einer REST-Integration kommen, über den Event-Bus eintreffen oder via externen Index gesucht werden. Sie weiß nur, dass AssetRepository, AssetEventPublisher und AssetSearchIndexer Ports sind, die sie aufrufen kann. Die Adapter-Schicht verdrahtet diese Ports mit der tatsächlichen Infrastruktur.

Der Nutzen zeigt sich genau dann, wenn man ihn am meisten braucht:

• Den Such-Backend zu tauschen ist eine Ein-Adapter-Änderung, kein Domain-Rewrite.
• Eine neue Integration hinzuzufügen ist ein Adapter auf der anderen Seite, kein chirurgischer Eingriff durch den ganzen Stack.
• Die Domain zu testen ist trivial: jeder Port hat einen In-Memory-Fake. Keine gemockten HTTP-Calls, keine Test-Container für Unit-Tests.
• Onboarding neuer Engineers reduziert sich auf "lerne die Domain-Sprache; die Infrastruktur ist veränderbares Detail."

Die Disziplin ist härter, als sie klingt. Die Versuchung, vom Controller "nur dieses eine Mal aus Performance-Gründen" direkt in die Datenbank zu greifen, ist konstant. Die Grenze zu halten ist, was die Plattform davor bewahrt, unter ihrem eigenen Gewicht in einen verteilten Monolithen zu kollabieren.

7. Ein Dutzend Services betreiben, ohne den Faden zu verlieren

Eine so gebaute Plattform zerlegt sich natürlich in ein Dutzend+ unabhängig deploybare Services: jeder ein Bounded Context, jeder mit eigener Datenbank, jeder publisht in und abonniert vom gemeinsamen Event-Bus, jeder exponiert seine API hinter dem gemeinsamen Identity-Gateway.

Ein paar operative Lektionen stechen aus dem Betrieb so vieler Services in Produktion heraus.

Event-Schema-Versionierung ist nicht verhandelbar. Jeder Event-Typ trägt ein Schema-Version-Feld, Consumer tolerieren die Version, für die sie gebaut wurden, und ignorieren unbekannte Zukunftsfelder, und Breaking-Changes shippen als neue Event-Typen statt als In-Place-Rewrites. Klingt offensichtlich, aber die Kosten, das auch nur einmal falsch zu machen, sind eine mehrwöchige Migration über jeden Consumer.

Observability muss eine Plattform-Capability sein und nicht etwas, das jeder Service neu erfindet: ein einziges strukturiertes Log-Format über alle Services, eine einzige Distributed-Trace-ID, die durch den Bus propagiert wird, ein einziger Metrics-Namespace. Bau das an Tag eins oder kämpfe damit im dritten Jahr.

Idempotenz-Keys gehören auf den Bus. Jedes Event trägt eine eindeutige event_id, und jeder Consumer dedupliziert darauf, was eine ganze Klasse von "wurde die Mail zweimal verschickt"-Bugs kollabiert, bevor sie passieren.

Beim Storage gilt Schema-Evolution vor Daten-Migration. Neue Felder hinzufügen, alte sanft deprecaten, nie löschen; eine zusätzliche Spalte kostet fast nichts, während eine koordinierte Stop-the-World-Migration über ein Dutzend Services ruinös teuer ist.

Und schließlich: ein goldenes Integration-Test-Environment mit echten Services. Unit-Tests dürfen gegen Fakes laufen, aber Integration-Tests müssen gegen echte Services in Compose laufen, denn gemockte Integration-Tests passen genau dann, wenn Produktion bricht.

8. Die Checkliste: wie man jeden Anbieter-Claim bewertet

Wer eine SOC-Plattform mit Single-Pane-of-Glass-Anspruch evaluiert, sollte folgende Fragen stellen, in der Reihenfolge, in der sie Substanz von Marketing am verlässlichsten trennen:

Erstens: Was ist Ihr kanonischer Asset-Identifier, und wie wird er aus nativen Identifiern über Integrationen hinweg abgeleitet? Ist die Antwort vage, hat die Plattform keinen.

Zweitens: Zeigen Sie mir eine Query, die über mehr als ein Subsystem spannt und in einem Durchgang gerankte Resultate liefert. Öffnet die Demo zwei Browser-Tabs, haben Sie Ihre Antwort.

Drittens: Wenn ich einen User im IdP widerrufe, wie lange dauert es, bis jedes Subsystem in Ihrer Plattform sein Token ablehnt? Die ehrliche Antwort ist "beim nächsten Token-Refresh, typischerweise unter fünf Minuten." Alles länger heißt out-of-band User-Sync, was Drift heißt, was Audit-Findings heißt.

Viertens: Beschreiben Sie, wie eine neue Integration hinzugefügt wird. Erfordert die Antwort Änderungen außerhalb des Bounded Contexts der Integration selbst, ist die Architektur enger gekoppelt, als das Marketing behauptet.

Fünftens: Zeigen Sie mir das Event-Schema einer Ihrer Kern-Entitäten. Gibt es kein Event-Schema, gibt es keinen Event-Bus, und der "Single Pane" wird mit Polling und Hoffnung zusammengehalten.

Eine Plattform, die diese Fragen gut beantwortet, hat das Engineering geleistet; eine, die ausweicht, das Marketing. Dieser Unterschied zählt am meisten, wenn ein echter Incident drei Subsysteme spannt und der Analyst sechs Minuten zum Triagieren hat.

Abschluss

Ein Single Pane of Glass ist ein Architektur-Commitment, das sich zufällig als Dashboard zeigt: darunter liegen ein gemeinsames Asset-Modell, ein Event-Bus, eine vereinheitlichte Such-Oberfläche und eine föderierte Identity-Ebene, eingewickelt in modulare Grenzen, die die Plattform sich ohne Rewrites entwickeln lassen.

Alle sehen das Dashboard. Ob es die Wahrheit sagt, entscheiden die vier Verträge darunter.

Der nächste Beitrag in dieser Serie geht tief in einen dieser Verträge (den Event-Bus) und wie sein Schema, Consumer-Vertrag und Replay-Tooling in der Praxis aussehen.

Weiterlesen

• Alistair Cockburn: Hexagonal Architecture (2005)
• Martin Fowler: Event-Driven Architecture und Choreography vs. Orchestration
• Sam Newman: Building Microservices, 2. Auflage
• NIST SP 800-207: Zero Trust Architecture