Можно ли включить двухфакторную аутентификацию для RDP одной настройкой?

Нет. Требование NLA означает только предварительную проверку учётных данных до создания полноценного графического сеанса; вторым фактором оно не является. Credential Guard защищает секреты на устройстве, а Remote Credential Guard не передаёт пароль и производные секреты пользователя на удалённый компьютер в поддерживаемых сценариях, но оба механизма не включают MFA. Для многофакторной аутентификации RDP обычно организуют отдельную точку входа через RD Gateway. Шлюз может аутентифицировать пользователя через поддерживаемую интеграцию RADIUS/NPS либо другой совместимый механизм MFA. Применимость конкретного поставщика, методы аутентификации и ограничения нужно сверять для используемой схемы RD Gateway и версии компонентов. Даже при MFA прямой доступ к RDP не следует оставлять открытым для всех источников. Ограничьте доступ доверенными IP-адресами, VPN-подсетями или адресами RD Gateway, используйте TLS с доверенным сертификатом и назначайте права RDP только нужным ролевым группам.

Можно ли защитить RDP от перебора только блокировкой учётных записей?

Нет. Блокировка уменьшает число попыток для одной учётной записи, но не гарантирует защиту от password spraying, распределённых атак и входа с уже украденным паролем. Слишком низкий порог также позволяет намеренно блокировать пользователей. Настраивайте её вместе с ограничением источников, NLA, TLS, MFA и мониторингом блокировок.

Почему пользователь из Remote Desktop Users получает отказ во входе?

Возможно, у пользователя нет права Allow log on through Remote Desktop Services или он, либо одна из его вложенных групп, попал в Deny log on through Remote Desktop Services. Запрет имеет приоритет над разрешением. Проверьте результирующие локальные и доменные GPO, а также фактические группы пользователя командой whoami /groups.

Нужно ли ограничивать UDP 3389, если TCP уже разрешён только с нужных IP?

Да, если UDP используется активными RDP-клиентами или конфигурацией. Ограничение только TCP не закрывает UDP-правило с областью Any: оно может оставить RDP доступным по UDP из лишних сетей. Проверьте все применимые входящие правила RDP, их профиль, протокол, порт и RemoteAddress, включая IPv6.

Почему RDP показывает предупреждение о сертификате после включения TLS?

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

Что делать, если после обновления политик настройки RDP возвращаются?

Проверьте, не переопределяет ли локальные параметры доменная GPO. Сформируйте отчёт gpresult /h C:\Temp\rdp-gpo-before.html, найдите применённые политики Remote Desktop Services, прав входа и firewall, затем изменяйте эффективный источник настройки. Не исправляйте это в единственной RDP-сессии: сохраните доступ через консоль или другой независимый канал.

Защита RDP на Windows Server: NLA, MFA и ограничение доступа

Безопасная настройка RDP складывается из независимых слоёв: ограничений по источникам, NLA и TLS, прав входа, разумной блокировки учётной записи, отключения лишних перенаправлений и аудита. NLA не заменяет firewall, защиту пароля или MFA. Многофакторная аутентификация для RDP требует поддерживаемой схемы — обычно через RD Gateway или иной шлюз, а не включается одной настройкой Windows Server.

Не меняйте RDP в единственной административной сессии

Ошибка в GPO, правах входа, firewall или сертификате может оставить сервер без удалённого доступа. До каждого изменения сохраните независимый путь восстановления: консоль гипервизора, физическую консоль или заранее проверенный канал управления. Для аппаратного управления учитывайте отдельную защиту BMC в статье «Защита BMC: безопасная настройка iDRAC, iLO и отдельной сети управления».

Подготовьте доступ, область изменений и откат

Пути в интерфейсе, названия политик, доступные переключатели и состав встроенных правил зависят от выпуска Windows Server, роли Remote Desktop Services, оснастки, языка ОС, доменных GPO и обновлений. Ниже приведены типовые действия и команды для проверки результата; перед применением сопоставьте их с официальной документацией Microsoft для используемых версии ОС, RDS и средств управления.

