Applocker windows server 2012 r2

Hi all,

For this post, lets go through a very simple step on how to configure a very basic Applocker in Windows Server 2012 R2…

So, what is AppLocker?

AppLocker, which was introduced in the Windows 7 operating system and Windows Server 2008 R2, is a security setting feature that controls which applications users are allowed to run. 

AppLocker provides administrators a variety of methods for determining quickly and concisely the identity of applications that they may want to restrict, or to which they may want to permit access.

You apply AppLocker through Group Policy to computer objects within an OU. You can also apply Individual AppLocker rules to individual AD DS users or groups.

That’s just a plain explanation about AppLocker, now let try do the basic configuration…

For this demo as usual, I used my existing Domain Server which is DC01.comsys.local and my Windows 8 Client (Surface01.comsys.local), what I going to do is very simple step where as I want implement AppLocker to restrict non-standard applications from running such as .bat file….

Lets get started…..

1 –  1st, just make sure you transfer any PC / Client to specific Computer OU, so that we know only PC / Client listed in the OU is effected to AppLocker policy, in my Demo, I already transferred my Surface01.comsys.local into ComSystem Laptop OU…

2 – Next, on the Domain Server, open Group Policy Management…

3 – In the GPMC, double click Forests: Comsys.local, expend until you get Group Policy Objects then right click and then click New…

4 – In New GPO box, type ComSystem Software Control GPO, and then click OK…

5 – Next, right click ComSystem Software Control GPO, and then click Edit…

6 – Once the Group Policy Management Editor open, double click Computer Configuration, expand Policies, expand Windows Settings, expand Security Settings, expand Application Control Policies, and then expand AppLocker…

7 – Under AppLocker, right-click Executable Rules, and then click Create Default Rules, you can repeat the previous step for Windows Installer Rules, Script Rules, and Packaged app Rules…

8 – once you completed Create Default Rules, click AppLocker, and then in the right pane, click Configure rule enforcement..

9 – Next, In the AppLocker Properties box, under Executable rules, select the Configured check box, and then from the drop-down menu, select Audit only, for this demo, I also check Windows Installer Rules, Script Rules and Packaged app Rules and then click OK…

10 – Next, In the Group Policy Management Editor, go to System Services, and then double-click Application Identity, click Define this policy setting, under Select service startup mode, click Automatic, and then click OK…

11 – Next, In the GPMC, right-click ComSystem Laptop OU, and then click Link an Existing GPO…

12 – In the Select GPO window, in Group Policy Objects list, click ComSystem Software Control GPO, and then click OK…

13 – Next, log in to your Windows 8 client, mine will be Surface01.comsys.local, open Command Prompt and type gpupdate /boot /force then Enter… then type gpresult /r to check the result of the command and ensure that Comsystem Software Control GPO is displayed under Computer Settings, Applied Group Policy Objects…

14 – Next, still on the Windows 8 client, on my Windows 8 desktop, I had 1 batch file call Comsystem, this is actually a .bat script and the function is to clear all event viewer log files.. lets try if we can run the this batch file by execute the file…

15 – Look like my batch file can run and now open your Windows 8 Event Viewer and lets see what is the information available in Event Viewer…

** In the Event Viewer window, under MSI and Scripts, you will see there are few event log 8005 that contains the following text: %OSDRIVE%\USERS\ADMINISTRATOR\DESKTOP\COMSYSTEM.BAT was allowed to run… meaning we still can execute the batch file but with Event Information.. so now lets block this batch file so that it cannot be run anymore…

16 – On the Domain Server, open ComSystem Software Control GPO and browse to Computer Configuration/Policies/Windows Settings /Security Settings/Application Control Policies/AppLocker, click Script Rules and then on the right pane, double click Allow, on the Allow Properties box, click Deny and click OK to proceed, repeat the step again for the next Allow…

17 – Next, on the Window 8 client, in the command prompt, type gpupdate /boot /force and press Enter…

18 – Next, still in the command prompt, access to where you keep the batch file, in my case I put in on my desktop, so I type cd desktop, and then type the batch file filename (compsystem) and press Enter, you should get and error stated “This program is blocked by group policy.”

19 – our last step, open Event Viewer on the Windows 8 client, and you should see Event ID 8007 which error stated %OSDRIVE%\USERS\ADMINISTRATOR\DESKTOP\COMSYSTEM.BAT was prevented from running…

