Apache Kafka für die Verteidigung: sichere Echtzeit-Messaging-Architektur

Verteidigungssysteme erzeugen Daten in einem Tempo und Volumen, das konventionelle Request-Response-Architekturen nicht bewältigen können. Ein einzelnes UAS liefert Dutzende von Telemetrieparametern pro Sekunde. Ein C2-Knoten auf Brigadeebene verarbeitet Hunderte von Positionsmeldungen und Statusereignissen pro Minute. Eine ISR-Fusionszelle nimmt gleichzeitig Feeds von Radar, Signalaufklärung und menschlicher Berichterstattung auf, die alle eine Korrelation unter einer Sekunde erfordern. Wenn diese Streams zuverlässig über eine widerstandsfähige, prüfbare und eingestufte Infrastruktur fließen müssen, hat sich Apache Kafka als bevorzugtes architektonisches Rückgrat etabliert.

Dieser Artikel behandelt, wie man Kafka speziell für Verteidigungsanwendungsfälle einsetzt: Partitionierungsstrategie für Multi-Klassifizierungsumgebungen, vollständige Verschlüsselungskonfiguration, Air-Gap-Deployment mit KRaft-Modus und den Kompromiss zwischen selbst gehosteten Clustern und verwalteten Alternativen wie Azure Event Hubs für GovCloud-Workloads.

Warum Event-Streaming zu Verteidigungsarchitekturen passt

Verteidigungsabläufe sind von Natur aus ereignisgesteuert. Sensor-Telemetrie kommt nicht in geordneten Batches an — es ist ein kontinuierlicher Strom von Messwerten, der im Moment des Eintreffens verarbeitet werden muss, um operativ nützlich zu sein. C2-Ereignisse — Truppenbewegungen, Auftragsänderungen, Statusaktualisierungen — sind diskrete Nachrichten, die mehrere konsumierende Systeme gleichzeitig benötigen: das Common Operating Picture, Logistik, Feuerkoordination und Nachbesprechungsberichte benötigen alle dasselbe zugrunde liegende Ereignis, ohne dass der Produzent wissen muss, wer zuhört.

Kafkas Publish-Subscribe-Modell passt sauber auf diese Anforderung. Ein Produzent schreibt eine Sensorablesung oder ein C2-Ereignis in ein Topic. Eine beliebige Anzahl von Consumer-Gruppen — jede stellt eine andere nachgelagerte Anwendung dar — wiederholt das Ereignis unabhängig voneinander in eigenem Tempo. Diese Entkopplung bedeutet, dass das Hinzufügen einer neuen Analytics-Workload keine Änderungen am produzierenden System erfordert, was in Verteidigungsumgebungen entscheidend ist, wo die Softwareänderungskontrolle langsam und die Genehmigungszyklen lang sind.

Über die Entkopplung hinaus bietet Kafkas dauerhaftes Log einen Append-only-Audit-Trail, der die forensischen Anforderungen erfüllt, die die meisten Verteidigungssysteme tragen. Jede Nachricht wird für einen konfigurierbaren Zeitraum auf der Festplatte gespeichert. Wenn ein Vorfall eintritt, können Operatoren die genaue Ereignissequenz, die dazu geführt hat, wiedergeben, ohne auf das Logging auf Anwendungsebene angewiesen zu sein.

Kern-Kafka-Architektur für eingestufte Umgebungen

Broker-Topologie

Ein produktionstauglicher eingestufter Kafka-Cluster erfordert mindestens drei Broker-Knoten, um einen Replikationsfaktor von drei und eine min.insync.replicas-Einstellung von zwei zu unterstützen. Diese Konfiguration toleriert den Ausfall eines einzelnen Brokers ohne Datenverlust oder Produzierfehler. Für hochverfügbare eingestufte Deployments bieten fünf Broker — verteilt auf mindestens drei physische Racks oder Verfügbarkeitszonen — stärkere Fehlertoleranz mit Spielraum für rollende Upgrades.

