Безпека самостійно розгорнутих LLM: on-premise не означає безпечний за замовчуванням
Компанії переносять AI-навантаження в on-premise з цілком обґрунтованих причин: резидентність даних, відповідність GDPR і SOC 2, а також контроль витрат у масштабі. Запуск моделі з відкритими вагами (open-weight) у межах власного периметра означає, що промпти й донавчені ваги ніколи не залишають вашу інфраструктуру. Але за цим рішенням ховається небезпечне припущення: «воно працює на наших серверах, отже — це безпечно». Це не так. Self-hosting усуває один ризик — перегляд ваших даних третьою стороною — і перекладає на вас повну відповідальність за все те, що провайдер managed API раніше мовчки брав на себе: безпеку ендпоінтів, перевірку артефактів, ізоляцію та патчинг. Ось реальна поверхня атаки.
175 000 відкритих серверів інференсу
У вересні 2025 року Cisco Talos виявила понад 1100 інстансів Ollama в публічному інтернеті без жодної автентифікації. На початку 2026 року сканування SentinelLABS і Censys нарахували приблизно 175 000 публічно доступних хостів Ollama у 130 країнах, а також незахищені ендпоінти vLLM і LiteLLM.
Корінна причина: популярні інструменти для self-hosting створювалися заради зручності розробників. REST API Ollama постачається взагалі без вбудованої автентифікації. Достатньо одного біндингу на 0.0.0.0 або надто дозвільної security group у хмарі — і весь API стає відкритим. Зловмисники активно сканують інтернет у пошуках таких інстансів — задокументовані операції «LLMjacking» знаходять відкриті інстанси й перепродають доступ до них на тіньових майданчиках.
Відкритий ендпоінт дає зловмиснику безкоштовні обчислення на GPU, можливість витягнути ваші донавчені моделі (які і є вашими даними), видимість системних промптів і конфігурацій RAG, а також мережевий плацдарм усередині вашого периметра.
CVE у шарі інференсу
Шар обслуговування (serving layer) — це молоде програмне забезпечення, створене насамперед заради продуктивності. Ось його історія:
- Probllama (2024) — віддалене виконання коду (RCE) в Ollama
- CVE-2025-47277 — шар розподіленого інференсу vLLM викликав
pickle.loads()на даних із мережевого сокета: підручниковий приклад RCE - Bleeding Llama, CVE-2026-7482 — три неавтентифіковані виклики API давали витік системних промптів, сесій, ключів API та облікових даних БД з Ollama. Патч існував місяцями до того, як CVE отримав номер — увесь цей час сканери та compliance-інструменти цього не бачили
Висновок: сервер інференсу — це production-сервіс у мережі, і йому потрібна така сама дисципліна патчингу, як і вашій базі даних. Відстежуйте релізи upstream напряму — самі лише фіди CVE вас підведуть. Є й ризик, унікальний саме для AI: серверні движки об'єднують запити у спільні пули пам'яті GPU та KV-кеші. Скомпрометований процес може виливати фрагменти розмов інших користувачів, а привілейовані драйвери GPU залишають скомпрометований контейнер лише за один крок від хоста.
Ваги моделей — це виконувані артефакти
Команди застосовують supply-chain безпеку до коду, але завантажують ваги моделей із публічних хабів без будь-якої перевірки. Два сценарії збою: Шкідлива серіалізація. Формати моделей на основі pickle можуть виконувати довільний код під час завантаження. У 2026 році немає жодної причини завантажувати в production щось, крім safetensors. Отруєння моделі (model poisoning). Ваги, які на бенчмарках поводяться нормально, але донавчені так, щоб за певних умов зливати дані або виконувати приховані інструкції. Без збоїв, без записів у логах. Рішення — класична гігієна ланцюга постачання: тільки довірені джерела, артефакти прив'язані до перевірених хешів, підписи моделей там, де вони доступні, а внутрішні донавчені моделі трактуються як найцінніша інтелектуальна власність компанії.
Prompt injection не залежить від того, де працює модель
Шкідливі інструкції, вбудовані в документи, листи чи вебсторінки, працюють однаково і проти self-hosted, і проти хмарних моделей. А self-hosting часто робить ситуацію гіршою: моделі з відкритими вагами мають слабше навчання з безпеки, команди вимикають guardrails, бо «це ж внутрішнє», а модель on-premise зазвичай має значно привілейованіший доступ — до баз даних, внутрішніх API, інструментів файлової системи — ніж будь-коли матиме хмарна модель. OWASP Top 10 для LLM-застосунків — правильний фреймворк для орієнтиру. Головне: доступ до інструментів за принципом найменших привілеїв, ставлення до виходу моделі як до недовіреного вводу, виконання коду в пісочниці та фільтрація вихідного трафіку на воркерах інференсу.
Базовий рівень hardening
Мінімальна планка для production:
- Мережа: біндинг до localhost або приватних підмереж; увесь доступ — лише через автентифікований reverse proxy або LLM gateway; фільтрація вихідного трафіку за замовчуванням
- Платформа: контейнери без root, мінімальний набір capabilities, патчинг, що відстежує релізи upstream
- Артефакти: тільки safetensors, прив'язані до хешів, сховище з контролем доступу для донавчених ваг
- Застосунок: ревʼю за OWASP LLM Top 10, валідація виходу моделі, повне логування інференсу у ваш SIEM
У цьому немає нічого екзотичного — це та сама дисципліна, яку ви вже застосовуєте до баз даних, поширена на нове навантаження, яке більшість команд наразі розгортають з рівнем безпеки вихідного дня хобі-проєкту.
Висновок
«On-premise» — це властивість резидентності даних, а не властивість безпеки. 175 000 відкритих серверів інференсу — це не провал інструментів, а провал мислення: AI-інфраструктуру розгортають як десктопний застосунок, хоча її слід трактувати як production-базу даних. У NextVector ми будуємо backend- та blockchain-інфраструктуру, де безпека — це вимога дизайну, а не запізніла думка, — і та сама дисципліна напряму стосується AI. Плануєте on-premise розгортання AI? Звʼяжіться з нами.