Arhitectura data lake pentru apărare: de la ingestia senzorilor la interogarea analiștilor

O organizație modernă de apărare generează date la o rată care depășește capacitățile bazelor de date tradiționale. O singură platformă ISR produce gigabyți de imagini pe misiune. Un convoi cu senzori denși generează mii de rapoarte de poziție CoT pe minut. O singură sesiune de colectare SIGINT poate produce terabyți de date brute I/Q înainte ca orice procesare de semnal să fi avut loc. Înmulțiți aceste volume la scara unei întregi forțe comune — sute de platforme, zeci de tipuri de senzori, niveluri multiple de clasificare — și problema rezultată nu mai este o problemă de baze de date. Este o problemă de data lake.

Acest articol parcurge arhitectura completă a unui data lake pentru apărare: cum intră datele, cum sunt stocate și structurate, cum sunt aplicate granițele de clasificare, cum le interogează analiștii și cum sunt retrase în siguranță datele clasificate. Modelele descrise aici se aplică indiferent dacă construiți un sistem clasificat on-premises, o implementare hibridă sau o platformă de analiză conectată la cloud la nivelul neclasificat sau controlat-neclasificat.

De ce bazele de date tradiționale nu pot gestiona datele de apărare la scară

Bazele de date relaționale sunt proiectate în jurul unor scheme structurate, bine definite. Excelează în sarcini tranzacționale — creare, citire, actualizare și ștergere de înregistrări cu garanții puternice de consistență. Majoritatea datelor provenite de la senzori de apărare nu se încadrează în niciunul dintre aceste tipare. Ele sosesc în formate eterogene: XML CoT de la trupe terestre, fișiere binare de pistă radar, video comprimat de la UAV-uri, JSON din pipeline-uri de radio definit prin software, rapoarte PDF de informații și transcrieri audio din monitorizarea comunicațiilor. Forțarea tuturor acestora într-o schemă relațională normalizată nu este doar practic imposibilă din punct de vedere operațional — distruge fidelitatea brută la care analiștii uneori trebuie să se întoarcă.

Bazele de date NoSQL rezolvă problema schemei, dar introduc altele noi: cele mai multe nu sunt proiectate pentru tiparele de interogare analitică pe care le impune activitatea de informații (scanări complete de tabele, agregări peste milioane de înregistrări, căutări de similaritate vectorială peste reprezentări de documente). Bazele de date de serii temporale gestionează bine fluxurile de senzori cu frecvență ridicată, dar cedează sub îmbinările analitice ad-hoc. Modelul data lake pentru apărare abordează toate aceste lacune prin separarea preocupărilor de ingestie, stocare și interogare în straturi scalabile independent.

Stratul de ingestie: streaming versus batch

Stratul de ingestie este locul unde datele brute intră în data lake. Două modele distincte domină mediile de apărare, iar un data lake de producție are nevoie de ambele.

Ingestie în streaming

Fluxurile de senzori în timp real — rapoarte de poziție, piste radar, alerte de informații despre semnale, mesaje de chat, evenimente de analiză video — sosesc continuu și trebuie ingerate cu latență redusă. Apache Kafka este alegerea open-source dominantă pentru mediile on-premises și air-gapped. Topicurile Kafka se mapează natural la surse de date: un topic per tip de senzor sau flux. Listele de control al accesului (ACL) la nivel de topic oferă o primă linie de aplicare a clasificării — un flux de senzori clasificat Secret ajunge într-un topic clasificat Secret, iar doar consumatorii cu credențiale corespunzătoare se pot abona.

Pentru implementările hibride sau conectate la cloud, Azure Event Hubs oferă o suprafață de API compatibilă cu Kafka cu integrare nativă în Azure Data Lake Storage Gen2 și Azure Synapse Analytics. Event Hubs Capture scrie evenimentele primite direct în ADLS Gen2 în format Avro sau Parquet, eliminând un proces separat de consum pentru zona de aterizare brută. Costurile operaționale sunt semnificativ mai mici față de Kafka auto-administrat, cu prețul unui control redus asupra politicilor de acces la nivel de topic.

