Azure Event Hubs vs Kafka local pentru sarcini de apărare

Alegerea unei platforme de streaming de evenimente pentru un program de apărare implică mai mult decât compararea benchmark-urilor de debit. Cerințele de rezidență a datelor, mandatele de air gap, cadrele de conformitate și nivelurile de clasificare constrâng decizia în moduri care nu au echivalent în implementările comerciale. O echipă care alege un serviciu cloud gestionat fără a verifica autorizările la nivel de impact, sau care implementează Kafka self-hosted fără a planifica pentru sarcina operațională, va întâmpina probleme care nu pot fi remediate după ce sistemul este în producție.

Acest articol prezintă un cadru de decizie pentru alegerea între Azure Event Hubs și Apache Kafka local pentru sarcini de apărare, acoperă implicațiile specifice de conformitate și arhitectură ale fiecăruia, descrie un model hibrid care utilizează ambele platforme pentru diferite niveluri de clasificare și explică calea de migrare între ele atunci când cerințele se schimbă.

De ce contează decizia privind platforma de streaming în apărare

Într-o implementare comercială, alegerea între un serviciu de streaming gestionat și un cluster self-hosted este în primul rând un compromis operațional: serviciile gestionate costă mai mult per eveniment, dar elimină overhead-ul de gestionare a clusterului. În apărare, decizia este și o decizie de arhitectură de securitate și conformitate cu consecințe care depășesc orice singur sprint.

Regulile de rezidență a datelor pentru informațiile clasificate specifică nu doar unde pot fi stocate datele, ci și ce furnizori de infrastructură sunt autorizați să le gestioneze. Un program care operează sub restricțiile IL5 poate utiliza doar regiunile Azure Government care au primit autorizarea provizorie IL5 — nu fiecare serviciu Azure din Azure Government se califică, și nu fiecare regiune poartă aceleași autorizări. Un program cu o cerință strictă de air gap nu are nicio cale către un serviciu cloud gestionat, indiferent de postura sa FedRAMP, deoarece chiar și un serviciu autorizat FedRAMP High necesită o conexiune de rețea pentru a funcționa.

Platforma de streaming este, de asemenea, locul unde obligațiile de conformitate privind jurnalizarea auditului, proprietatea cheilor de criptare și retenția datelor sunt aplicate la nivelul infrastructurii. A face corect această arhitectură de la început economisește luni de refactorizare atunci când funcționarul autorizator examinează planul de securitate al sistemului.

Azure Event Hubs: streaming gestionat pentru sarcini GovCloud

API compatibil cu Kafka și zero gestionare a clusterului

Nivelurile Premium și Dedicated ale Azure Event Hubs expun un endpoint de protocol compatibil cu Kafka. Producătorii și consumatorii construiți cu biblioteca client Apache Kafka se conectează la un namespace Event Hubs modificând două valori de configurare: bootstrap.servers indică spre <namespace>.servicebus.usgovcloudapi.net:9093 în Azure Government, iar sasl.mechanism este setat la PLAIN cu credențiale de șir de conexiune sau la un token Azure Active Directory folosind mecanismul OAuth bearer. Nu sunt necesare modificări de cod specifice Kafka. API-ul este compatibil cu bibliotecile client Kafka 1.0 și versiunile ulterioare.

Consecința operațională este că nimeni din echipa dvs. nu trebuie să gestioneze provizionarea broker-elor, configurația quorum-ului controller, rotația certificatelor TLS pentru cluster, stocurile de credențiale SCRAM sau scalarea capacității. Unitățile de debit se scalează la cerere. Disponibilitatea este susținută de un acord de nivel de serviciu. Geo-redundanța este o setare de configurare, nu un proiect de implementare multi-site.

Autorizare FedRAMP High, IL4 și IL5

Azure Event Hubs în Azure Government deține autorizarea FedRAMP High. Nivelul Dedicated, care oferă infrastructură single-tenant, acceptă nivelurile de impact IL4 și IL5 conform documentației din matricea de disponibilitate a serviciilor Azure Government. Criptarea cu chei gestionate de client este disponibilă prin Azure Key Vault Managed HSM, satisfăcând cerința AES-256 la repaus pe care o poartă sarcinile IL5. Datele procesate și stocate în Event Hubs Dedicated în Azure Government nu părăsesc granița cloud-ului guvernamental.