Блокировка установки/запуска приложений с помощью AppLocker

Рассмотрим ситуацию: У Вас есть «терминальный» сервер, на котором сидят люди с тонких клиентов. Мы для них все настроили, в том числе и браузер, и хотим, чтобы они все пользовались 1 браузером. Но они начинают ставить себе Хром, Яндекс, и упаси Боже — Амиго… А они ставятся не в \Program Files, а в профиль пользователю…

В данной статье рассмотрим, как же можно стандартными средствами Windows запретить пользователю устанавливать приложения, которые ставятся в папку с профилем пользователя, такие как Yandex браузер, Амиго, спутник Mail и т.п.

Для начала идем в «Панель управления» во вкладку «Администрирование»

Открываем «Службы» и находим службу «Удостоверение приложения»

Открываем свойства данной службы

По «умолчанию» она остановлена и стоит «Запуск — вручную»

Нам необходимо установить «Запуск — автоматически» и нажать кнопку «Запустить»

Теперь снова возвращаемся в «Администрирование» и открываем «Локальная политика безопасности»

В открывшемся окне идем в «Политики управления приложениями -> AppLocker -> Исполняемые правила»

У Вас «по умолчанию» там будет пусто

Справа в свободном месте нажимаем правой кнопкой мыши и выбираем «Создать правило…»

Нас приветствует «Мастер создания новых правил», Нажимаем «Далее»

Выбираем, что мы хотим сделать, разрешить или запретить. Выбираем «Запретить«.

Далее можем оставить по умолчанию «Все», или выбрать конкретную группу или пользователя.

После нажимаем «Далее»

В данном окне есть несколько типов правил, я пользуюсь правилом «Издатель» и нажимаем «Далее»

Тут выбираем файл, установщик которого мы хотим запретить

Для примера я выбрал установщик Яндекс.Браузера

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

После того, как выбрали подходящий Вам вариант — нажимаем «Далее»

Тут можно добавить исключение. Я им не пользовался.

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

Теперь нам осталось только дать имя нашему правилу и его описание (не обязательно). После чего нажимаем кнопку «Создать»

Все! Наше правило готово. Чтобы оно немедленно вступило в силу — предлагаю обновить правила политики для ПК и Пользователя.

Для этого открываем командную строку (пуск -> выполнить -> cmd или PowerShell) и пишем gpupdate /force

Дожидаемся обновления политик и можем тестировать.

Так как я применял политику только на группу «Пользователи домена», на меня она не распространяется, но если запустить установку Яндекс.Браузера от имени обычного пользователя, то мы увидим вот такую ошибку:

Источник

Прелести технологии AppLocker. Часть 5

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

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

Основных сценариев применения политики AppLocker

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