Registrele de scheme — fie Confluent Schema Registry (pentru Kafka), fie Azure Schema Registry — ar trebui să fie obligatorii pentru ingestia în streaming. Înregistrarea schemelor la punctul de intrare previne propagarea mesajelor malformate în aval și oferă un contract versionat pentru evoluția schemei. O actualizare de firmware a senzorului care modifică numele unui câmp sau adaugă noi câmpuri de telemetrie nu ar trebui să perturbe niciodată în mod silențios analitice din aval.

Ingestie batch

Nu toate datele de apărare sosesc în timp real. Exporturile zilnice de rezumate de informații, înregistrările de semnale arhivate, bazele de date istorice de piste și datele importate din sistemele aliate sosesc de obicei ca transferuri în bloc pe un program definit. Pipeline-urile de ingestie batch sunt mai simple decât cele de streaming, dar aduc propriile provocări: fișierele pot sosi în formate vechi (imagini NITF, STANAG 4607 GMTI, exporturi CSV din sisteme C2 îmbătrânite), iar dimensiunile fișierelor pot varia de la kilobyți la sute de gigabyți per transfer.

Un strat robust de ingestie batch necesită detectarea și validarea formatului la punctul de intrare, verificarea sumei de control pentru a confirma integritatea transferului și o cale de tip dead-letter pentru fișierele care eșuează la validare. Ingestia ar trebui să fie idempotentă — rularea aceluiași job batch de două ori nu ar trebui să duplice înregistrările în zona structurată. Jurnalul de tranzacții al Delta Lake face ingestia batch idempotentă simplă: joburile de scriere verifică jurnalul de tranzacții înainte de adăugare, iar detectarea duplicatelor poate fi implementată cu o cheie de rând deterministă derivată din identificatorii sistemului sursă și timestamp-uri.

Stratul de stocare: de la zona de aterizare la zona structurată

Un data lake pentru apărare utilizează un model de stocare multi-zonă. Datele se mișcă prin zone pe măsură ce sunt validate, transformate și puse la dispoziție pentru analiză.

Zona de aterizare brută

Zona de aterizare brută este prima destinație pentru toate datele primite — evenimentele de streaming scrise ca fișiere Avro sau JSON line, transferurile batch stocate în formatul lor original. Nimic nu este modificat aici. Zona de aterizare este un registru criminalistic: dacă o eroare de procesare corupe un set de date din aval, zona de aterizare brută este punctul de recuperare. Stocarea constă în obiect-stocare compatibilă S3 — AWS S3, Azure Data Lake Storage Gen2, MinIO pentru implementări on-premises air-gapped sau Ceph pentru stocarea pe obiecte on-premises la scară largă.

Obiectele din zona de aterizare sunt denumite cu o schemă deterministă de chei care codifică sistemul sursă, nivelul de clasificare, tipul de date și timestamp-ul de sosire. O convenție de denumire de tipul raw/{classification}/{source}/{year}/{month}/{day}/{hour}/{uuid}.{ext} oferă pipeline-ului de transformare o structură de partiționare fiabilă și face posibilă reprelucrarea unui anumit interval de timp pentru o singură sursă fără a atinge date necorelate.

Zona structurată: Parquet și Delta Lake

Zona structurată este locul unde datele brute sunt transformate într-un format pe care motoarele analitice îl pot interoga eficient. Standardul actual constă în fișiere Parquet colunare gestionate de un strat de format de tabel Delta Lake sau Apache Iceberg. Structura colunară a Parquet reduce dramatic I/O pentru interogările analitice care accesează doar un subset de câmpuri — ceea ce reprezintă norma pentru analiza informațiilor. O interogare pentru toate pistele aeriene dintr-un rază de 50 km pe o fereastră de șase ore necesită doar coloanele de latitudine, longitudine, altitudine, timestamp și ID pistă, nu schema completă de 80 de câmpuri a senzorului.

