Полное руководство по Applocker для системных администраторов

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

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

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

Я должен сказать вам, что ответ, который я получил на свой вопрос, на самом деле не заставил меня чувствовать себя лучше, но я принял тот факт, что политики ограниченного использования программного обеспечения были совершенно новыми, и предположил, что они будут значительно улучшены в следующей версии. Windows. К моему разочарованию, Microsoft внесла лишь незначительные изменения в политики ограниченного использования программ в Windows Vista и Windows Server 2008. Они добавили новый тип правил, называемых правилами сетевой зоны, и ввели новый уровень безопасности, называемый «Базовый пользователь», но это было в значительной степени степень изменений.

Хорошая новость заключается в том, что в Windows 7 Microsoft наконец-то изменила политику ограниченного использования программ. Эта недавно переработанная функция также была переименована в AppLocker. Не ожидайте, что AppLocker будет таким же всеобъемлющим, как сторонние решения для блокировки настольных компьютеров, но он немного лучше, чем политики ограничения программного обеспечения.

Недостатки политики ограниченного использования программ

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

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

Правила сертификата

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

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

Хэш-правила

Второй тип правил, поддерживаемых политиками ограниченного использования программ, — это хеш-правила. Идея состоит в том, что Windows может создать математический хэш исполняемых файлов и использовать этот хэш для уникальной идентификации приложения. Я должен признать, что хеш-правила были хорошей идеей в то время, когда они были впервые введены, но сегодня они непрактичны. Любой, кто отвечает за управление матчами в организации, знает, что нас забрасывают патчами с угрожающей скоростью. Каждый раз, когда вы исправляете приложение, хеш изменяется для любых файлов, которые были заменены, что делает ранее существовавшие правила хеширования устаревшими.

Правила пути

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

Правила интернет-зоны

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

Во-первых, правила зоны Интернета применяются только к файлам MSI (пакетам установщика Windows). Другая проблема заключается в том, что правила зоны Интернета применяются только во время загрузки файла. Это означает, что если пользователь загружает ZIP-файл, содержащий приложение, то правило зоны Интернета не будет препятствовать установке этого приложения.

Правила сетевой зоны

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

Суть проблемы

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

Начало работы с Applocker

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

Совместимость

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

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

Ограничения

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

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

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

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

Основные стратегии AppLocker

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

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

Я хочу сказать, что существует гораздо больше приложений, которые вы не хотите, чтобы пользователи запускали, чем приложений, которые пользователи должны использовать. В этом случае гораздо проще предоставить Windows белый список разрешенных приложений, чем блокировать каждое отдельное приложение, запуск которого вы хотите предотвратить. Это философия Microsoft, лежащая в основе того, как работают правила AppLocker.

Это подводит меня к первой основной концепции правил AppLocker. Даже если вы больше ничего не помните из всей этой серии, пожалуйста, помните об этом. Правила AppLocker организованы в коллекции (о которых я расскажу позже). Хотя можно создать явный запрет, правила AppLocker обычно следует рассматривать как механизм предоставления разрешения на что-либо (помните, что легче одобрить программное обеспечение, которое вы хотите разрешить, чем запретить программное обеспечение, которое вы хотите ограничить). ). Теперь наступает действительно важная часть. Если вы создаете хотя бы одно единственное правило в наборе правил, Windows автоматически предполагает, что вы хотите предотвратить выполнение всех остальных правил.

Это чрезвычайно важная концепция, потому что давайте предположим на мгновение, что вы хотите, чтобы ваши пользователи могли запускать Microsoft Office и Internet Explorer, поэтому вы создаете правило, позволяющее им это делать. Тем самым вы лишили пользователя права запускать что-либо еще, включая операционную систему Windows. Хотите верьте, хотите нет, но легко случайно заблокировать пользователя от Windows, неправильно создав правила AppLocker. Это то, что я собираюсь рассмотреть намного позже в статье.

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

Учитывая то, как работает AppLocker, мы не можем просто запретить всем доступ к инструментам администрирования. Вместо этого нам пришлось бы предоставить всем доступ к системным файлам Windows. Оттуда мы могли бы добавить отказ для инструментов администрирования, который применяется к определенной группе пользователей (всем, кроме персонала службы поддержки). Вам не нужно ничего делать для сотрудников службы поддержки, потому что у них есть доступ к административным инструментам, потому что вы предоставили всем доступ к системным файлам Windows.

Открытие консоли AppLocker

Вы можете получить доступ к AppLocker через редактор объектов групповой политики. Он находится по адресу: Конфигурация компьютера | Параметры Windows | Настройки безопасности | Политики управления приложениями | AppLocker. Вы также можете получить доступ к AppLocker, выбрав ярлык «Локальная политика безопасности» в меню «Администрирование». При просмотре локальной политики безопасности AppLocker находится по адресу: Параметры безопасности | Политики управления приложениями | AppLocker. Вы можете увидеть, как выглядит контейнер AppLocker на рисунке 1.