1. Учет приложений. Смотрите, какая может возникнуть ситуация. Возможно, вам нужно будет смоделировать и применить специфическую политику, предназначенную для, так называемой, стандартизации программного обеспечения, используемого в каждом подразделении компании. Следовательно, перед вами может встать необходимость получения данных фактического использования программных продуктов. Или же, например, в компании может внедряться новая политика безопасности, на основании которой должны определиться используемые в компании программные продукты. В связи с этим вы должны знать, на каких компьютерах и в какое время используются те или иные проинсталлированные программы. Все это реально реализовать средствами лишь одного AppLocker-а. Функциональные возможности данной технологии предусматривают применение своих политик исключительно в режиме аудита, при помощи которого вы можете фиксировать все действия, связанные с доступом к приложениям в журналы событий. Даже, если говорить точнее, то фиксировать это все будете не вы, а сбор данных производится автоматически средствами AppLocker, а вам уже, в свою очередь, потом нужно будет просто проанализировать полученные результаты;
2. Соответствие лицензиям. В целях обеспечения исключения проблем с юридической точки зрения, в компании может быть жестко установлено (да и должно так быть, по большому счету) правило использования исключительно лицензионных программных продуктов. Поэтому вы должны определять нелицензионные продукты и исключать возможность использования такового программного обеспечения своим пользователям. Другой случай: лицензия на используемый продукт может быть отозвана, либо просто срок ее действия может истечь, и вам в таком случае следует позаботиться о том, чтобы пользователи более не использовали такой продукт. И вот, ввиду того, что AppLocker позволяет вести учет приложений, вы тем самым можете определить программные продукты, соответствующие лицензионным соглашениям и согласно этим соглашениям ограничить их использование должным образом. Помимо этого, вам предоставляется возможность упразднить использование нелицензионных продуктов;
3. Защита от нежелательных программ. С каждым днем выходят новые программные продукты. Обычный пользователь вряд ли будет задумываться над тем, можно ли доверять этому приложению, и не было ли оно специально создано злоумышленником для хищения данных. Следовательно, ввиду того, что за наличием вредоносных программных продуктов на клиентских компьютерах необходимо следить именно вам, вы должны быть уверены в том, что с легкостью можете устранить эту проблему. Как я уже писал в предыдущих статьях этого цикла, благодаря мощным возможностям AppLocker вы можете создавать исключения из разрешающих правил согласно условиям спланированных для групп ваших пользователей. Однако тут нужно помнить, что если такое приложение не было указано явным образом по его издателю, пути установки или хэшу файла, попытка выполнения такого приложения однозначно завершается неудачей;
4. Улучшение управляемости. Всегда может возникнуть такая ситуация, когда ввиду каких-либо причин определенное приложение может резко прекратить поддерживаться организацией. Скажем, нашли лучшую альтернативу или еще что-то. Поэтому, вам нужно будет запретить пользователям работать с такой программой. Другой случай: для приложения выходит обновление и его версионность изменяется. Вам нужно быстро среагировать и разрешить его пилотное использование только определенной группе пользователей. Или, например, для определённых программных продуктов доступ должен быть только у небольшой группы пользователей, а остальные попросту не должны запускать такие программы. Как вы прекрасно знаете, настроенные политики ограничений AppLocker всегда можно редактировать и развертывать средствами групповой политики, что считается самым удобным средством централизованного управления настройками рабочих станций. Между прочим, можно использовать политики AppLocker в сочетании с политиками ограниченного использования программ, что позволяет обеспечить управление приложениями оптимальным образом. Для лучшего управления изменениями в политике приложений, вы всегда можете изменить существующие политики и протестировать соответствие их работы с ожидаемыми результатами;
5. Стандартизация программного обеспечения в организации. Во многих организациях можно найти таких сотрудников, которые совместно используют один компьютер. Нет ничего странного, даже в том, что они могут использовать различный набор программных продуктов для выполнения своих должностных обязанностей. Следовательно, перед вами может встать задача, связанная с предоставлением отдельному пользователю или, скажем, небольшой группе пользователей, доступа к определенному приложению, однако, доступ к которому должен быть запрещен другим пользователям. В конце концов, вам может понадобиться управлять доступом к конфиденциальным данным через использование приложений, что также является важной задачей. Именно благодаря технологии AppLocker, вы можете настроить политики таким образом, чтобы разрешить выполнение только поддерживаемых или утвержденных приложений на определенных компьютерах. Эта возможность обеспечивает более единообразное развертывание приложений.

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

Так что же нам дает аудит и как его настраивать?

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

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

Между прочим, среди всех правил, которые создаются по умолчанию, также присутствует правило, позволяющее запускать локальным администраторам любые файлы. Его нужно удалить, не забудьте. Посмотрим еще раз на сгенерированные правила. Более того, в предыдущей статье автоматически было создано много правил AppLocker. Они должны распространяться на приложения, которые установлены в папки %ProgramFiles%. По этой причине сейчас просто необходимо удалить еще одно правило, и я хотел бы объяснить почему. Ранее были созданы правила по умолчанию, а после этого при автоматическом создании правил AppLocker была выбрана папка Program Files. Следовательно, сейчас в коллекции Исполняемых правил можно обнаружить одно постороннее правило. Смотрите, при создании правил по умолчанию добавляется правило пути, которое разрешает выполнение любого EXE-файла во всей папке Program Files. Как я уже упоминал, это правило добавляется по той причине, чтобы пользователям было разрешено выполнение любых приложений из этой папки. Ввиду того, что это правило уже отчасти дублируется теми правилами, которые автоматически были созданы ранее, следует это правило удалить, чтобы обеспечить выполнение более конкретной политики. Имя этого правила по умолчанию — (Правило по умолчанию) Правило Microsoft Windows Program Files. Следовательно, удаляем его. Теперь можно переходить к настройке аудита и анализу собранных событий.

