Het kiezen van een event streaming-platform voor een defensieprogramma gaat verder dan het vergelijken van doorvoerbenchmarks. Vereisten voor dataresidentie, air-gap-mandaten, nalevingskaders en classificatieniveaus beperken de beslissing op manieren die geen equivalent hebben in commerciële implementaties. Een team dat een beheerde cloudservice kiest zonder de impactniveau-autorisaties te controleren, of self-hosted Kafka implementeert zonder de operationele last te plannen, zal problemen tegenkomen die niet kunnen worden opgelost nadat het systeem in productie is.

Dit artikel presenteert een beslissingskader voor de keuze tussen Azure Event Hubs en on-premises Apache Kafka voor defensie-workloads, behandelt de specifieke compliance- en architectuurimplicaties van elk, beschrijft een hybride model dat beide platforms gebruikt voor verschillende classificatietiers, en legt het migratiepad uit wanneer vereisten veranderen.

Waarom de keuze van streaming-platform belangrijk is in defensie

Bij een commerciële implementatie is de keuze tussen een beheerde streamingservice en een self-hosted cluster primair een operationele afweging: beheerde services kosten meer per event maar elimineren de overhead van clusterbeheer. Bij defensie is de beslissing ook een compliance- en beveiligingsarchitectuurbeslissing met gevolgen die elke enkele sprint overleven.

Regels voor dataresidentie van geclassificeerde informatie specificeren niet alleen waar data mag worden opgeslagen, maar ook welke infrastructuurproviders bevoegd zijn om deze te verwerken. Een programma dat onder IL5-beperkingen opereert, kan alleen Azure Government-regio's gebruiken die IL5-voorlopige autorisatie hebben ontvangen — niet elke Azure-service in Azure Government kwalificeert, en niet elke regio draagt dezelfde autorisaties. Een programma met een harde air-gap-vereiste heeft geen weg naar een beheerde cloudservice, ongeacht zijn FedRAMP-positie, omdat zelfs een FedRAMP High-geautoriseerde service een netwerkverbinding vereist om te functioneren.

Het streaming-platform is ook waar nalevingsverplichtingen rondom auditlogboeken, eigendom van versleutelingssleutels en gegevensbewaring worden afgedwongen op infrastructuurniveau. Door deze architectuur vanaf het begin goed op te zetten, bespaart u maanden van herwerk wanneer de autoriserende functionaris het systeembeveiligingsplan beoordeelt.

Azure Event Hubs: beheerde streaming voor GovCloud-workloads

Kafka-compatibele API en nul clusterbeheer

Azure Event Hubs Premium en Dedicated-tiers bieden een Kafka-compatibel protocol-eindpunt. Producers en consumers gebouwd op de Apache Kafka-clientbibliotheek verbinden met een Event Hubs-naamruimte door twee configuratiewaarden te wijzigen: bootstrap.servers verwijst naar <namespace>.servicebus.usgovcloudapi.net:9093 in Azure Government, en sasl.mechanism is ingesteld op PLAIN met verbindingsreekscredentials of op een Azure Active Directory-token met behulp van het OAuth-bearerachanism. Er zijn geen Kafka-specifieke codewijzigingen vereist. De API is compatibel met Kafka 1.0 en latere clientbibliotheken.

De operationele consequentie is dat niemand in uw team broker-provisioning, controllerquorumconfiguratie, TLS-certificaatrotatie voor het cluster, SCRAM-credential-opslag of capaciteitsschaalbaarheid hoeft te beheren. Doorvoereenheden schalen op aanvraag. Beschikbaarheid wordt ondersteund door een service level agreement. Geo-redundantie is een configuratie-instelling in plaats van een multi-site implementatieproject.

FedRAMP High, IL4 en IL5-autorisatie

Azure Event Hubs in Azure Government heeft FedRAMP High-autorisatie. De Dedicated-tier, die infrastructuur voor één tenant biedt, ondersteunt IL4- en IL5-impactniveaus zoals gedocumenteerd in de Azure Government-servicebeschikbaarheidsmatrix. Versleuteling met door de klant beheerde sleutels is beschikbaar via Azure Key Vault Managed HSM, wat voldoet aan de AES-256-versleutelingsvereiste in rust die IL5-workloads meebrengen. Data verwerkt en opgeslagen in Event Hubs Dedicated in Azure Government verlaat de overheidscloudgrens niet.

