Перейти к содержанию

Сетевая изоляция

Цель

Безопасная установка не должна публиковать наружу каждый контейнер отдельно. Внешняя сеть должна видеть только необходимые точки входа.

Базовая схема

пользователь
   ↓ HTTPS
входной веб-сервер
   ↓
внутренняя сеть Студии
   ├── основная серверная часть
   ├── панель администратора
   ├── MongoDB
   ├── Redis
   ├── поисковый индекс
   ├── векторная база
   ├── RAG
   ├── интернет-поиск
   ├── защитный получатель страниц
   ├── Центр управления моделями
   ├── шлюз Яндекс Облака
   └── локальная модель

Большинство внутренних компонентов не должны быть доступны пользователю напрямую.

1. Входящий трафик

Обычно снаружи требуются:

  • основной HTTPS-интерфейс;
  • при необходимости отдельно защищённая административная панель.

Не публикуйте без необходимости:

  • MongoDB;
  • PostgreSQL/pgvector;
  • Redis;
  • Meilisearch;
  • RAG;
  • SearXNG;
  • среду локальной модели;
  • внутренний шлюз Яндекс Облака.

Публикация базы «для удобства» увеличивает поверхность атаки.

2. Административная панель

В рабочей среде желательно:

  • ограничить доступ внутренней сетью, VPN или иным доверенным контуром;
  • не использовать общий пароль;
  • применять отдельные административные учётные записи;
  • по возможности усиливать вход дополнительной проверкой;
  • журналировать изменения системных прав.

Если панель опубликована в Интернет, это должно быть осознанным архитектурным решением.

3. TLS

Используйте HTTPS в рабочем контуре.

Проверьте:

  • доменное имя соответствует сертификату;
  • сертификат не истёк;
  • цепочка доверена пользователям;
  • закрытый ключ защищён;
  • HTTP обрабатывается согласно политике;
  • cookies используют безопасные параметры при HTTPS.

Самоподписанный сертификат допустим на закрытом тестовом стенде, но постоянное предупреждение браузера в рабочем публичном контуре не должно считаться нормой.

4. Исходящий трафик

Набор направлений зависит от функций.

Полностью локальный чат

После установки модели постоянный внешний доступ может быть не нужен, если внешние возможности выключены.

Интернет-поиск

Требует выхода к поисковым источникам и веб-страницам.

Яндекс Облако

Требует доступа к IAM и нужным API.

Yandex AI

Требует доступа к Yandex AI Studio.

Установка моделей

Требует доступа к источнику модельного артефакта, если он не доставлен заранее.

Обновление

Требует доступа к источникам релиза либо заранее подготовленного автономного комплекта.

5. Политика исходящих соединений

Для защищённой среды полезно перейти от:

серверу разрешён весь Интернет

к:

разрешены только необходимые направления

Документируйте:

  • назначение соединения;
  • адрес назначения;
  • компонент-инициатор;
  • протокол;
  • владельца интеграции;
  • необходимость;
  • порядок отключения.

6. Защита от внутренних URL через веб-поиск

Пользователь или вредоносная страница может попытаться заставить сервер получить адрес вроде:

http://127.0.0.1:...
http://localhost:...
http://10.x.x.x/...
http://169.254.x.x/...

Это опасно, потому что сервер видит внутренние службы, недоступные обычному пользователю.

Защитный получатель должен проверять назначение до запроса и после перенаправлений.

Блокировать следует как минимум:

  • loopback;
  • частные диапазоны;
  • link-local;
  • служебные адреса облачных метаданных;
  • запрещённые схемы URL;
  • перенаправление во внутренний адрес.

7. Облачные метаданные

В облачной ВМ могут существовать служебные адреса метаданных.

Компонент, который получает произвольные URL, не должен иметь к ним доступ. Иначе возникает риск чтения служебной информации через уязвимость класса SSRF.

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

8. DNS

Ошибки DNS часто выглядят как проблема модели или облака.

Проверяйте разрешение имён отдельно, например:

getent hosts example.com

