Перейти к основному контенту

Подписывание RDP-файлов в JumpServer EE (RDP Signing)

Зачем это нужно

Если компания раздаёт пользователям .rdp-файлы для подключения, встаёт вопрос: можно ли гарантировать, что критичные параметры подключения (адрес цели, поведение шлюза, редиректы) не были подменены до запуска файла.

JumpServer EE решает это с помощью подписывания ключевых RDP-параметров при генерации файла подключения — опция RDP_SIGN_ENABLED=1.

Актуальность в 2026: Microsoft относит CVE-2026-26151 к уязвимостям класса RDP spoofing (недостаточное предупреждение пользователя об опасных действиях). Начиная с апрельского обновления безопасности 2026 года Microsoft изменила логику предупреждений при открытии RDP-файлов: открытие непроверенных .rdp-файлов может раскрыть локальные ресурсы, если пользователь разрешит опасные опции редиректа. Подробнее — в документации Microsoft.

Вывод: подписывание RDP-файлов стоит считать не опциональным усилением, а базовым требованием безопасности удалённого доступа.

изображение.png

Что даёт подпись

  • Неподписанные файлы могут отображаться в Windows как файл от неизвестного издателя.
  • Подписанные файлы показывают проверяемого издателя.
  • Подпись повышает подлинность и целостность файла, но не гарантирует, что сама цель подключения безопасна — дисциплина проверки со стороны пользователей и мониторинг со стороны security-команды по-прежнему нужны.

Как создать сертификат и ключ для подписи RDP файлов?

Выпустить через вашу AD CS (Enterprise CA)

Это удобнее всего, если в домене уже поднята Certificate Authority (или её можно развернуть на DC/отдельном сервере): корневой сертификат такой CA уже доверен всем доменным машинам через GPO, поэтому пользователям не нужно будет вручную ничего доверять — подпись сразу покажется как "проверяемый издатель".

Оба нужных JumpServer файла (.crt и .key) — это просто разные части одного и того же сертификата, который вы выпустите и экспортируете. Порядок действий:

  1. Создать шаблон сертификата с нужным назначением. Стандартный "Code Signing" не годится напрямую — Windows требует у подписи RDP-файла EKU Document Signing (OID 1.3.6.1.4.1.311.10.3.12), которого в базовом шаблоне нет. На сервере CA откройте certtmpl.msc, продублируйте существующий шаблон (например, "Code Signing"), на вкладке Extensions → Application Policies добавьте "Document Signing" (если такого пункта нет в списке — добавьте вручную по OID). На вкладке Request Handling включите "Allow private key to be exported" — иначе не сможете забрать ключ.
  2. Опубликовать шаблон на CA. В certsrv.msc → Certificate Templates → New → Certificate Template to Issue → выбрать созданный шаблон.
  3. Запросить сертификат. На любой доменной машине откройте MMC → snap-in "Certificates" (Local Computer) → Personal → All Tasks → Request New Certificate → выбрать новый шаблон.
  4. Экспортировать с приватным ключом. В той же MMC: правой кнопкой по выпущенному сертификату → All Tasks → Export → выбрать "Yes, export the private key" → сохранить как .pfx с паролем.
  5. Сконвертировать PFX в два PEM-файла, которые и требует JumpServer (нужен OpenSSL — можно на любой Linux-машине или в WSL):

   openssl pkcs12 -in signer.pfx -clcerts -nokeys -out rdp_signer.crt
   openssl pkcs12 -in signer.pfx -nocerts -nodes -out rdp_signer.key

На выходе получаете ровно те два файла, что нужны для RDP_SIGN_CERT и RDP_SIGN_CERT_KEY — останется положить их в /opt/jumpserver/data/certs внутри контейнера jms_core.

  1. Проверить доверие. Поскольку сертификат выпущен вашей же AD CS, её корень почти наверняка уже в "Trusted Root CA" на доменных клиентах — дополнительно ничего разносить не нужно.