Voor programma's waarvan het classificatieplafond CONFIDENTIAL of FOUO is — of SECRET-workloads met een goedgekeurd cloud-toegangspunt — is Event Hubs Dedicated in Azure Government vaak het snelste pad naar een conforme streaminginfrastructuur. De brokerinfrastructuur valt onder het FedRAMP-autorisatiepakket van Microsoft, waardoor het oppervlak dat uw team moet documenteren en verdedigen in het systeembeveiligingsplan wordt verkleind.

API-beperkingen en wat ze betekenen voor defensietoepassingen

Event Hubs implementeert niet de volledige Kafka API. Transacties en exactly-once semantics over meerdere topics worden niet ondersteund op het brokerniveau. De ACL-beheer-API's van AdminClient ontbreken — toegangscontrole wordt afgehandeld op de Azure RBAC-laag (Data Sender en Data Receiver-rollen op naamruimte- of entiteitsniveau) in plaats van via Kafka-native ACL's. Consumer group offsets worden beheerd door de service en zijn niet direct manipuleerbaar via de Kafka offset commit API op dezelfde manier als bij een self-hosted cluster.

Voor defensietoepassingen die vanaf nul zijn gebouwd voor Event Hubs, zijn deze hiaten werkbaar door er omheen te ontwerpen. Voor toepassingen die migreren van self-hosted Kafka die afhankelijk zijn van transacties of programmatisch ACL-beheer, vereisen ze codewijzigingen. Controleer deze afhankelijkheidslijst voordat u Event Hubs als langetermijnplatform vastlegt.

On-premises Kafka: air-gap-capaciteit en volledige classificatiecontrole

Het enige levensvatbare pad voor harde air-gap-vereisten

Elk programma met een mandaat om te opereren zonder externe netwerkconnectiviteit — of dat nu voor fysieke beveiliging, operationele beveiliging of accreditatieredenen is — heeft precies één levensvatbaar streaming-platform: self-hosted Kafka op on-premises infrastructuur. Er is geen beheerde service-equivalent die functioneert zonder internettoegang. Azure Event Hubs, ongeacht zijn compliancepositie, vereist connectiviteit met het Azure Government-besturingsvlak om resources in te richten, SAS-tokens te roteren en beheer-API-aanroepen te ontvangen.

On-premises Kafka in KRaft-modus, geïmplementeerd zonder netwerkinterfaces die verder gaan dan de enclavegrens, voldoet aan de harde air-gap-vereiste. Alle afhankelijkheden — JVM, Kafka-binaire bestanden, containerafbeeldingen, TLS-certificaten — worden lokaal vooraf opgeslagen voordat het netwerk wordt verbroken. Het cluster werkt vervolgens voor onbepaalde tijd zonder uitgaande connectiviteit. Zie voor een gedetailleerde doorloop van containerafbeelding-staging en air-gap-implementatiepatronen het artikel over air-gapped implementatiepatronen voor defensie-workloads.

KRaft-modus en zelfstandige clusterwerking

Kafka 3.3 introduceerde KRaft-modus als vervanging voor ZooKeeper-gebaseerd metadatabeheer. Voor defensie-implementaties is KRaft de juiste standaard voor elk nieuw cluster. Een afzonderlijk ZooKeeper-ensemble voegt drie of meer extra knooppunten toe, een afzonderlijk foutdomein, een apart configuratieoppervlak en een extra proces om te patchen en te beveiligen. KRaft consolideert controllerquorumbeheer in het Kafka-brokerproces zelf met behulp van een Raft-gebaseerd consensuslog.

In een kleine tot middelgrote geclassificeerde implementatie — drie tot vijf brokerknooppunten — kunnen de controller- en brokerrollen op dezelfde knooppunten worden geplaatst, waardoor het totale knooppuntaantal op drie blijft. In grotere implementaties biedt een dedicated drieknooppunts-controllerquorum apart van brokerknooppunten schonere operationele grenzen. Hoe dan ook heeft het cluster geen externe serviceafhankelijkheden tijdens runtime eenmaal opgestart.

Operationele last en personeelsimplicaties