Как видно на рисунке, консоль разделена на три секции. В разделе «Начало работы» отображается предупреждающее сообщение, указывающее, что после того, как вы начнете создавать правила AppLocker, будет разрешено запускать только те приложения, которые определены этими правилами. Также есть несколько ссылок, по которым можно узнать больше о AppLocker или определить, к каким редакциям правил Windows AppLocker применяются.

Раздел «Настройка применения правил»

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

Если вы просто экспериментируете с AppLocker на одном ПК, обычно лучше всего использовать диспетчер управления службами, чтобы установить для типа запуска службы идентификации приложений значение «Автоматически», а затем запустить службу. Если вы планируете использовать AppLocker со всеми рабочими столами Windows 7, то лучше включить службу идентификации приложений на уровне групповой политики. Системные службы находятся в разделе Конфигурация компьютера | Параметры Windows | Настройки безопасности | Системные службы в дереве групповой политики.

Если вы снова посмотрите на рис. 1, то заметите, что раздел Configure Rule Enforcement консоли AppLocker содержит ссылку Configure Rule Enforcement. Щелкнув по этой ссылке, вы попадете на лист свойств AppLocker, показанный на рис. 3.

Как видно на рисунке выше, правила AppLocker по умолчанию не настроены. Не позволяйте этому обмануть вас. Согласно документации Windows 7, «если принудительное применение не настроено, но правила присутствуют в соответствующем наборе правил, эти правила применяются».

Имейте в виду, что после того, как вы начнете создавать правила, любые приложения, которые явно не определены этими правилами, больше не смогут запускаться. Согласно тексту из документации Windows 7, простое создание правила приводит к его принудительному применению, даже если вы не установили флажок «Настроено» для набора правил.

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

Если набор правил установлен в режим «Только аудит», правила в этом наборе правил не применяются. Вместо этого всякий раз, когда пользователь запускает приложение, на которое могло бы повлиять правило в коллекции, информация о правиле и приложении записывается в журнал событий AppLocker.

Есть две основные причины, по которым я рекомендую установить для каждого набора правил значение «Только аудит» еще до того, как вы начнете создавать какие-либо правила. Во-первых, это мера безопасности. Пока AppLocker работает в режиме аудита, вам не нужно беспокоиться о том, чтобы заблокировать себя в системе. Во-вторых, аудит ваших правил позволяет проверить, насколько хорошо они работают. Изучив журналы аудита, вы можете обнаружить, что вам нужно пересмотреть свои правила, потому что приложение, которое должно быть запрещено, разрешено для запуска. С другой стороны, вы можете обнаружить, что ваши правила слишком строгие и влияют на важные приложения. Аудит позволяет вам узнать, как именно будут вести себя ваши правила, но без потенциальных неблагоприятных побочных эффектов.

Расширенные свойства AppLocker

Если вы снова посмотрите на рис. 3, то заметите, что лист свойств AppLocker содержит вкладку «Дополнительно». Если вы выберете эту вкладку, вам будет предоставлена возможность включить коллекцию правил DLL, как показано на рисунке 4.

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

Если вы решите включить набор правил DLL, вы должны одобрить каждую отдельную DLL, используемую авторизованными приложениями в вашей системе. Это, как правило, очень большая работа, и легко случайно пропустить DLL. Если вы забудете утвердить DLL-файл, приложения, зависящие от этой DLL, не будут работать правильно.

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

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

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

Правила по умолчанию

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

Как ни странно, правила по умолчанию не создаются по умолчанию. Чтобы создать правила по умолчанию, откройте редактор объектов групповой политики и перейдите в дереве консоли к Конфигурация компьютера | Параметры Windows | Настройки безопасности | Политики управления приложениями | AppLocker | Исполняемые правила. Теперь щелкните правой кнопкой мыши контейнер «Исполняемые правила» и выберите команду «Создать правила по умолчанию» в появившемся контекстном меню.

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

Обзор правил по умолчанию

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

Если вы посмотрите на рис. 5, то увидите, что Windows создает три исполняемых правила по умолчанию. Первое правило разрешает всем запускать все файлы, расположенные в папке Program Files. Второе правило разрешает всем запускать все файлы, находящиеся в папке Windows. Третье правило позволяет учетной записи BUILTINAdministrator запускать любой файл в системе.

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

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

По умолчанию пользователи имеют полные права на чтение/запись/создание каталога C:WindowsTemp. Когда создаются исполняемые правила по умолчанию, пользователю автоматически предоставляется разрешение на выполнение приложений, находящихся в каталоге C:WindowsTemp, поскольку он находится ниже каталога C:Windows. Это означает, что пользователь потенциально может установить приложение в каталог Temp и запустить его.

Прежде чем я покажу вам, как изменить правила по умолчанию, я хочу воспользоваться моментом и показать вам правила установщика Windows по умолчанию. Как и в случае с правилами исполняемых файлов по умолчанию, Windows создала три правила установщика Windows по умолчанию, которые вы можете видеть на рисунке 6.

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

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

Последнее из правил установщика Windows позволяет учетной записи BUILTINAdministrator запускать все файлы установщика Windows. Как и раньше, вы должны оставить это конкретное правило в покое, потому что учетная запись BUILTINAdministrator нуждается в этих разрешениях.

Подготовка к изменению правил по умолчанию

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

