Rozwiązania międzydziedzinowe dla obronności: bezpieczne przesyłanie danych między poziomami klasyfikacji

Rozwiązanie międzydziedzinowe (CDS) to system sprzętowo-programowy umożliwiający kontrolowany transfer danych między sieciami działającymi na różnych poziomach klasyfikacji bezpieczeństwa — na przykład z operacyjnej sieci SECRET do niejawnego portalu koalicyjnego UNCLASSIFIED lub z niejawnego kanału danych sensorycznych do tajnego systemu dowodzenia i kontroli (C2). Bez CDS obie sieci muszą pozostawać całkowicie odizolowane: żadne dane nie mogą między nimi przepływać. Dzięki CDS starannie zdefiniowane transfery mogą odbywać się pod ścisłym egzekwowaniem polityki, umożliwiając niejawnym informacjom wywiadowczym kształtowanie niejawnych decyzji taktycznych oraz zasilanie niejawnych analiz danymi z sieci UNCLASSIFIED — bez narażania sieci o wyższej klasyfikacji na kompromitację.

Technologia CDS leży na przecięciu polityki, inżynierii i prawa bezpieczeństwa narodowego. Prawidłowy wybór, wdrożenie i integracja CDS to jedna z najbardziej decydujących decyzji architektonicznych w niejawnym programie oprogramowania obronnego. Nieprecyzyjnie określony lub nieprawidłowo zintegrowany CDS jest albo zbyt restrykcyjny — blokując przepływy danych niezbędne operacyjnie i obniżając skuteczność misji — albo zbyt liberalny, tworząc kontrolowaną ścieżkę, przez którą wrażliwe informacje mogą wyciekać do sieci o niższej klasyfikacji. Niniejszy artykuł omawia architekturę, akredytację i wzorce integracji, które architekci bezpieczeństwa i dyrektorzy IT sektora obronnego muszą zrozumieć, aby podjąć właściwą decyzję.

Dlaczego transfery między domenami są niezbędne operacyjnie

Operacyjny imperatyw przesyłania danych między domenami wynika z fundamentalnego napięcia w zarządzaniu informacją w obronie: najbardziej wartościowe informacje wywiadowcze są często wysoce niejawne, ale personel i systemy, które muszą na nich działać, często funkcjonują na niższych poziomach klasyfikacji lub w środowiskach koalicyjnych, gdzie wymagane jest dzielenie się danymi ponad krajowymi granicami klasyfikacji.

Degradacja z wywiadu do operacji to klasyczny przypadek użycia CDS. Tajny produkt wywiadowczy — ocena zagrożeń, pakiet celowania, raport rozmieszczenia sił — musi zostać odtajniony i udostępniony w sieci UNCLASSIFIED lub koalicyjnej, aby dowódcy taktyczni i siły partnerskie mogli na jego podstawie działać. Bez CDS proces ten wymaga ręcznej weryfikacji przez człowieka i ręcznego ponownego wprowadzania odtajnionych informacji, co jest powolne, podatne na błędy i nie skaluje się do wolumenu nowoczesnych operacji informacyjnych.

Agregacja danych sensorycznych między poziomami klasyfikacji napędza przepływ odwrotny. Niejawne informacje wywiadowcze ze źródeł otwartych (OSINT), komercyjne zobrazowania satelitarne i kanały danych sensorycznych państw partnerskich muszą być pozyskiwane do środowisk analitycznych SECRET lub wyżej sklasyfikowanych w celu fuzji z niejawnymi danymi. CDS zapewnia kontrolowaną ścieżkę pozyskiwania: niejawne dane wchodzą do środowiska o wyższej klasyfikacji przez strażnika, gdzie mogą być łączone z niejawnymi danymi, które nigdy nie opuszczają sieci po stronie wysokiej.

Operacje koalicyjne tworzą wymagania między domenami ponad krajowymi granicami klasyfikacji. Oznaczenia NATO REL (Releasable) i poziom klasyfikacji Mission Secret definiują, jakie informacje mogą być udostępniane konkretnym państwom partnerskim, ale technicznym mechanizmem egzekwowania tych reguł udostępniania na poziomie sieci jest CDS, który rozumie i egzekwuje polityki wymiany danych koalicji.

Wzorce architektury CDS

Produkty CDS implementują jeden z kilku wzorców architektonicznych, z których każdy jest odpowiedni dla różnych wymagań dotyczących przepływu danych i poziomów pewności bezpieczeństwa.

