Architektura platformy GEOINT: pozyskiwanie, przetwarzanie i udostępnianie geoprzestrzennego wywiadu w skali

Wywiad geoprzestrzenny to dyscyplina odpowiadająca na pytanie: co się dzieje, gdzie i kiedy? Platforma GEOINT to infrastruktura programowa, która sprawia, że na to pytanie można odpowiadać w skali — pozyskując zobrazowania satelitarne z wielu sensorów i okien czasowych ponownego odwiedzenia, łącząc je z filmami z BSP, danymi wysokościowymi i warstwami wektorowymi, przetwarzając surowe piksele na użyteczne produkty wywiadowcze i dostarczając te produkty analitykom pracującym przy stanowiskach oraz żołnierzom noszącym tablety z systemem Android w terenie. Wyzwanie inżynieryjne polega na tym, że każdy krok tego łańcucha operuje na różnych woluminach danych, ograniczeniach opóźnień i konwencjach formatów, które nigdy nie były zaprojektowane do współpracy.

W tym artykule opisano architekturę produkcyjnej platformy GEOINT od pozyskiwania do konsumpcji. Obejmuje typy danych zasilających system, potok konwersji formatów i kafelkowania, architekturę przechowywania surowych i przetworzonych zobrazowań, potok przetwarzania wykrywania zmian i rozpoznawania obiektów, warstwę obsługi dla analityków i urządzeń TAK, model dystrybucji offline dla środowisk z ograniczoną przepustowością, integrację stacji roboczych analityków oraz mechanizmy kontroli klasyfikacji i możliwości ujawniania regulujące przepływ danych między enklawitami.

Typy danych GEOINT: co platforma musi pozyskiwać

Kompletna platforma GEOINT pozyskuje dane z pięciu kategorii źródeł, każda z odmiennymi konwencjami formatów i charakterystykami operacyjnymi.

Zobrazowania satelitarne — elektrooptyczne (EO) i SAR. Zobrazowania elektrooptyczne są najbardziej znane: obrazy w zakresie widzialnym i bliskiej podczerwieni produkowane przez sensory takie jak WorldView, Sentinel-2 i Planet SkySat. Zobrazowania EO zapewniają bogate szczegóły wizualne potrzebne do rozpoznawania obiektów i wykrywania zmian, ale ulegają degradacji przy zachmurzeniu i są ograniczone do dziennych pozyskiwań dla sensorów panchromatycznych. Zobrazowania Synthetic Aperture Radar (SAR) są produkowane przez sensory Sentinel-1, ICEYE i Capella Space; penetrują zachmurzenie i działają zarówno w dzień, jak i w nocy, kosztem bardziej złożonego modelu interpretacji — obrazy SAR reprezentują rozproszenie radarowe, nie wygląd wizualny. Produkty EO i SAR są powszechnie dostarczane w formacie NITF (National Imagery Transmission Format) lub GeoTIFF z powiązanymi metadanymi geometrycznymi RPC (Rational Polynomial Coefficient) do ortorektyfikacji.

Wideo pełnoruchowe (FMV) z BSP. Taktyczne BSP produkują ciągłe strumienie wideo — zazwyczaj kodowane H.264 lub H.265 — opatrzone metadanymi MISB (Motion Imagery Standards Board) KLV osadzającymi pozycję sensora, orientację platformy, zasięg skośny i pole widzenia sensora. Strumień KLV umożliwia platformie geolokalizację każdej klatki wideo jako czworokątny ślad na ziemi. Klatki o wysokiej wartości można ekstrahować jako nieruchome obrazy i przekazywać do potoku zobrazowań do eksploatacji. Archiwa FMV są przechowywane oddzielnie od zobrazowań ze względu na ich wolumen; platforma utrzymuje indeks przestrzenny i czasowy, dzięki czemu analitycy mogą wyszukiwać segmenty wideo obejmujące dany obszar i okno czasowe.

Modele wysokościowe. Cyfrowe Modele Terenu (DTM) i Cyfrowe Modele Wysokościowe (DEM) zapewniają trzeci wymiar, którego brakuje zobrazowaniom. DTED (Digital Terrain Elevation Data) to standardowy format NATO na poziomach 0 (krok 900 m), 1 (90 m) i 2 (30 m). SRTM (Shuttle Radar Topography Mission) zapewnia prawie globalne pokrycie 30 m. Pochodne o wyższej rozdzielczości są produkowane ze stereoskopowych par zobrazowań EO lub interferometrii SAR. Dane wysokościowe są niezbędne do ortorektyfikacji zobrazowań, analizy widoczności 3D, maskowania terenu do planowania sensorów oraz geolokalizacji obserwacji sensorów z BSP i samolotów.

