Управление безопасностью настольных компьютеров Windows — задача сложная, для ее решения существует множество подходов и инструментов. Но в операционных системах Windows есть встроенный инструментарий, наделенный всей функциональностью, необходимой большинству компаний для надежной защиты настольных компьютеров в информационной среде любого размера. Это групповая политика.
Многие администраторы рассматривают групповую политику как средство для выполнения таких задач управления настольными компьютерами, как развертывание программных продуктов, перенаправление папок или запрет доступа пользователя к редактору реестра (regedit.exe). Но помимо этого, групповая политика — важный инструмент для управления настройками безопасности Windows. Действительно, у групповой политики есть довольно много малоизвестных возможностей. В данной статье рассматриваются некоторые функции безопасности групповой политики, объясняются принципы работы и даются советы по их использованию.
Безопасность базовой системы
Возможности групповой политики по управлению настройками безопасности можно разделить на три категории: безопасность базовой системы, ограничения для приложений и устройств и безопасность Microsoft Internet Explorer (IE). Настройки безопасности первой из этих категорий обычно можно найти с помощью редактора групповой политики в разделе Computer Configuration Windows SettingsSecurity Settings, как показано на экране 1, полученном на компьютере с Windows Vista. Ниже перечислены некоторые возможности групповой политики по защите базовой системы.
Политики учетной записи
Этот раздел групповой политики широко известен, потому что именно в нем задаются политики пароля и блокировки учетной записи. Например, можно установить минимальную длину пароля или потребовать, чтобы пароль содержал небуквенные символы. Если определить эти политики в объекте групповой политики (GPO), связанном с доменом (например, в политике Default Domain), политика пароля обрабатывается всеми контроллерами домена (DC) в домене, и объект GPO управляет политикой паролей для учетных записей пользователей домена. Политика паролей, определенная в GPO, привязанном к домену, обрабатывается всеми рабочими станциями и серверами, членами домена и устанавливает политику учетных записей для любых локальных учетных записей, определенных в этих компьютерах.
Как известно, через групповую политику можно определить только одну политику паролей в домене. Но в Windows Server 2008 появился новый набор объектов политики паролей, определенных в Active Directory (AD), который обеспечивает более полный контроль политики паролей внутри одного домена.
Локальные политики
Три категории политик безопасности в разделе локальных политик позволяют управлять разнообразными настройками безопасности на компьютерах Windows. Например, они обеспечивают применение политики аудита для выбора событий, вносимых в журналы событий безопасности Windows на серверах; использование процедуры назначения прав пользователя при определении пользователей, имеющих право доступа к определенному набору серверов и рабочих станций через удаленный рабочий стол; запрет или разрешение активности и переименования учетной записи администратора на определенном наборе компьютеров.
Применять политику аудита достаточно просто; с ее помощью можно определить типы событий, записываемых в журнал событий безопасности Windows. Здесь можно указать успешные и/или ошибочные события для аудита различных типов, от доступа к AD до доступа к системному объекту (например, файлу или разделу реестра). В зависимости от места привязки объекта GPO, определяющего события аудита, можно включить аудит на контроллерах домена или членах-серверах и рабочих станциях. Например, если привязать GPO, содержащий политику аудита, которая разрешает аудит доступа к службе каталогов, к организационной единице Domain Controllers, то объект будет обрабатываться всеми контроллерами в домене и, таким образом, весь доступ к AD будет регистрироваться на DC, который обслужил запрос доступа.
Назначение прав пользователя — еще один мощный инструмент безопасности в арсенале групповой политики. С его помощью можно определять, какие пользователи могут совершать те или иные действия на конкретном компьютере. Пример прав пользователя: право Logon Locally позволяет определить, кто может выполнить интерактивную регистрацию с консоли сервера или рабочей станции; право Load and Unload Device предоставляет группе или пользователю возможность устанавливать драйверы устройств, в частности драйверы принтеров и дисплея. Создавая объект GPO, привязанный на уровень домена, и назначая право Deny Log on Locally группе Authenticated Users, администратор фактически запрещает всем пользователям домена AD регистрироваться на рабочих станциях. Конечно, цель данного примера — не научиться нарушать работоспособность, а показать, насколько широки возможности назначения прав пользователей и как осторожно следует их использовать. Как и при работе с другими настройками политики, необходимо убедиться, что объект GPO, в котором устанавливаются права пользователя, применяется только к нужным компьютерам, а права назначаются правильно выбранным группам пользователей.
Еще одна особенность назначения прав пользователей заключается в том, что список прав, отображаемых в редакторе групповой политики, зависит от версии Windows, в которой редактируется групповая политика (то есть версии Windows, в которой запущен редактор). В новых версиях Windows, таких как Server 2008 и Vista, больше прав пользователей, чем в старых версиях, в частности Windows XP. Поэтому, если право пользователя определено в объекте GPO в Vista и этот GPO применяется на компьютере XP, на котором не реализовано данное право пользователя, XP обработает политику, но затем игнорирует ее.
Можно быстро сравнить различия в настройках безопасности между версиями Windows, загрузив таблицы Group Policy Settings Reference, опубликованные компанией Microsoft для каждой версии Windows по адресу download.microsoft.com. Запустите поиск по ключевым словам «Group Policy Settings Reference», чтобы найти таблицы для каждой версии. В таблицах содержится список всех стандартных административных шаблонов для данной версии, а также настройки безопасности.
Назначение прав пользователя, как и некоторые другие области безопасности Windows, можно применять для настройки ролей, определяющих круг действий, выполняемых различными пользователями. Встроенные группы, такие как операторы сервера и операторы архива, — просто группы, которым предоставлены права и разрешения для использования других ресурсов компьютера. Безусловно, можно создать группу администраторов настольных компьютеров и предоставить ей право выполнять любые задачи на компьютерах Windows, не включая членов этой группы в группу администраторов на каждом компьютере.
Последняя область в разделе локальных политик редактора групповой политики — параметры безопасности, которые находятся ниже параметров безопасности локальных политик. Я называю эти настройки элементами управления уязвимостью, так как они определяют настройки безопасности, управляющие способами определения мер безопасности компьютера. Например, в этом разделе можно задать требования к подписи пакета SMB на клиентах и серверах. Подписывание SMB — форма защиты соединения, при которой затрудняется доступ взломщиков к сетевым каналам между компьютерами с целью перехвата трафика. В этом разделе также можно управлять поведением функции контроля учетных записей UAC в Vista, как показано на экране 2.
Вероятно, самая интересная особенность раздела параметров безопасности заключается в том, что список параметров безопасности, представленный в этом разделе, хотя и зависит от версии Windows, из которой запущен редактор групповой политики, может быть изменен вручную. Список настраивается с помощью базового файла, sceregvl.inf, который находится в папке%windir%inf на настраиваемом компьютере. Внутри этого файла определены все политики, представленные в параметрах безопасности, и файл можно изменить, добавив в него дополнительные настройки, которыми нужно управлять через групповую политику. Дополнительные сведения об этом файле можно получить по адресу support.microsoft.com/kb/214752.
Политика групп с ограниченным доступом
Цель политики групп с ограниченным доступом — предоставить механизм для управления локальным членством на рабочих станциях и автономных серверах, членах домена.
Например, можно использовать политику групп с ограниченным доступом, чтобы только сотрудники службы поддержки были членами группы пользователей удаленного рабочего стола на всех рабочих станциях. Существует два режима применения групп с ограниченным доступом — Members и Member Of. Режим Members — более строгий. Членами локальной группы на наборе рабочих станций являются только перечисленные пользователи и группы, а все остальные группы и пользователи удаляются (за исключением локальной учетной записи администратора, к которой политика групп с ограниченным доступом не применяется). Однако в режиме Members Of можно неэксклюзивно добавлять пользователей и группы в другие группы. Другими словами, можно создать политику, чтобы всегда вводить группу администраторов настольных компьютеров в состав группы локальных администраторов на каждом компьютере, который обрабатывает политику. В этом случае администраторы настольных компьютеров добавляются в группу локальных администраторов, но члены всех остальных групп остаются незатронутыми.
Новые предпочтения групповой политики, которые появились в Server 2008, но могут применяться в XP и более поздних версиях операционной системы, также обеспечивают управление группами внутри области политик Computer (и User) Configuration PreferencesControl Panel SettingsLocal Users and Groups. С помощью этой функции можно выполнять такие задачи, как переименование групп и выборочное добавление и удаление конкретных пользователей и групп. Предпочтения групповой политики — гораздо более гибкий вариант политики групп с ограниченным доступом, их рекомендуется использовать в качестве альтернативы в случаях, когда группы с ограниченным доступом полезны, но нужно избежать имеющихся у них ограничений.
И последнее об использовании групп с ограниченным доступом и предпочтений групповой политики. Возникает соблазн использовать эти политики для управления членством в группах AD. Но в действительности эти политики не предназначены для использования в среде AD со многими хозяевами, и могут возникать неприятные ситуации, если групповая политика в различные моменты времени применяет изменения членства в группах с разных контроллеров домена DC. Это может привести к осложнениям, так как членство в группах реплицируется из DC, который инициировал изменение. Поскольку групповая политика обрабатывается одинаково всеми DC в домене, каждый DC обработает идентичные изменения членства в группах AD, как указано политикой групп с ограниченным доступом, и, в сущности, начинается «пинг-понг» идентичных репликационных изменений членства в группах по всем контроллерам домена, в зависимости от времени обработки политики каждым DC.
Политика системных служб
Политика системных служб позволяет управлять службами Windows, запускаемыми на данном компьютере. Кроме того, с ее помощью можно управлять разрешениями службы. Например, можно использовать эту область политики, чтобы предоставить только администраторам сервера возможность останавливать и запускать службу Print Spooler на всех серверах Windows, функционирующих как серверы печати. Политику системных служб можно применить, чтобы предоставить избранной группе возможность выполнить определенную задачу, хотя члены этой группы и не будут являться администраторами соответствующих компьютеров.
Предпочтения групповой политики, расположенные в разделе Computer ConfigurationPreferencesServices, также предоставляют политику для управления системными службами. Эта функция обеспечивает дополнительный контроль настроек, в том числе возможность изменять учетную запись службы и пароль учетной записи службы на нескольких компьютерах. Последняя возможность чрезвычайно полезна, так как в прошлом, если служба выполнялась на нескольких компьютерах в контексте учетной записи пользователя, приходилось посещать каждый компьютер, на котором требовалось изменить пароль учетной записи пользователя. В результате многие компании старались не менять пароль учетной записи службы, что представляло большой риск для безопасности, потому что многие учетные записи служб — привилегированные по сравнению с учетными записями пользователей. Кроме того, предпочтения групповой политики обеспечивают механизм «проталкивания» изменения на все компьютеры, что позволяет регулярно менять пароль учетной записи службы.
Политики реестра и файловой системы
Эти политики обеспечивают возможность централизованно назначать разрешения для файловой системы и разделов реестра. Например, требуется обезопасить определенный файл или папку, которая существует на всех настольных компьютерах, таких как файл HOSTS рабочей станции, чтобы вредные программы, проникшие в компьютер, не могли легко изменить этот файл. В таком случае политика файловой системы позволяет централизованно задать разрешения и наследование разрешений, которые должны существовать для этого файла на всех компьютерах, обрабатывающих политику. Но в целом политики безопасности файловой системы и реестра нечасто используются для централизованного управления безопасностью файловой системы и реестра, а их неправильное применение порождает проблемы. Эти политики не могут эффективно применяться для смены разрешений для больших деревьев файлов и папок или разделов реестра. Они просто непригодны для решения этой задачи при обработке групповой политики; известно, что иногда быстродействие компьютера при обработке политики резко снижается. Проблема усугубляется, так как по умолчанию политика безопасности автоматически обновляется через каждые 16 часов, даже если политика не изменялась.
Если нужно несколько ограничить разрешения файловой системы или реестра, рекомендуется использовать какой-нибудь иной метод, без групповых политик, например сценарии, шаблоны безопасности или инструменты безопасности независимых поставщиков. Но эти политики можно использовать, если назначаются разрешения лишь небольшому числу файлов, папок или разделов реестра. Данный способ может оказаться наиболее удачным для защиты ключевых ресурсов, учитывая цикличный метод обработки групповой политики.
Ограничения для приложений
В идеальном случае администратор указывает каждый процесс, который может запустить пользователь, и исключает все лишние процессы. Таким образом удается избежать запуска нежелательных программ, неосмотрительно установленных пользователями. Таков общий подход политик ограниченного применения программ Software Restriction Policies (SRP), которые находятся в каталоге Computer and User ConfigurationWindows Settings Security SettingsSoftware Restriction Policies. В сущности, через разнообразные механизмы правил можно определять программы, которые разрешено выполнять.
SRP можно настроить для работы в трех режимах. В режиме по умолчанию можно выполнять любые программы, и администратор явно запрещает конкретные приложения и сценарии. Этот процесс называют внесением в черный список (blacklisting), и, хотя организовать его просто, надежность этого метода невысока из-за слишком большого элемента неизвестности и невозможности указать каждую программу, которую могут попытаться запустить пользователи.
Второй режим предполагает составление белого списка (whitelisting) и представляет собой самый надежный вариант SRP, но требует больших усилий от администратора. В этом режиме можно установить по умолчанию уровень выполнения Disallowed, то есть запретить выполнение любых программ, кроме программ ядра Windows и явно указанных приложений и сценариев. Режим по умолчанию можно назначить в папке Security Levels, вложенной в Software Restriction Policies, как показано на экране 3.
Включая этот режим, необходимо создать правила, указывающие разрешенные программы. Для этого нужно знать, какие процессы будут запускать пользователи, и своевременно удовлетворять их потребности в новых приложениях. Задача управления белыми списками очень трудоемка, но обеспечивает высокую безопасность среды, если пользователи работают с ограниченным количеством приложений. Например, при внесении в белый список приложений, которые разрешено выполнять, пользователи не могут запустить неосмотрительно загруженные вредные программы, так как их нет в списке одобренных приложений. Разрешенные и запрещенные приложения задаются с использованием правил SRP, описанных ниже.
Последний режим, называемый Basic user, впервые появился в Vista, но поддерживается и в XP. В случаях когда пользователи работают как администраторы и администратор устанавливает уровень по умолчанию Basic user, из всех процессов, запускаемых администратором, удаляются административные маркеры, что, в сущности, приводит к выполнению процесса от лица пользователя без административных привилегий. Такой подход полезен, если нужно добиться, чтобы администраторы не запускали определенные процессы от имени административных учетных записей.
Основа подхода к использованию SRP состоит в том, чтобы сначала установить уровни безопасности по умолчанию в значение Unrestricted, Disallowed или Basic user. Затем можно подготовить правила, используя папку Additional Rules в Software Restriction Policy, как показано на экране 4. Эти дополнительные правила вводят исключения, чтобы разрешить или запретить запуск конкретных процессов. В SRP существует четыре типа правил: хеша, пути, сертификатов и сетевой зоны.
Правила хеша. Правила хеша используются, чтобы уникально идентифицировать выполняемый фрагмент программного кода. При использовании правила хеша выбирается определенная версия программы или сценария, и только эта конкретная версия обозначается как разрешенная (Unrestricted) или запрещенная (Disallowed). Если пользователь переименовывает исполняемый файл, хеш остается действительным, а пользователь блокируется, если установлено значение Disallowed. Но при каждом изменении версии приложения необходимо подготовить новое правило хеша, чтобы отразить это изменение. Если существуют различные версии приложения для разных выпусков Windows, то для каждой версии необходимо собственное хеш-правило. Правила такого типа неудобно обслуживать при большом количестве приложений, но они очень надежны, если требуется запретить или разрешить конкретное приложение. Хеш-правило составляется в редакторе групповой политики во время добавления исполняемого файла в политику.
Правила пути. Правила пути более гибкие, чем правила хеша. С их помощью можно указать путь в файловой системе, где хранится исполняемый код, и разрешить или запретить все программы, содержащиеся на этом пути (и в дочерних папках). Определяя правила, можно использовать подстановочные символы и переменные среды, чтобы сделать правила еще более гибкими. Недостаток правил пути заключается в том, что они хороши лишь настолько, насколько удачны разрешения в локальной файловой системе. Правило пути окажется бесполезным, если пользователи могут обойти его, просто скопировав нужную им программу в другую папку. Например, места хранения временных файлов обычно открыты для записи со стороны пользователей, поэтому нужно подготовить правило пути, которое запрещает выполнять любой программный код из папок временных файлов в Windows. Таким образом, оптимальным решением может оказаться комбинация правил пути, правил хеша и строгие разрешения файловой системы.
Правила сертификатов и сетевой зоны. Эти правила используются реже остальных. Правило сертификатов позволяет указать программу, которая может запускаться в зависимости от лица, подписавшего программный код с использованием сертификатов открытого ключа. Недостаток этих правил — в необходимости подписывать все запускаемые программы, что не всегда возможно. Правила сетевых зон позволяют управлять способами установки файлов в зависимости от их происхождения, но почти бесполезны, так как применяются только к файлам Windows Installer (.msi). Кроме того, правило игнорируется, если пользователь загружает файл setup.exe.
Ограничения для устройств
Контроль действий, совершаемых пользователями над важными бизнес-данными, столь же необходим, как и контроль выполнения программ. Защита данных предполагает не только обеспечение безопасности хранилища, но и контроль действий пользователей, которые могут физически изъять данные из компьютеров. Стоимость миниатюрного USB-накопителя емкостью в несколько гигабайтов — всего 20 долл., и злоумышленник может просто незаметно унести корпоративные данные в кармане. Решить проблему помогут накладываемые на устройства ограничения на основе групповой политики. Эти ограничения для устройств появились в Server 2008 и Vista и задаются в Computer (или User Configuration)Administrative TemplatesSystemRemovable Storage Access. Можно запретить доступ для чтения или записи (или и то и другое) для любого класса сменных носителей, в том числе USB-накопителей, записываемых CD- и DVD-дисков, и сменных жестких дисков, как показано на экране 5.
В прошлом ввести ограничения для устройств, подключаемых к настольным компьютерам с операционными системами, предшествующими Vista, можно было только с помощью продуктов независимых производителей. Но с появлением предпочтений групповой политики ограничения для устройств распространены и на Windows Server 2003 и XP. Можно разрешить или запретить определенные классы устройств по их уникальному идентификатору в Computer (User) ConfigurationPreferencesControl Panel SettingsDevices. Эта функция не обеспечивает достаточной детализации, чтобы управлять возможностью чтения, но не записи, как рассмотренная ранее политика для устройств Vista, но, по крайней мере, можно создать набор политик, которые ограничивают, например, все сменные устройства хранения, как показано на экране 6.
Безопасность IE
Вероятно, сложнее всего настроить с помощью групповой политики браузер IE. Причина заключается в том, что существует по крайней мере три различных способа настроить IE через групповую политику. Первый способ настроить IE — задействовать политику настройки IE (в User ConfigurationWindows SettingsIE Maintenance Policy). Второй способ — применить административный шаблон политик (в Computer — или User — ConfigurationAdministrative TemplatesWindows ComponentsInternet Explorer). Третий метод — настроить IE с использованием предпочтений групповой политики (в User ConfigurationPreferencesControl Panel SettingsInternet Settings).
У каждого из перечисленных вариантов есть свои достоинства и недостатки. Например, если нужно настроить такие параметры, как proxy-сервер или домашняя страница IE, можно применить политику настройки IE или предпочтения групповой политики. По возможности рекомендуется использовать предпочтения групповой политики, так как политика настройки IE давно известна как не очень надежное средство доставки параметров политики клиентам. Конечно, в большинстве случаев предпочтения групповой политики — всего лишь предпочтения. Они не запрещают пользователям изменять, например, настройки proxy-серверов, как политика настройки IE. Так что, если для управления, например, настройками proxy-сервера применяются предпочтения групповой политики, необходимо использовать административный шаблон политик для отключения страницы в IE, которая позволяет пользователям обращаться к этим настройкам. Цель политики безопасности IE — не позволять посетителям Web-узлов загружать сомнительные материалы. Используя такие возможности, как принудительное назначение proxy-сервера, можно сделать так, чтобы пользователи обращались в Internet только через контролируемый proxy-сервер. Блокируя элементы IE в административном шаблоне политик, можно предотвратить изменение конфигурации IE пользователем, который пытается обойти установленные ограничения.
Если требуется настроить зональную безопасность IE (чтобы централизованно определять безопасные Web-узлы) или внести адреса Web-узлов в списки блокировки всплывающих окон или зоны безопасности, то для управления этими параметрами можно использовать все три метода. Каждый метод имеет свои особенности и располагает различными наборами параметров. Например, можно задействовать политики в Computer (или User) Configuration Administrative TemplatesWindows ComponentsInternet ExplorerInternet Control PanelSecurity Page для настройки безопасности каждой зоны IE (надежные узлы, местная, Internet), а также списка сопоставления узлов и зон, с помощью которого можно указать, какие Web-узлы вносятся в каждую зону безопасности для пользователей. Если применяется данный метод, пользователи не смогут добавлять узлы или изменять эти параметры в IE — они будут полностью блокированы. Но если используется политика настройки IE, то можно настроить зональную безопасность и сопоставить узлы зонам, но пользователи все же смогут добавлять Web-узлы в зону. Наконец, если используются предпочтения групповой политики, то можно настроить зонную безопасность, но нельзя добавлять Web-узлы к зонам. Однако предпочтения групповой политики обеспечивают полный доступ ко всем настройкам на вкладке Advanced в свойствах IE (см. экран 7), чего не обеспечивают два других метода.
Полезные ресурсы для начинающих
Для настройки одного и того же набора параметров нередко существует несколько методов, но некоторые задачи по обеспечению безопасности настольного компьютера нельзя выполнить с помощью групповой политики. Начать работу рекомендуется с изучения руководств по безопасности для Vista и XP, опубликованных Microsoft. Загрузить их можно с сайта download.microsoft.com, выполнив поиск по ключевым словам Security Guide. В этих документах приведены оптимальные методы настройки безопасности настольных компьютеров, а также шаблоны безопасности и таблицы параметров, в которых определены надежные конфигурации. Кроме того, компания Microsoft предоставляет программу GPO Accelerator (www.microsoft.com/downloads/details.aspx?FamilyID=a46f1dbe-760c-4807-a82f-4f02ae3c97b0) с заранее подготовленными объектами GPO, которые можно импортировать и использовать для реализации оптимальных методов, указанных в руководствах по безопасности. Готовые объекты GPO не всегда точно соответствуют потребностям администратора, но могут служить отправной точкой для реализации и тестирования безопасной конфигурации сети.
Даррен Мар-Элиа (dmarelia@windowsitpro.com) — редактор Windows IT Pro, технический директор и учредитель компании SDM Software
Просмотр настроек UAC в параметрах безопасности