Delta Lake adaugă patru capabilități critice într-un mediu clasificat. În primul rând, tranzacțiile ACID asigură că scrierile simultane din multiple joburi Spark nu produc seturi de date parțiale sau corupte. În al doilea rând, jurnalul de tranzacții oferă un istoric complet al fiecărei operațiuni de scriere, actualizare și ștergere — o cerință pentru proveniența datelor în sistemele clasificate. În al treilea rând, interogările time-travel permit analiștilor să reconstituie starea unui set de date la orice moment din trecut, ceea ce susține atât analiza criminalistică, cât și revizuirea post-acțiune. În al patrulea rând, aplicarea schemei previne ca erorile de ingestie din aval să scrie înregistrări malformate în tăcere într-un tabel de producție.

Izolarea clasificării

Granițele de clasificare trebuie aplicate la stratul de stocare, nu doar la stratul aplicației. Fiecare nivel de clasificare (Neclasificat, Informații Controlate Neclasificate, Confidențial, Secret, Strict Secret/SCI) necesită bucketuri sau spații de nume de stocare separate fizic. Bucketurile partajate cu separare bazată pe cale nu sunt suficiente — o politică IAM configurată greșit sau o eroare software în stratul de control al accesului poate expune date între niveluri de clasificare dacă obiectele partajează același bucket.

Fiecare nivel de clasificare utilizează o cheie de criptare separată a datelor (DEK) gestionată de un modul de securitate hardware (HSM) sau un serviciu de gestionare a cheilor cu certificare FIPS 140-2 Nivel 3. Criptarea este aplicată pe server la stratul de stocare, astfel încât chiar și îndepărtarea suportului de stocare să nu expună date în text clar. Programele de rotație a cheilor sunt definite per nivel de clasificare și trebuie automatizate — rotația manuală a cheilor la frecvența necesară pentru datele clasificate este practic imposibilă din punct de vedere operațional.

Catalogul de date și aplicarea clasificării

Un data lake fără catalog este o mlaștină de date. Analiștii de apărare trebuie să descopere ce seturi de date există, ce conțin, când au fost ultima oară actualizate și ce nivel de clasificare poartă — înainte de a emite o interogare care ar putea solicita inadvertent date deasupra autorizației lor. Un catalog de metadate servește drept index căutabil al conținutului lacului.

Apache Atlas (implementat în mod obișnuit cu stive ale ecosistemului Hadoop) și AWS Glue Data Catalog (pentru implementări cloud sau hibride) sunt cele două opțiuni cele mai utilizate. Ambele suportă înregistrarea schemei, urmărirea liniei de date și atribute de metadate personalizate. Nivelul de clasificare ar trebui să fie un atribut obligatoriu al schemei — nu o etichetă opțională — astfel încât fiecare set de date din catalog să aibă o etichetă explicită de clasificare pe care stratul de interogare o poate aplica.

Vizibilitatea catalogului ar trebui să respecte ea însăși politica de acces: un analist autorizat pentru Secret nu ar trebui să poată naviga prin intrările din catalog pentru seturi de date Strict Secrete, chiar dacă nu poate interoga datele de bază. Aceasta necesită integrarea stratului de autorizare al catalogului cu furnizorul de identitate al organizației (Active Directory, LDAP sau un IdP compatibil SAML). Fiecare eveniment de acces la catalog ar trebui înregistrat într-un sink central de audit alături de evenimentele de interogare.

Stratul de interogare: SQL, analiticș batch și căutare vectorială

Stratul de interogare este locul unde analiștii și sistemele din aval consumă date din data lake. Un data lake de producție pentru apărare are nevoie de cel puțin trei modalități de interogare.