Seit Kafka 3.3 ersetzt der KRaft-Modus ZooKeeper für das Cluster-Metadaten-Management. Für Air-Gap-Verteidigungsdeployments ist dies nicht optional — es ist der korrekte Standard. Ein separates ZooKeeper-Ensemble fügt drei weitere Knoten, eine separate Fehlerdomäne und eine zusätzliche Angriffsfläche hinzu. KRaft konsolidiert das Metadaten-Management in den Kafka-Brokern selbst unter Verwendung eines Raft-basierten Quorums von Controller-Knoten, typischerweise zusammen mit Brokern in kleinen Clustern oder getrennt in großen.

Topic-Partitionierung nach Geheimhaltungsstufe

Die wichtigste Architekturentscheidung in einem Multi-Klassifizierungs-Kafka-Deployment ist, wie die Isolation zwischen Daten auf verschiedenen Sensibilitätsstufen durchgesetzt wird. Es gibt zwei Ansätze.

Der erste Ansatz verwendet einen einzigen Cluster mit ACL-Isolation auf Topic-Ebene. Topics werden nach Klassifizierung benannt: ts.sensor.uav-telemetry für streng geheime Telemetrie, s.c2.position-reports für geheime C2-Daten, c.logistics.supply-events für vertrauliche Logistik. Jedem Dienstkonto werden Produzieren- und Konsumieren-Rechte nur für Topics gewährt, die seiner Freigabestufe entsprechen. Dieser Ansatz reduziert die Betriebskomplexität, erfordert jedoch hohes Vertrauen in Kafkas ACL-Durchsetzung und sorgfältige Netzwerksegmentierung, um sicherzustellen, dass Broker-Prozesse selbst kein seitlicher Bewegungspfad sind.

Der zweite Ansatz — bevorzugt bei der Verarbeitung von Daten oberhalb SECRET auf derselben physischen Infrastruktur — verwendet separate Broker-Cluster pro Klassifizierungsdomäne, verbunden über eine Cross-Domain-Lösung (CDS) für die seltenen Fälle, in denen herabgestufte Daten eine Grenze überqueren müssen. Dies eliminiert das Shared-Broker-Risiko vollständig auf Kosten erhöhten Betriebsaufwands. Für eine tiefere Behandlung von Cross-Domain-Architekturen, siehe den Artikel über Cross-Domain-Lösungen für die Verteidigung.

Aufbewahrung und Partitionsanzahl

Legen Sie die Partitionsanzahl basierend auf dem erwarteten Durchsatz fest, nicht auf Bequemlichkeit. Ein Topic, das 10.000 Nachrichten pro Sekunde von einem Sensorarray verarbeitet, sollte genug Partitionen haben, damit jeder Consumer in einer Gruppe seine zugewiesenen Partitionen ohne Verzögerung verarbeiten kann. Als Faustregel gilt: Die Partitionsanzahl sollte mindestens der Anzahl der Consumer in der konsumierenden Gruppe entsprechen, idealerweise das Zwei- bis Dreifache davon, um Consumer-Gruppen-Rebalancing ohne Einführung von Hotspots zu ermöglichen.

Entscheidungen zur Aufbewahrungsrichtlinie müssen dokumentiert und vertretbar sein. Sensor-Telemetrie, die nahezu in Echtzeit analysiert wird, benötigt typischerweise nur 24–72 Stunden Aufbewahrung, bevor sie in Cold Storage ausgelagert oder verworfen werden kann. C2-Ereignisprotokolle, die für die Nachbesprechung erforderlich sind, sollten 30–90 Tage im Hot-Tier aufbewahrt und anschließend in ein verschlüsseltes, unveränderliches Archiv exportiert werden. Verlassen Sie sich nicht allein auf Kafka als langfristigen Audit-Speicher — es ist ein Event-Bus, keine Archivdatenbank.

Verschlüsselung während der Übertragung: TLS 1.3 und SASL SCRAM

Eingestufte Umgebungen verlangen Verschlüsselung auf jedem Datenpfad. Für Kafka bedeutet das zwei unterschiedliche Kontrollen: Transportverschlüsselung und Client-Authentifizierung.

TLS 1.3-Konfiguration

Konfigurieren Sie jeden Kafka-Listener — einschließlich Inter-Broker-Kommunikation — mit TLS 1.3. In server.properties:

