Как не потерять удалённый доступ при настройке Windows Firewall?

Сначала сохраните текущую конфигурацию правил и проверьте рабочий административный канал. Входящий доступ ограничивайте по роли сервера, доверенным источникам и необходимым протоколам, а изменения применяйте в контролируемом порядке. До смены правил должны быть проверены RDP, PowerShell Remoting, консольный доступ или BMC, а также путь отката.

Почему локальная политика не работает на сервере в домене?

Обычно её переопределяет доменная GPO. Локальная политика имеет меньший приоритет, а итоговое значение зависит также от привязки GPO, порядка обработки, наследования, принудительного применения, фильтрации и OU. На сервере — члене домена локальные настройки подходят для диагностики или временной проверки, но корпоративные требования следует закреплять доменной политикой и проверять эффективный результат.

Что проверить перед отключением SMBv1 на Windows Server?

Проверьте состояние компонента от имени администратора командой Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol. Нельзя исходить только из типовых значений: в современных чистых установках SMBv1 обычно отсутствует, но он может сохраниться после обновления с предыдущего выпуска, зависеть от типа установки, добавленного компонента или роли. До отключения соберите сведения о соединениях с файловым сервером и версиях клиентов. Особое внимание уделите старым NAS, МФУ, промышленным устройствам, старым версиям Windows, приложениям и резервному копированию. При наличии зависимостей заранее подготовьте обновление либо изоляцию неподдерживаемого устройства. В типичной конфигурации компонент отключают командой Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart, затем выполняют требуемую перезагрузку и повторно проверяют состояние. Не следует возвращать SMBv1 как постоянное решение: если это неизбежно, остаточный риск нужно документировать.

Можно ли сразу отключить NTLM на рабочих серверах?

Нет, сначала переведите ограничение в аудит или протестируйте его в отдельном контуре. Запрет NTLM способен отключить старых клиентов и приложения, поэтому до изменений нужны журналы протоколов, пилотная группа, проверка сервисов и заранее подготовленный откат. Расширять применение можно только после выявления затронутых учётных записей, клиентов и приложений.

Что будет, если включить обязательную подпись SMB?

Подключения клиентов или серверов без поддержки SMB signing перестанут устанавливаться. Требование подписи проверяется отдельно для серверной и клиентской стороны SMB: сервер контролирует входящие подключения к своим ресурсам, а клиент — подключения этого хоста к удалённым ресурсам. Поэтому настройку нужно проверять с учётом обеих ролей и совместимости всех участников.

Почему после отвязки тестовой GPO настройки не вернулись?

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

Hardening Windows Server 2019, 2022 и 2025: базовая защита

Начинайте hardening Windows Server не с массового импорта шаблона, а с инвентаризации роли, зависимостей и каналов администрирования. Затем выберите проверяемую базовую конфигурацию безопасности, применяйте её через пилотные группы и после каждого этапа проверяйте доступность сервисов и удалённого управления. Настройки, способные отключить старые клиенты — запрет NTLM, обязательная подпись SMB, удаление SMBv1, ограничения RDP, — сначала переводят в аудит или тестируют в отдельном контуре с заранее подготовленным откатом.

С чего начать hardening Windows Server

Одинаковая локальная политика не подходит автоматически файловому серверу, серверу приложений и контроллеру домена. Роль определяет опубликованные службы, используемые учётные записи, допустимые протоколы, требуемые сетевые потоки и последствия ошибки. Контроллер домена особенно чувствителен: его политики и аутентификация влияют на домен, а аварийное восстановление зависит от архитектуры Active Directory, а не только от доступа к одной машине.

Подготовка нового или работающего Windows Server к усилению защиты

Маршрут одинаков для Windows Server 2019, 2022 и 2025, но конкретный набор параметров зависит от выпуска, роли, установленных компонентов, обновлений и корпоративных политик.

