Das Ende der Gateways: Zero Trust auf Messaging-Ebene mit Apache Pulsar

Das Ende der Gateways?

Es beginnt oft unspektakulär: ein neuer Partner braucht Zugriff, ein Shop soll Bestellungen direkt übergeben, eine App möchte Lagerstände in Echtzeit sehen. Also entsteht ein weiterer technischer Kontrollpunkt zwischen Quelle und Zielsystem.

Dann noch einer. Und noch einer.

Mit jeder Integration wird dieselbe Management-Frage drängender: Wer darf jetzt eigentlich alles zugreifen, und wie stellen wir sicher, dass dieser Zugriff nicht ausgenutzt wird?

Viele Teams beantworten das zunächst mit Infrastruktur: API Gateway, ESB, Reverse Proxy, Security Appliance, Service Mesh. Oder mit dem nächsten Schritt: ein Cluster für Produktion, ein zweiter für Arbeitsvorbereitung, sauber physisch getrennt.

Das wirkt auf den ersten Blick plausibel. Tatsächlich ist es ein gefährlicher Irrtum.

Wer entscheidet eigentlich, welche fachlichen Befehle ein System überhaupt erzeugen darf – und wer nicht?

Genau dort liegt das Risiko: Systeme können technisch korrekt authentifiziert sein, im richtigen Netzwerk stehen und trotzdem Commands senden, die sie aus Prozesssicht nie senden dürften.

Gerade für ein ERP ist das der entscheidende Punkt. Nicht die Frage, ob ein System verbunden ist, sondern ob es genau diesen fachlichen Eingriff auslösen darf.

Und genau hier beginnt die eigentliche Geschichte dieses Artikels: Warum physische Trennung das konkrete Problem nicht löst, warum es auch bei zwei oder mehr hintereinandergeschalteten Clustern bestehen bleibt, und warum Apache Pulsar als Gatekeeper für fachliche Integrität den entscheidenden Unterschied macht.

Warum Legacy-Systeme keine Zero-Trust-Systeme sind

Viele ERP-Systeme stammen aus einer Zeit, in der Integrationen überschaubar waren.

Es gab:

• wenige Produzenten
• klar definierte Schnittstellen
• kontrollierte Batch-Prozesse
• interne Netzwerke
• implizites Vertrauen

Mit zunehmender Digitalisierung verändert sich diese Situation grundlegend.

Plötzlich entstehen Anbindungen an:

• Webshops
• Mobile Apps
• IoT-Plattformen
• Partnernetzwerke
• Fremdsysteme
• Automatisierungsplattformen

Die Folge ist häufig dieselbe:

Immer mehr Systeme dürfen direkt oder indirekt mit dem ERP sprechen.

Genau hier beginnt das eigentliche Sicherheitsproblem.

Zero Trust auf Messaging-Ebene

Zero Trust wird häufig auf Netzwerk- oder API-Ebene diskutiert. In der Praxis heißt das meist: Identität prüfen, Rechte vergeben, Verbindungen absichern, Zugriffe segmentieren.

Für klassische Request/Response-Systeme ist das sinnvoll, greift in modernen Integrationslandschaften aber zu kurz. Dort laufen zentrale Geschäftsprozesse längst über Events, Commands, Streams, Queues und Topics.

Wenn geschäftskritische Entscheidungen über Nachrichten transportiert werden, darf die Vertrauensgrenze nicht am HTTP-Endpunkt enden. Dann muss jede Nachricht denselben Maßstab bestehen wie ein API-Request: Wer hat sie erzeugt, aus welchem Topic kommt sie, welchen Command enthält sie, entspricht sie einer fachlichen Policy und darf sie das Zielsystem überhaupt erreichen?

Die eigentliche Vertrauensentscheidung verschiebt sich damit vom Netzwerk auf den Datenstrom.

Zero Trust wird zu:

Trust nothing. Validate every message.

Ein einfaches Command-Format

Nehmen wir ein altes, kompaktes ERP-Format an:

ORD+4711+ACME+1234.56

Das erste Feld beschreibt den Command.

ORD  Auftrag anlegen
CUS  Kunde ändern
STK  Bestand ändern
CAN  Auftrag stornieren

Das Format ist absichtlich simpel.

Es steht beispielhaft für viele in der Industrie verbreitete proprietäre Textformate, die in gewachsenen Legacy-Landschaften bis heute im Einsatz sind.

Der entscheidende Punkt ist:

Der Command steht an einer definierten Stelle.

Damit kann er extrahiert und gegen eine Policy geprüft werden.

Topic-Struktur als Sicherheitsmodell

Statt allen Produzenten Zugriff auf ein gemeinsames ERP-Topic zu geben, werden Eingangskanäle fachlich getrennt.

persistent://public/raw/shop
persistent://public/raw/crm
persistent://public/raw/warehouse

Jeder Produzent bekommt nur Schreibrechte auf seinen eigenen Eingangskanal.

Daraus entsteht eine einfache, aber starke Policy:

(raw/shop, ORD) -> PASS
(raw/shop, STK) -> FAIL

