Bezpieczeństwo samodzielnie hostowanych LLM: on-premise nie oznacza bezpieczne domyślnie
Firmy przenoszą obciążenia AI do środowisk on-premise z uzasadnionych powodów: rezydencja danych, zgodność z RODO i SOC 2 oraz kontrola kosztów na dużą skalę. Uruchomienie modelu open-weight we własnym obszarze infrastruktury oznacza, że prompty i dostrojone wagi nigdy nie opuszczają Twojej infrastruktury. Za tą decyzją kryje się jednak niebezpieczne założenie: „działa na naszych serwerach, więc jest bezpieczne". Nie jest. Self-hosting eliminuje jedno ryzyko — wgląd strony trzeciej w Twoje dane — i przenosi na Ciebie pełną odpowiedzialność za wszystko, co dotąd po cichu przejmował dostawca zarządzanego API: bezpieczeństwo endpointów, weryfikację artefaktów, izolację i łatanie. Oto realna powierzchnia ataku.
175 000 odsłoniętych serwerów wnioskowania
We wrześniu 2025 roku Cisco Talos wykryło ponad 1100 instancji Ollama dostępnych publicznie w internecie bez żadnego uwierzytelniania. Na początku 2026 roku skany SentinelLABS i Censys naliczyły około 175 000 publicznie dostępnych hostów Ollama w 130 krajach, a do tego niezabezpieczone endpointy vLLM i LiteLLM.
Główna przyczyna: popularne narzędzia do self-hostingu zaprojektowano z myślą o wygodzie programistów. API REST Ollama w ogóle nie ma wbudowanego uwierzytelniania. Wystarczy jeden bind na 0.0.0.0 lub zbyt permisywna grupa zabezpieczeń w chmurze, a całe API staje się otwarte. Atakujący aktywnie skanują internet w poszukiwaniu takich instancji — udokumentowane operacje „LLMjacking" znajdują otwarte instancje i odsprzedają do nich dostęp na podziemnych marketplace'ach.
Otwarty endpoint daje atakującemu darmową moc obliczeniową GPU, możliwość pobrania Twoich dostrojonych modeli (które są Twoimi danymi), wgląd w prompty systemowe i konfiguracje RAG oraz przyczółek sieciowy wewnątrz Twojej infrastruktury.
CVE w warstwie wnioskowania
Warstwa serwująca to młode oprogramowanie, zaprojektowane przede wszystkim pod kątem wydajności. Oto jej dotychczasowy bilans:
- Probllama (2024) — zdalne wykonanie kodu (RCE) w Ollama
- CVE-2025-47277 — warstwa rozproszonego wnioskowania vLLM wywoływała
pickle.loads()na danych z gniazda sieciowego: podręcznikowy przykład RCE - Bleeding Llama, CVE-2026-7482 — trzy nieuwierzytelnione wywołania API ujawniały prompty systemowe, sesje, klucze API i dane uwierzytelniające do baz danych z Ollama. Poprawka istniała przez wiele miesięcy, zanim przypisano CVE — przez cały ten czas skanery i narzędzia compliance były na to ślepe
Wniosek: serwer wnioskowania to produkcyjna usługa sieciowa i wymaga takiej samej dyscypliny łatania jak baza danych. Śledź bezpośrednio wydania upstream — samo poleganie na kanałach CVE Cię zawiedzie. Istnieje też ryzyko charakterystyczne wyłącznie dla AI: silniki serwujące grupują żądania we wspólnych pulach pamięci GPU i cache'ach KV. Skompromitowany proces może wyciekać fragmenty rozmów innych użytkowników, a uprzywilejowane sterowniki GPU sprawiają, że skompromitowany kontener dzieli tylko jeden krok od hosta.
Wagi modeli to wykonywalne artefakty
Zespoły stosują zasady bezpieczeństwa łańcucha dostaw do kodu, ale wagi modeli pobierają z publicznych repozytoriów bez żadnej weryfikacji. Istnieją dwa scenariusze awarii: Złośliwa serializacja. Formaty modeli oparte na pickle mogą wykonać dowolny kod w momencie wczytywania. W 2026 roku nie ma żadnego powodu, by w produkcji wczytywać cokolwiek poza formatem safetensors. Zatruwanie modelu. Wagi, które w benchmarkach zachowują się normalnie, ale zostały dostrojone tak, by w określonych warunkach wyciekać dane lub wykonywać ukryte instrukcje. Bez żadnej awarii, bez wpisu w logach. Rozwiązaniem jest klasyczna higiena łańcucha dostaw: wyłącznie zaufane źródła, artefakty przypięte do zweryfikowanych sum hash, podpisy modeli tam, gdzie są dostępne, oraz traktowanie wewnętrznie dostrojonych modeli jak najcenniejszej własności intelektualnej firmy.
Prompt injection nie obchodzi, gdzie działa model
Złośliwe instrukcje osadzone w dokumentach, e-mailach czy stronach internetowych działają identycznie zarówno przeciwko modelom self-hosted, jak i chmurowym. Co więcej, self-hosting często pogarsza sytuację: modele open-weight mają słabszy trening bezpieczeństwa, zespoły wyłączają zabezpieczenia, bo „to przecież wewnętrzne", a model on-premise zwykle ma dużo bardziej uprzywilejowany dostęp — do baz danych, wewnętrznych API, narzędzi systemu plików — niż jakikolwiek model chmurowy. Właściwym punktem odniesienia jest OWASP Top 10 dla aplikacji LLM. Podstawy to: dostęp do narzędzi zgodny z zasadą najmniejszych uprawnień, traktowanie wyników modelu jako danych niezaufanych, wykonywanie kodu w piaskownicy oraz filtrowanie ruchu wychodzącego z workerów wnioskowania.
Bazowy poziom hardeningu
Minimalny standard dla środowiska produkcyjnego:
- Sieć: bindowanie do localhost lub prywatnych podsieci; cały dostęp wyłącznie przez uwierzytelniony reverse proxy lub bramę LLM; domyślne filtrowanie ruchu wychodzącego
- Platforma: kontenery działające bez roota, minimalny zestaw uprawnień, łatanie śledzące wydania upstream
- Artefakty: wyłącznie safetensors, przypięte do sum hash, przechowywanie dostrojonych wag z kontrolą dostępu
- Aplikacja: przegląd zgodnie z OWASP LLM Top 10, walidacja wyników modelu, pełne logowanie wnioskowania do systemu SIEM
Nic z tego nie jest egzotyczne — to ta sama dyscyplina, którą stosujesz już wobec baz danych, rozszerzona na nowy typ obciążenia, które większość zespołów wdraża obecnie z poziomem zabezpieczeń przypominającym weekendowy projekt hobbystyczny.
Podsumowanie
„On-premise" to cecha dotycząca rezydencji danych, a nie bezpieczeństwa. 175 000 odsłoniętych serwerów wnioskowania to nie porażka narzędzi — to porażka podejścia: infrastruktura AI wdrażana tak, jak aplikacja desktopowa, podczas gdy powinna być traktowana jak produkcyjna baza danych. W NextVector budujemy infrastrukturę backendową i blockchainową, w której bezpieczeństwo jest wymogiem projektowym, a nie kwestią doraźną — i ta sama dyscyplina odnosi się bezpośrednio do AI. Planujesz wdrożenie AI on-premise? Skontaktuj się z nami.