Pentru programele al căror plafon de clasificare este CONFIDENTIAL sau FOUO — sau sarcinile SECRET cu un punct de acces cloud aprobat — Event Hubs Dedicated în Azure Government este adesea calea cea mai rapidă către o infrastructură de streaming conformă. Infrastructura broker-ului este acoperită de pachetul de autorizare FedRAMP al Microsoft, reducând suprafața pe care echipa dvs. trebuie să o documenteze și să o apere în planul de securitate al sistemului.

Limitările API și ce înseamnă ele pentru aplicațiile de apărare

Event Hubs nu implementează API-ul complet Kafka. Tranzacțiile și semantica exactly-once pe mai multe topicuri nu sunt acceptate la nivelul broker-ului. API-urile de gestionare ACL ale AdminClient lipsesc — controlul accesului este gestionat la nivelul Azure RBAC (rolurile Data Sender și Data Receiver la domeniul namespace-ului sau al entității) mai degrabă decât prin ACL-uri native Kafka. Offset-urile grupurilor de consumatori sunt gestionate de serviciu și nu sunt manipulabile direct prin API-ul de comitere a offset-ului Kafka în același mod ca un cluster self-hosted.

Pentru aplicațiile de apărare construite de la zero pe Event Hubs, aceste lacune sunt gestionabile prin proiectarea în jurul lor. Pentru aplicațiile care migrează de la Kafka self-hosted și care se bazează pe tranzacții sau gestionarea programatică a ACL-urilor, ele necesită modificări de cod. Auditați această listă de dependențe înainte de a vă angaja la Event Hubs ca platformă pe termen lung.

Kafka local: capacitate de air gap și control complet al clasificării

Singura cale viabilă pentru cerințele stricte de air gap

Orice program cu un mandat de a opera fără conectivitate la rețele externe — fie din motive de securitate fizică, securitate operațională sau acreditare — are exact o platformă de streaming viabilă: Kafka self-hosted pe infrastructură locală. Nu există un echivalent de serviciu gestionat care să funcționeze fără acces la internet. Azure Event Hubs, indiferent de postura sa de conformitate, necesită conectivitate la planul de control Azure Government pentru a proviziona resurse, a roti tokenurile SAS și a primi apeluri API de gestionare.

Kafka local în modul KRaft, implementat fără interfețe de rețea direcționate dincolo de granița enclavei, satisface cerința strictă de air gap. Toate dependențele — JVM, binarele Kafka, imaginile de container, certificatele TLS — sunt pre-pregătite local înainte de a întrerupe rețeaua. Clusterul funcționează apoi pe termen nedefinit fără conectivitate externă. Pentru o prezentare detaliată a pregătirii imaginilor de container și a modelelor de implementare cu air gap, consultați articolul despre modele de implementare cu air gap pentru sarcini de apărare.

Modul KRaft și operarea autonomă a clusterului

Kafka 3.3 a introdus modul KRaft ca înlocuitor al gestionării metadatelor bazate pe ZooKeeper. Pentru implementările de apărare, KRaft este implicit corect pentru fiecare cluster nou. Un ansamblu ZooKeeper separat adaugă trei sau mai multe noduri suplimentare, un domeniu de eșec separat, o suprafață de configurare distinctă și un proces suplimentar de corectat și securizat. KRaft consolidează gestionarea quorum-ului controller în procesul broker-ului Kafka însuși folosind un jurnal de consens bazat pe Raft.

Într-o implementare clasificată mică sau medie — trei până la cinci noduri broker — rolurile de controller și broker pot fi co-localizate pe aceleași noduri, menținând numărul total de noduri la trei. În implementări mai mari, un quorum dedicat de trei noduri controller separat de nodurile broker oferă granițe operaționale mai clare. În ambele cazuri, clusterul nu are dependențe de servicii externe la runtime odată inițializat.

