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

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

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

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

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

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

  1. Выберите в оснастке «Управление групповой политикой» (Group Policy Management) указанный ранее объект групповой политики и откройте для него редактор управления групповыми политиками;
  2. Находясь в оснастке редактора управления групповыми политиками, переходим к узлу Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Политики управления приложениями\AppLocker» (Computer Configuration\Policies\Windows Settings\Security Settings\Application Control Policies\AppLocker), а затем к узлу, в котором будут автоматически создаваться правила, например, в нашем случае это будет узел исполняемых файлов. Далее вызываем контекстное меню и из него, как видно на следующей иллюстрации, выбираем команду «Создать правила автоматически» (Automatically Generate Rules):

    Рис. 1. Создание автоматических правил AppLocker

  3. В отобразившемся диалоговом окне на первой странице мастера автоматического создания исполняемых правил, то есть на странице «Папки и разрешения» (Folder and Permissions), вам предоставляется возможность выбора групп безопасности и исходной папки, в которой будет производиться поиск исполняемых файлов для установленных приложений. Так как в настоящем примере выполняется создание правил для установленного и используемого программного обеспечения в тестовой среде, никакие группы выбирать не будем, однако, в случае необходимости, как видно на следующей иллюстрации, на данной странице мастера вам предоставляется такая возможность. С папкой, содержащей анализируемые файлы, все интереснее. По умолчанию мастер предлагает выбрать папку «Program Files» (и ее обязательно следует выбирать), однако в 64-разрядных операционных системах многие приложения инсталлируются не только в указанную по умолчанию папку, а еще и в папку «Program files (x86)», и при повторном создании автоматических правил обязательно нужно будет указать эту папку. Но об этом немного позже. На этой странице мастера также можно обнаружить текстовое поле имени, определяющего набор правил. Это поле предназначено для последующей идентификации созданных правил, а если говорить точнее, то по завершению автоматического создания правил указанное в этом текстовом поле имя будет задаваться в качестве префикса имени для каждого созданного таким образом правила. На данном этапе, так как никаких изменений вносить не требуется, следует просто нажать на кнопку «Далее»;

    Рис. 2. Страница «папки и разрешения» мастера автоматического создания правил

  4. Следующая страница мастера, то есть страница «Параметры правил» (Rule Preferences), отвечает за типы и условия создаваемых правил. С условиями, используемыми в создаваемых правилах, вы уже знакомы. Как можно заметить на следующей иллюстрации, при автоматическом создании правил по умолчанию указано, что должны создаваться правила издателя, однако если цифровая подпись для какого-либо приложения не будет найдена, вам предоставляется выбор между созданием правил для хэша либо правил для пути. Правила для пути могут быть опасны тем, что они не будут применяться в том случае, если на пользовательском компьютере приложение установлено в другом расположении, а при создании правила хэша, в свою очередь, нужно помнить о том, что при выходе обновления для программы такое правило обязательно нужно будет обновить. В любом случае, лучше всего останавливаться на правиле хэша, так как, например, в случае с правилами для папки «Program Files (x86)», к которой еще вернемся, расположение исполняемых файлов может отличаться для компьютеров, которые оснащены 32-разрядной операционной системой. Для уменьшения количества создаваемых правил их можно группировать, причем эта опция установлена по умолчанию. Рекомендую ее в таком положении и оставить, и нажать на кнопку «Далее». Сразу после нажатия на эту кнопку начнет выполняться процесс создания правил, и за этим процессом, как видно на следующей иллюстрации, придется наблюдать несколько секунд;

    Рис. 3. Страница «Параметры правил» мастера автоматического создания правил

  5. Страница «Проверка правил» (Review Rules) позволяет вам проанализировать создаваемые мастером правила. Здесь можно увидеть количество созданных правил для издателя и, в моем случае, количество таких же правил для хэшей файлов. При переходе по ссылке «Просмотр проанализированных файлов» (Review files that were analyzed) вы можете просмотреть перечень проанализированных мастером исполняемых файлов из папки %ProgramFiles%. Как можно заметить на очередной иллюстрации, отобразившееся диалоговое окно дает возможность просматривать имена файлов, их издателя, путь к папке и, таким образом, если вы помните, какие у вас приложения были проинсталлированы, можно сразу прикинуть, для какой программы будет создаваться правило хэша. При желании вы можете на этом этапе отказаться от создания того или иного правила, просто сняв флажок около ненужного имени файла. Перейдя по ссылке «Просмотреть автоматически создаваемые правила» (View rules that will be automatically created), вы сможете узнать, какие правила сейчас будут созданы (этот диалог вы увидите на шестой иллюстрации). Находясь в одноименном диалоговом окне вы еще раз сможете убедиться в том, какой тип правила был сгенерирован для конкретного программного продукта. Как видно на следующей иллюстрации, у меня сейчас будет создано 56 правил, сорок из которых будут правилами издателя, а остальные 16 – правилами для хэшей:

    Рис. 4. Страница «Проверка правил» и диалоговое окно просмотра проанализированных файлов мастера автоматического создания правил

    Если же при анализе исполняемых файлов возникают какие-либо ошибки (например, у мастера не получается считать данные из каких-то конкретных папок), в нижней части этой страницы мастера вы сможете просмотреть предупреждающее сообщение и, перейдя по ссылке «Просмотреть файлы и папки с ошибками», локализовать такие папки. Например, часто можно встретить такое сообщение при попытке анализа папки «C:\Program Files\Windows NT\Стандартные» в русскоязычной версии операционной системы. После того как вы ознакомитесь с создаваемыми правилами, можно нажимать на кнопку «Создать» (Create). Мастер автоматически будет закрыт, а правила, естественно, будут добавлены в область сведений выбранной коллекции (в нашем случае – коллекции исполняемых правил). Диалоговое окно «Просмотреть файлы и папки с ошибками» можно обнаружить ниже:

    Рис. 5. Диалоговое окно с ошибками во время анализа

