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

Общей проблемой разработки безопасной рабочей среды является смягчение угроз от вредоносных элементов управления ActiveX® с одновременным обеспечением соответствующего уровня совместимости приложений в среде. Это являлось проблемой настольных операционных систем в течение многих лет. К счастью, новая служба установщика ActiveX (AxIS) в Windows Vista™ решает проблемы управления элементами управления ActiveX в корпоративных средах. AxIS предоставляет простой и управляемый способ установки пользователями элементов управления ActiveX с одобренных веб-узлов, тогда как обычно этим пользователям такая установка не разрешена. Управление AxIS при помощи групповой политики позволяет администраторам отделов ИТ определять, какие элементы управления могут устанавливать пользователи, независимо от их разрешений.

В данной статье мы рассмотрим проблемы администрирования элементов управления ActiveX, решение этих проблем в предыдущих версиях Windows®, а также предоставление в Windows Vista уникального и эффективного способа управления установкой элементов управления ActiveX при помощи AxIS.

Что такое элемент управления ActiveX?

Элемент управления ActiveX – это часть исполняемого кода (обычно в файл OCX, упакованный в файле CAB), устанавливаемая и запускаемая пользователем через обозревателем Internet Explorer®. Веб-разработчики создают элементы управления ActiveX для добавления к веб-приложениям функций, которые невозможно осуществить с помощью стандартного кода HTML или простого сценария.

Главной функцией элементов управления ActiveX является их модель развертывания «загрузить и выполнить». Элементы управления ActiveX устанавливаются и выполняются через тег объекта HTML, который имеет атрибут CODEBASE, сообщающий обозревателю Internet Explorer (с помощью URL-адреса) о местонахождении элемента управления, если он еще не установлен на компьютере пользователя. В этом случае Internet Explorer загружает соответствующий пакет установки, выполняет доверенную проверку объекта и запрашивает разрешение пользователя на установку через панель информации Internet Explorer (показана на рис. 1). Во время установки элемент управления регистрируется и выполняется страницей отображения. После установки элемент управления могут запустить все стандартные пользователи. Этот простой механизм распространения и выполнения предоставляет разработчикам простой способ распространения своих компонентов пользователям их веб-приложений. Проблема этого метода распространения заключается в том, что стандартные пользователи не могут устанавливать элементы управления ActiveX напрямую, поскольку для установки необходимы права администратора.

Когда элементы управления ActiveX были впервые представлены в обозревателе Internet Explorer 4.0, Интернет выглядел более дружелюбным местом. Сегодня исполняемый код, распространяемый через Интернет, представляет значительную угрозу, поэтому Windows разрешает установку элементов управления ActiveX только пользователям с правами администраторов при одобрении установки в соответствии с параметрами политики. После установки элемента управления ActiveX администратором его может выполнить любой пользователь системы. Этот процесс упрощается с помощью набора списков ACL для файлов и реестра в Windows. Хотя это препятствует установке элементов управления ActiveX стандартными пользователями, это не снижает риск локальных администраторов и стандартных пользователей (с измененными разрешениями по умолчанию), устанавливающих элементы управления.

Хотя защита в Windows по умолчанию, разрешающая установку только пользователям с правами администраторов, устанавливает управление элементами управления ActiveX на индивидуальном уровне, она не предоставляет способа управления ими в большой организации. Общей проблемой корпоративных сред является разрешение использование элементов управления ActiveX, доверенных ИТ-организацией, с одновременным снижением рисков от внешних недоверенных элементов управления. В конце дня решение установки определенного элемента управления ActiveX, хорошего или плохого, часто оставляется на отдельного пользователя в зависимости от его прав. Для противодействия угрозам некоторые организации блокируют элементы управления ActiveX, тогда как другие позволяют конечным пользователям устанавливать их, но пытаются осуществлять управление установленными вредоносными программами.

