Architektura rozwiązania między domenami dla tajnych sieci wojskowych

Autor: Zespół inżynierów Corvus Intelligence · O zespole →

24 czerwca 2026 12 min czytania

Gdy wojskowy system informatyczny musi przenieść dane z sieci SECRET do sieci UNCLASSIFIED — lub ze środowiska TS/SCI do sieci partnera koalicyjnego — nie może po prostu kierować ruchu przez standardową zaporę sieciową. Bariera klasyfikacyjna nie jest problemem kontroli dostępu rozwiązywalnym przez politykę sieci. Jest to problem integralności treści: sama informacja może zawierać oznaczenia, przedziały lub osadzone elementy danych, które nie mogą opuścić enklawy wyższej klasyfikacji. Mechanizmem zaprojektowanym do rozwiązania tego problemu jest rozwiązanie między domenami, a właściwe jego zaprojektowanie wymaga zrozumienia architektury strażnika, logiki filtrowania treści, standardów oznaczania oraz rządowego procesu akredytacji, który zazwyczaj trwa dłużej niż chroniona przez niego aplikacja.

Niniejszy artykuł wyjaśnia, jak działają strażnicy CDS od wewnątrz — model monitora referencyjnego stanowiący podstawę każdego zatwierdzonego produktu, logika reguł filtrowania implementująca egzekwowanie oznaczeń CAPCO, techniki inspekcji specyficzne dla protokołów dla potoków XML i SMTP oraz ścieżka akredytacji NSA, która określa, czy wdrożenie jest prawnie autoryzowane do działania. Artykuł jest przeznaczony dla inżynierów i menedżerów programów, którzy muszą zrozumieć ograniczenia przed podjęciem decyzji o architekturze.

Czym jest rozwiązanie między domenami i kiedy jest wymagane

Rozwiązanie między domenami to produkt lub system egzekwujący politykę bezpieczeństwa podczas przenoszenia danych między sieciami akredytowanymi na różnych poziomach klasyfikacji lub z niekompatybilnymi kontrolami dostępu. Termin obejmuje sprzętowe diody danych, programowe dwukierunkowe strażniki i ich kombinacje. To, co odróżnia CDS od zwykłej bramy sieciowej, to fakt, że działa na warstwie treści, a nie warstwie pakietów — sprawdza ładunki, odczytuje oznaczenia klasyfikacyjne, stosuje ustrukturyzowane reguły filtrowania i podejmuje decyzję zezwól/odrzuć dla każdego elementu danych indywidualnie.

CDS jest wymagany, gdy jednocześnie spełnione są dwa warunki: sieć źródłowa zawiera informacje na wyższym poziomie klasyfikacji niż sieć docelowa jest akredytowana do odbioru, a wymóg operacyjny polega na przesłaniu części — ale nie wszystkich — tych informacji do sieci niższego poziomu. Jeśli nic nie powinno przepływać z poziomu wysokiego do niskiego, izolacja fizyczna (przerwa powietrzna) jest tańsza i bezpieczniejsza. Jeśli wszystko po stronie wysokiej może trafić do strony niskiej, sieci powinny zostać połączone lub sieć docelowa powinna zostać ponownie akredytowana. To właśnie przypadek selektywnego transferu wymaga CDS.

Typowe scenariusze wymagające CDS w programach obronnych obejmują: przekazywanie oczyszczonych danych śledzenia z tajnego wspólnego obrazu operacyjnego do jawnego wyświetlacza partnera koalicyjnego; publikowanie releasowalnych produktów wywiadowczych ze środowiska analitycznego TS/SCI do sieci dystrybucji SECRET; przesyłanie danych sensorycznych z tajnej platformy zbierania danych do jawnego archiwum do długoterminowego przechowywania; oraz łączenie krajowej sieci wywiadowczej z akredytowaną siecią kombinowaną NATO, gdzie schematy klasyfikacji różnią się. W każdym przypadku CDS jest mechanizmem egzekwowania granicy — a jego akredytacja daje łączącej instancji pewność, że granica jest prawidłowo egzekwowana.

Alternatywą dla CDS w niektórych ograniczonych scenariuszach jest ręczny przegląd: ludzki recenzent czyta dokument, ustala, że może zostać udostępniony, i przepisuje lub redaguje treść w sieci niższego poziomu. Jest to oryginalne "rozwiązanie" między domenami i nadal jest stosowane przy transferach o niskim wolumenie i wysokiej wrażliwości, gdzie automatyczne filtrowanie nie może być zaufane do wychwycenia wszystkich wrażliwych treści. Automatyczne produkty CDS są odpowiednie tylko wtedy, gdy treść jest wystarczająco ustrukturyzowana (oznaczony XML, SMTP z nagłówkami klasyfikacyjnymi, dobrze zdefiniowane formaty wiadomości), że filtr może niezawodnie egzekwować politykę bez ludzkiego osądu dla każdego transferu. Nieustrukturyzowany tekst swobodny — oceny narracyjne, raporty analityczne, szacunki dowódcy — często nadal wymaga przeglądu przez człowieka przed udostępnieniem, nawet gdy strażnik CDS jest obecny dla technicznego transferu.

Dla programów wymagających zajęcia się nie tylko mechanizmem transferu, ale szerszą postawą bezpieczeństwa tajnego środowiska, architektura zero trust dla oprogramowania obronnego zapewnia otaczającą strukturę kontroli dostępu, w którą integruje się CDS.

