«Локально» — это про место обработки, а не про права доступа

Локальная модель решает важную задачу: запросы могут обрабатываться на оборудовании компании, а не отправляться внешнему AI API. Но слово «локально» описывает расположение вычислений, а не то, кто вправе обратиться к серверу. Если служба доступна из офисной сети, это уже внутренний сетевой сервис со своими границами доверия.

На примере Ollama документация указывает, что API по умолчанию слушает `127.0.0.1:11434`. Чтобы открыть доступ по сети, адрес меняют через `OLLAMA_HOST`. Это полезно для сценария с отдельным сервером и несколькими пользователями, но настройка привязки не добавляет сама по себе аутентификацию, роли или журналирование. В API-примерах локальный адрес вызывается без ключа авторизации; поэтому доступ к порту следует считать привилегией, которую нужно ограничивать сетевыми и прикладными средствами.

Представьте, что стажёр-робот хотел подключить к модели один рабочий компьютер, но принёс в серверную весь клубок офисных кабелей. Он не злонамерен — просто не умеет отличать «дать нужному сервису» от «дать всем, кто нашёл розетку».

Сначала определите, кому нужен прямой доступ

Для одного пользователя или прототипа оставьте API на loopback (`127.0.0.1`) и обращайтесь к нему с того же компьютера. Не меняйте `OLLAMA_HOST` на `0.0.0.0` просто потому, что так проще проверить подключение. Такая привязка слушает на всех IPv4-интерфейсах, а фактическую доступность затем определяют firewall, маршрутизация и контейнерная конфигурация.

Если пользователям нужен общий чат-интерфейс, не обязательно выдавать каждому прямой доступ к API модели. Оставьте Ollama на отдельном хосте и поставьте перед пользовательским интерфейсом слой доступа: корпоративный VPN, аутентифицирующий reverse proxy или управляемый шлюз с TLS. Руководство Open WebUI рекомендует держать интерфейс за VPN, zero-trust proxy либо reverse proxy с аутентификацией и ограничением по IP; сам интерфейс не следует публиковать напрямую в интернет без дополнительного контроля.

Минимальная схема для малого офиса

Практичный первый вариант выглядит так:

  • **Модельный сервер** расположен в отдельном сегменте или на выделенном узле. Порт Ollama не опубликован в интернет и недоступен из гостевого Wi-Fi.
  • **Пользовательский вход** проходит через один известный URL с TLS и проверкой личности. Если уже есть корпоративный VPN или шлюз идентификации, используйте его, не добавляя отдельную публичную точку входа.
  • **Межсетевые правила** разрешают соединения только от конкретного proxy или backend-сервиса к API модели. Рабочим станциям и другим VLAN не нужен прямой маршрут к порту инференса.
  • **Сервисные учётные данные** разделены между приложениями и людьми; права ограничены тем, что нужно сценарию. Если шлюз не умеет проверять права, не считайте одну лишь сетевую изоляцию полноценной авторизацией.
  • **Журналы** фиксируют пользователя или сервис, время, результат доступа и объём запроса. Содержимое промптов записывают только при наличии основания, политики хранения и защиты этих журналов.

Это не обязательно сложная zero-trust-платформа. Для небольшого предприятия смысл проще: внутренний IP-адрес не является удостоверением личности, а доступ к одному ресурсу не должен автоматически открывать соседние ресурсы. Именно такую смену акцента — с доверия к расположению в сети на идентичность и отдельные ресурсы — описывает NIST в SP 800-207.

Когда нужен reverse proxy — и чего он не делает автоматически

Reverse proxy удобен как единая точка входа: он может завершать TLS, проверять входящие учётные данные, ограничивать частоту запросов и писать журналы доступа. Но обычная настройка `proxy_pass` лишь пересылает HTTP-запросы. Если аутентификация не настроена, proxy не защищает API магическим образом. Также проверьте, что прямой порт Ollama недоступен в обход proxy: иначе пользователь или устройство может обойти все правила на входе.

Для браузерных интерфейсов есть ещё один частый ложный сигнал безопасности. Ограничение CORS через `OLLAMA_ORIGINS` регулирует, какие origin браузеру разрешено использовать для cross-origin запросов. Оно не заменяет аутентификацию и сетевой firewall: не-браузерный клиент не обязан подчиняться браузерной политике CORS.

Разделите входящий и исходящий трафик. Для сервиса может быть нужен выход в интернет для обновлений или загрузки моделей, но это не означает, что сам порт инференса следует открыть во внешнюю сеть. Задайте отдельные правила для обновлений и для пользовательских запросов.

Проверка перед пилотом

Перед загрузкой внутренних документов проведите короткий технический тест с ИТ-ответственным:

1. На самом сервере проверьте ожидаемый адрес прослушивания и локальный вызов API.
2. С обычной рабочей станции, гостевого Wi-Fi и внешней сети проверьте, что прямой порт доступен только там, где это предусмотрено схемой.
3. Проверьте пользовательский путь через proxy: без входа запрос отклоняется; с учётной записью уходит к модели; в журнале есть субъект и результат.
4. Убедитесь, что остановка proxy закрывает пользовательский доступ, а не оставляет открытый обходной порт.
5. Измените правило доступа тестовой учётной записи и подтвердите, что отзыв действительно прекращает новые запросы.

Не ограничивайтесь проверкой с компьютера администратора: у него часто есть маршруты и права, которых у обычного сотрудника нет. И не отправляйте реальные персональные или коммерческие данные на этапе сетевого теста — достаточно синтетического запроса.

Ограничения и стоимость

Более строгая схема добавляет работу: настройку DNS и сертификатов, поддержку proxy или VPN, управление учётными записями, обновления, мониторинг и процедуру восстановления доступа. Для одного автономного рабочего места это может быть лишним. Для нескольких отделов стоимость проще сравнивать не с «бесплатным локальным API», а с часами ИТ-сопровождения, риском случайного доступа и требованиями к доступности сервиса.

Локальное исполнение также не гарантирует, что данные не покинут контур при любых обстоятельствах. Важно проверить режим продукта и его облачные функции, сетевые маршруты, плагины, логи, резервные копии и интеграции. Если в архитектуре есть облачная модель или внешний инструмент, именно туда могут уходить отдельные запросы.

Что сделать на этой неделе

Составьте одну таблицу: кто вызывает модель, откуда, через какую точку входа, какие данные передаёт и кто может отозвать доступ. Начните с loopback для одиночного сценария; для общего доступа выберите уже имеющийся корпоративный шлюз, закройте прямой порт firewall-ом и проверьте пользовательский путь с обычной учётной записью.

Так локальный ИИ останется локальным по обработке — и не станет общедоступным только потому, что все кабели оказались в одной стойке.