Любая on-premise нейросеть — это решето по умолчанию, пока вы не докажете обратное.
«Подождите, мы же развернули всё на своих серверах. Контур закрыт, наружу торчит только API для внутренних сервисов. Какая утечка?»
Типичная иллюзия безопасников, которые мыслят категориями классических веб-приложений. Выстроить ИБ-периметр для on-prem AI: как защитить контур с моделью, данными и GPU, чтобы прошёл аудит — это не просто накинуть firewall и закрыть порты. Нейросеть — это чёрный ящик. Она жрёт корпоративные данные терабайтами, генерирует непредсказуемый выхлоп и требует регулярного обновления весов гигабайтными чанками. Если злоумышленник или инсайдер получит доступ к GPU-ноде, он унесёт не только базу данных. Он унесёт мозги вашей компании.
Иллюзия изоляции и карта угроз AI-контура
Кому вообще нужны веса вашей RAG-системы?
Всем конкурентам. Кража модели — это моментальная кража интеллектуальной собственности, на тонкую настройку которой вы сожгли миллионы рублей и месяцы работы GPU-кластера. Злоумышленнику не нужно ломать приложение, достаточно найти открытый API-endpoint, через который примонтирована директория с файлами safetensors.
Но кража — это полбеды. Есть отравление данных (data poisoning). Представьте: кто-то загружает в корпоративную базу знаний вредоносный PDF-документ. RAG-пайплайн послушно его индексирует. Когда топ-менеджер спрашивает LLM: «Каковы риски сделки с компанией X?», модель вытаскивает отравленный вектор и галлюцинирует ответ, который манипулирует решением или подсовывает фишинговую ссылку во внутреннюю сеть.
«Но векторная база — это просто массивы чисел с плавающей точкой, их невозможно прочитать!»
Чушь. Эмбеддинги обратимы. Если атакующий сольёт ваш RAG-индекс, существуют доказанные атаки инверсии (model inversion), позволяющие восстановить исходный текст конфиденциальных документов с пугающей точностью. Шифрование вектора в покое (at-rest) и в транзите (in-transit) — это не прихоть, а абсолютная необходимость для систем, претендующих на аттестацию КИИ. Стоит ли шифрование latency? Да, вы потеряете драгоценные миллисекунды на расшифровку при каждом поиске ближайших соседей. Скорость генерации просядет. Зато когда сервер с векторной базой физически изымут или скомпрометируют админский доступ, вы не пойдёте под суд за массовый слив ПДн. Трейд-офф всегда один: либо вы платите задержкой ответа, либо платите репутацией и штрафами регулятора.
Архитектура и ИБ-периметр для on-prem AI: как защитить контур с моделью, данными и GPU, чтобы прошёл аудит
Здесь обычно начинается кровавая баня между Data Science и службой ИБ.
«Давайте сделаем полный air-gap. Выдернем кабель!»
Требует безопасник. И технически он прав. Физическая изоляция — стопроцентная гарантия того, что модель не сольёт данные на сторонний S3-бакет через хитрый prompt injection, заставивший её выполнить внешний HTTP-запрос. А такие уязвимости в LangChain и других оркестраторах всплывают с пугающей регулярностью.
Но полный air-gap мгновенно убивает MLOps.
Как вы планируете доставлять новые веса? Носить на зашифрованных флешках в серверную? Как обновлять зависимости CUDA, когда выходит критический патч безопасности? Как мониторить дрифт данных в реальном времени? В Morana Labs мы однажды наблюдали, как параноидально настроенный контур в одном финтех-проекте увеличил цикл выкатки новой версии модели с двух часов до двух недель из-за бесконечной бумажной волокиты и ручного переноса Docker-образов через шлюзы.
Баланс между эксплуатацией и паранойей лежит в жёстком контроле egress-трафика на уровне сети и гипервизора. Модель физически не должна иметь возможности инициировать соединение наружу. Никакого NAT, никакого IP-форвардинга на рабочих узлах. GPU-нода обязана быть заперта в строгий VLAN, куда пускают только входящие gRPC/REST запросы от внутреннего API-шлюза. Обновления весов и библиотек затягиваются строго через внутренний pull-registry, который сам ходит во внешнюю сеть через прокси с DPI, на лету валидируя чексуммы загружаемых артефактов.
Секреты, токены и ключи доступа к базам данных никогда не должны лежать в переменных окружения на GPU-воркере или в открытых ConfigMap. Только динамическая инъекция через Vault напрямую в память процесса инференса. Если атакующий каким-то чудом пробивает контейнер с моделью через уязвимость нулевого дня в движке инференса, он должен оказаться в пустой сетевой комнате без окон и дверей. Без сетевых утилит, без возможности сделать DNS-запрос или пропинговать соседнюю базу данных.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-gpu-egress-except-internal
namespace: ai-inference-prod
spec:
podSelector:
matchLabels:
workload-type: llm-worker
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.50.0.100/32
- ipBlock:
cidr: 10.50.0.200/32
ports:
- protocol: TCP
port: 443Логи промптов, ПДн и аттестация КИИ
«А как же логирование? Нам нужно видеть, что спрашивают пользователи, чтобы расследовать инциденты и улучшать качество ответов».
И тут вы наступаете на главную мину любого аудита.
Требования ФСТЭК предписывают полную прослеживаемость действий. Вы обязаны логировать всё. Но как только вы начинаете писать сырые промпты сотрудников в централизованную систему сбора логов, вы автоматически сливаете туда персональные данные клиентов, номера счетов, коммерческую тайну и случайно скопированные пароли. Служба ИБ, пытающаяся контролировать нейросеть, сама становится гигантским резервуаром утечки.
«Мы будем маскировать данные на лету!»
Звучит надёжно, пока не попадёт под реальную нагрузку. На практике NER-модели для поиска и маскировки PII либо катастрофически тормозят пайплайн, добавляя сотни миллисекунд к задержке первого токена, либо благополучно пропускают нестандартные финансовые реквизиты. Решение кроется в архитектурном разделении потоков. Если вы строите полноценный llm-rag-onprem контур, логирование должно быть строго стратифицированным.
- Сырые логи (Raw Prompts): пишутся асинхронно в изолированное хранилище WORM (Write Once Read Many). Аналитика по ним не строится. Доступ имеет только офицер ИБ по аппаратному токену в рамках инцидента.
- Обезличенные логи (Sanitized): прогоняются через легковесный регексп и хэширование сущностей в фоне, после чего летят в дашборды дата-саентистов для оценки RAG-метрик.
- Audit Trails: телеметрия доступа к железу и весам. Каждое чтение файла модели процессом, не принадлежащим инференс-серверу, генерирует критический алерт.
Аттестация значимых систем с генеративным ИИ внутри — это всегда столкновение лбами. Аудиторы пока сами не имеют жёстких методичек по проверке трансформеров, поэтому будут бить по классике: изоляция сетей, контроль доступа, криптография. Ваша архитектура должна доказывать одну предельно ясную вещь. Даже если модель сойдёт с ума, а админ кластера продаст свои ключи — корпоративные данные останутся запертыми на железе, а любая сетевая аномалия высветится в мониторинге до того, как векторную базу успеют сжать и отправить наружу. Всё остальное — лирика для конференций.