Предотвратите запуск этих нежелательных приложений в RDS

Введение

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

История

Прежде чем мы углубимся в самые современные технологии, доступные в Windows Server 2008 R2, давайте кратко рассмотрим предыдущую версию. До Windows Server 2008 R2 вам были доступны политики ограниченного использования программ (SRP). SRP реализованы с использованием объектов групповой политики (GPO). SRP будет проверять каждый экземпляр программного обеспечения, запущенного пользователем, и запускать его с помощью набора политик SRP. SRP всегда состоит из двух частей: уровня безопасности и набора правил. Уровень безопасности определяет общий метод от слабого до очень строгого (неограниченный, базовый или запрещенный). После определения этого общего уровня безопасности вы начинаете делать исключения из правила, чтобы явно запрещать или разрешать запуск определенных приложений. Это может быть основано на хеше, пути, сертификате или сетевой зоне. Это составит ваш SRP. Хороший набор инструментов для повышения безопасности вашей среды служб удаленных рабочих столов (или, по сути, служб терминалов, поскольку это было до R2), но давайте посмотрим, что Windows Server 2008 R2 добавляет к этой функциональности.

Сегодня

В Windows Server 2008 R2 (и Windows 7) появился AppLocker. AppLocker заменяет SRP, и хотя SRP все еще может существовать, вы, скорее всего, обнаружите, что используете AppLocker вместо SRP. В этой главе мы увидим, почему.

• Обзор

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

• Аудиторская проверка

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

Идентификатор события 8003: запуск %SYSTEM32%easteregg.exe был разрешен, но запуск был бы запрещен, если бы применялась политика AppLocker.

Ищите события в следующем месте:

Журналы приложений и служб Microsoft Windows AppLocker EXE и DLL

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

• Условия издателя

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

Издатель — это приведет к тому, что правило разрешит все приложения, содержащие определенного издателя.

Название продукта — это приведет к тому, что правило разрешит все приложения, содержащие определенное название продукта.

Имя файла — это приведет к тому, что правило разрешит все приложения, содержащие определенное имя файла.

Версия файла — это приведет к тому, что правило разрешит все приложения, содержащие определенное имя файла.

Разумеется, вам не нужно вводить эти значения вручную. Вы можете выбрать приложение на узле сеанса удаленного рабочего стола во время работы мастера, и мастер соберет всю информацию из исполняемого файла. Например, при выборе winword.exe в установке Office 2010 вам будут представлены следующие значения.

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

• Другие улучшения

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

Вывод

Как видите, реализация AppLocker имеет много преимуществ по сравнению с политиками ограниченного использования программ. Я не могу придумать какой-либо вариант, который был бы возможен с SRP, который был объявлен устаревшим в AppLocker, поэтому общий совет: если вы сегодня не используете какой-либо метод ограничения программного обеспечения в своей среде RDS, начните использовать AppLocker сегодня и используйте политики аудита, чтобы увидеть, что AppLocker может сделать для вас! Если вы все еще используете SRP на Windows Server 2008 R2, взгляните на возможности, которые AppLocker может предложить вам помимо того, что вы уже делаете с SRP.