Warstwy wektorowe. Bazy danych nazwanych obiektów, granice administracyjne, sieci drogowe, hydrografia i dane obiektów są dystrybuowane jako zbiory danych wektorowych w formatach Esri File Geodatabase, GeoPackage, Shapefile i GeoJSON. Klasyfikowane warstwy wektorowe, takie jak bazy danych celów i warstwy sił bojowych, są zarządzane w ramach architektury klasyfikacji i nigdy nie są mieszane z niesklasyfikowanymi warstwami na poziomie bazy danych.

OSINT z crowdsourcingu. Ekstrakty OpenStreetMap, dane lokalizacyjne z mediów społecznościowych i komercyjnie zagregowane raporty o zmianach zapewniają aktualizacje prawie w czasie rzeczywistym, których nie może dopasować ponowne odwiedzenie przez satelitę. Kanały OSINT są pozyskiwane jako GeoJSON lub niestandardowe schematy JSON i traktowane jako warstwy o niskim zaufaniu, niesklasyfikowane, które informują decyzje o zleceniach — kierując pozyskiwanie satelitarne na obszary, gdzie OSINT sygnalizuje aktywność — a nie jako podstawowe produkty wywiadowcze.

Potok pozyskiwania: pozyskiwanie NITF, konwersja COG i piramidy kafelków

Surowe zobrazowania trafiają do warstwy pozyskiwania w heterogenicznych formatach i odwzorowaniach. Potok pozyskiwania normalizuje je do spójnego formatu przechowywania, zanim uruchomi się jakikolwiek krok przetwarzania.

Pozyskiwanie NITF i GeoTIFF. Pliki NITF są analizowane przy użyciu sterownika NITF biblioteki GDAL, który ekstrahuje pasma obrazu, współczynniki RPC i pola nagłówka bezpieczeństwa. Pola bezpieczeństwa wypełniają atrybuty klasyfikacji i możliwości ujawniania rekordu metadanych katalogu. W przypadku wielosegmentowych kontenerów NITF (duże obrazy podzielone na wiele segmentów), GDAL obsługuje ponowne składanie w sposób przezroczysty. Pozyskiwanie GeoTIFF jest prostsze: GDAL odczytuje osadzone metadane GeoTransform lub RPC i dane obrazu bezpośrednio.

Ortorektyfikacja. Przed jakąkolwiek operacją przestrzenną surowe zobrazowania muszą zostać poddane ortorektyfikacji — korygowane pod kątem geometrii sensora i przesunięcia terenu — aby uzyskać spójny produkt rzutowany na ziemię. Funkcja GDAL gdalwarp z korekcją RPC i wejściem DEM wykonuje ten krok. Na wyjściu jest rzutowany GeoTIFF w WGS84 lub lokalnej strefie UTM, z błędem resztkowym zazwyczaj poniżej jednego piksela w rozdzielczości źródłowej.

Konwersja Cloud-Optimised GeoTIFF. Każdy ortorektyfiowany obraz jest natychmiast konwertowany do formatu COG przy użyciu gdal_translate ze sterownikiem -of COG. COG organizuje dane obrazu jako przeplatane kafelki z osadzonymi poziomami przeglądowymi (piramidy) w rozdzielczościach zmniejszonych o kolejne potęgi dwójki. Wynikowy plik obsługuje efektywny dostęp przez żądania zakresu HTTP: serwer kafelków lub klient z bezpośrednim dostępem może pobrać dowolny podzestaw przestrzenny na dowolnym poziomie powiększenia bez odczytywania całego pliku. Konwersja COG zazwyczaj podwaja ślad przechowywania w porównaniu z obrazem źródłowym ze względu na poziomy piramidy; jest to akceptowany kompromis za eliminację oddzielnej infrastruktury generowania kafelków.