listeners=SASL_SSL://0.0.0.0:9093
advertised.listeners=SASL_SSL://broker-1.internal:9093
ssl.protocol=TLSv1.3
ssl.enabled.protocols=TLSv1.3
ssl.keystore.location=/etc/kafka/ssl/broker.keystore.jks
ssl.keystore.password=${KEYSTORE_PASSWORD}
ssl.truststore.location=/etc/kafka/ssl/ca.truststore.jks
ssl.truststore.password=${TRUSTSTORE_PASSWORD}
ssl.client.auth=required

Die Einstellung ssl.client.auth=required erzwingt gegenseitiges TLS (mTLS): Jeder verbindende Client muss ein von Ihrer internen Zertifizierungsstelle signiertes Zertifikat vorlegen. Dies stellt sicher, dass nur bekannte, bereitgestellte Systeme eine Verbindung zum Cluster herstellen können — eine Anforderung in jeder eingestuften Enklave. Verwenden Sie in eingestuften Umgebungen nicht requested oder none.

Zertifikate müssen von Ihrer internen PKI stammen. Verwenden Sie in einer Air-Gap-Umgebung keine von öffentlichen CAs signierten Zertifikate — und erlauben Sie keine öffentlichen CA-Roots im Broker-Truststore, da dies einem kompromittierten externen Zertifikat ermöglichen könnte, sich als legitimer Client auszugeben.

SASL SCRAM-SHA-512

Zusätzlich zu mTLS verwenden Sie SASL SCRAM-SHA-512 für die Authentifizierung auf Benutzerebene. Dies bindet eine benannte Identität — wie ein Dienstkonto für eine bestimmte Anwendung — an die TLS-Verbindung und ermöglicht eine fein abgestufte ACL-Durchsetzung basierend auf dem Principal-Namen statt allein auf dem Zertifikats-Subject.

sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
security.inter.broker.protocol=SASL_SSL

Stellen Sie Anmeldedaten mit kafka-configs.sh bereit und speichern Sie sie in Ihrem Secrets-Management-System — HashiCorp Vault oder einem gleichwertigen Air-Gap-Secret-Store — statt in Konfigurationsdateien. Rotieren Sie Anmeldedaten nach einem Zeitplan, der mit der Schlüsselverwaltungsrichtlinie Ihrer Akkreditierung übereinstimmt, typischerweise alle 90 Tage oder bei Personalwechsel.

Verschlüsselung im Ruhezustand: AES-256 und Speicherschicht-Kontrollen

Kafka verschlüsselt in seine Log-Segmente geschriebene Daten nicht nativ. Die Verschlüsselung im Ruhezustand liegt in der Verantwortung der Speicherschicht. Für Bare-Metal- oder Virtual-Machine-Deployments verwenden Sie LUKS (Linux Unified Key Setup) mit AES-256 im XTS-Modus auf den Blockgeräten, die Kafkas log.dirs hosten. Für Kubernetes-basierte Deployments stellen Sie StorageClass-Ressourcen bereit, die durch verschlüsselte Volumes unterstützt werden — auf Azure Government verwenden Sie serverseitige Verschlüsselung mit kundenverwalteten Schlüsseln (SSE-CMK) auf Azure Disk. On-Premises-Entsprechungen umfassen NetApp mit NSE-Laufwerken oder rein software-basiertes LUKS auf Standard-NVMe.

Für Workloads, bei denen auch der Speicherbetreiber keine Nachrichteninhalte lesen darf — besonders relevant für Programme mit besonderem Zugang — implementieren Sie Verschlüsselung auf Anwendungsebene: Der Produzent verschlüsselt die Nachrichten-Payload vor dem Schreiben, und nur autorisierte Consumer besitzen den Entschlüsselungsschlüssel. Dieser Ansatz ist unabhängig von Kafkas Konfiguration und bietet eine End-to-End-Vertraulichkeit, die auch dann bestehen bleibt, wenn der Broker-Speicher kompromittiert wird. Der Kompromiss ist, dass Broker-seitige Filterung und Komprimierung auf verschlüsselten Payloads unmöglich werden, da der Broker den Inhalt nicht inspizieren kann.

Air-Gap-Kafka-Deployment mit KRaft-Modus

Ein Air-Gap-Kafka-Deployment hat keine Internetverbindung, keine externe DNS-Auflösung und keinen Zugriff auf öffentliche Container-Registries oder Paket-Mirrors. Jede Komponente muss lokal verfügbar sein, bevor der Cluster starten kann. Dieser Abschnitt behandelt die spezifischen Fallstricke, die Ingenieure beim Deployment in dieser Umgebung ertappen.