1
Зафиксируйте контекст сервера
Запишите имя хоста, версию Windows, членство в домене, роль сервера, установленные роли и компоненты, владельца приложения, критичность, сетевые интерфейсы, опубликованные сервисы и зависимые системы. Отдельно укажите, является ли сервер автономным, членом домена или контроллером домена. Ожидаемый результат — карточка сервера, по которой можно понять, какие изменения допустимы. Если владельца приложения или перечня клиентов нет, не вводите потенциально несовместимые запреты до инвентаризации.
2
Определите рабочие и аварийные пути управления
Проверьте, как выполняются RDP, PowerShell Remoting, консольный доступ и обслуживание через BMC, если он есть. Для автономного сервера и члена домена подготовьте отдельную аварийную учётную запись и проверенный консольный путь. Для контроллера домена согласуйте действия с владельцами домена, доступностью других контроллеров и процедурой восстановления Active Directory. Ожидаемый результат — проверенный способ войти на сервер и откатить политику, если обычный удалённый доступ перестанет работать.
3
Снимите исходное состояние политик и конфигурации
Сохраните результат применения групповых политик, сведения о локальных администраторах, включённых службах, сетевых правилах и параметрах SMB. Для доменного сервера определите GPO, уже назначенные его организационному подразделению. Ожидаемый результат — исходная точка для сравнения и понятный владелец каждой действующей политики. Если настройка уже задаётся доменной GPO, не исправляйте её локально: локальное значение может быть перезаписано при следующем обновлении политик.
4
Подготовьте проверку сервисов и откат
До изменения составьте короткий тест: вход администратора, подключение приложения, доступ клиентов к файловым ресурсам, работа резервного копирования, мониторинга, службы каталогов и зависимых заданий. Для каждой волны изменений определите окно обслуживания, ответственного, критерий остановки и способ вернуть прежние значения: обратную GPO, восстановление сохранённой конфигурации или явную установку предыдущих параметров. Отключение или отвязку тестовой GPO используйте как откат только после проверки, что конкретные параметры действительно возвращаются в прежнее состояние: часть настроек безопасности может сохраниться после выхода GPO из области действия. Ожидаемый результат — изменения можно проверять не по факту успешного выполнения команды, а по работе нужных сервисов.
5
Включите сбор сигналов до усиления запретов
Настройте хранение и просмотр журнала безопасности Windows, журналов применения политик и журналов протоколов, которые планируется ограничивать. Если используется пересылка событий Windows, проверьте доставку тестового события на коллектор. Ожидаемый результат — после пилота можно установить, какой клиент, учётная запись или приложение затронуты. Детальная настройка аудита приведена в статье «Аудит Windows Server: Security Event Log, Advanced Audit Policy и PowerShell logging».

Не применяйте baseline одновременно ко всем серверам

Импорт шаблона на уровне домена или корневого OU без пилота может изменить аутентификацию, права входа, SMB, службы и административный доступ на множестве хостов. Сначала применяйте изменения к отдельной группе серверов одной роли, проверяйте результат и только затем расширяйте область действия.

Выбор Microsoft Security Baselines, CIS Benchmark и собственного baseline

Microsoft Security Baselines — отправная точка Microsoft для поддерживаемых продуктов и выпусков Windows. Для Windows Server Microsoft публикует baselines через Microsoft Security Compliance Toolkit: набор обычно содержит резервные копии или шаблоны GPO, таблицы параметров и материалы для сравнения и развёртывания. Доступность конкретного baseline нужно сверять для точного выпуска Windows Server: актуальность пакетов и состав параметров меняются со временем.

Для Windows Server 2019, 2022 и 2025 следует брать baseline, соответствующий именно установленному выпуску и состоянию обновлений, а не переносить параметры из другого поколения ОС. Microsoft документирует развёртывание baseline через Group Policy и инструменты Security Compliance Toolkit, включая сравнение политик. Перед импортом проверьте официальный комплект и документацию Microsoft для используемого baseline.

Как выбрать источник параметров для Windows Server hardening

Источник	Когда использовать	Что обязательно проверить
Microsoft Security Baselines	Нужна исходная конфигурация, близкая к рекомендациям Microsoft для конкретного продукта.	Соответствие выпуску Windows Server, пересечения с действующими GPO, влияние на роли и приложения.
CIS Benchmark	Нужен независимый проверяемый ориентир, например для аудита или требований организации.	Выбранный уровень жёсткости, применимость каждого параметра, совместимость старых клиентов и сервисов.
Собственный baseline организации	Есть утверждённые требования, архитектура управления, набор поддерживаемых приложений и процедура исключений.	Связь с Microsoft или CIS как источником, версия baseline, владельцы, документированные отклонения и порядок пересмотра.

CIS Benchmark не является обязательной или универсально совместимой конфигурацией. Его уровни жёсткости могут предполагать ограничения, которые недопустимы для части серверов. Практичный вариант — взять Microsoft baseline или CIS Benchmark как исходный набор, сравнить с текущими GPO, утвердить исключения по ролям и собрать собственный версионируемый профиль. Методика составления такого профиля описана в статье «Базовая защита сервера: как составить security baseline».

