Apache Kafka voor defensie: beveiligde real-time berichtenarchitectuur

Defensiesystemen genereren gegevens in een tempo en volume dat conventionele request-response-architecturen niet kunnen verwerken. Een enkele UAS levert tientallen telemetrieparameters per seconde. Een C2-knooppunt op brigadeniveau verwerkt honderden positierapporten en statusgebeurtenissen per minuut. Een ISR-fusiecel neemt tegelijkertijd feeds in van radar, signaalintelligentie en menselijke rapportage, waarbij alle feeds sub-seconde correlatie vereisen. Wanneer deze stromen betrouwbaar moeten stromen over een veerkrachtige, auditeerbare en geclassificeerde infrastructuur, is Apache Kafka de architecturale ruggengraat bij uitstek geworden.

Dit artikel behandelt hoe Kafka specifiek voor defensietoepassingen kan worden ingezet: partitioneringsstrategie voor omgevingen met meerdere classificaties, volledige versleutelingsconfiguratie, air-gap-implementatie met KRaft-modus en de afweging tussen zelf-gehoste clusters en beheerde alternatieven zoals Azure Event Hubs voor GovCloud-workloads.

Waarom event streaming past bij defensiearchitecturen

Defensieworkflows zijn van nature event-driven. Sensortelemetrie komt niet in nette batches aan — het is een continue stroom van metingen die op het moment van aankomst moet worden verwerkt om operationeel nuttig te zijn. C2-gebeurtenissen — eenheidsbewegingen, taakwijzigingen, statusupdates — zijn discrete berichten die meerdere consumerende systemen tegelijkertijd nodig hebben: het gemeenschappelijk operationeel beeld, logistiek, vuurcoördinatie en evaluatie na actie hebben allemaal dezelfde onderliggende gebeurtenis nodig zonder dat de producer weet wie er meeluistert.

Het publish-subscribe-model van Kafka sluit goed aan op deze vereiste. Een producer schrijft een sensorlezing of een C2-gebeurtenis naar een topic. Elk aantal consumergroepen — elk vertegenwoordigt een andere downstream-applicatie — herhaalt de gebeurtenis onafhankelijk in zijn eigen tempo. Deze ontkoppeling betekent dat het toevoegen van een nieuwe analyticswerkload geen wijzigingen vereist in het producerende systeem, wat cruciaal is in defensieomgevingen waar softwarewijzigingsbeheer traag verloopt en goedkeuringscycli lang zijn.

Buiten ontkoppeling biedt Kafka's duurzaam logboek een append-only audittrail die voldoet aan de forensische vereisten die de meeste defensiesystemen dragen. Elk bericht wordt gedurende een configureerbare periode op schijf bewaard. Als er een incident optreedt, kunnen operators de exacte volgorde van gebeurtenissen voorafgaand aan het incident herspelen zonder afhankelijk te zijn van logging op applicatieniveau.

Kern-Kafka-architectuur voor geclassificeerde omgevingen

Brokertopologie

Een productieklaar geclassificeerd Kafka-cluster vereist minimaal drie brokerknooppunten om een replicatiefactor van drie en een min.insync.replicas-instelling van twee te ondersteunen. Deze configuratie tolereert het verlies van één enkele broker zonder gegevensverlies of producerfouten. Voor geclassificeerde implementaties met hoge beschikbaarheid bieden vijf brokers — verspreid over minimaal drie fysieke rekken of beschikbaarheidszones — sterkere fouttolerantie met ruimte voor rollende upgrades.

Sinds Kafka 3.3 vervangt KRaft-modus ZooKeeper voor clustermetadatabeheer. Voor air-gapped defensie-implementaties is dit niet optioneel — het is de juiste standaard. Een apart ZooKeeper-ensemble voegt drie extra knooppunten, een apart storingsdomein en een extra aanvalsoppervlak toe. KRaft consolideert metadatabeheer in de Kafka-brokers zelf via een Raft-gebaseerd quorum van controllerknooppunten, doorgaans gedeeld met brokers in kleine clusters of gescheiden in grote clusters.

Topicpartitionering per classificatieniveau

De belangrijkste architecturale beslissing in een Kafka-implementatie met meerdere classificaties is hoe isolatie tussen gegevens op verschillende gevoeligheidsniveaus moet worden afgedwongen. Er zijn twee benaderingen.