Generowanie piramidy kafelków. W przypadku warstw wymagających szybszego buforowanego serwowania kafelków niż mogą zapewnić żądania zakresu HTTP COG — mapy bazowe o wysokim ruchu, często odpytywane wyniki wykrywania zmian — jawny krok kafelkowania generuje piramidę kafelków przy użyciu MapTiler lub gdal2tiles.py z GDAL. Na wyjściu jest struktura katalogów XYZ lub pojedynczy kontener MBTiles, zapisany w magazynie obiektów i zaindeksowany w katalogu buforu kafelków. Wybór między serwowaniem COG na żądanie a wstępnie wygenerowanymi piramidami kafelków jest podyktowany częstotliwością zapytań: nowe przejście satelity pozyskane do natychmiastowego dostępu analityka jest serwowane jako COG; mapa bazowa używana przez tysiące równoczesnych urządzeń TAK jest wstępnie kafelkowana.

Architektura przechowywania: magazyn obiektów, PostGIS i kontenery kafelków

Platforma GEOINT zarządza trzema oddzielnymi warstwami przechowywania, każda zoptymalizowana pod kątem innego wzorca dostępu.

Magazyn obiektów dla surowych i przetworzonych zobrazowań. Wszystkie dane rastrowe — surowe pozyskiwania, ortorektyfiowane COG, produkty pochodne — są przechowywane w magazynie obiektów: MinIO dla odizolowanych wdrożeń lokalnych, magazyny kompatybilne z S3 dla środowisk połączonych z chmurą. Magazyn obiektów zapewnia praktycznie nieograniczoną poziomą pojemność, pobieranie zaadresowane do treści przez URI i natywne wsparcie dla żądań zakresu HTTP, na których polega COG. Zasady cyklu życia archiwizują zimne zobrazowania (do których nie uzyskiwano dostępu przez 90 dni) w tańszych warstwach; gorące zobrazowania (w bieżącym oknie operacyjnym) są przechowywane na wysokoprzepustowych nośnikach SSD.

PostGIS dla obiektów wektorowych i metadanych zobrazowań. Katalog zobrazowań, warstwy wektorowe, adnotacje analityków i wyniki wykrywania zmian są przechowywane w PostGIS. Tabela katalogu zobrazowań przechowuje jeden wiersz na scenę z kolumnami dla czasu pozyskania, sensora, poziomu klasyfikacji, zachmurzenia i kolumny geometry(POLYGON, 4326) dla śladu sceny. Przestrzenny indeks GiST na tej kolumnie sprawia, że zapytania przecięcia obwiedni — „znajdź wszystkie sceny obejmujące ten obszar zainteresowania" — są submilisekundowe nawet przy milionach wpisów w katalogu. Tabele warstw wektorowych stosują ten sam wzorzec: każdy obiekt ma kolumnę geometrii i zestaw kolumn atrybutów; indeksowanie przestrzenne umożliwia szybkie zapytania na poziomie kafelków mapy. Aby zapoznać się z pełnymi kompromisami indeksowania, zobacz Geoprzestrzenne indeksowanie dla obronności.

MBTiles i PMTiles do dystrybucji offline. Kontenery kafelków spakowane do użytku offline są przechowywane razem z przetworzonymi zobrazowaniami w magazynie obiektów, ale są również kopiowane do dedykowanego magazynu dystrybucji offline — udziału sieciowego lub fizycznie odizolowanego dysku — skąd urządzenia TAK i laptopy analityków pobierają pakiety. Pliki MBTiles to bazy danych SQLite: prosty schemat z tabelą tiles z kluczami według powiększenia, kolumny i wiersza sprawia, że są trywialnie przenośne i czytelne przez każde urządzenie z obsługą SQLite. PMTiles, pojawiająca się alternatywa, przechowuje kafelki w płaskim pliku binarnym z indeksem opartym na nagłówku, umożliwiając bezpośredni dostęp przez żądania zakresu HTTP ze statycznego serwera WWW bez procesu proxy kafelków.

Potok przetwarzania: wykrywanie zmian, rozpoznawanie obiektów, koherencja SAR

Potok przetwarzania przekształca surowe zobrazowania w produkty gotowe dla analityków. Trzy podstawowe tryby przetwarzania obejmują większość wymagań operacyjnych.

