Apache Kafka pentru apărare: arhitectură de mesagerie securizată în timp real

Sistemele de apărare generează date la un ritm și volum pe care arhitecturile convenționale cerere-răspuns nu le pot absorbi. Un singur UAS transmite zeci de parametri de telemetrie pe secundă. Un nod C2 la nivel de brigadă gestionează sute de rapoarte de poziție și evenimente de stare pe minut. O celulă de fuziune ISR ingerează fluxuri de la radar, informații de semnale și raportare umană simultan, toate necesitând corelație sub un minut. Când aceste fluxuri trebuie să circule fiabil printr-o infrastructură rezistentă, auditabilă și clasificată, Apache Kafka a devenit backbone-ul arhitectural de referință.

Acest articol acoperă modul de implementare a Kafka specific pentru cazurile de utilizare din apărare: strategia de partiționare pentru medii cu clasificări multiple, configurarea completă a criptării, implementarea air-gap folosind modul KRaft și compromisul dintre clusterele auto-găzduite și alternativele gestionate precum Azure Event Hubs pentru sarcinile de lucru GovCloud.

De ce streaming-ul de evenimente se potrivește arhitecturilor de apărare

Fluxurile de lucru din apărare sunt în mod inerent orientate pe evenimente. Telemetria senzorilor nu sosește în loturi ordonate — este un flux continuu de citiri care trebuie procesate în momentul în care ajung pentru a fi utile operațional. Evenimentele C2 — mișcarea unităților, schimbările de sarcini, actualizările de stare — sunt mesaje discrete de care mai multe sisteme consumatoare au nevoie simultan: imaginea operațională comună, logistica, coordonarea focului și raportarea post-acțiune au toate nevoie de același eveniment subiacent, fără ca producătorul să știe cine ascultă.

Modelul publish-subscribe al Kafka se mapează curat pe această cerință. Un producător scrie o citire de senzor sau un eveniment C2 într-un subiect. Orice număr de grupuri de consumatori — fiecare reprezentând o aplicație downstream diferită — reproduce evenimentul independent, în propriul ritm. Această decuplare înseamnă că adăugarea unei noi sarcini de lucru analitice nu necesită modificări ale sistemului producător, ceea ce este critic în mediile de apărare unde controlul schimbărilor de software este lent și ciclurile de aprobare sunt îndelungate.

Dincolo de decuplare, jurnalul durabil al Kafka oferă o urmă de audit doar-cu-adăugare care satisface cerințele criminalistice pe care le poartă majoritatea sistemelor de apărare. Fiecare mesaj este păstrat pe disc pentru o perioadă configurabilă. Dacă apare un incident, operatorii pot reproduce secvența exactă de evenimente care au condus la acesta, fără a se baza pe jurnalizarea la nivelul aplicației.

Arhitectura de bază Kafka pentru medii clasificate

Topologia brokerului

Un cluster Kafka clasificat de grad producție necesită minimum trei noduri broker pentru a suporta un factor de replicare de trei și o setare min.insync.replicas de doi. Această configurație tolerează pierderea unui singur broker fără pierdere de date sau erori ale producătorului. Pentru implementări clasificate cu disponibilitate ridicată, cinci brokeri — distribuiți pe cel puțin trei rack-uri fizice sau zone de disponibilitate — oferă o toleranță la erori mai puternică cu marjă pentru upgrade-uri continue.

Începând cu Kafka 3.3, modul KRaft înlocuiește ZooKeeper pentru gestionarea metadatelor clusterului. Pentru implementările de apărare air-gapped, aceasta nu este opțională — este valoarea implicită corectă. Un ansamblu ZooKeeper separat adaugă trei noduri suplimentare, un domeniu de eșec separat și o suprafață de atac suplimentară. KRaft consolidează gestionarea metadatelor în brokerii Kafka înșiși, folosind un quorum bazat pe Raft al nodurilor controler, de obicei co-găzduite cu brokerii în clustere mici sau separate în cele mari.

Partiționarea subiectelor pe niveluri de clasificare

Cea mai importantă decizie arhitecturală într-o implementare Kafka cu clasificări multiple este modul de impunere a izolării între datele la niveluri diferite de sensibilitate. Există două abordări.

