Bazowe zabezpieczenia dla self-hostowanych LLM: od odsłoniętego endpointu do jakości produkcyjnej

W Bezpieczeństwo self-hosted LLM przyjrzeliśmy się, dlaczego AI on-premise nie jest bezpieczne domyślnie — 175 000 wystawionych na publiczny internet serwerów inferencji udowodniło to lepiej niż jakikolwiek argument. Ten artykuł to praktyczna kontynuacja: bazowy poziom zabezpieczeń warstwa po warstwie, który pozwala przejść od wdrożenia „działającego na maszynie z GPU" do czegoś, co można dopuścić w pobliże danych produkcyjnych.

Model myślowy jest prosty: serwer inferencji to produkcyjna usługa sieciowa. Wszystko, co robisz już dla bazy danych, ma tu zastosowanie — plus kilka warstw specyficznych dla AI, które większość zespołów pomija.

Warstwa 1: Sieć — nic nie nasłuchuje w internecie

Najczęstszy błąd jest też najtańszy do naprawienia. Ollama, vLLM i podobne silniki są dostarczane bez uwierzytelniania; ich jedyną realną ochroną jest brak osiągalności.

• Powiąż silnik z localhost lub prywatnym interfejsem — nigdy z 0.0.0.0 na maszynie dostępnej publicznie. Dla Ollama oznacza to pozostawienie OLLAMA_HOST na domyślnej wartości 127.0.0.1:11434 i oparcie się pokusie „szybkiej naprawy", która to otwiera.
• Zablokuj port inferencji (domyślnie 11434 dla Ollama, 8000 dla vLLM) na poziomie firewalla i grup bezpieczeństwa w chmurze. Otwórz go wyłącznie dla swojego reverse proxy lub konkretnej zaufanej podsieci.
• Umieść każdego konsumenta za uwierzytelnionym punktem wejścia. Lekka wersja to nginx lub Caddy wymuszający klucze API lub mTLS przed silnikiem powiązanym z localhost:

server {
    listen 443 ssl;
    server_name llm.internal.example.com;

    location / {
        if ($http_authorization != "Bearer ${LLM_API_KEY}") {
            return 401;
        }
        proxy_pass http://127.0.0.1:11434;
    }
}

Cięższa wersja — warta wdrożenia, gdy wdrożenie dzieli kilka zespołów — to dedykowana bramka LLM (LLM gateway), która w jednym miejscu dodaje klucze dla poszczególnych konsumentów, limity zapytań, budżety i logi audytowe.

• Wydziel stos AI do własnej strefy sieciowej z jawnymi listami dozwolonych połączeń w obu kierunkach. I co kluczowe: filtruj ruch wychodzący. Worker inferencji niemal nigdy nie potrzebuje dostępu do internetu wychodzącego. Domyślna blokada ruchu wychodzącego (default-deny egress) to najtańsza kontrola, jaką masz zarówno przeciw eksfiltracji danych, jak i zatrutym callbackom modeli — i zamienia wiele „krytycznych" podatności w nieistotne zdarzenia.

Warstwa 2: Platforma — ogranicz zasięg awarii

Obciążenia GPU kuszą zespoły do kontenerów --privileged i procesów root. To dokładnie odwrotne podejście: sterowniki GPU już dają temu oprogramowaniu nietypowy dostęp do hosta, więc kontener wokół niego powinien być jak najbardziej szczelny.

• Uruchamiaj silnik jako użytkownik nie-root, usuń wszystkie zbędne capabilities i zamontuj katalog modelu w trybie tylko do odczytu. Przyznawaj dostęp do GPU jawnie (--gpus, wtyczki urządzeń) — nigdy przez tryb privileged.
• Przypnij wersje dla całego stosu: silnik, runtime CUDA, sterowniki, obraz bazowy. Odtwarzalne wdrożenia to kontrola bezpieczeństwa, a nie tylko wygoda operacyjna.
• Łataj na podstawie wydań upstream, nie kanałów CVE. Przypadek Bleeding Llama (CVE-2026-7482) pokazał, że poprawka trafiła do wydania miesiące przed pojawieniem się CVE — każdy, kto czekał na alerty skanera, pozostawał podatny, mając przy tym zielony dashboard. Subskrybuj kanały wydań swojego silnika i aktualizuj według harmonogramu.
• Na współdzielonej infrastrukturze pamiętaj, że silniki serwujące grupują użytkowników poprzez współdzieloną pamięć GPU i cache KV. Jeśli tenanci muszą być silnie izolowani, izoluj ich na poziomie instancji — osobne procesy silnika lub węzły — a nie tylko na poziomie API.