Если нет CA, можно использовать и само-подписанные сертификаты, но тогда нужно будет на всех машиных пользователей добавить этот сертификат в доверенные.

Быстрый старт: 4 шага

Шаг 1. Подготовить сертификат и ключ

Файлы в формате PEM, разместить на хосте:

/opt/jumpserver/config/certs/rdp_signer.crt
/opt/jumpserver/config/certs/rdp_signer.key

Имена файлов можно менять, если синхронизировать их с переменными окружения ниже.

Шаг 2. Настроить переменные окружения

RDP_SIGN_ENABLED=1
RDP_SIGN_CERT=/opt/jumpserver/data/certs/rdp_signer.crt
RDP_SIGN_CERT_KEY=/opt/jumpserver/data/certs/rdp_signer.key

Важно: сертификат подгружается внутри контейнера, поэтому пути в конфиге отличаются от путей на хосте (шаг 1). Убедитесь, что сертификат и ключ реально присутствуют в каталоге /opt/jumpserver/data/certs внутри контейнера jms_core.

Шаг 3. Перезапустить сервисы

jmsctl restart

Шаг 4. Проверить на реальном сценарии

  1. Через клиентское подключение сгенерировать и скачать .rdp-файл.
  2. Открыть его текстовым редактором — должны присутствовать строки:
    • signscope:s:...
    • signature:s:...
    Если строк нет — файл не подписан.
  3. На пропатченном Windows-клиенте открыть подписанный файл и убедиться, что диалог безопасности Remote Desktop показывает проверяемого издателя, а пользователь разрешает только необходимые редиректы.

Соответствие рекомендациям Microsoft и контролей JumpServer

Риск Контроль в JumpServer
Пользователь открывает неожиданный/фишинговый .rdp-файл Раздавать только файлы, сгенерированные JumpServer, с включённой подписью
Издателя файла нельзя проверить Включить RDP_SIGN_ENABLED=1 и поддерживать жизненный цикл сертификата подписи
Слишком широкий редирект локальных ресурсов Минимизировать редиректы, разрешать только нужные для бизнеса опции, обучать пользователей
Деградация безопасности из-за проблем с сертификатом/ключом остаётся незамеченной Настроить алерты на ошибки подписи; трактовать fallback без подписи как security-событие

Что важно знать об эксплуатации

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

Чек-лист диагностики проблем

  1. RDP_SIGN_ENABLED=1 присутствует в runtime-конфиге.
  2. Каталог с сертификатами корректно смонтирован в контейнер jms_core.
  3. Имена файлов cert/key совпадают с RDP_SIGN_CERT и RDP_SIGN_CERT_KEY.
  4. Оба файла — валидный PEM.
  5. Сценарий подключения действительно генерирует .rdp-файл.
  6. В файле присутствуют signscope:s: и signature:s:.

Рекомендации по безопасности

  1. Ограничить права доступа к приватному ключу на уровне файловой системы.
  2. Периодически ротировать сертификат/ключ подписи.
  3. Настроить алерты на повторяющиеся сбои подписи в логах.
  4. Сочетать RDP signing с принципом наименьших привилегий, hardening эндпоинтов и контролем на шлюзе.
  5. Держать Windows-клиенты полностью пропатченными для актуальной логики предупреждений об RDP-файлах.
  6. Обучать пользователей отклонять неожиданные .rdp-файлы и проверять издателя и цель подключения перед подключением.

Пример политики для security-команды

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

Итог

RDP_SIGN_ENABLED=1 — небольшое изменение конфигурации с существенным эффектом для безопасности. Для организаций, использующих нативные RDP-клиенты, включение подписи усиливает доверие к файлам подключения и помогает соответствовать требованиям безопасности удалённого доступа. Рекомендуется включить эту опцию при hardening продуктивной bastion-инфраструктуры.

 

Наверх