Wykrywanie zmian przez różnicowanie pikseli. Najprostsze podejście do wykrywania zmian odejmuje obraz bazowy od nowego obrazu tego samego obszaru, stosuje próg do wartości bezwzględnej różnicy i produkuje binarną maskę zmian. Jest to obliczeniowo tanie — para pikseli 10 000 × 10 000 kończy się w ciągu sekund na jednym rdzeniu CPU — i nie wymaga danych treningowych. Jego tryby awarii są dobrze poznane: sezonowe zmiany roślinności, różnice kąta oświetlenia i dryft kalibracji sensora — wszystko to generuje fałszywe pozytywy. W zastosowaniach taktycznych, gdzie szybkość jest ważniejsza niż wskaźnik fałszywych pozytywów, różnicowanie pikseli jest właściwym domyślnym podejściem.

Wykrywanie zmian oparte na ML. Splotowa sieć neuronowa wytrenowana na oznakowanych parach obrazów przed/po produkuje mapę prawdopodobieństwa zmian zamiast binarnej maski. Wytrenowane modele generalizują się w różnych warunkach oświetlenia i sezonowych zmianach, ponieważ uczą się cech na poziomie sceny, a nie na poziomie pikseli. Kompromisem jest koszt wnioskowania — wnioskowanie przyspieszone GPU dla dużej sceny trwa dziesiątki sekund — i wymóg oznakowanych danych treningowych reprezentatywnych dla środowiska operacyjnego. W produkcji różnicowanie pikseli działa jako szybki wstępny filtr: tylko regiony oznaczone przez różnicowanie pikseli są przesyłane do wnioskowania ML, zmniejszając obciążenie GPU o rząd wielkości dla scen ze rzadkimi zmianami.

Wykrywanie obiektów na zobrazowaniach. Modele wykrywania obiektów — zazwyczaj architektury klasy YOLO dostrojone na zobrazowaniach lotniczych — identyfikują pojazdy, samoloty, statki, obiekty i działalność budowlaną w zobrazowaniach EO. Model wypisuje prostokąty ograniczające z etykietami klas i wynikami ufności; prostokąty ograniczające są geolokalizowane przy użyciu metadanych ortorektyfikacji sceny i zapisywane do PostGIS jako obiekty punktowe lub poligonalne z dołączonymi metadanymi wykrywania. Wykryte obiekty zasilają szerszy potok fuzji jako obserwacje pochodne GEOINT: wykryty na produkcie zobrazowania konwój pojazdów wojskowych może być skorelowany ze ścieżką radarową lub azymutem SIGINT w warstwie fuzji wielosensorowej.

Analiza koherencji SAR. Koherencja jest obliczana z dwóch współzarejestrowanych obrazów SAR Single Look Complex (SLC) pozyskanych nad tym samym obszarem w różnych momentach. Wartość koherencji piksel po pikselu — znormalizowana wzajemna korelacja złożonych wartości pikseli — mieści się w zakresie od 0 (całkowita dekorelacja, wskazująca na zmianę powierzchni) do 1 (idealna koherencja, wskazująca brak zmian). Mapy utraty koherencji produkowane z par obrazów Sentinel-1 lub ICEYE podkreślają zaburzenia gruntu z czułością przekraczającą różnicowanie pikseli w terenie zalesionym lub o małym kontraście. Przetwarzanie wymaga dostępu do danych na poziomie SLC (nie produktów intensywności z wykrywaniem naziemnym, powszechnie dystrybuowanych ogólnym użytkownikom) i wyspecjalizowanego interferometrycznego oprogramowania do przetwarzania SAR — SNAP, ISCE lub niestandardowych implementacji CUDA dla wymagań czasu rzeczywistego.

Warstwa obsługi: punkty końcowe OGC, kafelki wektorowe i integracja TAK

Przetworzone produkty wywiadowcze muszą docierać do analityków i operatorów w terenie przez standardowe interfejsy, które istniejące narzędzia mogą konsumować bez niestandardowych prac integracyjnych.

Punkty końcowe OGC WMS i WMTS. Standard OGC Web Map Service definiuje protokół żądania obrazów mapowych z serwera na podstawie obwiedni, układu współrzędnych, rozmiaru obrazu i nazwy warstwy. WMS jest uniwersalnym standardem interoperacyjności: każde narzędzie GIS — QGIS, ArcGIS, Global Mapper, ATAK — może konsumować punkt końcowy WMS. Jego słabością jest opóźnienie: każde żądanie wyzwala renderowanie po stronie serwera. WMTS rozwiązuje ten problem wstępnie wyrenderowanymi buforami kafelków serwowanymi na stałych poziomach powiększenia; punkt końcowy WMTS może obsługiwać tysiące równoczesnych żądań kafelków z buforu bez dotykania backendu zobrazowań. MapServer, GeoServer i lżejszy TiTiler (chmurowy serwer kafelków COG) obsługują oba standardy.

