Как организовать безопасный RDP‑доступ для внешних подрядчиков

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

Почему публикация RDP требует особого подхода

RDP (Remote Desktop Protocol) — один из самых распространенных способов удаленного администрирования Windows-серверов и рабочих станций. Он удобен: подрядчик может подключиться к нужному компьютеру и выполнять задачи так, словно находится в офисе. Именно поэтому RDP часто используют для сопровождения инфраструктуры, настройки оборудования, обновления программ и технической поддержки.

Но если просто открыть RDP «наружу», удобство быстро превращается в риск. Порт постоянно сканируют автоматизированные боты: они ищут доступные серверы и сразу начинают подбирать пароли или проверять известные уязвимости. Если злоумышленнику удается получить доступ хотя бы к одной учетной записи, он получает ее права и может попытаться закрепиться на сервере или развить атаку на другие доступные системы.

Возможные сценарии выглядят так:

• подбор слабых или повторно используемых паролей (так называемые brute force и password spraying);
• использование учетных данных, ранее утекших из других сервисов;
• эксплуатация уязвимостей в службах удаленного рабочего стола или связанных компонентах;
• атаки на неправильно настроенное подключение, когда отсутствуют дополнительные механизмы защиты и проверки пользователя.

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

Поэтому безопасный доступ к RDP — это не одна настройка и не смена стандартного порта. Защита строится сразу на нескольких уровнях: необходимо безопасно организовать само подключение, надежно подтвердить личность пользователя, ограничить его права, фиксировать значимые события и при необходимости контролировать действия во время сессии. Именно такой подход сегодня считается базовой практикой при организации удаленного доступа для подрядчиков.

Как выбрать безопасную схему удаленного доступа

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

Какие варианты используют компании

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

RD Gateway выступает посредником между внешним пользователем и внутренними Windows-серверами. Подрядчик подключается к шлюзу, проходит проверку, а шлюз перенаправляет RDP-сессию к разрешенному ресурсу. К такой схеме можно добавить многофакторную аутентификацию, чтобы украденного пароля было недостаточно для входа.

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

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

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

VDI позволяет предоставить подрядчику изолированный виртуальный рабочий стол в контролируемой среде компании. Однако для сохранения безопасности необходимо обязательно ограничить перенаправление локальных дисков, буфера обмена, принтеров и USB-устройств. Без этих настроек данные могут быть скопированы на устройство подрядчика. Также стоит учитывать, что VDI требует значительных вычислительных ресурсов и затрат на лицензии. 

Реклама 16+

Коннект от Контур.Эгиды

Организуйте безопасный и удобный доступ к рабочим ресурсам компании из любой точки мира.

Оставить заявку

Как выбрать решение для конкретного подрядчика

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

Для разовой настройки обычного Windows-сервера может быть достаточно RD Gateway или VPN с двухфакторной аутентификацией, отдельной учетной записью и ограниченным сроком действия. Например, если подрядчик должен вечером обновить бухгалтерскую систему, ему не нужен постоянный доступ ко всей сети: достаточно открыть конкретный сервер на согласованное время и отключить учетную запись после завершения работ.

Если внешний специалист регулярно администрирует критичную инфраструктуру, одной защиты канала уже недостаточно. Здесь нужны минимальные привилегии, временная выдача административных прав и запись действий — то есть элементы Zero Trust и PAM.

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

Как безопасно настроить RDP-доступ

Настройте защищенную точку входа

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

Чаще всего для этого применяют RD Gateway или корпоративный VPN. Первый публикует только сам шлюз, а не RDP-службу каждого сервера. Второй создает защищенный туннель между устройством пользователя и корпоративной сетью, после чего пользователь подключается к нужному ресурсу по внутреннему адресу.

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

Настройте безопасную аутентификацию и права доступа

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

Минимальный набор выглядит так:

• включить двухфакторную аутентификацию (MFA);
• использовать индивидуальные, а не общие учетные записи;
• выдавать подрядчикам только минимально необходимые права (принцип Least Privilege);
• создавать временные учетные записи или автоматически отключать доступ после завершения работ.

