Менеджер удалённых подключений

У любой ИТ-команды со временем накапливается карта подключений: RDP к серверу 1С, SSH на VPS сайта, VNC к старому терминалу, VPN в офис, веб-панель NAS, консоль гипервизора, доступ к роутеру на объекте. Если этой карты нет в одном месте, она живёт в головах, заметках, истории терминала, файлах .rdp на рабочем столе и переписке с подрядчиком.

Менеджер удалённых подключений нужен не для того, чтобы «красиво разложить ярлыки». Он превращает хаотичный набор адресов в каталог: какие системы есть, кто владелец, как подключаться, какие учётки разрешены, где лежит пароль, нужен ли VPN, что делать после завершения работ. Для малого бизнеса это особенно полезно, когда ИТ-сопровождение ведёт подрядчик или небольшая внутренняя команда.

Что обычно идёт не так

Первый типичный сценарий — один инженер знает все адреса. Пока он доступен, всё работает. Ушёл в отпуск, сменил работу или перестал отвечать — новый человек начинает собирать инфраструктуру по кускам. Где сервер 1С? На каком порту SSH? Почему к роутеру нужно заходить только из VPN? Где RDP-файл для кассового сервера?

Второй сценарий — общий архив подключений без безопасности. В папке лежат .rdp, .ppk, сохранённые пароли, текстовые файлы с комментариями. Это удобно, но при утечке такого архива злоумышленник получает почти готовую карту инфраструктуры.

Третий — отсутствие дисциплины. Подрядчик подключается под общей учёткой, после работ доступ не отключается, старые сессии никто не чистит, временный проброс RDP наружу остаётся постоянным. Потом это всплывает при инциденте или смене подрядчика.

Что должен хранить каталог

Хороший каталог подключений содержит не только адрес. Для каждой системы полезны поля: название, назначение, площадка, тип подключения, внутренний и внешний адрес, требуется ли VPN, владелец, критичность, связанный сервис, ссылка на инструкцию, дата последней проверки.

Пароли лучше не хранить прямо в описании сессии, если инструмент не умеет безопасное хранилище и разграничение прав. Оптимально связать менеджер подключений с корпоративным сейфом секретов или использовать решение, где хранилище зашифровано, есть роли, MFA и журнал доступа. Подробнее о логике секретов — в статье корпоративный менеджер паролей.

Для SSH-ключей нужен отдельный порядок: где лежит приватный ключ, есть ли passphrase, кто имеет доступ, как отозвать ключ при уходе сотрудника. Ключ без пароля в общей папке — почти то же самое, что пароль в открытом виде.

Безопасность самого менеджера

Менеджер подключений становится ценным объектом. Если в нём есть карта сети, адреса серверов и сохранённые учётные данные, его нужно защищать не хуже хостинга или VPN. У каждого пользователя должен быть свой вход, MFA, роли и минимум прав. Подрядчик видит только свои объекты, стажёр не видит продакшен, руководитель может посмотреть каталог, но не обязан иметь доступ ко всем паролям.

Если используется локальная база менеджера, нужен бэкап и понятный владелец. Если облачное решение — проверьте условия хранения, экспорт, MFA, журнал действий и возможность отключить пользователя. В любом случае нельзя оставлять единственную копию базы на ноутбуке одного администратора.

Отдельно проверьте автозаполнение паролей. Оно удобно, но может скрыть проблему общих учёток. Если все входят на сервер под одним administrator, журнал Windows покажет не людей, а один технический логин. Лучше использовать индивидуальные учётки, а менеджер подключений — как каталог и удобный старт сессии, не как способ спрятать отсутствие контроля.

RDP, SSH, VNC: разные риски

RDP к Windows-серверам должен быть доступен через VPN или шлюз, а не напрямую из интернета. Открытый наружу RDP быстро находят сканеры, об этом подробно написали в статье RDP в интернет: почему нельзя. В каталоге сессии стоит явно указывать: «только через VPN», «доступ с IP подрядчика», «MFA обязательна».

SSH тоже требует порядка. Запрет паролей там, где можно использовать ключи, ограничение пользователей, обновления, журналирование, отдельные ключи для подрядчиков. Старые ключи нужно удалять при смене людей. Если SSH ведёт на сервер сайта или почты, доступ должен быть описан и связан с владельцем сервиса.

VNC и веб-панели часто забывают. Они могут висеть на нестандартных портах, быть доступны только из локальной сети или, хуже, опубликованы наружу. Каталог помогает хотя бы увидеть, что такие подключения существуют, и проверить, нужны ли они вообще.

Дисциплина доступа

Менеджер подключений полезен, когда вокруг него есть правила. Новую сессию добавляем в каталог, а не храним у себя. Временный доступ помечаем сроком. После завершения проекта отключаем учётку подрядчика. Раз в месяц или квартал просматриваем старые подключения: что удалить, что проверить, где сменился адрес.

При смене подрядчика каталог экономит много времени. Новый исполнитель видит карту, но не получает автоматически все секреты. Компания может выдать доступ постепенно, под задачи. Это снижает риск и ускоряет онбординг. Похожий подход мы описывали в материале про IT-аудит перед сменой подрядчика.

Для сети объектов полезно группировать подключения по площадкам: клуб на севере, термы, склад, офис, облако. Тогда при аварии на одной площадке не нужно искать по всему архиву, где её роутер и сервер.

Когда хватит простого списка

Если у вас один VPS и один сервер, можно начать с защищённой документации и менеджера паролей. Полноценный RDM-инструмент нужен, когда подключений много, есть несколько инженеров, подрядчики, разные протоколы и регулярная удалённая поддержка. Главное — не перепутать инструмент с порядком. Можно купить хороший менеджер и всё равно хранить пароли в чате.

Нормальный первый шаг — инвентаризация удалённых подключений: RDP, SSH, VPN, VNC, панели, облака. Затем закрыть прямые публикации, связать сессии с секретами, включить MFA и назначить владельцев.

Если хотите собрать каталог подключений и привести удалённый доступ в порядок, напишите нам через контакты. Поможем описать контур, убрать опасные публикации и встроить дисциплину доступов в администрирование серверов или регулярное ИТ-сопровождение.