Azure Event Hubs vs. on-premises Kafka für Defense-Workloads

Die Wahl einer Event-Streaming-Plattform für ein Defense-Programm umfasst mehr als den Vergleich von Durchsatz-Benchmarks. Anforderungen an den Datenhaltungsort, Air-Gap-Mandate, Compliance-Frameworks und Klassifizierungsstufen schränken die Entscheidung auf eine Weise ein, die in kommerziellen Deployments keine Entsprechung hat. Ein Team, das einen managed Cloud-Dienst auswählt, ohne Impact-Level-Autorisierungen zu prüfen, oder selbst gehostetes Kafka einsetzt, ohne für die Betriebslast zu planen, wird auf Probleme stoßen, die sich nach dem Produktionsbetrieb nicht mehr beheben lassen.

Dieser Artikel legt einen Entscheidungsrahmen für die Wahl zwischen Azure Event Hubs und on-premises Apache Kafka für Defense-Workloads vor, behandelt die spezifischen Compliance- und Architekturimplikationen beider Optionen, beschreibt ein Hybridmodell, das beide Plattformen für verschiedene Klassifizierungsebenen einsetzt, und erläutert den Migrationspfad zwischen ihnen, wenn sich die Anforderungen ändern.

Warum die Streaming-Plattform-Entscheidung im Defense-Bereich wichtig ist

In einem kommerziellen Deployment ist die Wahl zwischen einem managed Streaming-Dienst und einem selbst gehosteten Cluster primär ein operativer Kompromiss: Managed Services kosten mehr pro Event, eliminieren aber den Cluster-Management-Overhead. Im Defense-Bereich ist die Entscheidung auch eine Compliance- und Sicherheitsarchitekturentscheidung mit Konsequenzen, die jeden einzelnen Sprint überdauern.

Datenhaltungsregeln für klassifizierte Informationen legen nicht nur fest, wo Daten gespeichert werden dürfen, sondern auch, welche Infrastrukturanbieter zur Verarbeitung autorisiert sind. Ein Programm, das unter IL5-Beschränkungen betrieben wird, kann nur Azure Government-Regionen nutzen, die eine IL5-Provisional Authorization erhalten haben – nicht jeder Azure-Dienst in Azure Government qualifiziert sich, und nicht jede Region trägt dieselben Autorisierungen. Ein Programm mit einer harten Air-Gap-Anforderung hat keinen Weg zu einem managed Cloud-Dienst, unabhängig von dessen FedRAMP-Postur, da selbst ein FedRAMP High-autorisierter Dienst eine Netzwerkverbindung für den Betrieb erfordert.

Die Streaming-Plattform ist auch der Ort, an dem Compliance-Verpflichtungen bezüglich Audit-Protokollierung, Verschlüsselungsschlüssel-Eigentümerschaft und Datenhaltung auf Infrastrukturebene durchgesetzt werden. Diese Architektur von Anfang an richtig zu gestalten spart Monate an Nacharbeiten, wenn der Authorizing Official den System Security Plan prüft.

Azure Event Hubs: managed Streaming für GovCloud-Workloads

Kafka-kompatible API und kein Cluster-Management

Azure Event Hubs Premium und Dedicated stellen einen Kafka-kompatiblen Protokollendpunkt bereit. Producer und Consumer, die gegen die Apache Kafka-Client-Bibliothek entwickelt wurden, verbinden sich mit einem Event Hubs-Namespace durch Änderung von zwei Konfigurationswerten: bootstrap.servers zeigt auf <namespace>.servicebus.usgovcloudapi.net:9093 in Azure Government, und sasl.mechanism wird auf PLAIN mit Connection-String-Credentials oder auf ein Azure Active Directory-Token mit dem OAuth-Bearer-Mechanismus gesetzt. Es sind keine Kafka-spezifischen Codeänderungen erforderlich. Die API ist kompatibel mit Kafka 1.0 und späteren Client-Bibliotheken.

Die operative Konsequenz ist, dass niemand in Ihrem Team Broker-Provisionierung, Controller-Quorum-Konfiguration, TLS-Zertifikatsrotation für den Cluster, SCRAM-Credential-Stores oder Kapazitätsskalierung verwalten muss. Throughput Units skalieren auf Abruf. Die Verfügbarkeit wird durch ein Service Level Agreement abgesichert. Geo-Redundanz ist eine Konfigurationseinstellung und kein Multi-Site-Deployment-Projekt.

FedRAMP High, IL4 und IL5-Autorisierung

Azure Event Hubs in Azure Government verfügt über FedRAMP High-Autorisierung. Der Dedicated-Tier, der Single-Tenant-Infrastruktur bereitstellt, unterstützt die Impact Levels IL4 und IL5, wie in der Azure Government Service Availability Matrix dokumentiert. Kundenverwaltete Schlüsselverschlüsselung ist über Azure Key Vault Managed HSM verfügbar, was die AES-256-Anforderung für ruhende Daten von IL5-Workloads erfüllt. In Event Hubs Dedicated in Azure Government verarbeitete und gespeicherte Daten verlassen die Government Cloud-Grenze nicht.