Architektury strażników CDS

Cztery wzorce architektoniczne obejmują większość wdrożeń CDS. Każdy z nich wymienia zapewnienie bezpieczeństwa, złożoność operacyjną i możliwości wzajemnie względem siebie.

Sprzętowa dioda danych. Urządzenie fizyczne wykorzystujące izolację optyczną lub elektryczną, które gwarantuje jednokierunkowy przepływ danych na poziomie sprzętowym. Elektrony — a co za tym idzie sygnały — nie mogą poruszać się w zablokowanym kierunku. Dioda między siecią tajną a jawną zapewnia, że nawet jeśli oprogramowanie po stronie niskiej jest w pełni skompromitowane, żaden sygnał ze strony niskiej nie może dotrzeć do strony wysokiej. Ograniczenie jest ścisłe: protokół aplikacji musi tolerować przepływ jednostronny. Mechanizm potwierdzania TCP nie działa przez diodę; strumieniowanie UDP, syslog i replikacja plików przez niestandardowe protokoły działają. Diody są odpowiednie do masowego jednokierunkowego eksportu — strumieniowania sensorów, replikacji logów, dystrybucji wideo — gdzie strona wysoka nigdy nie potrzebuje potwierdzenia dostarczenia.

Dwukierunkowy strażnik z oddzielonymi procesami proxy. Najczęstsza architektura dla aplikacji wymagających protokołów żądanie-odpowiedź. Strażnik uruchamia proces proxy po stronie wysokiej i proces proxy po stronie niskiej bez wspólnej przestrzeni adresowej, wspólnego systemu plików lub bezpośredniej komunikacji między procesami między nimi. Jedyna ścieżka z poziomu wysokiego do niskiego — i z niskiego do wysokiego — przechodzi przez jądro strażnika, które egzekwuje politykę bezpieczeństwa dla każdego transferu. Aplikacja po stronie wysokiej łączy się z proxy po stronie wysokiej; aplikacja po stronie niskiej łączy się z proxy po stronie niskiej. Z perspektywy sieci każda strona widzi tylko swój własny proxy. Jądro strażnika jest monitorem referencyjnym — małym, formalnie określonym, niezależnie ocenianym komponentem, którego jedyną funkcją jest egzekwowanie polityki transferu.

Strażnik filtrowania treści. Strażnik, którego głównym mechanizmem egzekwowania jest inspekcja treści — parsowanie ładunku, wyodrębnianie oznaczeń klasyfikacyjnych, dopasowywanie do reguł filtrowania oraz przepuszczanie, odrzucanie lub oczyszczanie treści przed przekazaniem dalej. Strażnicy filtrowania treści implementują słownik oznaczeń CAPCO jako język polityki. Są odpowiedni, gdy przekazywane dane są ustrukturyzowane i dobrze oznaczone, a polityka wymaga selektywnego przepuszczania, a nie blokowania hurtowego. Większość nowoczesnych dwukierunkowych strażników zawiera filtr treści jako pierwszy etap po dwukierunkowym oddzieleniu.

Model monitora referencyjnego. Fundamentalna zasada bezpieczeństwa implementowana przez wszystkie cztery architektury. Monitor referencyjny to komponent, który: pośredniczy w każdym żądaniu dostępu między podmiotem (nadawcą) a obiektem (przesyłanym elementem danych); jest zawsze wywoływany (żaden transfer go nie omija); jest odporny na manipulacje (nie może być modyfikowany ani wyłączany przez żadną ze stron); i jest wystarczająco mały, aby można go było formalnie zweryfikować. W terminologii CDS monitorem referencyjnym jest jądro strażnika — a jego właściwości odporności na manipulacje i kompletnego pośrednictwa są tym, co ewaluatorzy weryfikują podczas procesu akredytacji. Produkt CDS, który umożliwia transfery omijające jądro strażnika w jakichkolwiek warunkach — tryb konserwacji, awaryjne przełączenie przy wysokim obciążeniu, stan błędu — nie spełnia wymogu monitora referencyjnego i nie może być akredytowany dla granicy sieci tajnych.

Poniższy diagram przedstawia architekturę dwukierunkowego strażnika z oddzielonymi procesami proxy:

  ┌──────────────────────┐          ┌──────────────────────┐
  │  SECRET Network       │          │  UNCLASSIFIED Network │
  │  (High Side)          │          │  (Low Side)           │
  │                       │          │                       │
  │  ┌─────────────────┐  │          │  ┌─────────────────┐  │
  │  │  C2 Application │  │          │  │  COP Display    │  │
  │  └────────┬────────┘  │          │  └────────▲────────┘  │
  │           │            │          │           │            │
  │  ┌────────▼────────┐  │          │  ┌────────┴────────┐  │
  │  │  High-Side Proxy│  │          │  │ Low-Side Proxy  │  │
  └──┴────────┬────────┴──┘          └──┴────────▲────────┴──┘
              │                                   │
              │         ┌─────────────────┐       │
              └────────►│  Guard Kernel   ├───────┘
                        │  (Reference     │
                        │   Monitor)      │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Filter    │  │
                        │  │ Rules     │  │
                        │  │ (CAPCO)   │  │
                        │  └───────────┘  │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Audit Log │  │
                        │  │ (Signed)  │  │
                        │  └───────────┘  │
                        └─────────────────┘
                        Physical separation
                        of proxy processes
                        No shared memory/FS