Sarcina operațională și implicațiile privind personalul

Kafka self-hosted nu este gratuit din punct de vedere operațional. Un cluster Kafka clasificat de calitate producție necesită atenție continuă: întărirea sistemului de operare și cicluri de corecții, gestionarea ciclului de viață al certificatelor TLS aliniată cu programul de reînnoire al PKI-ului intern, rotația credențialelor SCRAM, ajustarea retenției jurnalelor broker-ului, reechilibrarea partițiilor pe măsură ce debitul topicului crește și planificarea capacității pentru discul broker-ului. Upgrade-urile continue în versiunile minore Kafka necesită o secvențiere atentă pentru a evita incompatibilitățile de protocol.

Programele care subestimează această sarcină ajung cu clustere care derivă de la baseline-ul de configurare aprobat în timp — o problemă care apare dureros în timpul revizuirilor de re-acreditare. Dacă programul nu are o funcție dedicată de inginerie de platformă, planificați explicit cine deține operațiunile Kafka înainte ca clusterul să intre în producție.

Matricea de decizie

Tabelul de mai jos mapează factorii cheie de implementare la alegerea corespunzătoare de platformă.

Factor	Azure Event Hubs	Kafka local
Air gap strict necesar	Nu este viabil	Complet acceptat
FedRAMP High / IL4/IL5	Moștenit din Azure Gov	Responsabilitatea operatorului
Plafon clasificare date	IL5 / FOUO (GovCloud)	SECRET / TS (air-gap)
Capacitate ops necesară	Minimă (serviciu gestionat)	Mare (ops cluster complet)
Gestionare cluster	Niciuna (complet gestionat)	Completă (TLS, KRaft, corecții)
Elasticitate debit	Elastică (unități de debit)	Scalare manuală broker
Suprafață completă API Kafka	Parțială (fără tranzacții)	Completă

Arhitectură hibridă: streaming stratificat pe niveluri de clasificare

Multe programe de apărare operează simultan în mai multe domenii de clasificare. O platformă de management al câmpului de luptă poate ingera fluxuri OSINT neclasificate, date logistice FOUO și telemetrie de senzori SECRET din același tablou operațional. Construirea unei singure infrastructuri de streaming care să satisfacă toate cele trei niveluri este imposibilă — cerința de air gap pentru datele SECRET este incompatibilă cu abordarea cloud gestionat care funcționează bine pentru datele FOUO.

Răspunsul practic este o arhitectură stratificată: Azure Event Hubs în Azure Government gestionează nivelul UNCLASSIFIED și FOUO, unde autorizarea FedRAMP High acoperă cerința de conformitate și scalarea gestionată gestionează ratele variabile de ingestie. Kafka local în spatele unei enclave cu air gap gestionează nivelul SECRET și TS, unde nicio dependență de rețea externă nu este tolerabilă. Cele două niveluri nu sunt conectate direct.

Soluții cross-domain la granița nivelurilor

Acolo unde datele declasificate sau care pot fi divulgate trebuie să curgă de la nivelul clasificat la cel neclasificat — de exemplu, un raport de poziție sanitizat derivat dintr-un traseu fuzionat SECRET — o soluție cross-domain (CDS) certificată aplică granița. CDS-ul inspectează datele de ieșire față de o politică de conținut definită, elimină marcajele de clasificare și câmpurile sensibile și eliberează rezultatul în namespace-ul neclasificat Event Hubs. Nu există nicio cale de rețea directă între cele două medii Kafka. CDS-ul este singurul canal, iar fluxurile sale de date sunt documentate în planul de securitate al sistemului și validate în timpul acreditării.

Această arhitectură este mai complexă de operat decât o soluție cu un singur nivel, dar reflectă realitatea programelor de apărare multi-domeniu. Pentru o analiză mai aprofundată a modelelor de design cross-domain, consultați articolul despre soluții cross-domain pentru apărare.

Calea de migrare: de la Event Hubs la Kafka local