De eerste benadering gebruikt één enkel cluster met ACL-isolatie op topicniveau. Topics worden genaamd per classificatie: ts.sensor.uav-telemetry voor streng geheime telemetrie, s.c2.position-reports voor geheime C2-gegevens, c.logistics.supply-events voor vertrouwelijke logistiek. Elk serviceaccount krijgt produce- en consume-rechten alleen voor topics die overeenkomen met zijn vrijgaveniveau. Deze benadering vermindert operationele complexiteit, maar vereist groot vertrouwen in de ACL-handhaving van Kafka en zorgvuldige netwerksegmentatie om ervoor te zorgen dat brokerprocessen zelf geen zijdelingse bewegingsroute vormen.

De tweede benadering — de voorkeur wanneer gegevens boven GEHEIM op dezelfde fysieke infrastructuur worden verwerkt — gebruikt aparte brokerclusters per classificatiedomein, verbonden via een cross-domain solution (CDS) voor de zeldzame gevallen waarbij gedegradeerde gegevens een grens moeten overschrijden. Dit elimineert het risico van gedeelde brokers volledig, ten koste van verhoogde operationele overhead. Voor een uitgebreidere behandeling van cross-domein-architecturen, zie het artikel over cross-domain solutions voor defensie.

Bewaring en partitieaantal

Stel partitieaantallen in op basis van verwachte doorvoer, niet op basis van gemak. Een topic dat 10.000 berichten per seconde verwerkt van een sensorarray moet genoeg partities hebben zodat elke consumer in een groep zijn toegewezen partities zonder vertraging kan verwerken. Als vuistregel geldt: het partitieaantal moet minimaal het aantal consumers in de consumerende groep zijn, en idealiter twee tot drie keer dat aantal om herbalancering van consumergroepen mogelijk te maken zonder hotspots te introduceren.

Beslissingen over bewaarbeleid moeten worden gedocumenteerd en verdedigbaar zijn. Sensortelemetrie die in near-real-time wordt geanalyseerd, heeft doorgaans slechts 24–72 uur bewaring nodig voordat deze kan worden overgebracht naar koude opslag of verwijderd. C2-gebeurtenislogboeken die vereist zijn voor evaluatie na actie moeten gedurende 30–90 dagen in de hete laag worden bewaard, waarna ze moeten worden geëxporteerd naar een versleuteld, onveranderlijk archief. Vertrouw niet alleen op Kafka als langetermijnauditopslag — het is een eventbus, geen archiefdatabase.

Versleuteling tijdens transport: TLS 1.3 en SASL SCRAM

Geclassificeerde omgevingen vereisen versleuteling op elk gegevenspad. Voor Kafka betekent dit twee afzonderlijke beveiligingscontroles: transportversleuteling en clientauthenticatie.

TLS 1.3-configuratie

Configureer elke Kafka-listener — inclusief inter-brokercommunicatie — met 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

De instelling ssl.client.auth=required dwingt wederzijdse TLS (mTLS) af: elke verbindende client moet een certificaat presenteren dat is ondertekend door uw interne certificeringsinstantie. Dit zorgt ervoor dat alleen bekende, ingerichte systemen verbinding kunnen maken met het cluster — een vereiste in elke geclassificeerde enclave. Gebruik requested of none niet in geclassificeerde omgevingen.

Certificaten moeten afkomstig zijn van uw interne PKI. Gebruik geen certificaten ondertekend door openbare CA's in een air-gapped omgeving — en sta geen openbare CA-roots toe in de broker-truststore, omdat dit een gecompromitteerd extern certificaat in staat zou stellen zich voor te doen als een legitieme client.

SASL SCRAM-SHA-512

Naast mTLS gebruikt u SASL SCRAM-SHA-512 voor authenticatie op gebruikersniveau. Dit koppelt een benoemde identiteit — zoals een serviceaccount voor een specifieke applicatie — aan de TLS-verbinding, waardoor fijnkorrelige ACL-handhaving mogelijk is op basis van principenaam in plaats van alleen het certificaatonderwerp.

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

Richt referenties in met kafka-configs.sh en sla ze op in uw geheimbeheersysteem — HashiCorp Vault, of een equivalent air-gapped geheimopslag — in plaats van in configuratiebestanden. Roteer referenties op een schema dat is afgestemd op het sleutelbeheerbeleid van uw accreditatie, doorgaans elke 90 dagen of bij personeelswijzigingen.

Versleuteling in rust: AES-256 en opslaglaagcontroles