Diody danych to najprostsza i o najwyższym poziomie pewności architektura CDS. Dioda danych to urządzenie sprzętowe, które fizycznie wymusza jednostronny przepływ danych za pomocą izolacji optycznej: nadajnik po stronie wysokiej wysyła dane przez łącze światłowodowe do odbiornika po stronie niskiej, bez fizycznie możliwej drogi powrotnej. Ponieważ nie ma kanału zwrotnego, sieć po stronie wysokiej nie może otrzymywać żadnych informacji z sieci po stronie niskiej — nawet pakietów potwierdzenia TCP. Diody danych są stosowane, gdy pewność absolutnie jednostronnego przepływu jest ważniejsza niż wydajność protokołu. Wymagają adaptacji protokołu (zazwyczaj pompy danych oparte na UDP) w celu obejścia braku potwierdzenia TCP i nie wykonują inspekcji treści — przekazują wszystkie dane w określonym kierunku. Typowe przypadki użycia obejmują jednostronny eksport dzienników z niejawnych systemów do platform SIEM, jednostronne kanały danych sensorycznych do niejawnych sieci oraz jednostronne publikowanie wstępnie zatwierdzonych danych masowych.

Strażniki high-to-low to urządzenia dwukierunkowe egzekwujące politykę bezpieczeństwa opartą na treści dla danych przepływających z sieci o wyższej klasyfikacji do sieci o niższej klasyfikacji. Strażnik otrzymuje żądanie transferu ze strony wysokiej, sprawdza treść względem zdefiniowanej polityki bezpieczeństwa i — jeśli treść przejdzie wszystkie kontrole inspekcji — przekazuje zatwierdzoną treść do strony niskiej. Strażnik rejestruje zarówno zatwierdzone, jak i zablokowane transfery do celów audytu. Strażniki high-to-low są używane do kontrolowanego odtajniania: publikowania produktów wywiadowczych, raportów lub rekordów baz danych z niejawnej sieci do niejawnej lub koalicyjnej. Silnik inspekcji sprawdza treść pod kątem oznaczeń klasyfikacyjnych, wrażliwych słów kluczowych, osadzonych metadanych i złośliwej zawartości przed zatwierdzeniem transferu.

Strażniki dwustronne obsługują kontrolowaną wymianę danych w obu kierunkach przez granicę klasyfikacji. Dane przepływające z wyższego do niższego poziomu są sprawdzane pod kątem zgodności z polityką klasyfikacji i złośliwej treści. Dane przepływające z niższego do wyższego poziomu są sprawdzane pod kątem złośliwego oprogramowania, zgodności formatu i nieautoryzowanych typów treści. Strażniki dwustronne są używane tam, gdzie przepływy pracy wymagają obu kierunków: komunikaty dowodzenia przepływające z niejawnych systemów C2 do niejawnych sieci sensorycznych lub uzbrojenia, ze statusami przepływającymi z powrotem. Strażniki dwustronne mają większą powierzchnię ataku niż diody danych i wymagają bardziej rygorystycznej akredytacji, ale obsługują pełen zakres przepływów pracy operacyjnej.

Strażniki oparte na filtrach z inspekcją treści implementują ustrukturyzowaną analizę każdego żądania transferu względem formalnej polityki bezpieczeństwa. Potok inspekcji treści zazwyczaj obejmuje: weryfikację typu pliku (biała lista zatwierdzonych formatów), weryfikację schematu dla danych strukturyzowanych (XML, JSON sprawdzane względem zatwierdzonych schematów), skanowanie złośliwego oprogramowania (AV i sandboxing dla plików), usuwanie metadanych (usuwanie metadanych pliku, które mogą zawierać znaczniki klasyfikacji lub informacje o autorze) oraz — dla transferów high-to-low o wysokim poziomie pewności — semantyczną inspekcję treści, która analizuje tekst pod kątem oznaczeń klasyfikacyjnych i wrażliwych słów kluczowych.

Ramy akredytacyjne: UCDMO, NSA i NATO

