Architektura data lake w obronie: od pozyskiwania danych z sensorów do zapytań analitycznych

Nowoczesna organizacja obronna generuje dane w tempie, które łamie tradycyjne założenia dotyczące baz danych. Pojedyncza platforma ISR produkuje gigabajty zobrazowania na jeden lot. Konwój wyposażony w gęstą sieć sensorów generuje tysiące raportów pozycji CoT na minutę. Pojedyncza sesja zbierania SIGINT może wygenerować terabajty surowych danych I/Q zanim nastąpi jakiekolwiek przetwarzanie sygnału. Pomnóż te wolumeny przez całe zgrupowanie sił połączonych – setki platform, dziesiątki typów sensorów, wiele poziomów klasyfikacji – a wynikający problem z danymi przestaje być problemem bazy danych. To jest problem data lake.

Niniejszy artykuł omawia pełną architekturę obronnego data lake: jak dane są przyjmowane, jak są przechowywane i strukturyzowane, jak egzekwowane są granice klasyfikacji, jak analitycy je odpytują i jak dane niejawne są bezpiecznie wycofywane. Opisane wzorce mają zastosowanie zarówno przy budowie niejawnego systemu lokalnego, wdrożenia hybrydowego, jak i chmurowej platformy analitycznej na poziomie jawnym lub kontrolowanym niejawnym.

Dlaczego tradycyjne bazy danych nie radzą sobie z obronnymi danymi w skali

Relacyjne bazy danych są zaprojektowane wokół ustrukturyzowanych, dobrze zdefiniowanych schematów. Doskonale sprawdzają się w obciążeniach transakcyjnych – tworzeniu, odczycie, aktualizacji i usuwaniu rekordów z silnymi gwarancjami spójności. Większość obronnych danych sensorowych nie posiada żadnej z tych cech. Docierają w heterogenicznych formatach: XML CoT od wojsk lądowych, binarne pliki tras radarowych, skompresowane wideo z systemów bezzałogowych, JSON z potoków radia programowego, raporty wywiadowcze w PDF oraz transkrypty audio z monitoringu komunikacji. Wymuszanie takiej różnorodności w znormalizowanym schemacie relacyjnym jest nie tylko operacyjnie niepraktyczne – niszczy surową wierność danych, do której analitycy muszą czasem wracać.

Bazy danych NoSQL rozwiązują problem schematu, ale wprowadzają nowe: większość nie jest zaprojektowana dla wzorców zapytań analitycznych, jakich wymaga praca wywiadowcza (pełne skany tabel, agregacje po milionach rekordów, wyszukiwanie podobieństwa wektorowego po osadzeniach dokumentów). Bazy szeregów czasowych dobrze obsługują wysokoczęstotliwościowe strumienie sensorów, lecz nie radzą sobie z ad-hoc złączeniami analitycznymi. Wzorzec obronnego data lake rozwiązuje wszystkie te braki, rozdzielając pozyskiwanie danych, magazynowanie i warstwę zapytań na niezależnie skalowalne poziomy.

Warstwa pozyskiwania: strumieniowanie kontra wsad

Warstwa pozyskiwania to miejsce, gdzie surowe dane trafiają do jeziora. W środowiskach obronnych dominują dwa odrębne wzorce, a produkcyjny data lake potrzebuje obu.

Strumieniowe pozyskiwanie danych

Strumienie sensorów w czasie rzeczywistym – raporty pozycji, ślady radarowe, alerty wywiadu sygnałowego, wiadomości czatu, zdarzenia analityki wideo – napływają nieprzerwanie i muszą być pozyskiwane z małym opóźnieniem. Apache Kafka jest dominującym wyborem open-source dla środowisk lokalnych i izolowanych od sieci. Tematy Kafka naturalnie mapują się na źródła danych: jeden temat na typ sensora lub strumień. Listy kontroli dostępu (ACL) na poziomie tematu stanowią pierwszą linię egzekwowania klasyfikacji – niejawny strumień z czujnika trafia do niejawnego tematu, a subskrybować mogą tylko konsumenci z odpowiednimi uprawnieniami.

W wdrożeniach hybrydowych lub połączonych z chmurą, Azure Event Hubs oferuje powierzchnię API kompatybilną z Kafka z natywną integracją z Azure Data Lake Storage Gen2 i Azure Synapse Analytics. Funkcja Event Hubs Capture zapisuje przychodzące zdarzenia bezpośrednio do ADLS Gen2 w formacie Avro lub Parquet, eliminując oddzielny proces konsumenta dla surowej strefy lądowania. Koszty operacyjne są znacznie niższe niż w przypadku samodzielnie zarządzanej Kafka, kosztem zmniejszonej kontroli nad politykami dostępu na poziomie tematów.