Настройка аудита правил AppLocker и анализ собранных данных

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

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

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

Теперь осталось настроить политики исполняемых правил AppLocker только для аудита. Для этого в редакторе управления групповыми политиками перейдите к узлу «AppLocker», вызовите контекстное меню и выберите опцию «Свойства» (Properties). В отобразившемся диалоговом окне свойств AppLocker, находясь на вкладке «Применение» (Enforcement) от вас требуется установить флажок «Настроено» (Configured) напротив тех коллекций правил, для которых следует проводить аудит (как в данном примере, это выполняется только для коллекции правил исполняемых файлов), а затем из соответствующего раскрывающегося списка необходимо выбрать опцию «Только аудит» (Audit only), как показано на следующей иллюстрации. Естественно, после выполнения всех этих задач следует сохранить внесенные изменения.

Рис. 1. Настройка аудита для коллекции исполняемых правил

Исключительно для примера сейчас отредактируем несколько правил, на которых будем тестировать аудит. Например, пусть одно из таких правил будет правило для программы Microsoft Office One Note. То есть, следует открыть диалоговое окно свойств созданного ранее правила, а затем на вкладке «Общие» (General), в группе «Действие» (Action), как видно ниже, разрешающее правило сделать запрещающим.

Рис. 2. Изменение действия созданного ранее правила AppLocker

Теперь, перед сбором информации осталось лишь обновить подлежавшие изменениям параметры политики при помощи команды gpupdate с параметром /force и начинать проверять системные журналы.

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

Для начала анализа следует открыть оснастку «Просмотр событий» (Event Viewer) и сразу перейти к журналу «Журналы приложений и службMicrosoftWindowsAppLockerEXE и DLL» (Application and Services LogsMicrosoftWindowsAppLockerEXE and DLL). Здесь можно обнаружить несколько событий со следующими кодами:

• Информационное событие 8001. Свидетельствует о том, что политика AppLocker была успешно применена на этом компьютере. Здесь все понятно без каких-либо дополнительных разъяснений, она применилась и все;
• Информационное событие 8002. Это событие указывает на то, что в данном случае, выполнение определенного EXE- либо DLL-файла разрешены, согласно с распространяемым правилом AppLocker;
• Событие-предупреждение 8003. В свою очередь, данное событие указывает на то, что выполнение определенного файла на данный момент разрешается, однако, в случае применения политики AppLocker, его выполнение будет запрещено. Это означает, что как только будет распространяться данное запрещающее правило не в режиме аудита, пользователь более не сможет использовать такое приложение. В том случае, если бы не использовался режим аудита, мы бы сейчас видели событие уровня «ошибка» под номером 8004.

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

Рис. 3. Анализ сгенерированных событий

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

Заключение

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

Источник

dsa.msc> создаем отдельную OU для клиентских компьютеров Client Computers

Перемещаем в ou Client Computers клиентский компьютер.

gpmc.msc> Group Policy Objects> new GPO имя политики Software Control

Нажимаем правой кнопкой по Software Control и выбираем edit
Разворачиваем ветвь Computer Configuration\Policies \Windows Settings\Security Settings\Application Control Policies\AppLocker

Разворачиваем ветвь AppLocker и кликаем правой кнопкой по Executable Rules выбираем пункт Create Default Rules тоже самое повторяем для Windows Installer Rules, Script Rules и Packaged app Rules.

Кликаем на Configure rule enforcement в свойствах AppLocker Properties настраиваем Executable rules, Windows Installer Rules, Script Rules, и Packaged app Rules выставляем значение Audit only.

В редакторе групповой политики идем в ветвь Computer Configuration\Policies \Windows Settings\Security Settings\System Services
Находим службу Application Identity определяем параметры запуска в автоматический режим

Закрываем редактор. В консоли group policy managmet  правой кнопкой нажимаем по Client Computers и выбираем в меню Link an Existing GPO. 

 В окне выбора объекта групповой политики выбираем Software Control.

Идем на клиентский компьютер выполняем gpupdate /force и перезагружаем компьютер.
После перезагрузки пишем app.bat с следующим текстом:

rem testing app
pause


Кладем файл в каталог С:\temp и выполняем файл С:\temp\app.bat
Запускаем журнал событий eventvwr.msc разворачиваем журнал Application and Services Logs>Microsoft>Windows>AppLocker кликаем по MSI and Scripts 

 Наблюдаем событие 8005 %OSDRIVE%\CUSTOMAPP\APP.BAT was allowed to run. 
 (app.bat разрешен для запуска.)