Produkty CDS używane w systemach bezpieczeństwa narodowego USA muszą figurować na liście bazowej Unified Cross Domain Management Office (UCDMO) — autorytatywnej liście produktów CDS ocenionych i zatwierdzonych przez NSA. Lista bazowa UCDMO jest prowadzona przez National Cross Domain Strategy and Management Office (NCDSMO) NSA i jest dostępna dla niejawnych biur programowych za pośrednictwem niejawnych kanałów. Produkt trafia na listę bazową przez proces oceny NSA, który ocenia architekturę bezpieczeństwa, implementację i procedury operacyjne względem wymagań odpowiedniego Profilu Ochrony.

Proces oceny nowego produktu CDS trwa zazwyczaj 18–36 miesięcy. Dla biur programowych praktyczne implikacje są jasne: projektuj swoją architekturę między domenami w oparciu o produkty, które już znajdują się na liście bazowej UCDMO. Próba wprowadzenia nowego, nieocenionego produktu do programu opóźni harmonogram akredytacji o lata.

Nawet przy użyciu produktu znajdującego się na liście bazowej, jego wdrożenie w konkretnym środowisku wymaga akredytacji lokalizacji. Pakiet akredytacyjny lokalizacji dokumentuje konkretną konfigurację CDS, politykę inspekcji treści obowiązującą dla każdego zatwierdzonego przepływu danych, integrację z otaczającym systemem oraz procedury operacyjne zarządzania CDS i jego monitorowania. Organ akredytujący przegląda ten pakiet i przyznaje Upoważnienie do Działania (ATO) dla tego konkretnego wdrożenia. Akredytacje lokalizacji zazwyczaj trwają 3–9 miesięcy w zależności od złożoności integracji i obciążenia pracą organu akredytującego.

Akredytacja NATO jest zarządzana przez NATO Communications and Information Agency (NCI Agency) oraz krajowe Organy Bezpieczeństwa Łączności. Produkty CDS NATO są oceniane względem Profili Ochrony specyficznych dla NATO i umieszczane na odpowiedniku listy bazowej UCDMO NATO. Produkty zatwierdzone dla systemów bezpieczeństwa narodowego USA nie są automatycznie zatwierdzane do użytku NATO — wymagana jest odrębna ocena i umieszczenie na liście, choć dostawcy zazwyczaj realizują obie równolegle.

Systemy informacyjne z niejawnymi informacjami UE podlegają przepisom bezpieczeństwa dotyczącym informacji niejawnych UE (EUCI), a akredytacja jest zarządzana przez Komitet Bezpieczeństwa Rady i krajowe Organy Akredytacji Bezpieczeństwa. Produkty CDS używane w środowiskach niejawnych UE muszą być zatwierdzone w ramach unijnych przepisów, ponownie przez odrębny proces oceny.

Kategorie produktów CDS i krajobraz dostawców

Komercyjny rynek CDS jest obsługiwany przez niewielką liczbę dostawców, którzy zainwestowali w wieloletni proces oceny NSA. Zamiast rekomendować konkretne produkty, bardziej użyteczne dla architektów jest zrozumienie kategorii produktów i możliwości do oceny.

Strażnicy na poziomie sieci działają na warstwie IP/TCP i są zintegrowane z infrastrukturą sieciową między sieciami dwóch poziomów klasyfikacji. Zapewniają filtrowanie protokołów, filtrowanie IP i podstawową inspekcję treści. Są odpowiednie dla transferów danych masowych, gdzie wymagania dotyczące inspekcji treści są stosunkowo proste (typ pliku i skanowanie złośliwego oprogramowania), a opóźnienie nie jest krytyczne.

Strażnicy na poziomie aplikacji działają na warstwie protokołu aplikacji — poczta elektroniczna, transfer plików, usługi sieciowe — i integrują się z konkretnymi protokołami aplikacji. Strażnicy poczty elektronicznej sprawdzają wiadomości e-mail i załączniki zgodnie z polityką bezpieczeństwa; strażnicy transferu plików sprawdzają poszczególne pliki względem zatwierdzonych schematów i reguł typów plików; strażnicy usług sieciowych działają jako proxy API, które sprawdzają ładunki żądań i odpowiedzi. Strażnicy na poziomie aplikacji zapewniają bogatsze możliwości inspekcji treści niż strażnicy na poziomie sieci, ale wymagają integracji z konkretnymi aplikacjami po każdej stronie granicy.