Я объяснил, что правила для исполняемых файлов относятся к исполняемым файлам, но, хотите верьте, хотите нет, в AppLocker есть очень конкретное определение исполняемых файлов. AppLocker определяет исполняемые файлы как файлы.EXE или.COM. Несмотря на то, что.BAT,.PIF и некоторые другие форматы технически исполняемые, на них не распространяются правила для исполняемых файлов по умолчанию.

Точно так же, как в AppLocker есть специальное определение для исполняемых файлов, оно также имеет конкретное определение для файлов установщика Windows. Файлы установщика Windows определяются как файлы.MSI и.MSP.

Анатомия правила

Ключом к созданию нового правила AppLocker или изменению существующего правила является понимание того, какие ключевые компоненты составляют правило, и как эти компоненты работают вместе. После этого вы можете изменить существующее правило, просто щелкнув правило правой кнопкой мыши и выбрав команду «Свойства» в появившемся контекстном меню. Оттуда вы можете внести нужные изменения и нажать OK. Точно так же вы можете создать новое правило AppLocker, щелкнув правой кнопкой мыши категорию правила и выбрав команду «Создать новое правило» в контекстном меню.

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

Если вы посмотрите на рисунок 7 ниже, вы увидите лист свойств, который используется всякий раз, когда вы изменяете существующее правило. Первые два параметра на вкладке «Общие» листа свойств позволяют назначить имя правилу и ввести необязательное описание правила. Хотя вводить описание необязательно, я рекомендую быть как можно более описательным, потому что по мере того, как вы начинаете накапливать правила AppLocker, может быть сложно вспомнить, что делает каждое правило.

Следующий набор параметров на вкладке «Общие» позволяет вам контролировать, к кому будет применяться правило, и разрешать ли этому пользователю или группе запускать указанные приложения. Например, правило, показанное на рисунке выше, позволяет членам встроенной группы «Администраторы» запускать определенные приложения. Чтобы увидеть, какие приложения разрешает запускать эта группа, мы должны переключиться на вкладку «Путь», как показано на рисунке 8.

Лист свойств, показанный на рисунке выше, включает только вкладку «Путь», поскольку она относится к правилу пути. Если бы это было правилом издателя или правилом хэширования файлов, название вкладки было бы другим. В любом случае, эта вкладка устанавливает условия для правила. Например, на рисунке выше путь обозначен как *.*, что означает любой путь. Следовательно, условием, которое активирует это правило, является, по сути, «любой путь». Однако, как вы можете видеть на рисунке, мы могли бы так же легко указать более конкретный путь или даже отдельный файл.

Последняя вкладка на странице свойств — это вкладка «Исключения». Как следует из названия, вкладка исключений, показанная на рис. 9, позволяет делать исключения из правил. Исключение может состоять из правила Publisher, File Hash или Path. Например, правило AppLocker, которое я вам показывал, позволяет администраторам запускать любой файл установщика Windows, независимо от его местоположения. Если бы мы хотели создать исключение из правила, мы могли бы настроить правило так, чтобы администратор мог запускать любой файл установщика Windows, если он не находится в папке C:Program FilesGames. Другим вариантом может быть исключение, основанное на хэше файла установочного пакета для Grand Theft Auto. Таким образом, администратор может установить почти все, что ему нужно, но не сможет установить Grand Theft Auto.

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

Я знаю, что это звучит запутанно, поэтому позвольте мне привести вам пример. Предположим, вы по какой-то причине хотели заблокировать доступ ко всей папке Program Files (на самом деле не блокируйте эту папку, это просто пример), но вам нужно, чтобы пользователи могли запускать приложения, расположенные в Program Files Майкрософт. Вы можете достичь своей цели, создав правило, которое запрещает доступ к папке Program Files, но указывает Program FilesMicrosoft как исключение из правила.

Автоматическое создание правил AppLocker

Как видите, правила AppLocker не очень сложные. Тем не менее, как только вы начнете создавать правила AppLocker, вам придется авторизовать любое приложение, которое вы хотите разрешить пользователям запускать. Если вы пренебрежете авторизацией приложения, пользователи не смогут его запустить. Я хочу сказать, что хотя Microsoft упрощает создание правила AppLocker, создание полного набора правил AppLocker может потребовать много работы. К счастью, помощь есть.

AppLocker содержит механизм автоматической генерации необходимых правил. Чтобы получить доступ к этой функции, просто щелкните правой кнопкой мыши один из контейнеров правил и выберите команду «Автоматически создавать правила» в контекстном меню. Когда вы это сделаете, Windows запустит мастер, который запросит у вас имя пути к файлу для анализа, группу безопасности, к которой должны применяться вновь созданные правила, и имя, которое нужно назначить набору правил. Вы можете увидеть, как выглядит этот мастер на рисунке 10.

Когда вы нажимаете «Далее», Windows задает вам несколько вопросов о том, как должны быть созданы правила. По умолчанию Windows создает правила издателя для любых подписанных приложений и правила хэширования файлов для всех остальных приложений. Это просто поведение по умолчанию. У вас есть возможность создавать другие типы правил.

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

Вывод

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