Für Programme, deren Klassifizierungsgrenze CONFIDENTIAL oder FOUO ist – oder SECRET-Workloads mit einem genehmigten Cloud Access Point – ist Event Hubs Dedicated in Azure Government oft der schnellste Weg zu einer konformen Streaming-Infrastruktur. Die Broker-Infrastruktur wird durch das FedRAMP-Autorisierungspaket von Microsoft abgedeckt, was den Bereich reduziert, den Ihr Team im System Security Plan dokumentieren und verteidigen muss.

API-Einschränkungen und ihre Bedeutung für Defense-Anwendungen

Event Hubs implementiert nicht die vollständige Kafka-API. Transaktionen und Exactly-once-Semantik über mehrere Topics hinweg werden auf Broker-Ebene nicht unterstützt. Die ACL-Management-APIs des AdminClient fehlen – die Zugangskontrolle wird auf der Azure RBAC-Ebene gehandhabt (Data Sender- und Data Receiver-Rollen auf Namespace- oder Entitätsebene) statt über Kafka-native ACLs. Consumer-Group-Offsets werden vom Dienst verwaltet und sind nicht direkt über die Kafka-Offset-Commit-API manipulierbar wie bei einem selbst gehosteten Cluster.

Für Defense-Anwendungen, die von Grund auf gegen Event Hubs entwickelt werden, sind diese Lücken handhabbar, indem man um sie herum entwirft. Für Anwendungen, die von selbst gehostetem Kafka migrieren und auf Transaktionen oder programmatisches ACL-Management angewiesen sind, erfordern sie Codeänderungen. Überprüfen Sie diese Abhängigkeitsliste, bevor Sie sich langfristig auf Event Hubs als Plattform festlegen.

On-premises Kafka: Air-Gap-Fähigkeit und volle Klassifizierungskontrolle

Der einzige gangbare Weg für harte Air-Gap-Anforderungen

Jedes Programm mit einem Mandat, ohne externe Netzwerkverbindung zu betreiben – sei es aus Gründen der physischen Sicherheit, operativen Sicherheit oder Akkreditierungsgründen – hat genau eine gangbare Streaming-Plattform: selbst gehostetes Kafka auf On-premises-Infrastruktur. Es gibt keinen managed Service-Äquivalent, der ohne Internetzugang funktioniert. Azure Event Hubs, unabhängig von seiner Compliance-Postur, erfordert Konnektivität zur Azure Government Control Plane, um Ressourcen zu provisionieren, SAS-Token zu rotieren und Management-API-Aufrufe zu empfangen.

On-premises Kafka im KRaft-Modus, bereitgestellt ohne Netzwerkschnittstellen, die über die Enklavengrenze geroutet werden, erfüllt die harte Air-Gap-Anforderung. Alle Abhängigkeiten – JVM, Kafka-Binaries, Container-Images, TLS-Zertifikate – werden lokal vor dem Trennen der Netzwerkverbindung vorgestagt. Der Cluster betreibt sich dann unbegrenzt ohne ausgehende Konnektivität. Eine detaillierte Beschreibung des Container-Image-Stagings und Air-Gap-Deployment-Muster finden Sie im Artikel über Air-Gapped-Deployment-Muster für Defense-Workloads.

KRaft-Modus und eigenständiger Clusterbetrieb

Kafka 3.3 führte den KRaft-Modus als Ersatz für das ZooKeeper-basierte Metadata-Management ein. Für Defense-Deployments ist KRaft der korrekte Standard für jeden neuen Cluster. Ein separates ZooKeeper-Ensemble fügt drei oder mehr zusätzliche Knoten, eine separate Fehlerdomäne, eine separate Konfigurationsoberfläche und einen zusätzlichen Prozess zum Patchen und Absichern hinzu. KRaft konsolidiert das Controller-Quorum-Management in den Kafka-Broker-Prozess selbst unter Verwendung eines Raft-basierten Konsensus-Logs.

In einem kleinen bis mittelgroßen klassifizierten Deployment – drei bis fünf Broker-Knoten – können die Controller- und Broker-Rollen auf denselben Knoten co-lokiert werden, wodurch die Gesamtknotenanzahl auf drei begrenzt bleibt. In größeren Deployments bietet ein dediziertes Drei-Knoten-Controller-Quorum getrennt von Broker-Knoten sauberere operative Grenzen. In jedem Fall hat der Cluster nach dem Bootstrappen keine externen Dienstabhängigkeiten im Laufzeitbetrieb.

Betriebslast und Personalimplikationen