Prima abordare utilizează un singur cluster cu izolare ACL la nivel de subiect. Subiectele sunt spațiu-de-numere pe clasificare: ts.sensor.uav-telemetry pentru telemetria strict secretă, s.c2.position-reports pentru datele C2 de nivel secret, c.logistics.supply-events pentru logistica confidențială. Fiecare cont de serviciu primește drepturi de producere și consum doar pentru subiectele corespunzătoare nivelului său de autorizare. Această abordare reduce complexitatea operațională, dar necesită o mare încredere în impunerea ACL-urilor Kafka și o segmentare atentă a rețelei pentru a asigura că procesele broker în sine nu reprezintă o cale de mișcare laterală.

A doua abordare — preferată atunci când se gestionează date deasupra nivelului SECRET pe aceeași infrastructură fizică — utilizează clustere de brokeri separate per domeniu de clasificare, conectate printr-o soluție cross-domain (CDS) pentru cazurile rare în care datele degradate trebuie să treacă o granița. Aceasta elimină complet riscul brokerilor partajați, cu prețul unei sarcini operaționale crescute. Pentru o tratare mai aprofundată a arhitecturilor cross-domain, consultați articolul despre soluții cross-domain pentru apărare.

Retenția și numărul de partiții

Stabiliți numărul de partiții pe baza debitului așteptat, nu a comodității. Un subiect care gestionează 10.000 de mesaje pe secundă de la o matrice de senzori ar trebui să aibă suficiente partiții astfel încât fiecare consumator dintr-un grup să poată procesa partițiile atribuite fără întârziere. O regulă practică: numărul de partiții ar trebui să fie cel puțin egal cu numărul de consumatori din grupul consumator și ideal de două până la trei ori mai mare pentru a permite rebalansarea grupurilor de consumatori fără a introduce puncte fierbinți.

Deciziile privind politica de retenție trebuie documentate și justificabile. Telemetria senzorilor analizată în timp aproape real necesită de obicei doar 24–72 de ore de retenție înainte de a putea fi transferată la stocare rece sau eliminată. Jurnalele de evenimente C2 necesare pentru revizuirea post-acțiune ar trebui păstrate 30–90 de zile în nivelul fierbinte, după care ar trebui exportate într-o arhivă criptată și imuabilă. Nu vă bazați pe Kafka singur ca stocare de audit pe termen lung — este un bus de evenimente, nu o bază de date arhivală.

Criptarea în tranzit: TLS 1.3 și SASL SCRAM

Mediile clasificate impun criptarea pe fiecare cale de date. Pentru Kafka, aceasta înseamnă două controale distincte: criptarea transportului și autentificarea clientului.

Configurarea TLS 1.3

Configurați fiecare listener Kafka — inclusiv comunicarea inter-broker — cu TLS 1.3. În 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

Setarea ssl.client.auth=required impune TLS mutual (mTLS): fiecare client conectat trebuie să prezinte un certificat semnat de autoritatea certificatoare internă. Aceasta asigură că numai sistemele cunoscute și provizionate se pot conecta la cluster — o cerință în orice enclavă clasificată. Nu utilizați requested sau none în medii clasificate.

Certificatele trebuie să provină din PKI-ul intern. Nu utilizați certificate semnate de CA-uri publice într-un mediu air-gapped — și nu permiteți rădăcini CA publice în truststore-ul brokerului, deoarece aceasta ar putea permite unui certificat extern compromis să se prezinte ca un client legitim.

SASL SCRAM-SHA-512

Pe lângă mTLS, utilizați SASL SCRAM-SHA-512 pentru autentificarea la nivel de utilizator. Aceasta leagă o identitate numită — cum ar fi un cont de serviciu pentru o aplicație specifică — la conexiunea TLS, permițând impunerea ACL granulară bazată pe numele principal mai degrabă decât pe subiectul certificatului singur.

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

Provizionați credențialele cu kafka-configs.sh și stocați-le în sistemul de gestionare a secretelor — HashiCorp Vault sau un magazin de secrete echivalent air-gapped — mai degrabă decât în fișierele de configurare. Rotiți credențialele conform unui program aliniat cu politica de gestionare a cheilor din acreditarea dumneavoastră, de obicei la fiecare 90 de zile sau la schimbări de personal.

Criptarea în repaus: AES-256 și controale la nivelul de stocare

