RD Gateway + NPS + двухфакторка: закрываем прямой RDP из интернета

Прямой RDP на 3389 из интернета - это то, что мы видим в половине аудитов периметра. Не потому что люди не знают про риски, а потому что «так сложилось» и «работает же». Работает, да. До первого брутфорса или до аудитора с чеклистом PCI DSS.

У одного из клиентов на сопровождении как раз пришло время для аудита карточной инфраструктуры. Один из пунктов - удалённый доступ администраторов к серверам. Прямой RDP был открыт на несколько машин в DMZ. Это не проходит по требованиям 8.3 и 8.2: нет MFA, нет нормального аудита, нет контроля доступа на уровне выше «знаешь пароль - зашёл».

Решение - RD Gateway с NPS и двухфакторной аутентификацией. Прямой 3389 закрывается, всё ходит через шлюз по HTTPS (порт 443), аутентификация - логин/пароль плюс OTP, каждое подключение пишется в журнал.

Что такое RD Gateway и зачем он нужен

Remote Desktop Gateway (раньше - TS Gateway) - это роль Windows Server, которая принимает RDP-соединения по HTTPS и проксирует их на целевые серверы внутри сети. Клиент подключается через стандартный mstsc.exe, никакого дополнительного ПО не нужно. С точки зрения сети: наружу открыт только 443/TCP на шлюзе, все внутренние серверы закрыты.

Дополнительно идут два компонента политик:

• CAP (Connection Authorization Policy) - кто имеет право подключаться через шлюз (группы AD, MFA).
• RAP (Resource Authorization Policy) - к каким серверам кто имеет право подключаться.

Это позволяет гранулировать: один пользователь может достать только сервер A, другой - только сервер B. Без шлюза такой гранулярности нет вообще.

NPS как центральный компонент

Network Policy Server - это RADIUS-сервер от Microsoft. В нашей схеме он делает две вещи: обрабатывает запросы аутентификации от RD Gateway и пишет accounting в Event Log с полным набором атрибутов - кто, когда, с какого IP, на какой сервер, сколько времени держал сессию.

Именно NPS-логи стали ответом на вопрос аудитора «как вы аудируете административный доступ». Event ID 6272 (аутентификация разрешена) и 6273 (отказано) в журнале Network Policy and Access Services - это стандартный формат, который умеют читать SIEM-системы и который устроит QSA при проверке PCI DSS.

Двухфакторная аутентификация: что выбрали

Здесь начинается самое интересное, потому что готовых интеграций с RADIUS в 2014 году несколько, и все с нюансами.

Мы смотрели на два варианта:

• TOTP через сторонний RADIUS-сервер (например, FreeRADIUS + Google Authenticator PAM). Работает, но требует Linux-сервера рядом и самостоятельной поддержки.
• Аппаратные токены SafeNet через SafeNet Authentication Manager, который умеет RADIUS. Дороже, но у клиента уже были токены для другого проекта.

Выбрали второй вариант - проще согласовать с QSA, когда токен физический. SAM публикует RADIUS endpoint, NPS перенаправляет на него запросы через Connection Request Policy с Remote RADIUS Server Group. Схема:

mstsc.exe -> RD Gateway (443/HTTPS) -> NPS -> RADIUS -> SafeNet Auth Manager -> Active Directory

Пользователь в mstsc вводит логин и пароль+OTP (слитно, как один пароль). SAM разделяет их, проверяет OTP по токену, пароль - по AD.

Конфигурация RD Gateway

На Windows Server 2012 R2 роль ставится через Server Manager -> Add Roles -> Remote Desktop Services -> Remote Desktop Gateway. Вместе с ней добавляется RD Web Access - веб-интерфейс для запуска приложений через браузер, мы его тоже включили.

Ключевые моменты настройки:

• SSL-сертификат - обязательно публичный от доверенного CA или корпоративный PKI с проверкой цепочки у клиентов. Самоподписанный вызовет предупреждения и проблемы с mstsc на некоторых версиях. Мы взяли сертификат от того же CA, что закрывает публичные сервисы клиента.
• CAP - разрешаем только группу AD «RDP-Admins», метод аутентификации - Password и Smart Card (последнее нужно для RADIUS с OTP).
• RAP - явный список серверов. Не «все компьютеры домена», а конкретная группа ресурсов.
• NPS как внешний auth - в свойствах CAP указываем использовать Central NPS Server, прописываем адрес и shared secret.

После первоначальной настройки несколько часов ушло на отладку ошибки «The connection was denied because the user account is not authorized for remote login». Причина оказалась в том, что NPS не видел атрибут Tunnel-Type в RADIUS-ответе от SAM - пришлось добавить его в профиль ответа вручную.

Что с TLS на шлюзе

Поскольку шлюз слушает на 443 - к нему применимо всё то же самое, что мы делали с TLS-конфигами после Heartbleed. На IIS, который поднимается под RD Gateway, TLS настраивается через реестр или через SChannel GPO. По умолчанию Windows Server 2012 R2 разрешает TLS 1.0 - для PCI DSS это уже на грани, особенно если аудит идёт строгий. Мы выключили TLS 1.0 через реестровый ключ HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.

Нюанс: стандартный RDP-клиент на Windows XP работает только по TLS 1.0. Поскольку XP у клиента уже выведена из эксплуатации - это не проблема. Для всех остальных TLS 1.2 работает без вопросов.

Что получилось

Прямой 3389 закрыт на файрволе. Единственная точка входа - 443 на шлюзе. Каждое подключение требует токена. Каждое подключение пишется в NPS Event Log с атрибутами, достаточными для ответа на вопрос «кто был на сервере X в момент Y».

Аудитор PCI DSS закрыл пункты 8.2 и 8.3 без замечаний.

Побочный эффект, который оценили пользователи: RD Web Access даёт веб-интерфейс для запуска опубликованных приложений прямо в браузере, без необходимости прописывать адрес шлюза в mstsc руками. Это мелочь, но для тех, кто подключается редко и забывает настройки - удобно.

Что осталось на следующий шаг - интеграция NPS-логов в централизованный сбор событий. Пока они живут только в Event Log на NPS-сервере, что для аудита достаточно, но для оперативного мониторинга - не идеально.