Bezpieczna dostawa oprogramowania do sieci air-gap: potok transferu

Sieć air-gap nie ma ścieżki do rejestru pakietów, trasy do serwera aktualizacji ani sposobu na połączenie się z urzędem certyfikacji. Każdy bajt oprogramowania, który do niej wchodzi, musi być celowo wprowadzony, rozliczony i udowodniony jako godny zaufania przed uruchomieniem. Mechanizm, który to robi — pakowanie aktualizacji po stronie podłączonej, przenoszenie jej przez fizyczną granicę i weryfikacja po stronie izolowanej — to potok transferu. Ten artykuł analizuje, jak zbudować taki, który jest wystarczająco szybki, aby utrzymać enklawę załataną, i wystarczająco rygorystyczny, aby spełnić akredytację o wysokiej pewności: podpisane pakiety, strażnicy transferu, weryfikacja przy imporcie, powtarzalne kompilacje i lustro offline, które wiąże to wszystko razem.

Dlaczego dostawa air-gap to inny problem

W podłączonej sieci dostawa oprogramowania to rozwiązana wygoda: host pobiera z rejestru, weryfikuje podpis względem łańcucha zaufania online i instaluje. Nic z tego nie jest dostępne przez air gap. Izolowana sieć jest fizycznie odcięta od internetu — i często od każdej innej sieci — właśnie po to, aby atakujący nie mógł dotrzeć do niej zdalnie. Ta sama izolacja usuwa każde założenie, na którym opiera się normalny potok aktualizacji. Nie ma sprawdzania unieważnień online, nie ma rozwiązywania zależności na żywo, nie ma kanału telemetrii i często nie ma żadnej drogi powrotnej.

Konsekwencją jest to, że cała decyzja o zaufaniu musi być podjęta na podstawie informacji, które podróżują wewnątrz samego pakietu. Pakiet musi nieść własny dowód autentyczności, własny kompletny zestaw zależności i własne metadane pochodzenia. Strona wysoka nie może nikogo o nic zapytać; może jedynie zweryfikować to, co już posiada, względem tego, co właśnie przybyło. To przenosi ciężar inżynieryjny z momentu instalacji — gdzie żyje on w systemie podłączonym — na moment pakowania i moment importu. Dobrze ustaw te dwie granice, a air gap stanie się kontrolowanym kanałem, a nie operacyjnym ślepym zaułkiem. Jest to ściśle powiązane z szerszą dyscypliną inżynieryjną wdrażania air-gap dla oprogramowania obronnego, która obejmuje stałe środowisko zasilane przez potok.

Podpisane pakiety: jednostka transferu

Atomowa jednostka, która przekracza granicę, to podpisany pakiet. Pakiet to pojedyncze archiwum zawierające wszystko, czego potrzebuje aktualizacja — pliki binarne aplikacji, obrazy kontenerów, pakiety systemu operacyjnego, manifesty konfiguracji, skrypty migracji i zestawienie składników oprogramowania (SBOM) — wraz z manifestem wyliczającym każdy plik z jego skrótem kryptograficznym. Manifest jest następnie podpisywany kluczem prywatnym posiadanym przez organ wydający, najlepiej w sprzętowym module bezpieczeństwa lub magazynie kluczy offline, który nigdy nie dotyka podłączonej maszyny.

Podpis wykonuje jedno konkretne zadanie: dowodzi, że pakiet został wyprodukowany przez legalny potok wydawniczy i nie został od tego czasu zmieniony. Przy imporcie strona air-gap weryfikuje podpis względem klucza publicznego lub certyfikatu, który został udostępniony do enklawy z wyprzedzeniem, poza pasmem. Ponieważ klucz weryfikacyjny jest już wewnątrz enklawy, nie jest potrzebne wyszukiwanie online. To właśnie ta inwersja sprawia, że zaufanie air-gap działa — kotwica zaufania jest wstępnie umieszczona, a pakiet jest sprawdzany względem niej lokalnie.

Co wchodzi do manifestu

Solidny manifest to coś więcej niż lista plików. Zapisuje wersję pakietu, poprzednią wersję, po której ma następować, identyfikator kompilacji, skrót SBOM i tabelę skrótów dla każdego pliku. Zapisanie wersji poprzedniej pozwala stronie wysokiej odrzucić pakiet o zaburzonej kolejności lub odtworzony ponownie: enklawa działająca w wersji 14 powinna odmówić pakietowi, który deklaruje się jako następca wersji 11, ponieważ taka kolejność jest albo błędem, albo atakiem obniżenia wersji. Traktowanie łańcucha wersji jako części podpisanego ładunku — a nie jako luźnych metadanych — zamyka klasę ataków wycofania, którą czyste sprawdzanie podpisu pomija.

