8 (3952) 204-810
0Корзина

ViPNet и защищённый веб‑доступ: обратный прокси и TLS‑туннели

ViPNet и защищённый веб‑доступ: обратный прокси и TLS‑туннели

ViPNet позволяет организовать защищённый доступ к веб‑приложениям и внутренним порталам как для сотрудников, так и для внешних пользователей, не «выставляя» приложения напрямую в интернет.

В основе подхода — использование обратного прокси, TLS‑туннелей и отечественной криптографии, что позволяет централизованно контролировать аутентификацию, шифрование и публикацию сервисов.

Задачи, которые решает защищённый веб‑доступ на ViPNet

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

Безопасная публикация внутренних сервисов

Веб‑порталы, личные кабинеты, админ‑панели, API и другие HTTP(S)‑сервисы публикуются наружу через обратный прокси ViPNet, а не напрямую с внутренних серверов.

Защита трафика и аутентификация

Шифрование по TLS (в том числе с ГОСТ‑алгоритмами), проверка сертификатов и учётных данных, контроль доступа по политике и журналирование обращений.

Разделение внешнего и внутреннего контуров

Веб‑серверы и приложения могут оставаться во внутреннем сегменте, доступ к ним осуществляется только из DMZ со стороны прокси, что уменьшает поверхность атаки.

Обратный прокси ViPNet: общая схема работы

Обратный прокси (reverse proxy) на базе ViPNet работает как «фронт» для одного или нескольких веб‑приложений: с точки зрения клиента он — конечный веб‑сайт, а уже внутри проксирует запросы в нужные backend‑системы.

Функции обратного прокси

- Приём входящих HTTPS‑подключений от пользователей (TLS‑терминация).
- Проверка аутентификации (сертификаты, логин/пароль, внешние MFA‑сервисы).
- Маршрутизация запросов к нужным внутренним веб‑приложениям по URL/хосту.
- При необходимости — повторное шифрование трафика до backend (TLS‑от‑прокси‑до‑сервера).

Расположение в инфраструктуре

- Размещается в DMZ на границе с внешней сетью (интернет, сети партнёров).
- Имеет один «наружный» интерфейс для клиентов и один/несколько «внутренних» к веб‑серверам.
- Может быть развернут отдельно или на базе шлюзов ViPNet (Coordinator/VA) в составе периметра.

TLS‑туннели и схемы шифрования

Защищённый веб‑доступ в ViPNet‑архитектуре опирается на TLS‑туннели, причём трафик может шифроваться как «до прокси», так и дальше — до конечного приложения, в зависимости от требований безопасности.

Вариант 1. TLS до прокси

Клиент устанавливает TLS‑соединение с обратным прокси ViPNet, а прокси внутри ходит к backend‑сервисам по обычному HTTP. Удобно для упрощения конфигурации приложений, при условии, что внутренний сегмент доверенный.

Вариант 2. TLS до backend

Обратный прокси завершает внешнее TLS‑соединение и устанавливает отдельный TLS‑туннель до каждого внутреннего веб‑приложения. Так шифруется весь путь «клиент → прокси → сервер».

Вариант 3. «Сквозной» TLS‑туннель

Для некоторых сценариев прокси может работать в более прозрачном режиме, когда основное шифрование обеспечивается прикладной TLS‑инфраструктурой (например, на базе ViPNet OSSL), а прокси выполняет авторизацию и L7‑маршрутизацию.

Модели аутентификации при защищённом веб‑доступе

Обратный прокси ViPNet позволяет реализовать несколько вариантов аутентификации пользователей при доступе к веб‑приложениям, в том числе с использованием PKI и многофакторных схем.

Сертификатная и доменная аутентификация

- Двусторонний TLS: клиент предъявляет сертификат, прокси проверяет его валидность через PKI.
- Интеграция с AD/LDAP: после проверки сертификата можно маппить пользователя на доменную учётку.
- Разграничение доступа к разным приложениям на уровне групп и ролей.

Многофакторная аутентификация (MFA)

- Использование внешних систем OTP/Push/аппаратных токенов в качестве второго фактора.
- Сценарий: сертификат + OTP, доменный логин + push‑подтверждение и т.п.
- Вынесение логики MFA на фронтовой уровень (прокси), без изменение кода самих приложений.

Связка с ViPNet OSSL и PKI

Для построения полноценного защищённого веб‑доступа прокси‑уровень ViPNet логично использовать совместно с TLS‑стеком ViPNet OSSL и PKI‑инфраструктурой.

ViPNet OSSL как криптодвижок

Обеспечивает работу TLS с отечественными криптоалгоритмами для внешних и внутренних HTTPS‑соединений, а также поддерживает нужные наборы шифров и версии протокола.

ViPNet PKI Service

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

HSM для хранения ключей

Для критичных сервисов серверные ключи можно хранить в HSM, а обратный прокси использовать криптоинтерфейс для операций подписания и расшифрования, не «вынося» ключи на диск.

Типовые сценарии применения

Защищённый веб‑доступ на базе ViPNet востребован там, где нужно «вытащить» вовне существующие внутренние веб‑сервисы или обеспечить контролируемый доступ извне к чувствительным системам.

  • Публикация внутренних порталов и личных кабинетов для удалённых сотрудников и партнёров.
  • Безопасный доступ к административным консолям и панелям управления (вынесенным за VPN).
  • Защита REST/SOAP‑API корпоративных систем для внешних интеграций.
  • Организация доступа к системам мониторинга, ИТ‑сервисам и ЭДО из филиалов и сторонних сетей.
  • Создание единой «точки входа» для веб‑приложений с централизованной аутентификацией и авторизацией.
  • Разделение внешнего и внутреннего контуров при работе с государственными и отраслевыми сервисами.
  • Построение DMZ‑зоны, где обратный прокси ViPNet служит единственным шлюзом к внутренним веб‑ресурсам.

Преимущества подхода с обратным прокси и TLS‑туннелями ViPNet

Такой подход позволяет не только повысить безопасность, но и упростить управление веб‑доступом и его масштабирование.

Централизация настроек

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

Меньшая поверхность атаки

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

Гибкость и масштабируемость

Добавление новых веб‑сервисов, смена схемы аутентификации или обновление криптополитик происходят на уровне прокси, что значительно ускоряет изменения.

Как подойти к проектированию защищённого веб‑доступа на ViPNet

На практике стоит начать с инвентаризации всех веб‑сервисов, которые нужно сделать доступными извне: порталы, API, админ‑интерфейсы. Далее — спроектировать DMZ, выбрать схемы TLS‑терминации и варианты аутентификации (сертификаты, домен, MFA).

После этого можно описать карту маршрутизации (какой URL к какому backend‑у), настроить политики для разных категорий пользователей и провести пилот с ограниченным набором сервисов, прежде чем выводить архитектуру в промышленную эксплуатацию.