(raw/crm, CUS) -> PASS
(raw/crm, CAN) -> FAIL

Apache Pulsar als Gatekeeper

Die Architektur sieht dann so aus:

Shop
  |
  v
raw/shop
  |
  v
Command Filter (Policy Enforcement Point)
  |
  +--> erp/ingress
  |
  +--> erp/quarantine

Das ERP konsumiert nicht mehr aus raw/shop.

Es konsumiert ausschließlich aus:

persistent://public/erp/ingress

Nur eine kontrollierte Komponente darf dorthin schreiben.

Producer  -> produce auf raw/*
Function  -> consume raw/*, produce erp/*
ERP       -> consume erp/ingress

Damit wird Pulsar zur Sicherheitsgrenze – nicht als nachträglicher Proxy oder zusätzliches Gateway, sondern als brokerseitig kontrollierte Integrationsschicht.

Der hier gezeigte Command Filter ist dabei genau der Policy Enforcement Point: Dort wird jede Nachricht gegen die fachliche Policy geprüft und erst danach weitergeleitet oder in Quarantäne verschoben.

Pulsar Functions als Policy Enforcement Point

Der Command Filter aus dem vorherigen Abschnitt ist in der Umsetzung genau diese Pulsar Function.

Eine Pulsar Function konsumiert die eingehenden Nachrichten.

Sie extrahiert den Command:

String command = payload.substring(0, 3);

Dann prüft sie Topic und Command gegen eine Policy.

if (allowed(topic, command)) {
    forward();
} else {
    quarantine();
}

Nur freigegebene Nachrichten erreichen das ERP.

raw/*
   |
   v
Policy Function
   |
   +--> erp/ingress
   |
   +--> erp/quarantine

Warum wir plötzlich kein Gateway mehr brauchen

Der klassische Ansatz wirkt vertraut:

[Klassisch]
Partner-Systeme --> Gateway --> Pulsar --> ERP

Der neue Ansatz ist klarer in der Verantwortung:

[Neu]
Partner-Systeme --> Pulsar --> ERP
                      |
                      `--> Policy Enforcement (Pulsar Functions)

Der Unterschied ist entscheidend: Im klassischen Modell wird vor allem der Zugriff auf das System kontrolliert. Im Pulsar-Modell wird zusätzlich kontrolliert, welcher fachliche Befehl überhaupt weiterlaufen darf.

Und genau deshalb reicht auch eine physische Trennung von Clustern nicht aus. Das ließe sich nur verhindern, wenn Kommunikation grundsätzlich unterbunden wird – oder wenn wieder ein klassisches Gateway dazwischensteht. Solange Systeme kommunizieren, wandert ohne fachliche Policy-Prüfung auch ein unzulässiger Command technisch sauber bis zum Zielsystem durch.

Der praktische Vorteil im Betrieb: Authentifizierung, Autorisierung, Verschlüsselung, Limits, Observability und skalierbare Topic-Trennung bleiben Teil derselben Plattform und greifen direkt am Datenstrom ineinander, statt über mehrere Einzellösungen koordiniert werden zu müssen.

Was dieser Ansatz nicht löst

Pulsar ersetzt nicht jede Sicherheitsarchitektur.

Nicht automatisch gelöst werden:

• feingranulare Benutzerrechte im ERP
• mehrstufige fachliche Freigabeprozesse
• tiefe Stammdaten- und Betrugsprüfungen

Physische Trennung von Clustern bleibt sinnvoll für Betrieb und Isolation, löst aber das Kernproblem nicht: Solange Kommunikation erlaubt ist, braucht jede Nachricht eine fachliche Policy-Prüfung.

Für einfache Regeln reicht oft eine schlanke Function. Für komplexe Entscheidungen delegiert sie kontrolliert an einen Policy Service oder eine Rules Engine.

Fazit

Für viele Legacy-Umgebungen ist das der pragmatische Zero-Trust-Nachrüstweg: nicht das Kernsystem umbauen, sondern ungeprüfte Nachrichten gar nicht mehr durchlassen.

Der entscheidende Hebel sind Pulsar Functions als Policy Enforcement Point. Sie sind leichtgewichtig, standardisiert, bestehen oft aus wenigen Zeilen klarer Logik und lassen sich deutlich einfacher betreiben als klassische Gateway-Projekte mit hohem jährlichem Pflegeaufwand.

So entsteht eine Sicherheitsgrenze direkt im Datenstrom: Identität, Autorisierung, fachliche Command-Prüfung, Quarantäne und Beobachtbarkeit greifen an einem Ort zusammen.

Das Ergebnis ist management-relevant und technisch belastbar: weniger Architekturballast, klarere Verantwortlichkeit und ein kontrollierter Nachrichtenfluss bis ins ERP.

Vielleicht ist das tatsächlich das Ende vieler klassischer Gateways.

Nicht weil Gateways falsch waren.

Sondern weil Policy Enforcement im Message Bus für dieses Problem der wirksamere und wirtschaftlichere Ansatz ist.