Powtarzalne kompilacje i wbudowywanie zależności

Podpis dowodzi, kto zbudował artefakt. Nie dowodzi, że artefakt odpowiada kodowi źródłowemu, który został przejrzany i zatwierdzony. Powtarzalne kompilacje zamykają tę lukę. Powtarzalna kompilacja daje bajt po bajcie identyczny wynik za każdym razem, gdy ten sam kod jest kompilowany tym samym przypiętym łańcuchem narzędzi, co oznacza, że niezależny drugi kompilator może ponownie zbudować wydanie i potwierdzić, że skrót powstałego artefaktu pasuje do podpisanego pakietu. Gdy dwa niepowiązane kompilatory dochodzą do tego samego skrótu, masz mocny dowód na to, że pakiet odzwierciedla dokładnie przejrzany kod i nic nie zostało wstrzyknięte podczas kompilacji.

Powtarzalność jest osiągalna tylko wtedy, gdy każde wejście jest przypięte. Tu właśnie wchodzi wbudowywanie zależności. W podłączonej kompilacji zależności są rozwiązywane na żywo z repozytoriów nadrzędnych — opcja, która po prostu nie istnieje poniżej air gap. Kompilacja musi więc rozwiązać, pobrać i przypiąć każdą zależność według skrótu po stronie podłączonej: pakiety językowe, pakiety systemu operacyjnego i obrazy bazowe kontenerów — wszystkie odwoływane przez skrót zawartości, a nie zmienną etykietę wersji. Przypinanie według skrótu, a nie etykiety, to różnica między pakietem, który kompiluje się identycznie na zawsze, a takim, który po cichu dryfuje, gdy etykiety nadrzędne się przesuwają.

Wbudowany zestaw zależności podróżuje następnie wewnątrz pakietu, więc strona wysoka nigdy nie musi niczego pobierać. SBOM wylicza każde z tych wejść, dając recenzentowi po stronie importu kompletny, weryfikowalny inwentarz. Ten sam SBOM jest tym, co umożliwia audyt łańcucha dostaw wewnątrz środowiska, które nigdy nie może uruchomić skanera podatności online względem działającej sieci.

Strażnicy transferu: przenoszenie bajtów przez granicę

Gdy pakiet jest zbudowany i podpisany, musi fizycznie przekroczyć air gap. Istnieją dwa dominujące mechanizmy, a wybór między nimi kształtuje cały potok.

Diody danych. Dioda danych to sprzęt, który zezwala na przepływ danych dokładnie w jednym kierunku — zwykle z niskiego do wysokiego — i sprawia, że kierunek odwrotny jest fizycznie niemożliwy, a nie jedynie zabroniony polityką. Dioda pozwala ciągle wpychać pakiety do enklawy z pełną audytowalnością i bez ryzyka eksfiltracji danych przez ten sam kanał. Koszt inżynieryjny polega na tym, że prawdziwe łącze jednokierunkowe nie ma ścieżki potwierdzenia, więc protokół transferu musi dodać korekcję błędów do przodu i nadmiarową transmisję, aby tolerować straty bez żądania retransmisji przez kanał zwrotny. Diody to właściwa odpowiedź, gdy tempo dostaw jest wysokie, a granica musi pozostawać stale dostępna.

Nośnik wymienny. Alternatywą jest ręczny transfer sneakernet: pakiet jest zapisywany na jednorazowym nośniku optycznym lub dedykowanym, kontrolowanym urządzeniu USB i fizycznie przenoszony przez granicę przez upoważnioną osobę. Jest to proceduralnie prostsze i nie wymaga specjalnego sprzętu, ale jego bezpieczeństwo zależy całkowicie od dyscypliny kontroli nośników — unikalnego śledzenia nośników, obowiązkowego skanowania na ofiarnym hoście inspekcyjnym i nośnika jednorazowego, aby zapobiec wynoszeniu danych przez urządzenie. W przypadku ściśle niejawnej pracy formalna obsługa transferów z wysokiego do niskiego i z niskiego do wysokiego znacznie pokrywa się z dyscypliną rozwiązania międzydomenowego, które dodaje inspekcję i filtrowanie między poziomami klasyfikacji.

Niezależnie od użytego mechanizmu, strażnik nigdy nie może stać się dwukierunkową wygodą. Najczęstszym niepowodzeniem we wdrożeniach polowych jest operator, który sfrustrowany jednokierunkowym transferem wprowadza urządzenie USB, które dotknęło podłączonej maszyny, a następnie przenosi je z powrotem — po cichu zamieniając air gap w dwukierunkowy most.