Kafka versleutelt gegevens die naar zijn logsegmenten worden geschreven niet standaard. Versleuteling in rust is de verantwoordelijkheid van de opslaglaag. Voor bare-metal- of virtuele machine-implementaties gebruikt u LUKS (Linux Unified Key Setup) met AES-256 in XTS-modus op de blokapparaten die Kafka's log.dirs hosten. Voor Kubernetes-gebaseerde implementaties richt u StorageClass-resources in die zijn ondersteund door versleutelde volumes — op Azure Government gebruikt u server-side versleuteling met door de klant beheerde sleutels (SSE-CMK) op Azure Disk. On-premises equivalenten zijn onder meer NetApp met NSE-schijven of pure software-LUKS op standaard NVMe.

Voor workloads waarbij zelfs de opslagbeheerder de berichtinhoud niet moet kunnen lezen — met name relevant voor speciale toegangsprogramma's — implementeert u versleuteling op applicatielaag: de producer versleutelt de berichtpayload vóór het schrijven, en alleen geautoriseerde consumers beschikken over de ontsleutelingssleutel. Deze benadering is onafhankelijk van de Kafka-configuratie en biedt end-to-end vertrouwelijkheid die ook behouden blijft als de brokeropslag is gecompromitteerd. De afweging is dat filtering en compactie aan brokerzijde onmogelijk worden voor versleutelde payloads, omdat de broker de inhoud niet kan inspecteren.

Air-gapped Kafka-implementatie met KRaft-modus

Een air-gapped Kafka-implementatie heeft geen internetverbinding, geen externe DNS-resolutie en geen toegang tot openbare containerregisters of pakketspiegels. Elk onderdeel moet lokaal beschikbaar zijn voordat het cluster kan worden gestart. Dit gedeelte behandelt de specifieke valkuilen die engineers tegenkomen bij implementatie in deze omgeving.

KRaft-modus en werking zonder ZooKeeper

Gebruik Kafka 3.6 of later met ingeschakelde KRaft-modus. Het cluster vereist een controllerquorum — doorgaans drie controllerknooppunten, die mogelijk zijn samengevoegd met brokers in implementaties van drie tot vijf knooppunten. Elk knooppunt krijgt een node.id en een process.roles-waarde van controller, broker of beide.

Bootstrap het cluster met kafka-storage.sh format om een cluster-UUID te genereren en het initiële metadatalogboek te schrijven. Deze stap moet op elk knooppunt worden uitgevoerd met dezelfde UUID voordat enig brokerproces wordt gestart. Genereer in een air-gapped omgeving de UUID op één knooppunt, kopieer deze naar de andere en voer vervolgens format uit op elk knooppunt.

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

Interne DNS en certificaatbeheer

Configureer advertised.listeners om volledig gekwalificeerde hostnamen te gebruiken die oplosbaar zijn binnen de enclave — via een interne DNS-server of via /etc/hosts op elke host die verbinding maakt met het cluster. Het direct gebruiken van IP-adressen in advertised.listeners werkt, maar maakt certificaatbeheer ingewikkelder, omdat certificaat-SAN's elk IP-adres moeten vermelden.

Voer een offline root-CA uit met step-ca of CFSSL, die beide geen externe afhankelijkheden hebben tijdens runtime. Genereer brokercertificaten met SAN's die de hostnaam van de broker omvatten. Distribueer het CA-rootcertificaat naar de truststore van elke client. Stel certificaatgeldigheidstermijnen in die zijn afgestemd op uw heraccreditatieschema, en onderhoud een certificaatinventaris zodat verlengingen geen onverwachte storingen veroorzaken.

Containerimage- en artefactbeheer

Haal alle vereiste images op — Kafka, uw monitoringstack en eventuele Kafka Connect-plugins — op een met internet verbonden machine, exporteer ze met docker save, draag ze over naar de air-gapped omgeving via een goedgekeurde datadiode of een draagbaar mediaproces en laad ze in een lokaal register met docker load. Pin image-tags aan specifieke digests in uw implementatiemanifesten om onverwachte wijzigingen te voorkomen als het lokale register wordt bijgewerkt. Voor meer details over air-gapped Kubernetes-implementaties in defensiecontexten, zie het artikel over air-gapped implementatiepatronen voor defensie.

Azure Event Hubs als Kafka-compatibel alternatief