Filtrowanie oparte na treści: co sprawdzają strażnicy

Filtrowanie oparte na treści to mechanizm nadający strażnikom CDS możliwość selektywnego przepuszczania. Zamiast blokować wszystko lub przepuszczać wszystko, strażnik filtrowania treści odczytuje dane, wyodrębnia pola istotne dla bezpieczeństwa, stosuje reguły polityki i podejmuje decyzję zezwól/odrzuć/oczyść dla każdej wiadomości.

Parsowanie oznaczeń CAPCO. Podstawą filtrowania treści w tajnych systemach USA jest standard oznaczeń CAPCO, który definiuje kontrolowany słownik tokenów pojawiających się w banerach klasyfikacyjnych, oznaczeniach fragmentów i strukturalnych polach metadanych. Parser CAPCO strażnika odczytuje element metadanych klasyfikacyjnych z każdej przychodzącej wiadomości i wyodrębnia tokeny składowe. Dla wiadomości oznaczonej SECRET//SI//REL TO USA,GBR parser generuje: poziom klasyfikacji = SECRET; przedział SCI = SI; kontrola rozpowszechniania = REL TO; releasowalność = USA, GBR. Każdy token jest następnie sprawdzany w macierzy polityki dla sieci docelowej. Jeśli sieć docelowa nie jest akredytowana dla przedziału SI, transfer jest odrzucany. Jeśli sieć docelowa jest akredytowana dla treści REL TO GBR, transfer jest dozwolony — ale filtr nadal sprawdza, czy jakiekolwiek pole w treści wiadomości nosi wyższe oznaczenie niż twierdzą oznaczenia na poziomie dokumentu.

Egzekwowanie wrażliwego przedziału. Egzekwowanie przedziału SCI wymaga, aby strażnik rozpoznawał pełen zestaw tokenów przedziałów zdefiniowanych w obowiązującym przewodniku klasyfikacyjnym. Najczęstsze przedziały w systemach USA to SI (Signals Intelligence), TK (Talent Keyhole, zobrazowanie z kosmosu), HCS (Humint Control System) i G (Gamma, podprzedział SI). Każdy musi być sprawdzany indywidualnie względem akredytacji przedziałowej enklawy docelowej. Sieć docelowa akredytowana dla SI, ale nie dla TK, nie może otrzymywać wiadomości zawierających oznaczenie TK — nawet jeśli klasyfikacja na poziomie dokumentu mieści się w dozwolonym zakresie.

Egzekwowanie oznaczeń fragmentów. Sklasyfikowany dokument często zawiera akapity, sekcje lub elementy danych o różnych poziomach wrażliwości. CAPCO wymaga, aby każdy fragment miał własne oznaczenie. Strażnik egzekwujący oznaczenia fragmentów musi parsować nie tylko baner na poziomie dokumentu, ale każdy tag (S//SI) lub (U//FOUO) na poziomie akapitu i podejmować oddzielną decyzję polityczną dla każdego. Oczyszczanie — usuwanie fragmentów niespełniających polityki przy przekazywaniu pozostałych — jest bardziej złożone niż całkowite odrzucenie, ale jest operacyjnie niezbędne dla dokumentów o mieszanej treści.

Usuwanie załączników. Wiadomości SMTP i ładunki HTTP multipart często zawierają załączniki, które strażnik musi sprawdzać niezależnie od treści wiadomości. Każda część załącznika jest parsowana oddzielnie: typ zawartości MIME określa używany parser, załącznik jest sprawdzany pod kątem osadzonych metadanych klasyfikacyjnych (właściwości dokumentów PDF, właściwości niestandardowe Word, pola EXIF obrazów), a polityka jest stosowana do każdego załącznika indywidualnie. Załączniki w formatach, których strażnik nie może parsować — nierozpoznane formaty binarne, zaszyfrowane archiwa — są domyślnie odrzucane, nigdy nie przepuszczane bez inspekcji.

Interakcja między egzekwowaniem oznaczeń CAPCO na warstwie CDS a bazowym modelem danych jest szczegółowo opisana w artykule o wojskowej fuzji danych, który obejmuje propagację klasyfikacji przez wieloźródłową bazę danych śledzenia. Dla środowisk NATO powiązanie między równoważnymi oznaczeniami CAPCO a standardem etykietowania poufności NATO jest omówione w materiałach referencyjnych dotyczących implementacji etykietowania STANAG 4774/4778.

Formaty danych i protokoły obsługiwane przez nowoczesne produkty CDS

Strażnik CDS jest użyteczny tylko w takim stopniu, w jakim obsługuje formaty faktycznie używane przez aplikację. Parser strażnika musi rozumieć format wystarczająco głęboko, aby wyodrębnić pola klasyfikacyjne i sprawdzić treść — powierzchowna inspekcja nagłówków jest niewystarczająca.

Format / Protokół	Lokalizacja pola klasyfikacyjnego	Typowe zastosowanie wojskowe	Złożoność inspekcji strażnika
XML (IC-ISM / UCORE)	Atrybuty przestrzeni nazw na elemencie głównym i każdym sklasyfikowanym fragmencie	Wiadomości śledzenia, produkty wywiadowcze, raporty NiemXML	Wysoka — pełna ocena XPath z uwzględnieniem schematu
JSON z metadanymi ISM	Pole `ism:classification` na najwyższym poziomie lub osadzone obiekty oznaczeń	Ładunki REST API, nowoczesne mikroserwisy C2	Średnia — zależna od schematu, wymagana rekurencyjna inspekcja
SMTP / MIME	Nagłówek `X-Classification:` + baner treści + oznaczenie każdego załącznika	Dystrybucja produktów wywiadowczych, dystrybucja SITREP	Wysoka — rekurencyjne parsowanie MIME, wykrywanie typów załączników
HTTP/HTTPS (REST)	Niestandardowy nagłówek + treść ładunku	Wywołania API między usługami tajnymi i jawnymi	Średnia — wymagane zakończenie TLS + ponowna inspekcja treści
MTF (Message Text Format)	Pole CLASSIFICATION w zestawie nagłówków wiadomości	Wiadomości wojskowe NATO/legacy, USMTF, ADatP-3	Średnia — format o stałych polach, dobrze określone parsowanie
PDF / dokumenty Office	Niestandardowe właściwości dokumentu, metadane XMP, tekst baneru w treści	Gotowe produkty wywiadowcze, rozkazy, plany	Bardzo wysoka — osadzone obiekty, makra, wymagane usuwanie metadanych
Wideo (RTP/RTSP)	Nagłówki metadanych strumienia (jeśli obecne); tekst nakładki na klatkach	Łącze w dół ISR wideo, zasilania UAV	Bardzo wysoka — zazwyczaj wymaga diody + dedykowanego proxy wideo

Dla wiadomości wojskowych opartych na XML reguły filtrowania są wyrażone w XPath. Reguła odrzucająca dowolną wiadomość zawierającą token przedziału TK wygląda następująco:

<!-- Guard filter rule: reject if TK compartment is present -->
<FilterRule id="REJ-TK-001" action="REJECT">
  <Description>Reject messages carrying Talent Keyhole (TK) compartment</Description>
  <Condition>
    <XPathExpression>
      //*[contains(
        translate(
          @ism:SCIcontrols,
          'ABCDEFGHIJKLMNOPQRSTUVWXYZ',
          'abcdefghijklmnopqrstuvwxyz'
        ),
        'tk'
      )]
    </XPathExpression>
  </Condition>
  <AuditMessage>Transfer rejected: TK compartment detected in payload</AuditMessage>
