Файл: Управление правами пользователей в ос windows Локальная политика безопасности Пенза, 2014.doc
Добавлен: 12.01.2024
Просмотров: 369
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Рисунок 7 – Окно свойств AppLocker, вкладка «Дополнительно»
Стоит, однако, иметь в виду, что использование таких правил может существенно повлиять на производительность системы. Это связано с тем, что каждое приложение, как правило, использует для работы несколько файлов библиотек, поэтому на их проверку и соответствие правилам уходит гораздо больше времени, чем на проверку только приложений. Кроме этого, некоторые приложения загружают дополнительные файлы библиотек в процессе работы, поэтому проверка, которую Windows будет при этом выполнять, может замедлить работу пользователя с программой. При включении правил DLL их необходимо создавать для каждой библиотеки, которая используется всеми разрешёнными программами.
Необходимо отметить, что использование большого числа правил любого типа (это касается не только правил DLL) в любом случае будет снижать производительность системы, поскольку при попытке запуска каждого приложения Windows потребуется обрабатывать все правила, чтобы разрешить или запретить пользователю работу с программой.
Именно поэтому, создавая правила, имеет смысл строить их таким образом, чтобы общее их число было как можно меньшим. Все правила AppLocker работают по принципу разрешения («белый список»), запрета («черный список») и исключения. Иными словами, перед созданием правила стоит решить, что удобнее: 1) сделать правило, разрешающее определённое действие (при этом запуск всех приложений, которых нет в составленном администратором списке, будет запрещён), и сделать исключения для некоторых групп пользователей или приложений; или же 2) создать правило, разрешающее запускать все приложения, кроме указанных в списке, и также указать исключения.
Несмотря на то, что при помощи AppLocker можно создавать как разрешающие, так и запрещающие правила, в большинстве случаев рекомендуется использовать первый вариант. Это связано с тем, что для обеспечения безопасности любой организации гораздо логичнее составить фиксированный список разрешённых приложений, который можно по мере необходимости обновлять, нежели попытаться перечислить в правиле те программы, которые запрещено запускать. Любой новый вирус, который администратор не успел добавить в запрещающее правило
, имеет все шансы проникнуть в корпоративную сеть. Также причиной, по которой рекомендуется использовать разрешающие правила, является то, что запрещающие действия во всех случаях переопределяют разрешающие.
Для создания нового правила раскройте список AppLocker в окне «Локальная политика безопасности», необходимо щёлкнуть правой кнопкой мыши по нужному типу правила и выбрать команду «Создать новое правило». Будет запущен мастер, на первом этапе работы которого нужно будет определиться с тем, будет ли это правило разрешать или запрещать определённые действия, а также, на какие категории пользователей оно будет распространяться.
Затем нужно будет выбрать тип основного условия: «Издатель» (Publisher), «Путь» (Path) и «Хэшируемый файл» (File Hash). Несмотря на то, что типы условий похожи на те, которые использовались в политиках ограниченного использования программ в предыдущих версиях Windows, работа с ними организована по-другому.
Наиболее интересным является условие «Издатель», прототипом которого в политиках ограниченного использования программ было условие «Сертификаты» (Certificate). Это условие дает возможность разрешить запуск приложений, для которых имеется цифровая подпись издателя. При создании правил с таким условием учитывается не только название производителя, как это было в Windows XP, но и другая информация, такая как название продукта, имя файла, номер версии.
При этом условие может распространяться в точности на указанный номер версии приложения или на все версии, номер которых выше или ниже заданного. Благодаря этому, можно гибко настроить правило, которое будет разрешать установку новых версий приложений, но при этом запрещать установку старых релизов, которые могут быть несовершенны с точки зрения безопасности. Для использования условия «Издатель» нужно указать путь к файлу приложения, который содержит цифровую подпись. Установив флажок «Пользовательские значения», можно вручную отредактировать значения всех полей. Стоит иметь в виду, что если приложение не имеет цифровой подписи, то использовать условие «Издатель» в его отношении невозможно.
Условие «Путь» позволяет определить приложения, которые разрешено запускать и устанавливать пользователю, на основе их расположения в файловой системе локального компьютера, в сети или на сменных носителях. Создавая такое условие, можно использовать подстановочные знаки и переменные окружения. Например, чтобы указать путь на CD/DVD-диске, нужно использовать переменную %REMOVABLE%, а для указания пути на USB-накопителе – %HOT%.
Условие «Путь» необходимо использовать очень осторожно, так как при недостаточной продуманности оно может стать причиной того, что пользователи смогут с его помощью обходить некоторые запреты. Например, если создать разрешающее условие такого типа и включить в него расположение папки, в которую пользователь может выполнять запись, то пользователь сможет скопировать в такую папку запрещённый для запуска файл из другого расположения и запустить его.
Условие «Хэшируемый файл» в большинстве случаев является наименее эффективным, так как определение легитимности файла построено на вычислении его контрольной суммы. Нетрудно догадаться, что если выходит обновление приложения, то его контрольная сумма изменяется, и условие перестает работать. С другой стороны, такой способ позволяет защититься от возможности запуска известной программы, в которую был внедрен вредоносный код. Поскольку при этом контрольная сумма изменяется, модифицированное приложение запустить будет невозможно.
Как видно, каждое из условий несовершенно и имеет свои недостатки. Именно поэтому на следующем этапе работы мастера предлагается настроить исключения. Исключения можно использовать, если в качестве основного выбраны условия «Издатель» и «Путь».
Наконец, на последнем этапе работы мастера нужно дать правилу название, а также снабдить его описанием. Несмотря на то, что последнее необязательно, не стоит пренебрегать этой возможностью, так как описание может помочь в будущем вспомнить, за что отвечает то или иное правило.
Чтобы лучше понять, как работают правила, можно начать с создания правил по умолчанию. Они доступны для каждого из типов правил. Например, правила для исполняемых файлов включают такие: разрешение на запуск любых приложений членам группы «Администраторы», разрешение на запуск приложений, находящихся в директории Program Files и в папке Windows, для членов группы «Все». Для создания набора правил по умолчанию нужно раскрыть список AppLocker в окне «Локальная политика безопасности», щёлкнуть правой кнопкой мыши по нужному типу правила и выбрать команду «Создать правила по умолчанию».
Рисунок 8 – Создание правила по умолчанию
Правила по умолчанию можно редактировать. Для этого нужно щёлкнуть по названию правила в списке и выбрать строку «Свойства». Редактировать можно все свойства правил, например, добавлять исключения, изменять пути, группы пользователей, на которые они распространяются, и т.д.
Рисунок 9 – Редактирование свойств
В AppLocker встроен автоматический механизм, упрощающий создание правил. Выберите команду «Создать правила автоматически» для определённого типа правил, укажите группы пользователей, к которым будут применяться создаваемые правила, а также папку, в которую установлены приложения.
При автоматическом создании правил мастер пытается максимально уменьшить их число. В таком режиме создаются только разрешающие правила. Если среди проанализированных приложений имеются такие, которые созданы одним разработчиком и у которых совпадает название продукта (согласно цифровой подписи), для них создаётся одно правило с условием «Издатель». Что касается условия «Хеш», то создаётся одно условие, которое содержит контрольные суммы всех файлов.
После завершения работы мастера автоматического создания правил AppLocker выдает отчет, в котором выводит общее количество файлов и число правил, которые будут созданы. Перед созданием правил есть возможность просмотреть как проанализированные файлы, так и составленные правила.
Используя AppLocker, нужно иметь в виду, что правила, созданные с его помощью, могут быть применены только на компьютерах, работающих под управлением Windows 7 Максимальная, Windows 7 Корпоративная и Windows Server 2008 R2.
Политики безопасности IP на «Локальный компьютер
После стандартной инсталляции в операционной системе предлагаются три варианта настройки для организации защищенного IP-канала – политики безопасности IPSec в рамках одного домена:
-
«Сервер» – для всего трафика IP всегда запрашивает безопасность с помощью доверия Kerberos. Разрешает небезопасную связь с клиентами, которые не отвечают на запрос; -
«Безопасность сервера» – для всего IP-трафика всегда запрашивает безопасность с помощью доверия Kerberos. Не разрешает небезопасную связь с недоверенными клиентами; -
«Клиент» – обычная связь (небезопасная). Использует правило ответа по умолчанию для согласования с серверами, запрашивающими безопасность. Только запрошенный протокол и трафик с этим сервером будут безопасными.
После установки операционной системы ни одна из политик не назначена. Пользователь может активизировать (назначить) одну и только одну из существующих политик.
Ниже, в качестве справочной информации, приводятся настройки, которые используются Microsoft для трех стандартных вариантов политики безопасности IPSec.
При изучении вопросов, связанных с установлением защищенного соединения IPSес индивидуальные рекомендации необходимы для случая, если компьютер, который необходимо задействовать в схеме защищенного соединения, имеет несколько IP-адресов. Кроме того, для случая работы в домене локальная политика безопасности компьютера может перекрываться политикой безопасности, определяемой контроллером домена.
Таблица 1 – Настройки стандартных политик безопасности IP в ОС Windows 7
Политика безопасности IPПравило безопасности IP | Клиент (только ответ) | Безопасность сервера (требовать безопасность) | Сервер (запрос безопасности) | ||||
Динамический | Динамический | Весь ICMP-трафик | Весь IP-трафик | Динамический | Весь ICMP-трафик | Весь IP-трафик | |
Методы проверки подлинности | Kerberos V5 | Kerberos V5 | Kerberos V5 | Kerberos V5 | Kerberos V5 | Kerberos V5 | Kerberos V5 |
Тип подключения | Все сетевые подключения | Все сетевые подключения | Все сетевые подключения | Все сетевые подключения | Все сетевые подключения | Все сетевые подключения | Все сетевые подключения |
Методы безопасности (Действия фильтра/Методы безопасности) | Использование протокола ESP (3DES или DES) и (SHA1 или MD5) Использование протокола AH (SHA1 или MD5) | Использование протокола ESP (3DES или DES) и (SHA1 или MD5) Использование протокола AH (SHA1 или MD5) | Разрешить (Блокирование согласования безопасности IP - поток данных защищать не требуется) | Согласовывать - использование протокола ESP (3DES или DES) и (SHA1 или MD5), Принимать небезопасную связь, но отвечать с помощью IPSec | Использование протокола ESP (3DES или DES) и (SHA1 или MD5) Использование протокола AH (SHA1 или MD5) | Разрешить (Блокирование согласования безопасности IP - поток данных защищать не требуется) | Разрешать связь с компьютером, не поддерживающим IPSec Согласование - использование протокола ESP (3DES или DES) и (SHA1 или MD5), принимать небезопасную связь, но отвечать с помощью IPSec |
Список фильтров | – | – | ICMP (Мой IP <-> Любой IP) | Любой протокол (Мой IP <-> Любой IP) | – | ICMP (Мой IP <-> Любой IP) | Любой протокол (Мой IP <-> Любой IP) |