Безопасная подготовка перед изменением RDP

1
Зафиксируйте текущую схему входа
Запишите, кто подключается, откуда, к какому имени или IP, через прямой RDP, VPN либо RD Gateway; отдельно отметьте служебные, аварийные и привилегированные учётные записи. Проверьте, что есть минимум один подтверждённый альтернативный путь в консоль.
2
Откройте вторую проверочную сессию
Не закрывайте действующее подключение. Из отдельной клиентской машины или отдельного окна RDP выполните тест после каждого слоя: сначала доступность порта, затем вход разрешённой учётной записью, затем запрет для тестовой неразрешённой учётной записи.
3
Определите источник эффективных политик
На автономном сервере действуют локальные настройки. На члене домена или RDS-узле локальные параметры могут быть заменены доменными GPO. Сформируйте отчёт результирующих политик и сохраните его до изменений.
4
Согласуйте окно и условие отката
Определите исполнителя, время, тестовые учётные записи, разрешённые адреса и действие при отказе. Откатом может быть возврат сохранённой GPO, снятие новой области адресов с правила либо вход через консоль с исправлением политики.

Запустите команду из командной строки или PowerShell с повышенными правами. Она создаёт HTML-отчёт о применённых GPO для вошедшего пользователя и компьютера. Убедитесь, что в отчёте присутствуют обе области, затем проверьте политики Remote Desktop Services, User Rights Assignment и firewall. Если компьютерная часть отсутствует или отчёт не показывает ожидаемую доменную политику, не считайте локальную настройку окончательной.

gpresult /h C:\Temp\rdp-gpo-before.html

Показывает активный [профиль брандмауэра Windows](/baza-znaniy/glossariy/windows-firewall-profile). Ограничение, настроенное только для другого профиля, не защитит текущее подключение.

netsh advfirewall show currentprofile

Автономный сервер, член домена и RDS — разные случаи

На автономном сервере обычно достаточно локальной политики и локальных правил Microsoft Defender Firewall. На доменном сервере сначала выясняют владельца GPO и меняют источник, который станет эффективным. В развёртывании RDS нужно отдельно проверить Session Host, RD Gateway, Connection Broker и политики коллекций: ограничение на одном узле не обязательно меняет путь клиента до остальных компонентов.

Включите NLA и выберите TLS для RDP

NLA проверяет учётные данные до создания полной удалённой графической сессии. Это уменьшает поверхность службы и расход ресурсов на неаутентифицированные подключения, но не ограничивает, кто может достучаться до порта, и не добавляет второй фактор. NLA присутствует в Windows Server начиная с Windows Server 2008 и в клиентах Windows начиная с Windows Vista; для эксплуатации следует использовать только поддерживаемые выпуски ОС. В современных средах обычно проверяют совместимость управляемых клиентов Windows 10/11 и поддерживаемых версий Windows Server, а также старых RDP-клиентов, устройств и средств автоматизации.

Термин SSL в настройках RDP исторический: защищённый вариант использует TLS.

Параметр	Назначение	Практическое решение
Требовать NLA	Аутентифицирует пользователя до графического сеанса	Включить после проверки совместимости клиентов и сохранить консольный откат
RDP Security Layer	Использует собственный уровень безопасности RDP; это не выбор TLS как защищённого транспортного слоя	Не выбирать для новых управляемых подключений, когда доступен TLS
Negotiate	Позволяет клиенту и серверу согласовать SSL/TLS или RDP Security Layer	Допустим только при необходимости совместимости; проверьте, не допускается ли нежелательное понижение
SSL (TLS)	Требует TLS для RDP и сертификат сервера	Обычный выбор для управляемой современной среды; сертификат должен быть доверенным и соответствовать имени подключения

Настройка NLA и уровня безопасности RDP