</FilterRule>

<!-- Sanitization rule: strip SI-marked portion elements before forwarding -->
<FilterRule id="SAN-SI-001" action="SANITIZE">
  <Description>Strip SI-marked portions from otherwise-releasable documents</Description>
  <Condition>
    <XPathExpression>//*[@ism:SCIcontrols='SI']</XPathExpression>
  </Condition>
  <SanitizeAction>REMOVE_ELEMENT</SanitizeAction>
  <AuditMessage>Sanitized: SI-marked element removed from document</AuditMessage>
</FilterRule>

Zatwierdzenie NSA i proces akredytacji

Strażnik CDS chroniący połączenie między dwiema tajnymi sieciami rządu USA musi zostać zatwierdzony przez NSA/CSS przed rozpoczęciem działania. Nie ma ścieżki zwolnienia dla pilności operacyjnej — wdrożenie niezatwierdzonego CDS jest zgłaszalnym incydentem bezpieczeństwa. Zrozumienie procesu akredytacji i jego harmonogramu jest warunkiem wstępnym dla każdego programu obejmującego tajną granicę.

Lista zatwierdzonych produktów NSA/CSS (EPL). NSA ocenia produkty CDS i publikuje wyniki na Liście zatwierdzonych produktów. Wpis na EPL certyfikuje, że konkretna wersja produktu w konkretnej konfiguracji prawidłowo implementuje model monitora referencyjnego i jest odporna na klasy ataków testowane przez ewaluatorów. Wpis EPL określa dokładny model sprzętu i wersję firmware, wersję oprogramowania i opcje konfiguracyjne, które zostały ocenione. Odchylenie od ocenianej konfiguracji — nawet zastosowanie łatki systemu operacyjnego, która nie była częścią ocenianej linii bazowej — wymaga ponownej oceny lub autoryzacji odchylenia. Programy muszą śledzić, której wersji EPL odpowiada ich wdrożony strażnik i utrzymywać tę korespondencję przez całe życie operacyjne strażnika.

Inicjatywa Raise the Bar (RTB). Po serii incydentów, w których niedostatecznie zaprojektowane strażniki dopuściły do nieprawidłowego przesłania danych, NSA/CSS wydało wymagania Raise the Bar dla produktów CDS. RTB nakazuje sprzętowe oddzielenie ścieżek przetwarzania po stronie wysokiej i niskiej, formalne udokumentowanie każdej reguły filtrowania i jej uzasadnienia bezpieczeństwa, kryptograficznie podpisane logi audytu (tak aby manipulowanie logami było wykrywalne), niezależną weryfikację logiki strażnika przez stronę trzecią oraz zdefiniowaną procedurę łatania obejmującą ponowną weryfikację po zmianach istotnych dla bezpieczeństwa. Produkty spełniające wymagania RTB są wymienione na EPL z wyraźnym oznaczeniem RTB. Produkty nie-RTB mogą nadal znajdować się na starszych listach EPL, ale nie mogą być nowo zatwierdzane dla granic tajnych sieci rządu USA.

