Медицинская система только по секретной ссылке: обратный прокси с ежемесячной ротацией токена

Медицинская организация пользуется облачной медицинской информационной системой (МИС). Вендор системы умеет ограничивать доступ по IP-адресу, но у клиники несколько площадок, сотрудники работают и из дома, и с мобильных устройств, а провайдеры меняют адреса. Нужно было сделать так, чтобы страница входа в МИС была видна только своим, при этом не зависеть от IP на стороне пользователей и не переделывать саму МИС.

Идея

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

Получается три уровня: вендор видит один доверенный адрес, случайный сканер интернета получает 404 вместо формы логина, а своим достаточно один раз в месяц открыть новую ссылку.

Из чего собрано

• Небольшой сервер на Ubuntu с Docker.
• Nginx Proxy Manager как обратный прокси и для сертификатов Let's Encrypt.
• Свой фрагмент конфигурации nginx: map, который выбирает действующий токен по текущему месяцу.
• Скрипт, который раз в год генерирует 12 токенов и ссылок, и запись в cron.

Как выбирается токен без перезапусков

В nginx есть переменная $time_iso8601. Сопоставляем её с шаблоном «год-месяц» и получаем токен месяца — без скриптов и перезапусков прокси:

map $time_iso8601 $gw_token {
    default        "";
    "~^2026-10-"    "<токен октября>";
    "~^2026-11-"    "<токен ноября>";
    # ... по строке на каждый месяц
}

Дальше в настройках хоста: если в запросе есть параметр gw и он совпадает с $gw_token — ставим cookie и перенаправляем на корень. Если cookie нет или она не совпадает с токеном текущего месяца — отдаём 404. Старая ссылка с прошлого месяца автоматически перестаёт работать 1-го числа.

На чём мы споткнулись

Три момента, которые сэкономят время тем, кто повторит схему на Nginx Proxy Manager.

Include несуществующего файла ломает проверку конфигурации. Файл с токенами держим постоянно, даже пустым, иначе NPM отказывается применять настройки хоста.

Поле Advanced в NPM «теряет» содержимое после неудачного сохранения. После любой ошибки нужно перепроверить, что кастомный конфиг на месте, — иначе сертификат и правила молча не применяются.

МИС отвечала «система недоступна» через прокси. Причина — заголовки X-Forwarded-For, X-Real-IP, X-Forwarded-Proto, X-Forwarded-Host передавали адреса клиентов, и МИС видела «чужой» IP. Решение — очистить эти заголовки на прокси, тогда МИС видит только адрес шлюза.

Безопасность после запуска

• Токены, которые засветились во время отладки, сразу перегенерировали.
• Закрыли с интернета административные порты NPM и Portainer, оставили только 80 и 443.
• Вендору на белый список ушёл исходящий адрес шлюза, а не входящий — у сервера за NAT это разные адреса.

Что получил заказчик

Форма входа в МИС исчезла из общего интернета, при этом никто не поменял привычки: та же ссылка в закладках, тот же логин. Раз в месяц ответственный сотрудник рассылает новую ссылку. Схема не зависит от вендора МИС и подходит для любой веб-системы, которую нельзя спрятать за VPN — от бухгалтерских порталов до внутренних панелей.

\newpage