Rejestry schematów – Confluent Schema Registry (dla Kafka) lub Azure Schema Registry – powinny być obowiązkowe przy strumieniowym pozyskiwaniu danych. Rejestrowanie schematów w punkcie wejścia zapobiega propagacji zniekształconych wiadomości w dół potoku i zapewnia wersjonowany kontrakt dla ewolucji schematów. Aktualizacja oprogramowania układowego sensora, która zmienia nazwę pola lub dodaje nowe pola telemetryczne, nigdy nie powinna po cichu niszczyć analityki w dalszym etapie.

Wsadowe pozyskiwanie danych

Nie wszystkie obronne dane docierają w czasie rzeczywistym. Dzienne zrzuty podsumowań wywiadowczych, archiwalne nagrania sygnałów, historyczne bazy tras i dane importowane z systemów sojuszniczych zazwyczaj przychodzą jako transfery masowe w zdefiniowanym harmonogramie. Potoki wsadowego pozyskiwania są prostsze niż strumieniowe, ale niosą własne wyzwania: pliki mogą przychodzić w starszych formatach (zobrazowanie NITF, STANAG 4607 GMTI, eksporty CSV ze starzejących się systemów C2), a rozmiary plików mogą wahać się od kilobajtów do setek gigabajtów na transfer.

Solidna warstwa wsadowego pozyskiwania potrzebuje wykrywania formatów i walidacji w punkcie wejścia, weryfikacji sum kontrolnych w celu potwierdzenia integralności transferu oraz ścieżki „martwych listów" dla plików, które nie przeszły walidacji. Pozyskiwanie powinno być idempotentne – dwukrotne uruchomienie tego samego zadania wsadowego nie powinno duplikować rekordów w strefie ustrukturyzowanej. Dziennik transakcji Delta Lake sprawia, że idempotentne wsadowe pozyskiwanie jest proste: zadania zapisu sprawdzają dziennik transakcji przed dołączeniem danych, a wykrywanie duplikatów można zaimplementować za pomocą deterministycznego klucza wiersza wywodzonego z identyfikatorów systemu źródłowego i znaczników czasu.

Warstwa magazynowania: od strefy lądowania do strefy ustrukturyzowanej

Obronny data lake stosuje wielostrefowy model magazynowania. Dane przechodzą przez strefy w miarę ich walidacji, transformacji i udostępniania do analizy.

Surowa strefa lądowania

Surowa strefa lądowania jest pierwszym celem dla wszystkich przychodzących danych – zdarzenia strumieniowe zapisywane jako pliki Avro lub JSON, transfery wsadowe przechowywane w oryginalnym formacie. Nic nie jest tutaj modyfikowane. Strefa lądowania jest zapisem kryminalistycznym: jeśli błąd przetwarzania uszkodzi dalszy zbiór danych, surowa strefa lądowania jest punktem odzyskiwania. Magazynowanie odbywa się na kompatybilnym z S3 magazynie obiektowym – AWS S3, Azure Data Lake Storage Gen2, MinIO dla lokalnych wdrożeń izolowanych od sieci lub Ceph dla wielkoskalowego lokalnego magazynowania obiektowego.

Obiekty w strefie lądowania są nazwane deterministycznym schematem kluczy, który koduje system źródłowy, poziom klasyfikacji, typ danych i znacznik czasu przybycia. Konwencja nazewnictwa taka jak raw/{classification}/{source}/{year}/{month}/{day}/{hour}/{uuid}.{ext} daje potokom transformacji niezawodną strukturę partycjonowania i umożliwia ponowne przetworzenie określonego okna czasowego dla jednego źródła bez dotykania niepowiązanych danych.

Strefa ustrukturyzowana: Parquet i Delta Lake

Strefa ustrukturyzowana to miejsce, gdzie surowe dane są przekształcane w format, który silniki analityczne mogą efektywnie odpytywać. Aktualnym standardem są kolumnowe pliki Parquet zarządzane przez warstwę formatu tabeli Delta Lake lub Apache Iceberg. Kolumnowy układ Parquet drastycznie zmniejsza operacje I/O dla zapytań analitycznych, które uzyskują dostęp tylko do podzbioru pól – co jest normą w analizie wywiadowczej. Zapytanie o wszystkie ślady powietrzne w promieniu 50 km przez sześć godzin potrzebuje tylko kolumn szerokości, długości, wysokości, znacznika czasu i identyfikatora śladu – nie całego 80-polowego schematu sensora.