Lista zatwierdzonych produktów ujednoliconych możliwości DISA (UC APL). Dla programów DoD wpis na liście DISA UC APL jest wymagany oprócz EPL NSA. Ocena UC APL koncentruje się na interoperacyjności z infrastrukturą sieci DoD i zgodności z technicznymi przewodnikami implementacji bezpieczeństwa DoD (STIG). Produkt może być na EPL NSA, ale nie na UC APL lub odwrotnie — oba są wymagane dla większości wdrożeń tajnych sieci DoD. Przed oceną kandydujących produktów CDS należy sprawdzić obie listy.

Specyficzna dla lokalizacji Autoryzacja do Działania (ATO). Nawet z produktem EPL/UC APL, każde wdrożenie wymaga specyficznej dla lokalizacji ATO obejmującej: konkretną wdrożoną konfigurację sprzętu i oprogramowania; topologię sieci i fizyczne bezpieczeństwo instalacji strażnika; zestaw reguł filtrowania i jego związek z politykami klasyfikacji połączonych sieci; procedury ciągłego monitorowania; oraz proces zarządzania poprawkami i zmianami konfiguracji. Pakiet ATO jest przeglądany przez Urzędnika Autoryzującego (AO) dla systemów po obu stronach granicy. Dla połączeń między sieciami należącymi do różnych agencji wymagane jest dwustronne porozumienie między dwoma AO przed udzieleniem ATO. Harmonogram: 6 do 18 miesięcy dla produktu już na EPL w nieskomplikowanej konfiguracji.

Wzorce integracji dla potoków C2 i ISR

Integracja strażnika CDS z operacyjnym potokiem C2 lub ISR wymaga przemyślenia zarówno architektury przepływu danych, jak i ograniczeń wydajności wprowadzanych przez strażnika.

Wzorzec SECRET-to-UNCLASSIFIED COP. Najczęstsza integracja to potok publikuj-subskrybuj, gdzie broker SECRET zasila tajne aktualizacje śledzenia, a strażnik CDS subskrybuje brokera SECRET, sprawdza każdą aktualizację i ponownie publikuje oczyszczone aktualizacje do brokera UNCLASSIFIED, do którego subskrybują partnerzy koalicyjni lub konsumenci po stronie niskiej. Strażnik w tej architekturze działa jako filtrujący subskrybent po stronie wysokiej i produkujący wydawca po stronie niskiej — nigdy jako router przekazujący. Zapewnia to brak bezpośredniego połączenia między dwoma brokerami.

SECRET Network                     UNCLASSIFIED Network
─────────────                      ────────────────────

┌─────────────┐   track updates   ┌─────────────────────────────┐
│ SECRET      │ ─────────────────►│     CDS Guard               │
│ Message     │                   │                             │
│ Broker      │                   │  High-Side     Low-Side     │
│             │                   │  Subscriber    Publisher    │
│             │                   │      │              │       │
│             │                   │      ▼              │       │
│             │                   │  CAPCO Filter       │       │
│             │                   │  SI/TK/HCS check    │       │
│             │                   │  Sanitize/Reject     │       │
│             │                   │      │              │       │
│             │                   │      └──────────────►       │
└─────────────┘                   └─────────────────────────────┘
                                               │
                                               ▼ sanitized updates
                                   ┌───────────────────┐
                                   │ UNCLASSIFIED      │
                                   │ Message Broker    │
                                   └─────────┬─────────┘
                                             │
                                             ▼
                                   ┌───────────────────┐
                                   │ Coalition COP /   │
                                   │ UNCLASSIFIED      │
                                   │ Display           │
                                   └───────────────────┘

Planowanie opóźnień. Strażnik CDS wprowadza opóźnienie przetwarzania dla każdej sprawdzanej wiadomości. Dla małych wiadomości aktualizacji śledzenia XML (poniżej 4 KB) komercyjne strażniki zazwyczaj dodają od 50 do 200 milisekund opóźnienia inspekcji. Dla dużych wiadomości zawierających binarne załączniki lub wymagających oczyszczania wielu fragmentów opóźnienie może wynosić od 500 milisekund do 2 sekund. Dla dokumentów PDF lub złożonych wiadomości MIME przetwarzanie może trwać kilka sekund. Musi to być uwzględnione w częstotliwości odświeżania COP i SLA dla dystrybucji produktów wywiadowczych. Oceny przepustowości strażnika są publikowane w dokumentacji EPL — przed zaangażowaniem się w produkt należy zweryfikować, czy oceniana przepustowość przy rozmiarze i złożoności wiadomości aplikacji jest wystarczająca.

Ścieżki danych sensorów ISR. Dla sensorów ISR działających na tajnym poziomie, które muszą zasilać dane konsumentów na niższych poziomach klasyfikacji, ścieżka danych zazwyczaj obejmuje etap przetwarzania na tajnym poziomie, który produkuje oczyszczone produkty pochodne, które następnie przekraczają granicę CDS. Surowe dane sensorów (zobrazowanie pełnej wierności, surowe przechwycenia SIGINT) nigdy nie powinny być projektowane do przepływu przez strażnika CDS — klasyfikacja surowych danych ISR jest zazwyczaj znacznie wyższa niż to, co może otrzymać strona niska, a filtrowanie treści surowych danych sensorów jest zawodne. Wzorzec projektowy to: przetwarzaj na poziomie klasyfikacji danych, produkuj produkty pochodne pozbawione wrażliwych wskaźników źródłowych i przez strażnika przekazuj tylko produkty pochodne.