Strażnicy strumieniowania obsługują strumienie danych w czasie rzeczywistym — wideo, telemetria, dane sensoryczne — i są zoptymalizowani pod kątem transferu o niskim opóźnieniu i wysokiej przepustowości z weryfikacją formatu i filtrowaniem treści odpowiednim dla danego typu strumienia. Strażnicy wideo mogą na przykład usuwać osadzone metadane ze strumieni wideo, egzekwować ograniczenia kodeków i skanować w poszukiwaniu treści steganograficznych.

Dostawcy aktywni na akredytowanym rynku CDS obejmują firmy skupiające się na sprzęcie diod danych (zazwyczaj dla wymagań jednostronnych o najwyższym poziomie pewności) oraz firmy oferujące szersze rodziny produktów strażniczych obejmujące transfery poczty elektronicznej, plików i usług sieciowych. Każdy dostawca twierdzący o możliwościach CDS do użytku w systemach bezpieczeństwa narodowego powinien być w stanie wskazać swoje umieszczenie na liście bazowej UCDMO lub aktywny status oceny — jeśli nie może, produkt nie nadaje się do wdrożeń niejawnych niezależnie od jego możliwości technicznych.

Wzorce integracji dla oprogramowania obronnego

Architekci oprogramowania obronnego muszą projektować swoje aplikacje tak, aby współpracowały z istniejącym lub planowanym CDS. CDS jest zazwyczaj pozyskiwany i zarządzany oddzielnie od oprogramowania aplikacyjnego — aplikacja nie kontroluje CDS; przesyła do niego dane i otrzymuje od niego zatwierdzone dane. Wzorzec integracji musi być wybrany tak, aby pasował do obsługiwanych interfejsów produktu CDS i wymagań dotyczących przepływu danych.

Wzorzec proxy API: Aplikacja po stronie wysokiej wysyła dane do zarządzanego przez CDS punktu końcowego API (zazwyczaj REST lub SOAP). CDS sprawdza ładunek i, jeśli zostanie zatwierdzony, przekazuje go do odpowiedniego punktu końcowego po stronie niskiej. Aplikacja otrzymuje synchroniczną odpowiedź wskazującą na zatwierdzenie lub odrzucenie. Ten wzorzec jest odpowiedni dla transferów o niskim wolumenie i tolerujących opóźnienia, gdzie aplikacja potrzebuje natychmiastowej informacji zwrotnej o tym, czy transfer został zatwierdzony.

Wzorzec kolejki komunikatów: Aplikacja po stronie wysokiej publikuje komunikaty w kolejce komunikatów (JMS, AMQP lub zastrzeżona kolejka CDS). CDS pobiera komunikaty z kolejki, sprawdza każdy z nich i ponownie publikuje zatwierdzone komunikaty w kolejce po stronie niskiej, gdzie pobiera je aplikacja odbierająca. Odrzucone komunikaty są rejestrowane i generowany jest alert. Ten wzorzec jest odpowiedni dla transferów asynchronicznych o wyższym wolumenie, gdzie pożądane jest oddzielenie aplikacji produkujących od konsumujących. Aplikacja musi obsługiwać przypadek, gdy komunikat zostaje odrzucony i nie jest dostarczany do drugiej strony.

Wzorzec bramy pocztowej: Aplikacja po stronie wysokiej generuje wiadomości e-mail ze strukturyzowanymi załącznikami (raporty PDF, pliki danych XML) i wysyła je przez przekaźnik pocztowy CDS. CDS działa jako MTA, który sprawdza wiadomość i załączniki przed przekazaniem do serwera pocztowego po stronie niskiej. Ten wzorzec jest najczęstszy dla publikacji danych inicjowanych przez człowieka — analityk tworzy raport, dołącza PDF i wysyła go do listy dystrybucyjnej w sieci po stronie niskiej. CDS usuwa metadane z PDF, skanuje w poszukiwaniu oznaczeń klasyfikacyjnych i dostarcza oczyszczoną wiadomość, jeśli przejdzie inspekcję.

Niezależnie od wzorca integracji, kod aplikacji musi obsługiwać odrzucenia przez CDS w odpowiedni sposób. Transfery mogą być odrzucane z powodów politycznych (treść zawiera oznaczenie klasyfikacyjne, które nie powinno być publikowane), technicznych (zniekształcony XML, nieoczekiwany typ pliku) lub przejściowych (CDS tymczasowo niedostępny). Aplikacja powinna definiować wyraźne zachowanie dla każdego przypadku: powiadomienie operatora, kolejka kwarantanny, logika ponownych prób oraz rejestrowanie w dzienniku każdej próby transferu i jej wyniku.