Delta Lake dodaje cztery możliwości, które są krytyczne w środowisku niejawnym. Po pierwsze, transakcje ACID zapewniają, że współbieżne zapisy z wielu zadań Spark nie produkują częściowych ani uszkodzonych zbiorów danych. Po drugie, dziennik transakcji zapewnia pełną historię każdej operacji zapisu, aktualizacji i usunięcia – wymóg dla proweniencji danych w systemach niejawnych. Po trzecie, zapytania podróży w czasie pozwalają analitykom odtworzyć stan zbioru danych w dowolnym przeszłym momencie, co wspiera zarówno analizę kryminalistyczną, jak i przegląd po akcji. Po czwarte, wymuszanie schematów zapobiega cichemu zapisywaniu zniekształconych rekordów do tabeli produkcyjnej przez błędy pozyskiwania w dalszym etapie.

Izolacja klasyfikacji

Granice klasyfikacji muszą być egzekwowane na warstwie magazynowania, a nie tylko na poziomie aplikacji. Każdy poziom klasyfikacji (Jawne, Kontrolowane informacje jawne, Poufne, Tajne, Ściśle tajne/SCI) wymaga fizycznie oddzielnych zasobników lub przestrzeni nazw. Wspólne zasobniki z separacją opartą na ścieżkach są niewystarczające – błędnie skonfigurowana polityka IAM lub błąd oprogramowania w warstwie kontroli dostępu może ujawnić dane między klasyfikacjami, jeśli obiekty dzielą ten sam zasobnik.

Każdy poziom klasyfikacji używa oddzielnego klucza szyfrowania danych (DEK) zarządzanego przez sprzętowy moduł bezpieczeństwa (HSM) lub usługę zarządzania kluczami z certyfikatem FIPS 140-2 Level 3. Szyfrowanie jest stosowane po stronie serwera na warstwie magazynowania, tak aby nawet usunięcie nośnika pamięci masowej nie ujawniło danych w postaci jawnej. Harmonogramy rotacji kluczy są zdefiniowane dla każdego poziomu klasyfikacji i muszą być zautomatyzowane – ręczna rotacja kluczy z częstotliwością wymaganą dla danych niejawnych jest operacyjnie niepraktyczna.

Katalog danych i egzekwowanie klasyfikacji

Data lake bez katalogu to data swamp (bagno danych). Analitycy obroni muszą wiedzieć, jakie zbiory danych istnieją, co zawierają, kiedy były ostatnio aktualizowane i jaki poziom klasyfikacji mają – zanim wydadzą zapytanie, które mogłoby nieumyślnie zażądać danych powyżej ich uprawnień. Katalog metadanych służy jako przeszukiwalny indeks zawartości jeziora.

Apache Atlas (powszechnie wdrażany ze stosami ekosystemu Hadoop) i AWS Glue Data Catalog (dla wdrożeń chmurowych lub hybrydowych) to dwa najszerzej stosowane opcje. Obie obsługują rejestrację schematów, śledzenie linii danych i niestandardowe atrybuty metadanych. Poziom klasyfikacji powinien być obowiązkowym atrybutem schematu – nie opcjonalnym tagiem – tak aby każdy zbiór danych w katalogu miał wyraźną etykietę klasyfikacji, którą warstwa zapytań może egzekwować.

Widoczność katalogu powinna sama respektować politykę dostępu: analityk z poświadczeniami na poziomie Tajnym nie powinien móc przeglądać wpisów katalogu dla zbiorów danych Ściśle tajnych, nawet jeśli nie może odpytywać danych bazowych. Wymaga to integracji warstwy autoryzacji katalogu z dostawcą tożsamości organizacji (Active Directory, LDAP lub IdP kompatybilny z SAML). Każde zdarzenie dostępu do katalogu powinno być rejestrowane w centralnym systemie audytowym obok zdarzeń zapytań.

Warstwa zapytań: SQL, analityka wsadowa i wyszukiwanie wektorowe

Warstwa zapytań to miejsce, gdzie analitycy i systemy niższego szczebla konsumują dane z jeziora. Produkcyjny obronny data lake potrzebuje co najmniej trzech modalności zapytań.