Self-hosted Kafka is operationeel niet gratis. Een productiewaardige geclassificeerde Kafka-cluster vereist voortdurende aandacht: OS-hardening en patchcycli, TLS-certificaatlevenscyclusbeheer afgestemd op de vernieuwingsplanning van uw interne PKI, SCRAM-credential-rotatie, afstemming van brokerlogbewaring, partitieherbalancering naarmate de ondwerpdoorvoer groeit, en capaciteitsplanning voor brokerschijf. Rolling upgrades over Kafka-minor-versies vereisen zorgvuldige sequentiëring om protocolincompatibiliteiten te vermijden.

Programma's die deze last onderschatten, eindigen met clusters die in de loop van de tijd afwijken van hun goedgekeurde configuratiebasislijn — een probleem dat pijnlijk naar voren komt tijdens heraccreditatiereviews. Als het programma geen dedicated platformengineering-functie heeft, plan dan expliciet wie Kafka-operaties bezit voordat het cluster in productie gaat.

Beslissingsmatrix

De onderstaande tabel koppelt de belangrijkste implementatiefactoren aan de juiste platformkeuze.

Factor Azure Event Hubs On-prem Kafka
Harde air-gap vereist Niet haalbaar Volledig ondersteund
FedRAMP High / IL4/IL5 Geërfd van Azure Gov Verantwoordelijkheid operator
Classificatieplafond data IL5 / FOUO (GovCloud) SECRET / TS (air-gap)
Vereiste ops-capaciteit Minimaal (beheerde service) Hoog (volledig clusterops)
Clusterbeheer Geen (volledig beheerd) Volledig (TLS, KRaft, patches)
Doorvoer elasticiteit Elastisch (doorvoereenheden) Handmatige brokerscaling
Volledig Kafka API-oppervlak Gedeeltelijk (geen transacties) Volledig

Hybride architectuur: gestreamde streaming per classificatieniveau

Veel defensieprogramma's opereren tegelijkertijd over meerdere classificatiedomeinen. Een battlespace management-platform kan niet-geclassificeerde OSINT-feeds, FOUO-logistiekdata en SECRET-sensortelemetrie opnemen vanuit hetzelfde operationele beeld. Het bouwen van een enkele streaminginfrastructuur die aan alle drie tiers voldoet is onmogelijk — de air-gap-vereiste voor SECRET-data is incompatibel met de beheerde cloudaanpak die goed werkt voor FOUO-data.

Het praktische antwoord is een gelaagde architectuur: Azure Event Hubs in Azure Government verwerkt de UNCLASSIFIED- en FOUO-tier, waar FedRAMP High-autorisatie de nalevingsvereiste dekt en beheerde schaalbaarheid variabele ingeststromen verwerkt. On-premises Kafka achter een air-gapped enclave verwerkt de SECRET- en TS-tier, waar geen externe netwerkafhankelijkheid toelaatbaar is. De twee tiers zijn niet direct verbonden.

Cross-domain solutions aan de tiergrens

Waar afgeschaalde of vrijgegeven data van de geclassificeerde tier naar de niet-geclassificeerde tier moet stromen — bijvoorbeeld een gesaneerd positierapport afgeleid van een SECRET-gefuseerde track — dwingt een gecertificeerde cross-domain solution (CDS) de grens af. De CDS inspecteert uitgaande data tegen een gedefinieerd inhoudsbeleid, verwijdert classificatiemarkering en gevoelige velden, en geeft het resultaat vrij aan de niet-geclassificeerde Event Hubs-naamruimte. Er bestaat geen direct netwerkpad tussen de twee Kafka-omgevingen. De CDS is het enige kanaal, en de datastromen zijn gedocumenteerd in het systeembeveiligingsplan en gevalideerd tijdens accreditatie.

Deze architectuur is complexer te beheren dan een single-tier-oplossing, maar weerspiegelt de realiteit van multi-domein defensieprogramma's. Voor een diepgaandere behandeling van cross-domain-ontwerppatronen, zie het artikel over cross-domain solutions voor defensie.

Migratiepad: van Event Hubs naar on-prem Kafka

Programma's beginnen soms met Event Hubs — omdat de workload aanvankelijk in aanmerking komt voor een GovCloud-implementatie — en ontdekken later dat de classificatievereisten toenemen, een air-gap-mandaat wordt toegevoegd, of het programma migreert naar een meer restrictieve netwerkenenklave. De Kafka-compatibele API betekent dat deze migratie een configuratiewijziging is, geen herschrijving van code.