OGC WFS dla obiektów wektorowych. WFS udostępnia obiekty wektorowe — wyniki wykrywania zmian, wykryte obiekty, adnotacje analityków — jako odpowiedzi GeoJSON lub GML na przestrzenne i atrybutowe zapytania filtrujące. Klienci WFS pobierają obiekty do edycji i analizy, a nie do wyświetlania; zwrócone geometrie niosą pełne ładunki atrybutów. Dla dostępu tylko do odczytu o wysokiej przepustowości, OGC API Features (standard następnej generacji) zapewnia interfejs REST/JSON prostszy do buforowania i lepiej dostosowany do aplikacji internetowych.

Kafelki wektorowe Mapbox. MVT jest de facto standardem dla wysokowydajnego serwowania kafelków wektorowych. Dane wektorowe — sieci drogowe, nazwane obiekty, warstwy analityków — są dzielone na kafelki na każdym poziomie powiększenia i kodowane jako binarny Protocol Buffer; klienci wykonują renderowanie po stronie klienta przy użyciu WebGL, umożliwiając płynne powiększanie i przesuwanie bez odwołań do serwera. Platforma GEOINT generuje archiwa MVT z PostGIS przy użyciu tippecanoe lub funkcji PostGIS ST_AsMVT, przechowuje je jako MBTiles lub PMTiles i serwuje przez serwer kafelków konsumowany przez klienta ATAK-web i oparte na przeglądarce pulpity analityków.

Integracja ATAK i CloudTAK. Urządzenia ATAK łączą się z serwerem TAK — referencyjna implementacja to TAK Server (Java), z FreeTAKServer jako lżejszą alternatywą — który dystrybuuje wiadomości XML CoT (Cursor on Target) niosące pozycje obiektów w czasie rzeczywistym, ścieżki i alerty. Platforma GEOINT integruje się jako producent CoT: gdy potok przetwarzania wykrywa nowy obiekt lub znaczącą zmianę, publikuje zdarzenie CoT na serwer TAK, który przekazuje je do wszystkich subskrybujących urządzeń ATAK. Warstwy mapowe — przetworzone zobrazowania, warstwy wykrywania zmian — są dystrybuowane jako pakiety MBTiles, które serwer TAK udostępnia do pobrania przez urządzenia przez sieć lokalną.

Dystrybucja offline: pakowanie MBTiles, synchronizacja różnicowa i fizyczny transfer danych

Operatorzy w terenie regularnie pracują w środowiskach, gdzie łączność z backendem platformy GEOINT jest przerywana lub nieobecna. Dystrybucja offline nie jest przypadkiem brzegowym; jest to podstawowa ścieżka dostarczania.

Pakowanie MBTiles dla urządzeń TAK. Przepływ pracy pakietu offline rozpoczyna się od zdefiniowania przez użytkownika — analityka lub oficera wywiadowczego — obszaru zainteresowania i zestawu warstw (mapa bazowa, ostatnie zobrazowania, warstwa wykrywania zmian, obiekty wektorowe) i zamówienia pakietu. Platforma odpytuje PostGIS o odpowiednie kafelki, składa je w jeden plik SQLite MBTiles przy użyciu skryptu kafelkowania i kompresuje plik do transferu. Rozmiar pakietu jest zarządzany zakresem poziomów powiększenia: obszar zainteresowania 10 km × 10 km na poziomach powiększenia 0–17 zazwyczaj produkuje pakiet 200–500 MB, który mieści się na pendrivie USB lub transferuje się w ciągu minut przez lokalną sieć Wi-Fi.