Niet elke defensieworkload vereist een volledig losgekoppeld, zelf-beheerd cluster. Voor programma's die opereren binnen GovCloud-grenzen — Azure Government, IL4 of IL5 — bieden Azure Event Hubs Premium- en Dedicated-lagen een Kafka-compatibel eindpunt dat standaard Kafka-producers en -consumers accepteert zonder codewijzigingen. Het protocoloppervlak is compatibel met Kafka 1.0 en latere clientbibliotheken.

Event Hubs in Azure Government voldoet aan FedRAMP High-autorisatie en ondersteunt voor de Dedicated-laag door de klant beheerde sleutels via Azure Key Vault Managed HSM, waarmee de AES-256-versleutelingscontrole in rust wordt geboden die geclassificeerde workloads vereisen. Het operationele voordeel is aanzienlijk: geen brokerinrichting, geen certificaatrotatie voor het cluster zelf, ingebouwde geo-redundantie en SLA-gegarandeerde beschikbaarheid.

De afweging is duidelijk: Event Hubs ondersteunt niet het volledige Kafka API-oppervlak (geen transacties, geen exactly-once-semantiek over topics op brokerniveau en geen aangepast ACL-model buiten RBAC op naamruimteniveau). En voor workloads die volledig air-gapped moeten zijn — zonder verbinding met enig extern netwerk — is Event Hubs geen optie. Voor die programma's blijven zelf-gehoste KRaft-clusters het enige levensvatbare pad.

Zero-trust-integratie voor Kafka-consumers

Kafka's ACL-model is een noodzakelijke maar niet voldoende beveiligingscontrole in een zero-trust-omgeving. Elke consumerservice moet authenticeren met behulp van een kortlevende referentie die is uitgegeven door uw identiteitsprovider bij pod- of processtart, in plaats van een langlevend statisch wachtwoord. Vault's Kafka-geheimensengine kan dynamisch kortlevende SCRAM-referenties uitgeven, met automatische intrekking wanneer de lease verloopt. Gecombineerd met mTLS-clientcertificaten die op een schema worden geroteerd, zorgt dit ervoor dat een gecompromitteerde serviceaccountreferentie een beperkt operationeel venster heeft voor een aanvaller.

Pas netwerkbeleid toe op de Kubernetes- of firewalllaag om ervoor te zorgen dat alleen pods met de juiste labels Kafka-brokerpoorten kunnen bereiken. Kafka's native ACL's moeten de tweede verdedigingslinie zijn, niet de eerste. Voor een volledige behandeling van zero-trust-architectuur toegepast op defensienetwerken, zie het artikel over zero-trust-architectuur voor militaire netwerken.

Corvus.Quantum: op Kafka gebaseerde streaming met post-kwantumversleuteling

Corvus.Quantum is een in de praktijk beproefd event-streamingplatform gebouwd op Kafka, operationeel ingezet in Oekraïne voor real-time verwerking van defensiegegevens. Het breidt standaard Kafka uit met post-kwantumversleuteling op de applicatielaag — met CRYSTALS-Kyber voor sleutelinkapseling en AES-256-GCM voor payloadversleuteling — zodat berichten zijn beschermd tegen zowel huidige onderschepping door tegenstanders als toekomstige kwantumdecodeeringsaanvallen. Dit pakt de dreiging van "nu oogsten, later ontsleutelen" aan, die bijzonder relevant is voor signalen- en ISR-gegevens met een lange gevoeligheidsduur.

Buiten versleuteling biedt Corvus.Quantum een vooraf geharde brokerconfiguratie voor geclassificeerde implementaties: KRaft-modus clustersjablonen, TLS 1.3-certificaatautomatisering met een ingebedde step-ca-instantie, SCRAM-referentierotatie geïntegreerd met HashiCorp Vault en classificatiebewuste topic-ACL-sjablonen. Het platform is gevalideerd in omgevingen zonder internetverbinding en verwerkt duizenden sensorgebeurtenissen per seconde met een end-to-end latentie van minder dan 100 ms.

Voor inkoopteams die Kafka evalueren voor defensieprogramma's reduceert Corvus.Quantum de engineeringinspanning voor het beveiligen van een Kafka-cluster van maanden naar dagen, terwijl het een auditeerbare configuratiebasislijn biedt die is afgestemd op CNSA 2.0-vereisten en integratie met bestaande cross-domain solutions ondersteunt.

Gerelateerde artikelen

• Zero-trust-architectuur voor militaire netwerken
• Air-gapped implementatiepatronen voor defensieworkloads
• Post-kwantumcryptografie en CNSA 2.0-naleving voor defensie