Bezpieczeństwo operacyjne wdrożeń CDS

Strażnik CDS jest celem o wysokiej wartości właśnie dlatego, że jego skompromitowanie jest równoznaczne z eliminacją tajnej granicy. Operacyjne kontrole bezpieczeństwa wokół wdrożonego strażnika muszą być proporcjonalne do tego ryzyka.

Bezpieczeństwo fizyczne. Sprzęt strażnika musi być zainstalowany w fizycznie bezpiecznym miejscu — zamkniętym pomieszczeniu sprzętowym z kontrolowanym dostępem i rejestrowaniem odwiedzin. Zarówno połączenie sieciowe po stronie wysokiej, jak i sprzęt strażnika muszą znajdować się w fizycznym peryferie bezpieczeństwa sieci wyższej klasyfikacji. Manipulowanie strażnikiem — wstawianie urządzenia z ukrytym kanałem do połączenia sieciowego, wymiana firmware — to realne zagrożenie, któremu adresują kontrole fizyczne.

Zarządzanie poza pasmem. Interfejs zarządzania strażnikiem musi znajdować się w dedykowanej fizycznej sieci oddzielonej od operacyjnych sieci po stronie wysokiej i niskiej. Ruch zarządzający — zmiany konfiguracji, aktualizacje oprogramowania, pobieranie logów — przesyłany przez którąkolwiek z operacyjnych sieci tworzy wektor ukrytego kanału. Stacje robocze do zarządzania powinny znajdować się wewnątrz peryferii bezpieczeństwa wyższej klasyfikacji i być odpowiednio akredytowane.

Integralność logów i wykrywanie manipulacji. Logi audytu CDS są głównym dowodem prawidłowego egzekwowania granicy. Logi muszą być kryptograficznie chronione — każdy rekord logu zawiera HMAC nad zawartością rekordu i hash poprzedniego rekordu (łańcuch hash). Dzięki temu wstawienie, usunięcie lub modyfikacja dowolnego rekordu jest wykrywalna podczas weryfikacji łańcucha. Logi muszą być zapisywane w systemie, do którego ani sieć po stronie wysokiej, ani po stronie niskiej nie może pisać ani usuwać — dedykowanym serwerze logów dostępnym tylko dla administratora bezpieczeństwa przez sieć zarządzania poza pasmem. Przegląd logów musi być aktywną, codzienną czynnością: anomalie odrzuceń, niezwykłe wolumeny wiadomości lub powtarzające się naruszenia polityki przez tego samego nadawcę są wskaźnikami sondowania lub ataku.

Kontrola zmian konfiguracji. Każda zmiana zestawu reguł filtrowania — dodanie reguły, modyfikacja warunku, usunięcie reguły — musi przejść przez udokumentowany proces zmian obejmujący: pisemne żądanie zmiany z uzasadnieniem bezpieczeństwa; niezależny przegląd przez drugiego oficera bezpieczeństwa; wykonanie testów na reprezentacyjnej próbce ruchu; oraz audyt po zmianie pierwszych 24 godzin decyzji produkcyjnych w celu weryfikacji, że reguła zachowuje się zgodnie z zamierzeniem. Zmiany, które nie przeszły przez ten proces, nie mogą być stosowane do produkcyjnych konfiguracji strażnika. Zamrożenie zmian powinno obowiązywać podczas okresów intensywnych operacji, kiedy błędna konfiguracja strażnika byłaby najbardziej szkodliwa.

Zarządzanie poprawkami. Poprawki bezpieczeństwa dla systemu operacyjnego strażnika i aplikacji wymagają ostrożnego postępowania. Zastosowanie poprawki, która nie jest częścią ocenianej konfiguracji, może unieważnić ATO — a niestosowanie poprawek bezpieczeństwa tworzy exploitowalne luki. Procedura to: odebranie i ocena poprawki; określenie, czy wpływa na ocenianą linię bazową konfiguracji; jeśli tak, konsultacja z dostawcą EPL i uzyskanie autoryzacji odchylenia od oceny lub zaplanowanie ponownej oceny; testowanie poprawki w izolowanym środowisku strażnika odzwierciedlającym produkcję; zastosowanie do produkcji podczas zaplanowanego okna konserwacyjnego z krótką przerwą w usłudze; weryfikacja, że zachowanie reguł filtrowania nie zmieniło się po łataniu.

Testy czerwonego zespołu. Coroczne testy penetracyjne instalacji CDS powinny być wymaganiem w planie bezpieczeństwa. Zakres testu powinien obejmować: próby wyodrębnienia tajnych treści przez interfejs po stronie niskiej przy użyciu ataków wstrzyknięcia formatu i kodowania; próby eksploatacji ukrytych kanałów przez kanały czasowe, pamięci masowej i na poziomie protokołu; próby dostępu do interfejsu zarządzania strażnikiem z sieci operacyjnych; oraz scenariusze próby fizycznego manipulowania. Wyniki testów czerwonego zespołu są bezpośrednio włączane do raportu ciągłego monitorowania i mogą wyzwalać zmiany konfiguracji lub ponowną ocenę.