Weryfikacja przy imporcie: moment zaufania

Import to miejsce, w którym pakiet zdobywa prawo do uruchomienia. Strona wysoka wykonuje ustaloną, uporządkowaną sekwencję kontroli, a niepowodzenie na dowolnym kroku zatrzymuje proces — niepowodzenia weryfikacji są zdarzeniami bezpieczeństwa do zalogowania i zbadania, a nigdy warunkami ponowienia, które można obejść.

Po pierwsze, podpis na manifeście jest weryfikowany względem wstępnie udostępnionego klucza publicznego, zanim wypakowany zostanie choćby jeden plik. Po drugie, każdy plik jest rozpakowywany do obszaru kwarantanny, a jego skrót przeliczany i porównywany z wpisem manifestu; każda niezgodność powoduje odrzucenie pakietu. Po trzecie, zadeklarowana wersja poprzednia jest sprawdzana względem obecnie zainstalowanej wersji, aby wymusić monotoniczną kolejność i blokować obniżenia. Po czwarte, SBOM jest uzgadniany z wypakowaną zawartością, tak aby recenzent mógł potwierdzić, że inwentarz jest kompletny i pasuje do tego, co zatwierdzono po stronie niskiej.

Dopiero po przejściu wszystkich czterech kontroli artefakty wychodzą z kwarantanny. Obsługa sekretów, które jadą wraz z wydaniem — certyfikatów podpisu, poświadczeń usług, kluczy szyfrowania — kieruje się tą samą zasadą offline-first opisaną w zarządzaniu sekretami w obronnych potokach CI/CD: nic w postaci jawnej, każdy klucz powiązany z HSM lub sejfem, rotacja planowana wokół tempa transferu, a nie wokół założenia stałej dostępności online.

Lustro offline i krok wdrożenia

Pojedynczy pakiet łata system raz. Utrzymywanie enklawy serwisowanej przez lata wymaga stałego lustra offline: lokalnego rejestru kontenerów, lokalnego repozytorium pakietów systemu operacyjnego i lokalnego magazynu artefaktów, wszystkie zasilane wyłącznie z importowanych pakietów. Lustro jest tym, co pozwala usługom wewnątrz enklawy wdrażać się i skalować przy użyciu zwykłych narzędzi — pobierając obrazy i pakiety z lokalnego lustra, jakby było ono nadrzędne — bez potrzeby dostępu do sieci dla którejkolwiek z nich. Każdy zweryfikowany import dodaje do lustra; nic nigdy nie jest pobierane z zewnątrz.

Samo wdrożenie musi zakładać, że poprawka może zawieść w środowisku, w którym następny pakiet może być oddalony o dni. Każda aktualizacja jest zatem wdrażana z przetestowaną ścieżką wycofania, tak aby nieudana instalacja wracała do poprzedniego znanego-dobrego wydania przy użyciu artefaktów już obecnych w lustrze — nigdy nie wymagając świeżego transferu do odzyskania. Pełna sekwencja, od kompilacji do działającego systemu, jest zapisywana w niezmiennym dzienniku audytu: identyfikator kompilacji, zapis transferu, wynik weryfikacji, wynik wdrożenia. Ten nieprzerwany łańcuch jest tym, co czyta przegląd akredytacyjny, aby potwierdzić, że enklawa kiedykolwiek uruchamiała tylko oprogramowanie, którego pochodzenie można prześledzić od początku do końca.

Składanie potoku w całość

Działający potok dostawy air-gap to kompozycja pięciu dyscyplin: powtarzalne kompilacje z wbudowanymi zależnościami po stronie niskiej, podpisane pakiety jako jednostka transferu, audytowalny jednokierunkowy strażnik transferu, uporządkowana bramka weryfikacji przy imporcie i lustro offline zasilające wdrożenia z możliwością wycofania. Każda kompensuje założenie, które air gap usuwa. Żadna z nich nie jest opcjonalna — potok bez powtarzalności nie może wykryć zmanipulowanej kompilacji, taki bez wymuszenia łańcucha wersji jest otwarty na ataki obniżenia, a taki bez dyscypliny drogi powrotnej tak naprawdę wcale nie jest air-gap. Zbudowane razem, zamieniają izolowaną sieć z obciążenia konserwacyjnego w kontrolowany, rozliczalny kanał, który można utrzymywać aktualnym, nigdy nie kompromitując izolacji, która go uzasadnia.