1
Проверьте клиентов
Составьте список используемых RDP-клиентов и сценариев: интерактивные администраторы, службы поддержки, автоматизация, подключение через Gateway. С тестовой машины убедитесь, что клиент поддерживает NLA и доверяет планируемому сертификату.
2
Включите требование NLA
В типовой конфигурации это задают свойством удалённого доступа к серверу или политикой Remote Desktop Session Host, требующей user authentication for remote connections by using NLA. Если параметр возвращается к прежнему значению после обновления политик, найдите доменную GPO в gpresult и меняйте её, а не локальный переключатель.
3
Выберите SSL (TLS) или обоснованный Negotiate
Для современного управляемого парка задайте TLS в политике Security Layer и назначьте сертификат RDP-службе. Если остаётся Negotiate из-за совместимости, зафиксируйте конкретный несовместимый клиент и срок его замены.
4
Проверьте новое подключение по имени
Подключитесь к полному DNS-имени, которое указано в сертификате. Ожидаемый результат — вход возможен до создания рабочего стола, а клиент не показывает предупреждение о недоверенном издателе, просроченном сертификате или несовпадении имени.
5
Откатите при отказе совместимости
Не отключайте NLA для всех пользователей как первое действие. Войдите через консоль, восстановите прежнюю политику либо устраните проблему клиента или сертификата. Временно ослаблять защиту допустимо только в контролируемом окне и с ограничением источников firewall.

Предупреждение RDP о сертификате нельзя игнорировать

Предупреждение означает, что клиент не смог проверить сертификат TLS: его срок действия, цепочку доверия или соответствие имени сервера. Продолжение подключения сохраняет риск соединения не с тем узлом. Исправьте имя в сертификате или используйте корректное DNS-имя; выпуск и диагностика сертификатов разобраны в «SSL/TLS-сертификаты на сервере: как работают, какие бывают и что выбрать» и «Ошибки SSL/TLS-сертификатов: expired, chain incomplete и mismatch».

Ограничьте RDP нужными пользователями и группами

Членство в локальной группе Remote Desktop Users само по себе не гарантирует вход. Windows сопоставляет назначенные права пользователя: Allow log on through Remote Desktop Services (SeRemoteInteractiveLogonRight) разрешает вход, а Deny log on through Remote Desktop Services (SeDenyRemoteInteractiveLogonRight) запрещает его. Запрет имеет приоритет над разрешением. Обе настройки могут приходить из локальной политики, доменной GPO или политики для конкретного OU.

Настройка прав RDP без конфликтов GPO

1
Назначьте ролевую группу
Создайте или используйте доменную группу для конкретной роли, например операторов приложения, и добавьте её в разрешение RDP только на нужных серверах. Персональные учётные записи и отдельные роли проще проверять и отзывать, чем общую административную группу.
2
Проверьте Allow и Deny
В результирующей политике найдите оба права: разрешение и запрет входа через Remote Desktop Services. Проверьте не только пользователя, но и все его вложенные группы. Если учётная запись или любая её группа присутствует в Deny, удалите конфликтующее назначение либо используйте другую модель доступа.
3
Проверьте эффективное членство
Выполните вход тестовой учётной записью либо проверьте её групповые SID. Ожидаемый результат: разрешённая группа присутствует, а запрещающая — отсутствует. Для доменной учётной записи изменение членства может потребовать нового входа и обновления билетов.
4
Проведите отрицательный тест
Учётная запись вне разрешённой роли должна получить отказ. Не тестируйте запрет основной аварийной учётной записью, пока не подтверждён альтернативный канал управления.

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

whoami /groups

Не выдавайте RDP всем локальным администраторам без необходимости

Права локальных Administrators и Remote Desktop Users зависят от политики и роли сервера. Назначайте доступ отдельной группе по принципу наименьших привилегий, затем отдельно предоставляйте административные полномочия тем, кому они действительно нужны.

Ограничьте RDP по IP-адресам в Microsoft Defender Firewall

Не публикуйте RDP для всех источников интернета. Ограничьте его доверенными адресами администраторов, подсетью VPN или адресами RD Gateway по allowlist. Смена стандартного порта не является самостоятельной защитой: она не ограничивает источники, не меняет права входа и не заменяет TLS или MFA.