Ad-hoc SQL z Trino

Trino (dawniej PrestoSQL) jest standardowym wyborem dla ad-hoc zapytań SQL na dużych zbiorach danych Parquet lub Delta Lake. Architektura łączników Trino pozwala pojedynczemu zapytaniu łączyć dane z wielu źródeł – ustrukturyzowanej strefy Delta Lake, aktywnej operacyjnej bazy danych PostgreSQL i indeksu Elasticsearch – w jednej instrukcji SQL. W kontekście analityki obronnej oznacza to, że analityk może napisać zapytanie korelujące historyczne dane tras z jeziora z aktualnymi raportami kontaktów z obrazu operacyjnego bez eksportowania danych między systemami.

Warstwa kontroli dostępu Trino obsługuje filtrowanie na poziomie wierszy i maskowanie kolumn przez polityki na poziomie łącznika. Filtr wierszy może ograniczyć zapytanie wyłącznie do rekordów pasujących do autoryzowanego geograficznego obszaru odpowiedzialności analityka. Maskowanie kolumn może redagować wrażliwe pola – identyfikatory systemu źródłowego, kody metod zbierania – dla analityków, których poświadczenia nie obejmują tych metadanych. Wszystkie zdarzenia zapytań są rejestrowane w systemie audytowym, który przechwytuje tekst zapytania, uwierzytelnioną tożsamość użytkownika, dostępne tabele i poziom klasyfikacji zwróconych danych.

Wielkoskalowa analityka wsadowa z Spark

Niektóre zadania analizy wywiadowczej są zbyt duże dla interakcyjnego SQL. Analiza wzorca życia na podstawie sześciu miesięcy danych pozycyjnych, korelacja wywiadu sygnałowego z ruchami lądowymi na całym teatrze działań wojennych lub trenowanie modelu uczenia maszynowego na etykietowanych danych tras – wszystko to wymaga rozproszonego przetwarzania wsadowego. Apache Spark działający w klastrze YARN lub Kubernetes jest standardowym silnikiem dla tych obciążeń.

Spark integruje się natywnie z Delta Lake i może odczytywać Parquet bezpośrednio z kompatybilnego z S3 magazynu. W środowiskach niejawnych zadania Spark powinny działać w izolowanych według poziomu klasyfikacji klastrach lub przestrzeniach nazw, tak aby zadanie na poziomie Tajnym nie mogło przypadkowo odwołać się do jawnego zbioru danych przez błędnie skonfigurowaną zmienną ścieżki. Wykonanie zadania powinno być rejestrowane z tymi samymi szczegółami audytowymi co interakcyjne zapytania: właściciel zadania, poziom klasyfikacji wejściowych zbiorów danych, poziom klasyfikacji wyjściowych zbiorów danych i znacznik czasu wykonania.

Wyszukiwanie wektorowe dla dokumentów wywiadowczych

Nieustrukturyzowane dokumenty wywiadowcze – raporty, transkrypty, przetłumaczone przechwycenia – nie pasują dobrze do wzorców zapytań SQL. Analitycy potrzebują wyszukiwania semantycznego: „znajdź wszystkie raporty dotyczące zakłóceń na trasie zaopatrzenia w pobliżu tej siatki" zamiast „znajdź wszystkie rekordy, gdzie document_text LIKE '%trasa zaopatrzenia%'." Osadzenia wektorowe generowane przez model językowy i przechowywane w bazie danych wektorowej (pgvector na PostgreSQL lub dedykowana usługa jak Qdrant dla wdrożeń lokalnych) umożliwiają tego rodzaju semantyczne wyszukiwanie.

Warstwa wyszukiwania wektorowego musi respektować granice klasyfikacji w taki sam sposób jak warstwy SQL i Spark. Potoki generowania osadzeń powinny działać w ramach poziomu klasyfikacji dokumentów źródłowych, a wynikowe indeksy wektorowe powinny być izolowane według poziomu klasyfikacji. Semantyczne wyszukiwanie między klasyfikacjami – znajdowanie jawnych dokumentów tematycznie podobnych do niejawnego zapytania – wymaga przeglądu architektury rozwiązania cross-domain (CDS) i nie jest domyślną możliwością.

Retencja, czyszczenie i ścieżka audytowa