KRaft-Modus und Betrieb ohne ZooKeeper

Verwenden Sie Kafka 3.6 oder später mit aktiviertem KRaft-Modus. Der Cluster erfordert ein Controller-Quorum — typischerweise drei Controller-Knoten, die in Deployments mit drei bis fünf Knoten zusammen mit Brokern platziert sein können. Jedem Knoten wird eine node.id und ein process.roles-Wert von controller, broker oder beides zugewiesen.

Booten Sie den Cluster mit kafka-storage.sh format, um eine Cluster-UUID zu generieren und das initiale Metadaten-Log zu schreiben. Dieser Schritt muss auf jedem Knoten mit derselben UUID ausgeführt werden, bevor irgendein Broker-Prozess gestartet wird. In einer Air-Gap-Umgebung generieren Sie die UUID auf einem Knoten, kopieren Sie sie auf die anderen und führen Sie dann format auf jedem aus.

CLUSTER_ID=$(kafka-storage.sh random-uuid)
kafka-storage.sh format -t $CLUSTER_ID -c /etc/kafka/server.properties

Internes DNS und Zertifikatsverwaltung

Konfigurieren Sie advertised.listeners so, dass vollständig qualifizierte Hostnamen verwendet werden, die innerhalb der Enklave auflösbar sind — entweder über einen internen DNS-Server oder über /etc/hosts auf jedem Host, der eine Verbindung zum Cluster herstellt. Die direkte Verwendung von IP-Adressen in advertised.listeners funktioniert, erschwert aber die Zertifikatsverwaltung, da Zertifikats-SANs jede IP auflisten müssen.

Betreiben Sie eine Offline-Root-CA mit step-ca oder CFSSL, die beide zur Laufzeit keine externen Abhängigkeiten haben. Generieren Sie Broker-Zertifikate mit SANs, die den Hostnamen des Brokers abdecken. Verteilen Sie das CA-Root-Zertifikat an den Truststore jedes Clients. Legen Sie Zertifikatsgültigkeitszeiträume fest, die mit Ihrem Reakkreditierungsplan übereinstimmen, und führen Sie ein Zertifikatsinventar, damit Erneuerungen keine unerwarteten Ausfälle verursachen.

Container-Image- und Artefaktverwaltung

Pullen Sie alle erforderlichen Images — Kafka, Ihren Monitoring-Stack und alle Kafka-Connect-Plugins — auf einem mit dem Internet verbundenen Rechner, exportieren Sie sie mit docker save, übertragen Sie sie in die Air-Gap-Umgebung über eine genehmigte Datendiode oder einen tragbaren Medienprozess und laden Sie sie mit docker load in eine lokale Registry. Pinnen Sie Image-Tags auf spezifische Digests in Ihren Deployment-Manifesten, um unerwartete Änderungen zu verhindern, falls die lokale Registry aktualisiert wird. Für mehr Details zu Air-Gap-Kubernetes-Deployments in Verteidigungskontexten, siehe den Artikel über Air-Gap-Deployment-Muster für die Verteidigung.

Azure Event Hubs als Kafka-kompatible Alternative

Nicht jede Verteidigungsworkload erfordert einen vollständig getrennten, selbstverwalteten Cluster. Für Programme, die innerhalb von GovCloud-Grenzen operieren — Azure Government, IL4 oder IL5 — bieten Azure Event Hubs Premium und Dedicated Tiers einen Kafka-kompatiblen Endpunkt, der Standard-Kafka-Produzenten und -Konsumenten ohne Codeänderungen akzeptiert. Die Protokolloberfläche ist mit Kafka 1.0 und späteren Client-Bibliotheken kompatibel.

Event Hubs in Azure Government erfüllt die FedRAMP High-Autorisierung und unterstützt im Dedicated Tier kundenverwaltete Schlüssel über Azure Key Vault Managed HSM, was die AES-256-Verschlüsselungskontrolle im Ruhezustand bietet, die eingestufte Workloads erfordern. Der operative Vorteil ist erheblich: keine Broker-Bereitstellung, keine Zertifikatsrotation für den Cluster selbst, eingebaute Georedundanz und SLA-gestützte Verfügbarkeit.