Если используются внутренние имена:

  • разделяйте публичный и внутренний DNS;
  • не допускайте утечки внутренних имён во внешний поиск;
  • документируйте split DNS;
  • проверяйте прокси.

9. Корпоративный прокси

Определите:

  • какие компоненты идут через прокси;
  • какие внутренние адреса его обходят;
  • где хранится пароль прокси;
  • выполняется ли TLS-перехват;
  • установлен ли корпоративный центр сертификации.

Если прокси подменяет сертификаты, контейнеры должны доверять корпоративному центру осознанно.

Не отключайте проверку TLS глобально.

10. Не отключайте проверку сертификатов

Плохой обход:

verify_tls = false

Если соединение ломается из-за корпоративного сертификата:

  1. получите правильный корневой сертификат;
  2. добавьте его в доверенное хранилище нужного компонента;
  3. перезапустите компонент;
  4. повторите проверку;
  5. оставьте проверку TLS включённой.

11. Внутренняя сеть контейнеров

Различайте:

  • внешние порты;
  • внутренние имена контейнеров;
  • служебные сети;
  • сети интеграций.

Компоненту не нужен опубликованный порт только потому, что с ним общается другой контейнер.

12. Базы данных

Для MongoDB, pgvector, Redis и поискового индекса:

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

13. Сеть локальной модели

Среда локальной модели не должна быть доступна произвольным внешним клиентам.

Иначе стороннее приложение сможет обойти:

  • аутентификацию Студии;
  • права пользователей;
  • журналирование;
  • политики;
  • ограничения доступа.

Пользователь обращается к модели через Студию.

14. Яндекс Облако

При ошибке не открывайте «весь Интернет на все порты».

Проверяйте по порядку:

  1. DNS;
  2. TCP/443;
  3. TLS;
  4. прокси;
  5. IAM;
  6. конкретный API;
  7. права.

15. Billing

Финансовый сервис должен обращаться только к необходимым Billing API и не должен требовать публикации своей внутренней точки наружу.

Пользователь работает через основной интерфейс Студии.

16. Резервное хранилище

Если резервная копия отправляется в отдельное хранилище:

  • используйте отдельные учётные данные;
  • разрешите только нужное направление;
  • ограничьте право записи/чтения;
  • по возможности используйте неизменяемость или версии;
  • отделяйте рабочую учётную запись приложения от учётной записи резервирования.

17. Сетевой контрольный список

Снаружи сервера:

[ ] HTTPS Студии доступен
[ ] панель администратора доступна только из ожидаемого контура
[ ] MongoDB не опубликована
[ ] PostgreSQL не опубликован
[ ] Redis не опубликован
[ ] Meilisearch не опубликован
[ ] RAG не опубликован
[ ] среда модели не опубликована
[ ] внутренний шлюз YC не опубликован

Изнутри:

[ ] DNS работает
[ ] нужные HTTPS-направления доступны
[ ] ненужные направления закрыты
[ ] веб-получатель не открывает внутренние URL
[ ] адрес облачных метаданных недоступен через веб-получатель

18. После изменения сетевой политики

Проведите тесты:

  1. локальный чат;
  2. RAG;
  3. интернет-поиск;
  4. Яндекс Облако;
  5. Yandex AI;
  6. Billing;
  7. установка модели, если разрешена;
  8. резервное копирование во внешнее хранилище.

Не считайте политику успешной только потому, что контейнеры имеют статус healthy.

См. также

Известное сетевое рассогласование 0.3.66

Фактический compose.yml выпуска 0.3.66 публикует административную панель на внешнем порту 3001 по HTTP. Это не соответствует целевой схеме «одна защищённая HTTPS-точка входа».

До исправления следующего выпуска:

  • блокируйте 3001/tcp для Интернета на уровне security group / firewall;
  • разрешайте его только из доверенной административной сети, если панель действительно нужна напрямую;
  • основной пользовательский вход выполняйте через HTTPS 8143;
  • после обновления повторно проверьте опубликованные порты.

Этот пункт считается продуктовым блокером, а не рекомендуемой архитектурой.