Programele încep uneori cu Event Hubs — deoarece sarcina se califică inițial pentru o implementare GovCloud — și constată ulterior că cerințele de clasificare cresc, se adaugă un mandat de air gap sau programul migrează într-o enclavă de rețea mai restrictivă. API-ul compatibil cu Kafka înseamnă că această migrare este o modificare de configurare, nu o rescriere a codului.

Ce se schimbă în migrare

Pe partea producătorului și consumatorului, trei valori de configurare se schimbă. În primul rând, bootstrap.servers se mută de la endpoint-ul namespace-ului Event Hubs la adresa internă a clusterului Kafka local. În al doilea rând, security.protocol și sasl.mechanism se schimbă de la SASL_SSL cu PLAIN la SASL_SSL cu SCRAM-SHA-512. În al treilea rând, configurația truststore se schimbă de la lanțul de certificate publice al serviciului Azure la certificatul CA intern pentru clusterul local. ID-urile grupurilor de consumatori, numele topicurilor și toată logica la nivel de aplicație rămân neschimbate.

Pe partea infrastructurii, clusterul Kafka local trebuie provizionat, întărit și testat cu sarcini reprezentative înainte de tranziția producătorilor. Configurația topicurilor — numărul de partiții, factorii de replicare, politicile de retenție — trebuie replicată din namespace-ul Event Hubs în clusterul local. Offset-urile grupurilor de consumatori din Event Hubs nu pot fi transferate direct; planificați o fereastră de tranziție în care consumatorii reprocesează de la începutul ferestrei de retenție sau de la un checkpoint cunoscut.

Lista de verificare pre-migrare

Înainte de executarea tranziției, confirmați că clusterul local a trecut o revizuire de securitate: TLS 1.3 verificat pe toți listener-ii prin openssl s_client, auditul ACL completat cu kafka-acls.sh --list, porturile broker confirmate ca inaccesibile din afara enclavei prin scanare de rețea și toate credențialele SCRAM ale conturilor de serviciu stocate în sistemul de gestionare a secretelor cu rotația configurată. Documentați procedura de tranziție într-un runbook și efectuați o simulare cu sarcini de non-producție înainte de a migra fluxurile de date clasificate. Pentru controalele de rețea zero-trust care ar trebui să învelească stratul Kafka, consultați articolul despre arhitectura zero-trust pentru rețele militare.

Corvus.Quantum: streaming dual-mode pentru programele de apărare clasificate

Corvus.Quantum este o platformă de streaming de evenimente întărită pentru apărare care acceptă ambele moduri de implementare descrise în acest articol. În implementările GovCloud, se integrează cu Azure Event Hubs Dedicated folosind chei gestionate de client și autentificare Azure Active Directory, oferind un stack de producător și consumator pre-configurat cu criptare post-cuantică la nivelul aplicației. În implementările cu air gap, rulează pe un cluster Kafka în modul KRaft auto-conținut cu TLS 1.3, SCRAM-SHA-512 și stocare broker criptată LUKS — toate pre-întărite și validate pentru medii clasificate.

Platforma a fost implementată operațional pentru procesarea datelor de apărare în timp real, gestionând mii de evenimente pe secundă cu latență end-to-end sub 100 ms. Adaugă încapsulare de chei CRYSTALS-Kyber și criptare a sarcinii utile AES-256-GCM la nivelul aplicației, protejând conținutul mesajelor împotriva atât a interceptărilor actuale, cât și a decriptării viitoare cu capabilități cuantice — o cerință pentru datele de senzori și ISR cu o durată de viață lungă a sensibilității.

Pentru programele care navighează alegerea între Event Hubs și Kafka local, Corvus.Quantum elimină necesitatea de a construi și menține configurații întărite separate pentru fiecare mod de implementare. Aceeași aplicație se conectează la oricare backend prin același strat de abstractizare, iar calea de migrare între moduri nu necesită modificări ale codului aplicației. Când cerințele de clasificare ale programului dvs. se schimbă, infrastructura de streaming se schimbă odată cu ele.

Articole conexe

• Apache Kafka pentru apărare: arhitectură de mesagerie securizată în timp real
• Modele de implementare cu air gap pentru sarcini de apărare
• Arhitectura zero-trust pentru rețele militare