Внедрение baseline без массового отказа сервисов

1
Сравните шаблон с эффективными политиками
Сопоставьте параметры baseline с политиками, которые уже применяются к серверу. Отмечайте конфликтующие значения, владельца текущей GPO, цель настройки и затронутые роли. Ожидаемый результат — перечень изменений, а не непрозрачный импорт готового шаблона.
2
Разделите параметры по риску
Оцените влияние каждого параметра на роль, приложения и административный доступ. Сначала включите необходимый аудит и проверьте аварийный путь управления. Обновления, отключение служб, сокращение привилегий, SMB signing, NTLM, права входа, криптографические настройки и сетевые ограничения проводите отдельными волнами с подходящими тестами: ни одну из этих групп нельзя автоматически считать безопасной для всех серверов. Ожидаемый результат — при проблеме известно, какая группа изменений стала причиной.
3
Примените GPO к пилотной группе
Создайте отдельную группу серверов или OU для одной роли и привяжите тестовую GPO только к ней. Не редактируйте исходную корпоративную политику без контроля версий и согласования. Ожидаемый результат — изменения получают только выбранные узлы. Снятие ссылки или фильтрация области действия прекращает применение GPO, но не гарантирует возврат каждого параметра: для отката заранее подготовьте обратную GPO, предыдущую версию с нужными значениями или другой проверенный способ восстановления конфигурации.
4
Проверьте эффективный результат
После обновления политик убедитесь, что сервер получил ожидаемую GPO, параметры действительно изменились, а тест сервисов и удалённого доступа прошёл. Если значение отличается от проекта, найдите GPO, которая его задаёт, и скорректируйте область действия или приоритет; не компенсируйте доменную политику случайным локальным параметром.
5
Зафиксируйте исключения и расширьте пилот
Для каждого отклонения запишите причину, владельца приложения, компенсирующую меру, срок пересмотра и условие отмены. Только после стабильной работы пилота переносите GPO на следующую группу. Ожидаемый результат — конфигурационное соответствие можно проверять повторно после обновлений и изменений роли сервера.

Локальная политика безопасности и доменные GPO

Локальная политика безопасности хранит параметры безопасности на конкретном компьютере: например, права пользователей, локальные параметры безопасности и локальные политики аудита. Она является частью локальной Group Policy, но не включает весь набор возможностей редактора локальных политик: Local Group Policy также содержит параметры конфигурации компьютера и пользователя, включая административные шаблоны.

В домене параметры обычно управляются через Active Directory Group Policy. При обработке политик локальная политика имеет меньший приоритет, чем доменные GPO; при конфликте значение доменной политики обычно переопределяет локальное. На итог также влияют привязка GPO, порядок обработки, наследование, принудительное применение, фильтрация и политики OU. Поэтому локальная настройка на члене домена подходит для диагностики или временной проверки, но не является надёжным способом закрепить корпоративное требование.

Тип сервера	Основной способ управления	Особенность
Автономный сервер	Локальная Security Policy и Local Group Policy, либо поддерживаемое средство управления конфигурацией.	Нет доменной GPO, которая автоматически переопределит локальное значение; требуется особенно тщательно документировать настройки.
Член домена	Доменная GPO с ограниченной областью действия по роли или OU.	Локальные параметры могут быть перезаписаны доменной политикой; проверяют эффективный результат на хосте.
Контроллер домена	Отдельные GPO для OU контроллеров домена и правила, согласованные с архитектурой AD.	Изменения аутентификации, NTLM, прав входа и аудита могут влиять на доменные сервисы и другие системы.

Проверяйте эффективную политику

Наличие параметра в редакторе GPO не подтверждает его фактическое действие. После применения проверяйте результирующий набор политик на сервере и журналы Group Policy. Если доменная настройка конфликтует с локальной, исправляйте источник доменной политики или документируйте исключение.

Учётные записи и административный доступ

Для административной работы используйте отдельные персональные привилегированные учётные записи, а не обычные пользовательские учётные записи и не общий Administrator. Права выдавайте по принципу наименьших привилегий: членство в локальных администраторах, делегирование в AD и права удалённого входа должны соответствовать конкретной задаче.