Selbst gehostetes Kafka ist operativ nicht kostenlos. Ein produktionsreifer klassifizierter Kafka-Cluster erfordert kontinuierliche Aufmerksamkeit: OS-Hardening und Patch-Zyklen, TLS-Zertifikat-Lifecycle-Management entsprechend dem Erneuerungsplan Ihrer internen PKI, SCRAM-Credential-Rotation, Broker-Log-Retention-Tuning, Partition-Rebalancing bei wachsendem Topic-Durchsatz und Kapazitätsplanung für Broker-Disk. Rolling Upgrades über Kafka-Minor-Versionen erfordern sorgfältige Sequenzierung, um Protokollinkompatibilitäten zu vermeiden.

Programme, die diese Last unterschätzen, enden mit Clustern, die über die Zeit von ihrer genehmigten Konfigurationsbasisline abweichen – ein Problem, das schmerzhaft bei Re-Akkreditierungsreviews zutage tritt. Wenn das Programm keine dedizierte Plattform-Engineering-Funktion hat, planen Sie explizit dafür, wer Kafka-Operationen übernimmt, bevor der Cluster in Produktion geht.

Entscheidungsmatrix

Die folgende Tabelle ordnet die wichtigsten Deployment-Faktoren der geeigneten Plattformwahl zu.

Faktor	Azure Event Hubs	On-prem Kafka
Harter Air-Gap erforderlich	Nicht geeignet	Vollständig unterstützt
FedRAMP High / IL4/IL5	Erbt von Azure Gov	Betreiberverantwortung
Datenklassifizierungsgrenze	IL5 / FOUO (GovCloud)	SECRET / TS (Air-Gap)
Erforderliche Betriebskapazität	Minimal (managed Service)	Hoch (voller Clusterbetrieb)
Cluster-Management	Keines (vollständig managed)	Vollständig (TLS, KRaft, Patches)
Durchsatz-Elastizität	Elastisch (Throughput Units)	Manuelles Broker-Scaling
Vollständige Kafka-API-Oberfläche	Teilweise (keine Transaktionen)	Vollständig

Hybridarchitektur: gestuftes Streaming nach Klassifizierungsebene

Viele Defense-Programme operieren gleichzeitig über mehrere Klassifizierungsdomänen. Eine Battlespace-Management-Plattform könnte nicht klassifizierte OSINT-Feeds, FOUO-Logistikdaten und SECRET-Sensortelemetrie aus demselben operativen Lagebild aufnehmen. Eine einzige Streaming-Infrastruktur aufzubauen, die alle drei Ebenen erfüllt, ist unmöglich – die Air-Gap-Anforderung für SECRET-Daten ist mit dem managed Cloud-Ansatz, der gut für FOUO-Daten funktioniert, unvereinbar.

Die praktische Antwort ist eine gestufte Architektur: Azure Event Hubs in Azure Government übernimmt die UNCLASSIFIED- und FOUO-Ebene, wo die FedRAMP High-Autorisierung die Compliance-Anforderung abdeckt und managed Skalierung variable Aufnahmeraten bewältigt. On-premises Kafka hinter einer Air-Gapped-Enklave übernimmt die SECRET- und TS-Ebene, wo keine externe Netzwerkabhängigkeit tolerierbar ist. Die beiden Ebenen sind nicht direkt verbunden.

Cross-Domain-Lösungen an der Ebenengrenze

Wenn herabgestufte oder freigebbare Daten von der klassifizierten Ebene in die nicht klassifizierte Ebene fließen müssen – zum Beispiel ein bereinigter Positionsbericht, der aus einem SECRET-fusionierten Track abgeleitet wurde – erzwingt eine zertifizierte Cross-Domain-Lösung (CDS) die Grenze. Die CDS prüft ausgehende Daten gegen eine definierte Inhaltsrichtlinie, entfernt Klassifizierungsmarkierungen und sensible Felder und gibt das Ergebnis an den nicht klassifizierten Event Hubs-Namespace frei. Zwischen den beiden Kafka-Umgebungen besteht kein direkter Netzwerkpfad. Die CDS ist der einzige Kanal, und ihre Datenflüsse werden im System Security Plan dokumentiert und während der Akkreditierung validiert.

Diese Architektur ist komplexer zu betreiben als eine Single-Tier-Lösung, spiegelt aber die Realität von Multi-Domain-Defense-Programmen wider. Eine tiefere Behandlung von Cross-Domain-Designmustern finden Sie im Artikel über Cross-Domain-Lösungen für Defense.

Migrationspfad: von Event Hubs zu On-prem Kafka

Programme beginnen manchmal mit Event Hubs – weil der Workload zunächst für ein GovCloud-Deployment qualifiziert – und stellen später fest, dass Klassifizierungsanforderungen steigen, ein Air-Gap-Mandat hinzugefügt wird oder das Programm in eine restriktivere Netzwerkenklave migriert. Die Kafka-kompatible API bedeutet, dass diese Migration eine Konfigurationsänderung und kein Code-Rewrite ist.

