Собираем вместе: временный доступ без единственной волшебной двери
Цикл «Не светим лишнего». Выпуск 14.

За предыдущие выпуски мы накопили приличный набор инструментов. Было бы странно теперь выбрать один и заставить его защищать вообще всё.
HTTP-панель, RDP подрядчика, IPMI, dev-база и доступ филиала — разные задачи. Им нужны разные точки входа, но единая логика выдачи прав.
Один контроллер, несколько точек применения
В центре находится контроллер политики. Он хранит пользователей или токены, роли, группы ресурсов, сроки и активные сессии. Сам трафик через него идти не обязан.
Решение применяется там, где это удобнее:
- MikroTik или другой firewall управляет L3/L4-доступом;
- reverse proxy проверяет пользователя перед HTTP-приложением;
- Guacamole проводит индивидуальные RDP/SSH/VNC-сессии;
- VPN-шлюз даёт полноценную приватную связность;
- SPA или port knocking остаётся резервным техническим входом.
В терминах Zero Trust это иногда называют Policy Decision Point и Policy Enforcement Point. По-человечески: один компонент решает, другой стоит у двери и исполняет решение.
Как разложить ресурсы
Корпоративные веб-системы. Reverse proxy + OIDC/MFA. Если приложение особенно чувствительное, дополнительно короткий IP allow-list.
Dev- и test-контуры. TOTP + heartbeat открывает только адреса и порты конкретного проекта. Веб-интерфейсы при этом могут идти через proxy.
RDP и SSH подрядчиков. Web-bastion, без прямого внешнего NAT. Отключённая передача файлов, персональная учётка, при необходимости запись.
Нативные инструменты администраторов. TOTP + heartbeat или персональный VPN. Выбор зависит от того, нужны ли приватные адреса и много маршрутов.
IPMI, iDRAC, iLO, гипервизоры. Не публиковать напрямую. Bastion или управляемый VPN из отдельного административного сегмента.
Филиалы и системные интеграции. Статические allow-list и site-to-site VPN, потому что источник стабилен и является системой, а не случайным человеком.
Гостевой и технологический Wi‑Fi. Captive portal выдаёт базовую роль; дополнительный TOTP включает инженерную группу на время работ.
Аварийный доступ. Персональный SPA либо отдельный knocking-профиль с коротким timeout, журналом и собственной авторизацией конечного сервиса.
Пример ролей
monitoring — HTTPS к Grafana и Zabbix, без доступа к серверам.
developer-project-a — SSH к двум dev-хостам, HTTPS к registry и тестовой панели.
cctv-contractor — Guacamole-подключение к сервисной машине и web-доступ только к камерам нужного объекта.
incident-admin — расширенная роль максимум на два часа, с обязательным TOTP и уведомлением ответственному.
infrastructure-core — только с корпоративного устройства через сертификатный VPN и bastion.
Плюсы комбинированной схемы
- каждый ресурс получает подходящий способ защиты;
- нет единого широкого сетевого входа для всех;
- права описываются ролями и группами ресурсов;
- временность и отзыв работают единообразно;
- можно внедрять постепенно;
- отказ одного способа не требует раскрывать весь периметр.
Минусы
- компонентов больше, чем у одного VPN;
- нужна нормальная инвентаризация ресурсов;
- журналы придётся собирать из нескольких точек;
- роли могут разъехаться между proxy, firewall и bastion;
- контроллер политики становится важной внутренней системой.
Где можно больно ошибиться
Fail open. При падении контроллера старые короткие leases должны истечь, а новые — не выдаваться. Никакого «временно разрешим всем, пока база не вернулась».
Разные источники истины. Если роль удалена в портале, но осталась вручную на firewall, отзыв не работает. Ручные исключения либо запрещаем, либо регулярно сверяем.
Слишком крупные роли. admin-all быстро становится единственной используемой группой. Роли строим вокруг работы и ресурса.
Нет отдельного management-контура. API firewall, база секретов и админка портала не должны быть доступны через тот же публичный путь, которым пользуется подрядчик.
Собрать всё сразу. Начинать лучше с инвентаризации, default deny и временных списков. Потом добавить портал, heartbeat, proxy и bastion по мере реальной необходимости.
Практичная первая версия
Для небольшой лаборатории хватит MikroTik, отдельного контейнера портала, PostgreSQL, Redis для живых сессий и reverse proxy. За MikroTik размещаем тестовые HTTP, SSH и RDP-ресурсы. Сначала включаем TOTP и фиксированный timeout, затем heartbeat и reference counting. Guacamole можно добавить вторым этапом.
На этом теория заканчивается. В следующем выпуске соберём лабораторный стенд: MikroTik, портал, TOTP, WebSocket, тестовые HTTP/SSH/RDP и набор проверок отказа. Потому что вся красота временного доступа проверяется не успешным входом, а тем, как он закрывается при падении половины компонентов.
Ранее в цикле
- 1. Зачем прятать то, что всё равно должно быть доступно снаружи
- 11. TOTP-портал: ввёл код — firewall открыл нужную группу
- 12. Heartbeat: firewall открыт, пока жива вкладка
- 13. Web-bastion: RDP и SSH через браузер без прямого NAT