Ответить сразу на вопрос, какие роли используют сертификаты, сможет не каждый. А реальный ответ заключается в том, что все роли используют сертификаты. Важно понимать, где нужно применять сертификаты в инфраструктуре служб удаленных рабочих столов (RDS) и зачем они используются в каждой конкретной службе роли RDS.
Большинство ролей требуется сконфигурировать, но некоторым это не нужно (например, серверу лицензирования удаленных рабочих столов). По умолчанию сертификаты SSL (x.509) нужны на каждом этапе подключения к сеансу или размещенной на хосте виртуальной машине. Они используются для следующих трех основных целей: для защиты связи между клиентом и сервером, для удостоверения сервера или веб-сайта, к которому подключается клиент и для подписи RDP-файлов, чтобы пользователи знали, что эти файлы поступили из доверенного источника и не были изменены.
Вот несколько примеров использования сертификатов RDS:
- Серверы узлов сеансов удаленных рабочих столов (RD Session Host) используют сертификаты для подтверждения своей подлинности; это называется проверкой подлинности сервера.
- Серверы узлов сеансов и сеансов виртуализации удаленных рабочих столов используют сертификаты для создания безопасной связи между клиентом и сервером с помощью протокола TLS 1.0.
- Серверы узлов сеансов удаленных рабочих столов исопользут сертификаты для проверки подлинности клиентов, необходимой для проверки подлинности на уровне сети (NLA), единого входа (SSO) и реализации единого входа в веб.
- Серверы узлов сеансов удаленных рабочих столов и посредники подключений к удаленным рабочим столам используют сертификат SSL для подписания файлов RemoteApps и VM RDP, чтобы подтвердить пользователям, что они запускают доверенный файл.
- Серверы шлюзов удаленных рабочих столов используют сертификаты для шифрования связи с клиентами по протоколу TLS 1.0.
- Можно защитить безопасный сайт веб-доступа у к удаленным рабочим столам посредством сертификата SSL, чтобы обеспечить, что пользователи работали с доверенным сайтом (HTTPS).
Для включения функциональности RDS нужны определенные технологии, обеспечивающие использование сертификатов (рис. 1).
| Securiry feature | Функции безопасности |
| Server authentication | Проверка подлинности сервера |
| Session data encryption | Шифрование данных сеанса |
| Network level authentication | Проверка подлинности на уровне сети |
| Single sign-on | Единый вход |
| RD gateway secure connections | Безопасные подключение шлюза удаленных рабочих столов |
| HTTPS secure Web site | Безопасный веб-сайт с HTTPS |
| Technology | Технологии |
| Transport level security (TLS) | Протокол TLS (Transport Level Security) |
| Credential security provider (credSSP) | Поставщик безопасности credSSP |
| Security socket layer (SSL) | Протокол SSL (Security Socket Layer) |
Рис. 1. При включении функциональности RDS используются определенные технологии безопасности Защита канала
Защита канала
TLS является стандартом IETF (Internet Engineering Task Force), основанным на SSL версии 3 и опубликованным компанией Netscape. К усовершенствованиям TLS можно отнести новые уведомления о новых сообщениях, возможность создавать цепочки сертификатов до сертификата промежуточного, а не корневого центра сертификации, а также немного отличные от SSL алгоритмы шифрования.
Хотя TLS и основан на SSL, эти два протокола несовместимы. Вместе с тем в TLS реализован алгоритм, позволяющий при необходимости переключаться в режим SSL версии 3. Для создания безопасного коммуникационного канала между клиентом и сервером средствами TLS выполняется отправка сообщения, получение ответа и переход к шифрованию (рис. 2).
| The client sends Hello plus a random number | Клиент отправляет приветствие и случайное число |
| Hello + random number | Приветствие и случайное число |
| Endpoint responds with hello and sends a random number plus its digital certificate | Конечная точка отвечает приветствием и отправляет случайное число вместе с цифровым сертификатом |
| The client creates a pre-master secret, encrypts it using the public key from the endpoint’s certificate and sends it to the endpoint | Клиент создает предварительный секрет, шифрует его, используя открытый ключ из сертификата конечной точки и отправляет конечной точке |
| Pre-master secret | Предварительный секрет |
| The endpoint decrypts the pre-master key using its certificate’s private key | Конечная точка шифрует предварительный ключ, используя имеющийся закрытый ключ |
| Master secret client and endpoint use the pre-master secret plus the random values to generate the master secret, then use the master secret to ganarate the session keys used for data encryption and decryption during the session | Клиент и конечная точка используют предварительный секрет и случайные величины для генерации основного секрета, после чего используют его для генерации ключей сеансов, используемых для шифрования и расшифровки во время сеанса |
Рис. 2. Процесс двустороннего шифрования для создания безопасного канала
Для нормальной работы этого процесса должны выполняться два требования.
- Клиент должен доверять центру сертификации, подписавшему SSL-сертификат сервера.
- В подключении клиента и сервера должно использоваться высокоуровневое (по умолчанию) или FIPS-шифрование. Низкоуровневое шифрование используется только для шифрования трафика от клиента к серверу, а не от сервера к клиенту, поэтому это безопасный способ для пересылки функций безопасности или общих секретов.
Если подключение и уровни шифрования отвечают этим требованиям, клиент и сервер устанавливают связь в следующем порядке.
- Клиент отправляет приветсвенное сообщение вместе со значением фиксированной длины. Сервер отвечает случайной величиной фиксированной длины. Во время этого обмена, клиент сообщает серверу, какие хеши и методы сжатия он поддерживает. Он также сообщает серверу версию протокола и идентификатор сеанса Идентификатор сеанса идентифицируется канал связи — это не идентификатор сеанса на сервере узлов сеансов удаленных рабочих столов
- Сервер выбирает самый надежный метод шифрования, поддерживаемый им и клиентом, а также шифр и функцию хеширования из списка, предоставленного клиентом. Затем он сообщает о своем выборе клиенту. Если серверу и клиенту не удается достичь минимального уровня безопасности, подключение терпит сбой.
- Сервер отправляет свой цифровой сертификат клиенту. Этот сертификат содержит имя сервера, имя доверенного центра сертификации, подписавшего этот сертификат и открытый ключ сервера.
- Клиент проверяет, является ли сертификат действительным и доверенным. Сертификат, используемый для подписания сертификата сервера, должен быть в хранилище сертификатов доверенных корневых центров сертификации. Далее он создает предварительный секрет, шифрует его открытым ключом сервера и отправляет на сервер.
- Сервер получает и расшифровывает предварительный секрет своим закрытым ключом. Это единственный сервер, способный выполнить эту операцию, потому что у него есть парный закрытый ключ.
- В начале процесса сервер и клиент обмениваются предварительным секретом и случайными числами. Они используют эти значения для генерации 48-байтового основного секрета (который еще называется общим секретом). После генерации основного секрета предварительный секрет удаляется.
- Клиент и сервер далее хешируют 48-байтовый основной секрет и используют его для генерации секрета MAC (ключа сеанса, используемого для хеширования) и ключа WRITE (ключа сеанса, используемого для шифрования). Эти ключи используются для шифрования и расшифровки связи в процессе сеанса. По завершении сеанса ключи удаляются.
Если на любом из этапов этой последовательности происходит сбой, подключение оказывается не полностью защищенным. Что происходит дальше, зависит от настройки параметров на вкладке Advanced клиента подключения к удаленному рабочему столу (RDC). В случае сбоя проверки подлинности пользователь может выбрать один из следующих вариантов:
- Все равно подключиться, не уведомляя клиента о проблеме с проверкой подлинности сервера.
- Предупредить клиент, но все равно разрешить подключение (настройка по умолчанию).
- Запретить подключение, если его не удается удостоверить.
Исключение делается, если серверу требуется минимальный уровень безопасности. Если это так и клиент не в состоянии удовлетворить минимальному уровню безопасности, подключение завершается. По умолчанию клиент и сервер согласуют и используют наиболее безопасные параметры подключения, которые они в состоянии поддерживать.
Кеширование учетной информации средствами CredSSP
Кеширование учетной информации появилось в Windows Vista и Windows Server 2008. Это обеспечивает две возможности — защиту сервера и клиента.
Кеширование учетных данных позволяет пользователям хранить учетные данные, чтобы не приходилось предоставлять их каждый раз при подключении к серверу (это единый вход, или SSO). Это ускоряет соединение. В противном случае подключение с посредником нужно было проверять на каждом этапе.
На стороне сервера кеширование учетных данных предоставляет эти данные серверу до создания сеанса. Это позволяет избежать дополнительных издержек сеанса, если пользователь не аутентифицирован (это проверка подлинности на уровне сети, или NLA).
За кеширование учетных данных отвечает поставщик CredSSP (Credential Security Service Provider). Он имеется в Windows 7, Windows Vista, Windows Server 2008 и Windows XP SP3. Он не связан с используемой версией RDC, потому что CredSSP является частью операционной системы. CredSSP выполняет следующие функции:
- В NLA поставщик CredSSP обеспечивает каркас для проверки подлинности пользователя на сервере узлов сеансов удаленных рабочих столов до создания подключения.
- При переподключении сеанса в ферме CredSSP ускоряет процесс передачи подключения на правильный сервер, предоставляя серверу узлов сеансов удаленных рабочих столов информацию, кто входит, и избавляет от необходимости создавать совершенно новый сеанс. В этом случае сценарий использования NLA немного отличается.
- При SSO поставщик CredSSP хранит пользовательские учетные данные и передает их серверу узлов сеансов удаленных рабочих столов, обеспечивая таким образом автоматизацию входа.
CredSSP поддерживает взаимную проверку подлинности сервера и клиента (рис. 3).
| TLS secure channel | Безопасный канал TLS |
| SPNEGO tokens are used to mutually authenticate server and client and to exchange the session key | Для взаимной проверки подлинности сервера и клиента и для обмена ключом сеанса используются токены SPNEGO |
| User name | Имя пользователя |
| Password | Пароль |
Рис. 3. Для проверки подлинности сервера и клиента требуется безопасный канал
Процесс проверки подлинности выполняется в следующей последовательности.
- Клиент инициирует безопасный канал с сервером средствами TLS. Сервер возвращает сертификат со своим именем, именем центра сертификации и открытым ключом. Идентифицируется только сервер. На этом этапе клиент остается анонимным.
- После установления сеанса и создания ключа сеанса CredSSP использует протокол SPNEGO (Simple and Protected GSS-API Negotiation) для взаимной проверки подлинности сервера и клиента. По сути этот механизм позволяет клиенту и серверу согласовать механизм проверки подлинности, который они оба поддерживают, например Kerberos или NTLM (Windows NT LAN Manager).
- По завершении взаимной проверки подлинности поставщик CredSSP на стороне клиента шифрует серверный сертификат с ключом сеанса, созданном на этапе 2, и отправляет на сервер. Сервер получает зашифрованный сертификат, расшифровывает его своим закрытым ключом и добавляет единицу к одному из самых важных битов номера сертификата. Затем результат шифруется и отправляется обратно клиенту. Последняя операция гарантирует, что никто не может перехватить обмен информацией между клиентом и сервером и ложно олицетворять сервер.
- Клиент анализирует сертификат, полученный с сервера и сравнивает его с собственным сертификатом.
- Если результаты совпадают, поставщик CredSSP на стороне клиента отправляет учетные данные на сервер.
Проверка подлинности сервера
Одна из опасностей, связанных с взаимодействием с удаленным компьютером заключается в том, что вам нужно предоставлять свои учетные данные серверу, который может быть не тем, за кого себя выдает. Если за доверенный себя выдает подложный сервер, он может получить ваши учетные данные. Это позволяет злоумышленника подключиться к вашему серверу или контроллеру домена.
RDP предусматривает шифрование, но у протокола нет никаких средств проверить подлинность сервера. Именно для этого нужны TLS и CredSSP. При проверке подлинности проверяется соответствие имени, указанного в клиенте (или файле) RDC, и имени в сертификате, указанном в средстве конфигурирования удаленных рабочих столов на сервере узла сеансов, к котором он подключен.
Подписание файлов RDP
Для цифрового подписания файлов RemoteApp и RDP, которые используются для подключения к личной виртуальной машине или виртуальной машине в пуле. Подписание этих файлов гарантирует пользователю, что они созданы доверенным источником. Это также позволяет защитить RDP от изменения.
Подписание файлов RemoteApp также необходимо для реализации единого входа в веб. Это позволяет пользователям входить на сервер веб-доступа к удаленным рабочим столам только один раз. После этого они могут запускать RemoteApps из любой фермы, не предоставляя лишний раз свои учетные данные.
CredSSP не может передавать учетные данные серверу веб-доступа к удаленным рабочим столам. Чтобы сохранить свои учетные данные, пользователь должен предварительно войти на этот веб-сайт. После этого пользователям при запуске программ RemoteApp не потребуется повторно проходить проверку подлинности. Чтобы это работало, приложение RemoteApp должно быть подписано, а пользователь должен доверять сертификату, применяемому для подписания RemoteApp.
Файлы RDP, создаваемые, когда пользователь запускает подключение RDP на вкладке RD Web Access Desktops, создаются на лету. Файлы не подписываются. Поэтому при подключении к рабочим столам единый веб-вход не будет работать. Пользователю придется войти на конечную точку в момент установления подключения. Единый веб-вход также не будет работать в подключениях к персональным виртуальным машинам или виртуальным машинам в пуле.
Защита подключений
Шлюз удаленных рабочих столов использует протокол TLS 1.0 для защиты связи между шлюзом и удаленными столами, которые обычно расположены за пределами локальной сети (подключение через Интернет). Как говорилось ранее для работы TLS нужен сертификат SSL. Для защиты связи между клиентами и сервером веб-доступа к удаленным рабочим столам можно использовать цифровые сертификаты для шифрования сеансов связи с веб-сайтами (HTTPS).
Сертификаты являются важной частью инфраструктуры RDS. В RDS сертификаты используются для защиты подключений и других поддерживаемый функций.