После этого, так как в данном примере все действия выполняются на 64-разрядной операционной системе, следует повторно открыть мастер автоматического создания правил и еще раз создать правила для файлов, но уже из папки «Program Files (x86)». Следовательно, вызываем еще раз мастер. Здесь на первой странице нужно будет изменить указанную по умолчанию папку на «Program Files (x86)», а на второй странице, то есть на странице «Параметры правил», нужно оставить установленные по умолчанию параметры без изменений. С этой папкой все будет намного серьезнее, так как большая часть устанавливаемого программного обеспечения, как правило, 32-разрядная. Здесь же находятся компоненты Windows Live, продукты Microsoft Office, антивирусные продукты, браузеры и многое другое. Например, в моем случае было сгенерировано целых 156 правил, 75 из которых для издателя, а 81 – для хэшей. Как я отмечал ранее, на следующей иллюстрации вы увидите диалоговое окно «Просмотреть автоматически создаваемые правила» (View rules that will be automatically created) для правил, которые будут созданы специально для папки «Program Files (x86)»:

Рис. 6. Диалоговое окно просмотра автоматически создаваемых правил для «Program Files (x86)»

Не стоит забывать еще об одном моменте. Уже давно в операционных системах Windows существует такое понятия, как пользовательский и административный маркеры доступа. И если приложению нужно постоянно обращаться к своей базе данных или изменять свои файлы, нужно помещать такие файлы не в папки %ProgramFiles%, а в папку с пользовательскими профилями (чаще всего, AppData\Local). По этой причине, существует целый ряд программных продуктов, которые инсталлируются именно в это расположение. Следовательно, последняя папка, в которую могут инсталлироваться приложения, это папка пользовательских профилей. Значит, нужно еще раз вызвать мастер автоматически создаваемых правил, выбрать на этот раз папку «Users» и прогнать мастер в последний раз. Между прочим, в этом случае нельзя будет выбрать правила для пути.

В конечном счете, у вас автоматически будет создано множество правил, разрешающих запускать установленные приложения. Однако стоит обратить внимание и на то, что при любых раскладах у вас также будет сгенерировано много всякого "мусора", от которого следует избавиться. Следовательно, от вас потребуется пересмотреть созданные правила и удалить то, чего, по вашему мнению, не должно находиться в списке. Удалять правила проще простого. Для этого просто выделите удаляемое правило, а затем нажмите на клавишу «Delete» и в диалоговом окне предупреждения согласитесь с предложенными действиями. К сожалению, оснастка редактора управления групповыми политиками не предусматривает какой-либо строки состояния с итоговым количеством созданных правил, поэтому, в случае необходимости, вы можете либо пересчитать такие правила вручную, либо экспортировать список в *.txt или *.csv-файл.

Например, после удаления лишних правил на моей тестовой машине осталось 118 автоматически сгенерированных правил AppLocker.

Заключение

В этой статье мы с вами продолжили рассматривать такую технологию, как AppLocker. Рассмотрен метод, позволяющий упростить и автоматизировать процесс создания правил AppLocker средствами автоматического создания правил на примере правил для издателя. Вы узнали о самом процессе создания таких правил и о средствах, позволяющих регулировать количество правил, создаваемых в автоматическом режиме. Были описаны некоторые хитрости создания таких правил, и вы узнали о том, почему нецелесообразно использовать такой метод создания правил только с одним расположением (например, в случае с 64-разрядными операционными системами). В следующей статье этого цикла мы с вами копнем еще глубже, и вы узнаете об использовании аудита для отслеживания используемых продуктов, создания списков приложений и обо многом другом.

Реклама