Der Kompromiss ist klar: Event Hubs unterstützt nicht die vollständige Kafka-API-Oberfläche (keine Transaktionen, keine exakt-einmalige Semantik über Topics hinweg auf Broker-Ebene und kein benutzerdefiniertes ACL-Modell über namespace-weites RBAC hinaus). Und für Workloads, die vollständig luftisoliert sein müssen — ohne Konnektivität zu einem externen Netzwerk — ist Event Hubs keine Option. Für diese Programme bleiben selbst gehostete KRaft-Cluster der einzig gangbare Weg.

Zero-Trust-Integration für Kafka-Consumer

Kafkas ACL-Modell ist eine notwendige, aber nicht ausreichende Sicherheitskontrolle in einer Zero-Trust-Umgebung. Jeder Consumer-Dienst sollte sich mit einem kurzlebigen Credential authentifizieren, das von Ihrem Identity Provider beim Pod- oder Prozessstart ausgestellt wird, anstatt mit einem langlebigen statischen Passwort. Vaults Kafka-Secrets-Engine kann kurzlebige SCRAM-Credentials dynamisch ausstellen, mit automatischer Sperrung bei Ablauf des Leases. Kombiniert mit mTLS-Client-Zertifikaten, die planmäßig rotiert werden, stellt dies sicher, dass ein kompromittiertes Dienstkonto-Credential ein begrenztes operatives Fenster für einen Angreifer hat.

Wenden Sie Netzwerkrichtlinien auf der Kubernetes- oder Firewall-Ebene an, um sicherzustellen, dass nur Pods mit den korrekten Labels Kafka-Broker-Ports erreichen können. Kafkas native ACLs sollten die zweite Verteidigungslinie sein, nicht die erste. Für eine vollständige Behandlung der Zero-Trust-Architektur angewendet auf Verteidigungsnetzwerke, siehe den Artikel über Zero-Trust-Architektur für Militärnetzwerke.

Corvus.Quantum: Kafka-basiertes Streaming mit Post-Quanten-Verschlüsselung

Corvus.Quantum ist eine kampferprobte Event-Streaming-Plattform, die auf Kafka aufgebaut ist und operativ in der Ukraine für die Echtzeit-Verteidigungsdatenverarbeitung eingesetzt wird. Sie erweitert Standard-Kafka mit Post-Quanten-Verschlüsselung auf Anwendungsebene — unter Verwendung von CRYSTALS-Kyber für die Schlüsselkapselung und AES-256-GCM für die Payload-Verschlüsselung — sodass Nachrichten sowohl gegen aktuelle gegnerische Abfangaktionen als auch gegen zukünftige quantenfähige Entschlüsselungsangriffe geschützt sind. Dies adressiert die "Jetzt ernten, später entschlüsseln"-Bedrohung, die besonders relevant für Signale- und ISR-Daten mit langer Sensibilitätsdauer ist.

Über die Verschlüsselung hinaus bietet Corvus.Quantum eine vorgehärtete Broker-Konfiguration für eingestufte Deployments: KRaft-Modus-Cluster-Templates, TLS 1.3-Zertifikatsautomatisierung mit einer eingebetteten step-ca-Instanz, SCRAM-Credential-Rotation integriert mit HashiCorp Vault und klassifizierungsbewusste Topic-ACL-Templates. Die Plattform wurde in Umgebungen ohne Internetkonnektivität validiert und verarbeitet Tausende von Sensor-Ereignissen pro Sekunde mit einer End-to-End-Latenz von unter 100 ms.

Für Beschaffungsteams, die Kafka für Verteidigungsprogramme evaluieren, reduziert Corvus.Quantum den Engineering-Aufwand für die Absicherung eines Kafka-Clusters von Monaten auf Tage und bietet gleichzeitig eine prüfbare Konfigurationsgrundlage, die den CNSA 2.0-Anforderungen entspricht und die Integration mit bestehenden Cross-Domain-Lösungen unterstützt.

Verwandte Artikel

• Zero-Trust-Architektur für Militärnetzwerke
• Air-Gap-Deployment-Muster für Verteidigungs-Workloads
• Post-Quanten-Kryptografie und CNSA 2.0-Konformität für die Verteidigung