Jak określić wymagania CDS dla nowego systemu obronnego

Wczesne określenie wymagań CDS w programie pozwala uniknąć kosztownych późnych przeróbek architektonicznych wynikających z traktowania transferu między domenami jako rzeczy drugorzędnej. Proces określania wymagań powinien prowadzić do formalnego dokumentu Wymagań dotyczących Transferu Między Domenami, który staje się częścią bazowej linii wymagań bezpieczeństwa systemu.

Krok 1 — Zidentyfikuj wszystkie przepływy danych między domenami. Sporządź mapę każdego przepływu danych w systemie, który przekracza granicę klasyfikacji. Dla każdego przepływu udokumentuj: źródłowy i docelowy poziom klasyfikacji, typ i format danych, kierunek transferu, wymagania dotyczące wolumenu i opóźnień oraz potrzebę operacyjną, którą przepływ wspiera. Ten wykaz stanowi fundament dla wszystkich kolejnych decyzji.

Krok 2 — Określ właściwe ramy akredytacyjne. Ustal, czy program będzie korzystał z US UCDMO, NATO, EU-ACC czy ram krajowych. Decyduje to, które listy produktów są autorytatywne i który organ akredytujący musi zatwierdzić pakiet akredytacyjny lokalizacji. Zaangażuj organ akredytujący wcześnie — jego opinia na temat akceptowalnych architektur może zaoszczędzić miesięcy przeróbek.

Krok 3 — Wybierz architekturę CDS. Dopasuj architekturę (dioda danych, strażnik high-to-low, strażnik dwustronny) do charakterystyki przepływów danych. Preferuj prostsze architektury tam, gdzie jest to wykonalne operacyjnie — dioda danych spełniająca wymaganie jest lepsza niż strażnik dwustronny wprowadzający niepotrzebną złożoność i powierzchnię ataku.

Krok 4 — Zdefiniuj politykę inspekcji treści. Dla każdego zatwierdzonego przepływu danych określ dokładne reguły inspekcji: dozwolone typy plików, maksymalny rozmiar pliku, definicje schematów dla danych strukturyzowanych, wymagania dotyczące skanowania złośliwego oprogramowania oraz reguły postępowania w przypadku nieudanej inspekcji. Dokument polityki jest formalnym produktem, który musi zostać zatwierdzony jako część pakietu akredytacyjnego.

Krok 5 — Zaprojektuj interfejs integracyjny. Wybierz wzorzec integracji i zaprojektuj interfejsy aplikacji do CDS. Upewnij się, że aplikacja obsługuje odrzucenia w odpowiedni sposób i rejestruje wszystkie próby transferu.

Krok 6 — Zbuduj i przetestuj na reprezentatywnej instancji CDS. Uzyskaj jednostkę testową od dostawcy i zbuduj zautomatyzowane testy integracyjne obejmujące: zatwierdzane dane przechodzące przez system, blokowanie odrzuconych danych, obsługę zniekształconych danych oraz tryby awarii CDS.

Krok 7 — Przygotuj pakiet akredytacyjny dla lokalizacji. Skompiluj dokumentację akredytacyjną i złóż ją do organu akredytującego z odpowiednim wyprzedzeniem przed planowaną datą uruchomienia. Zaplanuj 3–9 miesięcy czasu przeglądu.

Dla programów, w których wymaganie CDS zostaje zidentyfikowane późno — po tym, jak architektura aplikacji jest już zdefiniowana — praca integracyjna jest bardziej złożona, ale te same zasady mają zastosowanie. Zaangażuj zespół integracyjny dostawcy CDS wcześnie: mają doświadczenie w adaptowaniu swojego produktu do różnych architektur aplikacji i mogą wskazać ścieżkę integracji o najmniejszym tarciu dla Twojej konkretnej sytuacji. Aby uzyskać wskazówki dotyczące tego, jak integracja CDS wpisuje się w szerszą bezpieczną architekturę chmury, zapoznaj się z naszym artykułem na temat architektury zero-trust dla sieci wojskowych oraz tego, jak wzorce wdrożeń air-gapped uzupełniają ścieżki transferu kontrolowane przez CDS. Informacje o zarządzaniu sekretami i kluczami, które muszą towarzyszyć każdemu wdrożeniu CDS, znajdziesz w artykule zarządzanie sekretami w potoklach CI/CD sektora obronnego.