Например, подрядчику, который обновляет SQL Server, обычно не требуется доступ к файловому серверу, контроллеру домена или рабочим станциям сотрудников.Чем меньше ресурсов будет доступно после аутентификации, тем меньше потенциальный ущерб в случае компрометации учетной записи.

Усильте защиту RDP-соединения

После того как доступ организован, стоит защитить и саму RDP-сессию. В первую очередь рекомендуется:

• включить Network Level Authentication (NLA), чтобы пользователь проходил проверку еще до создания полноценной RDP-сессии;
• использовать TLS 1.2 или более новую поддерживаемую версию для шифрования соединения;
• настроить блокировку после нескольких неудачных попыток входа;
• на межсетевом экране, VPN-шлюзе или RD Gateway ограничить источники подключений по IP-адресам, а при необходимости — по географии, если подрядчики работают только из определенных стран;
• отключить ненужное перенаправление локальных дисков, буфера обмена, принтеров и других устройств, если подрядчику эти функции не требуются.

Если доступ организован через RD Gateway или другую внешнюю точку входа, важно использовать действующий TLS-сертификат от доверенного центра сертификации. Это помогает убедиться, что пользователь подключается именно к корпоративному серверу, а не к подмененному узлу злоумышленника.

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

Как контролировать действия внешних подрядчиков

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

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

Например, подрядчик должен был установить обновление ночью с 22:00 до 23:00. Если на следующий день выясняется, что в 03:40 он продолжал работать на сервере или пытался получить доступ к другому ресурсу, такие события должны фиксироваться в журналах, а при настроенном мониторинге — вызывать уведомление. Без этого компания узнает о проблеме только после появления последствий.

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

Хорошей практикой считается настройка автоматических уведомлений о событиях, которые редко происходят при штатной работе. Например:

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

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

Как управлять доступом подрядчика на протяжении всего жизненного цикла

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

Этот процесс может выглядеть так:

1. Руководитель согласовывает необходимость доступа и перечень ресурсов.
2. Подрядчику создают отдельную персональную учетную запись — без использования общих логинов.
3. Выдают только минимально необходимые права для выполнения конкретной задачи.
4. Ограничивают срок действия доступа или заранее устанавливают дату его автоматического отключения.
5. После завершения работ учетную запись отключают или удаляют, а выданные права отзывают.

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

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

• какие подрядчики еще имеют доступ;
• действительно ли он им нужен;
• не осталось ли старых учетных записей после завершенных проектов;
• соответствуют ли текущие права выполняемым задачам.

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

Информационная безопасность бизнеса

Контур.Эгида — сервисы информационной безопасности: уменьшение рисков внутренних угроз и утечек конфиденциальных данных, предотвращение атак злоумышленников.

Оставить заявку

Чек-лист безопасной публикации RDP

Даже небольшие ошибки при настройке RDP могут свести на нет все остальные меры защиты. Перед тем как предоставить подрядчику удаленный доступ, полезно пройтись по короткому чек-листу.

• RDP не опубликован напрямую в интернет, а работает через VPN или RD Gateway.
• Для входа через VPN, RD Gateway или Windows настроена многофакторная аутентификация.
• У каждого подрядчика есть собственная учетная запись — без общих логинов и паролей.
• Выданы только необходимые права доступа к конкретным серверам и приложениям.
• Настроены ограничения по времени действия доступа или его автоматический отзыв после завершения работ.
• Включены Network Level Authentication (NLA) и современные версии TLS.
• Ведется журнал подключений и действий пользователей.
• Настроены уведомления о подозрительной активности и неудачных попытках входа.
• Установлены актуальные обновления Windows Server и компонентов RDP.
• Отключено ненужное перенаправление локальных дисков, буфера обмена, принтеров и других устройств.

Возможные ошибки

Нередко компании допускают одни и те же просчеты: открывают RDP-порт для подключений из интернета, используют общую учетную запись для нескольких подрядчиков, не включают MFA, забывают отключить доступ после окончания проекта или вообще не контролируют действия пользователей во время RDP-сеансов. Именно такие ошибки могут стать причиной успешных атак на удаленный доступ.