Зачем прятать то, что всё равно должно быть доступно снаружи
Цикл «Не светим лишнего». Выпуск 1.
Если у вас есть хоть какая-то корпоративная инфраструктура, то довольно быстро появляется список ресурсов, которые вроде бы внутренние, но иногда нужны снаружи. Причём «иногда» постепенно превращается в «каждый день, но разным людям и по разным причинам».
Самый очевидный пример — корпоративные веб-системы: мониторинг, helpdesk, Wiki, Git, панели виртуализации, внутренние отчёты. Дальше идут SSH и RDP, WinBox, интерфейсы камер, контроллеры Wi-Fi, IPMI, iDRAC и iLO. Разработчикам нужны dev- и test-контуры, registry, CI/CD и временные стенды. Подрядчику надо на два часа попасть к конкретной камере или серверу. Дежурному инженеру — ночью зайти с домашнего Интернета и починить аварию. С удалённой площадки требуется доступ к одной служебной системе, но тащить ради неё всю сеть в туннель не хочется.
Есть и менее очевидные точки входа. Например, технологический Wi-Fi на объекте: обычный сотрудник получает только Интернет и почту, а инженер после дополнительной авторизации — доступ к оборудованию. Или временный демонстрационный контур, который должен открываться заказчику на время показа и снова исчезать. Или админская панель нового проекта, которую разработчики выставили «на недельку», а нашли через полгода.
Три разные двери
Тут полезно разделить три вещи, которые в разговоре часто смешивают.
Первая дверь — сетевая достижимость. Есть ли вообще маршрут до ресурса, опубликован ли он через NAT или reverse proxy, отвечает ли его адрес из Интернета. Если порт закрыт молча, сканер видит одно. Если отвечает SSH-баннер, веб-сервер или страница входа — уже совсем другое.
Вторая дверь — решение firewall. Даже если маршрут и DNAT существуют, firewall может пропускать соединение только с определённых адресов, в определённое время или после специального действия. На этом уровне обычно видны IP, протокол, порт и состояние соединения. Имя пользователя firewall чаще всего не знает.
Третья дверь — авторизация самого ресурса. Логин в Grafana, SSH-ключ, пароль Windows, сертификат, TOTP, роль в корпоративной системе. Именно здесь приложение понимает, кто пришёл и что ему разрешено делать внутри.
Эти двери не заменяют друг друга. Если ресурс имеет отличный пароль, это ещё не повод круглосуточно показывать всему Интернету его версию, баннер, TLS-стек и форму входа. И наоборот: если доступ ограничен по IP, нельзя считать, что конкретный пользователь уже опознан. За одним разрешённым NAT может сидеть целый офис.
Почему не оставить только VPN
VPN — нормальная и привычная технология. Когда человеку действительно нужна приватная L3-связность с несколькими сетями и произвольными протоколами, он часто остаётся лучшим выбором.
Но VPN не всегда удобен как единственный ответ. На машине уже может работать другой корпоративный или личный VPN. Могут пересекаться адресные пространства, меняться DNS и default route, включаться kill switch. Для разового подрядчика приходится заводить профиль, выдавать инструкцию, потом не забыть всё отозвать. А иногда ради одной веб-панели пользователь получает возможность ходить в целую подсеть.
Поэтому дальше мы будем смотреть не на «замену VPN», а на набор инструментов. Где-то достаточно статического allow-list. Где-то лучше выдать временную запись на час. Где-то пригодится port knocking. Для веб-систем логичен авторизующий reverse proxy. Для RDP и SSH — web-bastion. А если хочется открывать firewall только при живой браузерной сессии, можно сделать TOTP-портал с heartbeat.
Что мы хотим получить в итоге
Нормальная схема должна отвечать на несколько простых вопросов:
- какой именно ресурс или группа ресурсов открывается;
- кому и на каком основании;
- с какого адреса или устройства;
- на какой срок;
- что произойдёт, если пользователь закроет сессию;
- оборвутся ли уже установленные соединения;
- кто потом сможет разобраться по журналам, что происходило.
И главное — доступ должен быть минимальным. Подрядчику по камерам не нужна сеть гипервизоров. Разработчику тестового проекта не нужен IPMI. Дежурному админу может понадобиться много, но только после сильной авторизации и на ограниченное время.
С чего начнём
В следующих выпусках пойдём от простого к сложному. Сначала обычный firewall и VPN, затем статические и временные списки, port knocking и SPA. Дальше — captive portal, reverse proxy, TOTP и наша любимая идея с живым WebSocket heartbeat. В финале соберём всё в одну комбинированную архитектуру и прикинем лабораторный стенд на MikroTik.
Смысл цикла не в том, чтобы объявить один метод правильным. Задача проще: перестать светить наружу всё подряд и научиться выдавать ровно тот доступ, который нужен человеку сейчас.