Для прямого RDP обычно применяются TCP 3389 и UDP 3389. TCP нужен для базового подключения; UDP используется клиентами и конфигурациями, которые его поддерживают, для улучшения передачи данных. На RDS и в разных выпусках состав активных правил может отличаться. Поэтому область источников нужно согласованно ограничить для всех применимых входящих TCP- и UDP-правил, а не оставить UDP с областью Any.

Ограничение RDP доверенными IP и подсетями

1
Определите реальные источники
Соберите внешние или внутренние IPv4-адреса администраторов, VPN-подсети и адреса RD Gateway. Не добавляйте широкую корпоративную сеть «на всякий случай»: это увеличивает число потенциальных источников.
2
Инвентаризируйте действующие правила RDP
Проверьте встроенные и GPO-правила, их профиль, протокол, локальный порт, область удалённых адресов и включённость. Если действует широкое разрешающее правило RDP, добавление рядом нового узкого правила не обязательно сузит доступ.
3
Ограничьте область каждого применимого правила
Для активного профиля задайте разрешённые адреса или подсети в RemoteAddress у TCP- и, если он используется, UDP-правила. В доменной среде предпочтительно задать это в назначенной GPO, чтобы локальная настройка не была перезаписана.
4
Отдельно проверьте IPv6
Посмотрите, есть ли на интерфейсах IPv6-адреса, маршрутизация и правила, разрешающие RDP по IPv6. Если IPv6 используется, внесите доверенные IPv6-адреса или префиксы в область правил. Если он не предусмотрен архитектурой, его состояние и политика должны быть определены отдельно, а не проигнорированы.
5
Проверьте из разрешённой и неразрешённой сети
Из разрешённого источника TCP-подключение и RDP-вход должны работать. Из неразрешённого источника подключение к порту должно быть недоступно. Если разрешённый источник не проходит, используйте консоль и сравните его фактический IP, профиль firewall и применённую GPO.

Показывает порты активных правил с распространёнными именами RDP. Локализованные имена и правила из GPO могут отличаться; сверяйте результат с правилами, которые реально применены на сервере.

Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'Remote Desktop|Удаленный рабочий стол' | Get-NetFirewallPortFilter | Format-Table Protocol,LocalPort

Показывает область удалённых адресов для найденных правил. Ожидаемый результат после настройки — конкретные IPv4/IPv6-адреса или подсети, а не `Any` для правила, открывающего RDP.

Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'Remote Desktop|Удаленный рабочий стол' | Get-NetFirewallAddressFilter | Format-Table RemoteAddress

Как изменить правило

Настройка области адресов, профилей, приоритета GPO и диагностика конфликтов правил подробно вынесены в «Windows Defender Firewall: правила, PowerShell и журналирование». Общие принципы политики и безопасного изменения доступа — в «Firewall сервера: default deny, порядок правил и политика доступа».

Настройте блокировку учётных записей без отказа в доступе

Защита RDP от перебора может включать политику блокировки учётных записей: порог неудачных попыток, длительность блокировки и период сброса счётчика. Она уменьшает число попыток для одной учётной записи, но не гарантирует защиту от password spraying, распределённых атак или использования уже украденного пароля. Слишком низкий порог позволяет злоумышленнику намеренно блокировать пользователей и создаёт операционный риск.

Выбор порога rdp account lockout

1
Разделите локальные и доменные учётные записи
Для локальных учётных записей автономного или членового сервера оцените локальную политику. Для доменных пользователей проверьте доменную политику и, если применимо, fine-grained password policies. Не предполагайте, что локальное значение управляет доменной учётной записью.
2
Оцените легитимные ошибки
По журналам определите частоту ошибочного ввода, сохранённые старые пароли на клиентах, заданиях и мобильных устройствах, а также допустимое время разблокировки. Отдельно проверьте аварийные и служебные учётные записи.
3
Выберите консервативные параметры и процедуру разблокировки
Порог должен допускать обычную ошибку пользователя, но не бесконечный подбор; длительность — быть соразмерной риску и доступности. Зафиксируйте, кто и как подтверждает личность при разблокировке.
4
Проверьте эффективную политику
Сравните значение в редакторе GPO с результатом на целевом сервере и с политикой домена. Проведите контролируемый тест только на тестовой учётной записи, не на рабочем администраторе.