SQL ad-hoc cu Trino

Trino (cunoscut anterior ca PrestoSQL) este alegerea standard pentru interogări SQL ad-hoc pe seturi de date Parquet sau Delta Lake de mari dimensiuni. Arhitectura de conectori a Trino permite unei singure interogări să îmbine date din multiple surse — zona structurată Delta Lake, o bază de date operațională PostgreSQL live și un index Elasticsearch — într-o singură instrucțiune SQL. Pentru analitice de apărare, aceasta înseamnă că un analist poate scrie o interogare care corelează datele istorice de piste din data lake cu rapoartele de contact live din imaginea operațională fără a exporta date între sisteme.

Stratul de control al accesului al Trino suportă filtrarea la nivel de rând și mascarea coloanelor prin politici la nivel de conector. Un filtru de rând poate restricționa o interogare doar la înregistrările care se potrivesc cu aria geografică de responsabilitate autorizată a analistului. Mascarea coloanelor poate redacta câmpurile sensibile — identificatorii sistemului sursă, codurile metodei de colectare — pentru analiștii a căror autorizare nu se extinde la acele metadate. Toate evenimentele de interogare sunt înregistrate într-un sink de audit care captează textul interogării, identitatea utilizatorului autentificat, tabelele accesate și nivelul de clasificare al datelor returnate.

Analiticș batch la scară largă cu Spark

Unele sarcini de analiză a informațiilor sunt prea mari pentru SQL interactiv. Analiza tiparelor de comportament pe șase luni de date de poziție, corelarea informațiilor despre semnale cu mișcările terestre pe un întreg teatru de operațiuni sau antrenarea unui model de învățare automată pe date de pistă etichetate necesită toate procesare batch distribuită. Apache Spark rulând pe un cluster YARN sau Kubernetes este motorul standard pentru aceste sarcini de lucru.

Spark se integrează nativ cu Delta Lake și poate citi Parquet direct din stocarea pe obiecte compatibilă S3. Pentru mediile clasificate, joburile Spark ar trebui să ruleze în clustere sau spații de nume izolate per nivel de clasificare, astfel încât un job de nivel Secret să nu poată face referire accidentală la un set de date neclasificat printr-o variabilă de cale configurată greșit. Execuția jobului ar trebui înregistrată cu același nivel de detaliu de audit ca și interogările interactive: proprietarul jobului, nivelul de clasificare al seturilor de date de intrare, nivelul de clasificare al seturilor de date de ieșire și timestamp-ul de execuție.

Căutare vectorială pentru documente de informații

Documentele nestructurate de informații — rapoarte, transcrieri, intercepte traduse — nu se potrivesc bine cu tiparele de interogare SQL. Analiștii au nevoie de căutare semantică: „găsește toate rapoartele care discută perturbarea rutei de aprovizionare lângă această referință de grilă" mai degrabă decât „găsește toate înregistrările unde document_text LIKE '%ruta de aprovizionare%'." Reprezentările vectoriale generate de un model de limbaj și stocate într-o bază de date vectorială (pgvector pe PostgreSQL sau un serviciu dedicat ca Qdrant pentru implementări on-premises) permit acest tip de recuperare semantică.

Stratul de căutare vectorială trebuie să respecte granițele de clasificare în același mod ca straturile SQL și Spark. Pipeline-urile de generare a reprezentărilor ar trebui să ruleze în nivelul de clasificare al documentelor sursă, iar indexurile vectoriale rezultate ar trebui izolate per nivel de clasificare. Căutarea semantică între niveluri de clasificare — găsirea de documente neclasificate similare tematic cu o interogare clasificată — necesită o revizuire explicită a arhitecturii de soluție cross-domain (CDS) și nu este o capabilitate implicită.

Retenție, ștergere și jurnal de audit