Kafka nu criptează nativ datele scrise în segmentele sale de jurnal. Criptarea în repaus este responsabilitatea nivelului de stocare. Pentru implementări pe bare-metal sau mașini virtuale, utilizați LUKS (Linux Unified Key Setup) cu AES-256 în modul XTS pe dispozitivele bloc care găzduiesc log.dirs ale Kafka. Pentru implementări bazate pe Kubernetes, provizionați resurse StorageClass susținute de volume criptate — pe Azure Government, utilizați criptarea de server cu chei gestionate de client (SSE-CMK) pe Azure Disk. Echivalentele on-premises includ NetApp cu unități NSE sau LUKS pur software pe NVMe standard.

Pentru sarcinile de lucru în care nici operatorul de stocare nu trebuie să poată citi conținutul mesajelor — deosebit de relevant pentru programele de acces special — implementați criptarea la nivelul aplicației: producătorul criptează conținutul mesajului înainte de scriere, iar numai consumatorii autorizați dețin cheia de decriptare. Această abordare este independentă de configurația Kafka și oferă confidențialitate end-to-end care persistă chiar dacă stocarea brokerului este compromisă. Compromisul este că filtrarea și compactarea la nivelul brokerului devin imposibile pentru conținut criptat, deoarece brokerul nu poate inspecta conținutul.

Implementarea Kafka air-gapped cu modul KRaft

O implementare Kafka air-gapped nu are conectivitate la internet, nu are rezoluție DNS externă și nu are acces la registre publice de containere sau oglinzi de pachete. Fiecare componentă trebuie să fie disponibilă local înainte ca clusterul să poată porni. Această secțiune acoperă capcanele specifice care prind inginerii atunci când implementează în acest mediu.

Modul KRaft și operarea fără ZooKeeper

Utilizați Kafka 3.6 sau o versiune ulterioară cu modul KRaft activat. Clusterul necesită un quorum controler — de obicei trei noduri controler, care pot fi co-localizate cu brokerii în implementări de trei până la cinci noduri. Fiecărui nod i se atribuie un node.id și o valoare process.roles de controller, broker sau ambele.

Bootstrap-ați clusterul cu kafka-storage.sh format pentru a genera un UUID de cluster și a scrie jurnalul de metadate inițial. Acest pas trebuie rulat pe fiecare nod cu același UUID înainte de pornirea oricărui proces broker. Într-un mediu air-gapped, generați UUID-ul pe un nod, copiați-l la celelalte, apoi rulați formatul pe fiecare.

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

DNS intern și gestionarea certificatelor

Configurați advertised.listeners să folosească nume de gazdă complet calificate rezolvabile în interiorul enclavei — fie printr-un server DNS intern, fie prin /etc/hosts pe fiecare gazdă care se va conecta la cluster. Utilizarea directă a adreselor IP în advertised.listeners funcționează, dar complică gestionarea certificatelor, deoarece SAN-urile certificatelor trebuie să listeze fiecare IP.

Rulați o CA rădăcină offline folosind step-ca sau CFSSL, ambele fără dependențe externe la rulare. Generați certificate de broker cu SAN-uri acoperind numele de gazdă al brokerului. Distribuiți certificatul CA rădăcină în truststore-ul fiecărui client. Stabiliți perioade de valabilitate a certificatelor aliniate cu programul de re-acreditare și mențineți un inventar de certificate pentru ca reînnoirile să nu provoace întreruperi neașteptate.

Gestionarea imaginilor de containere și a artefactelor

Extrageți toate imaginile necesare — Kafka, stiva de monitorizare și orice plugin-uri Kafka Connect — pe o mașină conectată la internet, exportați-le cu docker save, transferați-le în mediul air-gapped folosind o diodă de date aprobată sau procesul de suport media portabil și încărcați-le într-un registru local cu docker load. Fixați etichetele imaginilor la digest-uri specifice în manifestele de implementare pentru a preveni modificări neașteptate dacă registrul local este actualizat. Pentru mai multe detalii despre implementările Kubernetes air-gapped în contexte de apărare, consultați articolul despre modele de implementare air-gapped pentru apărare.

Azure Event Hubs ca alternativă compatibilă Kafka