На автономном сервере и сервере — члене домена существуют локальные встроенные учётные записи Administrator и Guest в локальной базе SAM. На контроллере домена локальная SAM для обычного управления учётными записями не используется: встроенные Administrator и Guest относятся к домену. Не переносите процедуру управления локальными пользователями на контроллер домена без проверки архитектуры и доменных политик.

Проверьте состав локальной группы Administrators и доменных групп, которым разрешено администрирование. Удалите неиспользуемые учётные записи и необоснованные постоянные права после проверки владельцем сервиса.
Убедитесь, что встроенная Guest отключена там, где она не требуется. В типовой конфигурации Windows встроенные Guest отключены, но это следует проверить в фактической системе и в применяемых политиках.
Не используйте встроенную Administrator как повседневную общую учётную запись. Если она нужна для аварийного сценария, ограничьте хранение реквизитов, доступ к ним и порядок использования.
Проверьте служебные учётные записи: владелец, назначение, права интерактивного входа, зависимости задач и служб. Не применяйте к ним запреты или блокировки без теста.
Политику паролей, блокировки учётных записей и MFA настраивайте как отдельный этап. Детали — в статье «Парольная политика, блокировка учётных записей и MFA в Windows Server».

Не блокируйте собственный административный доступ

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

Обновления, службы и сетевые точки входа

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

Инвентаризируйте службы, слушающие сетевые порты, и отключайте только подтверждённо неиспользуемые компоненты. Входящий доступ ограничивают по роли сервера, доверенным источникам и требуемым протоколам через Microsoft Defender Firewall. До изменения правил сохраните текущую конфигурацию и проверьте административный канал. Детальная настройка правил, профилей и журналирования рассматривается в статье «Windows Defender Firewall: входящие правила, PowerShell и журналирование».

Настройки TLS, наборов шифров и устаревших версий протокола не включайте в общий шаблон без проверки компонента, который завершает TLS-соединение: IIS, HTTP.sys, приложение, прокси или балансировщик могут иметь разные настройки. Это отдельная задача — «Hardening TLS: версии протокола, cipher suites и проверка слабых настроек».

Как отключить SMBv1 и спланировать подпись SMB

SMBv1 — устаревшая версия файлового протокола. В современных чистых установках Windows Server компонент SMBv1 обычно не установлен по умолчанию, однако он может сохраниться после обновления с предыдущего выпуска, зависеть от типа установки, добавленного компонента или роли. Поэтому для Windows Server 2019, 2022 и 2025 проверяют фактическое состояние, а не полагаются только на типовое значение по умолчанию.

Показывает состояние компонента SMBv1. Запускайте PowerShell с правами администратора.

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Вывод:

`Enabled` означает, что компонент включён. `Disabled` означает, что он отключён, но не обязательно удалён из хранилища компонентов; удалённая полезная нагрузка может отображаться как `DisabledWithPayloadRemoved`.

Отключает компонент SMBv1 в типичной конфигурации Windows Server. Перед выполнением проверьте устройства, приложения и резервное копирование, использующие файловые ресурсы; затем выполните требуемую перезагрузку и повторно проверьте состояние.

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Удаление SMBv1 может отключить старые системы

Устаревшие NAS, МФУ, промышленные устройства, старые версии Windows и приложения могут поддерживать только SMBv1. До отключения соберите соединения к файловому серверу, проверьте версии клиентов и подготовьте обновление или изоляцию неподдерживаемого устройства. Не возвращайте SMBv1 как постоянное решение без документированного остаточного риска.

Подпись SMB защищает целостность и подлинность SMB-сообщений, но требование подписи означает, что подключение не состоится с клиентом или сервером, который её не поддерживает. Параметры относятся отдельно к клиентской и серверной стороне SMB: сервер проверяет входящие подключения к своим ресурсам, клиент — подключения этого хоста к удалённым ресурсам.

Проверяет фактическое состояние SMB-сервера, включая поддержку и обязательность подписи.

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSecuritySignature,RequireSecuritySignature

Проверяет настройки SMB-клиента на сервере, который сам может обращаться к удалённым файловым ресурсам.

Get-SmbClientConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature

Значения по умолчанию подписи SMB различаются для клиентской и серверной стороны, а также зависят от роли и поколения Windows. В Windows Server 2025 SMB-клиент по умолчанию требует подпись для исходящих соединений. Это не означает, что любой SMB-сервер под Windows Server 2025 по умолчанию требует подпись для всех входящих соединений: такое требование по умолчанию действует, в частности, на контроллерах домена. В Windows Server 2019 и 2022 обязательность также зависит от стороны SMB, роли сервера и действующих политик. Во всех случаях проверяйте фактические значения RequireSecuritySignature на хосте и результирующие GPO.