Warstwa 3: Artefakty modelu — weryfikuj to, co ładujesz

Wagi modelu to artefakty wykonywalne i zasługują na takie samo traktowanie łańcucha dostaw jak obrazy kontenerów.

• Tylko safetensors. Formaty oparte na pickle (.bin, .pt) mogą wykonywać kod w momencie ładowania; w 2026 roku nie ma dla nich żadnego uzasadnienia produkcyjnego.
• Przypnij każdy model do kryptograficznego skrótu (hash) i weryfikuj przy wdrożeniu, dokładnie jak digest obrazu. Pobieraj z oficjalnych repozytoriów wydawców, nie z re-uploadów społeczności, i weryfikuj podpisy tam, gdzie wydawca je udostępnia.
• Traktuj dostrojone (fine-tuned) modele wewnętrzne jako klejnoty koronne własności intelektualnej: przechowywanie z kontrolą dostępu, szyfrowanie w spoczynku, logi audytowe przy każdym odczycie. Jeśli twój model był dostrajany na danych własnościowych, model jest danymi.

Warstwa 4: Aplikacja — zakładaj, że model zostanie zmanipulowany

Wszystko powyżej zabezpiecza infrastrukturę. Zachowanie modelu to osobna powierzchnia ataku — omówiliśmy ją szczegółowo w Prompt Injection — a baseline tutaj dotyczy ograniczania tego, co zmanipulowany model może zrobić:

• Narzędzia z najmniejszymi uprawnieniami: tylko do odczytu tam, gdzie to możliwe, żadnych danych uwierzytelniających produkcji w zasięgu agenta.
• Traktuj wyjście modelu jako niezaufane dane wejściowe — walidowane, zanim dotknie shella, SQL czy zewnętrznego API.
• Sandboxowane, ograniczone pod względem ruchu wychodzącego wykonanie dla każdego kodu wygenerowanego przez model.
• Potwierdzenie człowieka dla działań nieodwracalnych.
• Pełne logowanie promptów i wywołań narzędzi do twojego SIEM. Logi inferencji to telemetria bezpieczeństwa: próby injection, sondowanie i anomalne użycie narzędzi powinny wywoływać alerty, a nie pojawiać się dopiero w przeglądzie po incydencie.

Checklista na jedną stronę

Sieć: bindowanie do localhost · zaporowane porty inferencji · uwierzytelniony proxy lub gateway · segmentacja · domyślna blokada ruchu wychodzącego. Platforma: kontenery nie-root · brak trybu privileged · przypięte wersje · łatanie w oparciu o wydania · izolacja tenantów na poziomie instancji. Artefakty: tylko safetensors · przypięte do hasha · zaufane źródła · podpisane tam, gdzie to możliwe · dostrojone wagi jako chroniona własność intelektualna. Aplikacja: narzędzia z najmniejszymi uprawnieniami · walidowane wyjścia · sandboxowane wykonanie · człowiek w pętli dla działań nieodwracalnych · telemetria inferencji w SIEM.

Nic z tego nie wymaga egzotycznych narzędzi — reverse proxy, firewall, runtime kontenerów i dyscyplina pokrywają większość tego zakresu. Różnica między eksponowanym boxem Ollama a wdrożeniem gotowym na produkcję mierzona jest w dniach pracy, nie miesiącach. To, czego to wymaga, to decyzja, by traktować infrastrukturę AI jako to, czym faktycznie jest: usługę produkcyjną z dostępem do twoich najbardziej wrażliwych danych.

W NextVector budujemy infrastrukturę backendową, blockchain i AI, w której bezpieczeństwo jest ograniczeniem projektowym od pierwszego dnia. Planujesz wdrożenie LLM on-premise? Skontaktuj się z nami.