Эксперты в подборе IT-оборудования
Антивирус знает вредонос в лицо. Проблема в том, что у шифровальщика каждый раз новое лицо: сборку пересобирают под конкретную жертву, и к моменту запуска её ещё нет ни в одной базе. Дальше всё зависит от эвристики и удачи.
Белый список переворачивает логику. Вместо «запрещаем то, что опознали как плохое» - «разрешаем то, что мы сами внесли в список, остальное не запускается». Неизвестный файл не проверяется на вредоносность. Он просто не стартует.
В Windows для этого есть три механизма разного возраста: старый SRP, привычный админам AppLocker и относительно новый App Control for Business. Разберём, чем они отличаются, что из этого живо в 2026 году и как внедрять, не остановив работу компании.
| SRP | AppLocker | App Control for Business | |
|---|---|---|---|
| Когда появился | Windows XP / Server 2003 | Windows 7 / Server 2008 R2 | Windows 10, до 2024 года назывался WDAC |
| Статус у Microsoft | признан устаревшим начиная с Windows 10 1803 и Server 2019 | развитие остановлено: только исправления безопасности, новых возможностей не будет | развивается, рекомендуется для новых внедрений |
| Где ещё работает | Server 2022 и 2025 - да, клиентская Windows 11 22H2 и новее - нет | все поддерживаемые Windows Server | все поддерживаемые Windows Server |
| Настройка | оснастка групповых политик | оснастка групповых политик, PowerShell, MDM | XML-политика, компиляция в двоичный файл, раздача через GPO, скрипт или MDM |
| Правила для отдельных пользователей и групп | нет | есть | нет, политика на всю машину |
| Применение до загрузки системы | нет | нет | есть, через UEFI для подписанных политик |
Практический вывод из таблицы простой. SRP трогать стоит только если вам достался сервер, где он уже настроен и работает: технология не удалена и на Server 2022/2025 живёт, но новое на ней не строят. AppLocker - рабочая лошадка для типового Windows-сервера: настраивается мышкой, понимает пользователей и группы, документирована вдоль и поперёк. App Control жёстче и надёжнее, но и возни с ним больше.
Проверка редакции - первое, что стоит сделать, потому что исторически здесь была ловушка.
На Windows Server ограничений по редакции нет: AppLocker настраивается и применяется и в Standard, и в Datacenter, начиная с Server 2012 R2.
На клиентских Windows раньше требовалась Enterprise: на Pro правила можно было создать, но не применить. После обновления KB 5024351 это ограничение снято - Windows 10 версии 2004 и новее и все Windows 11 применяют политики AppLocker на любой редакции. Если в парке остались машины со старыми сборками или Server 2019 без обновлений, для них правило про Enterprise ещё действует при раздаче через GPO.
App Control for Business по редакциям не гейтится вовсе.
Правила живут в пяти коллекциях, и каждая отвечает за свой тип файлов:
| Коллекция | Расширения | Включена по умолчанию |
|---|---|---|
| Исполняемые файлы | .exe, .com | да |
| Установщики Windows | .msi, .msp, .mst | да |
| Сценарии | .ps1, .bat, .cmd, .vbs, .js | да |
| Упакованные приложения | .appx | да |
| Библиотеки DLL | .dll, .ocx | нет |
Коллекция DLL по умолчанию выключена, и это осознанное решение Microsoft: проверка каждой загружаемой библиотеки заметно бьёт по производительности. Её включают там, где требования к защите высокие и машина одна-две. На терминальном сервере, где сотня пользователей одновременно открывает офисные документы, эффект почувствуют все.
Каждое правило можно назначить конкретной группе безопасности. Бухгалтерии разрешить одно, разработчикам другое, всем остальным третье - на одном и том же сервере.
Здесь и находится развилка, от которой зависит, будете вы сопровождать эти правила или проклинать.
По издателю. Правило опирается на цифровую подпись файла: издатель, имя продукта, имя файла, версия. Приложение обновилось - подпись та же, правило работает дальше. Это единственный вариант, который не разваливается от установки обновлений, и на нём стоит строить основу списка.
По хешу. Считается контрольная сумма конкретного файла. Надёжно, точно и мертво после первого же обновления программы: хеш изменился, запуск запрещён. Годится для неподписанных утилит, которые вы обновляете руками и редко.
По пути. Разрешается всё, что лежит в указанной папке. Настраивается за минуту и ровно настолько же рискованно: если пользователь может писать в разрешённую папку, он положит туда что угодно, и оно запустится. Правило по пути работает только для каталогов, куда у обычного пользователя нет права записи.
Отсюда главная проверка после настройки: пройтись по всем разрешённым путям и убедиться, что обычный пользователь не может в них ничего создать. Пропущенный подкаталог с правом записи внутри C:\Windows или C:\Program Files превращает белый список в декорацию.
Включать запрет сразу на боевом сервере - верный способ остановить работу компании до вечера. Порядок другой.
Сначала создаются правила по умолчанию: AppLocker предлагает готовый набор, который разрешает всё из C:\Windows и C:\Program Files, а администраторам - всё остальное. Это база, поверх которой добавляются правила под ваши приложения.
Дальше - режим только аудита. Политика применяется, но ничего не блокирует: система лишь записывает в журнал, что было бы заблокировано. Пара недель в этом режиме показывает всё, что вы забыли: самописную утилиту бухгалтера, обновлятор драйверов, скрипт из планировщика.
Журналы лежат в «Просмотре событий», в разделе журналов приложений и служб: Microsoft → Windows → AppLocker. Там четыре отдельных журнала по коллекциям правил.
И только когда в аудите перестанут появляться неожиданности, коллекции переключаются в режим применения - лучше по одной, начиная с исполняемых файлов.
Служба Application Identity не запущена. Самая частая причина «настроил, а не работает». AppLocker опирается на службу AppIDSvc, а её тип запуска по умолчанию - ручной с запуском по триггеру. Политика применена, правила на месте, запускается всё подряд.
Отдельная подлость: начиная с Windows 10 эта служба работает как защищённый процесс, и переключить её в автозапуск через оснастку «Службы» больше нельзя - поле неактивно. Делается это командой:
sc.exe config appidsvc start=auto
либо, что правильнее для домена, шаблоном безопасности в той же групповой политике, которая раздаёт правила. Если машин больше одной, второй вариант обязателен - и тогда сначала стоит убедиться, что домен Windows у вас в порядке и политики доезжают до машин.
Забытые сценарии. Исполняемые файлы закрыли, а .ps1, .bat и .cmd остались вне политики - и обход занимает одну строку. Коллекция сценариев включается вместе с исполняемыми файлами, а не когда-нибудь потом.
Легальные программы как инструмент обхода. В самой Windows хватает подписанных Microsoft утилит, которые умеют выполнять чужой код. Правила по умолчанию их разрешают, потому что они лежат в системных каталогах. Полностью эта дыра закрывается только на стороне App Control с блок-листом рекомендованных к запрету файлов; на AppLocker её сужают исключениями для самых известных случаев.
Обновления приложений. Правило по хешу ломается при каждом обновлении, правило по пути - при смене каталога установки. Если в списке много правил по хешу, сопровождение съест больше времени, чем вы сэкономили.
App Control работает не на уровне пользовательского сеанса, а на уровне ядра, и его политику нельзя обойти правами администратора - в этом его главное отличие от AppLocker. Подписанную политику можно закрепить через UEFI, и тогда она применяется ещё до загрузки системы.
Плата - другой способ работы. Политика описывается в XML, компилируется в двоичный файл и раздаётся групповой политикой, скриптом или системой управления. Графической оснастки в комплекте Windows нет. Режим аудита есть и здесь, и начинать так же нужно с него.
Отдельно стоит посмотреть на механизм доверенного установщика (managed installer): система запоминает, какой программой был установлен файл, и разрешает запуск всего, что пришло через ваш инструмент развёртывания. Это снимает основную боль - необходимость описывать правилами каждое обновление.
Разумная схема для компании, которая только начинает: AppLocker на терминальных и файловых серверах, App Control - там, где цена компрометации высока и набор софта стабилен.
Честный раздел, которого обычно нет в статьях про безопасность.
Белый список требует, чтобы набор программ на машине был известен и менялся редко. Терминальный сервер бухгалтерии под это подходит идеально - там же лежит и остальная защита данных на терминальном сервере. Машина разработчика, который каждый день ставит новый инструмент, - нет: вы утонете в заявках «разрешите вот это».
Он требует человека. Не разово настроить, а вести: приходит новая программа - добавляется правило. Если в компании нет никого, кто за это отвечает, через полгода политика будет наполовину отключена «чтобы работало».
И он не заменяет остального. Белый список не закрывает ни перебор паролей, ни непропатченную уязвимость, ни утечку через флешку. Это один слой, и он работает поверх базовых мер: обновлений, разделения учётных записей, правильно настроенного RDP без проброса порта наружу. С этими мерами мы разбирались отдельно в материале о том, как обеспечить безопасность сервера на Windows. К этому же набору относится и шифрование канала до сервера - про защищённое соединение и разбор ошибок сертификата у нас есть отдельный материал.
Если инфраструктура уходит с Windows, механизм никуда не девается - он называется иначе.
В Astra Linux Special Edition роль белого списка играет замкнутая программная среда. Работает она по другому принципу: модуль ядра digsig_verif проверяет встроенную цифровую подпись у исполняемых файлов и модулей, и всё неподписанное доверенным ключом не запускается. Настраивается через графическую панель управления безопасностью или утилитами командной строки из пакета astra-safepolicy. Для сертифицированных установок это штатный механизм, а не дополнение.
Практический смысл для смешанного парка: логика «разрешено только известное» переносится, а вот правила - нет. Это два независимых механизма, и вести придётся оба.
Он не пытается опознать вредоносное. Он запрещает всё, чего нет в списке, и поэтому одинаково останавливает и известный троян, и свежесобранный шифровальщик. Антивирус при этом не отменяется - у него другая работа, включая проверку документов и почты.
На Windows Server 2022 и 2025 механизм присутствует и работает, но Microsoft признала его устаревшим ещё в 2018 году и рекомендует AppLocker или App Control. На клиентской Windows 11 начиная с 22H2 поддержки нет. Новое на SRP не строят.
AppLocker работает на уровне пользовательского сеанса, умеет разные правила для разных групп и настраивается привычной оснасткой. App Control работает на уровне ядра, политику нельзя отключить правами администратора, но она одна на всю машину и описывается в XML.
В девяти случаях из десяти не запущена служба Application Identity: её тип запуска по умолчанию - ручной. Второй по частоте вариант - политика стоит в режиме только аудита.
На Windows Server - нет, AppLocker доступен и в Standard, и в Datacenter. На клиентских машинах ограничение снято обновлением KB 5024351 для Windows 10 версии 2004 и новее и всех Windows 11.
Настройка правил по умолчанию - час. Дальше две-три недели в режиме аудита, чтобы собрать реальный список запускаемого. Основное время уходит на наблюдение, а не на настройку.
Собираете терминальный сервер, на котором будет работать вся бухгалтерия?
Инженеры ITTELO подберут конфигурацию под число пользователей и профиль нагрузки, соберут и протестируют под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