Ограничиваем доступ к упакованным приложениям

Все мы знаем, что с выходом Windows 8 корпорация Microsoft решила полностью изменить представление пользователей о десктопных приложениях. Упакованные приложения, они же Metro-приложения, отличаются единообразием, обновленным упрощенным внешним видом и новым взаимодействием с пользователем. В этих приложениях минимизированы отвлекающие факторы, удалены практически все графические эффекты, включая Windows Aero, над которыми Microsoft трудилась несколько последних лет, для всех приложений используются единая цветовая гамма, шрифты и прочее. Не будем сейчас останавливаться на том, хорошо ли поступили Microsoft, что решили возвращаться к приложениям в стиле Windows 3.1, однако, с этим придется смириться и предпринимать какие-то действия по обслуживанию таких приложений.
Как известно практически каждому, начиная с таких операционных систем, как Windows 7, специально для выполнения задач, связанных с ограничением доступа пользователей к конкретным файлам или приложениям, в дополнение к политикам SRP Microsoft создали новую технологию, которую они назвали AppLocker. Политика AppLocker представляет собой набор из правил AppLocker, включающих в себя различные настройки, предназначенные для принудительного применения. Как свойственно объектам групповой политики, каждое правило сохраняется в конкретной политике, а сами политики уже распространяются согласно вашей иерархии объектов групповой политики.
В отличие от классических приложений, у всех упакованных приложений есть общие атрибуты ­– это имя издателя, имя продукта и его версия. Поэтому всеми приложениями можно управлять с помощью одного типа правил. В операционных системах Windows Server 2012 и Windows 8 правила AppLocker для упакованных приложений можно создавать отдельно от классических приложений, то есть для них специально была выделена отдельная коллекция. Одно правило AppLocker для упакованного приложения может контролировать как установку, так и работу приложения. Поскольку все упакованные приложения подписаны, AppLocker поддерживает только правила издателей для упакованных приложений. Давайте посмотрим, каким образом можно ограничивать доступ к упакованным приложениям.
Хотелось бы сразу отметить, что обязательным требованием является наличие таких приложений на компьютере, где будут создаваться правила, так что придется нам сейчас установить такие приложения.
Перейдем в Windows Marketplace и найдем какие-то стандартные приложения, например, пусть это будут такие стандартные приложения как Microsoft Zune Music, Microsoft Zune Video, Microsoft Bing News, Microsoft Bing Maps, Microsoft Bing Travel и Microsoft Bing Sports. Установим эти приложения на компьютер. Как они выглядят и какое их основное назначение, вы и так знаете, в чем я более чем уверен. Установка некоторых упакованных приложений отображена на следующей иллюстрации:

Рис. 1. Установка четырех упакованных приложений из Windows Marketplace
Опять же, обязательно обратите внимание на тот момент, что на целевом компьютере, на который будут распространяться правила AppLocker, должна быть запущена служба «Удостоверение приложения» (Application Identity). Этот момент вы можете как мониторить вручную непосредственно из оснастки служб каждого компьютера, так и централизовано настроить такую службы средствами специального расширения клиентской стороны групповой политики, что, по моему мнению, намного логичнее. По умолчанию у нее тип запуска «Вручную», так что вам в любом случае придется предпринять какие-то меры.
Теперь уже можно переходить к правилам AppLocker.

Создание правила AppLocker

Чтобы создать правило, ограничивающее доступ к упакованному приложению, скажем, к Microsoft Bing Sports, вам понадобится выполнить следующие действия:

1. Для начала мы, естественно, создадим в оснастке «Управление групповой политикой» новый объект групповой политики, так как лучше всего, если правила, предназначенные для ограничения приложений, будут расположены в отдельном объекте GPO, и назовем его, скажем, «Правила AppLocker». После этого нужно будет связать такой объект с подразделением, в которое входят учетные записи компьютеров, на которые и должны распространяться создаваемые нами правила. Например, в моем случае привязка идет для всего домена, но в реальной среде идеальным вариантом будет распределение целевых компьютеров по конкретным подразделениям. Последней задачей предварительного этапа будет, понятное дело, открытие самого редактора управления групповыми политиками;
2. Теперь в отобразившейся оснастке следует развернуть узел Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Политики управления приложениями и перейти к узлу, который называется AppLocker (Computer Configuration\Policies\Windows Settings\Security Settings\Application Control Policies\AppLocker). Сейчас переходим к последней коллекции, которая называется «Правила упакованных приложений», что на английском звучит как «Packaged app Rules». Находясь внутри этой коллекции, создадим наше правило, то есть, следует выбрать опцию «Создать новое правило» (Create New Rule);

   
   Рис. 2. Создание нового правила AppLocker

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

   
   Рис. 3. Определение разрешений для создаваемого правила