Datele dintr-un data lake pentru apărare nu se acumulează la nesfârșit. Politicile de retenție bazate pe clasificare definesc cât timp se păstrează fiecare tip de date la fiecare nivel de clasificare. Datele operaționale de la senzori ar putea avea o retenție de 90 de zile la nivel Secret; produsele de informații strategice ar putea fi reținute timp de 10 ani. Politicile de retenție sunt definite într-un registru de politici și aplicate de joburi automate de gestionare a ciclului de viață care rulează conform unui program definit.

Ștergerea securizată a datelor clasificate nu se poate baza pe ștergerea standard a sistemului de fișiere sau expirarea obiectelor. Ștergerea standard marchează blocurile de stocare ca disponibile pentru reutilizare, dar nu le suprascrie. Pentru datele clasificate, abordarea necesară este ștergerea criptografică, numită și crypto-shredding: fiecare nivel de clasificare utilizează o DEK separată, iar când o politică de retenție declanșează ștergerea, DEK este rotită și versiunea anterioară a cheii este distrusă. Fără DEK, textul cifrat stocat este indistinguibil computațional de zgomotul aleatoriu. Această abordare se scalează la seturi de date de ordinul petabyților fără penalitatea de performanță a procedurilor de suprascriere cu mai multe treceri.

Fiecare eveniment de curățare trebuie să producă o intrare imutabilă în jurnalul de audit. Intrarea de audit trebuie să înregistreze cheile obiectelor sau identificatorii de partiție care au fost curățați, regula de retenție care a declanșat curățarea, timestamp-ul distrugerii cheii și identitatea principalului automatizat sau uman care a autorizat operațiunea. Jurnalul de audit în sine trebuie stocat într-o configurație write-once, tamper-evident — bucket S3 append-only cu object lock sau un serviciu dedicat de jurnal de audit cu înlănțuire criptografică.

Pentru mai multe detalii despre modul în care cozile de mesaje susțin stratul de ingestie în streaming descris aici, consultați articolul nostru despre arhitectura cozilor de mesaje pentru date de apărare cu debit ridicat. Pentru modelele de fuziune care operează asupra datelor odată ce acestea ajung în zona structurată, consultați ghidul nostru de arhitectură de fuziune multi-senzor.

Considerații operaționale

Un data lake pentru apărare nu este o infrastructură care se configurează o singură dată și se uită. Mai multe preocupări operaționale merită atenție explicită în timpul arhitecturii și achiziției.

Compatibilitate air-gap. Multe implementări clasificate nu pot menține conectivitate internet persistentă. Toate componentele stivei data lake — Kafka, Spark, Trino, serviciul de catalog, magazinul vectorial — trebuie să fie implementabile din oglinzi locale de pachete și registre de containere. Dependența de depozitele publice de pachete în timpul execuției reprezintă un risc de securitate și disponibilitate în mediile clasificate.

Guvernanța evoluției schemei. Actualizările firmware ale senzorilor, noile integrări de platforme și cerințele de raportare în schimbare vor modifica schemele de date în timp. Modificările de schemă în zona structurată trebuie să treacă printr-un proces de control al modificărilor care evaluează impactul din aval: modificarea afectează interogările Trino existente? Necesită o reprelucrare a datelor istorice? Controalele de evoluție a schemei din Delta Lake (opțiunea mergeSchema) și versionarea încorporată a schemei din Iceberg oferă mecanismele tehnice, dar procesul de guvernanță din jurul lor este la fel de important.

Monitorizarea performanței per nivel de clasificare. Performanța interogărilor poate diferi semnificativ între nivelurile de clasificare — un analist de Nivel 1 care rulează interogări pe un set de date Secret de ordinul petabyților operează într-un alt profil de performanță față de un analist de Nivel 3 care interogează un set de date mic Neclasificat. Monitorizarea latenței interogărilor, volumului de date scanate și utilizării clusterului per nivel de clasificare permite planificarea capacității să urmărească tiparele de utilizare reale, nu vârfurile teoretice.