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

Цикл «Не светим лишнего». Выпуск 14.

За предыдущие выпуски мы накопили приличный набор инструментов. Было бы странно теперь выбрать один и заставить его защищать вообще всё.

HTTP-панель, RDP подрядчика, IPMI, dev-база и доступ филиала — разные задачи. Им нужны разные точки входа, но единая логика выдачи прав.

Один контроллер, несколько точек применения

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

Решение применяется там, где это удобнее:

В терминах 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.

Плюсы комбинированной схемы

Минусы

Где можно больно ошибиться

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 и набор проверок отказа. Потому что вся красота временного доступа проверяется не успешным входом, а тем, как он закрывается при падении половины компонентов.

Ранее в цикле

Документация и источники

#network