Белые списки приложений (Application Whitelisting) и WDAC: как внедрить

Белые списки приложений, или application whitelisting, позволяют изменить сам принцип контроля программ в Windows: вместо поиска заведомо опасного ПО организация определяет, какой код считается доверенным и может запускаться. Такой подход помогает ограничить выполнение вредоносных, неизвестных и просто неразрешенных программ.

Разберем, как работает application allowlisting, чем отличаются AppLocker, Windows Defender Application Control (WDAC) и Software Restriction Policies и как внедрить контроль запуска приложений без массовой блокировки рабочих процессов.

Что такое белые списки приложений и зачем они нужны

Application whitelisting, или application allowlisting, — подход к контролю программного обеспечения, при котором запуск разрешается только доверенным приложениям и компонентам.

NIST определяет application whitelist как перечень приложений и их компонентов, авторизованных для использования в организации. Технологии application whitelisting контролируют, какие приложения разрешено выполнять на конкретном устройстве.

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

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

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

Чем белые списки отличаются от черных списков и антивирусов

Классический защитный механизм пытается определить нежелательный объект и заблокировать его. При application whitelisting логика обратная: сначала определяется доверенное множество приложений, а выполнение всего остального ограничивается.

Именно поэтому белые списки приложений и антивирус нельзя считать взаимозаменяемыми технологиями. Антивирус, EDR и другие средства защиты анализируют файлы и поведение программ и помогают обнаруживать вредоносную активность. Application control ограничивает саму возможность выполнения кода, который не соответствует установленной политике.

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

Поэтому allowlisting не заменяет другие средства защиты, а дополняет их.

Преимущества и ограничения подхода

Главное преимущество — сокращение возможностей для запуска произвольного кода. Белые списки приложений помогают:

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

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

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

Обзор инструментов Windows для Application Whitelisting

В современных версиях Windows для application control используются прежде всего AppLocker и App Control for Business — технология, исторически известная как Windows Defender Application Control, или WDAC. Выбор между ними зависит от задач, инфраструктуры и необходимого уровня контроля.

AppLocker — гибкий контроль приложений и пользователей

AppLocker позволяет создавать правила разрешения и запрета запуска на основе свойств файлов и применять их к определенным пользователям и группам. Он поддерживает правила для исполняемых файлов, установщиков Windows, скриптов, DLL и упакованных приложений.

Для идентификации программы можно использовать несколько основных типов правил.

Publisher. Правило строится на информации из цифровой подписи. Можно доверять определенному издателю, продукту, имени файла или диапазону версий.

Path. Разрешение или запрет определяется расположением файла.

File hash. Правило привязывается к конкретному файлу.

AppLocker — один из наиболее распространенных и доступных инструментов для контроля запуска приложений в Windows-среде. Он позволяет разграничивать набор доступного ПО для пользователей и групп, а политики можно централизованно распространять, в том числе с помощью Group Policy.

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

Windows Defender Application Control (WDAC) — более строгий контроль кода

Windows Defender Application Control сегодня развивается Microsoft под названием App Control for Business. Технология позволяет определять политики доверия к приложениям и драйверам и контролировать выполнение кода на устройствах Windows.

Если AppLocker удобен в сценариях, где важно в том числе определить, какие пользователи могут запускать конкретные программы, WDAC ориентирован на более строгий контроль доверенного кода на уровне устройства.

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

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

Software Restriction Policies (SRP) — устаревающий подход

Software Restriction Policies появились раньше AppLocker и также позволяют определять, какое программное обеспечение может выполняться в Windows.

Software Restriction Policies появились раньше AppLocker и также позволяют определять, какое программное обеспечение может выполняться в Windows. Microsoft считает SRP устаревшей технологией начиная с Windows 10 build 1803 и рекомендует использовать для контроля запуска приложений AppLocker или WDAC.

Однако это не означает, что SRP полностью потеряли практическое значение. В инфраструктуре крупных организаций могут годами сохраняться рабочие станции, серверы, специализированное или промышленное оборудование на старых версиях Windows. Причины бывают разными: зависимость от legacy-ПО, требования совместимости, длительный жизненный цикл оборудования или невозможность быстро обновить отдельный сегмент инфраструктуры. В таких средах уже настроенные SRP могут продолжать выполнять свою задачу.

Поэтому SRP сегодня стоит рассматривать прежде всего как инструмент для существующей legacy-инфраструктуры, а не как основу нового проекта application whitelisting. Если операционная система и архитектура инфраструктуры позволяют использовать более современные механизмы, предпочтительнее ориентироваться на AppLocker или WDAC.

Сравнение инструментов: что выбрать

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

Как внедрить Application Whitelisting: пошаговая инструкция

Шаг 1. Аудит установленного ПО и планирование

Начинать внедрение AppLocker или WDAC сразу с запрета запуска программ опасно. Сначала необходимо понять, что реально выполняется на рабочих станциях.

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

Для такого аудита недостаточно просто получить перечень установленного ПО. Важно понимать, какие приложения действительно запускаются, кем и насколько регулярно используются. Для построения такой карты можно использовать специализированные инструменты мониторинга. Например, Staffcop позволяет собирать сведения об установленном ПО и запущенных приложениях и анализировать их использование на рабочих компьютерах. Это помогает выявить фактически используемый набор программ и уже на его основе принимать решения о правилах запуска и ограничениях.

