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

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

Введение

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

Эволюция SRP в AppLocker

В Windows Server 2003 и Windows XP были введены политики ограниченного использования программ (SRP) как основанное на политике средство идентификации программных приложений и утилит, установленных на компьютерах, и дающее администраторам возможность контролировать, разрешено ли запускать отдельные программы. SRP был интегрирован с операционной системой как часть групповой политики Windows.

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

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

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

Благодаря всему вышеперечисленному многие администраторы, которые начинали в восторге от SRP, отказались от попыток заставить его работать. У Microsoft, как это часто бывает, были благие намерения, но с первого раза не получилось. Однако они склонны прислушиваться к отзывам клиентов (в конце концов). Увидев, как клиенты борются с SRP в Windows XP и Vista, несмотря на незначительные изменения в процессе, они решили изменить название и придать этой функции настоящий вид. Таким образом, в Windows 7 и Server 2008 R2 появилась блестящая новая версия с более броским названием: AppLocker.

Отличие AppLocker

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

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

Наиболее важно то, что пользователям не так легко обойти политики AppLocker, как SRP; однако пользователи с правами локального администратора смогут их обойти. Конечно, лучше всего давать права администратора только тем, у кого они должны быть. Иногда, конечно, может быть невозможно следовать этому правилу (например, когда человек, который не нуждается, но хочет административного контроля над своим компьютером, является начальником).

Есть два очень разных (на самом деле, прямо противоположных) основных способа контролировать, какие приложения разрешено запускать:

• Черный список (предоставление списка приложений, которые вы хотите запускать, с разрешенными всеми остальными) или
• Белый список (предоставление списка приложений, которые вы разрешить запускать, а все остальные заблокированы).

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

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

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

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

• Исполняемые правила
• Правила установки Windows
• Правила скрипта

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

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

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

Резюме

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

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