Organizacje wywiadu obronnego przez dziesięciolecia gromadziły dane — przechwycenia SIGINT, produkty GEOINT, raporty HUMINT, agregaty OSINT — i konsekwentnie nie potrafiły przekształcić tego nagromadzenia w coś, z czego analitycy mogliby naprawdę korzystać. Problem rzadko leży w zbieraniu. Tkwi w integracji. A organizacyjna przyczyna problemu integracji jest niemal zawsze ta sama: nikt nie jest właścicielem danych. Centralny zespół inżynierii danych, który jest właścicielem potoków danych, nie posiada wiedzy domenowej, aby utrzymać ich poprawność. Komórka SIGINT, która posiada wiedzę domenową, nie ma infrastruktury do publikowania swoich danych w formie, którą inne zespoły mogą konsumować.
Data mesh to wzorzec architektoniczny i organizacyjny, który bezpośrednio rozwiązuje tę pierwotną przyczynę. Opracowany przez Zhamak Dehghani i opisany po raz pierwszy w 2019 roku, przeformułowuje problem danych nie jako wyzwanie technologiczne, ale jako wyzwanie własności. Odpowiedzią nie jest lepsza scentralizowana platforma danych, lecz model federacyjny, w którym zespoły produkujące dane są również odpowiedzialne za ich publikowanie jako konsumowanego produktu.
Czym jest data mesh — i czym nie jest
Data mesh opiera się na czterech zasadach. Pierwsza to własność domenowa: zespół produkujący dane jest odpowiedzialny za udostępnienie ich konsumentom, a nie centralny zespół inżynierski. Druga to dane jako produkt: dane są traktowane z taką samą starannością inżynierską jak oprogramowanie — mają właściciela, wersjonowany schemat, SLA, dokumentację i zdefiniowany interfejs konsumenta. Trzecia to infrastruktura samoobsługowa: centralny zespół platformy dostarcza narzędzia, których potrzebują zespoły domenowe do publikowania i konsumowania produktów danych bez składania wniosków. Czwarta to zarządzanie federacyjne: standardy interoperacyjności są ustalane przez wielodomenowy organ zarządzający, ale ich egzekwowanie jest zautomatyzowane przez platformę.
Kontrast z data lake jest pouczający. Data lake centralizuje zarówno przechowywanie, jak i odpowiedzialność: zespół platformy zbiera wszystko, przechowuje i buduje potoki dla konsumentów. Gdy system zbierania SIGINT zmienia schemat wyjściowy, potok centralnego zespołu się psuje, a nikt tego nie zauważa, dopóki analityk nie zgłosi przestarzałych danych po trzech tygodniach. W data mesh zespół domeny SIGINT jest właścicielem potoku i kontraktu schematu.
Dlaczego scentralizowane architektury zawodzą w wywiadzie obronnym
Problemy, które rozwiązuje data mesh, są dotkliwe w wywiadzie obronnym, ponieważ organizacje te mają cechy, które sprawiają, że scentralizowane architektury danych są szczególnie kruche. Pierwszą są bariery tajności. Centralny zespół inżynierii danych budujący potoki przez wiele poziomów tajności stoi wobec złożoności kontroli dostępu, jakiej komercyjne zespoły nigdy nie napotykają. Drugą są silosy organizacyjne. Organizacje wywiadu obronnego są zbudowane wokół dyscyplin zbierania — HUMINT, SIGINT, GEOINT, OSINT — każda z własną kulturą i narzędziami. Trzecią jest kruchość monolitycznych ETL. Czwartą są spory o własność, których data mesh rozwiązuje przez jawne i kontraktowe przypisanie własności.
Własność domenowa w kontekście wywiadowczym
W obronnym data mesh domeny naturalnie odwzorowują się na dyscypliny INT: HUMINT, SIGINT, GEOINT, MASINT i OSINT stanowią odrębne domeny. Każdy zespół domenowy — komórka zbierania i analizy odpowiedzialna za tę dyscyplinę — jest właścicielem produktów danych, które publikuje w mesh. Własność nie jest formalnym oznaczeniem; niesie konkretne obowiązki: definiowanie kontraktu schematu, utrzymanie potoków zbierania, realizacja SLA (świeżość, dostępność, kompletność), reagowanie na problemy z jakością danych oraz zarządzanie wersjami schematu.
W środowisku niejawnym własność domenowa oznacza również zarządzanie metadanymi tajności dołączonymi do produktów danych. Zespół domeny SIGINT określa poziom tajności każdego produktu, zastrzeżenia dotyczące ujawniania oraz zasady dziedziczenia dla produktów pochodnych. To znaczna odpowiedzialność, ale zespół SIGINT jest wyjątkowo do niej kwalifikowany.
Produkty danych dla wywiadu
Koncepcja produktu danych jest jednostką wymiany w data mesh. Produkt danych to nie surowy zrzut danych ani tabela bazy danych, lecz wyselekcjonowany, udokumentowany i kontraktowo zarządzany interfejs. Cechy definiujące: jest wykrywalny (można go znaleźć w katalogu), adresowalny (można go odpytywać przez stabilny interfejs), godny zaufania (objęty SLA z monitoringiem), samoopisujący się (udokumentowany schemat) i interoperacyjny.
Przykłady: zespół domeny SIGINT może publikować produkt "aktualny obraz tras przeciwnika" — kolekcję GeoJSON aktywnych tras, aktualizowaną co 15 minut, zgodną ze schematem tras MIP4, sklasyfikowaną na poziomie TAJNE. Komórka analizy ELINT może publikować "bazę danych emiterów" — wersjonowany katalog znanych rekordów parametrów emiterów, aktualizowanych w ciągu czterech godzin od nowego zbierania. Komórka GEOINT może publikować "warstwę adnotacji obrazów" — zestaw obiektów relacji STIX2 łączących zaobserwowane obiekty z rekordami encji w bazie danych sił zbrojnych przeciwnika, aktualizowanych w ciągu ośmiu godzin od dostarczenia zamówionych obrazów.
Zarządzanie federacyjne
Zarządzanie federacyjne to mechanizm, który sprawia, że data mesh jest interoperacyjny, a nie zbiorem izolowanych silosów domenowych. Rada zarządzania danymi — z przedstawicielami każdej domeny, zespołu platformy i funkcji prawno-compliance — ustala standardy zarządzania obowiązujące wszystkie zespoły domenowe: wymagania interoperacyjności schematów, konwencje metadanych tajności, wymagania dotyczące metadanych katalogu oraz definicje wskaźników jakości danych.
W kontekście obronnym etykiety tajności funkcjonują jako atrybut zarządzania pierwszej klasy. Każdy produkt danych niesie poziom tajności i zestaw zastrzeżeń dotyczących ujawniania jako obowiązkowe pola metadanych. Platforma samoobsługowa automatycznie egzekwuje te atrybuty. Każde zdarzenie dostępu do danych musi być rejestrowane w niezmiennym dzienniku audytu.
Infrastruktura samoobsługowa dla środowisk niejawnych
Platforma samoobsługowa to to, co odróżnia data mesh od ram koncepcyjnych. W środowisku niejawnym ograniczenia są bardziej wymagające: platforma musi być wdrażana w sieciach z air-gap, działać bez zależności od publicznych interfejsów API chmury i spełniać wymagania akredytacji bezpieczeństwa.
Typowy stos platformy obejmuje: warstwę pamięci masowej obiektowej (MinIO lub Ceph dla wdrożeń z air-gap); rejestr schematów do zarządzania wersjami schematów; usługę katalogu danych (Apache Atlas) do odkrywania i dokumentowania produktów; warstwę kontroli dostępu zintegrowaną z dostawcą tożsamości i infrastrukturą PKI organizacji; oraz usługę monitorowania do śledzenia SLA. Każdy komponent musi być instalowany z lokalnych repozytoriów pakietów i rejestrów kontenerów.
Wyzwania wdrożeniowe i ścieżka migracji
Najczęstszy błąd inicjatyw data mesh w organizacjach obronnych to próba jednoczesnego wdrożenia wszystkich czterech zasad we wszystkich domenach. Prawidłowe podejście jest stopniowe: zaczynamy od jednej domeny, budujemy możliwości platformy równolegle z pierwszym produktem domenowym i rozszerzamy od tego miejsca.
Zalecana ścieżka migracji zaczyna się od zidentyfikowania jednej wartościowej domeny z wyraźnym właścicielem danych. Domena GEOINT jest często dobrym punktem startowym. Centralny data lake nie znika podczas tej migracji — staje się platformą przejściową, która maleje w miarę dojrzewania produktów domenowych. Równoległy okres, w którym zarówno lake, jak i produkt domenowy współistnieją, jest oczekiwaną ścieżką migracji.
Uwaga dotycząca przekraczania barier tajności: Data mesh nie rozwiązuje najtrudniejszego problemu integracji danych wywiadu obronnego, jakim jest traversal barier tajności — przenoszenie danych z poziomu TAJNE do JAWNE lub między różnymi zastrzeżeniami koalicyjnymi. Ten problem wymaga rozwiązania cross-domain (CDS), a nie wzorca architektonicznego. To, co data mesh rozwiązuje, to problem organizacyjny: kto jest właścicielem danych, kto odpowiada za ich jakość i kto decyduje o możliwości ich udostępnienia. W organizacjach obronnych, gdzie pytania te historycznie prowadziły do wieloletnich komitetów bez odpowiedzi, wyraźna własność domenowa z kontraktowymi SLA produktów danych jest naprawdę transformacyjna.
Szczegółowe omówienie architektury przechowywania, na której opierają się produkty danych domenowych, zawiera artykuł Architektura data lake dla obronności: projektowanie i operacje. Wzorce fuzji konsumujące produkty danych między domenami INT opisuje artykuł Fuzja danych wojskowych: architektury i metody. Potoki zbierania zasilające produkty danych domenowych omówiono w artykule Budowanie potoku fuzji danych obronnych, część 1: źródła i schematy.