Показывает часть локальных параметров учётных записей и блокировки. Для доменных пользователей этого недостаточно: проверьте доменную GPO или соответствующую политику Active Directory.

net accounts

Блокировка может стать атакой на доступность

Многократные неверные попытки к известной учётной записи способны заблокировать её до успешного входа легитимного пользователя. Наблюдайте за блокировками, подготовьте процедуру разблокировки и не распространяйте жёсткий порог без пилота. Полная настройка политики и MFA — в «Парольная политика, блокировка учётных записей и MFA в Windows Server».

Выберите поддерживаемую MFA-схему для RDP

Прямое RDP-подключение с NLA не получает универсальный второй фактор от включения NLA, Credential Guard или Remote Credential Guard. Чтобы требовать второй фактор при доступе по RDP, обычно используют точку входа RD Gateway, которая аутентифицирует пользователя через поддерживаемую интеграцию RADIUS/NPS или иной совместимый механизм MFA. Например, расширение Microsoft Entra MFA для NPS применяется в поддерживаемых RADIUS-сценариях; его применимость к RD Gateway, доступные методы аутентификации и ограничения следует сверять с актуальной документацией Microsoft и поставщика MFA.

Механизм	Что защищает	Чего не делает
Credential Guard	Изолирует секреты на устройстве с помощью виртуализационной защиты	Не добавляет MFA и не ограничивает сетевой доступ к RDP
Remote Credential Guard	Не передаёт пароль и производные секреты пользователя на удалённый компьютер в поддерживаемом RDP-сценарии	Не является вторым фактором и не подходит для всех клиентов, серверов и шлюзов
Restricted Admin Mode	Не делегирует на удалённый компьютер повторно используемые учётные данные подключившегося администратора	Не заменяет MFA и меняет модель доступа к сетевым ресурсам из удалённого сеанса
RD Gateway + совместимый MFA-поставщик	Создаёт контролируемую точку входа, где можно потребовать второй фактор	Не отменяет необходимость ограничить доступ Gateway, права RDP и аудит

Credential Guard поддерживается в соответствующих редакциях Windows при наличии аппаратной виртуализации и Virtualization-based Security; точные требования зависят от выпуска и редакции ОС, встроенного ПО, UEFI, безопасной загрузки (Secure Boot) и аппаратной платформы. Он защищает секреты на самом хосте, а не канал RDP как таковой.

Remote Credential Guard применяется для доменных RDP-сценариев с Kerberos между поддерживаемыми клиентами Windows 10 версии 1607 и новее и целевыми Windows Server 2016 и новее либо соответствующими клиентскими Windows. Он требует совместимой доменной/Kerberos-среды и не предназначен для обычного входа с произвольными локальными учётными записями. Restricted Admin Mode доступен для поддерживаемых сценариев, начиная с Windows 8.1/Windows Server 2012 R2, требует включения на целевом хосте и обычно предназначен для административного доступа. Для обоих режимов проверьте ограничения при использовании RD Gateway, типе аутентификации и конкретном RDP-клиенте до развёртывания.

Не настраивайте «RDP без пароля» отключением пароля

Windows Server не предлагает одну универсальную встроенную кнопку passwordless-входа для любого RDP-сценария. Не отключайте парольную аутентификацию, пока не проверены поддерживаемая альтернатива, MFA-схема, аварийный доступ и совместимость клиентов. Для внешнего администрирования сначала определите архитектуру VPN, bastion или Gateway в «Сегментация серверной сети: VPN, bastion host и защищённый административный доступ».

Отключите ненужные перенаправления RDP