Переход к обязательной подписи SMB

1
Разделите входящий и исходящий SMB
Составьте два списка: кто подключается к общим папкам этого сервера и к каким удалённым SMB-ресурсам подключается сам сервер. Добавьте резервное копирование, агенты, кластеры, устройства и сервисные учётные записи. Ожидаемый результат — понятно, какие клиенты проверять для серверной и клиентской стороны SMB.
2
Проверьте текущие настройки и соединения
Соберите текущие параметры командами Get-SmbServerConfiguration и Get-SmbClientConfiguration, затем проверьте доступ пилотных клиентов к файловым ресурсам. Ожидаемый результат — исходный набор совместимых клиентов и серверов.
3
Включите требование в пилотной GPO
Для доменных серверов задайте документированные параметры обязательной подписи SMB в отдельной GPO пилотной группы. На автономном сервере допустимо применить эквивалентные локальные настройки после сохранения исходного состояния. Ожидаемый результат — только пилотный сервер требует подпись на выбранной стороне SMB.
4
Проверьте все зависимые сценарии
Протестируйте чтение и запись файлов, резервное копирование, доступ устройств и межсерверные операции. При отказе определите неподдерживающего участника и обновите его, измените архитектуру доступа или оформите временное исключение. Не отключайте требование глобально только потому, что один старый клиент не подключается.
5
Расширяйте область действия по ролям
После успешного пилота перенесите настройку на однотипные серверы в окно обслуживания. Повторно проверьте фактические параметры и доступность ресурсов. Ожидаемый результат — обязательная подпись вводится контролируемо, а несовместимые системы известны и имеют план устранения.

Как ограничивать NTLM без внезапного отказа старых систем

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

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

Безопасный переход от аудита NTLM к ограничению

1
Определите область и владельцев
Разделите серверы на контроллеры домена, серверы — члены домена и автономные системы. Для каждой группы зафиксируйте приложения, старые устройства, внешние доверия и сервисные учётные записи. Ожидаемый результат — вы знаете, где нужен доменный аудит, а где важен входящий или исходящий NTLM на конкретном сервере.
2
Включите аудит, а не запрет
Через отдельную пилотную GPO включите документированные политики аудита NTLM, соответствующие роли. Собирайте записи из NTLM Operational и связанных журналов в течение периода, который покрывает обычные и регламентные операции. Ожидаемый результат — список фактических потребителей NTLM с именем клиента, сервера или приложения и учётной записью, где эта информация доступна.
3
Разберите каждую зависимость
Для каждого случая определите, можно ли перейти на Kerberos или другой поддерживаемый механизм, обновить клиент, исправить DNS/SPN, изменить учётную запись службы либо изолировать устаревшее устройство. Ожидаемый результат — обоснованный план устранения, а не список необъяснённых событий.
4
Проверьте запрет на ограниченной группе
В окно обслуживания примените ограничение NTLM к пилотной группе или тестовому контуру, сохранив аварийный доступ. Протестируйте вход, доступ к ресурсам, задания, службы и приложение. При отказе примените заранее подготовленную обратную GPO или явно верните предыдущие значения, затем проверьте эффективную политику и устраните выявленную зависимость. Не рассчитывайте только на снятие ссылки с пилотной GPO: отдельные параметры могут сохраниться после выхода политики из области действия.
5
Документируйте исключения
Если немедленный отказ от NTLM невозможен, ограничьте область исключения конкретным сервером или сценарием, добавьте компенсирующие меры и дату пересмотра. Ожидаемый результат — NTLM не остаётся разрешённым глобально из-за одной устаревшей интеграции.

Ограничение RDP и других административных точек входа

RDP не следует публиковать для всего интернета. Ограничьте источники подключения доверенными адресами, VPN-диапазоном, RD Gateway или выделенной точкой администрирования в соответствии с архитектурой сети. Сегментация, VPN и bastion host рассматриваются в статье «Сегментация серверной сети: VPN, bastion host и защищённый административный доступ».

Для совместимых клиентов включите NLA: она выполняет аутентификацию до создания полного графического RDP-сеанса и снижает нагрузку от неаутентифицированных подключений. NLA не является MFA и не заменяет ограничение источников, защиту учётных записей или аудит. MFA внедряется только в поддерживаемой для выбранной схемы удалённого доступа конфигурации.