Was sich bei der Migration ändert

Auf der Producer- und Consumer-Seite ändern sich drei Konfigurationswerte. Erstens verschiebt sich bootstrap.servers vom Event Hubs-Namespace-Endpunkt zur internen Adresse des On-premises-Kafka-Clusters. Zweitens ändern sich security.protocol und sasl.mechanism von SASL_SSL mit PLAIN auf SASL_SSL mit SCRAM-SHA-512. Drittens ändert sich die Truststore-Konfiguration von der öffentlichen Zertifikatskette des Azure-Dienstes zum internen CA-Zertifikat des On-premises-Clusters. Consumer-Group-IDs, Topic-Namen und die gesamte Anwendungslogik bleiben unverändert.

Auf der Infrastrukturseite muss der On-premises-Kafka-Cluster provisioniert, gehärtet und mit repräsentativer Last getestet werden, bevor Producer umgeschaltet werden. Die Topic-Konfiguration – Partition-Anzahl, Replikationsfaktoren, Retention-Richtlinien – muss vom Event Hubs-Namespace auf den On-prem-Cluster repliziert werden. Consumer-Group-Offsets von Event Hubs können nicht direkt übertragen werden; planen Sie ein Cutover-Fenster, in dem Consumer vom Beginn des Retention-Fensters oder von einem bekannten Checkpoint neu verarbeiten.

Pre-Migration-Checkliste

Bevor Sie den Cutover ausführen, bestätigen Sie, dass der On-premises-Cluster einen Security Review bestanden hat: TLS 1.3 über openssl s_client auf allen Listenern verifiziert, ACL-Audit mit kafka-acls.sh --list abgeschlossen, Broker-Ports über Netzwerkscan als von außerhalb der Enklave nicht erreichbar bestätigt, und alle Service-Account-SCRAM-Credentials im Secret-Management-System mit konfigurierter Rotation gespeichert. Dokumentieren Sie den Cutover-Prozess in einem Runbook und führen Sie einen Testlauf mit Nicht-Produktions-Workloads durch, bevor klassifizierte Datenströme migriert werden. Für die Zero-Trust-Netzwerkkontrollen, die die Kafka-Ebene umhüllen sollten, lesen Sie den Artikel über Zero-Trust-Architektur für Militärnetzwerke.

Corvus.Quantum: Dual-Mode-Streaming für klassifizierte Defense-Programme

Corvus.Quantum ist eine defense-gehärtete Event-Streaming-Plattform, die beide in diesem Artikel beschriebenen Deployment-Modi unterstützt. In GovCloud-Deployments integriert sie sich mit Azure Event Hubs Dedicated unter Verwendung von kundenverwalteten Schlüsseln und Azure Active Directory-Authentifizierung und bietet einen vorkonfigurierten Producer- und Consumer-Stack mit Post-Quantum-Verschlüsselung auf Anwendungsebene. In Air-Gapped-Deployments läuft sie auf einem eigenständigen KRaft-Mode-Kafka-Cluster mit TLS 1.3, SCRAM-SHA-512 und LUKS-verschlüsseltem Broker-Storage – alles vorgehärtet und für klassifizierte Umgebungen validiert.

Die Plattform wurde operativ für die Echtzeit-Defense-Datenverarbeitung eingesetzt und verarbeitet Tausende von Events pro Sekunde mit einer Ende-zu-Ende-Latenz unter 100 ms. Sie fügt CRYSTALS-Kyber-Schlüsseleinkapselung und AES-256-GCM-Payload-Verschlüsselung auf Anwendungsebene hinzu und schützt Nachrichteninhalte sowohl gegen aktuelle Abfangversuche als auch gegen zukünftige Quantum-fähige Entschlüsselung – eine Anforderung für Sensor- und ISR-Daten mit einer langen Sensitivitätslebensdauer.

Für Programme, die zwischen Event Hubs und On-prem Kafka navigieren, entfällt mit Corvus.Quantum die Notwendigkeit, für jeden Deployment-Modus separate gehärtete Konfigurationen zu erstellen und zu pflegen. Dieselbe Anwendung verbindet sich mit einem der beiden Backends über dieselbe Abstraktionsschicht, und der Migrationspfad zwischen den Modi erfordert keine Änderungen am Anwendungscode. Wenn sich die Klassifizierungsanforderungen Ihres Programms ändern, ändert sich die Streaming-Infrastruktur mit ihnen.

Verwandte Artikel

• Apache Kafka für Defense: sichere Echtzeit-Messaging-Architektur
• Air-Gapped-Deployment-Muster für Defense-Workloads
• Zero-Trust-Architektur für Militärnetzwerke