Подписывание 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-файлов стоит считать не опциональным усилением, а базовым требованием безопасности удалённого доступа.

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

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

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

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

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

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

Создать шаблон сертификата с нужным назначением. Стандартный "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" — иначе не сможете забрать ключ.
Опубликовать шаблон на CA. В certsrv.msc → Certificate Templates → New → Certificate Template to Issue → выбрать созданный шаблон.
Запросить сертификат. На любой доменной машине откройте MMC → snap-in "Certificates" (Local Computer) → Personal → All Tasks → Request New Certificate → выбрать новый шаблон.
Экспортировать с приватным ключом. В той же MMC: правой кнопкой по выпущенному сертификату → All Tasks → Export → выбрать "Yes, export the private key" → сохранить как .pfx с паролем.
Сконвертировать 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.

Проверить доверие. Поскольку сертификат выпущен вашей же 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. Проверить на реальном сценарии

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

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

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

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

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

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

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

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

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

Итог

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

<< SSH Port Forwarding в JumpServer

Нужна помощь?

Поддержка во время пилота JumpServer PAM Enterprise Edition

Вы начали тестирование JumpServer PAM EE и столкнулись с проблемой? Наш процесс включает в себя организацию групп переписок в электронной почте или групп в Telegram для оперативного решения вопросов. Если вы уверены, что вас не добавили в такую группу, обратитесь к вашему поставщику или к нам по адресу support@afi-d.ru

Обучение ваших специалистов настройке и администрированию JumpServer PAM

В рамках действующей подписки на техническую поддержку мы обучим ваших специалистов установке, настройке, адмнистрированию JumpServer PAM, а также восстановлению после ошибок и аварий.

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

Видео-инструкции

Посетите наш канал на RuTube с видео-инструкциями по настройке всех разделов JumpServer PAM. Видео на русском языке и актуализируются с выходом новых версий.

Техподдержка бесплатной редакции JumpServer PAM Community Edition

Мысль о внедрении непростой, но критичной для бизнеса PAM-системы может пугать кажущейся сложностью настройки системы, обучением администраторов и специалистов ИБ, изменениями в процессах работы с учетными записями.

Чтобы внедрение и настройка JumpServer Community Edition были комфортными, а также чтобы вы всегда могли обратиться за помощью к профессионалам, AFI Distribution предлагают годовую подписку на техническую поддержку.

Пакет поддержки в 1.5 млн рублей за экземпляр JumpServer Community Edition включает всё необходимое для использования PAM:

документацию на русском языке;
сценарии использования и рекомендуемые архитектуры для установки;
обучение администраторов и специалистов ИБ работе с JumpServer;
подсказки и решения для популярных вопросов;
оповещения о выходе новых версий с проверенной инструкцией для апгрейда;
прямой доступ к инженеру (без первой линии) с понятным SLA.

Узнать больше и приобрести вы можете на странице Подписка на техподдержку