Synchronizacja różnicowa dla środowisk z ograniczoną przepustowością. Gdy dostępne są okresowe okna łączności — łącze satelitarne, samolot przekaźnikowy nad głową — platforma obsługuje synchronizację różnicową zamiast pełnego ponownego dostarczania pakietu. Magazyn kafelków utrzymuje dziennik zmian: każdy zapis kafelka jest rejestrowany ze znacznikiem czasu i kluczem kafelka. Gdy urządzenie się ponownie łączy, zgłasza swój ostatni znacznik czasu synchronizacji; platforma oblicza zestaw zmienionych kafelków od tego czasu i przesyła tylko różnicę. Dla taktycznego obszaru zainteresowania z umiarkowanymi tempami zmian, synchronizacja różnicowa obejmująca 24 godziny aktualizacji może przesyłać dziesiątki megabajtów w porównaniu do setek przy pełnym odświeżeniu pakietu.

Transfer danych przez kody QR. Dla ekstremalnego ograniczenia przepustowości — bez radia, bez Wi-Fi, fizyczna izolacja — małe produkty wywiadowcze (jeden wynik wykrywania zmian, siatka celów, warstwa wektorowa z kilkoma obiektami) mogą być kodowane jako kody QR i transferowane wizualnie. Platforma generuje kod QR z ładunku GeoJSON zakodowanego w Base64, skompresowanego; urządzenie odbierające z wtyczką ATAK lub niestandardową aplikacją skanuje kod i importuje obiekt. To podejście jest ograniczone przez pojemność danych kodu QR — około 3 KB na kod — ale pokrywa krytyczny problem „ostatniego metra" dostarczenia konkretnej siatki celów lub doniesienia o pojeździe do urządzenia bez innej łączności.

Stacja robocza analityka: integracja QGIS, adnotacje i eksport

Stacja robocza analityka to podstawowe środowisko eksploatacji. Większość analityków zobrazowań obronnych pracuje w QGIS, uzupełnionym przez specjalistyczne narzędzia eksploatacyjne dla konkretnych typów produktów.

Integracja wtyczki QGIS. Wtyczka QGIS platformy GEOINT zapewnia zadokowany panel, który uwierzytelnia się przez API platformy, odpytuje katalog zobrazowań według obszaru zainteresowania i zakresu czasu oraz ładuje wybrane sceny jako warstwy COG WMS bezpośrednio na płótno QGIS. Wtyczka automatycznie obsługuje odświeżanie tokenów, konwencje nazewnictwa warstw i wyrównanie układu współrzędnych. Analitycy mogą nakładać wiele scen, przełączać warstwy wykrywania zmian i sprawdzać atrybuty wykrytych obiektów bez opuszczania środowiska QGIS. W przypadku niestandardowych integracji QGIS, patrz także PostGIS dla geoprzestrzennych danych obronnych — o warstwie bazy danych obsługującej katalog.

Przepływ pracy adnotacji. Analitycy opatrują obiekty adnotacjami — identyfikacja celów, etykiety aktywności, notatki eksploatacyjne — bezpośrednio na zobrazowaniach w QGIS przy użyciu standardowego paska narzędzi digitalizacji, a wtyczka zapisuje adnotacje do warstwy adnotacji PostGIS przez API platformy. Adnotacje niosą tożsamość analityka, poziom klasyfikacji i odniesienie do UUID źródłowego zobrazowania, tworząc pełny łańcuch proweniencji od surowego obrazu do gotowego produktu wywiadowczego. Zdarzenia adnotacji są publikowane na magistrali komunikatów, dzięki czemu konsumenci downstream — warstwa integracji TAK, silnik analizy wzorców zachowań — otrzymują aktualizacje prawie w czasie rzeczywistym.

Eksport do NITF, KMZ i GeoJSON. Gotowe produkty muszą opuścić platformę w formatach oczekiwanych przez konsumentów wywiadu downstream. Eksport NITF opakowuje przetworzony obraz z odpowiednimi polami nagłówka bezpieczeństwa wypełnionymi z metadanych klasyfikacji produktu. Eksport KMZ pakuje obiekty wektorowe jako nakładki Google Earth — standardowy format dostarczania dla wielu organizacji partnerskich. Eksport GeoJSON zaspokaja nowoczesnych konsumentów aplikacji internetowych. Wszystkie eksporty są rejestrowane jako zdarzenia proweniencji, a żądanie eksportu przechwytuje tożsamość żądającego i zamierzonego odbiorcy — niezbędne dla rozliczania klasyfikacji i wymagań śladu audytu.

Klasyfikacja i możliwość ujawniania: znakowanie metadanych, CDS i udostępnianie koalicyjne