Разрешите RDP только администраторам и операторам, которым он действительно нужен; проверьте права удалённого входа, запреты входа и действие локальных и доменных GPO.
Используйте отдельные привилегированные учётные записи для администрирования и не предоставляйте RDP всем обычным пользователям.
Ограничьте адреса источников в сетевой политике и учитывайте IPv4 и IPv6. Не считайте смену стандартного порта RDP защитой от атак.
Включите NLA после проверки совместимости клиентов и сохраните консольный или иной аварийный путь управления.
Проверьте необходимость перенаправления локальных дисков, буфера обмена, принтеров и других ресурсов: эти возможности расширяют канал обмена данными.
Собирайте события успешных и неуспешных входов, но анализируйте их вместе с типом входа, учётной записью и источником.

Пошаговая настройка NLA, MFA, ограничений RDP, перенаправлений устройств и правил доступа приведена в статье «Защита RDP на Windows Server: NLA, MFA, ограничения доступа и перенаправлений».

Проверка baseline, журналирование и контроль дрейфа

После hardening важен не только шаблон GPO, но и фактическое состояние сервера. Конфигурационный дрейф возникает, когда локальное изменение, новая GPO, обновление, установленная роль или ручное исключение постепенно уводят хост от утверждённого baseline. Результирующая политика и журналы Group Policy помогают определить, какая GPO управляет параметром и успешно ли она применилась, но не всегда показывают автора изменения. Для атрибуции заранее настраивают аудит изменений GPO в Active Directory и SYSVOL либо используют журнал системы управления конфигурациями; локальные изменения требуют подходящего аудита объектов. Отдельно проверяйте, сохранился ли административный доступ.

Минимальные категории контроля после применения baseline

Что контролировать	Категории или каналы	Что искать
Входы и аутентификация	Расширенная политика аудита: Account Logon, Logon/Logoff, включая Special Logon по необходимости.	Успешные и неуспешные входы, сеансы со специальными привилегиями, неожиданные источники и типы входа.
Изменение учётных записей и групп	Account Management.	Создание, включение, отключение и изменение учётных записей; изменение членства в привилегированных группах.
Применение и изменение политик	Policy Change, журнал Security и Operational-канал Group Policy; для изменения самих GPO — аудит Active Directory и SYSVOL либо журнал системы управления конфигурациями.	Применение и ошибки GPO; поддерживаемые события изменения политики аудита, прав пользователей и политик аутентификации. Изменение содержимого GPO и его автора проверяют в источнике управления политикой, а не только в журналах конечного сервера.
Использование привилегий и процессы	Privilege Use и Detailed Tracking; аудит создания процессов включают по назначению.	Использование чувствительных привилегий, создание административных или неожиданных процессов. Выдачу специальных привилегий сеансу проверяют через Special Logon.
Доступ к критичным объектам	Object Access, включаемый выборочно вместе с подходящими SACL.	Доступ и изменения объектов, для которых аудит нужен по сценарию: общих ресурсов, ключевых файлов, реестра или других защищаемых объектов.
Контроллеры домена	Directory Service Access, прежде всего Directory Service Changes, и подходящие SACL объектов AD.	Изменения объектов Active Directory и действия, влияющие на аутентификацию домена.
SMB и NTLM	Соответствующие SMB- и NTLM-каналы журналов.	Неудачные или несовместимые SMB-подключения, обращения с NTLM и клиенты, которые зависят от ограничиваемых механизмов.
Состояние системы	System и Application, журналы служб и средств управления.	Ошибки запуска служб, перезагрузки, отказы компонентов после обновления или применения политик.

Для детального аудита используйте расширенную политику аудита, а не включайте все возможные категории без цели: чрезмерный объём событий затрудняет расследование и может переполнить хранилище. Конкретные подкатегории, Event ID, размер журналов, аудит PowerShell и Sysmon разобраны в статье «Аудит Windows Server: Security Event Log, Advanced Audit Policy и PowerShell logging».

Проверка результата после каждой волны hardening