Перенаправление устройств RDP превращает клиентские ресурсы в доступные удалённому сеансу виртуальные каналы. Буфер обмена может переносить данные в обе стороны, локальные диски — файлы, принтеры — документы, а порты и Plug and Play-устройства — дополнительные устройства. Разрешайте каждый тип только при подтверждённой рабочей необходимости.

Как запретить локальные диски, буфер обмена и устройства

1
Соберите требования пользователей
Для каждой роли спросите отдельно: нужен ли обмен текстом, передача файлов через локальные диски, печать, смарт-карта, COM/LPT-порт, аудио, камера или Plug and Play-устройства. «Иногда может понадобиться» не является достаточным основанием для постоянного разрешения.
2
Отключите ненужные категории на сервере
В политиках Remote Desktop Session Host обычно доступны параметры запрета clipboard redirection, drive redirection, printer redirection, COM/LPT port redirection, supported Plug and Play device redirection и других каналов. Для чувствительного административного сервера типичный исходный вариант — запретить все перечисленные каналы и возвращать только обоснованные исключения.
3
Проверьте настройки клиента
Клиент RDP также может предлагать локальные ресурсы. Серверная запрещающая политика должна оставаться эффективной даже при включённом флажке на клиенте. Если ресурс всё ещё виден в сеансе, проверьте применённую GPO, роль RDS и параметры коллекции.
4
Проведите проверку по каждому каналу
В тестовом сеансе убедитесь, что запрещённый буфер обмена не передаёт данные, локальные диски не отображаются, а запрещённые принтеры и устройства не появляются. Если рабочий процесс нарушен, включите только необходимую категорию для нужной группы или сервера и документируйте исключение.

Политики redirection зависят от компонента

Наличие, область действия и формулировки политик зависят от версии Windows, клиента RDP, установленной роли RDS и доменных GPO. В RDS часть настроек может задаваться политикой коллекции. Не считайте клиентский флажок доказательством итогового разрешения — проверяйте сеанс на целевом сервере.

Проверьте события успешных и неудачных RDP-входов

После изменения проверяйте журнал безопасности Windows на самом сервере и в принятой системе сбора событий. Основной признак успешного интерактивного RDP-входа — Security Event ID 4624 с Logon Type 10 (RemoteInteractive). При NLA и связанных проверках могут встречаться и другие типы, в том числе Type 3 (Network), поэтому событие нужно интерпретировать в контексте.

Событие	Что смотреть	Ограничение интерпретации
4624	Logon Type, Account Name, Workstation Name, Source Network Address, Logon ID	Type 10 обычно указывает на удалённый интерактивный вход; сам Event ID не описывает все действия в сеансе
4625	Logon Type, Status, Sub Status, имя учётной записи, источник, время	Неудачный вход не доказывает перебор: причиной могут быть старый пароль, служба, ошибка пользователя или политика
4778	Имя пользователя, имя сеанса, клиент	Указывает на повторное подключение к существующему сеансу, а не обязательно на новую аутентификацию
4779	Имя пользователя и сеанс	Указывает на отключение от сеанса; это не равнозначно завершению работы пользователя
4672	Привилегии и Logon ID	Показывает назначение чувствительных привилегий новой сессии, а не самостоятельное повышение прав

Контроль после изменения RDP

1
Сделайте контролируемый успешный вход
Подключитесь разрешённой тестовой учётной записью с разрешённого IP. Найдите 4624, сопоставьте Logon Type 10, имя пользователя, адрес источника и время с тестом.
2
Сделайте безопасный отрицательный тест
Проверьте отказ с неразрешённого IP или тестовой учётной записью без права RDP. Убедитесь, что в журналах есть ожидаемое событие или сетевой отказ, но не превышайте порог блокировки.
3
Настройте сценарий анализа, а не только поиск Event ID
Для 4625 анализируйте серию событий по времени, адресу источника, целевым именам учётных записей, Status/SubStatus и типу входа. Один 4625 — повод понять контекст, а не автоматическое доказательство атаки.
4
Подтвердите сохранение журналов
Проверьте размер и срок хранения Security Log, а при централизованном сборе — доставку тестовых записей. Если события не появляются, сначала проверьте эффективную Audit Policy и доменные GPO.