Kluczowy wniosek: Najczęstszy operacyjny tryb awarii w wdrożeniach CDS to nie luka w regule filtrowania — to dryf konfiguracji. Strażnik wdrożony i akredytowany w zdefiniowanej konfiguracji stopniowo odbiega od tej konfiguracji przez nieautoryzowane poprawki, doraźne zmiany reguł i wymianę komponentów sprzętowych. Po 18 miesiącach działania bez formalnego audytu konfiguracji większość strażników działa w konfiguracji, która nigdy nie była oceniana. Wbuduj audyty konfiguracji do harmonogramu operacyjnego od samego początku.

Omów swój projekt

Projektujemy architektury integracji danych dla programów obronnych działających przez granice tajnych i jawnych sieci, w tym integrację CDS, potoki danych z uwzględnieniem CAPCO i łączność C2 wielodomenową.

Usługi integracji danych → Umów briefing

Niniejsza analiza została przygotowana przez inżynierów Corvus Intelligence, którzy tworzą oprogramowanie o krytycznym znaczeniu dla organizacji obronnych i rządowych. Dowiedz się więcej o naszym zespole →

Najczęściej zadawane pytania

Jaka jest różnica między rozwiązaniem między domenami a zaporą sieciową?

Zapora sieciowa egzekwuje kontrolę dostępu na warstwie sieciowej — zezwala lub odmawia połączeń między hostami na podstawie adresów IP, portów i protokołów. Rozwiązanie między domenami (CDS) działa na warstwie treści: sprawdza ładunek każdej wiadomości, weryfikuje obecność i poprawność oznaczeń klasyfikacyjnych, stosuje reguły filtrowania do samej treści i oczyszcza lub odrzuca transfer przed jego przekroczeniem do sieci niższej klasyfikacji. Zapora nie może odczytać oznaczeń CAPCO osadzonych w XML ani usunąć tajnych załączników z wiadomości SMTP; CDS jest zbudowany specjalnie do tych zadań. Produkty CDS podlegają również formalnej akredytacji rządowej (NSA/CSS EPL, DISA UC APL), której zwykłe zapory nie przechodzą.

Co oznacza skrót CAPCO i dlaczego jest używany w regułach filtrowania CDS?

CAPCO oznacza Controlled Access Program Coordination Office. Standardy CAPCO definiują kontrolowany słownik dla oznaczeń klasyfikacyjnych USA — ustrukturyzowane ciągi pojawiające się w banerach, oznaczeniach fragmentów i polach metadanych XML. Przykłady obejmują TOP SECRET//SI//REL TO USA,FVEY i SECRET//NOFORN. Reguły filtrowania strażnika CDS są pisane względem tych ustrukturyzowanych oznaczeń, ponieważ kodują precyzyjny poziom klasyfikacji, kontrole rozpowszechniania i releasowalność. Strażnik parsujący oznaczenie CAPCO wyodrębnia poziom klasyfikacji, przedziały SCI (SI, TK, HCS) i zastrzeżenia obsługi (NOFORN, ORCON, REL TO). Jeśli którykolwiek z tych tokenów przekracza to, do czego sieć docelowa jest autoryzowana, transfer jest odrzucany przed opuszczeniem przez ładunek enklawy źródłowej.

Czym jest dioda danych i kiedy jednokierunkowy strażnik jest niewystarczający?

Dioda danych to sprzętowo egzekwowane jednokierunkowe łącze wykorzystujące izolację optyczną lub podobną technologię, która zapewnia, że żaden sygnał nie może podróżować w zablokowanym kierunku. Diody są odpowiednie do masowego eksportu z tajnej sieci, gdy nigdy nie jest wymagany ruch odpowiedzi, np. zasilania wideo lub replikacji logów. Stają się niewystarczające, gdy protokół wymaga uzgadniania lub potwierdzenia, gdy aplikacja potrzebuje dwukierunkowej wymiany danych, lub gdy inspekcja treści jest wymagana przed transferem. W takich przypadkach potrzebny jest dwukierunkowy strażnik z oddzielnymi procesami proxy po stronie wysokiej i niskiej — egzekwujący model monitora referencyjnego.

Jak strażnik CDS egzekwuje NEED-TO-KNOW poza poziomem klasyfikacji?

Poziom klasyfikacji to tylko zewnętrzna granica. Wewnątrz poziomu klasyfikacji dodatkowe kontrole dostępu obejmują przedziały SCI (SI, TK, HCS), ograniczenia NOFORN, kontrole ORCON, oznaczenia REL TO i oznaczenia tylko dla wybranych oczu. Strażnik CDS egzekwuje te kontrole poprzez utrzymywanie macierzy polityki mapującej akredytację każdej sieci docelowej na zestaw dozwolonych tokenów oznaczeń. Obiekt oznaczony SECRET//REL TO USA,GBR jest dozwolony w sieci obejmującej użytkowników z poświadczeniem UK, ale odrzucany w sieci nie posiadającej autoryzacji REL TO GBR. Macierz ta musi być synchronizowana z dokumentacją akredytacyjną każdej podłączonej enklawy.

Czym jest inicjatywa NSA Raise the Bar i jak wpływa na zamówienia CDS?

