Закрытый контур: биллинг, который сам не ходит наружу

Перед покупкой биллинга служба безопасности оператора задаёт один вопрос, и задаёт его раньше, чем спрашивают про тарифы и отчёты: куда эта система ходит сама? Не «какие у неё интеграции», а куда уходят пакеты с сервера, на котором лежат паспорта абонентов, балансы и записи разговоров. Ответ «никуда, честное слово» не принимается — нужен способ проверить. Так в СмИТ Биллинге появился закрытый контур.

Четыре вопроса службы безопасности

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

1. биллинг обращается только к серверу лицензий и больше никуда;
2. если у сервера лицензий нет отдельного адреса — всё идёт через прокси оператора;
3. все функции ИИ принудительно выключены;
4. ИИ работает, но через собственную языковую модель оператора, а не через облако.

Честный ответ на тот момент: ни один сценарий без доработок не выполнялся. Сервер лицензий сам решал, какие сервисы идут через наш шлюз, а через шлюз проходили данные абонентов — подсказки адресов, SMS, чат личного кабинета. Общего выключателя ИИ не было, адреса провайдеров были прописаны в коде, а файлы клиентов без облачного хранилища не сохранялись.

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

Одна настройка — и её не поменять снаружи

Закрытый контур включается одной строкой в конфигурации на сервере оператора. Это принципиально: режим нельзя выключить из интерфейса биллинга и нельзя переключить с сервера лицензий. Разработчик не может «временно открыть доступ» удалённо, а сотрудник с правами администратора — случайно сломать контур галочкой в настройках.

После включения биллинг работает как обычно: начисления, платежи, авторизация абонентов (RADIUS), личный кабинет, отчёты и CRM не зависят ни от внешних сервисов, ни от ИИ. Меняется только то, что биллинг перестаёт ходить наружу.

Сторож исходящих соединений

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

Биллинг проверяет адрес назначения на двух уровнях. Первый — разрешение имени: обращение к DNS перехватывается у любой библиотеки сразу, будь то HTTP-клиент, почта или FTP. Второй — сам HTTP-запрос: адрес проверяется, даже когда запрос идёт через прокси и имя назначения биллинг сам не разрешает.

flowchart LR
  B["Биллинг<br/>на сервере оператора"] --> G{"Сторож<br/>соединений"}
  G -- "внутренняя сеть,<br/>база, Redis, RADIUS" --> I["Разрешено"]
  G -- "сервер лицензий:<br/>ключ и домен" --> L["Разрешено"]
  G -- "своя модель ИИ,<br/>прокси оператора" --> M["Разрешено"]
  G -. "любой другой адрес" .-> X["Заблокировано<br/>и записано в журнал"]

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

Журнал — главное в этой истории. Он превращает «мы обещаем» в «посмотрите сами»: если что-то в системе пытается выйти за периметр, это видно в тот же день.

Что уходит на сервер лицензий

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

А вот что в закрытом контуре перекрыто даже для него:

ИИ: выключить совсем или подключить свою модель

С ИИ у служб безопасности два разных запроса, и мы поддерживаем оба.

Выключить полностью. Все функции ИИ — помощник в личном кабинете и приложении, бот поддержки, черновики ответов, расшифровка звонков, ИИ в отчётах — отвечают «ИИ отключён на этой установке» без единого сетевого запроса. Адреса облачных провайдеров ИИ закрыты сторожем даже при открытом интернете, ключи читаются пустыми, фоновые задачи ИИ не запускаются. Этот выключатель работает и без закрытого контура.

Своя модель. Если у оператора есть собственная языковая модель с API, совместимым с OpenAI (Ollama, vLLM, LM Studio, корпоративный шлюз), все запросы ИИ идут туда: помощник, бот поддержки, подсказки в CRM, расшифровка звонков. Облачные провайдеры не используются вовсе.

flowchart LR
  F["Функция ИИ:<br/>помощник, бот,<br/>расшифровка"] --> Q{"Режим<br/>установки"}
  Q -- "ИИ выключен" --> OFF["«ИИ отключён»<br/>без сетевого запроса"]
  Q -- "своя модель" --> OWN["Модель оператора<br/>во внутренней сети"]
  Q -. "облако" .-> NO["Закрыто сторожем"]

Файлы остаются у оператора

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

Закрытые файлы — документы клиентов, записи разговоров, переписка — по прямому адресу не открываются. Их отдаёт сам биллинг по подписанной ссылке: сотруднику — после входа, клиенту — по ссылке из письма с ограниченным сроком. Как устроены такие ссылки, мы подробно рассказывали в статье «Копии базы — под замком».

Чем за это приходится платить

Закрытый контур — это компромисс, и о нём лучше знать заранее, чем узнать на запуске. Без внешних сервисов не работают:

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

Каждое такое исключение можно вернуть точечно: например, оставить свой Telegram-бот через прокси оператора. Это решение принимает оператор, а не мы.

Как проверить самому

Мы не просим верить на слово. К поставке прилагается протокол проверки: служба безопасности закрывает на межсетевом экране весь исходящий трафик сервера биллинга, кроме нужного по сценарию, и проходит рабочие сценарии — создать абонента, начисление, платёж, авторизацию по RADIUS, вход в личный кабинет, отчёт, сделку в CRM.

Журнал межсетевого экрана и журнал самого биллинга должны сойтись. Если в журнале биллинга видна попытка выйти наружу, это повод разобраться, а не исключение «на всякий случай».

Как это работает в СмИТ Биллинге

Закрытый контур — штатный вариант поставки на сервер оператора. Включает его администратор сервера в конфигурации установки, вместе с ним задаются разрешённые адреса, прокси, выключатель ИИ или адрес своей модели.

Журнал заблокированных обращений — «Настройки» → «Лицензия и расширения» → «Закрытый контур». Там же проверяется любой адрес: будет ли он заблокирован и почему. Для службы безопасности мы передаём два документа: «Закрытый контур» с протоколом проверки и «Исходящие соединения биллинга» — каждый адрес, порт, протокол и что по нему передаётся.