Другим способом предотвращения установки вредоносных элементов управления является ограничение прав стандартных пользователей и предварительная установка всех необходимых элементов управления на настольной платформе администратором отдела ИТ. Этот подход является эффективным, если используемые элементы управления ActiveX являются относительно статичными, изменяются с помощью запланированного процесса выпуска в связи с обновлениями рабочей среды или если в организации используется такой механизм распространения программного обеспечения, как Systems Management Server. Однако текущее управление, постоянно меняющиеся потребности разработчиков внутренних приложений и зависимость от внешних элементов управления продолжают являться проблемами этих подходов.

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

Одним из решений является использование внутреннего сервера загрузки компонентов Интернета для размещения одобренных элементов управления. Для данного решения требуется изменение строки CodeBaseSearchPath в реестре клиента. Обычно при нахождении на запрашиваемой странице HTML тега объекта с атрибутом CODEBASE клиенты Windows перенаправляются в местоположения, указанные данными CodeBaseSearchPath. По умолчанию данная строка реестра содержит ключевое слово CODEBASE и внутренние URL-адреса Интернета для галереи элементов управления ActiveX. Для реализации сервера загрузки компонентов Интернета необходимо заменить данные по умолчанию в CodeBaseSearchPath URL-адресом внутреннего сервера, на котором размещаются одобренные организацией элементы управления. Как и для предыдущего подхода, для данного решения требуется постоянное управление; оно также приводит к затратам и возникновению сложности размещения внутреннего сервера для элементов управления ActiveX.

Существуют другие решения, например изменение зоны URLActions обозревателя Internet Explorer, указание одобренных администратором элементов управления через групповую политику и блокирование установки всех элементов управления по периметру с помощью правил брандмауэра. Но, как вы видите, все эти подходы имеют собственные проблемы и многие из них в итоге не используются из-за недостаточной гибкости. Что еще хуже, для некоторых из этих решений требуется, чтобы пользователи имели права администраторов. Таким образом, эти изменения решают часть проблемы, например, контроль (или блокирование) источника элементов управления ActiveX, откуда они могут быть выполнены и т.д.; однако эти решения не решают фундаментальную проблему невозможности установки элементов управления ActiveX пользователями без прав администраторов.

Какие возможности предоставляет AxIS?

AxIS в Windows Vista позволяет корпоративным администраторам управлять элементами управления ActiveX, обеспечивая надежную защиту, поскольку пользователи выступают в качестве стандартных пользователей с параметрами файловой системы по умолчанию. AxIS предоставляет групповой политике возможности настройки доверенных источников элементов управления ActiveX и брокерский процесс для установки элементов управления из этих доверенных источников стандартными пользователями. Ключевым преимуществом является возможность сохранения неадминистративной безопасности рабочих станций пользователей с помощью централизованного административного управления. AxIS опирается на определение доверенных источников (обычно URL-адреса из Интернета или интрасети) элементов управления ActiveX администраторами отделов ИТ. Если тег объекта сообщает обозревателю Internet Explorer о необходимости выполнения элемента управления, AxIS выполняет следующие действия.

1. Проверка установки элемента управления. Если элемент отсутствует, он должен быть установлен для его использования.
2. Проверка параметров политики AxIS на предмет того, является ли источник элемента управления доверенным. Отдельная проверка устанавливает соответствие имени узла URL-адреса, указанного в атрибуте CODEBASE тега объекта, указанному в политике списку доверенных мест.
3. Загрузка и установка элемента управления от имени пользователя.

Если имя узла URL-адреса источника отсутствует в параметре политики AxIS, будет выполнен обычный запрос контроля учетных записей, указывающий необходимость прав администратора для выполнения установки. Кроме того, AxIS зарегистрирует в журнале событий приложений событие с идентификатором 4097 от источника AxInstallService с указанием попытки установки элемента управления ActiveX, а также путь загрузки элемента управления. Пример события 4097 показан на рис. 2. Данные этой записи журнала событий могут использоваться корпоративным администратором для изменения групповой политики с целью разрешения установки элемента управления AxIS при последующих посещениях веб-узла.