Dane w obronnym data lake nie gromadzą się w nieskończoność. Polityki retencji oparte na klasyfikacji definiują, jak długo każdy typ danych jest przechowywany na każdym poziomie klasyfikacji. Operacyjne dane sensorowe mogą mieć 90-dniowy okres retencji na poziomie Tajnym; strategiczne produkty wywiadowcze mogą być przechowywane przez 10 lat. Polityki retencji są zdefiniowane w rejestrze polityk i egzekwowane przez automatyczne zadania zarządzania cyklem życia uruchamiane zgodnie z harmonogramem.

Bezpieczne usuwanie danych niejawnych nie może polegać na standardowym usuwaniu systemu plików ani wygasaniu obiektów. Standardowe usuwanie oznacza bloki pamięci masowej jako dostępne do ponownego użycia, ale ich nie nadpisuje. W przypadku danych niejawnych wymaganym podejściem jest kryptograficzne wymazanie, zwane też crypto-shredding: każdy poziom klasyfikacji używa oddzielnego DEK, a gdy polityka retencji wyzwala usunięcie, DEK jest rotowany, a poprzednia wersja klucza jest niszczona. Bez DEK przechowywany szyfrotekst jest obliczeniowo nie do odróżnienia od losowego szumu. Podejście to skaluje się do zbiorów petabajtowych bez kary wydajnościowej procedur wielokrotnego nadpisywania.

Każde zdarzenie czyszczenia musi tworzyć niezmienialny wpis dziennika audytu. Wpis audytowy musi rejestrować klucze obiektów lub identyfikatory partycji, które zostały wyczyszczone, regułę retencji, która wyzwoliła czyszczenie, znacznik czasu zniszczenia klucza oraz tożsamość zautomatyzowanego lub ludzkiego administratora, który autoryzował operację. Sam dziennik audytu musi być przechowywany w konfiguracji jednokrotnego zapisu i odpornej na manipulacje – zasobnik S3 z blokadą obiektów lub dedykowana usługa dziennika audytu z kryptograficznym łączeniem.

Więcej szczegółów na temat obsługi kolejek wiadomości przez warstwę strumieniowego pozyskiwania opisaną tutaj znajdziesz w naszym artykule o architekturze kolejki wiadomości dla obronnych danych wysokiej przepustowości. Dla wzorców fuzji działających na danych po dotarciu do strefy ustrukturyzowanej, zapoznaj się z naszym przewodnikiem po architekturze fuzji wielosensorowej.

Zagadnienia operacyjne

Obronny data lake to nie jest infrastruktura „wdróż i zapomnij". Kilka kwestii operacyjnych zasługuje na wyraźną uwagę podczas architektury i zakupów.

Kompatybilność z izolacją sieciową (air-gap). Wiele niejawnych wdrożeń nie może utrzymywać stałej łączności z internetem. Wszystkie komponenty stosu jeziora – Kafka, Spark, Trino, usługa katalogu, magazyn wektorowy – muszą być wdrażalne z lokalnych kopii lustrzanych pakietów i rejestrów kontenerów. Zależność od publicznych repozytoriów pakietów podczas działania jest ryzykiem bezpieczeństwa i dostępności w środowiskach niejawnych.

Zarządzanie ewolucją schematów. Aktualizacje oprogramowania układowego sensorów, nowe integracje platform i zmieniające się wymagania raportowania będą modyfikować schematy danych w czasie. Zmiany schematów w strefie ustrukturyzowanej muszą przechodzić przez proces kontroli zmian, który ocenia wpływ na dalsze etapy: czy zmiana psuje istniejące zapytania Trino? Czy wymaga uzupełnienia danych historycznych? Kontrole ewolucji schematów Delta Lake (opcja mergeSchema) i wbudowane wersjonowanie schematów Iceberg zapewniają mechanizmy techniczne, ale równie ważny jest proces zarządzania wokół nich.

Monitorowanie wydajności per poziom klasyfikacji. Wydajność zapytań może się znacznie różnić między poziomami klasyfikacji – analityk pierwszego szczebla wykonujący zapytania na petabajtowym zbiorze danych na poziomie Tajnym działa w zupełnie innym zakresie wydajnościowym niż analityk trzeciego szczebla odpytujący mały zbiór jawny. Monitorowanie opóźnień zapytań, wolumenu skanowanych danych i wykorzystania klastra per poziom klasyfikacji pozwala planowaniu pojemności śledzić rzeczywiste wzorce użytkowania, a nie teoretyczne szczyty.