Служба Remote Desktop Services (RDS) в Windows Server 2008 R2 это не просто ребрендинг своего предшественника – службы Terminal Services. Новые функции, часть из которых появилась еще в Windows Server 2008, такие как RemoteApp, RD Gateway и RD Virtualization Host, позволяют просто и удобно обеспечить развертывание и функционирование как отдельных пользовательских приложений, так и целые рабочих столов в RDS и VDI решениях, причем функционал и удобство нисколько не хуже, чем у решений Citrix или комплексов других вендоров.
А как же обстоят дела с безопасностью службы Remote Desktop Services? Microsoft существенно обновила и усилила безопасность данной службы. В данной статье мы поговорим о механизмах безопасности RDS, об обеспечении безопасности терминальных служб средствами групповых политик и о практических аспектах обеспечения безопасности решений RDS.
Что нового в R2
Если вам приходилось работать с версиями служб терминалов в Windows Server 2003 и Windows Server 2008, то вы, вероятно, помните, что в Windows 2008 появился ряд новых возможностей, таких как TS Web Access (подключение через браузер), TS Gateway (доступ к терминальным службам через Интернет), RemoteApp (публикация отдельных приложений по протоколу RDP) и служба Session Broker (обеспечение балансировки нагрузки).
В Windows Server 2008 R2 появился следующие функции:
- Remote Desktop Virtualization для решений VDI
- Провайдер RDS для PowerShell (теперь администратор может управлять конфигурацией и управлением RDS из командной строки или с помощью скриптов)
- Remote Desktop IP Virtualization, позволяющей назначать подключениям IP адреса, основываясь на параметрах сессии или запускаемого приложения
- Новая версия протокола RDP и клиента Remote Desktop Connection (RDC) — v. 7.0
- Управление ресурсами CPU для динамического выделения процессорных ресурсов на основе количества активных сессий
- Совместимость с Windows Installer, позволяющая устанавливать программы с возможностью донастройки параметров приложения на стороне пользователя.
- Поддержка на стороне клиента до 16 мониторов.
Кроме того, были доработаны функции работы с видео и аудио, и полноценная поддержка технологии Windows Aero (отметим, что Aero не поддерживается при мультимониторном режиме работы).
Естественно, вопросы безопасности службы RDS зависят от конкретного решения. Например, если публиковать рабочий стол для пользователей, подключающихся через Интернет или с помощью браузера, то вопрос безопасности встает намного более остро, чем при стандартном решении, когда клиенты подключаются с помощью клиента RDC по локальной сети LAN.
Network Level Authentication
Для обеспечения большей безопасности для всех подключений необходимо задействовать механизм аутентификации Network Level Authentication (NLA). NLA требует от пользователя авторизоваться на сервере RD Session Host еще до того, как сессия создана. Этот механизм позволяет защитить сервер от обработки лишних сессий, которые могут генерироваться злоумышленниками или программами-ботами. Для того, чтобы воспользоваться NLA, клиентская операционная система должна поддерживать протокол Credential Security Support Provider (CredSSP), что подразумевает ОС Windows XP SP3 (как включить NLA в Windows XP SP3) и выше, а также клиента RDP 6.0 или выше.
Настроить NLA можно на сервере RD Session, открыв консоль Administrative Tools -> Remote Desktop Services -> Desktop Session Host Configuration.
- Щелкните правой кнопкой мыши по подключению
- Выберите Properties
- Перейдите на вкладку General
- Отметьте опцию “Allow connections only from computers running Remote Desktop with Network Level Authentication”
- Нажмите OK.
Transport Layer Security (TLS)
В сессии RDS можно задействовать один из трех механизмов безопасности, позволяющих защитить соединение между клиентов и сервером RDS Session Host:
- RDP security layer – используется встроенное шифрование протокола RDP, является менее безопасным.
- Negotiate – шифрование TLS 1.0 (SSL) будет использоваться в случае поддержки клиентом, если клиент его не поддерживает, будет использоваться обычный уровень безопасности RDP.
- SSL – шифрование TLS 1.будет использоваться для аутентификации сервера и шифрования передаваемых данных между клиентом и сервером. Это наиболее безопасный режим.
Для обеспечения высокого уровня безопасности необходимо использовать шифрование SSL/TLS. Для этих целей необходимо иметь цифровой сертификат, он может быть самоподписанным либо выданным центром сертификации CA (что предпочтительнее).
В дополнении к уровню безопасности можно выбрать уровень шифрования соединения. Доступны следующие виды шифрования:
- Low – используется 56 битное шифрование данных, отправляемых с клиента на сервер. Данные, передаваемые с сервера на клиент не шифруются.
- Client Compatible – данный вид шифрования используется по умолчанию. В этом случае шифруется весь трафик между клиентом и сервером с максимальной длиной ключа, которую поддерживает клиент.
- High – все данные передаваемые между клиентом и сервером в обе стороны шифруются 128 битным ключом
- FIPS Compliant – все данные передаваемые между клиентом и сервером в обе стороны шифруются методом FIPS 140-1.
Стоит отметить, что если используются уровни шифрования High или FIPS Compliant, то все клиенты, не поддерживающие данный вид шифрования, не смогут подключиться к серверу.
Настроить тип аутентификации сервера и уровень шифрования можно следующим образом:
- На сервере RD Session Host, откройте окно конфигурации Remote Desktop Session Host и перейдите в окно свойств.
- На вкладке General, в выпадающих меню выберите необходимый уровень безопасности и тип шифрования.
- Нажмите OK.
Групповые политики
Для настройки параметров RDS в Windows Server 2008 R2 есть ряд опций групповой политики. Все они расположены в разделе Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services (скриншот консоли Group Policy Management Console отображен на картинке).
Как вы видите здесь есть политики управления лицензированием, политики настройки клиента RDC и самого сервера RD Session Host. К политикам безопасности RD Session Host относятся:
- Set Client Connection Encryption Level: политика используется для управления уровнем шифрования. Если ее активировать, все соединения должны использовать указанный уровень шифрования (по умолчанию – High).
- Always Prompt for Password upon Connection: данная политика используется, если необходимо всегда спрашивать пароль пользователя при подключении к сессии RD, даже если пароль был введен в клиенте RDC. По умолчанию, пользователи могут автоматически входить в сессию, если они указали пароль в клиенте RDC.
- Require Secure RPC Communication: — при включенной политики разрешены только аутентифицированные и шифрованные запросы от клиентов.
- Require Use of Specific Security Layer for Remote (RDP) Connections: при включенной политике, все соединения между клиентом и сервером терминалов должны использовать уровень безопасности, указанный здесь (RDP, Negotiate или SSL/TLS)
- Do Not Allow Local Administrators to Customize Permissions: политика отключает возможность администраторам настраивать параметры безопасности RD Session Host.
- Require User Authentication for Remote Connections by using Network Level Authentication: Политика включает требование NLA для всех соединения с терминальным сервером (клиенты без поддержки NLA подключиться не смогут).
Параметры настройки клиента RDC находятся в подразделе Remote Desktop Connection Client:
- Do not allow passwords to be saved: политика запрещает сохранять пароли в клиенте RDC, опция «Сохранить пароль» становится недоступна, все ранее сохраненные пароли будут удалены.
- Specify SHA1 thumbprints of certificates representing trusted .rdp publishers: эта политика позволяет создать список отпечатков SHA1 сертификатов, и если сертификат соответствует отпечатку в это списке, он считается доверенным.
- Prompt for credentials on the client computer: политика активирует запрос учетных данных пользователя на клиентском компьютере, а не сервере RD Session.
RD Web Access
Пользователи компьютеров, на которых не установлен клиент RDC, могут получать доступ к опубликованным приложениям с помощью веб-браузера. Для этого пользователь должен в браузере открыть URL, на котором опубликованы ресурсы RDS. Сервер RD Web Access – это отдельная роль сервера RD, обычно он располагается на выделенном сервере.
Веб интерфейс сервера RD Web Access основан на использовании SSL и пользователи могут авторизоваться на нем с помощью своих учетных данных. Аутентифицированные пользователи видят лишь список тех опубликованных программ (RemoteApp), к которым у них есть доступ.
Сервер Web Access для шифрования использует сертификат X.509. По умолчанию используется самоподписанный сертификат.