Wat verandert in de migratie

Aan de producer- en consumerkant wijzigen drie configuratiewaarden. Ten eerste verplaatst bootstrap.servers van het Event Hubs-naamruimte-eindpunt naar het interne adres van het on-premises Kafka-cluster. Ten tweede wijzigen security.protocol en sasl.mechanism van SASL_SSL met PLAIN naar SASL_SSL met SCRAM-SHA-512. Ten derde verandert de truststore-configuratie van de openbare certificaatketen van de Azure-service naar het interne CA-certificaat voor het on-premises cluster. Consumer group ID's, onderwerpnamen en alle applicatielaaglogica blijven ongewijzigd.

Aan de infrastructuurkant moet het on-premises Kafka-cluster worden ingericht, gehard en getest met representatieve belasting voordat producers worden omgeschakeld. Onderwerpconfiguratie — partitieaantallen, replicatiefactoren, bewaarbeleid — moet worden gerepliceerd van de Event Hubs-naamruimte naar het on-prem-cluster. Consumer group offsets van Event Hubs kunnen niet direct worden overgedragen; plan voor een overgangsvenster waarbij consumers herverwerken vanaf het begin van het bewaarvenster of vanaf een bekend controlepunt.

Controlelijst voor pre-migratie

Bevestig voordat u de overgang uitvoert dat het on-premises cluster een beveiligingsreview heeft doorstaan: TLS 1.3 geverifieerd op alle listeners via openssl s_client, ACL-audit voltooid met kafka-acls.sh --list, brokerpoorten bevestigd onbereikbaar van buiten de enclave via netwerkscan, en alle serviceaccount-SCRAM-credentials opgeslagen in het geheimbeheersysteem met geconfigureerde rotatie. Documenteer de overgangsprocedure in een runbook en voer een droogoefening uit met niet-productie-workloads voordat geclassificeerde datastromen worden gemigreerd. Zie voor de zero-trust-netwerkcontroles die de Kafka-laag moeten omhullen het artikel over zero-trust-architectuur voor militaire netwerken.

Corvus.Quantum: dual-mode streaming voor geclassificeerde defensieprogramma's

Corvus.Quantum is een defensie-geharde event streaming-platform dat beide implementatiemodi ondersteunt die in dit artikel worden beschreven. In GovCloud-implementaties integreert het met Azure Event Hubs Dedicated met door de klant beheerde sleutels en Azure Active Directory-authenticatie, en biedt een vooraf geconfigureerde producer- en consumerstack met post-kwantumversleuteling op de applicatielaag. In air-gapped implementaties draait het op een zelfstandig KRaft-modus Kafka-cluster met TLS 1.3, SCRAM-SHA-512 en LUKS-versleutelde brokerstorage — allemaal vooraf gehard en gevalideerd voor geclassificeerde omgevingen.

Het platform is operationeel ingezet voor real-time defensie-dataverwerking, waarbij duizenden events per seconde worden verwerkt met minder dan 100ms end-to-end latentie. Het voegt CRYSTALS-Kyber-sleutelinkapsuling en AES-256-GCM-payload-versleuteling toe op de applicatielaag, waardoor berichtinhoud wordt beschermd tegen zowel huidige onderschepping als toekomstige kwantumgedecryptie — een vereiste voor sensor- en ISR-data met een lange gevoeligheidslevensduur.

Voor programma's die de keuze tussen Event Hubs en on-prem Kafka navigeren, verwijdert Corvus.Quantum de noodzaak om afzonderlijke geharde configuraties voor elke implementatiemodus te bouwen en te onderhouden. Dezelfde toepassing verbindt met beide backends via dezelfde abstractielaag, en het migratiepad tussen modi vereist geen toepassingscodewijzigingen. Wanneer de classificatievereisten van uw programma veranderen, verandert de streaminginfrastructuur mee.

Gerelateerde artikelen

Corvus.Quantum levert een productierijp defensie-streamingplatform dat draait op Azure Event Hubs in GovCloud of op self-hosted Kafka achter een air-gap — vooraf gehard, post-kwantumversleuteld en gevalideerd in actieve operationele implementaties. Als uw programma high-throughput geclassificeerde streaming nodig heeft zonder maanden van beveiligingstechniek, praat dan met ons team.

Ontdek Corvus.Quantum →