AxIS – это дополнительный компонент, входящий в версии (SKU) Business, Enterprise и Ultimate операционной системы Windows Vista, который может быть включен с помощью автоматического параметра или из диалогового окна панели управления (Программы | Программы и компоненты | Включение и отключение компонентов Windows), как показано на рис. 3. После включения AxIS выполняет указанные выше действия при каждом запросе элемента управления обозревателем Internet Explorer.

Возможность прикрепления заданий к событиям в Windows Vista предоставляет администраторам простой способ получения уведомлений от службы AxIS, например, при блокировании установки элемента управления ActiveX. Важно заметить, что нельзя всегда предполагать, что элемент управления ActiveX будет устанавливаться с этого же имени узла URL-адреса, к которому обращается конечный пользователь с веб-узла. По этой причине информация, предоставленная событием 4097 AxInstallService 4097 (попытка установки), является исключительно полезной для определения узла, с которого выполняется попытка установки элемента управления.

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

Рис. 4 Параметры редактора объектов групповой политики

Рис. 5 Одобренные AxIS узлы установки

Прежде всего, как упоминалось ранее, URL-адрес узла необходим для определения доверенного расположения элемента управления. В отличие от предыдущих решений, для которых необходимо было знать идентификатор CLSID элемента управления (который часто изменяется при изменении элементов управления другими разработчиками), AxIS позволяет установку любых элементов управления из доверенного месторасположения, что уменьшает общую потребность в административной деятельности. Вторым элементом информации является строка из четырех значений, разделенная запятыми, каждое из которых обозначает поведение загрузки элемента управления ActiveX. Значения определяют четыре свойства: TPSSignedControl, SignedControl, UnsignedControl и ServerCertificatePolicy. Первые два свойства (TPSSignedControl и SignedControl) могут иметь одно из трех значений: 0, 1 или 2. Эти значения схожи со значениями параметров URLAction. Значение 0 запрещает установку элемента управления, при установке значения 1 появляется запрос на разрешение пользователя на установку, а при установке значения 2 элемент управления будет автоматически установлен от имени пользователя. Неподписанные элементы управления не могут быть установлены автоматически, поэтому значения свойства UnsignedControl может быть только 0 или 1. Если политика не указана, используются значения по умолчанию 2, 1 и 0.

Последнее свойство определяет поведение установки на основе параметров сертификата элемента управления подписанных параметров. Как и большинство узлов SSL, сертификаты должны пройти ряд тестов безопасности для проверки действительности сертификата. Неверные свойства сертификата иногда являются практикой реализации подписанного элемента управления ActiveX. Благодаря настройке AxIS позволяет администраторам устранить недействительную информацию, которая иногда присутствует в сертификатах на основе «URL-адрес-URL-адрес». Последнее свойство – это сочетание значений с битовой маской, как показано на рис. 6.

Рис. 6  ServerCertificatePolicy

Значение по умолчанию – 0, что означает, что означает, что должны быть выполнены все тесты безопасности до завершения установки AxIS. Сочетание параметра узла и этих четырех значений указаны в параметре политики, как показано на рис. 7.

Заключение

AxIS позволяет настраивать групповую политику для определения элементов управления ActiveX, которые могут устанавливаться пользователями без полномочий администратора или необходимости сложных настроек. Управление на таком уровне могло быть затруднительным в предыдущих версиях Windows, а ранее доступные решения часто имели серьезные ограничения или значительную необходимость в управлении. AxIS предоставляет организациям другое средство с использованием подхода минимальных полномочий и прав конечных пользователей на настольных системах, что делает возможным реализацию модели стандартных пользователей, где для конечных пользователей не требуются права администраторов. Windows Vista предоставляет администраторам отделов ИТ значительное преимущество, поскольку они они могут выбирать, какие элементы управления ActiveX считаются доверенными в корпоративной среде, что определяется организацией, а не конечным пользователем.