Снижение безопасности приложений: все дело в приложениях (часть 5)

• Application Security Redux: все дело в приложениях (часть 4)
• Снижение безопасности приложений: все дело в приложениях (часть 8)

Введение

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

В части 4 мы начали изучать Microsoft AppLocker, который был представлен в Windows 7 и Server 2008 R2 и вырос из предыдущей функции политик ограниченного использования программ. На этот раз в части 5 мы углубимся в использование PowerShell для настройки и управления AppLocker, а затем завершим обсуждение в части 6, когда перейдем к новой возможности управления приложениями на мобильных устройствах с Windows 10 через CSP, который был добавлен в AppLocker в Windows 10.

Командлеты PowerShell для AppLocker

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

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

Но что бы вы об этом ни думали, факт в том, что Microsoft все больше и больше продвигает PowerShell для настройки, управления и автоматизации компонентов Windows и серверных приложений. Если вы не являетесь любителем CLI (интерфейса командной строки), вам надлежит развить вкус к работе в «темном пространстве», потому что GUI (графический пользовательский интерфейс) становится все более ограниченным в функциях, поскольку этого требуют сложные задачи. переходим к PowerShell.

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

Получение и использование командлетов AppLocker

Если вы знакомы с PowerShell, то знаете, что не все командлеты поставляются «в комплекте» с PowerShell. Модули PowerShell были представлены в PowerShell v2 для расширения репертуара командлетов (до v2 это выполнялось с помощью оснасток, которые все еще поддерживаются, но модули упрощают расширяемость). В зависимости от вашей версии Windows Server, она будет поставляться с рядом встроенных модулей. Те, которые не включены, могут быть импортированы. Во многих случаях соответствующий модуль будет включен в приложения, для которых он используется, и будет установлен вместе с самим приложением.

Примечание:
Если вы все еще используете Windows Server 2008 R2/Windows 7, вы можете импортировать командлеты AppLocker, введя в приглашении PowerShell следующее:

Существует пять командлетов AppLocker (на данный момент). Новые командлеты могут быть добавлены в будущем. Вот командлеты и то, что вы можете сделать с каждым из них:

• Get-AppLockerFileInformation — цель этого командлета очевидна из названия. Вы используете его для получения такой информации, как информация об издателе (для файлов с цифровой подписью), информация о хэше и информация о пути для файлов AppLocker. Это может происходить из журналов событий или из списка файлов. Вы можете использовать следующие параметры: –Path, -FileType, -Recurse, -EventLog, -LogPath, -EventType и –Statistics. С помощью этих командлетов вы можете получить информацию о файлах для всех исполняемых файлов в указанном каталоге или для определенного файла по пути, или для всех проверенных событий в журнале событий AppLocker, или получить статистику для событий в журналах. Синтаксис и примеры см. по этой ссылке.
• Set-AppLockerPolicy — политики AppLocker, как мы обсуждали в предыдущем выпуске этой серии, состоят из правил и коллекций правил и могут применяться к новому или существующему объекту групповой политики. Вы можете использовать этот командлет, чтобы настроить конкретный объект групповой политики, чтобы он содержал указанную политику AppLocker. Обратите внимание, что при этом будет перезаписана текущая политика объекта групповой политики, если только вы не используете параметр Merge, что приведет к объединению правил в указанной политике с правилами существующей политики в объекте групповой политики. Очень важно использовать Merge, если вы хотите, чтобы ваша новая политика была дополнением, а не заменой существующей политики. Другой параметр для этого командлета включает –XMLPolicy, который указывает путь, по которому сохраняется политика AppLocker (в формате.XML); -PolicyObject, указывающий объект, содержащий политику; -LDAP, указывающий путь LDAP к объекту групповой политики; -Подтверждение, которое запрашивает перед выполнением команды; и –WhatIf, который описывает, что , если вы выполните команду (фактически не делая этого). Синтаксис и примеры см. по этой ссылке.
• Get-AppLockerPolicy — этот командлет прост для понимания: он извлекает политику AppLocker для локального объекта групповой политики или домена или политику, которая в данный момент действует на компьютере. Параметры включают –Local, который получает политику от локального GPO; -Домен, который получает политику от GPO в параметре LDAP; -Эффективный, который показывает политику, действующую на компьютере, которая представляет собой слияние локальной и доменной политик; -LDAP, указывающий путь LDAP к уникальному объекту групповой политики; и –XML, который вы используете, если хотите, чтобы политика выводилась в виде строки XML. Синтаксис и примеры см. по этой ссылке.
• New-AppLockerPolicy. Опять же, этот командлет делает то, что следует из его названия: он используется для создания новой политики AppLocker, используя список сведений о файлах для автоматического создания правил, которые будут применяться к определенному пользователю или группе пользователей. Эти правила могут основываться на информации об издателе, хэше или пути. Параметры включают –FileInformation, который содержит эту информацию; -RuleType, который указывает тип создаваемых правил, и вы можете создать несколько типов правил, если хотите. Таким образом, у вас есть правила резервного копирования, которые можно использовать, когда один тип информации недоступен; -RuleNamePrefix, который можно использовать для обозначения префикса для каждого из создаваемых правил; -Пользователь, который указывает пользователя или группу, к которым применяются правила, и может быть отформатирован как имя пользователя DNS, имя участника-пользователя, имя пользователя SAM или SID; -Оптимизация, которая группирует похожие правила вместе; -IgnoreMissingFileInformation, который сообщает командлету, что он должен выполняться, даже если отсутствует информация, препятствующая созданию правила; и –XML (то же, что и выше). Синтаксис и примеры см. по этой ссылке.
• Test-AppLockerPolicy — этот командлет предоставляет простой способ проверить, будет ли разрешено выполнение указанных файлов для определенного пользователя. Всегда рекомендуется тестировать свои политики, чтобы убедиться, что они будут иметь ожидаемый эффект, поскольку несколько политик могут привести к неожиданному поведению. Параметры включают –PolicyObject, указывающий объект политики, содержащий политику AppLocker, которую вы хотите протестировать; -XMLPolicy, который позволяет ввести XML-путь к политике AppLocker; -Путь, которым можно указать список путей к файлам для проверки, используя регулярные выражения; -Пользователь для определения имени пользователя или группы, для которых вы хотите протестировать политику; и –Filter, который позволяет отображать только определенные решения по параметрам политики, такие как «Разрешено», «Запрещено», «Разрешено по умолчанию» или «Запрещено по умолчанию», а не отображать все решения политики, как это делается по умолчанию. Синтаксис и примеры смотрите по этой ссылке.

Собрав все вместе, вы сможете быстро создать и протестировать новую политику AppLocker прямо из интерфейса PowerShell. Вы используете Get-AppLockerFileInformation и отправляете выходные данные в New-AppLockerPolicy, затем используете Set-AppLockerPolicy, чтобы применить новую политику, которую вы создали, и используете Get-AppLockerPolicy, чтобы убедиться, что ваша политика была импортирована. Наконец, вы можете протестировать политику с помощью Test-AppLockerPolicy. Как только вы освоите эти пять командлетов, вы сможете значительно упростить и ускорить процесс работы с AppLocker для управления приложениями, которые ваши пользователи могут запускать на своих рабочих компьютерах.

Резюме

В этой части 5 нашей серии мы представили сводку командлетов PowerShell, которые Microsoft сделала доступными для AppLocker, а в следующий раз в части 6 мы завершим обсуждение ограничения того, что пользователи могут делать с разрешенными приложений, поскольку мы коснемся новой функции, которая была добавлена в Windows 10: возможность управлять приложениями на мобильных устройствах Windows 10 через CSP. Тогда увидимся.

• Снижение безопасности приложений: все дело в приложениях (часть 8)