Об удалённом доступе к RDP-серверу

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

С учётом данного требования описанная проблема может сводиться к переносу рабочего места удалённого сотрудника в сеть организации. В таком случае задача формулируется следующим образом: обеспечить доступ пользователю к внутреннему RDP-серверу через публичную сеть.

Как это часто бывает, вместо формулировки преследуемых целей организация предложила нам реализовать её собственное видение решения поставленной задачи. Заключалось оно в использовании шлюза на границе сети, который с помощью встроенного HTTPS-сервера обеспечивал взаимодействие пользователя с приложением по следующей схеме:

Стоит отметить, что реализуемый шлюзом функционал «посредника»‎ заключает в себе основную сложность данного решения – устройство одновременно выполняет две роли: а) роль HTTPS-сервера для пользователя, при этом преобразовывая получаемые в HTTP-запросах пользователя данные в данные RDP, и б) роль клиента для RDP-сервера, при этом преобразовывая получаемые от сервера данные в HTML-страницу.

В результате при возрастании числа удалённых пользователей до нескольких десятков такой подход может привести к снижению производительности устройства, что заметно скажется на времени отклика.

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

В данном случае VPN-концентратор для аутентификации удалённого клиента и организации защищённого взаимодействия пользователя с приложением терминирует IPsec-туннель, позволяя клиенту самостоятельно инициировать подключение к RDP-серверу без использования VPN-концентратора в качестве посредника на уровне приложения. За счёт меньшего числа манипуляций, осуществляемых устройством для обеспечения удалённого доступа пользователя к приложению, описанный подход является более стабильным и надёжным при эксплуатации.

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