Выводит события, которые стоит сопоставить с тестами за последние сутки. Для расследования открывайте XML или поля конкретной записи: краткая таблица не содержит Logon Type, Status и адрес источника.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4625,4778,4779,4672; StartTime=(Get-Date).AddHours(-24)} | Select-Object TimeCreated,Id,ProviderName | Format-Table -AutoSize

Где продолжить настройку аудита

Настройка Advanced Audit Policy, проверка эффективного аудита и смысл полей 4624/4625 разобраны в «Аудит Windows Server: Security Event Log, Advanced Audit Policy и PowerShell logging». Для пересылки, корреляции и оповещений используйте «Централизованный сбор журналов безопасности: события, корреляция и оповещения».

Термины в статье

Allowlist: Allowlist — перечень разрешающих записей или правил: система допускает только те субъекты, объекты, действия или значения, которые им соответствуют.
Credential Guard: Credential Guard — функция Windows, изолирующая учётные данные и производные секреты с помощью виртуализации, чтобы ограничить их извлечение из процессов ОС.
Microsoft Defender Firewall: Microsoft Defender Firewall — встроенный в Windows межсетевой экран, фильтрующий входящие и исходящие соединения по правилам, профилям сети и параметрам трафика.
NLA: NLA — механизм предварительной аутентификации RDP, проверяющий учётные данные пользователя до создания полного удалённого графического сеанса.
RDP: RDP — протокол удалённого доступа к графическому сеансу Windows, передающий экран, ввод и перенаправляемые ресурсы между клиентом и хостом.
Remote Credential Guard: Remote Credential Guard — режим защиты учётных данных в RDP, при котором пароль и производные секреты пользователя не передаются на удалённый компьютер.
Restricted Admin Mode: Restricted Admin Mode — режим RDP, при котором удалённому компьютеру не делегируются повторно используемые учётные данные подключившегося пользователя.
Блокировка учётной записи: Блокировка учётной записи — временное или административное запрещение входа для аккаунта, обычно после заданного числа неудачных попыток аутентификации.
Журнал безопасности Windows: Журнал безопасности Windows — системный журнал событий, фиксирующий результаты аудита входов, доступа к объектам, изменений политик и привилегий в Windows.
Идентификатор события 4625: Событие с идентификатором 4625 — запись аудита в журнале безопасности Windows о неудачной попытке входа, содержащая сведения о причине и источнике.
Многофакторная аутентификация: Многофакторная аутентификация — метод проверки личности, требующий подтверждений из двух или более независимых факторов: знания, владения или биометрии.
Перенаправление устройств RDP: Перенаправление устройств RDP — функция протокола удалённого рабочего стола, предоставляющая сеансу доступ к выбранным ресурсам клиентского устройства через виртуальные каналы.
Политика блокировки учётных записей: Политика блокировки учётных записей — набор параметров аутентификации, задающий порог неверных входов, длительность блокировки и период сброса счётчика.
Правило межсетевого экрана: Правило межсетевого экрана — элемент политики фильтрации, задающий условия сопоставления трафика и действие над пакетами или соединениями.
Привилегированная учётная запись: Привилегированная учётная запись — учётная запись с правами управления системами, данными или политиками доступа, превышающими полномочия обычного пользователя.
Принцип наименьших привилегий: Принцип наименьших привилегий — правило предоставления пользователю, службе или процессу только тех прав и на тот срок, которые необходимы для выполнения конкретной задачи.
Профиль брандмауэра Windows: Профиль брандмауэра Windows — набор параметров и правил, применяемых к сетевому подключению в зависимости от категории сети: доменной, частной или общедоступной.
Сертификат TLS: Сертификат TLS — цифровой документ X.509, содержащий открытый ключ и идентификаторы субъекта и подписанный издателем; доверие к связи определяется цепочкой и политикой клиента.