1
Проверьте, какая политика победила
Сравните ожидаемые значения baseline с результирующими настройками на сервере и отчётом о применённых GPO. Ожидаемый результат — для каждого критичного параметра известен управляющий объект политики. Если параметр не совпадает с проектом, найдите конфликтующую GPO или локальное изменение.
2
Повторите функциональные тесты
Проверьте доступ администратора в новой сессии, работу роли сервера, клиентские подключения, задания, мониторинг и резервное копирование. Ожидаемый результат — успешное применение политики сопровождается работающим сервисом. При ошибке используйте подготовленный откат, а не добавляйте широкое исключение без анализа.
3
Проверьте журналы изменений и отказов
Убедитесь, что поступают события применения GPO, изменения политик, входов и ошибок SMB или NTLM, если эти протоколы затронуты. Ожидаемый результат — журнал содержит контекст для диагностики. Если событий нет, сначала исправьте аудит или пересылку, затем расширяйте область действия запрета.
4
Зафиксируйте новую эталонную конфигурацию
Сохраните версию baseline, назначенные GPO, дату внедрения, результаты тестов и принятые исключения. Ожидаемый результат — при следующем изменении можно отличить согласованное обновление от конфигурационного дрейфа.
5
Назначьте регулярный пересмотр
Пересматривайте baseline после смены роли, установки приложения, крупного обновления Windows, изменения схемы удалённого доступа или появления новых клиентов SMB/NTLM. Ожидаемый результат — baseline остаётся применимым к реальной системе, а не превращается в устаревший документ.

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

CIS Benchmark: CIS Benchmark — набор рекомендаций CIS по безопасной конфигурации конкретной ОС, платформы или сервиса с проверяемыми параметрами и уровнями жёсткости.
Hardening: Hardening — процесс усиления защищённости системы через отключение лишних функций, ограничение доступа и настройку безопасных параметров для снижения доступной поверхности атаки.
Microsoft Defender Firewall: Microsoft Defender Firewall — встроенный в Windows межсетевой экран, фильтрующий входящие и исходящие соединения по правилам, профилям сети и параметрам трафика.
Microsoft Security Baselines: Microsoft Security Baselines — набор рекомендуемых параметров защиты для конкретных версий продуктов Microsoft, публикуемый как основа для безопасной типовой конфигурации.
NLA: NLA — механизм предварительной аутентификации RDP, проверяющий учётные данные пользователя до создания полного удалённого графического сеанса.
NTLM: NTLM — семейство протоколов аутентификации Microsoft с механизмом запрос—ответ, применяемое в Windows для подтверждения учётных данных без передачи пароля в открытом виде.
RDP: RDP — протокол удалённого доступа к графическому сеансу Windows, передающий экран, ввод и перенаправляемые ресурсы между клиентом и хостом.
Базовая конфигурация безопасности: Базовая конфигурация безопасности — утверждённый набор обязательных параметров защиты для однотипных систем, используемый как эталон развёртывания и контроля отклонений.
Журнал безопасности Windows: Журнал безопасности Windows — системный журнал событий, фиксирующий результаты аудита входов, доступа к объектам, изменений политик и привилегий в Windows.
Конфигурационное соответствие: Конфигурационное соответствие — степень, в которой фактические параметры ИТ-объекта отвечают утверждённой политике, шаблону или базовой линии.
Конфигурационный дрейф: Конфигурационный дрейф — накопившееся отклонение фактической конфигурации системы от утверждённого эталона вследствие несогласованных или незафиксированных изменений.
Локальная политика безопасности: Локальная политика безопасности — хранящиеся на компьютере параметры безопасности Windows, действующие для этого узла; доменные GPO могут переопределять конфликтующие настройки.
Пересылка событий Windows: Пересылка событий Windows — механизм доставки записей журналов Windows с источников на сервер-коллектор по подпискам, без установки отдельного агента сбора.
Подпись SMB: Подпись SMB — механизм проверки целостности и подлинности сообщений SMB, добавляющий криптографическую подпись к обмену между клиентом и файловым сервером.
Политика блокировки учётных записей: Политика блокировки учётных записей — набор параметров аутентификации, задающий порог неверных входов, длительность блокировки и период сброса счётчика.
Привилегированная учётная запись: Привилегированная учётная запись — учётная запись с правами управления системами, данными или политиками доступа, превышающими полномочия обычного пользователя.
Принцип наименьших привилегий: Принцип наименьших привилегий — правило предоставления пользователю, службе или процессу только тех прав и на тот срок, которые необходимы для выполнения конкретной задачи.
Расширенная политика аудита: Расширенная политика аудита — механизм Windows, задающий детальные подкатегории аудита безопасности вместо общих категорий базовой политики аудита.