5. Как вы увидите на иллюстрации под номером 5, следующая страница называется «Издатель» (Publisher), и здесь вы не можете выбрать ни правило пути, ни правило хэша файла, с которыми вы могли работать в других категориях AppLocker-а в той же Windows 7 или Windows Server 2008 R2. Здесь вы можете выбрать одну из следующих опций:
   • Использовать для примера установленное упакованное приложение (Use an installed packaged app as a reference). В этом случае вам следует выбрать приложение, которое уже установлено на компьютере. При создании правила будет использоваться издатель, имя пакета, а также версия этого приложения;
   • Использовать для примера установщик упакованного приложения (Use a packaged app installer as a reference). Остановившись же на этом варианте, вам нужно будет указать установочный файл упакованного приложения с расширением appx. Как и в предыдущем случае, для определения правила будут также использоваться издатель, имя пакета и его версия. Этот вариант приемлем в том случае, если пользователи будут устанавливать такие приложения вручную, скажем, при помощи PowerShell.

   Так как у нас приложения уже проинсталлированы, мы остановимся на первом варианте и нажмем на кнопку выбора. В отобразившемся диалоговом окне, как видно на иллюстрации ниже, будут отображаться все установленные упакованные приложения. Несмотря на то, что слева можно отметить контролл для установки чекбоксов, на многое не рассчитывайте, так как вы не сможете установить более одного флажка одновременно. Например, сейчас создадим правило для Microsoft Bing Sports, то есть его и выбираем;

   
   Рис. 4. Выбор установленного упакованного приложения
6. Как вы видите на этой иллюстрации, о которой шла речь немного выше, в нижней части этой страницы мастера вы можете указать свойства для создаваемого правила. Здесь доступны следующие свойства:
   • Любой издатель (Any Publisher). Это свойство отвечает за всех издателей для выбранной вами категории файлов. Например, если вы изначально выбираете значение «Разрешить», то в таком случае это правило будет в дальнейшем запрещать выполнение неподписанных приложений. Либо, само собой, вы можете раз и навсегда запретить использование любых упакованных приложений;
   • Издатель (Publisher name). При помощи этого управляющего элемента вы можете указать, что под область действия правила должны попадать все файлы, которые подписаны издателем с определенным именем;
   • Имя пакета (Package name). Данное свойство правила позволяет вам помимо данных об издателе еще и добавить в правило наименование самого пакета упакованного приложения. В данном случае это Microsoft.BingSports;
   • Версия пакета (Package version). Это самое гибкое свойство создаваемого правила. Здесь вы можете определить версию управляемого вами приложения. Например, чтобы указать конкретную версию упакованного приложения, вы, как и в случае с обычными exe-файлами или динамическими библиотеками, можете установить флажок на опции с пользовательскими значениями, а затем уже указать вручную номер версии и выбрать, хотите ли, чтобы правило применялось к приложениям, версия которых выше указанного вами значения, ниже его, либо чтобы правило применялось только лишь на конкретную версию программного продукта.

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

   
   Рис. 5. Настройка свойств, определяющих правило для упакованного приложения

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

   
   Рис. 6. Последняя страница мастера создания правила AppLocker

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

Рис. 7. Проверка выполненных действий

Подытожим

Из этой небольшой статьи вы узнали о том, каким образом можно ограничить доступ к одному из нововведений Microsoft в их последней операционной системе – к упакованным приложениям, которые чаще всего многие именуют Metro-приложениями. Было рассказано о том, как именно можно создать такие правила, на чем они основаны, а также об одном важном предварительном требовании, которое обязательно следует участь перед развертыванием таких правил. А вы у себя в компании используете упакованные приложения и планируете ли ограничивать пользователям доступ к каким-то APPX-файлам?