Wprowadzenie do problemu / definicja
Bezpieczeństwo modeli sztucznej inteligencji jest najczęściej oceniane przez pryzmat integralności plików modelu, obrazów kontenerów, podpisów kryptograficznych oraz mechanizmów rozruchu zaufanego. Coraz wyraźniej widać jednak, że taki model ochrony nie obejmuje całego łańcucha zaufania. Jeśli atakujący przejmie uprzywilejowany element infrastruktury, może wpłynąć na zachowanie modelu już po jego załadowaniu do pamięci, bez naruszania artefaktów zapisanych na dysku.
To oznacza, że organizacja może mieć pełną zgodność sum kontrolnych i podpisów, a mimo to korzystać z modelu, którego odpowiedzi zostały subtelnie zmienione w trakcie działania. W praktyce problem dotyczy nie tylko samego modelu, ale całego środowiska wykonawczego AI.
W skrócie
- Atak może modyfikować stan modelu w pamięci po zakończeniu standardowych kontroli integralności.
- Manipulacja nie wymaga zmiany pliku modelu, obrazu kontenera ani systemu plików.
- Ryzyko obejmuje host, firmware, BMC, DPU, SmartNIC, sterowniki GPU i inne uprzywilejowane komponenty.
- Skutkiem może być osłabienie zabezpieczeń, generowanie mniej bezpiecznego kodu lub selektywna zmiana odpowiedzi modelu.
- Tradycyjne narzędzia wykrywające naruszenia plików mogą takiego ataku nie zauważyć.
Kontekst / historia
Przez lata dominowało założenie, że jeśli organizacja kontroluje obraz systemu, kontener oraz plik modelu, to uruchomione środowisko AI pozostaje godne zaufania. To podejście sprawdza się jedynie częściowo, ponieważ współczesne platformy AI działają na złożonym stosie sprzętowo-programowym, w którym wiele decyzji dotyczących rzeczywistego stanu wykonania zapada poza warstwą aplikacyjną.
Wraz z rosnącą skalą wdrożeń AI wzrosło znaczenie komponentów takich jak BMC, DPU, SmartNIC, warstwy orkiestracji, firmware urządzeń i sterowniki akceleratorów. Jednocześnie te same elementy stają się atrakcyjnym celem dla atakujących. To zmienia sposób myślenia o bezpieczeństwie AI: model nie jest odizolowanym artefaktem, lecz zależy od wielu uprzywilejowanych warstw mogących wpływać na jego działanie.
Analiza techniczna
Sedno zagrożenia polega na różnicy między integralnością potwierdzaną podczas ładowania a integralnością zachowaną w czasie wykonywania. Hash pliku modelu potwierdza jedynie, że artefakt odczytany z dysku nie został zmieniony. Nie daje jednak gwarancji, że wagi, tensory, adaptery czy kontekst wykonawczy pozostają niezmienione po załadowaniu do pamięci DRAM lub pamięci akceleratora.
Atak może rozpocząć się od kompromitacji uprzywilejowanego komponentu, takiego jak host, hiperwizor, sterownik GPU, firmware UEFI, kontroler BMC, usługa aktualizacji firmware, agent orkiestracyjny albo urządzenie zdolne do operacji DMA. Po uzyskaniu odpowiednich uprawnień przeciwnik może odczytywać lub nadpisywać fragmenty pamięci zawierające stan modelu i zmieniać jego zachowanie bez naruszania integralności plików.
Szczególne znaczenie mają tu mechanizmy Direct Memory Access. DMA jest kluczowe dla wydajności nowoczesnych platform AI, ale jednocześnie rozszerza granicę zaufania. Jeśli konfiguracja IOMMU, izolacja PCIe lub uprawnienia urządzeń są zbyt szerokie, skompromitowany komponent może uzyskać bezpośredni dostęp do pamięci hosta lub akceleratora. W takim scenariuszu wystarczy nadpisanie wybranych danych już po przejściu standardowych kontroli bezpieczeństwa.
Taka manipulacja może być bardzo trudna do wykrycia. Model może zachowywać się inaczej tylko dla określonych danych wejściowych, użytkowników albo klas zadań, a następnie wracać do pozornie normalnego działania. To sprawia, że tradycyjne mechanizmy EDR, skanery obrazów i kontrole podpisów mogą nie wykryć incydentu, ponieważ artefakty na dysku pozostają nienaruszone.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem jest utrata zaufania do odpowiedzi generowanych przez model przy jednoczesnym zachowaniu pozornej integralności środowiska. Organizacja może więc długo operować na zmanipulowanych wynikach, nie mając oczywistych wskaźników kompromitacji.
Ryzyko ma kilka praktycznych wymiarów:
- model generujący kod może sugerować mniej bezpieczne praktyki, osłabiać walidację lub promować podatne zależności,
- możliwy jest wyciek własności intelektualnej, w tym wag modelu, adapterów, promptów systemowych i danych kontekstowych,
- atak może działać selektywnie, wpływając tylko na wybranych użytkowników lub konkretne zadania,
- kompromitacja na poziomie firmware lub BMC może przetrwać standardową reinstalację systemu operacyjnego.
W efekcie incydent związany z AI przestaje być wyłącznie problemem aplikacyjnym. Staje się pełnoprawnym incydentem infrastrukturalnym, obejmującym łańcuch zaufania całej platformy wykonawczej.
Rekomendacje
Organizacje wdrażające AI powinny rozszerzyć model bezpieczeństwa poza sam model, kontener i host. Granica zaufania musi objąć całą infrastrukturę wykonawczą, w tym sprzęt, firmware, urządzenia peryferyjne i warstwy zarządzające.
- Stworzyć pełny inwentarz komponentów AI: hostów, GPU, DPU, SmartNIC, BMC, firmware, sterowników, runtime’ów i bibliotek zewnętrznych.
- Wzmocnić izolację pamięci i urządzeń przez poprawną konfigurację IOMMU, ograniczenie uprawnień DMA oraz kontrolę topologii PCIe.
- Zabezpieczyć interfejsy zarządzania out-of-band, takie jak BMC, IPMI czy Redfish, z użyciem segmentacji sieci, silnego uwierzytelniania i stałego monitoringu.
- Rozszerzyć proces zarządzania podatnościami na firmware, sterowniki i komponenty infrastrukturalne, a nie tylko na system operacyjny i aplikacje.
- Wdrożyć ciągłą obserwowalność środowiska wykonawczego, zamiast ograniczać się do kontroli integralności przy uruchamianiu.
- Przygotować scenariusze detekcji obejmujące anomalie w pamięci akceleratorów, warstwie firmware i płaszczyznach zarządzania sprzętem.
Podsumowanie
Nowe analizy pokazują, że bezpieczeństwo AI nie kończy się na podpisanym pliku modelu i poprawnym obrazie kontenera. Kluczowe znaczenie ma integralność środowiska wykonawczego po załadowaniu modelu do pamięci. Jeśli przeciwnik przejmie kontrolę nad uprzywilejowanym komponentem infrastruktury, może wpłynąć na odpowiedzi modelu bez pozostawienia oczywistych śladów w artefaktach przechowywanych na dysku.
Dla firm i instytucji oznacza to konieczność zmiany perspektywy. Modele AI są bezpieczne tylko w takim stopniu, w jakim bezpieczna jest infrastruktura, która je uruchamia, monitoruje i aktualizuje.