Wdrożenia w środowiskach air-gapped dla oprogramowania obronnego: wyzwania i najlepsze praktyki

Air gap to fizyczna izolacja systemu komputerowego lub sieci od niezabezpieczonych sieci, w tym publicznego internetu. Systemy z luką powietrzną nie posiadają przewodowych ani bezprzewodowych połączeń z sieciami zewnętrznymi; transfer danych wymaga fizycznego przenoszenia zatwierdzonych nośników lub jednokierunkowych urządzeń do transferu danych. Luki powietrzne stanowią najbardziej fundamentalną kontrolę bezpieczeństwa dla najbardziej wrażliwych tajnych systemów informacyjnych: żaden poziom zabezpieczeń programowych nie może zrekompensować fizycznego połączenia sieciowego, gdy model zagrożeń obejmuje państwowych aktorów o zaawansowanych ofensywnych zdolnościach cybernetycznych.

Wdrażanie i utrzymanie nowoczesnego oprogramowania w systemach air-gapped wymaga zasadniczo odmiennego podejścia inżynierskiego od wdrożeń podłączonych do internetu. Funkcje wygody, na których polegają zespoły deweloperskie — automatyczne menedżery pakietów pobierające zależności z publicznych repozytoriów, obrazy kontenerów pobierane z Docker Hub, potoki CI/CD sięgające do zewnętrznych usług SaaS — wszystkie zawodzą w środowiskach z luką powietrzną. Oprogramowanie musi działać bez żadnego z tych połączeń, a proces deweloperski i operacyjny musi być zaprojektowany tak, aby to obsługiwać od samego początku.

Co oznacza air gap i gdzie jest wymagany

Luki powietrzne są wymagane wszędzie tam, gdzie klasyfikacja lub wrażliwość przetwarzanych danych lub kontrolowanych systemów uzasadnia fizyczną izolację sieciową. W kontekście wojskowym:

Bezpieczne pomieszczenia do przetwarzania informacji niejawnych (SCIF) to fizycznie zabezpieczone pomieszczenia lub budynki, w których mogą być przetwarzane i omawiane informacje niejawne powyżej poziomu SECRET — w szczególności SCI (Sensitive Compartmented Information). Systemy komputerowe w SCIF obsługujące dane na poziomie SCI muszą być odizolowane od sieci nieakredytowanych do tego samego poziomu klasyfikacji.

Tajne sieci operacyjne — SECRET lub wyżej — są odizolowane od sieci jawnych. Transfer danych między poziomami klasyfikacji wymaga Cross-Domain Solution (CDS): systemu sprzętowo-programowego wymuszającego reguły transferu informacji między obydwoma poziomami sieci.

Sterowniki systemów uzbrojenia i systemy wbudowane — komputery sterowania ogniem, systemy nawigacyjne, sterowniki radarów i czujników — są izolowane od sieci operacyjnych jako część ich architektury bezpieczeństwa. Aktualizacje oprogramowania dla tych systemów dostarczane są przez interfejs serwisowy platformy, przy użyciu zatwierdzonych nośników.

Wdrożenie oprogramowania bez internetu: rejestry artefaktów i lustrzane kopie pakietów

W środowisku air-gapped każda zależność oprogramowania wymagana przez aplikację musi być obecna w środowisku przed wdrożeniem. Nic nie może być pobrane z internetu w czasie wdrażania. Wymaga to zbudowania wewnętrznego ekosystemu artefaktów odwzorowującego zewnętrzne zasoby, na których aplikacja normalnie by polegała.

Harbor to ukończony projekt CNCF i otwarty rejestr kontenerów, będący standardowym wyborem dla wewnętrznych rejestrów obrazów kontenerów w odizolowanych środowiskach obronnych. Harbor zapewnia: przechowywanie i replikację obrazów, skanowanie podatności (poprzez Trivy), weryfikację podpisów cyfrowych obrazów oraz kontrolę dostępu opartą na rolach. Zapełnienie rejestru Harbor wymaga procesu importowania wstępnie zatwierdzonych, wstępnie zeskanowanych obrazów kontenerów spoza luki powietrznej za pomocą zatwierdzonych nośników.

Offline'owe lustrzane kopie pakietów replikują publiczne repozytoria pakietów do użytku wewnątrz luki powietrznej. Dla Pythona wewnętrzne lustro PyPI (przy użyciu narzędzi takich jak bandersnatch lub devpi) obsługuje żądania pip z wnętrza środowiska. Dla npm instancja Nexus lub Artifactory (lub open-source'owy Verdaccio) obsługuje żądania npm. Lustro pakietów musi być zasilane i aktualizowane poprzez zatwierdzony proces transferu nośników.

