Badania Eclypsium pokazują, jak przejęty sprzęt może zmieniać modele AI w czasie ich działania

Eclypsium pokazało, jak przejęta infrastruktura obliczeniowa może zmieniać zachowanie modelu AI podczas wnioskowania, mimo że jego oryginalne pliki pozostają nienaruszone. Badanie, opublikowane 29 października pod tytułem Zaufana sztuczna inteligencja wymaga zaufanej infrastruktury, pokazuje, dlaczego sprawdzenie sygnatury modelu lub skrótu pliku nie potwierdza integralności modelu działającego w pamięci.

W kontrolowanej demonstracji, przeprowadzonej przy wsparciu NVIDIA, badacze wykorzystali przejętą jednostkę przetwarzania danych (DPU) oraz niezbyt restrykcyjną izolację pamięci, aby zmodyfikować wagi modelu w czasie jego działania. Odpowiedzi modelu zmieniły się, choć nie zmodyfikowano zapisanego modelu ani usługi wnioskowania. Wyniki badania wskazują, że sprzęt, oprogramowanie układowe i konfiguracja urządzeń należą do granic bezpieczeństwa AI.

Inny sposób zmieniania modelu AI

Dyskusje o bezpieczeństwie AI często koncentrują się na złośliwych promptach, zatrutych danych treningowych i niebezpiecznym korzystaniu z narzędzi. W tym badaniu przyjrzano się niższej warstwie: infrastrukturze, która przechowuje i przenosi parametry modelu podczas jego działania.

Wagi to parametry liczbowe kształtujące odpowiedzi modelu. Prawidłowy plik zapisany na dysku można wczytać do pamięci, a następnie zmienić za pomocą komponentu dysponującego odpowiednio wysokimi uprawnieniami. Późniejsze sprawdzenie oryginalnego pliku nadal wykazuje oczekiwane bajty, mimo że odpowiedź została wygenerowana z użyciem zmienionego stanu modelu w czasie jego działania.

W demonstracji Eclypsium widocznie zmieniono wynik analizy dotyczącej kwestii geopolitycznej. Szerszy problem polega na tym, że manipulowanie modelem w czasie jego działania mogłoby wpłynąć na inne wrażliwe zastosowania, w tym generowanie kodu i zautomatyzowane podejmowanie decyzji. Należy odróżnić te możliwe scenariusze od konkretnego zachowania zaobserwowanego w laboratorium.

Twierdzenie, że zmiany pozostały niewykryte, ma też określony zakres: użyte w demonstracji kontrole integralności zapisanego modelu nie wykryły zmian w pamięci. Nie dowodzi to, że byłyby one niewidoczne dla każdej formy monitorowania lub analizy kryminalistycznej.

Znaczenie warunków ataku

Test przeprowadzono w środowisku NVIDIA Grace Hopper. Ścieżka bezpośredniego dostępu do pamięci zależała od przejęcia komponentu z wysokimi uprawnieniami oraz od ustawień konfiguracji, które umożliwiały dostęp do wrażliwej pamięci. Badacze wskazują na przekazywanie IOMMU i niezbyt restrykcyjną izolację PCIe jako istotne warunki, wyraźnie zaznaczając, że nie były to domyślne ustawienia systemu Linux.

IOMMU pomaga kontrolować, do jakich obszarów pamięci może uzyskać dostęp urządzenie peryferyjne. W przetestowanej przez badaczy konfiguracji z silniejszą izolacją ta sama bezpośrednia ścieżka była niedostępna. Wynik podkreśla zatem, jak ważne jest sprawdzanie rzeczywistych ustawień wdrożenia, zamiast zakładać, że zainstalowane zabezpieczenie aktywnie egzekwuje granice dostępu.

DPU to programowalny procesor infrastrukturalny wykorzystywany do obsługi sieci, pamięci masowej i usług bezpieczeństwa. Możliwość wydajnego przenoszenia danych jest cenna, ale uprawnienia potrzebne do realizacji uzasadnionych zadań infrastrukturalnych mogą stać się niebezpieczne, jeśli napastnik przejmie kontrolę nad tym komponentem.

Odpowiedź NVIDIA: weryfikacja granic zaufania

W relacji ze współpracy NVIDIA opisuje uwierzytelnione uruchamianie BlueField, zaufanie zakorzenione w sprzęcie, izolację, zabezpieczenia aktualizacji oprogramowania układowego i atestację. Podkreśla również, że operatorzy chmur wybierają różne konfiguracje zabezpieczeń w zależności od przyjętego modelu zaufania.