Mechanizmy kontroli klasyfikacji nie są warstwą dodaną na wierzchu platformy GEOINT — są strukturalne. Każdy obiekt danych w systemie nosi metadane klasyfikacji i możliwości ujawniania od momentu pozyskania, a te metadane rządzą każdą decyzją dotyczącą dostępu, przetwarzania i dystrybucji.

Znakowanie metadanych. Pliki NITF noszą klasyfikację w standardowych polach nagłówka bezpieczeństwa (FSCLAS, FSCLSY, FSREL, FSDCTP i powiązanych polach). Przy pozyskiwaniu platforma odczytuje te pola i przechowuje je w bazie danych katalogu jako atrybuty strukturyzowane, a nie łańcuchy tekstu swobodnego. Każdy produkt pochodny dziedziczy najwyższą klasyfikację swoich źródłowych danych wejściowych, chyba że zastosowano jawny przepływ pracy obniżenia klasyfikacji. Schemat znakowania jest zgodny z krajowymi lub sojuszniczymi standardami klasyfikacji (NATO, odpowiedniki krajowe) i jest egzekwowany na poziomie modelu danych — rekord produktu bez prawidłowej wartości klasyfikacji nie przechodzi walidacji schematu i nie jest dopuszczany do katalogu.

Integracja rozwiązania między domenami. Urządzenia CDS — sprzętowe lub programowe zabezpieczenia certyfikowane do transferu danych między domenami — są umieszczone między enklawitami klasyfikacji i egzekwują politykę opartą na treści dla danych przepływających z środowisk o wyższym poziomie tajności do niższego. Platforma GEOINT traktuje CDS jako zewnętrzny system, którym platforma zasila przez dedykowany interfejs eksportu. Produkty o wyższym poziomie tajności przeznaczone do ujawnienia muszą przejść przez przepływ pracy eksportu CDS, który waliduje metadane klasyfikacji, stosuje wszelkie wymagane redakcje lub degradacje i generuje rekord audytu po obu stronach granicy domenu. Platforma nie implementuje logiki CDS wewnętrznie — to jest granica certyfikacji dostawcy CDS — ale zapewnia metadane strukturyzowane, których wymagają silniki polityk CDS.

Automatyczne obniżenie klasyfikacji dla udostępniania koalicyjnego. Operacje koalicyjne wymagają udostępniania produktów wywiadowczych krajom partnerskim, które mogą nie mieć dostępu do najwyższego poziomu klasyfikacji. Automatyczne przepływy pracy obniżenia klasyfikacji działają w dwóch wymiarach: przestrzennym i spektralnym. Obniżenie przestrzenne usuwa lub pikselizuje obiekty w wrażliwych obszarach — konkretne lokalizacje obiektów, identyfikatory celów o wysokiej wartości — z produktu przed przekroczeniem granic klasyfikacji. Obniżenie spektralne degraduje rozdzielczość zobrazowania do poziomu zgodnego z zastrzeżeniem możliwości ujawniania. Operacje obniżenia są parametryzowane przez tagi możliwości ujawniania produktu i poziom poświadczenia bezpieczeństwa zamierzonego odbiorcy; platforma automatycznie wykonuje odpowiednie przekształcenie obniżenia i rejestruje parametry przekształcenia jako część proweniencji produktu. Produkty udostępnione koalicji są oznaczone zastrzeżeniem odbiorcy i mogą być dalej udostępniane tylko w ramach uprawnień dystrybucji tego zastrzeżenia.

Powiązane lektury

Architektura platformy GEOINT leży na przecięciu geoprzestrzennej inżynierii danych, przetwarzania wywiadu i projektowania oprogramowania obronnego. Artykuły poniżej szczegółowo omawiają powiązane tematy.

Geoprzestrzenna inżynieria danych: PostGIS dla geoprzestrzennych danych obronnych, Geoprzestrzenne indeksowanie dla obronności, Analiza wzorców zachowań dla wywiadu wojskowego.

Fuzja i multi-INT: Architektura fuzji wielosensorowej, Kompletny przewodnik po fuzji danych obronnych, Model fuzji danych JDL.

Inżynieria potoków danych: Kolejki komunikatów dla obronnych potoków danych, Event sourcing dla obronnych dzienników audytu, Budowanie obronnego potoku fuzji: źródła i schematy.

C2 i COP: Wspólny obraz operacyjny: jak jest budowany, Kompletny przewodnik po systemach C2.