Реклама 16+

Коннект от Контур.Эгиды

Организуйте безопасный и удобный доступ к рабочим ресурсам компании из любой точки мира.

Оставить заявку

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

Программы можно предварительно разделить на четыре категории:

1. системное ПО и компоненты, необходимые для работы операционной системы и инфраструктуры;
2. ПО, необходимое для бизнес-процессов организации — корпоративные и специализированные приложения, которые нужны сотрудникам или отдельным подразделениям для выполнения рабочих задач;
3. заведомо нежелательное ПО;
4. ПО, требующее дополнительной проверки.

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

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

Шаг 2. Выбор инструмента и настройка правил

После инвентаризации можно выбирать механизм application control и формировать правила.

Выбор инструмента зависит от модели угроз и прав пользователей. Для разграничения доступных приложений между пользователями и группами можно использовать AppLocker. Если требуется более жесткий контроль выполнения кода на уровне устройства, стоит рассматривать App Control for Business (ранее WDAC). Эти механизмы можно использовать и совместно.

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

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

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

Шаг 3. Включение режима аудита и анализ логов

Один из главных принципов application whitelisting best practices — не начинать с массовой блокировки.

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

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

Шаг 4. Развертывание и мониторинг

После анализа событий не стоит сразу распространять запрет запуска неразрешенных программ на всю организацию.

Безопаснее двигаться последовательно: тестовая среда → пилотные устройства → отдельное подразделение → несколько типовых групп → основная инфраструктура.

Так ошибка в правиле затронет ограниченное количество пользователей.

Само включение блокировок не завершает внедрение. Необходимо продолжать собирать события application control и отслеживать как ошибочные блокировки, так и попытки запуска неразрешенного ПО.

Шаг 5. Обработка запросов на добавление приложений

После внедрения white list необходимо постоянно поддерживать в актуальном состоянии. Поводом для изменения правил могут стать обновление ПО, появление новых приложений, запросы пользователей или изменение бизнес-процессов.

Поэтому еще на этапе внедрения нужно определить процесс сопровождения белого списка:

• кто может запросить добавление приложения;
• кто подтверждает бизнес-необходимость;
• кто оценивает риски и проверяет источник ПО;
• как вносятся изменения после обновления приложений;
• на какие устройства и группы пользователей распространяется разрешение;
• как часто проводится повторный анализ правил и исключений.

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

Application Whitelisting best practices: как избежать ошибок

Используйте правила на основе издателя и сертификатов

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

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

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

Разделяйте правила по группам пользователей

У разработчика, бухгалтера и администратора разные рабочие задачи. Единый огромный список разрешенных программ для всех сотрудников лишает application allowlisting части смысла.

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

Например, наличие административной утилиты может быть оправданно на компьютере ИТ-специалиста, но не на обычной пользовательской рабочей станции.

Регулярно обновляйте и тестируйте списки

Инфраструктура постоянно меняется: приложения обновляются, появляются новые версии, старое ПО выводится из эксплуатации.

Поэтому белый список нельзя сформировать один раз и считать завершенным. Необходим жизненный цикл политики:

инвентаризация → изменение правил → аудит → тестирование → применение → мониторинг → пересмотр.

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

Внедряйте процесс для временных исключений

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

Лучше предусмотреть отдельный процесс временного разрешения с владельцем, обоснованием и сроком действия.

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

Сторонние решения для Application Whitelisting

Какие задачи могут решать сторонние продукты

Встроенные возможности Windows — не единственный способ контролировать запуск приложений. Такие функции могут входить в системы endpoint management, endpoint security, DLP и другие корпоративные решения.

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

Например, Staffcop поддерживает мониторинг запуска и установки приложений и блокировку запуска программ. В режиме белого списка администратор задает разрешенные приложения, а запуск остальных блокируется.

Это отличается от модели доверия WDAC или набора правил AppLocker, поэтому механически считать такие инструменты взаимозаменяемыми нельзя. Они могут решать пересекающиеся задачи контроля запуска, но делают это разными способами.

Можно ли обойтись встроенными средствами Windows

Во многих случаях — да. Если инфраструктура преимущественно построена на Windows, а у компании уже есть процессы централизованного администрирования, возможностей AppLocker или WDAC может быть достаточно.

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

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

Когда использовать сторонние решения вместо встроенных

Встроенные механизмы application control и инструменты мониторинга могут дополнять друг друга. Например, AppLocker или App Control можно использовать для ограничения запуска ПО, а Staffcop — для контроля того, какие программы фактически устанавливаются и запускаются на рабочих местах.

Такая связка позволяет не только применять правила, но и анализировать реальное использование ПО, выявлять отклонения и получать данные для пересмотра белого списка. Например, можно обнаружить приложение, которое формально разрешено политикой, но используется сотрудником нетипичным образом или не требуется ему для рабочих задач.

При этом сам инструмент мониторинга не заменяет процесс управления белым списком: организации по-прежнему необходимо определить, какое ПО допустимо, кому оно необходимо и как будут пересматриваться правила.

Информационная безопасность бизнеса

Контур.Эгида — сервисы информационной безопасности: уменьшение рисков внутренних угроз и утечек конфиденциальных данных, предотвращение атак злоумышленников.

Оставить заявку