Przesłanie obu firm jest takie, że operatorzy potrzebują dowodów potwierdzających te wybory. Kontrolę dostępu do pamięci, izolację urządzeń i interfejsy zarządzania należy oceniać w kontekście modelu zagrożeń dla danego wdrożenia. Sama dostępność funkcji nie dowodzi, że została ona prawidłowo skonfigurowana.

NVIDIA i Eclypsium wskazują również, że problem nie ogranicza się do jednego dostawcy. Systemy AI zależą od oprogramowania hosta z wysokimi uprawnieniami, oprogramowania układowego akceleratorów, kontrolerów zarządzających i mechanizmów przesyłania danych. Konkretne ścieżki różnią się w zależności od architektury, ale konieczność uwzględnienia tych komponentów pozostaje niezmienna.

Dlaczego bezpieczeństwo agentów zależy również od bezpieczeństwa infrastruktury

Stawka rośnie, gdy model może wywoływać narzędzia, uzyskiwać dostęp do danych przedsiębiorstwa lub inicjować działania. Manipulowanie infrastrukturą może podważyć założenia zabezpieczeń na poziomie aplikacji dotyczące tego, jaki model faktycznie działa.

Otwarta platforma bezpieczeństwa agentów NVIDIA pokazuje wielowarstwowe podejście. OpenShell zapewnia nadzór nad działaniem w czasie wykonywania, a NVIDIA Sentry na platformie BlueField działa w domenie bezpieczeństwa odizolowanej sprzętowo, poza hostem i agentem. Architektura ma na celu monitorowanie zachowania i egzekwowanie zasad z odrębnego punktu kontroli.

Ta niezależna pozycja wiąże się z dodatkową odpowiedzialnością za bezpieczeństwo: sprzęt egzekwujący zabezpieczenia i jego stos oprogramowania muszą same pozostać godne zaufania. Przeniesienie kontroli poza aplikację zmniejsza zależność od jednego elementu, a zarazem zwiększa znaczenie weryfikacji komponentu, któremu powierzono tę kontrolę.

Od inwentaryzacji sprzętu do ciągłego zapewniania bezpieczeństwa

Eclypsium określa mianem „luki w zapewnianiu bezpieczeństwa infrastruktury AI” rozbieżność między zapewnianiem bezpieczeństwa modeli a integralnością infrastruktury. Jego platforma do zapewniania bezpieczeństwa infrastruktury tworzy wykaz komponentów, ocenia oprogramowanie układowe i konfigurację, porównuje stan urządzeń z zatwierdzonymi konfiguracjami bazowymi oraz monitoruje zmiany. Firma przedstawia te funkcje jako uzupełnienie istniejących zabezpieczeń aplikacji i modeli.

W przypadku operatorów praktyczne działania należy zacząć od traktowania DPU, GPU, kontrolerów zarządzania i ich oprogramowania układowego jako odrębnych, zarządzanych zasobów. Każdy z nich wymaga przypisania odpowiedzialności, śledzenia wersji, oceny podatności oraz jasno określonego procesu aktualizacji. W ramach tego przeglądu należy uwzględnić dostęp do płaszczyzny zarządzania oraz oprogramowanie firm trzecich działające na procesorach infrastrukturalnych.

Kontrole powinny obejmować również cały cykl życia sprzętu: wdrażanie, aktualizacje, przywracanie działania po incydencie i ponowne przydzielanie. Czysty obraz systemu operacyjnego sam w sobie nie dowodzi, że każdy komponent niższego poziomu ma zatwierdzony stan. Współdzielona infrastruktura sprawia, że zarządzanie tym cyklem ma szczególne znaczenie, ponieważ ze sprzętu mogą kolejno korzystać różni klienci.

Kontrola działającego systemu, a nie tylko artefaktu

Sygnatury modeli pozostają przydatne: odpowiadają na ważne pytanie dotyczące wczytywanego artefaktu. Bezpieczne uruchamianie, atestacja, izolacja w czasie działania i ciągłe monitorowanie pozwalają odpowiedzieć na inne pytania dotyczące systemu, który go wykonuje. Żadnego z tych mechanizmów nie należy traktować jako zamiennika wszystkich pozostałych.

Znaczenie badań Eclypsium polega na tym, że model może przejść jedną kontrolę integralności, podczas gdy inna część łańcucha jego wykonywania uległa zmianie. W organizacjach wdrażających AI w procesach, w których stawka jest wysoka, weryfikacja infrastruktury powinna towarzyszyć ocenie modelu przez cały okres jego działania.