Nu orice sarcină de lucru din apărare necesită un cluster complet deconectat, auto-gestionat. Pentru programele care operează în limitele GovCloud — Azure Government, IL4 sau IL5 — nivelurile Premium și Dedicated ale Azure Event Hubs oferă un endpoint compatibil Kafka care acceptă producătorii și consumatorii Kafka standard fără modificări de cod. Suprafața protocolului este compatibilă cu bibliotecile client Kafka 1.0 și ulterior.

Event Hubs în Azure Government satisface autorizarea FedRAMP High și, pentru nivelul Dedicated, suportă chei gestionate de client prin Azure Key Vault Managed HSM, oferind controlul de criptare AES-256 în repaus pe care sarcinile de lucru clasificate îl necesită. Beneficiul operațional este semnificativ: fără provizionare de brokeri, fără rotarea certificatelor pentru clusterul în sine, geo-redundanță încorporată și disponibilitate garantată prin SLA.

Compromisul este clar: Event Hubs nu suportă suprafața completă a API-ului Kafka (fără tranzacții, fără semantică exactly-once între subiecte la nivelul brokerului și fără model ACL personalizat dincolo de RBAC la nivel de spațiu de numere). Iar pentru sarcinile de lucru care trebuie să fie complet air-gapped — fără conectivitate la nicio rețea externă — Event Hubs nu este o opțiune. Pentru acele programe, clusterele KRaft auto-găzduite rămân singura cale viabilă.

Integrarea zero-trust pentru consumatorii Kafka

Modelul ACL al Kafka este un control de securitate necesar, dar nu suficient, într-un mediu zero-trust. Fiecare serviciu consumator ar trebui să se autentifice folosind o credențială de scurtă durată emisă de furnizorul de identitate la pornirea pod-ului sau procesului, mai degrabă decât o parolă statică de lungă durată. Motorul de secrete Kafka al Vault poate emite dinamic credențiale SCRAM de scurtă durată, cu revocare automată la expirarea contractului de închiriere. Combinat cu certificate de client mTLS rotite conform unui program, aceasta asigură că o credențială de cont de serviciu compromisă are o fereastră operațională limitată pentru un atacator.

Aplicați politici de rețea la nivelul Kubernetes sau al firewall-ului pentru a asigura că numai pod-urile cu etichetele corecte pot ajunge la porturile brokerului Kafka. ACL-urile native ale Kafka ar trebui să fie a doua linie de apărare, nu prima. Pentru o tratare completă a arhitecturii zero-trust aplicate rețelelor de apărare, consultați articolul despre arhitectura zero-trust pentru rețelele militare.

Corvus.Quantum: streaming bazat pe Kafka cu criptare post-cuantică

Corvus.Quantum este o platformă de streaming de evenimente testată în luptă, construită pe Kafka, implementată operațional în Ucraina pentru procesarea în timp real a datelor de apărare. Extinde Kafka standard cu criptare post-cuantică la nivelul aplicației — folosind CRYSTALS-Kyber pentru încapsularea cheilor și AES-256-GCM pentru criptarea conținutului — astfel încât mesajele sunt protejate atât împotriva interceptării actuale de către adversari, cât și împotriva atacurilor viitoare de decriptare cuantică. Aceasta abordează amenințarea „recoltează acum, decriptează mai târziu", deosebit de relevantă pentru datele de semnale și ISR cu o durată lungă de sensibilitate.

Dincolo de criptare, Corvus.Quantum oferă o configurație de broker pre-întărită pentru implementări clasificate: șabloane de cluster în modul KRaft, automatizarea certificatelor TLS 1.3 folosind o instanță step-ca integrată, rotarea credențialelor SCRAM integrată cu HashiCorp Vault și șabloane ACL de subiecte conștiente de clasificare. Platforma a fost validată în medii fără conectivitate la internet, gestionând mii de evenimente de senzori pe secundă cu latență end-to-end sub 100 ms.

Pentru echipele de achiziție care evaluează Kafka pentru programele de apărare, Corvus.Quantum reduce efortul de inginerie pentru securizarea unui cluster Kafka de la luni la zile, oferind în același timp o linie de bază de configurare auditabilă care se aliniază cu cerințele CNSA 2.0 și suportă integrarea cu soluțiile cross-domain existente.

Articole conexe

• Arhitectura zero-trust pentru rețelele militare
• Modele de implementare air-gapped pentru sarcinile de lucru din apărare
• Criptografia post-cuantică și conformitatea CNSA 2.0 pentru apărare