Proces zarządzania zależnościami musi być jawny: przed rozpoczęciem prac nad funkcją, która będzie wdrożona w środowisku air-gapped, deweloper musi jawnie zidentyfikować wszystkie zależności (w tym przechodnie) i zweryfikować ich obecność w wewnętrznym lustrze. Dodanie nowej zależności wymaga wniosku o transfer nośnika i procesu zatwierdzenia.

Zarządzanie poprawkami: przetestowane pakiety i kontrola zmian

Zarządzanie poprawkami w środowiskach air-gapped nie może korzystać z automatycznych systemów pobierających aktualizacje z chmurowych usług dostawców. Zamiast tego wymaga zdefiniowanego, udokumentowanego procesu przenoszenia poprawek zza luki powietrznej do jej wnętrza, testowania ich w reprezentatywnym środowisku i stosowania w kontrolowany sposób.

Przygotowanie pakietu poprawek odbywa się poza luką powietrzną: zespół zarządzania poprawkami identyfikuje wymagane poprawki (z biuletynów bezpieczeństwa dostawców, katalogu CISA KEV i aktualizacji STIG), pobiera je ze źródeł dostawców, weryfikuje ich autentyczność (suma kontrolna i weryfikacja podpisu cyfrowego) i pakuje do transferu.

Transfer za pomocą zatwierdzonych wymiennych nośników jest standardowym mechanizmem przenoszenia poprawek przez lukę powietrzną. Typowe procedury obejmują: używanie wyłącznie nośników zarządzanych przez organizację, skanowanie antywirusowe nośników po obu stronach luki, używanie nośników jednokrotnego zapisu (dysków optycznych) dla nieodwracalnych śladów audytu, dokumentowanie każdego transferu.

Testowanie etapowe jest niezbędne dla odizolowanych systemów operacyjnych: poprawki muszą być testowane w środowisku przemieszczania odzwierciedlającym konfigurację produkcyjną przed zastosowaniem na produkcji. Poprawka destabilizująca odizolowany system produkcyjny nie może być wycofana przez proste pobranie poprzedniej wersji ze źródła internetowego.

Rotacja sekretów w środowiskach air-gapped

Sekrety — certyfikaty TLS, dane uwierzytelniające bazy danych, klucze API — wygasają i muszą być rotowane. W środowiskach air-gapped żaden z tych zautomatyzowanych mechanizmów nie działa, ponieważ polegają one na łączności sieciowej z urzędami certyfikacji i interfejsami API zarządzania sekretami, które są niedostępne z wnętrza luki powietrznej.

Sprzętowe moduły bezpieczeństwa (HSM) zapewniają korzeń zaufania dla operacji kryptograficznych w odizolowanych środowiskach tajnych. HSM (taki jak Thales Luna lub nCipher nShield) przechowuje klucze prywatne w odpornym na manipulacje sprzęcie, wykonuje operacje kryptograficzne bez ujawniania materiału kluczowego i zapewnia bezpieczeństwo walidowane przez FIPS 140-2 Poziom 3 lub 4.

Procedury offline vault i ceremonii kluczowych definiują sposób rotacji sekretów bez zautomatyzowanych narzędzi. Ceremonia kluczowa to formalna, udokumentowana procedura — z udziałem wielu upoważnionych osób — generowania, ładowania lub rotacji kluczy kryptograficznych. W przypadku rotacji certyfikatu TLS ceremonia obejmuje wygenerowanie nowego żądania certyfikatu, podpisanie go kluczem offline CA (przechowywanym w HSM) i dystrybucję nowego certyfikatu do systemów go używających za pomocą zatwierdzonych nośników.

CI/CD dla środowisk air-gapped

Potoki ciągłej integracji i wdrażania mogą działać w środowiskach air-gapped przy właściwym doborze narzędzi. Infrastruktura potoku musi być całkowicie samodzielna wewnątrz luki powietrznej, bez zależności od usług chmurowych.

GitLab Community Edition wdrożony lokalnie jest standardową platformą git i CI/CD self-hosted dla środowisk air-gapped. GitLab CE zapewnia: hosting repozytoriów git, przepływy pracy z żądaniami scalenia, wykonywanie potoków CI/CD (przy użyciu GitLab Runners wdrożonych w tym samym środowisku), rejestr pakietów i rejestr kontenerów. Łączność z chmurą nie jest wymagana.

GitLab Runners muszą być skonfigurowane z dostępem do wewnętrznych luster pakietów (wewnętrzny PyPI, npm, Maven) zamiast zewnętrznych repozytoriów pakietów. Etapy potoku, które normalnie wywoływałyby usługi zewnętrzne, muszą zostać przekonfigurowane do używania wewnętrznych odpowiedników lub wyłączone.