Базовий рівень захисту для self-hosted LLM: від відкритого ендпоінта до production-grade рішення

У статті Безпека self-hosted LLM ми розглянули, чому on-premise AI не є безпечним за замовчуванням — 175 000 доступних з публічного інтернету серверів інференсу довели це краще за будь-який аргумент. Ця стаття — практичне продовження: базовий рівень захисту по кожному шару, який дозволяє перевести self-hosted розгортання зі стану «працює на боксі з GPU» до стану, який можна допустити до продакшн-даних.

Ментальна модель проста: сервер інференсу — це продакшн-сервіс у мережі. Все, що ти вже робиш для бази даних, застосовується і тут — плюс кілька специфічних для AI шарів, які більшість команд пропускають.

Шар 1: Мережа — ніщо не слухає в інтернеті

Найпоширеніша помилка водночас і найдешевша для виправлення. Ollama, vLLM та подібні рушії постачаються без автентифікації; їхній єдиний реальний захист — недосяжність.

• Прив'яжи рушій до localhost або приватного інтерфейсу — ніколи до 0.0.0.0 на машині, доступній ззовні. Для Ollama це означає залишити OLLAMA_HOST на значенні за замовчуванням 127.0.0.1:11434 і не піддаватися спокусі «швидкого фіксу», який його відкриває.
• Заблокуй порт інференсу (11434 для Ollama, 8000 для vLLM за замовчуванням) на рівні файрвола та cloud security-груп. Відкривай його лише для свого reverse proxy або конкретної довіреної підмережі.
• Постав кожного споживача за автентифікованою точкою входу. Легка версія — це nginx або Caddy, що вимагає API-ключі або mTLS перед рушієм, прив'язаним до 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;
    }
}

Важча версія — варта того, коли розгортання розділяють кілька команд, — це виділений LLM gateway, який додає ключі для кожного споживача, ліміти запитів, бюджети та логи аудиту в одному місці.

• Виділи AI-стек в окрему мережеву зону з явними allow-list у обох напрямках. І критично важливо: фільтруй egress. Воркеру інференсу майже ніколи не потрібен вихідний доступ до інтернету. Default-deny egress — це найдешевший контроль, який у тебе є проти ексфільтрації даних і отруєних callback-ів моделі одночасно — і він перетворює багато «критичних» вразливостей на непомітні події.

Шар 2: Платформа — обмеж радіус ураження

GPU-навантаження спокушають команди використовувати --privileged контейнери та root-процеси. Це якраз навпаки: GPU-драйвери вже дають цьому софту незвично широкий доступ до хоста, тож контейнер навколо нього має бути максимально жорстким.

• Запускай рушій під non-root користувачем, прибери всі непотрібні capabilities і монтуй каталог моделі в режимі лише для читання. Надавай доступ до GPU явно (--gpus, device plugins) — ніколи через privileged mode.
• Фіксуй версії для всього стеку: рушій, CUDA runtime, драйвери, базовий образ. Відтворювані розгортання — це контроль безпеки, а не просто зручність для операційної команди.
• Патч на основі upstream-релізів, а не CVE-фідів. Кейс Bleeding Llama (CVE-2026-7482) показав, що фікс вийшов за місяці до появи CVE — усі, хто чекав на алерти сканера, залишалися вразливими весь цей час із зеленими дашбордами. Підпишись на реліз-фіди свого рушія та онови за розкладом.
• На спільній інфраструктурі пам'ятай, що serving-рушії групують користувачів через спільну GPU-пам'ять і KV-кеші. Якщо тенанти мають бути сильно ізольовані, ізолюй їх на рівні інстансу — окремі процеси рушія або ноди — а не лише на рівні API.

Шар 3: Артефакти моделі — перевіряй те, що завантажуєш

Ваги моделі — це виконувані артефакти, і вони заслуговують на таке саме ставлення до supply chain, як образи контейнерів.

• Тільки safetensors. Формати на основі pickle (.bin, .pt) можуть виконувати код під час завантаження; у 2026 році немає жодного продакшн-виправдання для їх використання.
• Прив'язуй кожну модель до криптографічного хеша і перевіряй його під час розгортання, точно як image digest. Завантажуй з офіційних репозиторіїв видавця, а не з community re-upload-ів, і перевіряй підписи там, де видавець їх надає.
• Стався до fine-tuned внутрішніх моделей як до найціннішої інтелектуальної власності: сховище з контролем доступу, шифрування в стані спокою, логи аудиту на кожне читання. Якщо твоя модель була донавчена на пропрієтарних даних, модель і є цими даними.

Шар 4: Застосунок — вважай, що модель буде маніпульована

Все вище захищає інфраструктуру. Поведінка моделі — це окрема поверхня атаки, яку ми детально розглянули в статті Prompt Injection — і базовий рівень тут стосується обмеження того, що маніпульована модель може зробити:

• Інструменти з мінімальними привілеями: лише читання там, де можливо, жодних продакшн-credentials у зоні досяжності агента.
• Стався до виводу моделі як до недовіреного вводу — з валідацією до того, як він торкнеться shell, SQL чи downstream API.
• Sandboxed виконання з обмеженим egress для будь-якого коду, згенерованого моделлю.
• Людське підтвердження для незворотних дій.
• Повне логування промптів і викликів інструментів у твій SIEM. Логи інференсу — це телеметрія безпеки: спроби injection, зондування та аномальне використання інструментів мають викликати алерти, а не з'являтися лише у розборі після інциденту.

Чекліст на одну сторінку

Мережа: binding до localhost · захищені файрволом порти інференсу · автентифікований proxy або gateway · сегментація · default-deny egress. Платформа: non-root контейнери · без privileged mode · зафіксовані версії · патчинг на основі релізів · ізоляція тенантів на рівні інстансу. Артефакти: тільки safetensors · зафіксовані по хешу · довірені джерела · підписані там, де доступно · fine-tuned ваги як захищена IP. Застосунок: інструменти з мінімальними привілеями · валідовані виводи · sandboxed виконання · людина в контурі для незворотних дій · телеметрія інференсу в SIEM.

Ніщо з цього не потребує екзотичних інструментів — reverse proxy, файрвол, container runtime та дисципліна покривають більшу частину. Різниця між відкритим Ollama-боксом і розгортанням продакшн-рівня вимірюється днями роботи, а не місяцями. Що дійсно потрібно — це рішення ставитися до AI-інфраструктури як до того, чим вона насправді є: продакшн-сервіс із доступом до найчутливіших даних.

У NextVector ми будуємо backend, blockchain та AI-інфраструктуру, де безпека — це обмеження на рівні дизайну з першого дня. Плануєш on-premise LLM-розгортання? Зв'яжись з нами.