Raise the Bar (RTB) to inicjatywa NSA/CSS, która ustanowiła bardziej rygorystyczne standardy oceny produktów CDS po incydentach, w których nieodpowiednie strażniki dopuściły do wycieku danych. Produkty zgodne z RTB muszą wykazać sprzętowe oddzielenie ścieżek przetwarzania po stronie wysokiej i niskiej, formalną dokumentację polityki bezpieczeństwa, kryptograficzną integralność logów, niezależną weryfikację logiki strażnika i zdefiniowany proces łatania i ponownej oceny. Produkty spełniające wymagania RTB są wymienione na EPL NSA/CSS z wyraźnym oznaczeniem RTB. Zamawianie CDS niezgodnego z RTB dla granic tajnych sieci jest zabronione zgodnie z obowiązującą polityką.

Jakie formaty plików filtrują nowoczesne strażniki CDS i jakie są ryzyka nieobsługiwanych formatów?

Nowoczesne produkty CDS obsługują XML (IC-ISM, UCORE, schemat NIEM), JSON z polami metadanych klasyfikacyjnych, SMTP z załącznikami MIME, HTTP/HTTPS z inspekcją ładunku, dokumenty PDF z osadzonymi metadanymi i formaty wiadomości MTF. Ryzyko z nieobsługiwanymi formatami to binarne przepuszczanie lub całkowite blokowanie: jeśli strażnik nie może parsować formatu, albo blokuje cały ruch tego typu (zakłócając operacje), albo przepuszcza go bez inspekcji (tworząc wektor wycieku). Nieznane formaty binarne muszą domyślnie być odrzucane, nigdy przepuszczane. Wszelkie nowe formaty danych wprowadzone do potoku chronionego przez CDS wymagają jawnej walidacji obsługi formatu podczas testów akredytacyjnych.

Jak strażnicy CDS powinni być integrowani w potok C2 zasilający zarówno konsumentów SECRET, jak i UNCLASSIFIED?

Standardowy wzorzec to topologia publikuj-subskrybuj z brokerami na klasyfikację i strażnikiem CDS na granicy. Broker SECRET odbiera wszystkie aktualizacje śledzenia i produkty wywiadowcze. Strażnik CDS subskrybuje brokera SECRET, sprawdza każdą wiadomość zgodnie ze skonfigurowaną polityką, usuwa pola zawierające oznaczenia z przedziałami i ponownie publikuje oczyszczone wiadomości do brokera UNCLASSIFIED. Strażnik nigdy nie wystawia bezpośredniego połączenia dwukierunkowego między dwoma brokerami. Opóźnienie wprowadzane przez strażnika (zazwyczaj 50–500 ms dla wiadomości tekstowych) musi być uwzględnione w planowaniu SLA dla częstotliwości aktualizacji COP.

Jakie wymagania dotyczące logowania mają zastosowanie do wdrożeń strażników CDS?

Strażnicy CDS muszą produkować odporne na manipulacje logi audytu każdej decyzji o transferze. Każdy rekord logu musi zawierać zsynchronizowany z GPS znacznik czasu UTC, podmiot wysyłający, enklawę docelową, hash ładunku wiadomości, wyodrębnione tokeny oznaczeń, wyzwoloną regułę polityki i wynik decyzji. Logi muszą być przechowywane w systemie, do którego ani sieć po stronie wysokiej, ani niskiej nie może pisać ani usuwać. Integralność logów jest egzekwowana przez łańcuch HMAC — każdy rekord zawiera HMAC poprzedniego rekordu, dzięki czemu każda modyfikacja jest wykrywalna. Okres przechowywania wynosi zazwyczaj minimum trzy lata dla logów audytu tajnych systemów.

Czy strażnik CDS może obsługiwać dane strumieniowe w czasie rzeczywistym, takie jak wideo lub zasilania śledzenia?

Tak, ale architektura różni się od transferu opartego na wiadomościach. Dla wideo standardowym podejściem jest jednokierunkowa dioda danych połączona z proxy transkodera wideo: tajny strumień wideo wchodzi do proxy po stronie wysokiej, które ponownie koduje do czystego strumienia bitowego usuwając wszystkie metadane, a oczyszczony strumień wychodzi przez diodę do wyświetlacza po stronie niskiej. Dla zasilań śledzenia w czasie rzeczywistym świadomy treści strażnik pośredniczy w każdej wiadomości aktualizacji śledzenia, sprawdzając pola klasyfikacyjne przed przekazaniem. Produkty CDS ocenione dla strumieniowania o wysokiej przepustowości istnieją na EPL, ale muszą być specjalnie oceniane dla szybkości wiadomości zamierzonego wdrożenia.

Jak długo zazwyczaj trwa akredytacja NSA/DISA nowego wdrożenia CDS?

Wdrożenie CDS wykorzystujące produkt już na EPL NSA/CSS i DISA UC APL zazwyczaj wymaga od 6 do 18 miesięcy przetwarzania specyficznego dla lokalizacji ATO, zakładając kompletny Plan Bezpieczeństwa i konfigurację zgodną z ocenianą linią bazową. Wdrożenia wykorzystujące niestandardowo opracowane komponenty strażnika wymagają pełnej oceny sponsorowanej przez rząd, zazwyczaj trwającej 18 do 36 miesięcy. Programy wdrażające przed zakończeniem akredytacji zazwyczaj napotykają nakazy przymusowego zamknięcia. Wbudowanie procesu ATO w harmonogram programu od samego początku, z realistycznymi harmonogramami, jest niezbędne dla każdego programu zależnego od CDS.