Вы находитесь на странице: 1из 326

Руководства

Реагируй быстро. Достигай большего.

Руководство по безопасности
Windows Server® 2008
Версия 1.0
Опубликовано: февраль 2008
Самую свежую информацию можно найти на сайте
microsoft.com/wssg
Copyright © 2008 Microsoft Corporation. Все права защищены. Вы несете полную ответственность за
выполнение законов об авторском праве. Если вы используете данную документацию и предоставляете
отзывы, вы принимаете лицензионное соглашение, представленное ниже.

Использование данной документации исключительно в некоммерческих целях внутри ВАШЕЙ компании


или организации регламентируется лицензионным соглашением Creative Commons «Некоммерческая
лицензия с указанием авторства». Копию этой лицензии можно найти по адресу
http://creativecommons.org/licenses/by-nc/2.5/ или получить по почте, отправив письмо в Creative
Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

Данная документация предоставляется исключительно в информационных целях и «КАК ЕСТЬ». Эти


материалы не могут заменить специальное обслуживание и документацию, которые может разработать
Корпорация Microsoft для конкретного пользователя, исходя из конкретных требований его среды. В той
мере, в какой это позволяет закон, MICROSOFT НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ, НЕ БЕРЕТ НА СЕБЯ
НИКАКОЙ ОТВЕТСТВЕННОСТИ ЗА ВСЕ ВЫСКАЗАННЫЕ, ПОДРАЗУМЕВАЕМЫЕ И УСТАНОВЛЕННЫЕ ГАРАНТИИ
И НЕ НЕСЕТ ПЕРЕД ВАМИ НИКАКОЙ ОТВЕТСТВЕННОСТИ ЗА ЛЮБОЙ УЩЕРБ, ПОНЕСЕННЫЙ В СВЯЗИ С
ИСПОЛЬЗОВАНИЕМ ДАННЫХ МАТЕРИАЛОВ ИЛИ ЛЮБОЙ ВКЛЮЧЕННОЙ В НИХ ИНТЕЛЛЕКТУАЛЬНОЙ
СОБСТВЕННОСТИ.

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

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

Microsoft, Active Directory, Authenticode, MS-DOS, Win32, Windows, Windows Server, Windows Vista и
Windows XP являются или зарегистрированными торговыми марками, или торговыми марками корпорации
Microsoft в Соединенных Штатах и/или других странах.

Упоминаемые названия реальных компаний и продуктов могут являться торговыми марками их


владельцев.

Вы не обязаны предоставлять Microsoft какие-либо предложения, комментарии или отзывы (Отзыв)


относительно данной документации. Однако если вы все-таки предоставили Отзыв Microsoft, вы
безвозмездно предоставляете Microsoft право использовать, распространять и получать прибыль от этого
любым способом и в любых целях. Также вы безвозмездно предоставляете третьим лицам все патентные
права, необходимые для использования или взаимодействия их продуктов, технологий и служб с
определенными частями программного обеспечения или службы Microsoft, включающими ваш Отзыв. Вы
не должны предоставлять Отзыв, использование которого в ПО или документации потребует от Microsoft
лицензирования от третьих лиц.
Обзор
Добро пожаловать в Руководство по безопасности Windows Server 2008. В нем
представлены инструкции и рекомендации по повышению безопасности
компьютеров, на которых установлена Windows Server® 2008 и которые являются
участниками домена Active Directory®.
Кроме методологических принципов, данное руководство включает инструменты,
пошаговые процедуры, рекомендации и процессы, существенно упрощающие
развертывание. Это не просто руководство по эффективной настройке системы
безопасности, вам предлагается воспроизводимый метод для применения этих
рекомендаций, как к среде тестирования, так и к рабочей среде.
Ключевым инструментом, предоставляемый данным руководством, является
GPOAccelerator. С его помощью можно выполнять сценарий, который
автоматически создает все объекты групповой политики (Group Policy objects,
1
GPOs), необходимые для реализации данного руководства по безопасности . Книга
«Сборник параметров используемых в руководстве по безопасности Windows
Server 2008», сопровождающая данное Руководство по безопасности Windows
Server 2008, является еще одним ресурсом, который может использоваться для
определения и сравнения настроек групповой политики.
Данное нормативное руководство было представлено на рассмотрение проектным
группам, консультантам, специалистам технической поддержки, партнерам и
клиентам Microsoft, что обеспечило его:
 Достоверность. Руководство основывается на практическом опыте.
 Авторитетность. Руководство предлагает лучшие из существующих
рекомендаций.
 Точность. Руководство проверено и протестировано с технической точки
зрения.
 Практическую применимость. Руководство предлагает конкретные шаги
для достижения успеха.
 Уместность. Руководство решает реальные вопросы, связанные с
обеспечением безопасности.
Microsoft были опубликованы руководства по безопасности для Windows
Server 2003 и Windows 2000 Server. Данное руководство описывает значительные
улучшения в обеспечении безопасности, внесенные в Windows Server 2008.
Руководство было разработано и протестировано на компьютерах с Windows
Server 2008, объединенных в домен, использующий Службы каталогов Active
Directory® (Active Directory® Domain Services, AD°DS).
Операционная система продолжает развиваться и изменяться, поэтому с выходом
следующих ее версий можно ожидать появления и обновленных версий данного
руководства, которые будут включать новые возможности, связанные с
обеспечением безопасности. Также предлагаются руководства по развертыванию и
эксплуатации Windows Server 2008. Больше информации обо всех доступных
руководствах представлено на сайте TechNet в разделе Solution Accelerators.

1
В русской версии ОС не все объекты могут быть созданы из-за проблем с
именованием (прим. научного редактора).
Краткий обзор
ИТ-безопасность касается всех. Каждый день рекламодатели пытаются проникнуть
в ваши сети и получить доступ к вашим серверам, чтобы взломать их,
инфицировать вирусами или похитить информацию о клиентах и служащих. Угроза
поступает со всех сторон: от служащих, находящихся внутри сети и посещающих
Веб-сайты, инфицированные вредоносными программами, до внешних
подключений пользователей через виртуальные частные сети (virtual private
networks, VPNs), подключений сети филиала к серверам предприятия или прямых
нападок на уязвимые компьютеры или серверы вашей сети. Сегодня любые
организации, как большие, так и маленькие, также сталкиваются с повышенными
требованиями аудита.
Вы не понаслышке знаете, какую важную роль в обеспечении нормального
функционирования организации играют серверы. Данные, которые на них хранятся,
и службы, которые они предоставляют, – это жизнь организации. А ваша задача –
обеспечить безопасность этих жизненно важных элементов, не допустить, чтобы
они были взломаны или пали жертвой атак извне и изнутри организации, и доказать
контролирующим органам, что вы предпринимаете все необходимые шаги для
обеспечения их безопасности.
Windows Server 2008 с самого начала разрабатывалась с учетом вопросов
безопасности и предлагает целый ряд новых и улучшенных технологий
безопасности и компонентов, которые обеспечивают надежную базу для ведения и
построения вашего бизнеса. Руководство по безопасности Windows Server 2008
создано с учетом всех преимуществ компонентов и опций безопасности в
Windows Server 2008, что будет еще более способствовать улучшению
безопасности серверов вашей организации.
Данное руководство построено на базе Windows Server 2003 Security Guide
(Руководство по безопасности Windows Server 2003), в котором представлены
специальные рекомендации по повышению уровня защиты серверов с
Windows Server 2003 и Пакетом обновления 2 (SP2). Windows Server 2003 Security
Guide предлагает рекомендации по повышению безопасности серверов,
использующих базовые настройки безопасности для двух сред:
 Среда корпоративных клиентов (Enterprise Client, EC). Серверы в
данной среде располагаются в домене, который использует AD DS и
обменивается информацией с серверами с установленными Windows
Server 2008 или Windows Server 2003 SP2 или более поздними версиями.
Клиентские компьютеры в этой среде могут работать с разными ОС: на
некоторые установлена Windows Vista®, тогда как на другие – Windows XP с
SP2 или более поздние версии. Информация о базовых настройках
безопасности, используемых в этой среде, представлена в Приложении А
«Параметры групповой политики, связанные с безопасностью».
 Специальная безопасная среда с ограниченной функциональностью
(Specialized Security – Limited Functionality, SSLF). Безопасность этой
среды настолько важна, что допускается существенное ограничение
функциональности и управляемости. Например, компьютеры военных и
разведывательных органов работают в такой среде. На серверы в данной
среде устанавливается только Windows Server 2008. Информацию о
параметрах SSLF, используемых этой средой, можно найти в Приложении А
«Параметры групповой политики, связанные с безопасностью».
Внимание Параметры безопасности SSLF предназначены лишь для ограниченного
круга организаций. Конфигурация этих параметров разработана для организаций, в
которых обеспечение безопасности важнее, чем обеспечение функциональности.
Данное руководство организовано таким образом, чтобы можно было без труда
находить необходимую информацию. Руководство и прилагаемые к нему
инструментальные средства помогут:
 Установить и развернуть в вашей сетевой среде любые заданные базовые
настройки безопасности.
 Определить и использовать компоненты безопасности Windows Server 2008
для основных сценариев безопасности.
 Определить назначение каждого отдельного параметра любых базовых
настроек безопасности и понять их важность.
Для создания, тестирования и развертывания параметров безопасности любой из
представленных сред, среды EC или среды SSLF, вам понадобиться скачать
GPOAccelerator для Руководства по безопасности Windows Server 2008 и
практическое руководство по работе с этим инструментом. Данный инструмент
автоматически создает все объекты GPO для рекомендуемых этим руководством
параметров безопасности. Инструкции по выполнению этих задач с помощью
данного инструмента можно найти в руководстве How to Use the GPOAccelerator
(Как использовать GPOAccelerator).
Данное руководство ориентировано, главным образом, на корпоративных
заказчиков. Чтобы извлечь максимальную пользу из этого материала, его
необходимо прочитать полностью. Однако при выполнении конкретных задач
можно знакомиться с отдельными частями. В разделе «Обзор глав» кратко
представлена информация, предлагаемая в руководстве. Больше информации по
безопасности и параметрам безопасности, связанными с Windows Server 2008,
можно найти в книге «Сборник параметров используемых в руководстве по
безопасности Windows Server 2008» и сопроводительном руководстве Threats and
Countermeasures (Угрозы и контрмеры).

Кто должен прочитать это руководство


Руководство по безопасности Windows Server 2008 предназначено, главным
образом, для ИТ-специалистов, специалистов по безопасности, архитекторов
сетей, специалистов по вычислительной технике и других консультантов по
вопросам ИТ, которые занимаются планированием разработки приложений или
сред и развертывания Windows Server 2008 для серверов в среде предприятия.
Данное руководство не для пользователей домашних ПК, оно ориентировано на
тех, в чьи профессиональные обязанности входит одна или более из следующих
ролей:
 Специалист по обеспечению безопасности. Пользователи,
выполняющие эту роль, занимаются обеспечением безопасности между
разными платформами в рамках организации. Специалистам по
обеспечению безопасности необходимо надежное справочное руководство,
рассматривающее задачи по обеспечению безопасности на всех уровнях
организации и также предлагающее проверенные методы реализации
защитных контрмер по усилению безопасности. Специалисты по
безопасности определяют компоненты и параметры безопасности и дают
рекомендации того, как клиенты могут наиболее эффективно их
использовать в среде с повышенными рисками безопасности.
 ИТ-специалисты, сотрудники службы технической поддержки и
специалисты по развертыванию. Основной задачей ИТ-специалистов
является интеграция безопасности и управление изменениями в процессе
развертывания, тогда как специалисты по развертыванию занимаются
оперативным обеспечением обновлений безопасности. Сотрудники,
выполняющие эти роли, также выявляют проблемы безопасности
приложений, связанные с установкой, настройкой и улучшением
используемости и управляемости программного обеспечения. Они
отслеживают этот тип проблем, чтобы найти возможность улучшения
безопасности с минимальным изменением важных бизнес-приложений.
 Архитектор и планировщик сетей. Пользователи, выполняющие эту роль,
управляют процессами построения архитектуры компьютерных сетей в
своих организациях
 Консультант. Пользователи, выполняющие эту роль, занимаются
сценариями безопасности, которые распространяются на все бизнес-уровни
организации. ИТ-консультанты, как из служб Microsoft, так и со стороны
партнеров, используют инструменты передачи знаний корпоративным
заказчикам и партнерам.
Примечание Желающие применить представленное здесь нормативное руководство на
практике, должны, как минимум, прочитать руководство How to Use the GPOAccelerator (Как
использовать GPOAccelerator) и выполнить все предлагаемые в нем шаги по организации
среды EC.

Навыки и подготовка
Перечисленными ниже знаниями и навыками должны обладать консультанты,
персонал, штат службы технической поддержки и развертывания и специалисты по
безопасности, которые занимаются разработкой, развертыванием и обеспечением
безопасности серверных систем с установленной Windows Server 2008 в
организации предприятия:
 Сертификат MCSE по Microsoft Windows Server 2003 или более поздней
версии и два или более года опыта работы с безопасностью или
эквивалентные этим знания.
 Доскональное знание домена и среды Active Directory организации.
 Опыт работы с Консолью управления групповой политикой (Group Policy
Management Console, GPMC)
 Опыт администрирования Групповой политики с использованием GPMC,
обеспечивающей единое решение для управления всеми связанными с
групповой политикой задачами.
 Опыт использования инструментов управления, включая Консоль
управления Microsoft (Microsoft Management Console, MMC), Gpupdate и
Gpresult.
 Опыт использования Мастера настройки безопасности (Security
Configuration Wizard, SCW)
 Опыт развертывания приложений и серверов в средах предприятий.
Цели руководства
Основной целью данного руководства является научить вас:
 С помощью руководства эффективно создавать и применять прошедшие
тестирование базовые конфигурации, используя групповую политику.
 Понимать, почему в руководстве предлагаются именно такие рекомендаций
по настройке параметров безопасности в базовых конфигурациях, и
результаты их использования.
 Выявлять и рассматривать основные сценарии безопасности и затем
использовать специальные компоненты безопасности, предлагаемые в
Windows Server 2008, для управления сценариями в вашей среде.
 Понимать ролевую безопасность для разных рабочих нагрузок в Windows
Server 2008.
Данное руководство спланировано так, что можно использовать только отдельные
его части, которые помогут выполнить требования конкретной организации. Тем не
менее, максимальную пользу принесет прочтение всего руководства.

Область рассмотрения руководства


Основное внимание данное руководство уделяет созданию и обслуживанию
безопасной среды для серверов с установленной Windows Server 2008.
Руководство объясняет разные этапы обеспечения безопасности двух разных сред
и то, что определяет каждый параметр безопасности для серверов, развернутых в
каждой из сред. Руководство предлагает нормативные сведения и рекомендации по
обеспечению безопасности.
На клиентских компьютерах в среде EC может быть установлена:
 либо Windows XP с SP2 или более поздняя версия,
 либо Windows Vista.
Тем не менее, на серверах, управляющих этими клиентскими компьютерами в
сети, должны быть установлены:
 Windows Server 2008 или
 Windows Server 2003 с SP2 или более поздняя версия.
На клиентских компьютерах в среде SSLF может быть установлена только
Windows Vista, а на управляющих ими серверах – только Windows Server 2008.
В данное руководство включены главы с рекомендациями по безопасности,
касающимися повышения уровня защиты следующих ролей сервера и служб роли,
которые они предоставляют:
 Доменных служб Active Directory (AD DS)
 DHCP-сервера
 DNS-сервера
 Веб-сервера (IIS)
 Файловых служб
 Служб печати
 Служб сертификации Active Directory (AD CS)
 Служб политики сети и доступа
 Служб терминалов
Примечание Сведения о настройке роли сервера, такие как пошаговое руководство по
настройке конкретных ролей, не представлены в данном руководстве. Сюда включены
только параметры безопасности, доступные в рекомендуемой операционной системе. Больше
сведений о настройке для Windows Server 2008 можно найти на Веб-странице Windows
Server 2008 Step-by-Step Guides (Пошаговые руководства Windows Server 2008) Центра
загрузки Microsoft.
В данное руководство не включены рекомендации по повышению уровня защиты
для следующих ролей сервера:
 Службы федерации Active Directory
 Службы Active Directory облегченного доступа к каталогам
 Службы управления правами Active Directory
 Сервера приложений
 Факс-сервера
 Hyper-V
 Службы потоковой передачи медиаданных
 Службы UDDI
 Службы развертывания Windows
Все параметры безопасности Windows Server 2008 подробно обсуждаются в
сопроводительном руководстве Threats and Countermeasures (Угрозы и контрмеры).

Необходимые руководства и инструменты


Пакет руководства включает следующие документы и книги:
 «Руководство по безопасности Windows Server 2008»
 Приложение А, «Параметры групповой политики, связанные с
безопасностью»
 «Справочник по поверхности атаки для Windows Server 2008»
 «Сборник параметров используемых в руководстве по безопасности
Windows Server 2008»
Примечание В книге «Справочник по поверхности атаки для Windows Server 2008»
(Windows Server 2008 Attack Surface Reference) представлены уникальные
идентификаторы CCE для каждого параметра. Идентификаторы CCE можно
использовать для обеспечения быстрого и точного согласования данных множества
информационных источников и инструментов.
Скачав руководство Windows Server 2008 Security Guide (Руководство по
безопасности Windows Server 2008) в Центре загрузки Microsoft, с помощью файла
Установщика Microsoft Windows (.msi) установите эти ресурсы на свой компьютер в
каталог по своему выбору. После этого можете скачать GPOAccelerator и
руководство по созданию, тестированию и развертыванию параметров
безопасности, описанных в «Руководстве по безопасности Windows Server 2008»,
для данного инструмента.
Примечание Для получения доступа к инструменту GPOAccelerator и документу How to Use
the GPOAccelerator, извлеките архив GPOAccelerator.zip для этих ресурсов.
Обзор глав
Данное издание «Руководства по безопасности Windows Server 2008» включает 11
глав и приложение, которое можно использовать как справочник по описаниям,
рекомендациям по применению и значениям параметров. Файл книги «Сборник
параметров используемых в руководстве по безопасности Windows Server 2008»,
сопровождающий руководство, предоставляет другой ресурс, который может
использоваться для сравнения и оценки параметров групповой политики. Кроме
того, в книге «Справочник по поверхности атаки для Windows Server 2008» сведена
воедино вся информация о службах, файлах и правилах брандмауэра, характерных
для каждой рассматриваемой в руководстве роли сервера. На следующем рисунке
представлена структура руководства, которая поможет найти оптимальные пути
реализации и развертывания нормативного руководства.

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

Глава 1: Реализация базовых настроек безопасности


В данной главе обозначены преимущества, которые организация получает от
создания и развертывания базовых настроек безопасности. Эта глава включает
общие рекомендации по проектированию безопасности, которым можно следовать
при подготовке к реализации базовой безопасности EC или SSLF. В главе
объясняются подходы к обеспечению безопасности для обеих сред, EC и SSLF, и
основные отличия этих сред.
Сопровождающий данное руководство «Сборник параметров используемых в
руководстве по безопасности Windows Server 2008» является еще одним
источником, который может использоваться для сравнения и оценки параметров
групповой политики. Инструмент GPOAccelerator доступен как отдельный пакет для
загрузки в Центре загрузки Microsoft. Инструкции по применению этого инструмента
представлены в книге How to Use the GPOAccelerator.
Внимание Данная глава ориентирует вашу организацию на установку среды SSLF, которая
отличается от среды EC. Руководство по SSLF предназначается только для сред с высоким
уровнем безопасности. Оно не является дополнением руководства для среды EC. Параметры
безопасности, определенные для среды SSLF, ограничивают ключевую функциональность в
среде. Поэтому базовые настройки безопасности SSLF не годятся для большинства
организаций. Прежде чем реализовывать базовые настройки безопасности SSLF в
производственной среде, они должны быть тщательнейшим образом протестированы.

Глава 2: Сокращение поверхности атаки посредством


роли сервера
В данной главе представлен обзор встроенных инструментов Windows Server 2008,
с помощью которых можно быстро настроить, сохранить и активировать всю
необходимую функциональность для серверов среды. В этой главе обсуждается,
как с помощью Диспетчера сервера можно сократить поверхность атаки ваших
серверов за счет настройки только необходимой функциональности каждой роли
сервера.
Также в главе обсуждается использование Мастера настройки безопасности (SCW)
для сохранения и активации настроек, реализованных Диспетчером сервера. В
главе представлена информация о Server Core, новой опции установки в Windows
Server 2008.

Глава 3: Повышение уровня защиты доменных служб


Active Directory
В данной главе обсуждаются возможности повышения уровня защиты Доменных
служб Active Directory (AD DS) для управления пользователями и ресурсами,
такими как компьютеры, принтеры и приложения в сети. AD DS в Windows
Server 2008 включают ряд новых возможностей, которые были недоступны в
предыдущих версиях Windows Server, и основной задачей некоторых из них
является более безопасное развертывание AD DS. К функциям, повышающим
безопасность в AD DS, относятся возможности аудита, расширенные политики
паролей и возможность использования контроллеров домена только для чтения
(RODCs).

Глава 4: Повышение уровня защиты служб DHCP


Данная глава предлагает нормативное руководство по повышению уровня защиты
роли DHCP-сервер. В главе обсуждаются службы DHCP-сервер и DHCP-клиент в
Windows Server 2008, включающие улучшения безопасности для Защищенного
сетевого доступа (Network Access Protection, NAP) и функциональность DHCPv6.

Глава 5: Повышение уровня защиты DNS-служб


Данная глава предлагает нормативное руководство по повышению уровня защиты
роли DNS-сервер. Windows Server 2008 обеспечивает улучшения DNS-сервера,
направленные, главным образом, на улучшение производительности или
обеспечение новых функций, включая фоновую загрузку зон, которая помогает
предотвратить потенциальные атаки типа отказ в обслуживании (DoS), и поддержку
контроллеров RODC, размещаемых на сетевом периметре, филиалов или других
небезопасных сред.

Глава 6: Повышение уровня защиты Веб-служб


Данная глава предлагает нормативное руководство по повышению уровня защиты
роли Веб-сервер. В главе обсуждается, как роль Веб-сервер устанавливает
Microsoft® Internet Information Services (IIS) 7.0, структура которой изменена и
разбита на сорок модульных компонентов, устанавливаемых по запросу.

Глава 7: Повышение уровня защиты файловых служб


Данная глава предлагает нормативное руководство по повышению уровня защиты
роли файлового сервера. Повышение уровня защиты файловых серверов может
представлять особую сложность, потому что обеспечение баланса между
безопасностью и функциональностью предоставляемых ими фундаментальные
служб – тонкое искусство. Windows Server 2008 представляет ряд новых
возможностей, которые помогут в управлении и улучшении защиты файлового
сервера в вашей среде.

Глава 8: Повышение уровня защиты служб печати


Данная глава предлагает нормативное руководство по повышению уровня защиты
роли сервера печати. Безопасность служб печати в операционной системе
Windows Vista претерпела существенные изменения. Эти изменения также
включены в Windows Server 2008, чтобы ваша организация могла в полной мере
воспользоваться обеспечиваемыми ими преимуществами.
Глава 9: Повышение уровня защиты служб
сертификации Active Directory
Данная глава предлагает нормативное руководство по повышению уровня защиты
служб сертификации Active Directory (AD CS) на сервере с установленной Windows
Server 2008. AD CS предоставляют настраиваемые службы для создания и
управления сертификатами открытого ключа, которые используются в программных
системах безопасности, построенных на технологиях открытого ключа. В главе
обсуждается, как организации могут повышать безопасность с помощью AD CS,
связывая удостоверение человека, устройства или службы с соответствующим
закрытым ключом.

Глава 10: Повышение уровня защиты служб политики


сети и доступа
Данная глава предлагает нормативное руководство по повышению уровня защиты
служб Политики сети и доступа на серверах с установленной Windows Server 2008.
Службы политики сети и доступа (Network Policy and Access Services, NPAS) в
Windows Server 2008 предоставляют технологии, обеспечивающие возможность
развертывания и работы виртуальной частной сети (VPN), удаленного доступа к
сети, защищенного по стандарту 802.1X проводного и беспроводного доступа и
устройств на базе технологии управления доступа в сеть (Network Admission
Control, NAC) Cisco.
В данной главе обсуждаются возможности использования NPAS для определения и
применения политик аутентификации и авторизации сетевого доступа, а также
безопасности клиента для сети с помощью Сервера сетевой политики (Network
Policy Server, NPS), Службы маршрутизации и удаленного доступа, Центра
регистрации работоспособности (Health Registration Authority, HRA) и протокола
авторизации учетных данных узла (Host Credential Authorization Protocol, HCAP).

Глава 11: Повышение уровня защиты служб


терминалов
Данная глава предлагает нормативное руководство по повышению уровня защиты
служб терминалов на серверах с установленной Windows Server 2008. Эти серверы
обеспечивают основные службы, с помощью которых пользователи получают
возможность доступа к программам Windows или всему рабочему столу Microsoft
Windows® из разных мест. Вы можете использовать ряд входящих в Windows
Server 2008 специальных служб роли, включая лицензирование служб терминалов
(TS Licensing) для управления клиентскими лицензиями служб терминалов
(Terminal Server client access licenses, TS CALS), которые необходимы устройствам
и пользователям для подключения к серверу терминалов.
В главе также обсуждается, как служба роли посредник сеансов службы
терминалов (Terminal Services Session Broker, S Session Broker) поддерживает
повторное подключение в существующему сеансу на сервере терминалов,
входящим в состав фермы серверов терминалов с балансировкой нагрузки; как
служба роли Шлюз служб терминалов (Terminal Services Gateway, TS Gateway)
позволяет авторизованным пользователям подключаться к серверам терминалов и
удаленным рабочим столам сети предприятия по Интернету, используя RDP через
HTTPS; и как служба роли Веб-доступ к службе терминалов (Terminal Services Web
Access,(TS Web Access) позволяет авторизованным пользователям получить
доступ к серверам терминалов через Веб-браузер.

Приложение А: Параметры групповой политики,


связанные с безопасностью
Приложение включает описания и таблицы, представляющие подробную
информацию о параметрах, определенных для базовой безопасности сред EC и
SSLF в данном руководстве. В приложении описываются все параметры и
основания применения заданных значений. Также в приложении обозначены
различия между Windows Server 2008 и Windows Server 2003.

Принятые обозначения
В данном руководстве действуют следующие соглашения о шрифтовом
оформлении.
Таблица 1.1. Принятые обзначения
Элемент Значение
Жирный шрифт Применяется для обозначения символов, вводимых точно,
как они представлены, включая команды, ключи и имена
файлов. Элементы пользовательского интерфейса также
выделяются жирным шрифтом.
Курсив Названия книг и других важных публикаций выделяются
курсивом.
<Курсив> Заполнитель, выделенный курсивом и заключенный в
угловые скобки <имяфайла>, представляет переменные.
Моноширинный Используется для примеров кода и сценариев.
шрифт
Примечание Обращает внимание читателя на дополнительную
информацию.
Важно Важное примечание предлагает сведения, необходимые для
выполнения задачи.
Предупреждение Обращает внимание читателя на важную дополнительную
информацию, которую нельзя проигнорировать.
‡ Символ, указывающий на специальные изменения или
рекомендации параметра групповой политики.
§ Символ, обозначающий параметры групповой политики,
веденные в Windows Server 2008.
Дополнительные ресурсы
В следующих ресурсах Microsoft.com можно найти дополнительную информацию по
вопросам безопасности и всестороннее обсуждение концепций и рекомендаций по
безопасности, рассматриваемых в данном руководстве:
 GPOAccelerator, инструмент и руководство от Центра загрузки Microsoft.
 Infrastructure Planning and Design.
 Microsoft Assessment and Planning Toolkit Solution Accelerator.
 Microsoft Deployment.
 Microsoft Windows Security Resource Kit.
 Microsoft Windows Server 2003 Resource Kit: Special Promotional Edition.
 Security Guidance.
 Solution Accelerators.
 Threats and Countermeasures.
 Windows Server 2003 Security Guide.
 Windows XP TechCenter.
 Windows XP Security Guide.

Поддержка и обратная связь


Команда Solution Accelerators – Security and Compliance (SA–SC) будет рада узнать
ваше мнение об этом и других руководствах.
Пожалуйста, присылайте свои комментарии по следующим адресам:
 Электронные письма по адресу secwish@microsoft.com.
 Сообщения в блог Solution Accelerators – Security and Compliance на сайте
Microsoft TechNet.
С нетерпением ожидаем ваших отзывов.

Благодарности
Команда Solution Accelerators – Security and Compliance (SA–SC) выражает
признательность и благодарит всех, кто принимал участие в создании Руководства
по безопасности Windows Server 2008. Перечисленные ниже люди принимали
активное участии и внесли значимый вклад в написание, разработку и
тестирование этого решения.

Команда создателей
Разработчики содержимого
Byron Hynes – Microsoft
Benjamin Curry – Content Master
Doug Steen – Wadeware LLC
Richard Harrison – Content Master
Разработчики
José Maldonado – Microsoft
Bhakti Bhalerao – Infosys Technologies Ltd
Naresh Krishna Kumar Kulothungan – Infosys Technologies Ltd.
Редакторы
John Cobb – Wadeware LLC
Steve Wacker – Wadeware LLC
Руководители призводства
Alain Meeus – Microsoft
Jim Stuart – Microsoft
Руководители проекта
Vlad Pigin – Microsoft
Руководитель выпуска
Karina Larson – Microsoft
Руководитель группы тестирования
Gaurav Singh Bora – Microsoft
Тестировщики
Beenu Venugopal – Infosys Technologies Ltd.
Sumit Parikh – Infosys Technologies Ltd.
Swaminathan Viswanathan – Infosys Technologies Ltd.

Помощники и рецензенты
Derick Campbell, Chase Carpenter, Nils Dussart, Michiko Short, Siddharth Bhai, Brad
Mahugh, Thomas Deml, Nazim Lala, Pitchai "Elango" Elangom, Ashwin Palekar,
Sudarshan Yadav, Daniel H. Brown, Georgi Matev, David Kruse, Adrian Lannin, Frank
Olivier, Brandon Baker, Nathan Muggli, Pankaj Chhabra, Abhishek Pathak,
Ramasubramanian K. Neelmani, Jim Groves, Jeff Westhead, Dan Kaminsky, Oded Ye
Shekel, Greg Lindsay, Anthony Leibovitz, Sreenivas Addagatla, Lambert Green, Chandra
Nukala, Richard Costleigh, David Kennedy, Marco Nuijen, Robert Hoover, Sanjay Pandit,
Michiko Short, Ido Dubrawsky, Doug Neal, Roger Grimes, Eugene Siu, Richard Lewis,
Herbert Mauerer, Enrique Saggese, Manu Jeewani, Sanjay Pandit, Jan De Clercq
(Hewlett-Packard), Jorge de Almeida Pinto (MVPS), Juergen Otter (Siemens AG),
Renato Miguel de Barros (Modulo Security Solutions), John Addeo (Dimension Data
America), Derek Seaman (PointBridge)
Примечание Национальный институт стандартов и технологии (National Institute of
Standards and Technology, NIST) Министерства торговли США участвовал в рецензировании
данного руководства по безопасности Microsoft и предоставил комментарии, которые были
включены в опубликованную версию.
Примечание По запросу Microsoft Отдел контроля информации Агентства национальной
безопасности (National Security Agency Information Assurance Directorate) принял участие в
рецензировании данного руководства по безопасности Microsoft и предоставил комментарии,
которые были включены в опубликованную версию
Глава 1: Реализация базовых настроек безопасности
Windows Server® 2008 – самая безопасная операционная система, выпущенная
Microsoft на данный момент. Однако разным организациям требуется разный
уровень безопасности и функциональности, поэтому может возникнуть
необходимость изменения конфигурации соответственно требованиям конкретной
среды. В данной главе демонстрируется, как относительно просто конфигурировать
настройки безопасности для повышения уровня защиты компьютеров,
осуществляющих различные роли сервера. На каждый сервер установлена
Windows Server 2008 в стандартной конфигурации. Все серверы включены в домен
с помощью доменных служб Active Directory® (Active Directory® Domain Services,
AD DS).
Теперь существует возможность повысить уровень защиты, используя только
объекты групповой политики (Group Policy objects, GPOs). Предыдущее руководство
по безопасности от Microsoft предлагало импортировать .inf-файлы шаблонов
безопасности и вручную вносить существенные изменения в административные
шаблоны нескольких объектов GPO, теперь в этом нет необходимости. Тем не
менее .inf-файлы шаблона безопасности включены в инструмент GPOAccelerator,
так чтобы их можно было использовать для повышения уровня защиты
изолированных серверов. «Изолированный» сервер не является участником
домена AD DS. Все рекомендуемые настройки групповой политики приведены в
Приложении А, «Параметры групповой политики, связанные с безопасностью».
Для работы с данным руководством вам понадобится:
 Создать структуру подразделений (organizational unit, OU) для своей среды.
 Запустить инструмент GPOAccelerator, предоставленный для данного
руководства.
Важно Чтобы создавать, тестировать и развертывать настройки безопасности для
Руководства по безопасности Windows Server 2008, скачайте GPOAccelerator и
руководство Как использовать GPOAccelerator для данного инструмента. Этот
инструмент автоматически создает все объекты GPO для параметров безопасности,
рекомендуемых данным руководством. Также он включает .inf-файлы шаблона
безопасности, которые можно использовать для применения параметров безопасности к
изолированным серверам.
 Использовать Консоль управления групповой политикой (Group Policy
Management Console, GPMC) для связывания и управления объектами
GPO.
Внимание Перед развертыванием в среде производственной эксплуатации схемы OU и
GPO должны быть тщательнейшим образом протестированы. Подробные рекомендации
по выполнению этого представлены в документе Как использовать GPOAccelerator.
Используйте данное руководство для создания и развертывания структуры
подразделений и объектов GPO безопасности, как на этапе тестирования, так и на этапе
производственной эксплуатации.
Поставляемые с данным руководством объекты GPO с набором базовых
показателей безопасности предлагают набор оттестированных настроек,
повышающих безопасность компьютеров на которых установлена ОС Windows
Server 2008, в двух различных средах:
 Среда корпоративных клиентов (Enterprise Client, EC)
 Специальная безопасная среда с ограниченной функциональностью
(Specialized Security – Limited Functionality, SSLF)

Среда корпоративных клиентов


Рассматриваемая в данной главе среда корпоративных клиентов (Enterprise Client,
EC) состоит из домена, использующего AD DS, с контролерами домена под
управлением Windows Server 2008 с Active Directory. Контроллеры управляют
клиентскими компьютерами, на которых установлены ОС:
 Windows Vista® или
 Windows XP® с пакетом обновлений 2 (Service Pack 2, SP2) или
 более поздние версии;
а также рядовыми серверами, на которых установлены ОС:
 Windows Server 2008 или
 Windows Server 2003 с SP2 или
 более поздние версии.
Управление клиентскими компьютерами и серверами-участниками в этой среде
осуществляется посредством Групповой политики, применяемой к сайтам,
доменам и подразделениям. Групповая политика обеспечивает централизованную
инфраструктуру в рамках AD DS, что позволяет распространять изменения и
управлять настройками пользователей и компьютеров, включая данные системы
безопасности и пользовательские данные, на уровне всего каталога.
Примечание Предписанные данным руководством базовые настройки безопасности среды
Корпоративный клиент позволяют реализовать повышенную безопасность, при которой
обеспечивается достаточная функциональность операционной системы и приложений в
преимущественном большинстве организаций.

Специальная безопасная среда с ограниченной


функциональностью
Рассматриваемая в данной главе Специальная безопасная среда с ограниченной
функциональностью (Specialized Security – Limited Functionality SSLF) состоит из
домена, использующего AD DS, с контролерами домена под управлением Windows
Server 2008 с Active Directory. Контроллеры управляют клиентскими компьютерами,
на которых установлены ОС:
 Windows Vista® или
 Windows XP® с пакетом обновлений 2 (Service Pack 2, SP2) или
 более поздние версии;
а также рядовыми серверами, на которых установлены ОС:
 Windows Server 2008 или
 Windows Server 2003 с SP2 или
 более поздние версии.
Базовая конфигурация SSLF, описанная в данном руководстве, отвечает
требованию по созданию сред с высоким уровнем безопасности для компьютеров,
на которых установлена ОС Windows Server 2008. Безопасность таких сред
настолько важна, что допускается существенное ограничение функциональности и
управляемости. Рекомендации по применению данных параметров разработаны
при взаимодействии с несколькими правительственными агентствами разных стран
мира.
Внимание Параметры безопасности SSLF предназначены лишь для ограниченного круга
организаций. Конфигурация этих параметров разработана для организаций, в которых
обеспечение безопасности важнее, чем обеспечение функциональности.
При тестировании и развертывании параметров конфигурации SSLF на серверах
среды можно наблюдать увеличение количества обращений пользователей в
службу технической поддержки вашей организации, связанных с ограничением
функциональности, обусловленным данными настройками. Конфигурация этой
среды обеспечивает более высокий уровень безопасности данных и сети, но также
препятствует выполнению некоторых служб, которые могут быть необходимы
организации. Например, Служб терминалов (Terminal Services), которые
обеспечивают пользователям возможность интерактивного подключения к рабочим
столам и приложениям на удаленных серверах.
Важно отметить, что базовая конфигурация безопасности SSLF не является
дополнением к базовой конфигурации EC: базовая конфигурация SSLF
обеспечивает совершенно иной уровень безопасности. По этой причине не
пытайтесь применять базовую конфигурацию SSLF и базовую конфигурацию EC к
одним и тем же компьютерам. В контексте данного руководства необходимо,
прежде всего, определить необходимый вашей среде уровень безопасности и
затем принимать решение о применении базовой конфигурации либо EC, либо
SSLF. Сравнение различий базовых конфигураций EC и SSLF проведено в
Приложении А «Параметры групповой политики, связанные с безопасностью».
Сборник параметров используемых в руководстве по безопасности Windows Server
2008, также прилагаемый к данному руководству, предлагает другой ресурс для
сравнения значений параметров.
Важно Если вы предполагаете использовать базовую конфигурацию SSLF, будьте готовы к
всестороннему тестированию компьютеров своей среды, чтобы убедиться, что параметры
безопасности SSLF не препятствуют реализации компьютерами данной среды необходимой
функциональности.

Среда со специализированной безопасностью


Организации, использующие компьютеры и сети, особенно если они подключены к
внешним ресурсам, таким как Интернет, должны учитывать вопросы безопасности
при проектировании системы и сети, а также при конфигурации и развертывании
компьютеров. Возможности, включающие автоматизацию процессов, удаленное
управление, удаленный доступ, возможность доступа 24 часа в сутки, возможность
доступа из любой точки земного шара и независимость от программных средств и
устройств, упрощают жизнь предприятий и позволяют работать более эффективно
в условиях рыночной конкуренции. Однако эти возможности также являются
причиной подверженности компьютеров этих организаций потенциальным рискам.
Как правило, администраторам необходимо предпринимать меры по
предотвращению несанкционированного доступа к данным, сбоя служб и
неправомерного использования компьютеров. Некоторым организациям, например
военным, правительственным и финансовым, необходимо обеспечить
безопасность определенного уровня некоторым или всем службам, системам и
данным, с которыми они работают. Базовая конфигурация SSLF разработан с
целью обеспечить этот уровень безопасности для таких организаций. Показатели
SSLF можно найти в Приложении А «Параметры групповой политики, связанные с
безопасностью».

Среда с ограниченной функциональностью


Специализированная безопасность, которую обеспечивает набор базовых
показателей SSLF, может приводить к ограничению функциональности среды.
Причиной этому является то, что базовая конфигурация SSLF ограничивает
пользователей лишь специальными функциями, необходимыми для выполнения
требуемых задач. Доступ возможен лишь к одобренным приложениям, службам и
инфраструктурам сред. Ограничена и возможность настройки, потому что SSLF
деактивирует многие привычные пользователям страницы свойств.
Области повышенной безопасности и ограниченной функциональности,
обеспечиваемые базовой конфигурацией SSLF, описаны в следующих разделах
данной главы:
 Ограниченный доступ к службам и данным.
 Ограниченный доступ к сети.
 Надежная защита сети.

Ограниченный доступ к службам и данным


Настройки, входящие в конфигурацию SSLF, требуют от пользователей
применения надежных паролей. Однако такие пароли легко забыть или допустить
ошибку при вводе, что может привести к тому, что допустимые пользователи не
получат доступ к службам или данным. Следствием этого может стать увеличение
количества обращений в службу технической поддержки. С другой стороны, данные
настройки обеспечивают компьютерам, с установленной ОС Windows Server 2008,
защиту среды от атак злонамеренных пользователей. К опциям базовой
конфигурации SSLF, которые потенциально могут помешать доступу
пользователей к службам и данным, относятся:
 Административные группы с ограниченным доступом, такие как Операторы
архива (Backup Operators) и Операторы сервера (Server Operators).
 Параметры, вводящие требования к применению более надежных паролей.
 Параметры, вводящие более строгую политику блокировки учетной записи.
 Параметры, ужесточающие политику Назначения прав пользователей
(User Rights Assignments) и Опций безопасности (Security Options).
Примечание Эти параметры, как для базовой конфигурации EC, так и для базовой
конфигурации SSLF, подробно рассматриваются в Приложении А «Параметры групповой
политики, связанные с безопасностью». Также для сравнения значений параметров можно
использовать «Сборник параметров используемых в руководстве по безопасности Windows
Server 2008», прилагаемый к данному руководству.
При помощи групповой политики можно задавать значения по умолчанию для
многих прав пользователя и опций безопасности, а также отключать их. Это может
привести к тому, что некоторые приложения, требующие специальных прав
пользователей, не будут функционировать надлежащим образом. Поэтому важно
провести тщательный предварительный анализ требований по настройке прав
пользователя и доступа для приложений, не установленных посредством
включения различных ролей сервера. Этот набор приложений включает, но не
ограничивается приложениями, разработанными специально для вашей среды, или
инструментами, используемыми для диагностики или обновления ваших
компьютеров.

Ограниченный доступ к сети


Надежность сети и возможность подключения системы являются главными
условиями успешности бизнеса. Операционные системы Microsoft обеспечивают
расширенные возможности работы в сети, которые помогают устанавливать,
поддерживать и восстанавливать соединения в случае их нарушения. Эта
возможность полезна для обслуживания подключения к сети, но может
использоваться для атак с целью повреждения или незаконного проникновения в
компьютеры вашей сети.
В основном администраторы приветствуют функции, обеспечивающие поддержку
сетевых подключений. Однако в особых случаях первостепенное значение имеет
безопасность данных и сервисов. В таких специализированных средах допускается
некоторое ограничение возможностей подключения с целью обеспечения защиты
данных. К опциям конфигурации SSLF, которые повышают безопасность сети, но
могут потенциально препятствовать доступу пользователей к сети, относятся:
 Параметры, ограничивающие доступ к клиентским системам по сети.
 Параметры, обеспечивающие сокрытие систем в списках просмотра.
 Параметры, управляющие исключениями брандмауэра Windows.
 Параметры, реализующие безопасность соединения, например, подпись
пакетов.

Надежная защита сети


Самой распространенной стратегией атак на сетевые сервисы является
использование атаки типа Отказ в обслуживании (denial of service, DoS). Такая
атака препятствует возможности доступа к данными или сервисами или
перегружает ресурсы системы и снижает производительность. Базовая
конфигурация SSLF обеспечивает дополнительную защиту объектам системы и
распределение ресурсов, что помогает защититься от этого типа атак. К опциям
базовой конфигурации SSLF, способствующим предотвращению атак типа Отказ в
обслуживании, относятся:
 Параметры, контролирующие распределение квот памяти для процессов.
 Параметры, контролирующие создание объектов.
 Параметры, контролирующие возможности отладки программ.
 Параметры, управляющие профилированием процессов.
Все эти меры по обеспечению безопасности повышают вероятность того, что
параметры безопасности базовой конфигурации SSLF могут воспрепятствовать
нормальному выполнению приложений в вашей среде или доступу пользователей к
службам и данным. Поэтому важно провести всестороннее тестирование
реализованной базовой конфигурации SSLF перед его применением в среде
производственной эксплуатации.
Проектирование безопасности
Приведенные в этой главе рекомендации по проектированию безопасности,
являются отправной точкой для сценариев, рассматриваемых данным
руководством, и предлагают средства их защиты. В последующих разделах главы
подробно рассматривается основная структура безопасности, используемая в
данном руководстве:
 Структура подразделений
 Структура объекта групповой политики

Структура подразделения для политик безопасности


Подразделение (OU) – это контейнер в рамках домена AD DS. Подразделение
может содержать пользователей, группы, компьютеры и другие подразделения.
Если подразделение включает другие подразделения, оно называется
родительским подразделением, и подразделение в рамках родительского
подразделения называется дочерним подразделением.
Можно связать GPO с OU, что обеспечит применение настроек GPO к
пользователям и компьютерам, входящим в состав OU, и его дочерним OU. Чтобы
упростить администрирование, можно делегировать полномочия по
администрированию каждого отдельного подразделения конкретным
администраторам или группам.
Подразделения обеспечивают эффективный способ установления
административных границ между пользователями и компьютерами. Microsoft
рекомендует распределять пользователей и компьютеры в разные подразделения,
потому что существуют настройки, применяемые исключительно к пользователям
или исключительно к компьютерам.
Управление отдельным подразделением может быть делегировано в Мастере
делегирования управления (Delegation Wizard) в оснастке Active Directory -
Пользователи и компьютеры (Active Directory - Users and Computers) консоли
управления Microsoft (Microsoft Management Console, MMC). В разделе
«Дополнительные источники» в конце данной главы можно найти ссылки на
документацию по делегированию полномочий.
Одна из основных целей создания структуры подразделений для любой среды –
обеспечение базы для реализации Групповой политики, которая может
применяться ко всем компьютерам домена AD DS. Это помогает обеспечить
соответствие компьютеров стандартам безопасности, установленным
организацией. Схема OU также должна обеспечивать адекватную структуру для
применения параметров безопасности для определенных типов ролей сервера,
служб ролей и пользователей в организации. Например, разработчики должны
иметь намного более широкие права доступа к своему компьютеру, чем обычные
пользователи. Следующий рисунок иллюстрирует простую структуру OU,
достаточную для обсуждаемой в данной главе Групповой политики. Эта структура
OU может отличаться от требуемой для среды вашей организации.
Корень домена

Подразделение Подразделение
рядовых серверов контроллеров домена

Подразделение роли 1
сервера

Подразделение роли 2
сервера

Подразделение роли 3
сервера

Подразделение роли n
сервера

Рис. 1.1. Пример структуры подразделения для компьютеров, с


установленной ОС Windows Server 2008

Корень домена
Чтобы управлять общей конфигурацией домена, некоторые параметры
безопасности должны быть установлены глобально для всего домена. Эти
настройки хранятся в объектах групповой политики, применяемых к домену.
Computers and Users (Компьютеры и пользователи) располагаются в другом
контейнере.

Подразделение контроллеров домена


Контроллеры домена содержат некоторые наиболее чувствительные данные
вашей организации – данные, управляющие самой конфигурацией системы
безопасности. На этом уровне объекты GPO применяются в структуре OU для
конфигурации и защиты контроллеров домена.

Подразделение рядовых серверов


Это подразделение включает описываемые ниже дочерние подразделения. В
объекты GPO данного подразделения должны быть включены параметры,
применяемые ко всем серверам, но не к рабочим станциям.
Подразделения ролей сервера
Microsoft рекомендует для каждой роли сервера, используемой в вашей
организации, создавать отдельное подразделение. Каждое подразделение должно
включать только один тип компьютера-сервера. Тогда можно конфигурировать
параметры GPO и применять их к подразделениям, специально отведенным под
каждую роль.
Также в случае необходимости один сервер может сочетать определенные роли.
Например, можно объединить роли сервера Файлы (File) и Печать (Print). В этом
случае для этих комбинированных ролей сервера можно создать подразделение
Сервер файлов и печати (File and Print Server) и затем связать с этим
подразделением две характерных для роли политики GPO
Важно Комбинирование ролей сервера на одном компьютере требует тщательного
планирования и тестирования, чтобы гарантированно исключить негативный эффект на
общую безопасность комбинируемых ролей сервера.

Структура объектов групповой политики для политик


безопасности
Объект групповой политики (GPO) – это набор параметров Групповой политики.
Объекты GPO хранятся на уровне домена. Область их действия распространяется
на пользователей и компьютеры, содержащиеся на сайтах, в доменах и
подразделениях.
С помощью объектов GPO можно гарантировать применение определенных
параметров политики, прав пользователей и поведения компьютера к компьютерам
или пользователям подразделения. Применение Групповой политики вместо
настройки вручную существенно упрощает задачу по управлению и внесению
изменений для множества компьютеров и пользователей. Конфигурирование
вручную не только малопроизводительно, поскольку требует от технического
специалиста настройки каждой рабочей станции, но также потенциально
неэффективно. Неэффективность, главным образом, обусловлена тем, что если
параметры политики объектов GPO уровня домена отличаются от локальных
параметров, параметры политики GPO уровня домена переопределят локальные
настройки.
5 Политика дочернего
подразделения
4 Политика родительского
подразделения
3 Политика домена

2 Политика сайта

1 Локальная политика
безопасности

Рис. 1.2. Очередность применения GPO


Приведенный рисунок показывает очередность применения объектов GPO к
компьютеру, входящему в дочернее подразделение, начиная от самого низкого
приоритета (1), до самого высокого (5). Сначала применяется Групповая политика
из локальной политики безопасности каждой рабочей станции. После применения
локальной политики безопасности применяются объекты GPO на уровне сайта и
затем на уровне домена.
Для компьютеров, работающих под управлением Windows Server 2008, Windows
Server 2003 SP2 или более поздних версий и Windows Vista или Windows XP с SP2
или более поздними версиями, располагающихся в многократно вложенных
подразделениях, объекты GPO применяются в порядке от уровня родительского
подразделения к самому нижнему по иерархии дочернему подразделению.
Последним применяется GPO подразделения, включающего учетную запись
компьютера. Такой порядок обработки GPO для Групповой политики (локальная
политика безопасности, сайт, домен, родительское подразделение и дочернее
подразделение) имеет большое значение, потому что параметры объектов GPO,
применяемых позже, переопределяют предыдущие параметры. Если один и тот же
параметр имеет различные значения в разных GPO, эти значения никогда не
комбинируются. Принцип применения объектов GPO для пользователей
аналогичен.
При разработке Групповой политики необходимо учитывать следующее:
 Администратор должен задать порядок связывания нескольких GPO с
подразделением, или Групповая политика будет применена по умолчанию в
том порядке, в каком она была подключена к подразделению. Если
параметр задан в нескольких политиках, преимущественное значение будет
иметь политика, располагающаяся в списке политик контейнера выше.
 Параметры Групповой политики применяются к пользователям и
компьютерам, исходя из месторасположения объекта пользователя или
компьютера в Active Directory. В некоторых случаях приходится применять
политику к объекту пользователя на основании месторасположения
объекта компьютера. Свойство замыкания на себя Групповой политики дает
администраторам возможность применять пользовательские настройки
Групповой политики исходя из того, на каком компьютере пользователь
зарегистрирован. Более подробную информацию по этому вопросу можно
найти в статье Loopback Processing of Group Policy (Обработка замыкания
Групповой политики).
 Для GPO можно задать опцию Enforced (Принудительный). Если эта опция
выбрана, другие объекты GPO не могут переопределять параметры,
заданные в этом GPO.
 В Active Directory можно задать для сайта, домена или подразделения
опцию Block policy inheritance (Блокировать наследование политики). Эта
опция блокирует параметры GPO от объектов GPO, расположенных в
Active Directory выше по иерархии, кроме тех для которых выбрана опция
Enforced. Иначе говоря, опция Enforced имеет приоритет над опцией Block
policy inheritance.
Примечание Администраторы должны с чрезвычайной осторожностью
использовать опции Enforced и Block policy inheritance, потому что их активация
может сильно усложнить процесс поиска и устранения неисправностей в объектах
GPO.

Рекомендованные объекты GPO


Для реализации описанной выше структуры подразделений потребуются как
минимум следующие объекты GPO:
 Политика домена.
 Политика для обеспечения набора базовых показателей безопасности для
всех контроллеров доменов.
 Политика для обеспечения набора базовых показателей безопасности для
всех рядовых серверов
 Политика для каждой роли сервера в вашей организации.
Примечание Для реализации безопасности для клиентских компьютеров и пользователей в
вашей организации потребуются дополнительные объекты GPO. Более подробную
информацию можно найти в Windows Vista Security Guide (Руководство по безопасности
Windows Vista).
На следующем рисунке предварительная структура подразделений представлена
развернуто с целью показать связи между этими объектами GPO и структурой
подразделений.
Политика
домена
Корень
домена Базовая политика
контроллеров
домена

Базовая политика
EC или SSLF Подразделение Подразделение
Windows Server рядовых серверов контроллеров
2008 домена

Политика

Подразделение серверов AD CS

Политика

Подразделение серверов DHCP

Политика

Подразделение серверов DNS


Политика

Подразделение файловых серверов

Политика

Подразделение серверов печати

Политика

Подразделение серверов служб сетевого доступа

Политика

Подразделение серверов служб терминалов

Политика

Подразделение веб-серверов

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


политики для компьютеров, с установленной ОС Windows Server 2008
В примере на рис. 1.3 Сервер файлов входит в Подразделение серверов файлов.
Первой к серверу применяется локальная политика безопасности. Однако, как
правило, локальная политика выполняет лишь незначительную конфигурацию
серверов или не выполняет ее вообще. Политики и параметры безопасности всегда
должны вводиться в действие Групповой политикой.
Поскольку в данном примере всего одни Сервер файлов, объекты GPO на этом
уровне не применяются. Таким образом, следующей политикой, применяемой к
серверам, становится GPO домена. Затем к Подразделению рядовых серверов
применяется Базовая политика Windows Server 2008 EC. Наконец, к
Подразделению веб-серверов применяются все специальные политики для Веб-
серверов среды.
В качестве примера очередности применения политик рассмотрим сценарий, в
котором параметр политики Allow logon through Terminal Services (Разрешить
вход в систему через службу терминалов) задан для следующих подразделений и
групп пользователей:
 Подразделение рядовых серверов – группа Администраторы
(Administrators)
 Подразделение веб-серверов – группы Пользователи удаленного
рабочего стола (Remote Desktop Users) и Администраторы
В этом примере возможность входа в систему через Службы терминалов была
предоставлена только группе Администраторы Подразделения рядовых
серверов. Однако пользователь, учетная запись которого располагается в группе
Пользователи удаленного рабочего стола, может регистрироваться на
Файловом сервере через Службы терминалов, потому что Подразделение
файловых серверов является дочерним для Подразделения рядовых серверов, и в
силу вступает дочерняя политика.
Если в GPO для Подразделения рядовых серверов активирована опция политики
Enforced, регистрироваться на компьютере, являющемся Файловым сервером,
через Службы терминалов могут только пользователи, учетные записи которых
находятся в группе Администраторы. Это объясняется тем, что опция Enforced
препятствует переопределению ранее примененной политики политикой дочернего
подразделения.

Дополнительные ресурсы
Дополнительную информацию по обеспечению безопасности Windows Server 2008
можно найти в следующих ресурсах на сайте Microsoft.com:
 Administering Group Policy (Администрирование групповой политики).
 Enterprise Management with the Group Policy (Управление предприятием с
использованием групповой политики).
 Инструмент GPOAccelerator и руководство от Центра загрузки Microsoft.
 Loopback Processing of Group Policy.
 Migrating GPOs Across Domains with GPMC (Миграция объектов GPO по
доменам с использованием GPMC).
 Step-by-Step Guide to Understanding the Group Policy (Пошаговое
руководство для понимания групповой политики).
 Step-by-Step Guide to Using the Delegation of Control Wizard (Пошаговое
руководство по использованию Мастера делегирования управления).
 Summary of New or Expanded Group Policy (Обзор новой или развернутой
Групповой политики).
 Windows Server 2008 TechCenter (Центр технической поддержки Windows
Server 2008).
 Windows Server Group Policy (Групповая политика Windows Server).
 Windows Vista Security Guide (Руководство по безопасности Windows Vista).

Глава 2: Сокращение поверхности атаки посредством


роли сервера
Концепция ролей сервера не нова, но возможность централизованного управления
ими появилась впервые и стала основным компонентом Windows Server® 2008.
Стандартная установка Windows Server 2008 не предоставляет никаких сетевых
сервисов, кроме базовой возможности подключения к сети. Стандартный подход к
проектированию безопасности для операционной системы требует от
администраторов активации всех необходимых функций в ходе развертывания
сервера.
В данной главе предлагается обзор встроенных инструментов, которые позволяют
быстро устанавливать, конфигурировать и поддерживать все необходимые
функции серверов среды.
 В разделе «Обеспечение безопасности ролей сервера» рассматривается,
как с помощью оснастки Диспетчер сервера (Server Manager) Консоль
управления Microsoft (Microsoft Management Console, MMC) можно
уменьшить поверхность атаки ваших серверов путем настройки только
необходимой функциональности каждой конкретной роли сервера.
o В данном разделе также представлен компонент Windows
Server 2008 Server Core, который поможет еще более сократить
поверхность атаки на роли сервера вашей организации.
o В данном разделе обсуждается возможность использования
Мастера настройки безопасности (Security Configuration Wizard,
SCW) для обслуживания и введения в действие конфигурации,
реализованной в Диспетчере сервера
 В разделе «Использование Мастера настройки безопасности и Групповой
политики для повышения уровня безопасности» даются рекомендации по
созданию и применению объектов Групповой политики (GPOs) для
укрепления защиты серверов, работающих под управлением Windows
Server 2008.

Обеспечение безопасности ролей сервера


Оснастка Диспетчер сервера в Windows Server 2008 упрощает задачу по
управлению и обеспечению безопасности множества ролей, выполняемых
серверами организации. Диспетчер сервера является единым инструментом
управления идентификационной и системной информацией сервера Он
отображает состояние сервера, выявляет проблемы с конфигурацией ролей
сервера и управляет всеми ролями, установленными для сервера. Когда
безопасная конфигурация сервера создана, SCW поможет гарантировать
сохранение настроек сервера неизменными.

Диспетчер сервера
Диспетчер сервера ускоряет настройку и конфигурацию сервера и упрощает
текущее обслуживание ролей сервера. В Windows Server 2008 каждая роль сервера
предназначена для выполнения определенного класса задач. Сервер может
1
выполнять одну или множество ролей. Например, часто роли DHCP -сервер и DNS-
2
сервер устанавливаются на один сервер.
Однако на сервер могут быть установлены компоненты для поддержания
функциональности и повышения уровня безопасности, не относящиеся к основной
функции сервера. Например, программу шифрования дисков BitLocker™ от
Microsoft® можно установить на файловый сервер или сервер, выполняющий
любую другую роль. Эта функция помогает защитить данные сервера на случай,
если он будет украден.
Диспетчер сервера заменяет несколько компонентов Windows Server 2003, включая
Управление данным сервером (Manage Your Server), Настройка сервера (Configure
Your Server) и Установка компонентов Windows (Add or Remove Windows
Components). Он устраняет необходимость запуска SCW перед развертыванием
серверов. При использовании Диспетчера сервера в Windows Server 2008 для
установки ролей сервера роли конфигурируются с рекомендуемыми Microsoft
настройками безопасности по умолчанию. Также можно использовать SCW для
задания соответствующих настроек ролей для ваших серверов.
Стандартная установка Windows Server 2008 выполняет минимальный набор служб
и не реализовывает никаких ролей или функций сервера. Такая схема позволяет
максимально сократить поверхности атаки для каждого сервера и, таким образом,
защитить любую вновь установленную роль сервера.
Чтобы роли сервера могли выполнять полезные функции, они должны быть
соответствующим образом конфигурированы. Диспетчер сервера включает
компонент Задачи начальной настройки (Initial Configuration Tasks, ICT). Он
автоматически выводится на экран, когда администратор впервые регистрируется
на новом сервере, как показано на рисунке ниже.

1
Dynamic Host Configuration Protocol – протокол динамической настройки хостов
(прим. переводчика)
2
Domain Name System – Система именования доменов (прим. переводчика)
Рис. 2.1. Компонент Задачи начальной настройки в Диспетчере сервера
ICT выделяет и организовывает для администраторов важные задачи, которые
должны быть выполнены при установке новых серверов, обеспечивая им быстрый
доступ к наиболее часто используемым мастерам настройки в Диспетчере сервера.
Обычно все серверы можно конфигурировать и настроить в Диспетчере сервера,
доступ к которому можно получить, запустив ServerManager.msc или щелкнув ярлык
Диспетчер сервера, по умолчанию располагающийся в меню Пуск (Start).
Рис. 2.2. Консоль диспетчера сервера
При конфигурировании роли Диспетчер сервера автоматически устанавливает все
необходимые службы и компоненты. Также он автоматически настраивает все
правила брандмауэра, необходимые для обеспечения новой роли. Аналогично, при
использовании Диспетчера сервера для удаления какой-либо отдельной роли он
изменяет настройки служб и брандмауэра сервера таким образом, чтобы
гарантированно сохранить безопасную конфигурацию сервера и не затронуть
выполнение других ролей. Эти нововведения гарантируют выполнение сервером
только необходимых служб и обеспечение минимально возможной уязвимости.
В главы данного руководства, посвященные ролям сервера, включена информация
обо всех установленных службах и открытых портах, используемых каждой ролью.
Также в статье Server Manager на сайте Microsoft TechNet можно найти подробное
техническое описание Диспетчера сервера и ролей сервера, которые он
поддерживает.

Server Core
Server Core – это новый вариант установки в Windows Server 2008. Он
обеспечивает сокращение поверхности атаки на поддерживаемые роли сервера за
счет установки только необходимых для работы сервера двоичных файлов. Такой
подход также приводит к сокращению размера установки сервера, следствием чего
является уменьшение числа файлов, требующих обновления в будущем.
Например, оболочка Explorer и Microsoft Internet Explorer® не являются частью
установки Server Core.
Установка Server Core поддерживает следующие роли сервера:
 Доменные службы Active Directory
 Службы Active Directory облегченного доступа к каталогам
 DNS-сервер
 DHCP-сервер
 Файловые службы
 Службы печати
 Службы потоковой передачи медиаданных (Streaming Media Services)
 Веб-сервер (IIS)
 Hyper-V™
Также поддерживаются следующие необязательные компоненты и функции:
 Отказоустойчивый кластер Microsoft (Microsoft Failover Cluster)
 Балансировка сетевой нагрузки (Network Load Balancing)
 Подсистема для приложений UNIX
 Возможности архивации данных Windows Server
 Многопутевой ввод/вывод
 Управление съемными носителями
 Шифрование дисков BitLocker
 Службы SNMP
1

 WINS -сервер
2

 Клиент Telnet
 Качество службы (Quality of Service, QoS)
Для установки Server Core необходимо всего около 1 ГБ пространства жесткого
диска сервера и дополнительные 2 ГБ для нормальной работы. После установки и
конфигурации сервера компонентами можно управлять локально из командной
строки, удаленно, используя Удаленный рабочий стол, с помощью MMC или
инструментов командной строки, которые поддерживают удаленное использование.
В главах данного руководства, посвященных ролям сервера, обозначено, когда
установка Server Core может способствовать улучшению защиты вашей среды.
Более подробную информацию и руководство по установке Server Core можно
найти на сайте TechNet в документе Server Core Installation Option of Windows
Server 2008 Step-By-Step Guide (Пошаговое руководство по установке Server Core
для Windows Server 2008).

Мастер настройки безопасности


Функциональность Мастера настройки безопасности (SCW) в Windows Server 2008
аналогична функциональность версии этого мастера для Windows Server 2003
Service Pack 2 (SP2). По-прежнему SCW может использоваться для уменьшения

1
Simple Network Management Protocol – простой протокол управления сетью (прим.
переводчика).
2
Windows Internet Naming Service – служба присваивания имен в Интернет для
Windows (прим. переводчика).
поверхности атаки сервера путем деактивации ненужных служб и блокирования
неиспользуемых или ненужных портов. Однако теперь есть возможность
самостоятельно принимать решение о применении или неприменении мастера.
Windows Server 2003 был разработан так, чтобы администраторы использовали
SCW после установки на сервере стандартной версии операционной системы для
уменьшения поверхности атаки. Но теперь при установке Windows Server 2008
Диспетчер сервера автоматически определяет, что требуется установить на
сервер, и реализует минимально необходимую для выполнения сервером
определенной роли функциональность.
SCW последовательно проводит вас по всем аспектам процесса конфигурации, так
что вы можете анализировать и обеспечивать оптимальную настройку. SCW не
является оснасткой MMC, это независимая программа, доступ к которой можно
получить, запустив SCW.exe.
SCW может использоваться для быстрого создания политик безопасности для
множества серверов или групп серверов с одного компьютера. Эта возможность
позволяет управлять всеми политиками организации из одной точки. Политики
обеспечивают согласованные меры по повышению уровня защиты, которые
поддерживаются и подходят для функций, предоставляемых серверами в рамках
организации.
В Windows Server 2008 SCW интегрирован с новым брандмауэром Windows. Если
вы не воспрепятствуете этому, SCW конфигурирует брандмауэр Windows таким
образом, что будет разрешен необходимый операционной системе входящий
сетевой трафик на важные порты, а также слушающие приложения. Если
необходимы дополнительные фильтры для портов, их можно создать с помощью
SCW. Таким образом, создаваемые SCW политики замещают специальные
сценарии, используемые для настройки или изменения фильтров IPsec для
блокирования нежелательного трафика, что упрощает задачу по повышению
уровня защиты сети. Также с SCW проще настроить сетевые фильтры для служб,
использующих удаленный вызов процедур (remote procedure call, RPC) или
динамические порты.
Больше информации о новом брандмауэре Windows можно найти в статье The New
Windows Firewall in Windows Vista (Новый брандмауэр Windows в Windows Vista) на
сайте TechNet.
Больше нет необходимости запускать SCW для уменьшения поверхности атаки
отдельных серверов. Однако по-прежнему с помощью SCW можно создавать и
развертывать политики безопасности, которые используются для обслуживания
конфигурации, реализованной Диспетчером сервера, на одном или более серверах
через Групповую политику.
Создавая новую политику, SCW использует текущую конфигурацию сервера в
качестве исходной. Поэтому лучше всего создавать политику на сервере того же
типа, что и сервер, для которого эта политика создается. Такой подход несколько
упростит задачу, потому что начальная конфигурация должна примерно совпадать
с требуемой. При создании новой политики SCW создает XML-файл и по
умолчанию сохраняет его в папке %systemdir%\security\msscw\Policies. После того
как политики созданы, с помощью SCW или инструмента командной строки
SCWcmd.exe их можно применить непосредственно к тестовым серверам.
Следующий раздел данной главы посвящен созданию объектов GPO с помощью
SCW и SCWcmd.exe для применения ваших настроек безопасности сервера. Более
подробную информацию о SCW, включая возможности мастера и ссылки на другие
посвященные SCW ресурсы, можно найти в статье Security Configuration Wizard
Concepts (Основные принципы мастера настройки безопасности) на сайте TechNet.

Использование Мастера настройки


безопасности и Групповой политики для
повышения уровня безопасности
SCW может использоваться для создания и применения политик безопасности
непосредственно к серверам. Однако при таком подходе для настройки большого
количества серверов требовалось бы очень много времени. Microsoft рекомендует
развертывать политики SCW, используя инструмент SCWcmd.exe для
преобразования политики SCW на базе XML-файлов в объект GPO, который
впоследствии может быть применен одновременно ко множеству серверов. Хотя на
первый взгляд это преобразование может показаться ненужным, такой подход
обеспечивает следующие преимущества:
 Привычные основанные на Active Directory механизмы тиражирования,
развертывания и применения политик.
 Объекты GPO, становящиеся доступными благодаря этому
преобразованию, позволяют дополнительно применять политики к
подразделениям (OUs), а также использовать наследование политик для
более тонкой настройки и повышения уровня защиты серверов со схожей,
но, тем не менее, немного отличной конфигурацией. Например, при
использовании Групповой политики серверы можно поместить в дочернее
подразделение и применить к нему дополнительную политику. При
решении этой задачи с помощью SCW вы должны создавать новую
политику для каждой конфигурации своей среды.
 Политики автоматически применяются ко всем серверам, размещающимся
в соответствующих подразделениях. При использовании SCW политики
должны применяться или вручную, или посредством специального
сценария.

Использование Мастера настройки безопасности для


создания политик роли
Начинайте настройку в новой установке операционной системы. В этом случае
гарантируется отсутствие настроек или программного обеспечения, сохранившихся
от предыдущих конфигураций, которые могут оказывать влияние на вашу работу.
По возможности используйте оборудование, аналогичное оборудованию вашего
окружения, чтобы обеспечить максимальную совместимость.
В следующем процессе новую установку будем называть тестовым компьютером.
Чтобы создать политику роли
1. Создайте новую установку Windows Server 2008 на новом тестовом
компьютере.
2. Используя инструмент ICT, включите компьютер в домен.
3. Установите на тестовом компьютере обязательные приложения. К таким
приложениям относятся агенты программ и управления, агенты архивации
на магнитной ленте и антивирусные или антишпионские программы.
4. С помощью Диспетчера сервера установите соответствующие роли
сервера. Например, если целевые серверы будут выполнять DHCP и DNS,
установите эти роли.
Примечание Не обязательно конфигурировать каждую рабочую нагрузку в точности
аналогично развертываемым серверам, но необходимо установить роли, чтобы SCW мог
правильно определить конфигурацию каждого сервера.
5. Щелкните Пуск, Все программы (All Programs), Администрирование
(Administrative Tools) и затем щелкните Мастер настройки безопасности
(Security Configuration Wizard).
6. На странице Действие настройки (Configuration Action) выберите Создать
новую политику безопасности (Create new policy) и щелкните Далее (Next).
7. На странице Выбор сервера (Select Server) введите имя или IP-адрес
тестового компьютера и щелкните Далее.
Примечание Этим действием вводится локальное имя компьютера по умолчанию.
8. На странице Обработка базы данных настройки безопасности
(Processing Security Configuration Database) щелкните Далее и затем на
странице Настройка служб на основе ролей (Role-Based Service
Configuration) щелкните Далее.
9. На странице Выбор ролей сервера (Select Server Roles) убедитесь, что
мастер определил и выбрал все установленные на тестовом компьютере
роли сервера. После этого щелкните Далее.
Внимание Если мастер выбрал не все роли, которые вы желаете установить на сервере,
полученная в результате политика отключит службы, необходимые некоторым ролям, и
сервер будет работать неправильно.
10. На странице Выбор клиентских возможностей (Select Client Features)
убедитесь, что мастер определил и выбрал все установленные на вашем
тестовом компьютере компоненты. После этого щелкните Далее.
Внимание Если мастер выбрал не все компоненты, которые вы желаете установить на
сервере, полученная в результате политика отключит службы, необходимые некоторым
ролям, и сервер будет работать неправильно.
11. На странице Выбор управления и других параметров (Select
Administration and Other Options) убедитесь, что мастер определил и выбрал
все установленные на вашем тестовом компьютере опции. После этого
щелкните Далее.
12. На странице Выбор дополнительных служб (Select Additional Services)
убедитесь, что мастер определил и выбрал все необходимые службы на
вашем тестовом компьютере. После этого щелкните Далее.
Примечание Если вы настроили на своем тестовом компьютере все необходимые роли
и установили все необходимое дополнительное программное обеспечение, такое как
агенты архивации или антивирусные программы, вам не придется вносить изменения ни
на одной из упомянутых выше страницах настройки служб для ролей.
13. На странице Обработка неопределенных служб (Handling Unspecified
Services) щелкните Далее.
14. На странице Подтверждение изменений для служб (Confirm Service
Changes) просмотрите изменения режима службы, которые SCW включит в
результирующую политику безопасности, и щелкните Далее.
Внимание Особое внимание обратите на службы, начальный режим которых меняется с
Automatic (Автоматический) на Disabled (Деактивирован), чтобы убедиться, что вы не
отключаете необходимые функции.
15. На странице Сетевая безопасность (Network Security) щелкните Далее.
16. На странице Правила сетевой безопасности (Network Security Rules)
убедитесь, что SCW определил соответствующие порты и приложения,
которые будет использовать для настройки брандмауэра Windows. После
этого щелкните Далее.
17. На странице Параметры реестра (Registry Settings)установите флажок
Пропустить этот раздел (Skip this section) и щелкните Далее.
18. На странице Политика аудита (Audit Policy) установите флажок
Пропустить этот раздел и щелкните Далее.
19. На странице Сохранение политики безопасности (Save Security Policy)
щелкните Далее.
20. На странице Имя файла политики безопасности (Security Policy File Name)
задайте соответствующий путь, имя политики и затем щелкните Далее.
Примечание По умолчанию XML-файлы политики сохраняются в подпапку
Security\msscw\policies папки установки сервера (как правило, она располагается в
каталоге C:\Windows). Однако SCW предоставляет возможность задать другое
местоположение.
21. На странице Применение политики безопасности (Apply Security Policy)
щелкните опцию Применить позже (Apply Later). После этого щелкните
Далее.
Примечание Чтобы применить политику безопасности непосредственно в серверу,
можно выбрать опцию Применить сейчас (Apply Now). Это позволяет применять
политику безопасности к изолированным серверам.
22. Наконец, на странице Завершение мастера настройки безопасности
(Completing the Security Configuration Wizard) щелкните Готово (Finish).
Далее представлен порядок операций при использовании SCWcmd.exe для
преобразования только что созданного в SCW XML-файла политики в GPO.
Чтобы преобразовать политику роли в GPO
1. Введите следующее в командной строке и нажмите ENTER (ввод):
scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName>
Следующий пример создает в Active Directory GPO под именем File Server Policy
(Политика файлового сервера). Для нового GPO должно быть задано
уникальное имя, иначе в результате выполнения этой команды будет
возвращена ошибка:
scwcmd transform
/p:"C:\Windows\Security\msscw\Policies\FileServer.xml"
/g:"File Server Policy"
Примечание Этот пример представлен здесь в несколько строк из-за ограниченных
размеров страницы (экрана) и для упрощения восприятия, но в командную строку при
выполнении команды вводить информацию необходимо в одну строку.
2. Используйте Консоль управления групповыми политиками (Group Policy
Management Console, GPMC) для связывания вновь созданного GPO с
соответствующими подразделениями.
3. Упомянутый в Главе 1 «Реализация базовых настроек безопасности»
инструмент GPOAccelerator создает образцы объектов GPO, которые
изначально были созданы с использованием SCW. В эти GPO внесены
изменения, чтобы они не деактивировали службы системы и не
реализовывали правила брандмауэра. Хотя это позволяет комбинировать
объекты GPO для серверов, настроенных на выполнение нескольких ролей,
но GPO лишь гарантируют, что необходимые службы системы остаются
активными.
4. Таким образом, мы получаем механизм, обеспечивающий гарантированную
доступность системы, но, кроме того, идеальный GPO отключает все
ненужные службы. На своих серверах, находящихся в производственной
эксплуатации, можно использовать GPO, созданные инструментом
GPOAccelerator, но значительное преимущество обеспечат объекты GPO,
созданные специально для ваших серверов с использование описанных
выше процедур.
Важно Скачайте инструмент GPOAccelerator и руководство «Как использовать
GPOAccelerator» для него, чтобы создавать, тестировать и развертывать настройки
безопасности для «Руководства по безопасности Windows Server 2008». Данный
инструмент автоматически создает все объекты GPO для параметров безопасности,
рекомендованных этим руководством. Также инструмент включает .inf-файлы Шаблонов
безопасности, которые можно использовать для применения параметров безопасности к
изолированным серверам.

Общие предпосылки настройки безопасности


Microsoft рекомендует начинать работу по настройке в новой установке
операционной системы, чтобы Диспетчер сервера оптимально конфигурировал
выбираемые вами роли и компоненты. Однако если нет возможности выполнить
новую установку, приступая к настройке определенной роли, проверьте сначала
следующие общие параметры безопасности. Такой подход поможет свести до
минимума возможность влияния настроек предыдущих конфигураций на
параметры безопасности новой роли сервера.
В следующей таблице представлен список лучших практик настройки параметров
безопасности, которым рекомендует следовать Microsoft перед настройкой сервера
для выполнения определенной роли. Используйте эту таблицу как контрольный
список, который поможет гарантировать, что ваш сервер соответствующим образом
конфигурирован и защищен от злонамеренных атак.
Таблица 2.2. Рекомендации по настройке сервера
Компонент Характеристики
Физическая Располагайте серверы в безопасных зонах с ограниченным
безопасность доступом, что обеспечит снижение возможности
несанкционированного доступа и сведет до минимума
возможность кражи.
Обновления После установки операционной системы для установки на
системы серверы последних обновлений безопасности и системы
используйте Центр обновления Windows.
Компонент Характеристики
Роли Для удаления с серверов всех ненужных служб или компонентов
ролей используйте Диспетчер сервера. Эта лучшая практика
поможет максимально сократить поверхность атаки для каждого
сервера.
Приложения, Диспетчер сервера конфигурирует необходимые службы и
службы и устройства, установленные на каждый сервер для
устройства осуществляемых ими ролей. Однако любое приложение,
установленное на сервер, но более не используемое, может
быть угрозой для безопасности. Microsoft рекомендует удалять
со всех серверов все приложения и службы, в которых больше
нет необходимости.
Протоколы Удалите или деактивируйте все неиспользуемые протоколы. По
умолчанию Windows Server 2008 устанавливает стандартные
протоколы TCP/IP версии 4 и 6 для использования с
установленными сетевыми платами.
Учетные записи Удалите все неиспользуемые учетные записи пользователей.
Убедитесь, что учетная запись гостя не активирована (она
отключена по умолчанию).
Присвойте новое имя учетной записи администратора и задайте
для нее надежный пароль. Для дополнительной защиты
отключите стандартную учетную запись администратора.
Убедитесь, что применяются политики надежных паролей.
Запретите возможность удаленного входа в систему для
стандартных учетных записей пользователей.
Отключите пустые сеансы (анонимные входы в систему).
Отключите или удалите общие учетные записи администратора.
Ограничьте состав локальных групп администраторов
(идеальный вариант – до двух участников).
Потребуйте от администраторов выполнять вход в систему в
интерактивном режиме (или реализуйте безопасное решение
удаленного администрирования).
Файлы и С помощью Windows Explorer проверяйте жесткие диски сервера
каталоги на наличие файлов или папок, в которых больше нет
необходимости. По возможности переформатируйте диски, на
которых хранились конфиденциальные данные.
Убедитесь, что группа Все не имеет прав доступа к папкам или
ресурсам с конфиденциальными данными.
Проверка Удалите с сервера неиспользуемые ресурсы.
ресурсов Удалите права доступа для группы Все для всех ресурсов
сервера.
Компонент Характеристики
Пересмотр Проверьте состояние брандмауэра Windows и убедитесь, что
правил для доступа из сети доступны только необходимые сетевые
брандмауэра порты. В книге «Справочник по поверхности атаки для Windows
Server 2008», сопровождающей данное руководство, описаны
стандартные правила брандмауэра Windows, создаваемые
Диспетчером сервера при настройке роли сервера.
Проверьте конфигурацию диапазона динамических портов.
Более подробную информацию о необходимых Windows
Server 2008 динамических портах можно найти в статье 929851
Базы знаний Microsoft «The default dynamic port range for TCP/IP»
(Стандартный диапазон динамических портов для TCP/IP).
Во всех остальных главах данного руководства предполагается применение этих
лучших практик перед попыткой конфигурировать конкретные роли сервера.

Дополнительные источники
Дополнительную информацию о Диспетчере сервера и Мастере настройки
безопасности, входящих в состав Windows Server 2008, можно найти на сайте
Microsoft.com в следующих источниках:
 Security Configuration Wizard Concepts.
 Security Configuration Wizard для Windows Server 2008.
 Server Manager (Диспетчер сервера).
 Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.
 The New Windows Firewall.
 Windows Server 2008: Server Management (Windows Server 2008: управление
сервером).
 Windows Server 2008 Server Manager Technical Overview (Технический обзор
диспетчера сервера Windows Server 2008).

Глава 3: Повышение уровня защиты доменных служб


Active Directory
Организации используют Доменные службы Active Directory® (Active Directory®
Domain Services, AD DS) для управления доменными пользователями и ресурсами,
такими как компьютеры, принтеры и приложения. AD DS в Windows Server® 2008
включает ряд новых компонентов и функциональных возможностей, которые не
были доступны в предыдущих версиях Windows Server. Основной задачей
некоторых из этих компонентов является более безопасное развертывание AD DS.
Как представлено на следующем рисунке, роли Доменные службы Active Directory
доступны такие службы роли:
 Контроллер домена AD DS. Эта служба роли устанавливается с ролью
AD DS по умолчанию. Она позволяет серверу сохранять данные каталога и
управляет обменом информацией между пользователями и доменами,
включая процессы входа пользователей в систему, аутентификации и
поиска по каталогам.
 Диспетчер удостоверений для UNIX. Эта служба роли интегрирует
компьютеры, работающие под управлением Windows®, в существующую
среду UNIX. Могут быть установлены следующие необязательные
1
подсистемы этой службы роли :
o Сервер для Сетевых информационных служб (Network
Information Services, NIS). Эта подсистема выполняет интеграцию
сетей Windows и NIS, экспортируя сопоставления доменов NIS в
записи Службы каталогов. Это позволяет контроллеру домена Active
Directory выступать в роли основного NIS-сервера.
o Синхронизация паролей. Эта подсистема гарантирует, что при
изменении пароля в одной среде (UNIX или Windows), он будет
изменен и в другой среде.

Контроллер домена AD DS

Роль доменные службы Active


Directory

Диспетчер удостоверений для UNIX

Сервер для сетевых информационных служб

Синхронизация паролей

Рис. 3.1. Иерархия служб роли для AD DS

1
В указанном перечне пропущено «Средства администрирования», которые
позволяют конфигурировать сервер NIS и синхронизацию паролей (прим. научного
редактора).
Служба роли Контроллер домена Active Directory
Служба роли Контроллер домена Active Directory в Windows Server 2008 включает
следующие связанные с обеспечением безопасности улучшения по сравнению с
предыдущими версиями Windows Server:
 Аудит изменений атрибутов. Теперь Windows Server 2008 при успешном
изменении атрибута протоколирует как новое, так и старое его значения.
Ранее в процессе аудита AD DS протоколировалось только имя
измененного атрибута. Windows Server 2008 также включает
дополнительные подкатегории для аудита AD DS. Благодаря этим
улучшениям вы получаете возможность отслеживать изменения атрибутов
Active Directory, касающихся безопасности. Больше информации по этому
вопросу можно найти в разделе «Политики и подкатегории аудита»
Приложения А, «Параметры групповой политики, связанные с
безопасностью».
Примечание Это улучшение касается текстовых атрибутов. Для двоичных
атрибутов значение не определено.
 Расширенные политики паролей. Windows Server 2008 позволяет
задавать несколько политик паролей и блокировки учетных записей для
одного домена. Таким образом, к разным группам пользователей домена
можно применять разные политики паролей и блокировки учетных записей.
 Контроллер домена только для чтения (Read-only domain controller,
RODC). Windows Server 2008 поддерживает этот новый тип контроллера
домена, который имеет базу данных AD DS, доступную только для чтения, и
поддерживает только входящую репликацию для всех размещенных
разделов и SYSVOL. Эти контроллеры доменов не сохраняют копии
паролей учетных записей, только специальную учетную запись компьютера
для RODC и специальную учетную запись Kerberos для RODC. Таким
образом, другие конфиденциальные данные гарантированно не копируются
в них. Контроллеры домена только для чтения особенно полезны в средах,
в которых нельзя гарантировать физической безопасности.
Примечание Служба роли Контроллер домена Active Directory устанавливается при
реализации роли AD DS, но, тем не менее, сервер не считается контроллером домена на этом
этапе. Поэтому многие службы, связанные со службой роли, деактивированы. Чтобы
использовать службу роли Контроллер домена Active Directory, на сервер необходимо
добавить функции контроллера домена с помощью Мастера установки доменных служб
Active Directory (Active Directory Domain Services Installation Wizard)

Поверхность атаки
Служба роли Контроллер домена Active Directory подвержена тем же типам атак на
систему безопасности, что и контроллеры доменов, работающие с предыдущими
версиями Windows Server. Чтобы обозначить всю поверхность атаки для этой
службы роли, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли Контроллер домена Active Directory.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
роли Контроллер домена Active Directory.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой роли Контроллер
домена Active Directory правила брандмауэра Windows.
 Зависимости роли. Это зависимости службы роли Контроллер домена
Active Directory.
Подробная информация о поверхности атаки для службы роли Контроллер домена
Active Directory включены в Справочник по поверхности атаки в Windows Server
2008, прилагаемый к данному руководству. Увидеть поверхность атаки для данной
службы роли можно на вкладке AD DS книги в разделах, соответствующих каждому
из пунктов предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию службы роли Контроллер домена Active Directory
для защиты сервера от злоумышленных атак. Приведенные ниже рекомендации
предполагают, что на странице Выбор служб роли (Select Role Services) Мастера
добавления ролей (Add Roles Wizard) выбрана только опция Служба роли
Контроллер домена Active Directory. Рекомендации для других служб роли не
включены.

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу роли Контроллер домена Active Directory. В случае
возникновения трудностей с выполнением каких-либо пунктов контрольного списка
дополнительное описание и рекомендации можно найти в следующих разделах
данной главы.
Таблица 3.1. Контрольный список настройки
Задачи настройки
Использовать Server Core Windows Server 2008.
Использовать контроллеры RODC там, где невозможно гарантировать
физическую безопасность.
Делегировать локальное администрирование контроллеров RODC.
Ограничить количество конфиденциальных данных, хранящихся на
контроллерах RODC.
Объединить службы роли DNS и Контроллер домена.
Ограничить количество участников группы администрирования и объемы
администрирования.
Запретить администраторам служб обходить политики паролей.
Настроить расширенные политики паролей.
Потребовать многофакторную аутентификацию для пользователей с высоким
уровнем привилегий.
Задачи настройки
Управлять администраторами служб при помощи управляемой структуры
подразделений.
Управлять членством в группах для учетных записей администраторов служб.
Шифровать данные, хранящиеся на локальных дисках, с помощью Шифрования
дисков BitLocker®.
1
Архивировать информацию восстановления для BitLocker и TPM .
Защитить ключ запуска компьютера с помощью Syskey.

Использовать Server Core Windows Server 2008


Развертывание Windows Server 2008 с использованием опции установки Server
Core сокращает поверхность атаки для операционной системы за счет ограничения
числа необходимых файлов и служб. При использовании Server Core не
устанавливаются файлы и службы, необходимые для графического
пользовательского интерфейса (graphical user interface, GUI); в этом основное
преимущество этой опции.
При развертывании операционной системы с использованием опции установки
Server Core Windows Server 2008 управлять сервером можно только локально через
инструменты командной строки. Чтобы управлять сервером с помощью
инструментов GUI, необходимо установить и запустить их на другом компьютере с
GUI на базе Windows.
Для установки, удаления, запуска и остановки роли AD DS могут использоваться
следующие инструменты командной строки:
 Чтобы установить или удалить роль AD DS, выполните одну из следующих
команд:
dcpromo /unattend:<unattendfile>
или
dcpromo /unattend /option1=”value1” /option2=”value2”
/option=…”
Где unattendfile – имя файла ответов для автоматической установки
Dcpromo.exe. Установка роли AD DS должна выполняться с
использованием файла ответов, потому что графический мастер
Dcpromo.exe не поддерживается.
 Для запуска службы Доменные службы Active Directory выполните
следующую команду:
net start "Active Directory DomainServices"
 Чтобы остановить службу Доменные службы Active Directory, выполните
следующую команду:
net stop "Active Directory DomainServices"

1
Trusted Platform Module – Доверенный платформенный модуль (прим.
переводчика).
Более подробную информацию об опции установки Server Core и управлении
AD DS из командной строки можно найти в следующих источниках:
 Server Core.
 Managing Active Directory (Управление Active Directory).

Использовать RODC там, где невозможно гарантировать


физическую безопасность
По причине их большой важности Microsoft рекомендует размещать контроллеры
домена в физически защищенных местах, доступ к которым имеет только
квалифицированный административный персонал. В ситуациях, когда вашей
организации приходится размещать контроллеры домена в незащищенных
окружениях, например филиалах, можно использовать контроллеры домена только
для чтения (RODCs).
Контроллеры RODC не хранят локально копии паролей всех учетных записей,
только специальную учетную запись компьютера для RODC и специальную
учетную запись Kerberos для RODC. С помощью Политики репликации паролей
(Password Replication Policy), специально создаваемой для RODC, можно настроить
пароли каких учетных записей будут храниться на том или ином RODC. Обычно
большинство контроллеров RODC локально кэшируют ограниченный набор
паролей учетных записей. Он содержит подмножество паролей, для которых
разрешено копирование в RODC, и тех, к которым осуществляется
непосредственный доступ в этом RODC. С помощью Отфильтрованного набора
атрибутов RODC (RODC Filtered Attribute Set) можно гарантировать, что
копирование других конфиденциальных данных выполняться не будет.
Контроллеры не допускают изменений базы данных AD DS извне по следующим
причинам:
 База данных AD DS в RODC является доступной только для чтения.
 Для всех размещенных разделов и ресурса SYSVOL поддерживается
только входящая репликация.
Таким образом, можно разместить обычные контроллеры домена в безопасных
центрах обработки данных и затем установить сетевое взаимодействие с
контроллерами RODC. Однако никогда нельзя забывать о том, что любой
компьютер, находящийся в физически незащищенном месте, представляет угрозу
для безопасности организации.
Примечание Хотя контроллеры RODC не требуют применения таких же мер безопасности,
как доступные для записи контроллеры доменов, реализация рекомендаций по обеспечению
безопасности для доступного для записи домена гарантирует самую надежную из возможных
защиту.

Делегировать локальное администрирование контроллеров


RODC
Функция Разделения Административных Ролей позволяет делегировать права
администратора RODC любому пользователю домена или группе доступа без
предоставления им каких-либо дополнительных прав на доступ к домену или
другим контроллерам домена. Таким образом, администратор с делегированными
полномочиями может регистрироваться на RODC для выполнения работ по
обслуживанию сервера, таких как обновление драйвера.
Однако администратор с делегированными полномочиями не сможет
регистрироваться на любом другом контроллере домена или выполнять какие-либо
другие административные задачи в домене. То есть можно делегировать
полномочия группе доступа, в состав которой входят не участники группы Domain
Admins (Администраторы домена), а пользователи из филиала, и предоставить ей
возможность эффективно управлять RODC в филиале, не подвергая рискам
безопасность остального домена.

Ограничить количество конфиденциальных данных, хранящихся


на контроллерах RODC
Некоторые приложения, использующие AD DS как хранилище данных, могут иметь
подобные удостоверениям данные или атрибуты, такие как пароли, учетные
данные или ключи шифрования, которые нежелательно хранить в RODC по
причине его возможного похищения или взлома. Чтобы защитить подобные
атрибуты приложений можно предпринять следующие действия:
 Добавить все атрибуты в отфильтрованный набор атрибутов RODC, чтобы
предотвратить их копирование в контроллеры RODC леса.
 Пометить каждый атрибут как конфиденциальный, что устраняет
возможность чтения этих данных для членов группы Прошедшие проверку
(Authenticated Users), включая любые контроллеры RODC.
Более подробную информацию о том, как ограничить доступ к конфиденциальной
информации, хранящейся в контроллерах RODC, можно найти в статье «RODC
filtered attribute set» (Отфильтрованный набор атрибутов RODC) на странице RODC
Features (Возможности RODC) для Windows Server 2008.

Объединить службы роли DNS и Контроллер домена


Для контроллеров домена Windows Server 2008 необходима стабильная, правильно
конфигурированная служба DNS. Можно интегрировать зоны DNS в AD DS, что
является более безопасным вариантом, потому что в этом случае поддерживаются
безопасные обновления.
По этой причине многие организации сочетают на одном компьютере службы роли
Контроллер домена Active Directory и DNS-сервер, когда служба роли DNS-сервер
поддерживает Active Directory. Однако Microsoft рекомендует избегать
комбинирования службы роли Контроллер домена Active Directory с другими
ролями сервера. Единственным исключением является служба роли DNS-сервер,
поддерживающая Active Directory. Выполняя все остальные роли на других
серверах, мы максимально сокращаем уязвимость службы роли Контроллер
домена Active Directory.

Ограничить количество участников группы администрирования и


объемы администрирования
Microsoft рекомендует предоставлять доступ к обычным контроллерам домена в
вашей организации только ограниченной группе выделенных администраторов. А
также разделять административные полномочия так, чтобы никто в вашей среде
гарантированно не обладал избыточными полномочиями в Active Directory. Обычно
это подразумевает разбиение административных задач и ролей на подкатегории и
создание групп соответственно этим задачам и ролям.
К остальным административным действиям, которые можно предпринять для
повышения безопасности службы роли Контроллер домена Active Directory,
относятся:
 Деактивировать или удалить неиспользуемые учетные записи
пользователей и/или компьютеров.
 Деактивировать учетную запись гостя.
 Присвоить новое имя стандартной учетной записи администратора, задать
более сложный пароль и затем деактивировать ее с помощью объекта
групповой политики.
 Ввести в действие правила сложности паролей.
 Запретить общие учетные записи.

Запретить администраторам служб обходить политики паролей


Пользователь, обладающий более высоким уровнем привилегий, может создавать
объекты пользователя или изменять права доступа в атрибуте useraccountcontrol
(контроль учетных записей) и обходить политики паролей. Например, по
умолчанию участники группы Администраторы домена (Domain Admins) могут
восстанавливать пароль, срок действия которого истек, или могут активировать или
деактивировать расширенное право password not required (пароль не требуется)
для объектов пользователей.
Вы можете изменить это поведение по умолчанию, настраивая следующие
расширенные права в Active Directory:
 Включить отдельно для каждого пользователя обратимое
1
шифрование пароля (Enable-Per-User-Reversibly-Encrypted-Password).
Это расширенное право управления доступом дает возможность
пользователю активировать или деактивировать расширенное право на
создание пароля с возможностью обратного шифрования (reversible
encrypted password) для объектов пользователя и компьютера.
 Отмена истечение срока пароля (Unexpire-Password). Это расширенное
право управления доступом дает возможность пользователю
восстанавливать пароль, срок действия которого истек, для объекта
пользователя.
 Обновить бит запроса пароля (Update-Password-Not-Required-Bit). Это
расширенное право управления доступом дает возможность пользователю
активировать или деактивировать расширенное право пароль не
требуется (password not required) для объектов пользователя.
Больше информации о конфигурации расширенных прав в Active Directory можно
найти в следующих источниках:
 Appendix D: Active Directory (Приложение D: Active Directory).
 Best Practices for Delegating Active Directory (Лучшие практики
делегирования прав в Active Directory).

1
В русской версии ОС название данного права обрезается в некоторых
интерфейсах и выглядит как «Включить отдельно для каждого ПО» (прим.
технического редактора).
Настроить расширенные политики паролей
Windows Server 2008 позволяет задавать несколько политик паролей в рамках
одного домена. Такие политики называют расширенными политиками паролей. Тем
самым появляется возможность для домена в целом реализовывать минимальный
уровень безопасности паролей, но при этом применять более строгие политики
паролей к конкретным группам пользователей и компьютеров.
С помощью расширенных политик паролей можно налагать различные ограничения
на политики паролей и политики блокировки учетных записей для разных групп
пользователей в домене. Например, можно применить более строгие параметры к
привилегированным учетным записям и менее строгие параметры к учетным
записям остальных пользователей. В некоторых случаях может потребоваться
специальная политика паролей для учетных записей, для которых происходит
синхронизация паролей с другими источниками данных. Примером этому могут
быть учетные записи, используемые компьютерами под управлением UNIX,
которые требуют менее строгих политик паролей.
В частности, более строгие политики паролей задаются для следующих
пользователей:
 Участников группы доступа Администраторы предприятия (Enterprise
Admins).
 Участников группы доступа Администраторы домена (Domain Admins).
 Участников группы доступа Администраторы схемы (Schema Admins)
 Участников группы доступа DHCP Admins.
 Участников группы доступа DNS Admins.
 Участников группы доступа Операторы сервера (Server Operators).
 Участников группы доступа Операторы архива (Backup Operators).
 Участников группы доступа Администраторы (Administrators).
 Участников группы доступа Администраторы политики (Policy
Administrators).
 Участников группы доступа Администраторы сертификатов (Certificate
Administrators).
 Участников группы доступа Администраторы шифрования (Cryptographic
Administrators).
 Участников группы доступа Операторы печати (Print Operators).
 Участников группы доступа с делегированными правами
администрирования AD DS, таких как персонал службы технической
поддержки.
 Участников группы доступа с делегированными правами
администрирования приложений, выполняющихся на компьютерах-
серверах, таких как администраторы Microsoft Exchange Server или Microsoft
SQL Server®.
Расширенные политики паролей применяются только к объектам пользователя или
объектам inetOrgPerson, если они используются вместо объектов пользователя, и
глобальным группам доступа. По умолчанию только участники группы
Администраторы домена могут создавать, конфигурировать и просматривать
расширенные политики паролей. Право на создание, конфигурацию и просмотр
этих политик можно делегировать другим пользователям, но для этого требуется
режим работы домена Windows Server 2008. Тем не менее, Microsoft рекомендует
предоставлять возможность создавать или настраивать расширенные политики
паролей только участникам группы доступа Администраторы домена.
Вы можете делегировать возможность просматривать расширенные политики
паролей пользователям, которым необходимо такое делегирование
административных прав, например, персоналу службы технической поддержки.
Чтобы предоставить таким пользователям возможность просматривать
расширенные политики паролей, необходимо сделать следующее:
1. Создать группу доступа, состоящую из пользователей, которым требуется
просматривать расширенные политики паролей.
2. Предоставить группе, созданной в Шаге 1, право на чтение Password
1
Settings Container (PSC) .
По умолчанию PSC создается в домене в контейнере System (Система).
Просматривать этот контейнер можно с помощью оснастки Active Directory –
Пользователи и компьютеры с включенными дополнительными компонентами. В
2
PSC хранятся Password Settings objects (PSOs) домена.
Возможны случаи, когда требуется делегировать не фактическую возможность
создавать расширенные политики паролей, а лишь право назначать расширенные
политики паролей определенным группам пользователей. Для этого Microsoft
рекомендует выполнить следующее:
1. Создать объект расширенной политики паролей со строгой настройкой.
2. Связать группу доступа Пользователи домена (Domain Users) с объектом
расширенной политики паролей, созданным в Шаге 1.
3. Для всех остальных создаваемых вами объектов расширенной политики
паролей делать следующее:
a. Создать объект расширенной политики паролей.
b. Создать глобальную группу доступа.
c. Связать глобальную группу доступа, созданную в Шаге b, с
объектом расширенной политики паролей, созданным в Шаге а.
d. Делегировать администрирование членства в глобальной группе
доступа пользователям, которые будут управлять пользователями
группы, вследствие чего делегируется право назначать
расширенные политики паролей пользователям, входящим в
глобальную группу доступа.
Расширенная политика паролей не может применяться непосредственно к
подразделению (OU). Чтобы применить расширенную политику паролей к
пользователям в подразделении, можно использовать скрытую группу.
Скрытая группа – это глобальная группа доступа, логически проецируемая на
подразделение для введения в действие расширенной политики паролей.
Пользователи подразделения добавляются как участники вновь созданной скрытой
группы, и затем эта скрытая группа связывается с расширенной политикой паролей.
Также можно создавать дополнительные скрытые группы для других

1
Контейнер параметров паролей (прим. переводчика).
2
Объекты параметров паролей (прим. переводчика).
подразделений. Если пользователь переходит из одного подразделения в другое,
необходимо обновить состав участников соответствующих скрытых групп.
Расширенные политики паролей не препятствуют работе специальных фильтров
паролей, которые могут использоваться в том же домене. Организации,
применяющие специальные фильтры паролей в контроллерах доменов,
выполняющих Windows 2000 или Windows Server 2003, могут продолжать
использование этих фильтров паролей для наложения дополнительных
ограничений на пароли.
Больше информации о расширенных политиках паролей можно найти в статье AD
DS: Fine-Grained Password Policies (AD DS: расширенные политики паролей).

Потребовать многофакторную аутентификацию для


пользователей с высоким уровнем привилегий
Факторы аутентификации пользователя обычно классифицируются следующим
образом:
 Пользователь располагает специальной информацией, такой как пароль,
парольная фраза или персональный идентификационный номер (personal
identification number, PIN).
 Пользователь имеет специальное устройство, такое как смарт-карта,
маркер доступа, маркер программы или мобильный телефон.
 Пользователь предоставляет биометрический параметр, такое как
отпечаток пальца или узор сетчатки глаза, последовательность ДНК,
распознавание подписи или голоса, уникальные биоэлектрические сигналы
или другие биометрические показатели.
Часто в организациях используются сочетания этих методов. Например, платежная
карта и PIN, такой способ еще называют двухфакторной аутентификацией.
Аутентификация пользователей может проводиться только по паролю, но для
повышения уровня аутентификации в организации может использоваться
многофакторная аутентификация. В многофакторной аутентификации обычно
принимает участие физическое устройство, такое как устройство чтения смарт-
карт, USB-маркер доступа или устройство считывания отпечатков пальцев. Выбор
физических устройств для многофакторной аутентификации часто осуществляется,
исходя из требований, не связанных с безопасностью.
Например, ваша организация могла бы потребовать, чтобы смарт-карты
пользователей включали идентификацию по фотографии, поскольку на смарт-карте
могут быть напечатаны фото и имя владельца. Однако для использования смарт-
карты необходимо устройство для чтения, что ведет к дополнительным расходам.
USB-маркер может включать флэш-память для хранения документов и файлов, и
пользователи могут подключать USB-маркер в существующие USB-порты своих
компьютеров.
Такая форма обеспечения безопасности рекомендуется для учетных записей с
более высоким уровнем привилегий. В частности, Microsoft рекомендует применять
многофакторную аутентификацию к таким группам пользователей:
 Участникам группы доступа Администраторы предприятия.
 Участникам группы доступа Администраторы домена.
 Участникам группы доступа Администраторы схемы
 Участникам группы доступа DHCP Admins.
 Участникам группы доступа DNS Admins.
 Участникам группы доступа Операторы сервера.
 Участникам группы доступа Операторы архива.
 Участникам группы доступа Администраторы.
 Участникам группы доступа Администраторы политики.
 Участникам группы доступа Администраторы сертификатов.
 Участникам группы доступа Администраторы шифрования.
 Участникам группы доступа Операторы печати.
 Участникам группы доступа с делегированными правами
администрирования AD DS, таких как персонал службы технической
поддержки.
 Участникам группы доступа с делегированными правами
администрирования приложений, выполняющихся на компьютерах-
серверах, таких как администраторы Microsoft Exchange Server или Microsoft
SQL Server®.
Примечание По возможности рекомендуется использовать в организации многофакторную
аутентификацию, поскольку это обеспечит требование по предоставлению самых надежных
из возможных паролей для учетных записей пользователя. Использование многофакторной
аутентификации заставляет систему автоматически формировать криптографически стойкие
случайные пароли для учетных записей.

Управлять администраторами служб при помощи управляемой


структуры подразделений
Администраторы служб отвечают за обеспечение работы службы каталогов,
параметры уровня каталога, установку и обслуживание программного обеспечения
и применение пакетов обновления и исправлений операционной системы на
контроллерах домена. Для осуществления этих функций администраторы служб
должны иметь физический доступ к контроллерам домена.
Чтобы защитить учетные записи администраторов служб, обладающие высоким
уровнем привилегий, возможность управлять этими учетными записями должны
иметь только администраторы служб. Поскольку такие учетные записи обладают
высоким уровнем привилегий, администраторы данных не должны иметь
полномочий для их изменения. Иначе это позволит администраторам данных
повышать уровень своих привилегий. Доступ и управление учетными записями
администраторов служб в любом домене должен осуществляться в управляемом
поддереве.
Чтобы получить более управляемую среду, в которой намного проще
контролировать учетные записи и рабочие станции администраторов служб,
создайте структуру подразделений, которая позволит работать с учетными
записями администраторов служб в Active Directory, как показано на следующем
рисунке. Участник группы Администраторы домена должен создать управляемую
структуру подразделений для каждого домена и сконфигурировать каждое
подразделение рекомендуемыми параметрами безопасности.
Создав структуру подразделений, содержащую учетные записи администраторов
служб и их рабочие станции, можно будет применить необходимые параметры
безопасности и повысить, таким образом, уровень защиты учетных записей и
компьютеров. На следующем рисунке представлен пример управляемой структуры
административного подразделения и применяемые к нему параметры управления
доступом.

Домен компании

Подразделение встроенных учетных


записей и других объектов

Подразделение контроллеров домена


Отключить наследование прав
доступа в этом подразделении

Администраторы
служб

Пользователи и
группы

Рабочие станции
администраторов

Параметры управления доступом для


подразделения администраторов службы
Пользователи
Администраторы предприятия: полный доступ
Администраторы домена: полный доступ
Администраторы: полный доступ
Область применения:
Этот объект и все дочерние объекты.
Пред-Windows 2000 доступ:
Список содержимого
Прочитать все свойства
Чтение разрешений
Область применения:
Объекты пользователей

Рис. 3.2. Пример структуры подразделения для управления учетными


записями администраторов
Создание управляемой структуры подразделений включает следующие этапы:
1. Создание структуры подразделений.
2. Задание списков управления доступом (access control lists, ACLs) для
управляемых подразделений.
3. Добавление группы администраторов служб в управляемую структуру
подразделений.
4. Добавление учетных записей пользователей для администраторов служб в
управляемую структуру подразделений.
5. Добавление учетных записей рабочих станций администраторов в
управляемую структуру подразделений.
6. Защита групп администраторов служб вне управляемой структуры
подразделений.
Шаг 1: Создание структуры подразделения
Создайте подразделение высокого уровня для размещения в нем групп и
пользовательских учетных записей администраторов служб и их рабочих станций.
В рамках этого подразделения создайте другое подразделение, которое будет
включать учетные записи администраторов и групп, и еще одно подразделение для
рабочих станций администраторов.
На приведенном выше рисунке отражена рекомендуемая иерархия подразделений,
составляющих управляемое поддерево, для организации учетных записей
администраторов служб и рабочих станций. Она включает управляемую структуру
подразделений, корнем которой является подразделение Администраторов служб,
содержащее два дополнительных подразделения: подразделение пользователей и
групп, в котором размещаются учетные записи администраторов и групп, и
подразделение рабочих станций администраторов, в котором размещаются
учетные записи рабочих станций, используемых администраторами служб.
Шаг 2: Задание списков управления доступом (access control lists, ACLs) для
управляемых подразделений
В зависимости от остальной структуры подразделений пользователи с
делегированными административными правами могут непреднамеренно получить
право на администрирование пользователей из управляемых подразделений.
Чтобы управлять членством пользователей, групп и рабочих станций
администраторов служб могли только конкретные администраторы, необходимо
внести изменения в списки управления доступом управляемых подразделений. Это
предотвратит ошибочное наследование управляемыми подразделениями
изменений настроек прав доступа в GPO, занимающем более высокую позицию в
структуре подразделений.
Чтобы ограничить доступ к управляемым подразделениям, необходимо сделать
следующее:
 Отключить наследование прав доступа подразделением Администраторов
служб, чтобы изменения, вносимые в параметры GPO выше в структуре
подразделений, не могли наследоваться структурой, располагающейся
ниже, и приводить к изменению заблокированных параметров.
 Задать список управления доступом для подразделения Администраторов
служб, как показано в следующей таблице.
Таблица 3.2. Настройки списка управления доступом для подразделения
Администраторов служб
Тип Имя Доступ Применение
Разрешить Администраторы Полный доступ Этот объект и все
предприятия дочерние объекты.
Разрешить Администраторы Полный доступ Этот объект и все
домена дочерние объекты.
Разрешить Администраторы Полный доступ Этот объект и все
дочерние объекты.
Разрешить Пред-Windows 2000 Составлять список Объекты пользователей.
доступ содержимого
Читать все
свойства
Читать права
доступа

Шаг 3: Добавление групп администраторов служб в управляемую структуру


подразделений
Перенесите следующие группы администраторов службы из их текущего
местоположения в каталоге в подразделение Пользователи и группы своей
управляемой структуры подразделений:
 Администраторы домена
 Администраторы предприятия (если является корневым доменом леса)
 Администраторы схемы (если является корневым доменом леса)
Чтобы полностью защитить группы администраторов служб, идеально было бы
перенести встроенные группы, а это группы Администраторы, Операторы служб,
Операторы учетных записей и Операторы архива, в управляемую структуру
подразделений. Однако вы не можете переносить встроенные группы из их
контейнера по умолчанию. Шаг 6 объясняет, как защитить учетные записи
участников этих групп.
Шаг 4: Добавление учетных записей пользователей-администраторов служб в
управляемую структуру подразделений
Перенесите все пользовательские учетные записи администраторов, являющихся
участниками любой из групп администраторов служб, перечисленных в Шаге 3, из
их текущего местоположения в каталог подразделения Пользователи и группы
своей управляемой структуры подразделений. Обязательно перенесите
встроенную учетную запись администратора домена.
Microsoft рекомендует создавать две учетные записи для каждого администратора
служб: одну для административных обязанностей и другую для обычного доступа в
качестве пользователя. Поместите административные учетные записи в
подразделение Пользователи и группы своей управляемой структуры
подразделений. Если эти учетные записи уже существуют где-то в каталоге,
перенесите их в структуру подразделений в данном шаге. Не размещайте обычные
пользовательские учетные записи администраторов в этой управляемой структуре
подразделений.
Шаг 5: Добавление учетных записей рабочих станций администраторов в
управляемую структуру подразделений
Обозначьте компьютеры администраторов как рабочие станции администраторов.
Перенесите учетные записи компьютеров этих рабочих станций в подразделение
Рабочие станции администраторов своей управляемой структуры подразделений.
Важно Ни в коем случае не переносите учетные записи контроллеров доменов из
подразделения по умолчанию Контроллеры доменов, даже если некоторые администраторы
используют их для выполнения административных задач. Перенос учетных записей
контроллеров домена нарушит согласованность применяемых политик контроллеров домена
ко всем доменам вашей среды.
Шаг 6: Защита групп администраторов служб вне управляемой структуры
подразделений
Некоторые встроенные учетные записи администраторов службы защищены
специальными стандартными дескрипторами безопасности, которые применяются
при установке Active Directory. Однако эти дескрипторы не защищают группы
Операторы сервера, Операторы архива и Операторы учетной записи.
Также поскольку эти учетные записи являются встроенными, вы не можете
защитить их, перенеся в управляемую структуру подразделения. Чтобы защитить
эти три группы, примените тот же стандартный список управления доступом,
который использовался для защиты учетных записей других администраторов
службы, перечисленных в приведенной ранее таблице.

Управлять членством в группах для учетных записей


администраторов служб
Для повышения уровня безопасности сведите количество участников в каждой из
групп администраторов служб до абсолютного минимума, допустимого логистикой
вашей организации, сохраняя при этом способность управлять функциями службы
Active Directory. Таким образом, сокращается количество учетных записей
администраторов, доступных злоумышленникам. В следующих разделах
объясняются некоторые рекомендованные практики управления членством в
группах администраторов служб.
Назначение надежного персонала
Предоставляйте право управлять конфигурацией и службой каталогов только
надежному персоналу. Такая ответственность должна возлагаться исключительно
на надежных и проверенных пользователей, показавших себя ответственными
обладателями прав, на тех, кто полностью понимает, как следует обслуживать
каталог. Эти администраторы должны прекрасно разбираться в политиках
безопасности и операционных политиках вашей организации и должны
продемонстрировать свое желание воплощать их в жизнь.
Ограничение членства в Группе обслуживания только пользователями из леса
Microsoft рекомендует включать в группы администраторов служб пользователей
или группы из другого леса, только если вы абсолютно доверяете администраторам
служб этого леса. Администраторы служб другого леса полностью контролируют
учетные записи пользователей в том лесу, поэтому они могут без труда
использовать удостоверения одного из этих пользователей для проникновения в
ваш лес. Более того, такое доверие удаленному домену (или лесу) подразумевает
доверие используемым в нем мерам безопасности, а их вы контролировать не
можете.
Примечание Если вы обнаруживаете необходимость установления отношений доверия с
другим лесом, реализуйте фильтрацию идентификаторов безопасности (security identifier,
SID) между лесами. Фильтрация SID активирована по умолчанию для внешних отношений
доверия, но не для отношений доверия между лесами. Это не дает администратору одного
леса (Лес А) получить более высокий уровень привилегий в другом лесу (Лес В) путем
вставки SID группы Администраторы домена в атрибут sidhistory Леса А своей учетной
записи в Лесу В.
Если администратору из другого леса необходимо выступать в роли
администратора служб в вашем домене, создайте в своем домене учетную запись,
которую этот администратор может использовать для выполнения
административных задач. Создание такой учетной записи устраняет вашу
зависимость от мер безопасности другого леса.
Ограничение группы Администраторы схемы временными участниками
Группа Администраторы схемы – это особая группа в корневом домене леса,
которая обеспечивает административные права доступа к схеме Active Directory.
Участники этой группы обладают необходимыми правами пользователя для
внесения изменений в схему. Как правило, поскольку схема меняется очень редко,
нет необходимости в том, чтобы администратор схемы был доступен постоянно.
Эта учетная запись нужна только в момент обработки обновления схемы или
внесения изменений в конфигурацию хозяев операций схемы.
Чтобы свести до минимума возможность атак на Active Directory через учетную
запись администратора, Microsoft рекомендует оставлять группу Администраторы
схемы пустой и добавлять в нее пользователя, которому можно доверять, только
когда требуется выполнить задачу по администрированию схемы. После
завершения выполнения задачи, этот участник должен быть удален из группы.
Предоставление администраторам лишь тех прав, которые действительно
необходимы
В Active Directory есть встроенная группа Операторы архива. Участники этой группы
считаются администраторами служб, потому что обладают правом выполнять
локальный вход в систему и восстанавливать файлы, в том числе и системные, на
контроллерах домена. Microsoft рекомендует ограничить членство в группе
Операторы архива лишь теми участниками, которые выполняют резервное
копирование и восстановление данных контроллеров домена.
На каждом рядовом сервере также имеется встроенная локальная группа
Операторы архива. Microsoft рекомендует не вводить лиц, ответственных за
резервное копирование данных приложений, таких как SQL Server, в группу
Операторы архива в Active Directory, а сделать их участниками локальной группы
Операторы архива данного сервера. Членство в группе Операторы архива в Active
Directory следует ограничить лишь теми участниками, которые архивируют и
восстанавливают данные контроллеров домена.
На выделенном контроллере домена можно сократить количество участников
группы Операторы архива. Когда контроллер домена используется для выполнения
других приложений, как это может иметь место в филиале, лица, ответственные за
архивацию данных приложений, должны обладать правами администраторов
служб, необходимыми для восстановления файлов, в том числе и системных,
контроллеров домена.
Необходимо избегать прямого делегирования задач по «администрированию
данных», таких как управление учетными записями, группе Операторы учета.
Стандартные разрешения для каталога обеспечивают этой группе возможность
изменять состав участников других групп администраторов служб, таких как
Операторы сервера, поэтому участники группы Операторы учета могут расширить
свои права до уровня администраторов служб. По умолчанию группа Операторы
учета пуста, и список ее участников должен оставаться пустым.
Существующие встроенные группы обычно имеют больше прав и разрешений, чем
это необходимо для осуществления определенной роли. Поэтому Microsoft
рекомендует использовать не встроенные группы, а создавать специальные группы
доступа и назначать им необходимые права и разрешения. Создавая специальные
группы, вы можете назначить им лишь те права, которые необходимы для
выполнения определенной роли в вашей организации. Например, можно создать
новую группу доступа Персонал службы технической поддержки и предоставить ей
только те права и разрешения, которые необходимы ее участникам для
выполнения их роли.

Шифровать данные, хранящиеся на локальных дисках, с


помощью шифрования дисков BitLocker
Шифрование дисков BitLocker – это компонент защиты данных, доступный в
операционных системах Windows Vista® Enterprise и Windows Vista® Ultimate для
клиентских компьютеров и в Windows Server 2008. BitLocker предоставляет
улучшенную защиту против хищения данных или использования компьютера в
случае его потери или кражи, а также более безопасное удаление данных при
списании компьютеров, защищенных BitLocker.
В случае потери или кражи компьютера хранящиеся на нем данные оказываются
уязвимыми для несанкционированного доступа, как путем использования
программных средств для несанкционированного доступа, так и путем переноса
жесткого диска на другой компьютер. Сочетая два основных механизма защиты
данных, BitLocker помогает сократить вероятность доступа к данным на потерянных
или похищенных компьютерах:
 Шифрование всего тома операционной системы Windows и томов данных
на жестком диске. BitLocker шифрует в томе операционной системы все
файлы пользователя и системные файлы, включая файлы подкачки и
данных спящего режима, также могут шифроваться тома данных.
 Проверка целостности компонентов загрузки и конфигурационных данных
загрузки в самом начале загрузки. На компьютерах с Доверенным
платформенным модулем (Trusted Platform Module, TPM) версии 1.2
BitLocker, используя расширенные возможности безопасности TPM,
гарантирует, что ваши данные доступны только при условии целостности
компонентов загрузки компьютера и размещения шифрованного диска на
исходном компьютере.
Доступный для записи контроллер домена содержит все пароли учетных записей
домена, сертификаты X.509 и другую касающуюся безопасности информацию.
Поэтому использование BitLocker для шифрования томов обеспечивает
дополнительную защиту на случай кражи контроллера домена или его жесткого
диска. В контроллерах RODC хранится лишь часть этой информации, но Microsoft
все равно рекомендует использовать шифрование томов с помощью BitLocker.
Более подробную информацию о настройке BitLocker для Windows Server 2008
можно найти в статье BitLocker Drive Encryption (Шифрование дисков BitLocker).
Примечание Обезопасьте основные ключи тома BitLocker в контроллерах домена с
помощью TPM и ключа запуска или TPM и PIN. TPM не должен быть единственным методом
защиты основных ключей тома для контроллеров домена.
Больше информации о лучших практиках использования BitLocker представлено в
следующих источниках:
 IT Showcase: Optimizing Client Security by Using Windows Vista (Демонстрация
для ИТ-специалистов: оптимизация безопасности клиента с использованием
Windows Vista).
 Secure Hardware - Overview (Обзор аппаратных средств защиты).

Архивировать информацию восстановления для BitLocker и TPM


Во время установки для каждого тома с поддержкой BitLocker создается пароль
восстановления. Если используется и TPM, требуется также задать пароль
владельца TPM. Необходимую для этих технологий информацию восстановления
можно хранить в AD DS.
Сохранение резервной копии паролей восстановления для тома диска,
защищенного BitLocker, позволяет администраторам восстанавливать том в случае
его блокировки. Это гарантированно обеспечивает возможность доступа к
шифрованным данным предприятия авторизованным пользователям.
Примечание Этот метод создания резервной копии паролей восстановления предполагает
наличие в организации нескольких контроллеров домена. Если имеется только один
контроллер домена, пароли восстановления необходимо копировать и на съемные носители.
Резервное копирование сведений о владельце TPM для компьютера позволяет
администраторам локально и удаленно конфигурировать оборудование
безопасности TPM этого компьютера. Например, при выводе из эксплуатации или
изменении назначения компьютера администратор может восстановить для TPM
значения по умолчанию.
Больше информации о конфигурировании AD DS для резервного копирования
информации восстановления BitLocker и TPM можно найти в статье Configuring
Active Directory (Настройка Active Directory).

Защитить ключ запуска компьютера с помощью Syskey


Как правило, в безопасных средах центров обработки данных выполнять
перезапуск контроллеров домена может только авторизованный персонал. Однако
в среде, в которой невозможно строго выполнить эти рекомендации, например в
филиалах, существует повышенная вероятность того, что перезапуск контроллера
выполнит неавторизованное лицо.
Незапланированный или неожиданный перезапуск контроллера домена может
свидетельствовать о том, что он был запущен злоумышленником в альтернативной
операционной системе и его безопасность нарушена. С другой стороны, перезапуск
может произойти всего лишь из-за отключения электропитания или планового
обслуживания контроллера домена. В следующих разделах рассматриваются
методы, зависимости и соображения относительно SYSKEY, на основании которых
можно определить оптимальный вариант использования SYSKEY в вашей среде.
Можно ли применять SYSKEY для вашей среды?
Системный ключ (system key, SYSKEY) в операционной системе Windows
защищает информацию системы безопасности, включая хранящиеся в базе данных
Active Directory пароли, а также данные службы Локальной проверки подлинности
(Local Security Authority, LSA), от физического несанкционированного доступа путем
кодирования их хранилища в контроллере домена. SYSKEY может базироваться на
заданном вами пароле, или храниться на съемном носителе, таком как гибкий диск
или USB-накопитель.
Примечание SYSKEY защищает только информацию системы безопасности в Active Directory
или другие данные LSA. BitLocker защищает все данные, хранящиеся в шифрованных
BitLocker томах. SYSKEY должен использоваться для защиты информации Active Directory и
данных LSA в тех случаях, когда невозможно шифрование всего тома.
При запуске контроллера домена, защищенного этим методом, для успешного
перезапуска компьютера необходимо ввести пароль или применить съемный
носитель с SYSKEY. Чтобы выбрать, какой из этих методов будет применяться для
запуска компьютера, можно использовать утилиту системного ключа (Syskey.exe),
которая устанавливается в контроллере домена вместе с Windows Server 2008.
Применение SYSKEY обеспечивает следующие преимущества в обеспечении
безопасности:
 Управление моментом перезапуска контроллера домена, что позволяет
установить причину перезапуска контроллера домена и определить, не
была ли нарушена безопасность.
 Защиту паролей, хранящихся в базе данных каталога, от физического
несанкционированного доступа в случае похищения контроллера домена
или диска.
При использовании SYSKEY существуют определенные логистические проблемы,
связанные с эксплуатацией. Первая из них – управление паролями или съемными
носителями SYSKEY. Например, довольно проблематично требовать от
руководителя филиала или локальных администраторов приходить в офис в 3 утра,
чтобы ввести пароль или вставить съемный носитель.
Чтобы решить эту проблему, можно разрешить ИТ-персоналу по эксплуатации из
центрального офиса предоставлять пароль SYSKEY удаленно. Для обеспечения
удаленного управления потребуется дополнительное оборудование. Таким
образом, ИТ-персонал по эксплуатации может вводить пароль или подключать
виртуальные образы гибких дисков, содержащие SYSKEY.
Другая потенциальная проблема – если пароль или съемный носитель SYSKEY
утеряны, никто не сможет перезапустить контроллер домена. Невозможно
восстановить контроллер домена, если пароли или съемный диск SYSKEY
утрачены. В этом случае придется полностью перестраивать контроллер домена.
У каждого метода есть преимущества и потенциальные недостатки. Если принято
решение применять для защиты контроллеров домена SYSKEY, проведите анализ
своей среды, чтобы определить наиболее подходящий для вашей организации
метод.
Задание паролей SYSKEY для перезапусков контроллеров домена
Преимущество паролей SYSKEY в том, что для них не требуется физических
носителей, которые могут быть утеряны. Когда требуется перезапустить
контроллер домена, проверенный персонал должен ввести пароль в консоль,
подключенную к контроллеру домена. Пароль должна знать только небольшая
группа проверенных администраторов, желательно, только участникам группы
Администраторы домена. Недостаток применения пароля для защиты SYSKEY –
администраторы должны запоминать еще один пароль, и для применения пароля
требуется их личное присутствие.
Для поддержки филиалов, возможно, понадобиться предоставлять пароль SYSKEY
удаленно с помощью проверенного ИТ-персонала центрального офиса. Однако
удаленное управление потребует дополнительного оборудования.
Поскольку злоумышленники могут раскрыть пароли, Microsoft рекомендует
повышать безопасность паролей SYSKEY для перезапусков SYSKEY следующим
образом:
 Использовать надежные пароли.
 Хранить пароли в безопасном месте, таком как банковский депозитарий.
 Выдвинуть требование о периодическом изменении паролей SYSKEY.
Предоставление SYSKEY для перезапусков контроллеров домена на съемном
носителе
Преимущество предоставления SYSKEY на съемном носителе в том, что
администраторам не придется запоминать пароль. Однако при реализации
SYSKEY с использованием съемного носителя возникает риск потери или
повреждения этого физического носителя. Более того, при перезагрузках
контроллера домена съемный носитель необходимо вставлять в компьютер. Опять
же, только проверенный персонал, желательно участники группы Администраторы
домена, должен иметь доступ к съемному носителю SYSKEY.
Для поддержки удаленного управления филиалами, вероятно, придется установить
оборудование сторонних производителей, чтобы можно было удаленно передавать
образы гибких дисков в контроллер домена. Используя эти устройства,
проверенный ИТ-персонал центрального офиса может передавать копию образа
диска SYSKEY в удаленный контроллер домена. После перезапуска контроллера
домена удаленный образ гибкого диска SYSKEY может быть уничтожен ИТ-
персоналом по эксплуатации.
Поскольку съемный носитель содержит ключ шифрования для SYSKEY,
необходимо предпринять меры по предотвращению кражи, потери, повреждения
или копирования данных съемного носителя неавторизованными лицами. Microsoft
рекомендует следующие меры по устранению этих рисков:
 Создать копию съемного носителя и хранить ее вне организации, например,
в банковском депозитарии.
 Хранить рабочую копию съемного носителя в безопасном месте в
организации.
 Убирать съемный носитель сразу после перезапуска контроллера домена.
Соответствующие параметры групповой политики
Domain Controller Baseline Policy (Базовая политика контроллера домена, DCBP),
дополняющая Default Domain Controller Policy (Стандартная политика контроллера
домена), связывается с подразделением Domain Controllers (Контроллеры домена).
Параметры DCBP повышают общий уровень безопасности контроллеров домена в
любой среде. Использование лишь двух объектов GPO для реализации
безопасности контроллеров домена обеспечивает защиту стандартной среды и
упрощает поиск и устранение неисправностей.
Более подробную информацию об этих параметрах можно найти в следующих
источниках:
 Приложении А «Параметры групповой политики, связанные с
безопасностью», сопровождающем данное руководство.
 Прилагаемом к данному руководству «Сборнике параметров, используемых
в руководстве по безопасности Windows Server 2008».

Дополнительные источники
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службу роли Контроллер домена Active Directory, можно
найти в следующих источниках:
 Active Directory.
 AD DS: Fine-Grained Password Policies.
 Приложение D: Active Directory.
 Best Practices for Delegating Active Directory.
 BitLocker Drive Encryption.
 Configuring Active Directory.
 IT Showcase: Optimizing Client Security by Using Windows Vista.
 Managing Active Directory.
 «RODC filtered attribute set» (Отфильтрованный набор атрибутов
контроллера домена только для чтения) в RODC Features.
 Secure Hardware - Overview.
 Server Core.
 Set computer-specific synchronization properties (Задание специальных
свойств синхронизации компьютера).

Служба роли Диспетчер удостоверений для


UNIX
Используя службу роли Диспетчер удостоверений для UNIX, можно выполнять
1
аутентификацию учетных данных в Active Directory по протоколу NIS и выполнять
синхронизацию паролей учетных записей, хранящихся в Active Directory, с
паролями учетных записей, которые хранятся на NIS-серверах, работающих под

1
Network Information Services – сетевые информационные службы (прим.
переводчика).
управлением UNIX. Служба роли Диспетчер удостоверений для UNIX включает
следующие подсистемы службы роли:
 Сервер для сетевых информационных служб (Server for Network
Information Services)
 Синхронизация паролей (Password Synchronization)
Этим подсистемам службы роли посвящены следующие разделы. Более
подробную информацию о службе роли Диспетчер удостоверений для UNIX можно
найти в разделе Обзор диспетчера удостоверений для UNIX службы Справка и
поддержка Windows Server 2008.

Сервер для сетевых информационных служб


Подсистема службы Сервер для NIS интегрирует сети Microsoft Windows® и NIS,
предоставляя контроллеру домена AD DS на базе Windows возможность выступать
в роли основного NIS-сервера для одного или более доменов NIS.
Сервер для NIS хранит и стандартные, и нестандартные сопоставления данных NIS
с AD DS и создает единое пространство имен для доменов Windows и NIS.
Администратор Windows может управлять этим пространством имен, используя
один набор инструментов, и без труда создавать, изменять и удалять учетные
записи пользователей для доменов Windows и UNIX с поддержкой NIS
одновременно. Управление пользователем, имеющим учетные записи в обеих
средах, и в Windows, и в UNIX, может осуществляться AD DS с использованием
всех атрибутов, необходимых для соответствующего домена и пространства имен.
Сервер для NIS обычно используется в сочетании с Сервером для Network File
1
System (NFS) . NFS предоставляет общий доступ к файлам клиентам NFS, которые
обычно располагаются на компьютерах, работающих под управлением UNIX.

Поверхность атаки
Служба роли Сервер для сетевых информационных служб (NIS) подвержен тем же
атакам на систему безопасности, что и NIS-сервер. Чтобы определить поверхность
атаки для этой службы роли, необходимо установить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли Сервер для NIS.
 Выполняющиеся службы. Это сервисы, выполняющиеся как часть службы
роли Сервер для NIS.
Примечание Для проверки целостности установленных файлов и файлов, выполняемых
службами, можно воспользоваться утилитами RootkitRevealer и Sigcheck, являющимися
частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это правила брандмауэра Windows, используемые
службой роли Сервер для NIS.
 Зависимости роли. Это зависимости службы роли Сервер для NIS.
Более подробная информация о службе роли Сервер для NIS представлена в
Справочнике по поверхности атаки для Windows Server 2008, прилагаемом к
данному руководству. Оценить поверхность атаки для данной службы роли можно

1
Сетевая файловая система (прим. переводчика).
при помощи вкладки AD DS книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию службы роли Сервер для NIS для защиты сервера
от злоумышленных атак. Приведенные далее рекомендации предполагают, что на
странице Выбор служб роли Мастера добавления ролей была выбрана только
служба роли Сервер для сетевых информационных служб. Рекомендации для
других служб роли не включены.

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих службу роли
Сервер для NIS. При возникновении каких-либо трудностей по выполнению этих
задач, обратитесь к следующим разделам данной главы за дополнительной
информацией и рекомендациями.
Таблица 3.3. Контрольный список настройки
Задачи настройки
Конфигурировать компьютер для выполнения Сервера для NIS в режиме
главного сервера.
Потребовать от пользователей изменения их паролей Windows.
Примечание Служба роли Сервер для сетевых информационных служб недоступна в
установке Server Core Windows Server 2008.

Конфигурировать компьютер для выполнения Сервера для NIS в


режиме главного сервера
Для работы Сетевых информационных служб (NIS) компьютер может выполнять их
в режиме главного или подчиненного сервера. Основное отличие этих двух
режимов в том, что и подчиненный, и главный серверы могут читать данные
сопоставлений, но только главный сервер может обновлять их. Кроме того, главный
NIS-сервер обеспечивает периодические обновления сопоставлений для
подчиненных серверов.
Конфигурируйте один из компьютеров, выполняющих Сервер для NIS, как главный
NIS-сервер. Таким образом, главный NIS-сервер, выполняющийся под управлением
Windows, будет гарантированно получать обновления от других NIS-серверов,
выполняющихся в подчиненном режиме. Хранение данных в Active Directory
обеспечивает им более надежную защиту, чем обычно, когда они хранятся на
файловой системе UNIX.
Боле подробную информацию о режимах основного и подчиненного сервера и о
взаимодействии между компьютерами, работающими в этих режимах, можно найти
в разделе «Главный и подчиненный режимы работы сервера» службы Справка и
поддержка для Windows Server 2008.
Потребовать от пользователей изменения их паролей Windows
Обычно пользователи, работающие в операционных системах UNIX или LINUX,
меняют свои пароли NIS с помощью команды yppasswd. Эта команда используется
для обновления пароля пользователя в NIS. Команда yppasswd посылает старый
пароль на NIS-сервер в простой текстовой форме, поэтому эта команда может
стать причиной раскрытия паролей Windows пользователей.
Вместо применения этой команды пользователи должны изменять NIS-пароль,
меняя пароли Windows, а Сервер для Сетевых информационных служб будет
синхронизировать изменение пароля с подчиненными NIS-серверами.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли Сервер для NIS.

Дополнительные источники
В этом источнике предлагается дополнительная информация по лучшим практикам
повышения уровня защиты компьютеров-серверов, выполняющих службу роли
Сервер для NIS.
 В разделе «Сервер для NIS» службы Справка и поддержка для Windows
Server 2008.

Синхронизация паролей
Служба роли Синхронизация паролей помогает интегрировать сети Windows и
UNIX, упрощая процесс обслуживания безопасных паролей в обеих средах. Она
устраняет необходимость обслуживать отдельные пароли для учетных записей
Windows и UNIX и меняет пароли в обеих системах. Когда используется служба
роли Синхронизация паролей, при изменении пользователем паролей в
компьютере домена, работающем под управлением Windows, пароли
автоматически меняются на всех UNIX-хостах, на которых имеются учетные записи
этого пользователя. Также можно настроить службу роли Синхронизация паролей
на автоматическое изменение паролей Windows пользователя при любом
изменении им паролей UNIX.
Больше информации о службе роли Синхронизация паролей можно найти в
разделе «Синхронизация паролей с NIS-доменом» службы Справка и поддержка
для Windows Server 2008.

Поверхность атаки
Служба роли Синхронизация паролей подвержена тем же атакам на систему
безопасности, что и любой контроллер домена AD DS. Чтобы определить
поверхность атаки для этой службы роли, необходимо установить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли Синхронизация паролей.
 Выполняющиеся службы. Это сервисы, выполняющиеся как часть службы
роли Синхронизация паролей.
Примечание Для проверки целостности установленных файлов и файлов, выполняемых
службами, можно воспользоваться утилитами RootkitRevealer и Sigcheck, являющимися
частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это правила брандмауэра Windows, используемые
службой роли Синхронизация паролей.
 Зависимости роли. Это зависимости службы роли Синхронизация
паролей.
Более подробная информация о службе роли Синхронизация паролей
представлена в Справочнике по поверхности атаки для Windows Server 2008,
прилагаемому к данному руководству. Оценить поверхность атаки для данной
службы роли можно при помощи вкладки AD DS книги в разделах,
соответствующих каждому из пунктов предыдущего списка.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих службу роли
Синхронизация паролей. При возникновении каких-либо трудностей по выполнению
этих задач, обратитесь к следующим разделам данной главы за дополнительной
информацией и рекомендациями.
Таблица 3.4. Контрольный список настройки
Задачи настройки
Гарантировать согласованность политик паролей Windows и UNIX.
Задать для компьютера собственный уникальный ключ шифрования паролей.
Явно перечислить пользователей, для которых разрешена или заблокирована
синхронизация паролей.
Блокировать синхронизацию паролей деактивированных учетных записей
пользователей UNIX.
Избегать синхронизации паролей пользователей с расширенными
привилегиями.
Не использовать стандартный номер порта и ключ шифрования.
Защитить файл sso.conf.
Обеспечить соответствующую защиту каталогу на хосте UNIX,
идентифицированному константой TEMP_FILE_PATH.
Задачи настройки
Обеспечить соответствующую защиту файлам журнала на хосте UNIX.
Примечание Служба роли Синхронизация паролей недоступна в установке Server Core
Windows Server 2008.

Гарантировать согласованность политик паролей Windows и UNIX


Предоставляя только одностороннюю синхронизацию паролей, убедитесь, что
политика паролей на компьютере, с которого будет выполняться синхронизация, по
крайней мере, обладает таким же уровнем ограничений, что и политика на
компьютере, на котором будут синхронизироваться пароли. Например, если задать
синхронизацию Windows-UNIX, политика паролей Windows должна быть, по
крайней мере, настолько же строгой, как и политика компьютеров под управлением
UNIX, на которых будут синхронизироваться пароли.
Если поддерживается двухсторонняя синхронизация, политики паролей должны
быть одинаково строгими в обеих системах. Несогласованность политик может
привести к сбою синхронизации при изменении пароля в системе с менее строгой
политикой, или пароль может быть изменен в системе с более строгими
политиками, несмотря на его несоответствие им.
Также обеспечьте осведомленность пользователей Windows обо всех специальных
ограничениях для паролей в системах UNIX, с которыми они будут
синхронизировать пароли. Например, в некоторых версиях UNIX максимальная
длина пароля – восемь символов. Если вы не уверены в том, что все системы UNIX
вашей среды поддерживают более длинные пароли, для обеспечения
максимальной совместимости стандартной политики паролей Windows и таких
ограничений UNIX определите максимальную длину паролей в семь или восемь
символов.

Задать для компьютера собственный уникальный ключ


шифрования паролей
Компьютер под управлением Windows может посылать и принимать обновленные
пароли с компьютеров, работающих под управлением UNIX, только в виде
шифрованного текста. Управляющая программа единого входа (single sign-on
daemon, SSOD) службы роли Синхронизация паролей получает шифрованный
пароль, дешифрует его и только потом запрашивает изменение пароля в хосте
UNIX.
Аналогично, если служба роли Синхронизация паролей настроена на поддержку
синхронизации UNIX-Windows, подключаемый модуль аутентификации (pluggable
authentication module, PAM) шифрует пароль перед его отправкой в службу
Синхронизации паролей на компьютере, работающем под управлением Windows.
Служба Синхронизации паролей сначала дешифрует пароль, а потом пошлет
запрос на изменение пароля в компьютер Windows.
Для обеспечения дополнительной безопасности можно задать ключ шифрования,
который будет использоваться только между конкретным компьютером,
выполняющим Windows, и UNIX-хостом. Таким образом, дешифрация паролей
будет возможна только между определенными компьютерами. Дополнительную
информацию можно найти в статье Set computer-specific synchronization properties.
Явно перечислить пользователей, для которых разрешена или
заблокирована синхронизация паролей
Чтобы получить максимальный контроль над тем, кто из пользователей может
синхронизировать пароли, не применяйте ключевое слово ALL к списку
SYNC_USERS в файле sso.conf на UNIX-хосте. Лучше явно перечислить всех
пользователей, которым вы хотите разрешить или запретить синхронизацию
паролей.
На компьютере, работающем под управлением Windows и выполняющем службу
Синхронизация паролей, создайте группу PasswordPropAllow и добавьте в нее
учетные записи тех пользователей, пароли которых вы хотите синхронизировать.
Дополнительную информацию по этой теме можно найти в статье Controlling
password synchronization for user accounts (Управление синхронизацией паролей
для учетных записей пользователей).

Блокировать синхронизацию паролей деактивированных


учетных записей пользователей UNIX
В некоторых версиях UNIX изменение пароля деактивированной учетной записи
пользователя приводит к активации этой учетной записи. Таким образом, если
пользователь деактивировал учетную запись на UNIX-компьютере, который
конфигурирован на синхронизацию паролей с Windows-компьютером, пользователь
или администратор может активировать учетную запись UNIX, изменив пароль
пользователя в Windows.
Чтобы предотвратить это и блокировать синхронизацию для деактивированных
учетных записей UNIX, используйте группу PasswordPropDeny. Также при
деактивации учетной записи UNIX не забудьте блокировать для нее синхронизацию
паролей, используя запись SYNC_USERS в файле sso.conf.

Избегать синхронизации паролей пользователей с


расширенными привилегиями
Не выполняйте синхронизацию паролей для участников групп Windows с
расширенными привилегиями или владельцев учетных записей супер-
пользователь или root в UNIX, потому что расширенные права этих учетных
записей не распространяются на другую систему. Например, участники группы
Администраторы домена не обладают по умолчанию более высоким уровнем
привилегий на компьютерах, выполняющих UNIX.

Не использовать стандартный номер порта и ключ шифрования


В случае использования стандартного номера порта и ключа шифрования
злоумышленник может настроить подставной UNIX-хост для перехвата паролей.
Чтобы предотвратить такую возможность, измените порт и стандартный ключ
шифрования паролей, используемые службой синхронизации.
Примечание Используемые для синхронизации паролей номера портов и ключи
шифрования должны быть защищены так же, как сами пароли.
Более подробную информацию по этим вопросам можно найти в следующих
разделах службы Справка и поддержка для Windows Server 2008:
 «Setting the default port» (Настройка порта по умолчанию)
 «Setting the password encryption key» (Установка ключа шифрования
пароля).

Защитить файл sso.conf


В файле sso.conf на каждом UNIX-хосте содержится важная конфигурационная
информация, которая может быть использована злоумышленниками для
нарушения безопасности. Microsoft рекомендует для усиления защиты этого файла
задать для нее битовую маску состояния равную 600.

Обеспечить соответствующую защиту каталогу на хосте UNIX,


идентифицированному константой TEMP_FILE_PATH
Временные файлы, создаваемые на UNIX-хостах службой Синхронизации паролей,
содержат важную информацию, которая может быть использована
злоумышленниками для нарушения безопасности системы. По этой причине все
каталоги, указанные в TEMP_FILE_PATH в файле sso.conf, должны гарантированно
иметь доступ только для чтения для учетной записи администратора, и никто из
пользователей не должен иметь доступа к этой учетной записи.

Обеспечить соответствующую защиту файлам журнала на хосте


UNIX
Для протоколирования сообщений, формируемых в ходе операций синхронизации,
служба Синхронизации паролей использует службу syslogd. В получаемых в
результате журналах регистрации содержится такая информация, как имена
пользователей, синхронизация паролей которых выполнялась, компьютеры, с
которыми выполнялась синхронизация, накапливающиеся ошибки и т.д. Чтобы
гарантировать невозможность доступа к файлам журнала остальных
пользователей, кроме администратора, предоставьте возможность доступа к
каталогу с файлами журналов только учетной записи администратора. В
настройках службы syslogd задайте каталог, в который будут сохраняться файлы
журнала.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли Синхронизация
паролей.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов можно найти в следующих источниках:
 Для компьютеров, выполняющих службу роли Контроллер домена Active
Directory:
o Active Directory.
o AD DS: Fine-Grained Password Policies.
o Приложение D: Active Directory.
o Best Practices for Delegating Active Directory.
o BitLocker Drive Encryption.
o Configuring Active Directory.
o IT Showcase: Optimizing Client Security by Using Windows Vista.
o Managing Active Directory.
o «RODC filtered attribute set» в RODC Features.
o Secure Hardware - Overview.
o Server Core.
o Set computer-specific synchronization properties.
 Для получения информации о службе роли Сервер сетевых
информационных служб (NIS) обратитесь к:
o «Сервер для NIS» в разделе Справка и поддержка для Windows
Server 2008.
 Для получения информации о службе роли Синхронизация паролей
обратитесь к:
o Controlling password synchronization for user accounts.
o «Синхронизация паролей» в разделе Справка и поддержка для
Windows Server 2008.
o Set computer-specific synchronization properties.
o «Настройка порта по умолчанию» в разделе Справка и поддержка
для Windows Server 2008.
o «Установка ключа шифрования пароля» в разделе Справка и
поддержка для Windows Server 2008.

Глава 4: Повышение уровня защиты служб DHCP


Серверы DHCP (Dynamic Host Configuration Protocol) используются в сетях
организаций для автоматической выдачи корректных IP-адресов для клиентских
компьютеров и других сетевых устройств, работающих по протоколу TCP/IP. DHCP
также могут предоставлять дополнительные параметры настройки, так называемые
опции DHCP, которые обеспечивают возможность клиентским компьютерам и
устройствам соединяться с другими сетевыми ресурсами, такими как DNS-серверы
и маршрутизаторы.
Служба DHCP-сервер и служба DHCP-клиент в Windows Server® 2008 включают
следующие связанные с обеспечением безопасности новые возможности, которых
не было в предыдущих версиях Windows Server:
 Функциональность DHCPv6. В Windows Server 2008 Microsoft была
введена функциональность DHCPv6 для DHCP-сервера. Клиентские
компьютеры используют режим без состояния DHCPv6 для получения
только параметров конфигурации сети без IPv6-адреса. В данном сценарии
IPv6-адрес настраивается через механизм, не основанный на DHCPv6,
например, через автонастройку IPv6-адреса на базе IPv6-префиксов,
включенных в объявления маршрутизатора (Router Advertisements), или
через статическую конфигурацию. В режиме с состоянием клиентские
компьютеры получают через DHCPv6 и IPv6-адрес, и остальные параметры
конфигурации сети. Если IPv6 не развернут в вашей среде, DHCP
обеспечивает настройку IP только для IPv4-адресов. Больше информации о
DHCPv6 можно найти в статье The DHCPv6 Protocol (Протокол DHCPv6) на
сайте TechNet.
 Защищенный сетевой доступ (Network Access Protection, NAP). NAP
интегрирован с DHCP и вынуждает клиентов при получении IP-адреса для
доступа в интрасеть подтверждать безопасное состояние своей системы
для сети. NAP поддерживается в DHCP для адресов IPv4, не IPv6. Больше
информации о NAP можно найти в следующих ресурсах:
o Статья «Network Access Protection» (Защищенный сетевой доступ)
на сайте Microsoft TechNet.
o Step-by-Step Guide: Demonstrate NAP DHCP Enforcement in a Test
Lab (Пошаговое руководство: как обеспечить работоспособность
DHCP с помощью NAP в лабораторных условиях).
В данной главе дается нормативное руководство по повышению уровня защиты
роли DHCP-сервер. У роли DHCP-сервер нет подчиненных служб роли.

Поверхность атаки
Роль DHCP во многом подвержена тем же атакам на систему безопасности, что и
любой сервер, предоставляющий службы DHCP. Чтобы обозначить всю
поверхность атаки для этой роли, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть роли DHCP-
сервера.
 Выполняющиеся службы. Это службы, выполняющиеся как часть роли
DHCP-сервера.
Примечание Для проверки целостности установленных файлов и файлов, выполняемых
службой, можно воспользоваться утилитами RootkitRevealer и Sigcheck, являющимися
частью пакета служебных программ Windows Sysinternals
 Правила брандмауэра. Это используемые ролью DHCP-сервера правила
брандмауэра.
 Зависимости роли. Это зависимости роли DHCP-сервера.
Подробная информация о поверхности атаки для роли DHCP-сервера включена в
книгу «Справочник по поверхности атаки в Windows Server 2008», прилагаемой к
данному руководству. Оценить поверхность атаки для данной службы роли можно
при помощи вкладки AD DS книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию роли DHCP-сервера для защиты сервера от
злоумышленных атак. Приведенные ниже рекомендации предполагают, что на
странице Выбор служб роли Мастера добавления ролей выбрана только опция
DHCP-сервер. Рекомендации для других служб роли не включены.
Контрольный список настройки
В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих роль DHCP-
сервера. При возникновении каких-либо трудностей по выполнению этих задач
обратитесь к следующим разделам данной главы за дополнительной информацией
и рекомендациями.
Table 4.1. Контрольный список настройки
Задачи настройки
Использовать выделенный компьютер для выполнения роли DHCP-сервера.
Развернуть установку Server Core Windows Server 2008.
Использовать функциональность DHCPv6.
Исключить компьютеры, выполняющие неавторизованные DHCP-службы.
Добавить DHCP-диапазоны резервирования и исключения для IP-адресов.
Использовать NAP для обеспечения безопасности конфигурации компьютера.
Ограничить количество участников группы доступа DHCP.
Настроить принадлежность записей DNS, чтобы предотвратить возникновение
устаревших записей DNS.

Использовать выделенный компьютер для выполнения роли


DHCP-сервера
Как правило, комбинировать роли сервера не рекомендуется, за исключением
особых обстоятельств. Например, в некоторых организациях можно было бы
совмещать роли серверов DNS и AD DS. Однако DHCP-серверы часто
представляют критическую нагрузку для среды. Комбинирование ролей серверов
увеличивает поверхность атаки и повышает шансы на успех в реализации атак
типа отказ в обслуживании (Denial of Service, DoS). По этим причинам Microsoft
обычно не рекомендует сочетать роль DHCP-сервера с какой-либо иной ролью.
Но если по финансовым или другим соображениям организация вынуждена
комбинировать роли сервера, роль DHCP-сервер можно сочетать с другими ролями
сервера среды. Подходящим вариантом могла бы быть роль сервера Windows
1
Internet Name Service (WINS) , хотя многие среды Windows Server 2008 больше не
нуждаются в WINS-сервере. Microsoft рекомендует избегать комбинирования роли
DHCP-сервера с такими ролями:
 С ролями сервера, характеризующимися менее строгими политиками,
такими как роль Веб-сервер или роль Сервер служб терминалов
 С ролью AD DS, поскольку для этой роли сервера очень важно
максимально сократить поверхность атаки.
 С ролью AD CS, поскольку для этой роли сервера очень важно
максимально сократить поверхность атаки.

1
Служба имeн в Интернете для Windows (прим. переводчика).
Развернуть установку Server Core Windows Server 2008
Развертывание Windows Server 2008 с использованием опции установки Server
Core обеспечивает сокращение поверхности атаки для операционной системы за
счет ограничения числа необходимых файлов и служб. Преимущество опции Server
Core в том, что в случае ее применения не устанавливаются файлы и службы для
графического пользовательского интерфейса (GUI).
Если для развертывания операционной системы Windows Server 2008 используется
опция установки Server Core, управлять сервером можно только локально с
помощью инструментов командной строки. Чтобы управлять сервером через
инструменты графического пользовательского интерфейса, необходимо установить
и запустить их на другом компьютере, на котором установлен GUI на базе Windows.
Для управления ролью DHCP-сервер используются следующие инструменты
командной строки:
 Чтобы установить роль DHCP-сервер, выполните следующую команду:
start /w ocsetup DHCPServerCore
 Чтобы настроить службу DHCP-сервер, выполните следующую команду:
sc config dhcpserver start = auto
Примечание Пробел между "start" и "=" обязателен. Также необходим пробел
между "=" и "auto".
 Чтобы запустить службу DHCP-сервер, выполните следующую команду:
net start dhcpserver
 Чтобы конфигурировать DHCP-серверы, области действия DHCP и опции
областей действия DHCP, выполните следующие команды:
netsh DHCP
netsh DHCP server
netsh DHCP server scope
netsh DHCP server mscope
Дополнительную информацию по управлению ролью DHCP-сервер с
помощью netsh можно найти в статье Netsh commands for DHCP
(Использование команды Netsh для настройки DHCP).
 Чтобы установить роль DHCP-сервер, выполните следующую команду:
start /w ocsetup DHCPServerCore /uninstall
Дополнительную информацию по установке и управлению ролью DHCP-сервер с
использованием опции установки Server Core можно найти в материале Server Core
Installation Option of Windows Server 2008 Step-By-Step Guide.

Использовать функциональность DHCPv6


Протокол IPv6 обеспечивает компьютерам возможность автоматически получать
IP-адреса, используя автоматическую настройку режима без состояния. Этот
протокол не требует наличия DHCP-сервера и гарантирует уникальность IP-
адресов, потому что использует MAC-адрес сетевого адаптера как часть адреса и
затем рассылает многоадресный пакет, чтобы убедиться, что этот IP-адрес не
используется ни одним другим хостом в сегменте сети.
Даже если DHCP-сервер использует автоматическую настройку режима без
состояния, его все равно можно применять для предоставления дополнительных
опций настройки сети. Windows Server 2008 поддерживает автоматическую
настройку режима без состояния, тем не менее, для обеспечения распределения
IPv6-адресов используйте в DHCP режим с состоянием.
Сформированные DHCPv6-сервером адреса хаотично распределены по
доступному адресному пространству подсети. Вероятность того, что
злоумышленники подберут сетевой IPv6-адрес, очень мала, потому что 64-
разрядный префикс IPv6 обеспечивает большой диапазон адресов, по которому
DHCP-сервер распределяет адреса случайным образом.
Роль DHCP-сервер посредством DHCPv6 также поддерживает постоянные и
временные адреса. Для динамической регистрации DNS можно использовать
постоянный IPv6-адрес, так что клиентский компьютер будет «известен» под этим
адресом. Но в сценариях, в которых требуется обеспечить конфиденциальность
постоянных адресов, для установления исходящего соединения можно
воспользоваться временным IPv6-адресом. С помощью Объявлений
маршрутизатора (Router Advertisements) администраторы могут автоматизировать
настройку IPv6 компьютеров на использование режима с и без состояния.

Исключить компьютеры, выполняющие неавторизованные


DHCP-службы
Одна из самых распространенных атак с участием DHCP-серверов –
использование неавторизованных серверов для выдачи адресов клиентским
компьютерам. В большинстве случаев такую атаку легко осуществить, потому что
для ее организации необходимо просто добавить в сеть, обслуживающую
клиентские компьютеры, дополнительный DHCP-сервер.
Для предотвращения возможности внедрения неавторизованных DHCP-серверов
Windows Server 2008 поддерживает авторизацию серверов в Active Directory®.
Чтобы компьютер, являющийся частью домена и работающий под управлением
Windows Server 2008, мог выдавать адреса, он должен быть зарегистрирован в
Active Directory.
Изолированным серверам с Windows Server® для выдачи предоставляемых в
аренду DHCP-адресов не требуется регистрация в Active Directory. Однако если
изолированный DHCP-сервер обнаруживает существующий домен в той же
подсети, он прекращает выдачу IP-адресов.
Если DHCP-сервер работает под управлением операционной системы отличной от
Windows Server, он не может быть оповещен о необходимости прекращения
выдачи IP-адресов. Чтобы компьютер, работающий не под управлением Windows,
прекратил предоставлять DHCP-сервис, необходимы другие механизмы
предотвращения его доступа во внутреннюю сеть, такие как физический контроль
над Ethernet и беспроводными соединениями.
С помощью инструмента командной строки DHCPLoc, который составляет список
всех DHCP-серверов в локальной подсети, можно выявлять неавторизованные
DHCP-серверы. Инструмент DHCPLoc доступен на компакт-диске продуктов
Windows® XP, Windows Vista®, Windows Server® 2003 и Windows Server 2008 в
разделе Windows Support Tools (Средства поддержки Windows) в папке
\Support\Tools.
Более подробную информацию об утилите DHCPLoc можно найти в статье Dhcploc
Overview (Обзор Dhcploc) на сайте TechNet.

Добавить DHCP-диапазоны резервирования и исключения для IP-


адресов
Гарантировать присвоение компьютерам корректных IP-адресов можно следующим
образом:
 Зарезервировав статические адреса, чтобы они случайно не были
присвоены другим IP-устройствам.
 Задав диапазон IP-адресов, чтобы предварительно выделить их для других
устройств.
Примечание Если IP-адрес зарезервирован и попадает в диапазон исключений,
резервирование будет иметь больший приоритет.

Использовать NAP для обеспечения безопасности конфигурации


компьютера
В случае применения DHCP в Windows Server 2008, прежде чем компьютеру будет
присвоена конфигурация IPv4, которая обеспечит ему доступ к вашей интрасети, он
подвергается проверке безопасности состояния для сети, осуществляемой NAP.
Если компьютер не проходит проверки безопасности, ему присваивается
конфигурация IPv4, обеспечивающая доступ только к изолированной сети. В ходе
проверки безопасности состояния выясняется, удовлетворяет ли или превышает
конфигурация целевого компьютера требованиям безопасности вашей
организации, таким как наличие последних пакетов обновлений или файлов
сигнатур антивирусов.
Если DHCP обеспечивает безопасность состояния клиента для сети посредством
NAP, требования политики проверки безопасности состояния контролируются при
каждой попытке DHCP-клиента получить в аренду или обновить IP-адрес. Если
DHCP-клиент не проходит проверку безопасности его состояния для сети, ему
предоставляет доступ только к изолированной сети.
К подсистемам DHCP обеспечения безопасности состояния клиента для сети
посредством NAP относятся DHCP-сервер проверки условий карантина (Quarantine
Enforcement Server, QES), который является частью службы DHCP-сервер в
Windows Server 2008, и DHCP-клиент проверки условий карантина (Quarantine
Enforcement Client, QEC), который является частью службы DHCP-клиент. Больше
информации о NAP можно найти в Главе 10 «Повышение уровня защиты служб
сетевого доступа» и в статье Network Access Protection.

Ограничить количество участников группы доступа DHCP


Можно создать следующие группы доступа для DHCP:
 Администраторы DHCP. Участники этой группы имеют право
администрировать DHCP-серверы, но обладают более низким уровнем
привилегий, чем группа Администраторы домена. Включая пользователей,
выполняющих конфигурирование и обслуживание DHCP, в группу
Администраторы DHCP, а не в группу Администраторы домена, вы
реализуете принцип предоставления минимальных прав. Применение
компонента групповой политики Группы с ограниченным доступом
гарантированно обеспечит неизменность участников группы
Администраторы DHCP. Более подробную информацию по этой теме
можно найти далее в данной главе в разделе «Соответствующие
параметры групповой политики».
 Пользователи DHCP. Участники этой группы имеют возможность доступа
только для чтения к информации через консоль управления Microsoft
Администрирование DHCP.

Настроить принадлежность записи DNS, чтобы предотвратить


возникновение устаревших записей DNS
DHCP-сервер можно конфигурировать так, чтобы он динамически регистрировал
записи хостов (А) и указателей на ресурсы (PTR) от лица DHCP-клиентов. При
такой конфигурации использование безопасного динамического обновления для
DNS-серверов может привести к появлению устаревших записей ресурсов.
В некоторых условиях это может привести к возникновению проблем. Например,
если сервер DHCP1 выходит из строя и к сети подключается резервный сервер
DHCP2, второй сервер не может обновлять имя клиента, потому что не является
владельцем имени.
Другой пример: если DHCP-сервер выполняет динамические обновления DNS для
DHCP-клиентов устаревшей версии (клиентских компьютеров, выполняющих
версии Windows®, предшествующие Windows® 2000), и впоследствии эти
клиентские компьютеры обновляются до операционной системы Windows 2000,
Windows XP или Windows Server 2003, обновленный клиентский компьютер не
может вступать во владение обновлением или обновлять собственные DNS-записи.
Для решения этой проблемы предоставляется группа доступа DnsUpdateProxy.
Если сделать все DHCP-серверы участниками группы DnsUpdateProxy, один сервер
сможет обновлять записи другого сервера в случае сбоя последнего. Также
поскольку все объекты, создаваемые участниками группы DnsUpdateProxy, не
защищены, сервер (не являющийся участником группы DnsUpdateProxy), который
изменит ассоциированный с именем DNS набор записей первым, становится его
владельцем.
Таким образом, после обновления клиентских компьютеров, выполняющих
устаревшие версии операционной системы, они могут стать владельцами записи об
их именах на DNS-сервере. Чтобы исключить потенциальную возможность
возникновения таких проблем, все регистрационные записи ресурсов DHCP-
сервера для клиентов устаревших версий необходимо сделать участником группы
DnsUpdateProxy. Настраивать группу доступа DnsUpdateProxy можно через Active
Directory - Пользователи и компьютеры.

Соответствующие параметры групповой политики


В следующей таблице перечислены параметры групповой политики, относящиеся к
службе роли DHCP-сервер. Используйте параметры групповой политики для
реализации необходимую конфигурацию системы безопасности своей среды.
Приведенные в следующей таблице параметры групповой политики можно найти в
Редакторе объектов групповой политики (Group Policy Object Editor) в разделе:
Конфигурация компьютера\Настройки Windows\Настройки
безопасности\Группы с ограниченным доступом
Таблица 4.2. Параметры групповой политики службы роли DHCP-сервер
Объект политики Описание Стандартные
настройки
Windows Server
2008
Администраторы Добавляйте учетные записи пользователей в Не создается.
DHCP эту группу по мере необходимости. Если
учетная запись добавлена в эту группу, но не
добавлена в данный объект политики, она
автоматически удаляется, и в журнале
безопасности, если вы активировали аудит
для этого объекта политики, регистрируется
событие ID 637.
Пользователи Добавляйте учетные записи пользователей в Не создается.
DHCP эту группу по мере необходимости. Если
учетная запись добавлена в эту группу, но не
добавлена в данный объект политики, она
автоматически удаляется, и в журнале
безопасности, если вы активировали аудит
для этого объекта политики, регистрируется
событие ID 637.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
компьютеров, выполняющих роль DHCP-сервера, можно найти в следующих
источниках на сайте Microsoft.com:
 Dhcploc Overview.
 Dynamic Host Configuration Protocol (DHCP) NAP Components (Компоненты
NAP протокола динамической настройки хостов).
 Netsh commands for DHCP.
 Network Access Protection.
 The DHCPv6 Protocol.
 Server Core.
 Services and Service Accounts Security Planning Guide (Руководство по
планированию безопасности служб и учетных записей служб).
 Step-by-Step Guide: Demonstrate DHCP NAP.

Глава 5: Повышение уровня защиты DNS-служб


Служба доменных имен (Domain Name System, DNS) – это система для
присваивания имен компьютерам и сетевым службам, организованным в иерархию
доменов. Чтобы упростить работу с сетевыми ресурсами, такие системы имен как
DNS являются средством связывания понятного для пользователей имени
компьютера или службы с другими данными, ассоциированными с этим именем,
такими как IP-адрес. При использовании в приложении понятного для пользователя
DNS-имени, DNS-службы выполняют его сопоставление с числовым адресом.
DNS является обязательной службой в доменах, использующих Windows
Server® 2008, потому что контроллеры домена и клиентские компьютеры в домене
Active Directory® используют DNS-службу и другие службы, предоставляемые через
Active Directory.
Служба DNS-сервера и служба DNS-клиента в Windows Server 2008 включают
следующие связанные с обеспечением безопасности новые возможности, которых
не было в предыдущих версиях Windows Server®:
 Фоновая загрузка зон. DNS-серверы, размещающие большие DNS-зоны,
которые они хранят, используя доменные службы Active Directory (AD DS),
теперь могут быстрее отвечать на запросы клиентских компьютеров после
перезапуска, потому что данные зоны загружаются в фоновом режиме.
Используя загрузку зон в фоновом режиме, DNS-сервер может отвечать на
запросы практически сразу же после перезагрузки и не ожидать, когда зоны
полностью загрузятся. DNS-сервер может отвечать на запросы к узлам,
которые уже загрузились или которые он может извлечь из AD DS. Фоновая
загрузка зон помогает обойти потенциальные атаки типа Отказ в
обслуживании (DoS), реализуемые путем простой перезагрузки DNS-
серверов с большими зонами.
 Поддержка контроллеров домена только для чтения (RODCs). Роль
DNS-сервер в Windows Server 2008 позволяет использовать основные
доступные только для чтения зоны на контроллерах RODC. Это делает
возможным копирование DNS-зон на контроллеры RODC, размещенные в
сетевых периметрах, филиалах или других небезопасных окружениях.
Данная глава обеспечивает нормативное руководство по повышению уровня
защиты роли DNS-сервера. Роль DNS-сервер не имеет подсистем служб роли.

Поверхность атаки
Роль DNS-сервер во многом подвержена тем же атакам на систему безопасности,
что и любой компьютер-сервер, предоставляющий службы DNS. Чтобы обозначить
всю поверхность атаки для этой роли, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть роли DNS-
сервера.
 Выполняющиеся службы. Это службы, выполняющиеся как часть роли
DNS-сервера.
Примечание Для проверки целостности установленных файлов и файлов, выполняемых
службой, можно воспользоваться утилитами RootkitRevealer и Sigcheck, являющимися
частью пакета служебных программ Windows Sysinternals
 Правила брандмауэра. Это используемые ролью DNS-сервера правила
брандмауэра.
 Зависимости роли. Это зависимости роли DNS-сервера.
Подробная информация о поверхности атаки для роли DNS-сервера включена в
книгу «Справочник по поверхности атаки в Windows Server 2008», прилагаемой к
данному руководству. Оценить поверхность атаки для данной роли сервера можно
при помощи вкладки DNS книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию роли DNS-сервера для защиты сервера от
злоумышленных атак. Приведенные ниже рекомендации предполагают, что на
странице Выбор служб роли Мастера добавления ролей выбрана только опция
DNS-сервер. Рекомендации для других служб роли не включены.

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих роль DNS-
сервера. При возникновении каких-либо трудностей по выполнению этих задач
обращайтесь к следующим разделам данной главы за дополнительной
информацией и рекомендациями.
Таблица 5.1. Контрольный список настройки
Задачи настройки
Развернуть установку Server Core Windows Server 2008.
Защитить DNS-зоны в небезопасных окружениях путем использования
контроллеров домена только для чтения (RODCs).
Установить роли DNS-сервер и AD DS-сервер на одном сервере.
Настроить зоны на использование безопасных динамических обновлений.
Разрешить передачу зон фиксированной группе DNS-серверов.
Развернуть разные серверы для внутреннего и внешнего распознавания DNS.
Настроить брандмауэр для защиты внутреннего пространства имен DNS.
Активировать рекурсию только для соответствующих DNS-серверов.
Настроить DNS таким образом, чтобы игнорировались записи ресурсов, которые
не являются доверенными.
Настроить корневые ссылки для внутреннего пространства имен DNS.

Развернуть установку Server Core Windows Server 2008


Развертывание Windows Server 2008 с использованием опции установки Server
Core обеспечивает сокращение поверхности атаки для операционной системы за
счет ограничения числа необходимых файлов и служб. Преимущество опции Server
Core в том, что в случае ее применения не устанавливаются файлы и службы для
графического пользовательского интерфейса (GUI).
Если для развертывания операционной системы Windows Server 2008 используется
опция установки Server Core, управлять сервером можно только локально с
помощью инструментов командной строки. Чтобы управлять сервером через
инструменты графического пользовательского интерфейса, необходимо установить
и запустить их на другом компьютере, на котором установлен GUI на базе Windows.
Для управления ролью DNS-сервер используются следующие инструменты
командной строки:
 Чтобы установить роль DNS-сервер, выполните следующую команду:
start /w ocsetup DNS-Server-Core-Role
 Чтобы конфигурировать службу DNS-сервер, выполните следующую
команду:
sc config dnsserver start = auto
Примечание Пробел между "start" и "=" обязателен. Также необходим пробел между
"=" и "auto".
 Чтобы запустить службу DNS-сервер, выполните следующую команду:
net start dnsserver
 Чтобы конфигурировать DNS-зоны, выполните следующую команду:
dnscmd
 Чтобы удалить роль DNS-сервер, выполните следующую команду:
start /w ocsetup DNS-Server-Core-Role /uninstall
Дополнительную информацию по установке и управлению ролью DNS-сервер с
использованием опции установки Server Core можно найти в материале Server Core
Installation Option of Windows Server 2008 Step-By-Step Guide. И подробнее об
управлении DNS-зонами с помощью команды dnscmd рассказывает статья Dnscmd
Overview (Обзор Dnscmd) в разделе Microsoft Windows Server сайта TechCenter.

Защитить DNS-зоны в небезопасных окружениях путем


использования контроллеров домена только для чтения (RODCs)
По причине их большой важности Microsoft рекомендует обеспечивать физическую
безопасность DNS-серверов в среде и размещать их там, где доступ к ним будет
иметь только квалифицированный административный персонал. В ситуациях, когда
вашей организации приходится предоставлять DNS-службы в незащищенных
окружениях, например филиалах, защищайте DNS-зоны, используя копии
интегрированных в Active Directory зон на контроллерах RODC.
На контроллерах RODC располагается доступная только для чтения копия
разделов каталога приложения, используемого DNS для хранения
интегрированных в Active Directory зон, включая раздел домена, ForestDNSZones и
DomainDNSZones. Это гарантирует, что выполняющийся на контроллере RODC
DNS-сервер располагает доступной только для чтения копией всех DNS-зон,
хранящихся на центральном контроллере домена в этих разделах каталога.
Администратор RODC может лишь просматривать содержимое доступной только
для чтения копии зоны. Однако администратор может менять содержимое зоны на
контроллере домена, для которого разрешен доступ для записи.
AD DS посредством DNS предоставляет сетевым клиентам сервис преобразования
имен. Изменения службы роли DNS-сервера необходимы для поддержки RODC
доменными службами AD DS.
Примечание Любой компьютер, находящийся в физически незащищенном месте,
представляет угрозу для безопасности организации.
Установить роли DNS-сервер и AD DS-сервер на одном сервере
Microsoft рекомендует разворачивать роль DNS-сервер на тот же сервер, который
выполняет роль AD DS в вашей среде. Сочетание этих ролей на одном сервере
позволяет обезопасить динамические обновления записей DNS.
Однако Microsoft рекомендует избегать комбинирования роли DNS-сервер с
остальными ролями сервера. Это поможет максимально сократить поверхность
атаки на сервере. Очень важно максимально сократить поверхность атаки для
ролей DNS и AD DS, выполняющихся на одном сервере, потому что
функциональность всего леса или домена зависит от выполняемых этим сервером
служб.
В небольших организациях администраторы вынуждены комбинировать роли
сервера по финансовым соображениям. Если такая необходимость возникает в
вашей организации, RODC и DNS можно сочетать с другими ролями сервера.
Только контроллеры RODC обеспечивают возможность делегирования прав
локального администрирования компьютера без делегирования прав
администрирования AD DS.
Но если необходима возможность управления DNS-зонами на контроллере домена,
Microsoft рекомендует сочетать роль DNS-сервер только с контроллерами домена,
доступными для записи, потому что на RODC вы не можете создаватьи
редактировать интегрированные в Active Directory зоны.

Настроить зоны на использование безопасных динамических


обновлений
Часто домены Windows включают сотни или тысячи подлежащих регистрации DNS-
клиентов, в том числе серверы, контроллеры доменов и рабочие станции. На
обслуживание этих ресурсов вручную может уходить слишком много времени,
поэтому DNS поддерживает динамические обновления. Динамические обновления
гарантируют ответственность DNS-клиента за обновление его регистрационной
информации, а это также сокращает затраты на администрирование.
Однако динамические обновления могут использоваться для реализации атак на
DNS-сервер. Введение в сеть подставных DNS-клиентов может привести к
заполнению базы данных DNS ложными записями. Безопасные динамические
обновления снижают риск этого, поскольку требуют, чтобы все DNS-клиенты были
участниками домена Windows Server 2008. Безопасные динамические обновления
требуют от сервера использовать Active Directory совместно с DNS. Поэтому
преимуществом данной меры по обеспечению безопасности воспользоваться
нельзя, если DNS-служба установлена на изолированном компьютере.

Разрешить передачу зон фиксированной группе DNS-серверов


Можно определять серверы, которые будут передавать зоны. По умолчанию любой
DNS-сервер может передавать информацию зоны на любой другой DNS-сервер.
Однако изменяя свойства DNS-сервера, можно сохранить возможность
запрашивать передачу зоны только некоторым серверам.
Интегрированные в Active Directory зоны тиражируют зоны, используя репликацию
Active Directory, что обеспечивает большую защищенность зон. Также Active
Directory автоматически копируется во все остальные контроллеры домена.
Поэтому для интегрированных в Active Directory зон нельзя ограничить передачу
зон.
Но в тех случаях, когда информация зоны должна проходить по общедоступной
сети, или когда вы не можете использовать контроллеры домена AD DS,
ограничивать передачи зон необходимо другим способом. Один из вариантов –
использовать для связи с DNS-сервером IPsec, что позволит защитить
информацию зоны при передаче по сети.

Развернуть разные серверы для внутреннего и внешнего


распознавания DNS
Microsoft рекомендует размещать внутреннее пространство имен DNS на DNS-
серверах, находящихся за брандмауэром вашей сети. Внешний DNS
обеспечивается за счет использования DNS-сервера в сетевом периметре (также
известном как DMZ, демилитаризованная зона или промежуточная подсеть).
Чтобы обеспечить разрешение Internet-имен для внутренних хостов, можно
конфигурировать внутренние DNS-серверы на использование сервера пересылки
для пересылки внешних запросов на внешние DNS-серверы. Сервер пересылки –
это DNS-сервер в сети, который перенаправляет DNS-запросы для внешних DNS-
имен на DNS-серверы, находящиеся вне этой сети. Также можно использовать
серверы пересылки по условию и пересылать запросы соответственно
определенным именам доменов. Больше информации о серверах пересылки
можно найти в статье Using forwarders (Использование серверов пересылки) на
сайте Microsoft TechNet.
Примечание Во многих средах не требуется, чтобы внутренние компьютеры разрешали
Internet-имена. Если перед такими компьютерами возникает данная необходимость, это
может выполнить для них прокси-сервер. Больше информации по этой теме можно найти в
статье Configuring DNS Servers for ISA Server 2004 (Настройка DNS-серверов для ISA-
сервера 2004).
Microsoft рекомендует настраивать DNS-серверы так, чтобы они самостоятельно
выполняли запросы распознавания имен, а не перенаправляли их на ненадежные
DNS-серверы. Однако в некоторых случаях, таких как распознавание пространств
доменных имен для Интернет-хостов, это может быть невозможным. Для DNS-
серверов вашей сети, открытых для доступа из Интернета, ограничьте передачи
DNS-зон либо DNS-серверами, идентифицированными в зоне записями ресурса
сервер имен (name server, NS), или определенными DNS-серверами своей сети.

Настроить брандмауэр для защиты внутреннего пространства


имен DNS
Чтобы предотвратить возможность получения информации о внутреннем
пространстве имен DNS кем бы то ни было вне вашей организации, настройте свои
маршрутизаторы и брандмауэры на обеспечение только исходящего DNS-трафика
между вашими внутренними DNS-серверами и внешними DNS-серверами,
находящимися во внешней сети или Интернет. Такая конфигурация обеспечит
возможность вашим внутренним DNS-серверам пересылать DNS-запросы во
внешнюю сеть, но предотвратит передачу внешних запросов на ваши внутренние
DNS-серверы. В случае использования сервера Microsoft Internet Security and
Acceleration (ISA) определять допустимый трафик через ISA-серверы можно с
помощью фильтров блокировки.
Если в прокси-сервере имеется две сетевых интерфейсных платы (network interface
cards, NICs) – одна для внутренней сети, и одна для Интернета – и прокси-сервер
также выполняет роль DNS-сервера, можно настроить сервер так, чтобы он слушал
только DNS-трафик на IP-адрес, используемый NIC внутренней сети.

Активировать рекурсию только для соответствующих DNS-


серверов
Рекурсия должна быть включена только на серверах, которые отвечают DNS-
клиентам напрямую. Для обмена информацией DNS-серверы используют
итерационные запросы. Microsoft рекомендует отключать в своей среде рекурсию
на DNS-серверах, которые не общаются с DNS-клиентами напрямую и не
конфигурированы на использование серверов пересылки.
В качестве альтернативы можно развертывать следующие типы DNS-серверов:
 Серверы, размещающие на себе определенный набор имен, которые
обслуживаются другими серверами имен.
 Серверы, разрешающие имена путем поиска полномочного сервера.
Чтобы включить или выключить рекурсию, на вкладке Дополнительные
параметры (Advanced) страницы Свойства (Properties) для DNS-сервера уберите
или установите флажок Отключить рекурсию (Disable recursion). Больше
информации по этой теме можно найти в статье «Configure a DNS server to use
forwarders» (Настройка DNS-сервера на использование серверов пересылки)
раздела Справка и поддержка для Windows Server 2008.

Настроить DNS таким образом, чтобы игнорировались записи


ресурсов, которые не являются доверенными
DNS-серверы должны игнорировать записи ресурсов от серверов, не являющихся
полномочными серверами для этих записей. Информацию таких записей
неполномочных ресурсов называют загрязнением имен (name pollution). Если на
вкладке Дополнительные параметры диалогового окна свойств DNS-сервера
установлен флажок Включить безопасный кэш (Secure cache against pollution),
что является настройкой по умолчанию, это защитит ваш DNS от загрязнения имен.
Также убедитесь, что для всех DNS-серверов вашей среды установлен флажок
Включить безопасный кэш.

Настроить корневые ссылки для внутреннего пространства имен


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

Соответствующие параметры групповой политики


Хотя существуют параметры групповой политики для службы DNS-клиента,
параметров групповой политики для службы DNS-сервера нет.
Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
компьютеров, выполняющих роль DNS-сервера, можно найти в следующих
источниках на сайте Microsoft.com:
 Configuring DNS Servers for ISA Server 2004.
 Dnscmd Overview.
 New features for DNS (Новые возможности DNS).
 Server Core.
 Using DNS Security Extensions (DNSSEC) (Использование безопасных
расширений DNS).
 Using forwarders.

Глава 6: Повышение уровня защиты Веб-служб


Данная глава посвящена повышению уровня защиты Веб-серверов с
установленной ОС Windows Server® 2008. По умолчанию роль Веб-сервер
устанавливает на компьютер с Windows Server® 2008 Microsoft® Internet Information
Services (IIS) 7.0
Структура IIS 7.0 была переработана и разбита на 40 модульных компонентов,
каждый из которых устанавливается по необходимости. Чем меньше компонентов
устанавливается, тем меньше поверхность атак.
По умолчанию Программа установки IIS 7.0 устанавливает на Веб-сервер
минимальную функциональность, обеспечивающую поддержку статических Веб-
страниц, фильтрацию запросов, сжатие статических файлов и графический
пользовательский интерфейс IIS Manager. Существует множество сценариев IIS
7.0, которые организации могут использовать для обеспечения Веб-сервисов, но
ключевыми при планировании структуры Веб-сервера являются следующие два
аспекта:
 Чувствительность данных, которые будет представлять сервер. Зная это,
можно оценить, какую опасность представляет утечка этих данных, и какие
усилия должна предпринять ваша организация для их защиты.
 Необходимый уровень взаимодействия пользователя с системой: от этого
зависят требования, предъявляемые к функциональности самого Веб-узла,
и то, какие компоненты необходимо установить для его защиты.
В данной главе рассматривается типовой сценарий размещения в интрасети
предприятия Веб-сервера с особо важной информацией и данными. Доступ
пользователей к серверу или приложениям на сервере ограничен и
предоставляется, исходя из необходимости, обусловленной занимаемой ими
должностью. Веб-сервер такого типа нуждается в специальных механизмах
аутентификации и авторизации, применяемых для пользователей и групп Active
Directory®. Эти группы могут использоваться для формирования сертификатов для
идентификации пользователей после предоставления им права доступа к
информации на сервере.
В данной главе обсуждается применение лучших практик для этого сценарии
направленных на повышение уровня защиты Веб-сервера от злонамеренных атак,
как от анонимных, так и от зарегистрированных пользователей. При использовании
стандартных модулей, устанавливаемых с IIS 7.0, Веб-сервер будет предоставлять
только статические HTML-страницы и изображения. В книге «Справочник по
поверхности атаки для Windows Server 2008», прилагаемой к данному руководству,
перечислены файлы и службы, которые устанавливаются с каждым компонентом.
Как и в предыдущих версиях IIS, при выполнении стандартной установки IIS 7.0 на
компьютер с Windows Server 2008 устанавливается и запускается служба Worldwide
Web Publishing (W3SVC).
Кроме того, программа установки IIS 7.0 устанавливает и запускает службу
активации Windows (Windows Process Activation Service, WAS). WAS обобщает
модель процесса IIS, делая IIS 7.0 HTTP-независимым. Благодаря этому сервер IIS
может размещать службы Windows Communication Foundation (WCF), используя
отличные от HTTP протоколы. Он также включает настройку прикладных
программных интерфейсов (application programming interfaces, APIs), с помощью
которых можно конфигурировать настройки WAS программно. Служба W3SVC
зависит от службы WAS.
Наконец, стандартная установка IIS 7.0 также включает Application Host Helper
Service (AppHostSvc). Эта служба обеспечивает механизм хранения истории
изменений настроек, который позволяет возвращаться к более ранней версии
конфигурации Веб-сервера. Служба Application Host Helper Service сохраняет файл
ApplicationHost.config в разные подкаталоги историю изменений настроек с
заданной периодичностью. Предыдущие параметры конфигурации для данной
службы по умолчанию сохранялись в подкаталог
\inetpub\history\CFGHISTORY_xxxxxxxxxx, где каждый x представляет число,
увеличивающееся на единицу для каждой последующей версии конфигурации.
Если скопировать конфигурационный файл IIS в каталог
%windir%\system32\inetsrv\config, IIS возвратиться к состоянию, описанному в
восстановленном файле.

Безопасность по умолчанию
На концептуальном уровне подходы к обеспечению безопасности для роли Веб-
сервера при использовании IIS 7.0 на компьютере с Windows Server 2008
существенным образом не отличаются от применяемых на сервере IIS 6.0 под
управлением Windows Server® 2003. По-прежнему важно максимально сократить
поверхность атак.
Однако на уровне реализации для версий IIS 6.0 и IIS 7.0 многое изменилось.
Основное изменение в том, что вместо того, чтобы устанавливать множество
компонентов и затем активировать или деактивировать их, как это было с IIS 6.0,
IIS 7.0 по умолчанию использует минимальную установку. Устанавливаются только
компоненты, работающие со статическими сайтами. В стандартную установку IIS
7.0 входят следующие функциональные модули:
 Модуль Статическое содержимое
 Модуль Стандартный документ
 Модуль Обзор каталогов
 Модуль Ошибки HTTP
 Модуль Ведение журнала HTTP
 Модуль Монитор запросов
 Модуль Фильтрация запросов
 Модуль Сжатие статического содержимого
 Модуль Консоль управления IIS
Стандартная установка IIS 7.0 не поддерживает функциональность ASP.NET или
ASP. Чтобы включить эти технологии в Веб-сервер IIS 7.0, их необходимо явно
указать при выборе ролей. На следующем рисунке представлены службы ролей,
составляющие роль Веб-сервера (IIS) Windows Server 2008.
Примечание На рисунке полужирным шрифтом выделены компоненты, которые
устанавливаются по умолчанию при выборе роли Веб-сервера.
Стандартный документ
Обзор каталогов
Основные Ошибки HTTP
возможности HTTP Перенаправление HTTP
Статическое содержимое

ASP
ASP.NET
CGI
Разработка Расширения ISAPI
приложений Фильтры ISAPI
Расширяемость .NET
Включения на стороне сервера (SSI)

Особое протоколирование
Ведение журнала HTTP
Работоспособность и Средства ведения журналов
диагностика
Ведение журнала ODBC
Слежение
Монитор запросов
Роль Веб-сервера
Обычная проверка подлинности
Проверка подлинности с сопоставлением сертификата клиента
Дайджест-проверка подлинности
Ограничения IP-адресов и доменов
Безопасность
Проверка подлинности путем сопоставления сертификата клиента IIS
Фильтрация запросов
Проверка подлинности Url
Проверка подлиности Windows

Сжатие динамического содержимого


Быстродействие Сжатие статического содержимого

Консоль управления IIS


Сценарии и средства управления IIS
Служба управления Консоль управления IIS 6.0
Средства управления
Совместимость управления IIS 6.0 Совместимость метабазы IIS 6.0
Службы сценариев IIS 6.0
Совместимость WMI IIS 6.0
FTP-сервер
Служба FTP-публикации Консоль управления FTP
Рис. 6.1. Иерархия служб роли для роли Веб-сервера

Поверхность атаки
IIS 7.0 характеризуется модульной архитектурой и минимальным количеством
зависимостей между модулями или компонентами. При настройке конкретного Веб-
сервера соответственно нуждам приложений предоставляется возможность
выбирать из 40 модулей.
Стандартная установка IIS 7.0 поддерживает только функции для обслуживания
статического содержимого, такого как файлы HTML и изображений. Это
максимально сокращает поверхность атаки, обеспечивая при этом
функциональность Веб-сервера.
Установка IIS 7.0 организована Microsoft в семь функциональных областей. К ним
относятся Основные возможности HTTP (Common HTTP Features), Разработка
приложений (Application Development), Работоспособность и диагностика (Health
and Diagnostics), Безопасность (Security), Быстродействие (Performance), Средства
управления (Management Tools) и Служба FTP-публикации (FTP Publishing Service).
То, какие модули и компоненты должны быть установлены, определяется тем, как
будет осуществляться управление Веб-сервером IIS 7.0, и требованиями сайтов и
приложений, которые планируется размещать на Веб-сервере IIS 7.0. Но чем
больше модулей и компонентов устанавливается, тем больше поверхность атаки
Веб-сервера.
Программа установки IIS 7.0 в зависимости от выбранных компонентов и модулей
устанавливает разные наборы файлов, служб и правил брандмауэра. Чтобы
обозначить поверхность атаки для этой службы роли, необходимо определить
следующее:
 Установленные файлы. Это файлы, установленные как часть роли Веб-
сервера.
 Установленные службы. Это службы, установленные как часть роли Веб-
сервера.
Примечание Для проверки целостности установленных файлов и файлов, выполняемых
службой, можно воспользоваться утилитами RootkitRevealer и Sigcheck, являющимися
частью пакета служебных программ Windows Sysinternals
 Правила брандмауэра. Это установленные (или активированные) для
роли Веб-сервера правила брандмауэра.
Подробная информация о поверхности атаки для роли Веб-сервера включена в
книгу «Справочник по поверхности атаки в Windows Server 2008», прилагаемой к
данному руководства. Оценить поверхность атаки для данной службы роли можно
при помощи вкладки Web книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию Веб-сервера (IIS) для защиты сервера от
злоумышленных атак. Приведенные ниже рекомендации предполагают, что на
странице Выбор служб роли Мастера добавления ролей выбрана только опция
Веб-сервер, приняты все настройки по умолчанию и включена опция ASP.NET.
Дальнейшие рекомендации по Основным возможностям HTTP, Разработке
приложений, Работоспособности и диагностике, Безопасности, Быстродействию,
Средствам управления и Службе FTP-публикации здесь не приводятся.
Дополнительную информацию по настройке этих служб можно найти в статье IIS
7.0: Configure Web Server Security (IIS 7.0: настройка безопасности Веб-сервера).
Существует множество вариантов настройки Веб-сервера, использующего IIS, но
данное руководство рассматривает основной сценарий, в котором используется
ASP.NET приложение, которое подключается к базе данных. Например, такой
базой данных могли бы быть внутренняя система заказов или приложение
управления персоналом.
Веб-узел такого типа обычно включает следующее:
 Статические страницы (HTML-страницы).
 Изображения в форматах .jpg и .gif.
 Динамические страницы ASP.NET.
В ходе планирования установки Веб-сервера убедитесь, что разработчики
приложений вашей организации придерживаются лучших практик безопасности.
Дополнительную информацию по лучшим практикам в этой области можно найти в
статье Improving Web Application Security: Threats and Countermeasures (Повышение
безопасности Веб-приложений: угрозы и контрмеры).
Важно понимать, что если ваша организация не использует лучшие практики
безопасности, ваш Веб-сервер станет легкой добычей для злонамеренных атак.
Даже если при разработке Веб-приложения применялись лучшие практики,
необходимо предпринять несколько шагов по обеспечению безопасности Веб-
сервера.

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих службу роли
Веб-сервер. При возникновении каких-либо трудностей по выполнению этих задач
обращайтесь к следующим разделам данной главы за дополнительной
информацией и рекомендациями.
Таблица 6.1. Контрольный список настройки
Задачи настройки
Рассмотреть возможность развертывания установки Server Core Windows Server
2008.
Установить среду выполнения приложений.
Настроить механизм аутентификации.
Удалить неиспользуемые компоненты IIS.
Настроить уникальную привязку.
Перенести корневые каталоги в отдельный раздел или диск.
Настроить разрешения учетной записи пользователя.
Задачи настройки
Активировать Secure Sockets Layer (SSL).
Рассмотреть дополнительные специализированные меры по настройке
безопасности.

Рассмотреть возможность развертывания установки Server Core


Windows Server 2008
Рассмотрите возможность развертывания Windows Server 2008 с использованием
опции установки Server Core, чтобы еще больше сократить поверхность атаки на
операционную систему за счет сокращения количества установленных файлов и
выполняющихся служб. Преимущество опции установки Server Core в том, что при
ее использовании не устанавливается графический пользовательский интерфейс
(GUI), т.е. не устанавливаются файлы и службы, необходимые обычному GUI.
При использовании установки Server Core Windows Server 2008 для роли Веб-
сервер (IIS) необходимо помнить две вещи. Первое, вы не можете управлять
установкой напрямую через GUI. Вместо этого должны удаленно использоваться
инструменты Консоли управления Microsoft (MMC) с компьютера, на который они
установлены, или инструменты командной строки для прямого управления
установкой сервера. Второе, Server Core не поддерживает связанные с ASP.NET и
.NET Framework возможности. Если вашим приложениям требуется
функциональность .NET, установку Server Core Windows Server 2008 использовать
нельзя.
Поскольку рассматриваемый в данной главе сценарий требует ASP.NET, вы не
сможете реализовать эти процедуры с помощью установки Server Core. Однако
установка Server Core позволит применить общие принципы, определенные для
любой роли Веб-сервера (IIS).
Для установки роли Веб-сервера на компьютер с Windows Server 2008 можно
использовать следующие инструменты командной строки:
 Чтобы установить стандартную роль Веб-сервера (IIS) и связанные с ней
службы, выполните следующую команду:
start /w pkgmgr /iu:IIS-WebServerRole;WAS-
WindowsActivationService;WAS-ProcessModel
 Чтобы установить все доступные службы и компоненты для роли Веб-
сервера (IIS), выполните следующую команду:
start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-
CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-
DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-
ApplicationDevelopment;IIS-ASP;IIS-CGI;IIS-
ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-
HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-
RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-
ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-
WindowsAuthentication;IIS-DigestAuthentication;IIS-
ClientCertificateMappingAuthentication;IIS-
IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-
RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-
HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-
WebServerManagementTools;IIS-ManagementScriptingTools;IIS-
IIS6ManagementCompatibility;IIS-Metabase;IIS-
WMICompatibility;IIS-LegacyScripts;IIS-
FTPPublishingService;IIS-FTPServer;WAS-
WindowsActivationService;WAS-ProcessModel
Больше информации о том, как устанавливать роль Веб-сервера (IIS) с
использованием установки Server Core Windows Server 2008, можно найти в статье
Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.
Кроме того, для управления ролью Веб-сервера можно использовать инструмент
командной строки appcmd. Инструкции по использованию appcmd приведены в
разделе Администрирование (Administrative Tools) «IIS 7.0: Operations Guide»
(Руководство по эксплуатации IIS 7.0) в Windows Server 2008 Technical Library
(Техническая библиотека Windows Server 2008).
Также для локального или удаленного управления ролью Веб-сервера (IIS),
выполняющейся на установках Server Core Windows Server 2008, можно
использовать WMI.
Больше информации о WMI можно найти в статье Windows Management
Instrumentation (Инструментарий управления Windows) и в разделе WMI «IIS 7.0
Operations Guide» в Windows Server 2008 Technical Library.

Установить среду выполнения приложений


В рассматриваемом в данной главе сценарии применяется ASP.NET, потому что
это самая популярная из предоставляемых IIS сред разработки. ASP.NET
использует .NET Framework 2.0, которая доступна в Windows Server 2008.
В разделе Выбор служб роли процесса установки Веб-сервера при выборе
ASP.NET обязательными являются следующие компоненты IIS 7.0:
 ASP.NET: Включает файлы и параметры конфигурации для активации
поддержки ASP.NET в IIS.
 Фильтры ISAPI: ASP.NET требует наличия фильтра с именем
«ASPNET_FILTER.DLL».
 Расширения ISAPI: Базовая функциональность ASP.NET находится в
файле ASPNET_ISAPI.DLL. Этот DLL-файл построен на базе интерфейса
ISAPI Extension (Расширения ISAPI). IIS не устанавливает интерфейс ISAPI
Extension по умолчанию.
 Расширяемость .NET: Расширяемость .NET позволяет вашему серверу
поддерживать управляемые модули, выполняющиеся с использованием
модели программирования ASP.NET. Ваши разработчики могут создавать
новые компоненты Веб-сервера, используя API .NET Framework.
 Служба активиции процессов Windows (WAS): Поддерживает активацию
управляемого кода в модели процесса IIS 7.0.
Если ваши приложения ASP.NET используют сервис ASP.NET Session state
для внепроцессного хранения сессий ASP.NET, этот компонент должен
быть активирован. Если данный компонент был активирован, но ваши
приложения ASP.NET им не пользуются, деактивируйте его.
Следующий шаг по обеспечению безопасности Веб-сервера после установки среды
разработки – установка механизма проверки подлинности, который будет
использоваться для идентификации пользователей, соединяющихся с
приложениями Веб-сервера.

Настроить механизм аутентификации


Microsoft рекомендует в качестве механизма аутентицикации пользователей для
Веб-приложений применять проверку подлинности Windows (Windows
Authentication), потому что она интегрирована с Windows и доменными службами
Active Directory (AD DS). Включая проверку подлинности Windows и отключая
анонимную проверку подлинности, вы обеспечиваете возможность доступа к Веб-
приложениям только аутентифицированным пользователям. Для установки,
активации и деактивации этих механизмов аутентификации можно использовать
следующие процедуры.
Чтобы установить Проверку подлинности Windows
1. Щелкните Пуск и затем щелкните Диспетчер сервера.
2. На панели Диспетчер сервера разверните Роли (Roles) и выберите Web
Server (IIS).
3. В окне Службы роли (Role Services) щелкните Добавить службы роли (Add
Role Services).
4. В мастере Добавление служб роли выберите Проверка подлинности
Windows и щелкните Далее.
5. На странице Подтвердите выбранные элементы (Confirm Installation
Selections) щелкните Установить (Install).
6. На странице Результаты установки (Installation Results) щелкните Закрыть
(Close).
Чтобы активировать Проверку подлинности Windows
1. На панели Диспетчер сервера щелкните Диспетчер служб IIS (Internet
Information Services (IIS) Manager).
2. В окне Подключения (Connections) щелкните имя сервера и затем в окне
Начальная страница (Home) щелкните двойным щелчком Проверка
подлинности (Authentication).
Рис. 6.2. Активация Проверки подлинности Windows в диспетчере IIS
3. На панели Проверка подлинности щелкните Проверка подлинности
Windows и затем на панели Действия (Actions) щелкните Включить (Enable).
Чтобы деактивировать Анонимную проверку подлинности
1. На панели Проверка подлинности диспетчера IIS щелкните Анонимная
проверка подлинности.
2. На панели Действия щелкните Отключить (Disable).
Важно Данная процедура отключает Анонимную проверку подлинности для всего Веб-
сервера IIS. Если имеются другие Веб-приложения, которым требуется анонимный доступ,
вероятно, следует снова включить эту возможность.
Также можно отключить анонимную проверку подлинности через командную строку.
Это может быть полезным при использовании сценария для настройки Веб-
сервера.
Для отключения анонимной проверки подлинности через командную строку в окне
командной строки используется следующий синтаксис:
%windir%\system32\inetsrv\appcmd set config -
section:anonymousAuthentication -enabled:false

Удалить неиспользуемые компоненты IIS


На этом этапе процесса настройки роли Веб-сервера необходимо проверить, какие
компоненты IIS 7.0 установлены на сервере, и убедиться в наличии всего
необходимого вашей установке. Все службы и компоненты роли, предоставляемые
IIS 7.0, устанавливаются явно. Единственная возможность службе, в которой нет
необходимости, быть установленной на вашем Веб-сервере – вы сами ее
установите. Вернитесь к разделу «Поверхность атаки» выше в данной главе, чтобы
выяснить, какие службы роли необходимы Веб-серверу, добавьте любую из тех,
которые нужны вашим приложениям, и удалите любую, в которой они не
нуждаются.
Как правило, рекомендуется проверять компоненты в таких областях:
 Стандартные основные модули HTTP, установленные программой
установки IIS 7.0.
 Неиспользуемые компоненты среды выполнения приложений.
 Компоненты управления.

Настроить уникальную привязку


По умолчанию Веб-узел IIS слушает соединения по всем конфигурированным IP-
адресам Веб-сервера. Сайт также обслуживает все запросы, использующие порт
80 независимо от заданного заголовка хоста. Вредоносные программы, вирусы или
черви, могут делать попытки перебирать подряд IP-адреса в определенном
диапазоне в поисках новых Веб-серверов для атаки. Сократить риск или количество
подобных атак, можно настроив Веб-узел на прослушивание только определенного
имени хоста. Это называется уникальной привязкой.
Например, если слушать не все имена хостов (*:80:*), а задать имя хоста
*:80:myWebServer, можно предотвратить автоматизированные атаки, в которых для
попытки доступа к серверу используется только IP-адрес. Обычно в ходе
автоматизированных атак последовательно перебираются адреса пространства
имен IP-адресов. Например, сначала делается попытка выполнить доступ по
адресу 1.1.1.1, потом 1.1.1.2, 1.1.1.3 и т.д.
Если не задать уникальную привязку, ваш Веб-узел, в конце концов, будет
атакован. Однако если настроить сервер так, чтобы для соединения требовалось
имя хоста, автоматизированные атаки станут невозможными, потому что запрос к
IP-адресу будет давать сбой, и червь, не имея более сложного кода для
разрешения имен хостов, не сможет определить имя хоста сервера. Для настройки
уникальной привязки можно использовать следующую процедуру.
Чтобы настроить уникальную привязку
1. Откройте Диспетчер служб IIS.
2. Выберите имя своего Веб-сервера и в ветке Узлы (Sites) щелкните правой
кнопкой мыши необходимый Веб-узел.
3. В контекстном меню выберите Изменить привязки (Edit Bindings).
4. В диалоговом окне Привязки сайта (Edit Site Binding) выберите в списке типов
http и щелкните Изменить (Edit).
5. Выберите для Веб-узела сервера необходимый IP-адрес и задайте
соответствующий необходимому имени хоста Заголовок хоста, как показано на
следующем рисунке.
Рис. 6.3. Диалоговое окно Изменить привязки сайта
Исходя из предыдущего рисунка, возможность доступа к сайту имеют только
приложения, запрашивающие полный URL для «http://contoso». Если
автоматизированный Интернет-червь выполняет доступ к сайту, используя IP-
адрес, например «http://10.10.10.20», соединение установлено не будет.
Также можно конфигурировать эту настройку из командной строки, используя
следующий синтаксис:
%windir%\system32\inetsrv\appcmd set site "Default Web Site" -
bindings:http/10.10.10.20:80:contoso

Перенести корневые каталоги в отдельный раздел или диск


Уязвимость системы безопасности в прошлом позволяла злоумышленнику
переходить из пространства имен URL в каталоги файловой системы ОС.
Например, если http://contoso/cgi.exe был спроецирован в C:\inetpub\wwwroot\cgi.exe
без необходимых мер защиты, для доступа к следующему адресу злоумышленник
мог использовать этот URL для выполнения обработчика команд Windows cmd.exe,
а не CGI-программы cgi.exe:
http://contoso/../../windows/system32/cmd.exe.
IIS 7.0 спроектированы так, что предотвращают атаки такого типа по умолчанию.
Однако лучшей практикой является перенести содержимого вашего Веб-узла из
раздела, используемого операционной системой, в отдельный раздел или диск. Это
не обязательно, но многие организации предпочитают хранить содержимое Веб-
узла в выделенном разделе. Это может быть выгодным, как с точки зрения
производительности, так и безопасности. Далее описана процедура переноса
содержимого Веб-узла в новый раздел.
Чтобы перенести содержимое Веб-узла в новый раздел
1. Откройте Диспетчер служб IIS.
2. Щелкните имя своего Веб-сервера и в ветке Узлы щелкните правой кнопкой
мыши Default Web Site (Стандартный Веб-узел).
3. Выберите Управление Веб-узлом (Manage Web Site) и затем выберите
Дополнительные параметры (Advanced Settings).
4. Измените свойство Физический путь (Physical Path), задав в нем каталог
нового раздела данных.
Эти операции не обеспечивают перенос содержимого Веб-узла и не изменяют
права доступа к Веб-папке, поэтому для завершения переноса необходимо также
переместить эти ресурсы.
Изменить стандартный физический путь для Веб-узла, можно выполнив
следующую строку команд:
%windir%\system32\inetsrv\appcmd set vdir "Default Web Site/" -
physicalPath:D:\Web
Примечание Данная команда предполагает, что содержимое Веб-узла переносится в
каталог D:\Web.

Настроить разрешения учетной записи пользователя


Далее необходимо назначить разрешения для каталога содержимого Веб-узла и
выбрать учетные записи пользователей, которым будет разрешен доступ к Веб-
узлу. Для этого предоставьте доступ следующим объектам системы безопасности:
 Учетной записи, ассоциированной с рабочим процессом IIS, который
используется для стандартного Веб-узла.
По умолчанию это учетная запись NetworkService. Чтобы изменить данную
настройку, необходимо редактировать параметр Пул приложений. Если для
этого параметра задана особая учетная запись, вы должны предоставить
доступ ей, а не NetworkService.
Примечание Не задавайте учетные записи LocalSystem или LocalService, потому что
каждая их них обладает большими полномочиями, чем Microsoft рекомендует
предоставлять рабочим процессам IIS.
 Пользователям, которые обращаются к вашему Веб-узлу.
В большинстве случаев для папки можно сохранить стандартные разрешения
группы ИмяКомпьютера\Пользователи, которые разрешают участникам домена
доступ к папке содержимого. Если группе ИмяКомпьютера\Пользователи
предоставлены какие-либо особые полномочия, их необходимо удалить.
 Администраторам Веб-узла.
Чтобы настроить разрешения для Веб-узла, используйте стандартный механизм
предоставления разрешений файловой системы Windows через Windows Explorer.
В этом случае вы можете определять конкретные разрешения безопасности для
каждой сущности системы безопасности. Для этого используется следующая
процедура.
Чтобы задать разрешения для папки D:\Web
1. Откройте Windows Explorer, щелкните правой кнопкой мыши папку Веб-
содержимого (D:\Web в примере данной главы) и затем щелкните Свойства.
2. Щелкните вкладку Безопасность (Security), щелкните кнопку
Дополнительные параметры и выберите Изменить.
3. Уберите флажок Добавить разрешения, наследуемые от родительских
объектов (Include inheritable permission from this object's parent).
4. В диалоговом окне Безопасность Windows установите флажок Копировать
(Copy), чтобы копировать унаследованные разрешения для папки.
5. Установите флажок Заменить все наследуемые разрешения для всех
потомков наследуемыми разрешениями этого объекта (Replace all existing
inheritable permissions on all descendants with inheritable permissions from this
object).
6. Выберите все записи разрешений, кроме приведенных ниже, и щелкните
Удалить (Remove):
 SYSTEM
 Администраторы
 <Имякомпютера>\Пользователи, например,
WebServer1\Пользователи
7. Щелкните Добавить и затем в окне Введите имена выбираемых объектов
(Enter the object name to select) введите Сетевая служба (Network Service).
8. Щелкните Проверить имена (Check Names), чтобы разрешить имя
NETWORK SERVICE. Это идентификатор рабочего процесса IIS по
умолчанию.
9. Щелкните OK, затем подтвердите, что под Разрешить (Allow) в окне
Элемент разрешения (Permission Entry) выбран список разрешений,
представленные на следующем рисунке, и щелкните OK.
Рис. 6.4. Настройка списков управления доступом для учетной записи
сетевой службы
10. В диалоговом окне Дополнительные параметры безопасности (Advanced
Security Settings) щелкните Добавить и затем в окне Введите имена
выбираемых объектов введите <ИмяДомена>\Пользователи.
Для используемого в данном примере домена Contoso было бы введено
Contoso\Users.
11. Щелкните Проверить имена, чтобы разрешить имя Domain Users.
Примечание Это пользователи, которым вы разрешаете доступ к Веб-узлу. Для
узла, предъявляющего особые требования к безопасности, возможно, потребуется
дать разрешения выделенной группе пользователей, в которую будут входить
пользователи, специально введенные в группу по необходимости. Если это
возможно, предоставьте группе ИмяМашины\Пользователи разрешения на чтение и
выполнение.
12. Щелкните OK и убедитесь, что в диалоговом окне Элемент разрешения
для Веб (Permission Entry for Web) выбраны те же разрешения, что
отображены на следующем рисунке.
Рис. 6.5. Настройка списков управления доступом для пользователей
домена
13. Щелкните OK, когда потребуется выйти из окна Свойства.

Активировать Secure Sockets Layer (SSL)


Если передача информации между Веб-сервером и клиентскими компьютерами
проходит по ненадежным сетям, Microsoft рекомендует активировать Secure
Sockets Layer (SSL) для шифрования трафика, что поможет обезопасить его от
анализа сетевого трафика с целью выявления конфиденциальной информации и
спуфинга хостов.
SSL требует предъявления сертификата, подтверждающего подлинность серверов
и пользующегося доверием у браузеров клиентов. Если к Веб-серверу в рамках
предприятия возможен только закрытый доступ, этот сертификат может
выдаваться существующей инфраструктурой открытых ключей (public key
infrastructure, PKI) организации. Однако если Веб-сервер доступен из Интернета,
Microsoft рекомендует получать сертификат в общедоступном центре
сертификации. Также для целей тестирования шифровать трафик можно с
помощью самозаверенного сертификата.
IIS 7.0 поддерживает несколько методов установки сертификата SSL, включая:
 С использованием GUI Диспетчер служб IIS.
 С использованием GUI Диспетчер сертификатов.
 Подача заявок через Веб и автоматически.
 С использованием инструмента командной строки appcmd.
 Программно через Microsoft.Web.Administration с использованием сценариев
Инструментария управления Windows (WMI).
Подробнее об установке сертификата SSL рассказывается в статье How to Setup
SSL on IIS7 (Как настроить SSL в IIS7) на Веб-узле Microsoft Internet Information
Services (IIS).
Установка сертификата SSL повышает уровень защиты конфигурации Веб-сервера,
при этом гарантированно обеспечивая вам возможность управлять набором
функциональных возможностей сервера.

Рассмотреть дополнительные специализированные меры по


настройке безопасности
Для сред, требующих дополнительной безопасности, существует несколько
дополнительных мер повышения уровня защиты Веб-сервера. Однако важно
отметить, что эти шаги приводят к повышению издержек на управление и могут
создавать проблемы с совместимостью Веб-приложения. Прежде чем пытаться
реализовать эти рекомендации на рабочем сервере, очень важно тщательно
протестировать Веб-приложения в тестовом окружении.
Для повышения безопасности установки своего Веб-сервера можно рассмотреть
возможность применения следующих функций и компонентов:
 Повышение уровня защиты с помощью Списка управления доступом (ACL).
Можно еще более ограничить доступ к своему Веб-узлу, задавая в ACL для
своего каталога содержимого конкретных пользователей.
 Если для ограничения доступа к своему Веб-узлу вы хотите использовать
более удобный инструмент, можно обратиться к встроенной функции
Авторизация URL-адресов IIS7. Больше информации об этой функции
можно найти в статье Understanding IIS7 URL Authorization (Понимание
авторизации URL-адресов IIS7) на Веб-узле Microsoft IIS.
 Компонент Списки ограничений по IPv4 (IPv4 Restriction Lists), позволяющий
ограничивать IP-адреса браузеров клиентов, которым разрешено
соединяться с Веб-сервером.
 Компонент Фильтрация запросов, позволяющий управлять многими
компонентами HTTP, такими как команды HTTP, заголовки HTTP и размер
URL. Больше информации об этом компоненте можно найти в статье How to
Use Request Filtering (Как использовать фильтрацию запросов) на Веб-узле
Microsoft IIS.
 Сопоставление сертификатов клиентов, что позволяет применять строгую
аутентификацию за счет требования предоставления пользователями
клиентских сертификатов при запросе доступа к вашему узлу. Больше
информации по этой функции можно найти в статье How to Setup SSL on
IIS7 на Веб-узле Microsoft IIS.
Также изменять удостоверение узла, можно меняя удостоверение Пула
приложений на менее привилегированную локальную учетную запись.
Дополнительные ресурсы
Более подробные сведения из лучших практик по проектированию и обслуживанию
Веб-серверов можно найти в следующих источниках на сайте Microsoft.com:
 How to Setup SSL on IIS7.
 How to Use Request Filtering.
 Improving Web Application Security: Threats and Countermeasures.
 IIS 7.0: Configure Web Server Security.
 Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.
 Windows Management Instrumentation.
 Windows Server 2008 Technical Library.
 Understanding IIS7 URL Authorization.

Глава 7: Повышение уровня защиты файловых служб


Данная глава посвящена повышению уровня защиты компьютеров, выполняющих
роль Файловые службы, которая доступна в Windows Server® 2008. Обеспечение
безопасности компьютеров, выполняющих эту роль, является нелегкой задачей,
поскольку сохранение баланса между безопасностью и функциональностью
фундаментальных служб – тонкое искусство. Windows Server 2008 представляет
ряд новых компонентов и функций, которые помогут в управлении и повышении
защиты файловых служб в вашей среде.
Блок сообщений сервера (Server Message Block, SMB) – это протокол совместного
доступа к файлам, используемый компьютерам с ОС Windows® по умолчанию.
1
SMB – это расширение протокола Common Internet File System (CIFS) . Windows
Server 2008 включает SMB версии 2.0, что обеспечивает улучшенные рабочие
характеристики.
Большинство обсуждаемых в данной главе параметров политики можно настроить
и применить посредством объектов групповой политики. Объект групповой
политики, дополняющий базовую политику рядовых серверов (Member Server
Baseline Policy, MSBP), может быть соотнесен с подразделениями (OU), в которые
входят компьютеры с Windows Server 2008, выполняющие роль Файловые службы,
что обеспечит данной роли сервера необходимые параметры безопасности. В этой
главе обсуждаются только параметры групповой политики, отличающиеся от
параметров, определяемых для MSBP.
Роль Файловые службы также позволяет устанавливать службу роли
Распределенная файловая система (Distributed File System, DFS). DFS состоит из
следующих двух технологий. Они могут использоваться совместно или независимо
друг от друга для обеспечения отказоустойчивых и гибких служб общего доступа к
файлам и репликации в сети на базе Windows:
 Пространства имен DFS. Эта технология позволяет группировать общие
папки, находящиеся на разных серверах, в одно или несколько логически

1
Общая межсетевая файловая система (прим. переводчика).
структурированных пространств имен. Каждое пространство имен
представляется пользователям как единая общая папка с наборами
подпапок, однако лежащая в основе структура пространства имен может
состоять из множества общих папок, располагающихся на разных серверах
и множестве узлов. Поскольку базовая структура общих папок скрыта от
пользователей, одна папка в пространстве имен DFS может
соответствовать множеству общих папок с множества серверов. Такая
структура обеспечивает отказоустойчивость и возможность
автоматического соединения пользователей с локальными общими
папками, вместо того чтобы направлять их через глобальную сеть (wide
area network, WAN).
 Репликация DFS. Данная технология является механизмом репликации с
несколькими хозяевами, что обеспечивает возможность синхронизировать
папки на многих серверах по локальным или WAN-соединениям. Эта
1
служба использует протокол Remote Differential Compression (RDC) для
обновления только тех частей файлов, которые изменились с момента
последней репликации. Репликация DFS может использоваться в сочетании
с пространствами имен DFS или самостоятельно.
Кроме того, можно установить службу роли Диспетчер ресурсов файлового сервера
(FSRM), обеспечивающую набор инструментов, благодаря которым
администраторы получают возможность понимать, контролировать и управлять
количеством и типом хранящихся данных, используемых Файловыми службами. С
помощью FSRM вы можете устанавливать квоты для папок и томов, проводить
активный мониторинг файлов и формировать полные отчеты хранилища.
Служба роли Службы для NFS обеспечивает предприятиям, использующим
смешанную среду Windows и UNIX, альтернативное решение для общего доступа к
файлам. Благодаря Службам для NFS можно обмениваться файлами между
компьютерами с операционными системами Windows Server 2008 и UNIX по
протоколу NFS. Служба поиска Windows также позволяет выполнять быстрый поиск
файлов на сервере с клиентских компьютеров, совместимых с поиском Windows.
Следующие службы, предоставляемые файловым серверам Windows Server 2008
ролью Файловый сервер Windows Server® 2003, делают их совместимыми с
файловыми серверами с Windows Server 2003 и Windows® 2000:
 Служба репликации файлов (File Replication Service, FRS), которая
поддерживает синхронизацию папок с файловыми серверами,
использующими FRS, а не новую службу Репликация DFS. Чтобы сервер
мог синхронизировать папки с серверами, использующими FRS с
реализациями Распределенной файловой системы (DFS) Windows
Server 2003 или Windows 2000, установите FRS. Чтобы использовать самую
последнюю и наиболее эффективную технологию репликации, установите
Репликацию DFS.
 Служба индексирования, которая каталогизирует содержимое и свойства
файлов на локальных и удаленных компьютерах. Эта служба посредством
гибкого языка запросов также позволяет быстро находить файлы. Нельзя
устанавливать Службу индексирования и Службу репликации файлов на
один компьютер.

1
Удаленное разностное сжатие (прим. переводчика).
Также можно установить следующие необязательные подсистемы роли Файловые
службы:
 Система архивации данных Windows Server, которая помогает надежно
архивировать и восстанавливать операционную систему, приложения
Windows Server System™ и файлы и папки, хранящиеся на сервере. Эта
подсистема вводит новую технологию архивации и восстановления и
заменяет предыдущий компонент Архивации, доступный в более ранних
версиях Windows.
 Диспетчер хранилища для сетей SAN, который позволяет
обеспечивать подсистемы хранения Fibre Channel или iSCSI в сети
хранения данных (storage area network, SAN).
 Многопутевой ввод/вывод, который позволяет повышать доступность
данных за счет предоставления подсистемам хранения избыточных
соединений. Поддержка нескольких каналов ввода-вывода также может
обеспечить сбалансированную нагрузку трафика ввода-вывода, что
улучшит производительность системы и приложений.
Следующий рисунок иллюстрирует службы роли, составляющие роль Файловых
служб Windows Server 2008.
Файловый сервер

Пространства имен DFS


Распределенная
файловая система DFS Репликация DFS

Диспетчер ресурсов
файлового сервера

Служба роли Файловые службы

Службы для NFS

Служба поиска Windows

Служба репликации файлов


Файловые службы Windows Server
2003 Служба индексации

Рис. 7.1. Иерархия служб роли Файловые службы

Поверхность атаки
Роль Файловые службы обеспечивает технологии для управления хранением и
репликацией файлов, управления распределенными пространствами имен,
быстрого поиска файлов и упрощенного доступа клиентов к файлам. Чтобы
обозначить поверхность атаки для этой службы роли, необходимо определить
следующее:
 Установленные файлы. Это файлы, установленные как часть роли
Файлового сервера.
 Установленные службы. Это службы, установленные как часть роли
Файлового сервера.
Примечание Для проверки целостности установленных файлов и файлов, выполняемых
службой, можно воспользоваться утилитами RootkitRevealer и Sigcheck, являющимися
частью пакета служебных программ Windows Sysinternals
 Правила брандмауэра. Это используемые ролью Файлового сервера
правила брандмауэра.
Подробная информация о поверхности атаки для роли Файловые службы включена
в книгу «Справочник по поверхности атаки в Windows Server 2008», прилагаемой к
данному руководству. Оценить поверхность атаки для данной роли сервера можно
при помощи вкладки File (Файл) книги в разделах, соответствующих каждому из
пунктов предыдущего списка.

Меры по обеспечению безопасности


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

Контрольный список настройки


Этот раздел включает рекомендации по настройке и контрольный список
настройки, созданный на основании лучших практик по повышению уровня защиты
файловых серверов в вашей среде. Сюда не включены рекомендации для DFS,
FSRM, служб для NFS, поисковой службы Windows и служб роли Файловые службы
Windows Server 2003. Больше информации о настройке этих служб можно найти в
разделе File Services (Файловые службы) в Windows Server 2008 Technical Library.
Описанные изменения настроек помогают защитить файловые серверы от этих
угроз, тем не менее, Microsoft рекомендует использовать дополнительную защиту
от вирусов, чтобы гарантировать файловым серверам организации отслеживание
передаваемых через них файлов в режиме реального времени. Больше
информации о защите от вирусов в режиме реального времени для
Windows Server 2008 можно найти в статье Security and Protection (Безопасность и
защита) в Windows Server 2008 Technical Library.
В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих службу роли
Файловый сервер. В случае возникновения трудностей с выполнением каких-либо
пунктов контрольного списка дополнительное описание и рекомендации можно
найти в следующих разделах данной главы.
Таблица 7.1. Контрольный список настройки
Задачи настройки
Развернуть установку Server Core Windows Server 2008.
Использовать цифровую подпись.
Рассмотреть возможность удаления общих административных ресурсов.
Рассмотреть возможность использования шифрования дисков и файлов.

Развернуть установку Server Core Windows Server 2008


Развертывание Windows Server 2008 с использованием опции установки Server
Core еще больше сокращает поверхность атаки операционной системы за счет
сокращения количества установленных файлов и выполняющихся служб.
Преимущество опции установки Server Core в том, что при ее использовании не
устанавливается графический пользовательский интерфейс (GUI), т.е. не
устанавливаются файлы и службы, необходимые обычному GUI.
При использовании опции установки Server Core Windows Server 2008 для
развертывания операционной системы вы можете управлять сервером только
локально, используя инструменты командной строки. Чтобы управлять сервером
инструментами GUI, необходимо установить и запустить эти инструменты на
другом компьютере с GUI на базе Windows.
Служба сервера устанавливается и запускает по умолчанию при создании
установки Server Core Windows Server 2008, и эта служба поддерживает службу
роли Файловый сервер. Если на компьютер, выполняющий установку Server Core
Windows Server 2008 необходимо установить другие службы, связанные с ролью
Файловые службы, обратитесь к руководству Server Core Installation Option of
Windows Server 2008 Step-by-Step Guide.
Для управления службами роли Файловый сервер можно использовать следующие
инструменты командной строки:
 net share
 chkdsk
 chkntfs
 dfsutil
 diskpart
 fsutil
 vssadmin
Это неполный список. Перечень всех инструментов командной строки и
информацию о том, как их использовать, можно найти в разделе «Command
Reference» (Описание команд) Windows Server 2008 Technical Library.
Для удаленного управления службой роли Файловые службы на компьютерах с
установками Server Core Windows Server 2008 можно также использовать сценарии
WMI или службу WS-Management и службу Windows Remote Shell (Удаленная
оболочка Windows).
Более подробно о WMI рассказывает статья Windows Management Instrumentation.
Больше информации о службах WS-Management и Windows Remote Shell можно
найти в статье Windows Remote Management (Удаленное управление Windows).
Примечание Далее в данном разделе предполагается, что выполняется стандартная
установка Windows Server 2008. Если для своей роли Файлового сервера вы установили
Server Core Windows Server 2008, можете следовать данным шагам, используя оснастку
Консоль управления Microsoft (MMC) с удаленного компьютера.

Использовать цифровую подпись


Протокол SMB обеспечивает базу для совместного доступа Windows к файлам,
принтерам и многим другим сетевым операциям, таким как удаленное
администрирование Windows. Для предотвращения атак с перехватом, при
которых SMB-пакеты изменяются при передаче, протокол SMB поддерживает
установку цифровой подписи для SMB-пакетов. Можно настроить групповую
политику, задавая параметр Сервер сети Microsoft: использовать цифровую
подпись (всегда) (Microsoft network server: Digitally sign communications
(always)) в следующем разделе редактора объекта групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры
безопасности\Локальные политики\Параметры безопасности
Этот параметр политики определяет, должна ли согласовываться установка
цифровой подписи SMB-пакета, прежде чем будет разрешен дальнейший обмен
информацией с клиентом SMB. В Windows Server 2008 параметру Сервер сети
Microsoft: Использовать цифровую подпись (всегда) по умолчанию
присваивается значение Отключен (Disabled). Microsoft рекомендует активировать
этот параметр для файловых серверов, выполняющихся в средах EC и SSLF,
описанных в данном руководстве.
Больше информации о настройке безопасности можно найти в статье Microsoft
network server: Digitally sign communications (always).

Рассмотреть возможность удаления общих административных


ресурсов
Windows Server 2008 создает по умолчанию ряд общих папок, доступ к которым
имеют только пользователи с правами администратора на компьютере,
выполняющем службу роли Файлового сервера. В следующей таблице описаны эти
ресурсы для файлового сервера, на котором под службу роли Файлового сервера
отведен один жесткий диск.
Таблица 7.2. Административные общие папки файлового сервера
Ресурс Описание Путь
Admin$ Общая папка, используемая администратором для C:\Windows
удаленного администрирования компьютера.
БукваДиска$ Корневые разделы и тома являются общими, если к C:\
букве диска добавлен символ $.
Для каждого создаваемого вами дополнительного тома на сервере Windows
Server 2008 создает соответствующую общую папку корня тома, чтобы сделать его
доступным администраторам по сети.
Вообще Microsoft рекомендует не изменять эти специальные общие папки. Однако
если организация предъявляет особые требования к безопасности, согласно
которым эти стандартные общие папки должны быть удалены, и не дает
операционной системе автоматически создавать их, используя Редактор реестра,
вы можете выполнить следующую процедуру.
Внимание Неправильное использование Редактора реестра может привести к серьезным
проблемам, в результате чего, возможно, придется переустанавливать операционную
систему. Microsoft не гарантирует, что вы сможете решить проблемы, возникшие в
результате неверного использования Редактора реестра, поэтому вы можете использовать
Редактор реестра на свой страх и риск.
Чтобы удалить административные общие папки и предотвратить их
автоматическое создание в Windows
1. Щелкните Пуск, щелкните Выполнить (Run) и в окне Открыть (Open) введите
regedit и нажмите ENTER.
2. Если получено предупреждение User Access Control (Управление доступом на
уровне пользователя), щелкните Продолжить (Continue).
3. Найдите и щелкните следующий раздел реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanSer
ver\Parameters\AutoShareServer
Примечание Если этого раздел реестра нет в списке, добавьте его вручную.
AutoShareServer должен быть задан типа REG_DWORD. Если этому разделу задано
значение 0 (нуль), Windows Server 2008 не будет автоматически создавать
административные общие папки. Это не распространяется на общую папку IPC$ или
общие папки, создаваемые вами вручную.
4. В меню Редактировать щелкните Изменить (Modify) и затем в окне вода данных
Значение (Value) введите 0 и щелкните OK.
5. Выйдите из Редактора реестра.
6. Щелкните Пуск и затем щелкните Выполнить.
7. В окне Открыть введите cmd и щелкните OK.
8. В окне командной строки введите следующее, нажимая ENTER после каждой
строки:
net stop server
net start server
9. Введите exit и нажмите ENTER.
Примечание Если остановить создание административных общих папок с помощью
пользовательского интерфейса и не изменить реестр, после перезапуска службы Сервера
или после сброса настроек севера общие папки будут создаваться вновь.

Рассмотреть возможность использования шифрования дисков и


файлов
Для сред с повышенными требованиями к безопасности следует рассмотреть
возможность использования шифрования для защиты жестких дисков и данных на
компьютерах с Windows Server 2008, выполняющих службу роли Файловый сервер.
Для этого на таких компьютерах можно использовать один из двух вариантов:
 Шифрование дисков Microsoft BitLocker™.
 Шифрующую файловую систему (Encrypting File System, EFS).
BitLocker защищает данные на сервере, предотвращая возможность нарушения
защиты файлов и системы Windows на утерянных или похищенных компьютерах
неавторизованными пользователями. BitLocker шифрует тома целиком, включая
все пользовательские и системные файлы, и среди этих файлов также файлы
подкачки и данных спящего режима.
Больше информации об использовании BitLocker для защиты данных на
компьютере, выполняющем службу роли Файловый сервер, можно найти в статье
Windows BitLocker Drive Encryption (Шифрование дисков Windows BitLocker).
EFS позволяет шифровать файлы, хранящиеся в томах, использующих файловую
систему NTFS. EFS интегрирована с NTFS, ею легко управлять и сложно атаковать.
Дополнительные возможности EFS в Windows Vista® и Windows Server 2008
включают улучшения управляемости и поддержку хранения ключей шифрования на
смарт-картах.
Дополнительную информацию по использованию EFS для защиты данных на
компьютере, выполняющем службу роли Файловый сервер, можно найти в статье
Encrypting File System (Шифрующая файловая система).

Дополнительные ресурсы
Более подробные сведения из лучших практик по проектированию и обслуживанию
сервера с Windows Server 2008, осуществляющего роль Файлового сервера, можно
найти в следующих источниках на сайте Microsoft.com:
 Encrypting File System.
 Microsoft network (Сеть Microsoft).
 Security and Protection.
 Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.
 Windows BitLocker Drive Encryption.
 Windows Management Instrumentation.
 Windows Remote Management.
 Windows Server 2008 Technical Library.

Глава 8: Повышение уровня защиты служб печати


Данная глава посвящена повышению уровня защиты компьютеров, выполняющих
роль Сервера печати, которая доступна в Windows Server® 2008. В операционной
системе для Windows Vista® в службы печати Microsoft внесены существенные
изменения, связанные с безопасностью. Эти изменения также вошли в Windows
Server 2008. Более подробную информацию о новых возможностях, появившихся в
Windows Vista, можно найти в документе Point and Print Security in Windows Vista
(Безопасность функции указания и печати в Windows Vista).
Служба печати в Windows Server 2008 поддерживает клиентов предшествующих
версий, но организация сможет достичь оптимальной безопасности, только если на
все клиентские компьютеры будет установлена ОС Windows Vista.
На компьютере с Windows Server 2008 можно выбрать три службы роли,
составляющие роль Службы печати: Сервер печати, LPD (Line Printer Daemon) и
печать через Интернет.
 Служба роли Сервер печати. Установка этой службы роли не приводит к
большим изменениям на сервере. Основная служба печати – служба
Диспетчера печати (Spooler). Эта служба обеспечивает большую часть
функциональности, необходимой приложениям для управления печатью.
Кроме управления принтером, многие приложения также используют эту
службу в операциях печати и обработки страниц, таких как форматирование
страниц при их отображении на экране. Поэтому в Windows Server 2008
служба диспетчера очереди печати по умолчанию включена, независимо от
того, установлена ли роль Службы печати на сервере или нет. Однако эта
служба не включена по умолчанию для сетевого доступа, так что напрямую
ее можно использовать только из консоли сервера. Для серверов, не
предоставляющих доступа к своим принтерам по сети, это помогает
сократить поверхность атаки.
При добавлении роли Службы печати в стандартную установку Windows
Server 2008 и последующей установке и организации общего доступа к
принтерам, службы диспетчера печати становятся доступными для сетевых
соединений посредством удаленного вызова процедур (remote procedure
call, RPC). Когда эти службы становятся доступными по сети, поверхность
атаки Сервера печати увеличивается.
При установке роль Службы печати не зависит напрямую от роли Файловый
сервер, но когда на сервер добавляется общий принтер, такая зависимость
возникает. И службы печати, и файловые службы для доступа к общим
ресурсам, будь то принтеры или папки и файлы, используют одинаковые
механизмы RPC и NetBIOS по протоколу TCP/IP (NetBT). Когда вы впервые
откроете общий доступ к принтеру, вы заметите, что роль Файловый сервер
будет активирована автоматически, и вы сможете управлять ею в
Диспетчере сервера.
Правила брандмауэра для роли Службы печати определены заранее, но
выключены по умолчанию. Эти правила не активируются в процессе
установки данной службы роли. Их активация происходит в момент
установки и предоставления общего доступа к принтеру.
Более подробная информация приведена в разделе «Поверхность атаки»
данной главы.
 Служба LPD. Эта служба роли активирует печать, используя базированный
на TCP/IP протокол LPD. Для данной службы роли требуется, чтобы была
установлена роль Службы печати, что приводит к небольшому увеличению
поверхности атаки на сервер. Более подробная информация представлена
в разделе «Поверхность атаки» данной главы
 Служба роли Печать через Интернет. С помощью этой роли общие
принтеры можно делать доступными клиентским компьютерам путем
16
использования протокола Internet Printing Protocol (IPP) по HTTP-
соединению. Клиентские компьютеры, использующие Веб-браузер, могут
подключаться и работать с принтерами, опубликованными с помощью роли
Веб-сервера, доступной в Windows Server 2008. Печать через Интернет
также обеспечивает возможность соединений между пользователями и
принтерами, находящимися в разных доменах или сетях.
Служба роли Печать через Интернет зависит от роли Веб-сервер (IIS),
которую Windows Server 2008 устанавливает автоматически при выборе
службы роли Печать через Интернет. Установка включает ряд служб роли и
компонентов Веб-сервера:
 Разработка приложений
o ASP
o Расширяемость ISAPI
o Фильтры ISAPI
o Расширяемость .NET

16
Протокол печати через интернет (прим. переводчика).
 Безопасность
o Фильтрация запросов
o Обычная проверка подлинности
o Windows- проверка подлинности
 Основные возможности HTTP
 Работоспособность и диагностика
 Быстродействие
 Средства управления
Наряду с этими компонентами устанавливается и активируется Служба
процессов активации Windows (WAS), включающая прикладные
программные интерфейсы (API) для конфигурации и модель процессов для
среды .NET.
Поскольку служба роли Печать через Интернет так сильно зависит от роли
Веб-сервера, к упомянутым в этом разделе службам должна быть
добавлена поверхность атаки роли Веб-сервера. Больше информации о
поверхности атаки роли Веб-сервера можно найти в Главе 6, «Повышение
уровня защиты Веб-служб», данного руководства.
При добавлении службы роли Печать через Интернет в стандартную
установку Windows Server 2008 программа установки добавляет на сервер
IIS 7.0 ряд файлов Active Server Pages (ASP), что позволяет расширить
функциональность Веб-сервера и обеспечить поддержку IPP. Для службы
роли Печать через Интернет больше не требуется устанавливать никакие
дополнительные службы и открывать дополнительные сетевые порты,
потому что браузер клиентского компьютера для соединения с принтером
использует стандартные порты Веб-сервера (80 и 443).
После установки службы роли Печать через Интернет клиенты сервера
печати организации смогут печатать или управлять документами из своих
Веб-браузеров. Когда клиенты сервера печати пытаются подключиться к
Веб-странице принтеров, сервер создает .cab-файл, содержащий
соответствующие файлы драйверов принтера, и загружает этот .cab-файл
на клиентский компьютер. После установки драйверов принтер появляется
в папке Принтеры (Printers) на клиентском компьютере. Больше
информации можно найти в разделе «Поверхность атаки» данной главы.
На следующем рисунке проиллюстрированы службы роли, составляющие роль
Службы печати Windows Server 2008.
Сервер печати

Службы роли для Служба LPD


Службы печати

Печать через Интернет

Рис. 8.1. Иерархия служб роли Сервера печати

Поверхность атаки
Роль Службы печати позволяет организовать общий доступ к принтерам по сети, а
также обеспечивает централизацию управления сервером печати и сетевым
принтером. Чтобы обозначить поверхность атаки для этой службы роли,
необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть каждой
службы роли для роли Службы печати.
 Установленные службы. Это службы, установленные как часть каждой
службы роли для роли Службы печати.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows
Sysinternals.
 Правила брандмауэра. Это используемые ролью Службы печати
правила брандмауэра.
Подробная информация о поверхности атаки для роли Службы печати включена в
книгу «Справочник по поверхности атаки в Windows Server 2008», прилагаемой к
данному руководству. Оценить поверхность атаки для данной роли сервера можно
при помощи вкладки Print книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию роли Службы печати для защиты сервера от
злоумышленных атак. Приведенные ниже рекомендации предполагают, что на
странице Выбор служб роли Мастера добавления ролей выбрана только опция
Сервер печати. Рекомендации для других служб роли не включены.
Контрольный список настройки
Этот раздел включает рекомендации по настройке, основанные на лучших
практиках по повышению уровня защиты серверов печати в вашей среде. Сюда не
включены рекомендации для ролей Служба LPD и Печать через Интернет. Больше
информации о настройке этих ролей можно найти в статье Windows Server 2008:
Server Manager.
В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих роль Службы печати. В случае возникновения трудностей с
выполнением каких-либо пунктов контрольного списка дополнительное описание и
рекомендации можно найти в следующих разделах данной главы.
Таблица 8.1. Контрольный список настройки
Задачи настройки
Развернуть установку Server core Windows Server 2008.
Использовать цифровую подпись.
Рассмотреть возможность использования функции указания и печати.
Управлять общим доступом к принтеру.
Переместить стандартный файл очереди печати.

Развернуть установку Server core Windows Server 2008


Развертывание Windows Server 2008 с использованием опции установки Server
Core сокращает поверхность атаки операционной системы за счет сокращения
количества установленных файлов и выполняющихся служб. Преимущество опции
установки Server Core в том, что при ее использовании не устанавливается
графический пользовательский интерфейс (GUI), т.е. не устанавливаются файлы и
службы, необходимые обычному GUI.
При развертывании операционной системы с использованием опции установки
Server Core Windows Server 2008 управлять сервером можно только локально через
инструменты командной строки. Чтобы управлять сервером с помощью
инструментов GUI, необходимо установить и запустить их на другом компьютере с
GUI на базе Windows.
Для управления ролью Службы печати могут использоваться следующие
инструменты командной строки:
 Чтобы установить службу роли Сервер печати, выполните следующую
команду:
start /w ocsetup Printing-ServerCore-Role
 Чтобы установить службу роли LPD (Line Printer Daemon), выполните
следующую команду:
start /w ocsetup Printing-LPDPrintService
Примечание Поскольку служба роли Печать через Интернет зависит от
компонентов .NET Framework, не поддерживаемых установкой Server Core Windows
Server 2008, эта служба роли недоступна на компьютерах с установками Server
Core.
Больше информации о том, как устанавливать и управлять ролью Службы печати в
установке Server Core Windows Server 2008, можно найти в руководстве Server
Core Installation Option of Windows Server 2008 Step-By-Step Guide.
Также для управления сервером печати можно использовать следующие
инструменты:
 Lpg
 Lpr
 Net print
 Print
 Prncnfg.vbs
 Prndrvr.vbs
 Prnjobs.vbs
 Prnmngr.vbs
 Prnport.vbs
 Prnqctl.vbs
 Pubprn.vbs
О том, как использовать эти инструменты, рассказывает раздел «Command
Reference» документа Windows Server 2008 Technical Library.
Управлять удаленно службой роли Сервер печати на компьютерах с Server Core
Windows Server 2008 можно с помощью сценариев WMI или удаленной оболочки
Windows.
Больше информации и WMI можно найти в статье Windows Management
Instrumentation.
Больше информации о WS-Management и удаленной оболочке Windows
представлено в статье Windows Remote Management.
Примечание В данном разделе предполагается, что выполняется стандартная установка
Windows Server 2008. Если вы создали установку Server Core Windows Server 2008 для роли
Сервер печати, вы можете следовать данным шагам, используя оснастку консоль управления
Microsoft (MMC) с удаленного компьютера.

Использовать цифровую подпись


Протокол SMB обеспечивает базу для совместного доступа Windows к файлам и
принтерам и многих других сетевых операций, таким как удаленное
администрирование Windows. Для предотвращения атак с перехватом, когда
SMB-пакеты изменяются при передаче, протокол SMB поддерживает цифровую
подпись SMB-пакетов. Групповую политику можно настроить, задавая параметр
Сервер сети Microsoft: Использовать цифровую подпись (всегда) в
следующем разделе редактора объекта групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры
безопасности\Локальные политики\Параметры безопасности
Этот параметр политики определяет необходимость согласования цифровой
подписи SMB-пакета для обмена информацией с клиентом SMB.
Microsoft рекомендует активировать параметр Сервер сети Microsoft:
Использовать цифровую подпись (всегда) для серверов печати,
выполняющихся в средах EC и SSLF, описанных в данном руководстве.
Рассмотреть возможность использования функции указания и
печати
Функция указания и печати (Point and Print) – это функция Windows®, которая
обеспечивает автоматическое скачивание и установку драйвера принтера при
подключении пользователя к общему принтеру. Функция указания и печати также
обновляет драйвер принтера на клиентском компьютере при обновлении
конфигурации драйвера на сервере печати. В Windows Server 2008 и Windows Vista
параметр групповой политики Ограничения указания и печати (Point and Print
Restrictions) был обновлен для облегчения управления улучшенной
безопасностью компонента Указания и печати.
Настроить параметры групповой политики Указания и печати можно в следующем
разделе редактора объектов групповой политики:
Конфигурация пользователя\Административные шаблоны\Панель
управления\Принтеры
В следующей таблице представлены данные по параметрам безопасности,
характерные для этой технологии в Windows Server 2008.
Таблица 8.2. Параметры указания и печати
Объект Описание Стандартные
политики настройки Windows
Server 2008
Разрешить Если этот параметр включен или не Не конфигурирован
обзор сети для задан, пользователи могут использовать
поиска Мастер установки принтеров (Add Printer
принтеров Wizard) для вывода на экран списка
(Browse the общих принтеров, имеющихся в сети.
network to find Если этот параметр отключен, страница
printers) обзора сетевых принтеров не
отображается в Мастере установки
принтеров, и пользователи не могут,
используя Windows Explorer,
осуществлять поиск принтеров в сети.
Объект Описание Стандартные
политики настройки Windows
Server 2008
Использовать Если этот параметр включен, Не конфигурирован
только пользователи могут использовать
функцию функцию указания и печати только на
указания и принтерах, драйверы которых
печати для поддерживают пакеты. При
пакета (Only использовании функции указания и
use Package печати для пакета клиентские
Point and print) компьютеры проверяют подписи всех
драйверов, загруженных с серверов
печати.
Если этот параметр отключен или не
задан, пользователи смогут применять
функцию указания и печати не только для
пакетов.
Этот параметр применяется только в
Windows Server 2008 и Windows Vista.
Функция Если этот параметр включен, Не конфигурирован
указания и пользователи могут использовать
печати для функцию указания и печати для пакета
пакетов - только на серверах печати, разрешенных
Разрешенные сетевым администратором. При
серверы использовании функции указания и
(Package Point печати для пакета клиентские
and print - компьютеры проверяют подписи всех
Approved драйверов, загруженных с серверов
server) печати.
Если этот параметр отключен или не
задан, функция указания и печати для
пакетов может применяться не только для
конкретных серверов печати.
Этот параметр применяется только в
Windows Server 2008 и Windows Vista.
Объект Описание Стандартные
политики настройки Windows
Server 2008
Ограничения Если этот параметр политики включен, Не конфигурирован
указания и клиентские компьютеры могут
печати (Point использовать функцию указания и печати
and Print только на серверах, имена которых явно
Restrictions) перечислены в списке.
Если этот параметр политики отключен,
клиентские компьютеры могут
использовать функцию указания и печати
на любом сервере. Компьютеры с
Windows Vista не будут выводить на
экран предупреждение или запрос на
повышение прав, когда пользователи
применяют функцию указания и печати к
серверу, или когда драйвер
существующего подключения к принтеру
требует обновления.
Важно понимать, какие варианты доступны с этими параметрами групповой
политики, и как их можно использовать для максимального увеличения
безопасности установок принтеров клиентских компьютеров. Вариант,
предлагающий наибольшую безопасность, может не работать в среде с большим
количеством разнообразных принтеров и многофункциональных печатных
устройств, которым необходимы драйверы, не предоставляемые Windows
Server 2008. На следующем рисунке представлены возможные варианты и
обеспечиваемые ими преимущества и недостатки.
Рис. 8.2. Безопасные параметры печати
Самый безопасный вариант настройки – использовать групповую политику,
посредством которой разрешить установкам принтеров применять только
драйверы, поставляемые с Windows®. Эти драйверы подвергаются тщательному
тестированию и подписываются, что гарантирует невозможность их
фальсификации.
Однако этот вариант является ограничивающим, если в организации уже
установлены разнообразные печатные устройства. Скорее всего, для обеспечения
требований печати вам понадобятся драйверы разработанные производителями
принтеров. Для поддержки сред такого типа Microsoft были созданы пакеты
драйверов указания и печати. Такие драйверы от производителей принтеров
предлагают следующие преимущества:
 Все компоненты драйвера устанавливаются на клиент печати.
 Подпись и целостность драйвера проверяются на клиенте печати.
 Функция указания и печати более надежна и более управляема в
управляемой среде.
В Windows Vista установка пакета используется как предпочтительный метод
установки драйверов. Однако клиентские компьютеры с более ранними версиями
Windows не могут использовать эти драйверы, потому что для них требуется
локальное хранилище драйверов, которое появилось только в Windows Vista. Когда
к серверу печати Windows Server 2008 подключается клиентский компьютер с более
ранней версией Windows, сервер печати устанавливает принтер на клиентский
компьютер с помощью традиционной функции указания и печати.
Последний вариант для клиентский компьютеров с Windows Vista – повышение
привилегий, чтобы разрешить установку драйверов печати, не поддерживающих
функцию указания и печати для пакетов. В этом случае пользователь должен знать
имя пользователя и пароль локальной учетной записи, имеющей привилегии
администратора, или администратор должен установить драйверы принтера от
лица пользователя. Больше информации по данным вариантам и параметрам
можно найти в документе Point and Print Security in Windows Vista.

Управлять общим доступом к принтеру


В следующей таблице представлены разрешения по умолчанию, применяемые к
новому общему принтеру на входящем в домен сервере печати.
Таблица 8.3. Разрешения принтера по умолчанию
Группа или учетная Разрешения
запись
Все Печать
СОЗДАТЕЛЬ - Управление документами
ВЛАДЕЛЕЦ
Администратор Печать, управление принтерами, управление
документами
Для сред, в которых требуется повышенный уровень безопасности, добиться его
можно, удалив разрешения из группы Все и создав выделенную группу
пользователей для принтера. В этом случае возникают издержки на создание и
управление доступом к принтеру, но доступ к принтеру получают только те
пользователи, которые были добавлены в выделенную группу и получили, таким
образом, права доступа. Пользователям, не являющимся участниками группы,
доступ к принтеру запрещен.

Переместить стандартный файл очереди печати


Для сред с повышенными требованиями к безопасности или производительности
Microsoft рекомендует переместить файл очереди печати в выделенный том
очереди на сервере печати.
В результате следующей процедуры создается новый стандартный каталог
очереди для всех принтеров, настроенных на данном компьютере.
Чтобы создать новый стандартный каталог очереди
1. Щелкните Пуск и введите Принтеры.
2. Откройте окно управления Принтеры.
3. В меню Файл (File) щелкните Свойства сервера (Server Properties) и затем
щелкните вкладку Дополнительные параметры.
4. В поле Папка очереди печати (Spool Folder) введите путь к выделенному тому
и затем щелкните OK.
Примечание Для нагруженных серверов печати необходимо отслеживать метрики
производительности диска, чтобы не допустить перегрузку томов сервера очередью печати.

Дополнительные ресурсы
Более подробные сведения из лучших практик по проектированию и обслуживанию
сервера с Windows Server 2008, осуществляющего роль Сервера печати, можно
найти в следующих источниках на сайте Microsoft.com:
 Документ Point and Print Security in Windows Vista.
 Server Core Installation Option of Windows Server 2008 Step-By-Step Guide.
 Windows Management Instrumentation.
 Windows Remote Management.
 Windows Server 2008: Server Manager.
 Windows Server 2008 Technical Library.

Глава 9: Повышение уровня защиты служб сертификации


Active Directory
Службы сертификации Active Directory® (Active Directory® Certificate Services,
AD CS) в Windows Server® 2008 обеспечивают службы, которые могут быть
настроены для создания и управления сертификатами открытого ключа в
программных системах безопасности, использующих технологии открытого ключа,
включая версию 3 сертификатов X.509. Организации могут применять AD CS для
повышения безопасности путем связывания удостоверения пользователя,
устройства или службы с соответствующей парой ключей. AD CS также включает
функции, позволяющие управлять подачей заявок на получение и отзыв
сертификатов в различных масштабируемых средах.
Службы роли, доступные для роли AD CS, представлены на следующем рисунке.
Центр сертификации

Служба подачи заявок в центр


сертификации через Интернет
Роль Службы сертификации Active
Directory
Сетевой ответчик

Служба подачи заявок на


сетевые устройства

Рис. 9.1. Иерархия служб роли AD CS


С помощью данной главы вы сможете повысить уровень защиты серверов,
выполняющих роль AD CS. В ней представлено нормативное руководство по
повышению защиты всех служб, доступных для роли AD CS. Каждая служба роли
AD CS выполняет определенную функцию, поэтому сначала необходимо
определиться с тем, что вы хотите настроить на своем сервере, а затем
использовать рекомендации данной главы для повышения уровня защиты
отдельных служб роли.
Примечание Служба роли AD CS недоступна в установках Server Core Windows Server 2008
или Windows Server 2008 для компьютеров на базе процессоров Itanium.
Больше информации о службе роли AD CS представлено в статье Active Directory
Certificate Services (Службы сертификации Active Directory).

Служба роли Центр сертификации


Служба роли Центр сертификации позволяет устанавливать корневые и
подчиненные центры сертификации (ЦС) для выдачи сертификатов для
пользователей, компьютеров и служб, а также для управления сроком действия
сертификатов.
Чтобы установить эти ЦС, должны быть выполнены следующие требования:
 Минимальным требованием для установки корневого ЦС является членство
в локальной группе Администраторы или эквивалентной ей группе. При
установке ЦС предприятия минимальным требованием является членство в
группе Администраторы домена. Дополнительную информацию можно
найти в разделе «Реализация администрирования на основании ролей» в
службе Справка и поддержка Windows Server 2008.
 Минимальным требованием для выполнения процедуры установки
подчиненного ЦС является членство в локальной группе Администраторы
или эквивалентной ей группе. При установке ЦС предприятия минимальным
требованием является членство в группе Администраторы домена.
Дополнительную информацию можно найти в разделе «Реализация
администрирования на основании ролей» в службе Справка и поддержка
Windows Server 2008.
Поверхность атаки
Служба роли Центр сертификации подвержена тем же атакам на систему
безопасности, что и любой Центр сертификации. Чтобы обозначить поверхность
атаки этой роли, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли Центр сертификации.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
роли Центр сертификации.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals
 Правила брандмауэра. Это используемые службой роли Центр
сертификации правила брандмауэра.
 Зависимости роли. Это зависимости службы роли Центр сертификации.
Подробная информация о поверхности атаки для роли Центр сертификации
включена в книгу «Справочник по поверхности атаки в Windows Server 2008»,
прилагаемой к данному руководству. Оценить поверхность атаки для данной роли
сервера можно при помощи вкладки AD CS книги в разделах, соответствующих
каждому из пунктов предыдущего списка.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих службу роли
Центр сертификации. При возникновении каких-либо трудностей по выполнению
этих задач обратитесь к следующим разделам данной главы за дополнительной
информацией и рекомендациями.
Таблица 9.1. Контрольный список настройки
Задачи настройки
Развернуть автономный корневой центр сертификации (ЦС).
Защитить ЦС с помощью аппаратного модуля безопасности.
Развернуть автономный ЦС соответствия политике.
Публиковать сертификаты и списки CRL в AD DS.
Развернуть подчиненные ЦС предприятия.
Задачи настройки
Опубликовать и списки CRL, и разностные CRL.
Ограничить типы сертификатов, которые могут быть выпущены ЦС.
Реализовать разделение ролей на основании спецификаций Common Criteria.
Требовать многофакторную аутентификацию для пользователей с ролями
управления PKI.
Избегать размещения OID и CDP политик или расширений сертификатов AIA в
корневых сертификатах.
Примечание Эти рекомендации сформулированы, исходя из предположения, что ваша
инфраструктура открытых ключей (PKI) основывается на Rooted Trust Model (Корневая
доверительная модель).

Развернуть автономный корневой центр сертификации (ЦС)


Все ЦС в Инфраструктуре открытых ключей уязвимы, но корневой ЦС наиболее
уязвим, потому что если он будет скомпрометирован, скомпрометирована будет
вся PKI. Корневой ЦС – это единая точка доверия для всей структуры,
объединяющей в себе несколько организаций.
Важно В более крупномасштабных средах подчиненные ЦС соответствия политике для
разных подразделений или организационных единиц могут играть ту же роль, что и
корневые ЦС. Развертывайте эти подчиненные ЦС соответствия политике как автономные
ЦС.
Microsoft рекомендует предпринимать следующие меры по предупреждению
компрометации ЦС:
 Развернуть корневой ЦС как автономный изолированный ЦС.
Развернуть корневой ЦС как изолированный (offline) ЦС, чтобы
предотвратить сетевые атаки. Для развертывания изолированного
корневого ЦС вы должны развернуть ЦС как автономный (stand-alone) ЦС,
потому что изолированные ЦС предприятий не поддерживаются. Больше
информации о развертывании автономных ЦС можно найти в следующих
разделах службы Справки и поддержки Windows Server 2008:
o «Автономные центры сертификации».
o «Центры сертификации предприятия».
o «Установка корневого центра сертификации».
 Защитить компьютер, являющийся корневым ЦС. Для повышения
защиты корневого ЦС необходимо предпринять одну или более из
перечисленных ниже мер по обеспечению безопасности:
o Хранить компьютеры, являющиеся изолированными ЦС, в
физически защищенных помещениях. Компьютеры, являющиеся
изолированными ЦС, желательно располагать не в обычном
помещении для серверов, а в серверной комнате с ограниченным
доступом или в сейфе. Доступ в серверное помещение или к сейфу
должен быть предоставлен только лицам, занимающимся
администрированием ЦС, все случаи доступа в помещение для
серверов должны записываться. Или можно создать журналы
регистрации физического доступа, в которых будут
протоколироваться все случаи доступа к компьютерам ЦС.
o Хранить компьютеры ЦС в безопасном серверном шкафу.
Существуют модели серверных шкафов, для открытия которых
необходимо ввести PIN-код. Некоторые модели даже отслеживают
все попытки доступа к серверному шкафу и обеспечивают
возможность извлекать журналы регистрации доступов через
последовательные соединения.
o Хранить оборудование изолированных ЦС в отдельных
безопасных помещениях. В некоторых организациях из
компьютеров ЦС удаляют жесткий диск и хранят их в удаленном
сейфе. В этом случае для получения доступа к изолированному ЦС
злоумышленнику надо сначала добраться до компьютера-сервера и
жесткого диска. Такая тактика позволяет компаниям использовать
автономный компьютер-сервер в других целях, когда ЦС удален из
сети.
o Устанавливать корневой ЦС в виртуальной среде и хранить
этот виртуальный образ в отдельном безопасном месте. Это
вариант хранения изолированных компьютеров ЦС в физически
защищенном помещении, но, в данном случае, изолированным
компьютером ЦС является виртуальный образ, а не физический
компьютер.

Защитить ЦС с помощью аппаратного модуля безопасности


Защищайте ЦС, особенно корневой ЦС, с помощью аппаратного модуля
безопасности (hardware security module, HSM) с маркером оборудования HSM-
оператора для ограничения доступа к закрытому ключу ЦС. Кроме ограничения
доступа к закрытому ключу ЦС, большинство HSM являются также аппаратными
ускорителями шифрования, обеспечивающими лучшую производительность, чем
обычная программная система шифрования. Больше информации о HSM можно
найти в разделе «Настройка центра сертификации с помощью аппаратного модуля
безопасности» службы Справка и поддержка Windows Server 2008.

Развернуть изолированный ЦС соответствия политике


ЦС соответствия политике – это тип промежуточного ЦС, который обычно
используется для классификации сертификатов при помощи политик. Например,
разделение может основываться на уровне гарантий, обеспечиваемом ЦС, или
географическом положении ЦС, по которому можно различать разные популяции
конечных субъектов. ЦС соответствия политике может быть подключенным к сети
или автономным.
Для публикации сертификата и CRL изолированного ЦС используйте безопасные
процедуры. Сертификат изолированного ЦС необходимо опубликовать только один
раз. Но CRL для изолированного ЦС должен публиковаться через равные
промежутки времени, соответствующие интервалу публикации CRL, заданному в
Свойствах отозванных сертификатов (Revoked Certificates Properties)
изолированного ЦС.
Если изолированный ЦС обслуживается в безопасном помещении, таком как центр
обработки данных или защищенное хранилище, лучше всего, когда публикацией
изолированного CRL в этом помещении занимается не один, а несколько
администраторов или доверенных лиц, как предписано политикой сертификатов и
уведомлениями о правилах работы с сертификатами для вашей организации.
После публикации CRL вы должны вручную перенести его из центра обработки
данных или защищенного хранилища туда, где он может быть развернут на точки
распространения CRL.
Изолированный CRL должен публиковаться, по крайней мере, за несколько дней до
истечения рока действия предыдущего CRL. Это дает возможность заранее
исправить любые проблемы с оборудованием или ошибки публикации, что
гарантирует непрерывность предоставления службы при публикации
изолированных CRL и их репликации на все точки распространения CRL (CDP).
Установив изолированный ЦС, конфигурируйте различные опции ограничений и
политик для выдаваемых им сертификатов. Эти расширения обеспечивают
приложениям и клиентам, использующим сертификаты в иерархии, возможность
гарантированно выполнять отзыв и построение цепочки по необходимости.
Microsoft рекомендует развертывать изолированный ЦС соответствия политике,
руководствуясь рекомендациями, приведенными ранее в этой главе в разделе
«Развернуть автономный корневой центр сертификации (ЦС)». С точки зрения
безопасности изолированный ЦС соответствия политике аналогичен корневому ЦС.
Однако ЦС соответствия политике будет переводиться в оперативный режим чаще,
чем корневой ЦС.

Публиковать сертификаты и списки CRL в AD DS


Если организация использует PKI для обеспечения сертификатами пользователей
и компьютеров домена, Microsoft рекомендует публиковать сертификаты и списки
CRL в AD DS. AD DS обеспечивает безопасное хранилище для сертификатов и
списков CRL. По умолчанию доступ к сертификатам и спискам CRL осуществляется
1
по протоколу LDAP (Lightweight Directory Access Protocol ). Бывают случаи, когда
невозможно организовать доступ к сертификатам и спискам CRL по протоколу
LDAP. Тогда, если PKI конфигурирована на публикацию сертификатов и списков
CRL другими методами, используются другие протоколы, такие как HTTP.
И ЦС предприятия, и автономные ЦС могут публиковать сертификаты и списки CRL
в Active Directory. По умолчанию ЦС предприятия публикуют сертификаты и списки
CRL в домен, в который они входят. Публикация сертификатов и списков CRL в
другие домены и леса должна осуществляться вручную. Также вручную
выполняется настройка автономного ЦС для публикации сертификатов и списков
CRL в Active Directory.
Устанавливать автономный ЦС так, чтобы он публиковал свои сертификаты и CLR
в AD DS, могут участники группы Администраторы домена родительского домена
предприятия или администратор с правом записи в AD DS. Больше информации о
публикации сертификата или CRL в Active Directory на автономном ЦС можно найти
в разделе «To publish as certificate or CRL to Active Directory» (Чтобы опубликовать
сертификат или CRL в Active Directory) материала Certutil tasks for managing CRLs
(Применение программы Certutil для управления списками CRL).

1
Протокол облегченного доступа к каталогам (прим. переводчика).
Развернуть подчиненные ЦС предприятия
Если в организации PKI используется, главным образом, в интрасети, разверните
подчиненные ЦС предприятия, потому что они автоматически публикуют
сертификаты и списки CRL в AD DS. Больше информации о преимуществах
публикации сертификатов и списков CRL в AD DS можно найти в предыдущем
разделе данной главы, «Публиковать сертификаты и списки CRL в AD DS».
Дополнительную информацию о развертывании подчиненных ЦС предприятия
можно найти в следующих разделах службы Справка и поддержка
Windows Server 2008:
 «Центры сертификации предприятия».
 «Установка подчиненного центра сертификации».

Опубликовать и списки CRL, и разностные CRL


В больших ЦС, переживших существенное число отзывов сертификатов, списки
CRL могут достигать очень больших размеров. Частая загрузка таких списков
представляет сложность для клиентских компьютеров. Чтобы максимально
сократить частоту загрузки больших списков CRL, существует возможность
публиковать разностные CRL. В этом случае клиентские компьютеры могут
загружать текущий CRL и, комбинируя его с последним базовым CRL, получать
полный список отозванных сертификатов. Поскольку клиентские компьютеры
обычно хранят списки CRL локально, использование разностных CRL потенциально
способствует улучшению производительности.
Чтобы использовать разностные CRL, клиентское приложение должно
поддерживать и явно использовать разностные CRL для проверки отзыва
сертификатов. Если клиентский компьютер не использует разностные CRL, он
будет извлекать CRL из ЦС при каждом обновлении своего кэша, независимо от
того, существует разностный CRL или нет. Поэтому убедитесь, что
соответствующие приложения используют разносные CRL, и надлежащим образом
настройте ЦС. Если клиентские компьютеры не поддерживают использование
разностных CRL, либо не конфигурируйте ЦС на публикацию разностных CRL, либо
настройте его таким образом, чтобы CRL и разностные CRL публиковались с
равной периодичностью. Таким образом, новые приложения, поддерживающие
разностные CRL, могут использовать их, а существующие приложения
обеспечиваются текущими списками CRL.
Примечание Все приложения, использующие CryptoAPI в Windows® XP, Windows Vista®,
Windows Server® 2003 и Windows Server 2008 используют разностные CRL.

Ограничить типы сертификатов, которые могут быть выпущены


ЦС
Разверните ЦС, которые будут выдавать особый тип сертификатов. Например,
если необходимо выдавать сертификаты для аутентификации смарт-карт или
подписи сообщений электронной почты, разверните выделенный ЦС для выдачи
сертификатов подлинности смарт-карт и отдельный ЦС для выдачи сертификатов
подписи сообщений электронной почты. Типы выдаваемых ЦС сертификатов
ограничиваются с помощью шаблонов сертификатов. Больше информации о
шаблонах сертификатов можно найти в материале Certificate Template Overview
(Обзор шаблонов сертификатов),
Реализовать разделение ролей на основании спецификаций
Common Criteria
Для организации администраторов ЦС в отдельные предопределенные роли на
основании задач используется ролевое администрирование. Microsoft рекомендует
распределят управление ролями между несколькими сотрудниками организации.
Это обеспечит невозможность компрометации служб PKI одним человеком.
Разделение ролей позволяет администраторам контролировать действия друг
друга.
Важно Количество пользователей, управляющих ЦС, должно быть ограниченным, потому
что ЦС играют решающую роль в обеспечении безопасности PKI.
1
К ролям управления PKI по стандарту Common Criteria относятся:
 Администратор PKI. Настраивает и обслуживает ЦС, назначает других
администраторов ЦС и диспетчеров сертификатов, обновляет сертификаты
ЦС.
 Диспетчер сертификатов. Подтверждает или отклоняет запросы на выпуск
сертификатов и отзывает выпущенные сертификаты.
 Оператор архива. Выполняет архивацию базы данных ЦС, настройки ЦС и
пары закрытого и открытого ключа ЦС (также называемой парой ключей).
 Диспетчер аудита. Определяет, какие события подлежат аудиту для
Службы сертификации, и анализирует журнал безопасности в Windows
Server 2008 на предмет успешных и неудачных событий аудита,
касающихся Службы сертификации.
 Диспетчер восстановления ключей. Запрашивает закрытый ключ
службы.
 Заявитель. Запрашивает сертификаты на ЦС.
Больше информации по реализации разделения ролей на базе спецификаций
Common Criteria можно найти в статье Defining PKI Management and Delegation
(Определение управления и делегирования в PKI).

Требовать многофакторную аутентификацию для пользователей


с ролями управления PKI
Факторы аутентификации пользователей обычно классифицируются следующим
образом:
 Пользователь знает специальную информацию, такую как пароль,
парольная фраза или персональный идентификационный номер (PIN).
 Пользователь использует специальное устройство, такое как смарт-карта,
маркер доступа, маркер программы, телефон или мобильный телефон.
 Пользователь предоставляет биометрический параметр, такое как
отпечаток пальца или узор сетчатки глаза, последовательность ДНК,
распознавание подписи или голоса, уникальные биоэлектрические сигналы
или другие биометрические показатели.
Часто в организациях используются сочетания этих методов. Например, платежная
карта и PIN, такой способ еще называют двухфакторной аутентификацией.

1
Общие критерии (прим. переводчика).
Проверка подлинности пользователей может проводиться только по паролю, но
для повышения уровня аутентификации в организации может использоваться
многофакторная аутентификация. В многофакторной аутентификации обычно
принимает участие физическое устройство, такое как устройство чтения смарт-
карт, USB-маркер доступа или устройство считывания отпечатков пальцев. Выбор
физических устройств для многофакторной аутентификации обычно
осуществляется, исходя из требований, не связанных с безопасностью.
Например, ваша организация могла бы потребовать, чтобы смарт-карты
пользователей включали идентификацию по фотографии, поскольку на смарт-карте
могут быть напечатаны фото и имя владельца. Однако для использования смарт-
карты необходимо устройство для чтения, что ведет к дополнительным расходам.
USB-маркер может включать флэш-память для хранения документов и файлов, и
пользователи могут подключать USB-маркер в существующие USB-порты своих
компьютеров.
Такая форма обеспечения безопасности рекомендуется для учетных записей,
выполняющих роли управления PKI. В частности, требуйте многофакторной
аутентификации для пользователей, выполняющих следующие роли управления
PKI:
 Администратор PKI
 Диспетчер сертификатов
 Оператор архива
 Диспетчер аудита
 Диспетчер восстановления ключей
Примечание По возможности рекомендуется использовать в организации многофакторную
аутентификацию, поскольку это обеспечит требование по предоставлению самых надежных
из возможных паролей для учетных записей пользователя. Использование многофакторной
аутентификации заставляет систему автоматически формировать криптографически стойкие
случайные пароли для учетных записей.

Избегать размещения OID и CDP политик или расширений


сертификатов AIA в корневых сертификатах
В качестве лучшей практики Microsoft рекомендует избегать размещения
идентификаторов объектов политики (OID) в корневых сертификатах. По
определению, корневой ЦС реализует все политики. Это относится как к ЦС
предприятия, так и к автономным ЦС.
Для ЦС, располагающегося в любой точке иерархии, может быть определена одна
или более политика. Если сертификат ЦС имеет какие-либо OID политики, все
сертификаты, располагающиеся ниже этого ЦС по иерархии, должны также иметь
подмножество OID этой политики. Цепочка сертификатов, не имеющая набора
действительных политик, будет считаться недействительной, тогда как цепочка
вообще без OID политики будет действительной и соответствовать OID «любой
политики». Это действительно только для Политик приложения, но не для Политик
выдачи. Отсутствие расширения certificatePolicies (политики сертификатов) в
некорневом сертификате означает отсутствие политики выдачи.
Кроме того, следует избегать размещения расширений Точка распространения
списков отзыва (CRL Distribution Point, CDP) и Доступ к информации о центрах
сертификации (Authority Information Access, AIA) в корневых сертификатах, потому
что некоторые приложения не контролируют отзыв сертификатов корневого ЦС.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли Центр
сертификации.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
компьютеров-серверов, выполняющих службу роли Центр сертификации можно
найти в следующих источниках на сайте Microsoft.com:
 Active Directory Certificate Services.
 Certutil tasks for managing CRLs.
 Certificate Template Overview.
 Defining PKI Management and Delegation.
 Rooted Trust Model.
 Следующие разделы службы Справка и поддержка Windows Server 2008:
o «Автономные центры сертификации».
o «Центры сертификации предприятия».
o «Установка корневого центра сертификации».
o «Настройка центра сертификации при помощи аппаратного модуля
безопасности».
o «Установка подчиненного центра сертификации».
o «Реализация ролевого администрирования».

Служба роли Служба подачи заявок в центр


сертификации через Интернет
Служба роли Служба подачи заявок в центр сертификации через Интернет
обеспечивает механизм подачи заявок на выпуск и обновление сертификатов для
следующих ресурсов:
 Пользователей и компьютеров, являющихся участниками вашего домена.
 Пользователей и компьютеров, не входящих в ваш домен.
 Пользователей и компьютеров, не подключенных в вашу интрасеть
напрямую.
 Пользователей с операционной системой отличной от Windows®.
 А также загрузку списков доверия сертификатов.
Вместо использования функции автоматической подачи заявок ЦС или Мастера
запроса сертификатов (Certificate Request Wizard), можно предоставить
пользователям возможность запрашивать и получать новые или возобновленные
сертификаты по Интернету или соединению интрасети с помощью Службы подачи
заявок в центр сертификации через Интернет.
Устанавливать службу подачи заявок в центр сертификации через Интернет могут
пользователи, обладающие как минимум правами Администраторов домена или
эквивалентными им. Дополнительную информацию можно найти в разделе
«Реализация ролевого администрирования» службы Справка и поддержка Windows
Server 2008.
Больше информации о Службе подачи заявок в центр сертификации через
Интернет можно найти в статье AD CS: Web Enrollment (AD CS: подача заявок
через Интернет).

Поверхность атаки роли


Служба подачи заявок в центр сертификации через Интернет подвержена тем же
атакам на систему безопасности, что и любой ЦС. Чтобы обозначить поверхность
атаки этой службы роли, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
подачи заявок в центр сертификации через Интернет.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
подачи заявок в центр сертификации через Интернет.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой подачи заявок в центр
сертификации через Интернет правила брандмауэра Windows.
 Зависимости роли. Это зависимости службы подачи заявок в центр
сертификации через Интернет.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу подачи заявок в центр сертификации через Интернет. В
случае возникновения трудностей с выполнением каких-либо пунктов контрольного
списка дополнительное описание и рекомендации можно найти в следующих
разделах данной главы.
Таблица 9.2. Контрольный список настройки
Задачи настройки
Включить Проверку подлинности Windows для запросов внутри интрасети.
Задачи настройки
Защитить запросы на сертификаты и ответы на них с помощью шифрования
1
Secure Sockets Layer (SSL).
Выделить компьютер для службы подачи заявок в центр сертификации через
Интернет.
Выполнить рекомендации по повышению уровня защиты для роли сервера Веб-
служб (IIS).
Настроить учетную запись пользователя соответственно предписанию центра
регистрации.

Включить Проверку подлинности Windows для запросов внутри


интрасети
При установке службы роли Подачи заявок на сертификат через Интернет на Веб-
узле по умолчанию (Default Web Site) создаются виртуальные каталоги CertSrv и
CertEnroll. Для доступа к этим виртуальным каталогам по умолчанию используется
анонимная проверка подлинности. Если Служба подачи заявок на сертификат
через Интернет обслуживает только компьютеры, подключенные к интрасети, эти
виртуальные каталоги можно конфигурировать на использование Проверки
подлинности Windows.
Проверка подлинности Windows для аутентификации клиентских компьютеров
использует протоколы NTLM или Kerberos. Проверка подлинности Windows лучше
всего подходит для среды интрасети и обычно не используется в Интернете. Для
проверки подлинности запросов, поступающих по Интернету, применяется обычная
или дайджест-аутентификация и с помощью SSL шифруется весь трафик.
Важно Не включайте анонимный доступ для виртуальных каталогов CertSrv и CertEnroll,
создаваемых на Веб-узле по умолчанию.
Больше информации о настройке Веб-узла для использования Проверки
подлинности Windows можно найти в статье IIS 7.0: Configuring Authentication in IIS
7.0 (IIS 7.0: настройка проверки подлинности в IIS 7.0)

Защитить запросы на сертификаты и ответы на них с помощью


шифрования Secure Sockets Layer (SSL)
По умолчанию виртуальные каталоги CertSrv и CertEnroll, созданные на Веб-узле
по умолчанию, используют HTTP. HTTP-протокол передает запросы на
сертификаты и отклики в виде открытого текста. Microsoft настоятельно
рекомендует защищать этот трафик с помощью SSL-шифрования.
Больше информации о том, как конфигурировать Веб-узел для защиты трафика
посредством SSL-шифрования, приведено в разделе «Шифрование данных,
пересылаемых между Веб-сервером и клиентом» службы Справка и поддержка
Windows Server 2008.

1
Протокол безопасных соединений (прим. переводчика).
Выделить компьютер для службы подачи заявок в центр
сертификации через Интернет
Установите службу подачи заявок в центр сертификации через Интернет на
компьютер, выделенный для этой службы роли. Данную службу можно
устанавливать на компьютер, выполняющий службу роли Центр сертификации, но
это приведет к увеличению поверхности атаки службы роли Центр сертификации.
Устанавливая службу роли Подача заявок в центр сертификации через Интернет на
отдельный компьютеры, вы отводите Веб-трафик с компьютера, выполняющего
службу роли Центр сертификации.
В зависимости от поддерживаемых типов пользователей может понадобиться
установить Службу подачи заявок в центр сертификации через Интернет на
несколько компьютеров. Например, если вы поддерживаете:
 Пользователей в интрасети, тогда, вероятно, в вашей интрасети должно
быть несколько компьютеров, выполняющих службу подачи заявок в центр
сертификации через Интернет
 Пользователей в Интернете, тогда, вероятно, на сетевом периметре или во
внешней сети вашей организации понадобится разместить один или более
компьютеров, выполняющих службу подачи заявок в центр сертификации
через Интернет.

Выполнить рекомендации по повышению уровня защиты для


роли сервера Веб-служб (IIS)
Поскольку данная служба роли выполняется в IIS 7.0, должны быть обязательно
выполнены рекомендации по повышению уровня безопасности для роли сервера
Веб-служб (IIS). Больше информации по повышению уровня защиты роли сервера
Веб-служб (IIS) можно найти в Главе 6, «Повышение уровня защиты Веб-служб»,
данного руководства.

Настроить учетную запись пользователя соответственно


предписанию центра регистрации
Службе подачи заявок в центр сертификации через Интернет необходим набор
учетных данных, которые она использует для аутентификации на Центре
сертификации при запросе сертификата. Этот набор называют назначенным
центром регистрации.
Microsoft рекомендует использовать в качестве назначенного центра регистрации
не учетную запись сетевой службы (NetworkService), а создавать для этого
специальную учетную запись пользователя. Причина в том, что учетной записи
пользователя можно присвоить только необходимые права и разрешения, тогда как
учетная запись NetworkService может обладать более широкими правами, чем
требуется. Кроме того, изменение прав и разрешений, предоставленных учетной
записи NetworkService, может повлиять на другие программы, выполняющиеся на
компьютере. Учетная запись пользователя должна быть участником Домена и
добавляется в локальную группу IIS_IUSRS.
Соответствующие параметры групповой политики
Не существует параметров групповой политики для службы роли Подача заявок в
центр сертификации через Интернет.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службу подачи заявок в центр сертификации через
Интернет, можно найти в следующих источниках на сайте Microsoft.com:
 Active Directory.
 AD CS: Web Enrollment (AD CS: подача заявок через Интернет).
 IIS 7.0: Configuring Authentication in IIS 7.0.
 Следующие разделы службы Справка и поддержка Windows Server 2008:
o «Шифрование данных, пересылаемых между Веб-сервером и
клиентом».
o «Реализация ролевого администрирования».

Служба роли Сетевой ответчик


Отзыв сертификатов – необходимая часть процесса управления сертификатами,
выпущенными ЦС. Обычно состояние отзыва сертификатов передается путем
распространения списков отзыва сертификатов (certificate revocation lists, CRLs).
Однако в инфраструктурах открытых ключей (public key infrastructures, PKIs), в
которых использование традиционных списков CRL не является оптимальным
решением, служба роли Сетевой ответчик может управлять и распространять
информацию о состоянии отзыва с помощью протокола Online Certificate Status
1
Protocol (OCSP) .
Основной недостаток традиционных списков CRL – их потенциально большой
размер, что является причиной ограниченной масштабируемости подхода с
использованием CRL. Большой размер требует от ЦС и участвующей стороны
наличия большой полосы пропускания для передачи и большого хранилища, таким
образом, ограничивает возможность распространения CRL системой. Также
слишком высокая частота публикации негативному сказывается на полосе
пропускания, дисковом пространстве и обрабатывающей способности ЦС.
Было предпринято множество попыток решить проблему с размером CRL через
введение секционированных CRL, разностных CRL и непрямых CRL. Все эти
подходы добавили сложности системе и повысили ее стоимость, не предоставив
идеального решения основной проблемы.
Другой недостаток традиционных CRL – задержка. Поскольку периодичность
публикации CRL определена заранее, информация, содержащаяся в CRL, может
устареть еще до выхода нового CRL или разностного CRL.
Примечание Операционные системы Microsoft до Windows Vista поддерживают только CRL и
разностный CRL. Windows Vista и Windows Server 2008 поддерживают CRL, разностный CRL и
OCSP как метод определения состояния сертификата. Поддержка OCSP включает как
клиентский компонент, так и Сетевой ответчик, который является серверным компонентом.

1
Протокол сетевого состояния сертификата (прим. переводчика).
Служба роли Сетевой ответчик декодирует запросы состояния отзыва
определенных сертификатов, оценивает состояние этих сертификатов и
возвращает подписанный ответ, содержащий запрашиваемую информацию о
состоянии сертификата.
Минимальным требованием для установки службы роли Сетевой ответчик является
членство в локальной группе Администраторы или эквивалентной ей.
Минимальным требованием для настройки в ЦС поддержки службы роли Сетевой
ответчик является членство в группе Администраторы домена или Администраторы
предприятия или эквивалентных им. Больше информации по вопросам
администрирования PKI можно найти в разделе «Реализация ролевого
администрирования» службы Справка и поддержка Windows Server 2008.
Больше информации о службе роли Сетевой ответчик можно найти в статье AD CS:
Online Certificate Status Protocol Support (AD CS: поддержка протокола сетевого
состояния сертификата).

Поверхность атаки
Служба роли Сетевой ответчик подвержена тем же атакам на систему
безопасности, что и любой компьютер-сервер, публикующий списки CRL. Чтобы
обозначить поверхность атаки этой службы роли, необходимо определить
следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли Сетевой ответчик.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
роли Сетевой ответчик.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой роли Сетевой ответчик
правила брандмауэра Windows.
 Зависимости роли. Это зависимости службы роли Сетевой ответчик.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу роли Сетевой ответчик. В случае возникновения трудностей
с выполнением каких-либо пунктов контрольного списка дополнительное описание
и рекомендации можно найти в следующих разделах данной главы.
Таблица 9.3. Контрольный список настройки
Задачи настройки
Включить Проверку подлинности Windows для запросов внутри интрасети.
Защитить запросы состояния отзыва сертификатов и ответы на них с помощью
SSL-шифрования.
Защитить ключи подписи протокола OCSP с помощью HSM.
Защитить Сетевой ответчик в сценариях развертывания во внешней сети.
Выполнить рекомендации по повышению уровня защиты для роли сервера Веб-
службы (IIS).
Настроить учетную запись пользователя как назначенный центр регистрации.

Включить Проверку подлинности Windows для запросов внутри


интрасети
При установке службы роли Сетевой ответчик на Веб-узле по умолчанию
создается виртуальный каталог ocsp. Для доступа к этому виртуальному каталогу
по умолчанию используется анонимная проверка подлинности. Если Сетевой
ответчик обслуживает только компьютеры, подключенные к интрасети,
виртуальный каталог ocsp можно настроить на использование Проверки
подлинности Windows.
Проверка подлинности Windows для аутентификации клиентских компьютеров
использует протоколы NTLM или Kerberos. Проверка подлинности Windows лучше
всего подходит для интрасети и обычно не используется в Интернете. Для
проверки подлинности запросов, поступающих по Интернету, применяется обычная
или дайджест-аутентификация и с помощью SSL шифруется весь трафик.
Больше информации о настройке Веб-узла для использования Проверки
подлинности Windows можно найти в статье IIS 7.0: Configuring Authentication in IIS
7.0.

Защитить запросы состояния отзыва сертификатов и ответы на


них с помощью SSL-шифрования
По умолчанию виртуальный каталог ocsp, созданный на Веб-узле по умолчанию,
использует HTTP. HTTP-протокол передает запросы состояния отзыва
сертификатов и отклики в виде открытого текста. Microsoft настоятельно
рекомендует защищать этот трафик с помощью SSL-шифрования.
Больше информации о том, как конфигурировать Веб-узел для защиты трафика
посредством SSL-шифрования, приведено в разделе «Шифрование данных,
пересылаемых между Веб-сервером и клиентом» службы Справка и поддержка
Windows Server 2008.

Защитить ключи подписи протокола OCSP с помощью HSM


OCSP снабжает цифровой подписью каждый успешный запрос, таким образом,
запрашивающая сторона знает, что отклик на запрос состояния отзыва поступил с
надежного сервера. Служба роли Сетевой ответчик подписывает отклики ключом
подписи OCSP, который можно получить от ЦС или HSM.
В качестве HSM может выступать PCI-плата или внешнее устройство, такое как
устройство USB, PCMCIA, SCSI или RS232, которое формирует и хранит
долгосрочные данные, используемые для шифрования. Также HSM физически
защищает секреты от доступа. Основное преимущество HSM в том, что он
предоставляет более высокую безопасность для подписи ключей, используемых
ролью Сетевой ответчик, потому что HSM является физическим устройством.
Другое преимущество – большинство HSM также являются аппаратными
ускорителями шифрования. Поскольку HSM не допускают изъятия ключей с
устройства в нешифрованной форме, они должны уметь выполнять обычные
операции шифрования. Эти устройства обеспечивают лучшую производительность,
чем обычная программная система шифрования.
Больше информации о настройке Сетевого ответчика на использование HSM для
защиты ключей подписи OCSP можно найти в разделе «Using an HSM to protect
OCSP signing keys» (Использование HSM для защиты ключей подписи OCSP)
статьи Online Responder Installation, Configuration, and Troubleshooting Guide
(Руководство по установке, настройке и поиску и устранению неисправностей
Сетевого ответчика).

Защитить Сетевой ответчик в сценариях развертывания во


внешней сети
Одной из задач проектирования развертывания Сетевых ответчиков во внешней
сети является определение уровня защиты, который должен быть обеспечен ключу
подписи Сетевого ответчика. На следующем рисунке представлено два варианта
защиты Сетевого ответчика.
ISA

IIS

Сетевой
периметр

Сетевой
ответчик

Рис. 9.2. Варианты развертывания во внешней сети


На диаграмме 1 предыдущего рисунка Сетевой ответчик расположен в
защищенной локальной сети (local area network, LAN), тогда как все запросы
перенаправляются аутентифицированным сервером, выполняющим IIS, который
размещается на сетевом периметре (который также называют DMZ,
демилитаризованной зоной и промежуточной подсетью).
Преимущество такой модели развертывания в том, что настройка брандмауэра
заключается лишь в направлении трафика между IIS и Сетевым ответчиком через
определенные порты: HTTP-трафика через TCP-порт 80 или HTTPS-трафика через
TCP-порт443. Аналогичных результатов можно добиться, используя способность
сервера Microsoft Internet Security and Acceleration (ISA) выступать в роли обратного
прокси-сервера, как показано на диаграмме 2 предыдущего рисунка.
Больше информации о том, как защитить Сетевой ответчик в сценариях
развертывания во внешней сети, можно найти в разделе «Using an HSM to protect
OCSP signing keys» статьи Online Responder Installation, Configuration, and
Troubleshooting Guide.

Выполнить рекомендации по повышению уровня защиты для


роли сервера Веб-службы (IIS)
Поскольку данная служба роли выполняется в IIS 7.0, должны быть обязательно
выполнены рекомендации по повышению уровня безопасности для роли сервера
Веб-служб (IIS). Больше информации по повышению уровня защиты роли сервера
Веб-служб (IIS) можно найти в Главе 6, «Повышение уровня защиты Веб-служб»,
данного руководства.
Настроить учетную запись пользователя как назначенный центр
регистрации
Службе роли Сетевой ответчик необходим набор учетных данных, которые она
использует для аутентификации в Центре сертификации при запросе сертификата.
Этот набор называют назначенным центром регистрации.
Microsoft рекомендует использовать в качестве назначенного центра регистрации
не учетную запись сетевой службы (NetworkService), а создавать специальную
учетную запись пользователя для этого. Причина в том, что учетной записи
пользователя можно присвоить только необходимые права и разрешения, тогда как
учетная запись NetworkService может обладать более широкими правами, чем
требуется. Кроме того, изменение прав и разрешений, предоставленных учетной
записи NetworkService, может повлиять на другие программы, выполняющиеся на
компьютере. Учетная запись пользователя должна быть участником Домена и
добавляется в локальную группу IIS_IUSRS.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли Сетевой ответчик.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службу роли Сетевой ответчик можно найти в следующих
источниках:
 Active Directory.
 AD CS: Online Certificate Status Protocol Support.
 IIS 7.0: Configuring Authentication in IIS 7.0.
 Online Responder Installation, Configuration, and Troubleshooting Guide.
 Раздел «Реализация ролевого администрирования» службы Справка и
поддержка Windows Server 2008.

Служба подачи заявок на сетевые устройства


Служба подачи заявок на сетевые устройства (Network Device Enrollment Service,
NDES) обеспечивает возможность маршрутизаторам и другим сетевым
устройствам, не имеющим учетных записей Windows, получать сертификаты. NDES
1
– это реализация Microsoft протокола Simple Certificate Enrollment Protocol (SCEP) ,
протокола связи, который позволяет программам, выполняющимся на сетевых
устройствах, таким как маршрутизаторы и коммутаторы, которые не могут быть
аутентифицированы в сети никаким другим образом, подавать заявку на получение
сертификатов X.509 от ЦС.
Минимальным требованием для настройки службы подачи заявок на сетевые
устройства является членство в группе Администраторы. Больше информации
можно найти в разделе «Реализация ролевого администрирования» службы
Справка и поддержка Windows Server 2008.

1
Протокол простой подачи заявки на сертификат (прим. переводчика).
Для получения дополнительной информации об этой службе роли обратитесь к
следующим ресурсам:
 AD CS: Network Device Enrollment Service (AD CS: служба подачи заявок на
сетевые устройства).
 Microsoft SCEP Implementation Whitepaper (Документация по реализации
Microsoft SCEP).

Поверхность атаки
Служба роли NDES во многом подвержена тем же атакам на систему безопасности,
что и любой ЦС. Чтобы обозначить поверхность атаки этой службы роли,
необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли NDES.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
роли NDES.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой роли NDES правила
брандмауэра Windows.
 Зависимости роли. Это зависимости службы роли NDES.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию службы роли NDES для защиты сервера от
злоумышленных атак. Приведенные ниже рекомендации предполагают, что на
странице Выбор служб роли Мастера добавления ролей выбрана только опция
Служба подачи заявок на сетевые устройства. Рекомендации для других служб
роли не включены.

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу роли NDES. В случае возникновения трудностей с
выполнением каких-либо пунктов контрольного списка дополнительное описание и
рекомендации можно найти в следующих разделах данной главы.
Таблица 9.4. Контрольный список настройки
Задачи настройки
Настроить учетную запись пользователя как назначенный центр регистрации.
Обеспечить максимальную безопасность центра сертификации.
Настроить учетную запись пользователя как назначенный центр
регистрации
Службе роли NDES необходим набор учетных данных, которые она использует для
аутентификации на Центре сертификации при запросе сертификата. Этот набор
называют назначенным центром регистрации.
Microsoft рекомендует использовать в качестве назначенного центра регистрации
не учетную запись сетевой службы (NetworkService), а создавать специальную
учетную запись пользователя для этого. Причина в том, что учетной записи
пользователя можно присвоить только необходимые права и разрешения, тогда как
учетная запись NetworkService может обладать более широкими правами, чем
требуется. Кроме того, изменение прав и разрешений, предоставленных учетной
записи NetworkService, может повлиять на другие программы, выполняющиеся на
компьютере. Учетная запись пользователя должна быть участником Домена и
добавляется в локальную группу IIS_IUSRS.
Больше информации о настройке учетной записи в качестве назначенного центра
регистрации можно найти в разделе «Настройка службы подачи заявок на сетевые
устройства» в службе Справка и поддержка Windows Server 2008.

Обеспечить максимальную безопасность центра сертификации


Для подачи заявок на сетевые устройства служба роли NDES использует два
сертификата и их ключи. Один сертификат и ключ используется, чтобы избежать
повторных подключений между ЦС и Центром регистрации. Другой сертификат и
ключ обеспечивают безопасность обмена информацией между Центром
регистрации и сетевым устройством.
Организации могут хранить эти ключи у других Поставщиков служб шифрования
(Cryptographic Service Providers, CSPs) или могут менять длину ключей,
используемых службой. Конфигурацию Центра регистрации можно задать при
установке службы роли NDES на странице Настроить шифрование для центра
регистрации (Configure Cryptography for Registration Authority). Если не
предъявляются какие-либо специальные требования, Microsoft рекомендует
сохранять стандартные настройки.
Примечание Для ключей Центра регистрации поддерживаются только Поставщики служб
криптографического прикладного программного интерфейса (Cryptographic Application
Programming Interface, CryptoAPI). Поставщики следующего поколения криптографических
API (Cryptography API: Next Generation, CNG) не поддерживаются.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли NDES.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службу роли NDES, можно найти в следующих источниках:
 Active Directory Certificate Services.
 AD CS: Network Device Enrollment Service.
 Microsoft SCEP Implementation Whitepaper.
 В службе Справка и поддержка Windows Server 2008 этим вопросам
посвящены следующие разделы:
o «Реализация ролевого администрирования».
o «Настройка службы подачи заявок на сетевые устройства».

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службы роли AD CS, предоставляют следующие ресурсы
сайта Microsoft.com:
 Для службы роли Центр сертификации:
 Active Directory Certificate Services.
 Certutil tasks for managing CRLs.
 Certificate Template Owerview.
 Defining PKI Management and Delegation.
Разделы Справки и поддержки Windows Server 2008:
 «Центры сертификации предприятия».
 «Установка корневого центра сертификации».
 «Установка подчиненного центра сертификации».
 «Настройка центра сертификации с использованием аппаратного
модуля безопасности».
 «Автономные центры сертификации».
 «Реализация ролевого администрирования».
 Для службы подачи заявок в центр сертификации через Интернет:
 Active Directory Certificate Services.
 AD CS: Web Enrollment.
 IIS 7.0: Configuring Authentication in IIS 7.0.
Разделы Справки и поддержки Windows Server 2008:
 «Шифрование данных, пересылаемых между Веб-сервером и
клиентом».
 «Реализация ролевого администрирования».
 Для службы роли Сетевой ответчик:
 Active Directory Certificate Services.
 AD CS: Online Certificate Status Protocol Support.
 IIS 7.0: Configuring Authentication in IIS 7.0.
 Online Responder Installation, Configuration, and Troubleshooting Guide.
Разделы Справки и поддержки Windows Server 2008:
 «Реализация ролевого администрирования».
 Для службы подачи заявок на сетевые устройства:
 Active Directory Certificate Services.
 AD CS: Network Device Enrollment Service.
 Microsoft SCEP Implementation Whitepaper.
Разделы Справки и поддержки Windows Server 2008:
 «Настройка службы подачи заявок на сетевые устройства».
 «Реализация ролевого администрирования».

Глава 10: Повышение уровня защиты служб политики


сети и доступа
Службы политики сети и доступа (Network Policy and Access Services, NPAS) в
Windows Server® 2008 обеспечивают технологии, позволяющие развертывать и
работать с виртуальной частной сетью (virtual private network, VPN),
коммутационной сетью, выполнять защищенный по стандарту 802.1X проводной и
беспроводной доступ и работать с устройствами на базе Cisco Network Admission
1
Control (NAC) . Используя NPAS, можно определять и применять политики
аутентификации, авторизации и оценки безопасного состояния клиента для входа в
сеть с помощью Сервера политики сети (Network Policy Server, NPS), Службы
маршрутизации и удаленного доступа (Routing and Remote Access Service), Центра
регистрации работоспособности (Health Registration Authority, HRA) и Протокола
авторизации учетных данных узла (Host Credential Authorization Protocol, HCAP).
NPS может развертываться как сервер Службы удаленной аутентификации
пользователей, устанавливающих соединение по телефонным линиям (Remote
Authentication Dial-in User Service, RADIUS), RADIUS-прокси, одновременно сервер
и прокси-сервер RADIUS и как сервер политики безопасности клиента для сети
Защищенного сетевого доступа (Network Access Protection, NAP). NAP
обеспечивает совместимость подключающихся к сети компьютеров с сетью
организации и их соответствие политикам безопасности клиента для сети.
Примечание Роль сервера NPAS недоступна в установках Server Core Windows Server 2008.
В данной главе предлагается нормативное руководство по повышению уровня
защиты служб роли NPAS. Службы роли, составляющие роль NPAS, представлены
на следующем рисунке.

1
Управление доступом в сеть (прим. переводчика).
Сервер политики сети

Маршрутизация и удаленный доступ


Служба удаленного доступа
Роль Службы политики Служба маршрутизации
сети и доступа
Центр регистрации работоспособности

Протокол авторизации учетных данных узла

Рис. 10.1. Иерархия служб роли NPAS


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

Служба роли NPS


NPS – это реализация Microsoft RADIUS сервера и прокси-сервера. NPS может
использоваться для централизованного управления доступом в сеть посредством
разнообразных серверов сетевого доступа, включая точки беспроводного доступа,
VPN-серверы, серверы удаленного доступа и коммутаторы, выполняющие
аутентификацию по стандарту 802.1X. Кроме того, с помощью NPS можно
реализовывать безопасную проверку паролей путем использования любого
совместимого с RFC3748 метода Протокола расширенной проверки подлинности
(Extensible Authentication Protocol, EAP), такого как Защищенный протокол
расширенной проверки подлинности (Protected Extensible Authentication Protocol,
PEAP) PEAP-MS-CHAP v2 или Облегченный протокол расширенной проверки
подлинности (Lightweight Extensible Authentication Protocol, LEAP). Также NPS
содержит ключевые компоненты для развертывания NAP в вашей сети.
Больше информации о службе роли NPS можно найти в статье Network Policy
Server (Сервер политики сети) на сайте Microsoft® TechNet.

Поверхность атаки
Служба роли NPS подвержена тем же атакам на систему безопасности, что и
любой RADIUS-сервер и прокси-сервер. Чтобы обозначить поверхность атаки этой
службы роли, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли NPS.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
роли NPS.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой роли NPS правила
брандмауэра Windows.
 Зависимости роли. Это зависимости службы роли NPS.
Подробная информация о поверхности атаки для роли NPS включена в книгу
«Справочник по поверхности атаки в Windows Server 2008», прилагаемой к данному
руководству. Оценить поверхность атаки для данной роли сервера можно при
помощи вкладки NPAS книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу роли NPS. В случае возникновения трудностей с
выполнением каких-либо пунктов контрольного списка дополнительное описание и
рекомендации можно найти в следующих разделах данной главы.
Таблица 10.1. Контрольный список настройки
Задачи настройки
Ограничить трафик на основании предлагаемых служб.
Запретить запросы от устройств, поддерживающих устаревшие версии
протокола RADIUS .
Явно задать клиентов RADIUS.
Защитить компьютеры, выполняющие NPS.
Настроить правила промежуточных брандмауэров.
Использовать IPsec для защиты соединений между NPS и RADIUS-клиентами.
Включить атрибут проверки подлинности сообщения, если не используется
аутентификация по протоколу EAP.
Защитить общие секреты RADIUS.
Использовать протокол проверки подлинности PEAP или EAP-TLS для
аутентификации клиентских компьютеров и пользователей.
Ограничить трафик на основании предлагаемых служб
Можно настроить службу роли NPS так, чтобы она отвечала только на запросы на
проверку подлинности RADIUS, только на запросы учетных данных RADIUS или на
оба типа запросов.
 Изменяя правила брандмауэра Windows, на компьютерах, которые
отвечают только на запросы на проверку подлинности, запретите UDP-
порты, отвечающие на запросы учетных данных (UDP-порты 1812 и 1645).
 Изменяя правила брандмауэра Windows, на компьютерах, которые
отвечают только на запросы учетных данных, запретите UDP-порты,
отвечающие только на запросы на проверку подлинности (UDP-порты 1813
и 1646).
Запрещая неиспользуемый трафик, вы уменьшаете поверхность атаки компьютера,
выполняющего службу роли NPS. Больше информации о настройке правил
брандмауэра Windows можно найти в разделе «Правила брандмауэра» службы
Справка и поддержка Windows Server 2008.

Запретить запросы от устройств, поддерживающих устаревшие


версии протокола RADIUS
Стандарт протокола RADIUS поддерживает два набора UDP-портов: одну пару для
текущего стандарта RADIUS (UDP-порты 1812 и 1813), и пару для поддержки
предыдущих версий (UDP-порты1645 и 1646). Если все устройства NAS
организации поддерживают текущую версию стандарта RADIUS, следует запретить
UDP-порты для поддержки устаревших версий, изменив правила брандмауэра
Windows и блокировав входящий трафик на UDP-порты 1645 и 1646. Больше
информации о настройке правил брандмауэра Windows можно найти в разделе
«Правила брандмауэра» службы Справка и поддержка Windows Server 2008.

Явно задать клиентов RADIUS


Можно настроить NPS на обмен информацией со всеми клиентами RADIUS
(например, устройствами NAS) в вашей интрасети. Это известно как общий доступ.
Однако такая конфигурация включает всех RADIUS-клиентов, в том числе и
подставных RADIUS-клиентов.
Чтобы предотвратить возможность подключения подставных RADIUS-клиентов к
NPS, необходимо явно задавать RADIUS-клиентов, используемых для удаленного
доступа. Больше информации о явном задании RADIUS-клиента приводится в
разделе «Добавление RADIUS-клиента» службы Справка и поддержка Windows
Server 2008.

Защитить компьютеры, выполняющие NPS


Компьютер-сервер, выполняющий роль NPS, для подтверждения подлинности
учетных данных удаленных пользователей должен обмениваться информацией с
контроллерами домена Доменных служб Active Directory® (AD DS). NPS-сервер
общается с AD DS напрямую, поэтому серверы, выполняющие службу роли NPS,
должны располагаться в защищенных сетях, таких как ваша интрасеть,
защищенная внешняя сеть или защищенный сетевой периметр. Больше
информации об обмене информацией между NPS и контроллерами домена можно
найти в статье Network Policy Server Infrastructure (Инфраструктура сервера
политики сети) на сайте Microsoft® TechNet.

Настроить правила промежуточных брандмауэров


RADIUS-клиенты обычно размещаются во внешней сети или на сетевом периметре
(также называемом DMZ, демилитаризованной зоной и промежуточной подсетью).
Компьютеры, выполняющие службу роли NPS, обычно находятся в защищенных
сетях, в которых между RADIUS-клиентом и NPS устанавливается один или более
брандмауэров.
Правила промежуточных брандмауэров настраиваются на разрешение
соответствующего типа трафика. Больше информации о типах допускаемого
трафика представлено в предыдущих разделах: «Ограничить трафик на основании
предлагаемых служб» и «Запретить запросы от устройств, поддерживающих
устаревшие версии протокола RADIUS».

Использовать IPsec для защиты соединений между NPS и


RADIUS-клиентами
RADIUS-клиенты обычно располагаются в менее безопасных средах по сравнению
со средой, в которой находится компьютер, выполняющий службу роли NPS. Для
предотвращения потенциальной возможности просмотра трафика между NPS и
RADIUS-клиентами необходимо защитить соединения с помощью IPsec, который
включает следующие протоколы:
 IPSec с использованием аутентификации заголовка (IPSec using
Authentication Header, IPSec AH). Этот протокол обеспечивает
целостность, проверку подлинности и неподдельность в случае
правильного выбора алгоритмов шифрования.
 IPSec с использованием защищенной инкапсуляции содержимого
(IPSec using Encapsulating Security Payload, IPSec ESP). Этот протокол
обеспечивает конфиденциальность, а также необязательную проверку
подлинности и защиту целостности, что настоятельно рекомендуется
Microsoft.
Для защиты соединений между NPS и RADIUS-клиентами может применяться
любой из приведенных протоколов через использование IPsec. Однако наивысший
уровень защиты IPsec обеспечивает в случае применения обоих протоколов.
Microsoft рекомендует использовать другие методы проверки подлинности IPsec
вместо предварительных ключей, такие как аутентификация по протоколу Kerberos
версии 5 или сертификату открытого ключа. Больше информации можно найти в
разделе IPsec на сайте TechNet.

Включить атрибут проверки подлинности сообщения, если не


используется аутентификация по протоколу EAP
При конфигурации RADIUS-клиента в NPS вы задаете IP-адрес клиента. Если
входящее сообщение запроса доступа RADIUS поступает не с заданного IP-адреса
клиента, NPS игнорирует это сообщение, защищая NPS-сервер. Однако
злоумышленники могут подделывать исходные IP-адреса.
Важно Клиентские компьютеры, такие как портативные компьютеры с беспроводным
подключением и другие компьютеры с клиентскими ОС, не являются RADIUS-клиентами.
RADIUS-клиенты – это серверы сетевого доступа, такие как точки беспроводного доступа,
коммутаторы, выполняющие аутентификацию по стандарту 802.1X, серверы виртуальной
частной сети и серверы удаленного доступа. Они являются RADIUS-клиентами, потому что
используют протокол RADIUS для связи с RADIUS-серверами, такими как серверы Network
Policy Server (NPS).
Чтобы обеспечить защиту от поддельных сообщений запроса доступа и искажений
сообщений RADIUS, можно дополнительно защитить каждое сообщение RADIUS
атрибутом RADIUS Message Authenticator (Удостоверение сообщения RADIUS).
Он описан в спецификации RFC 2869, RADIUS Extensions (Расширения RADIUS).
Включение атрибута Message Authenticator обеспечивает дополнительную
безопасность при использовании для аутентификации протоколов PAP, CHAP, MS-
CHAP и MS-CHAP v2. EAP использует атрибут Message Authenticator по
умолчанию. Поэтому если методом проверки подлинности является EAP, нет
необходимости включать атрибут Message Authenticator.
О том, как настраивать атрибут Message Authenticator для RADIUS-клиентов
сервера NPS, рассказывает раздел «Использование атрибута Message
Authenticator» службы Справка и поддержка Windows Server 2008.

Защитить общие секреты RADIUS


Общие секреты используются для проверки достоверности сообщений RADIUS. Их
рассылает устройство с поддержкой RADIUS, конфигурированное таким же общим
секретом, со всеми сообщениями, кроме сообщений запроса доступа. Общие
секреты также удостоверяют, что RADIUS-сообщение не было изменено при
передаче, и гарантируют целостность сообщения. Общий секрет используется для
шифрования некоторых атрибутов RADIUS, таких как User-Password (Пароль
пользователя) и Tunnel-Password (Пароль туннеля). Для проверки достоверности
сообщений запроса доступа можно активировать атрибут RADIUS Message
Authenticator, как для RADIUS-клиента, конфигурированного на сервере NPS, так и
для подключаемого сервера.
При создании и использовании общего секрета придерживайтесь следующих
рекомендаций и лучших практик:
 На обоих RADIUS-устройствах используйте один чувствительный к регистру
общий секрет.
 Для каждой пары RADIUS-сервер – RADIUS-клиент используйте разные
общие секреты.
 Чтобы гарантировать случайность общего секрета, генерируйте случайную
последовательность, по крайней мере, 22 символа длиной.
 Могут использоваться любые стандартные буквенно-цифровые и
специальные символы.
 Общий секрет может быть длиной до 128 символов. Чтобы защитить свой
сервер Microsoft Internet Security and Acceleration (IAS) и RADIUS-клиентов
от атак методом подбора, используйте общие секреты длинной более 22
символов.
 Чтобы защитить IAS-сервер и RADIUS-клиентов от атак перебором по
словарю, создавайте общий секрет, являющийся случайной
последовательностью букв, цифр и знаков препинания, и часто меняйте
его. Общие секреты должны содержать символы из каждой из приведенной
в следующей таблице групп:
Таблица 10.2. Символы, используемые в общих секретах
Группа Примеры
Буквы (верхнего и нижнего регистра) A, B, C и a, b, c
Цифры 0, 1, 2, 3
Символы (все символы, не являющиеся Восклицательный знак (!), звездочка
буквами или цифрами) (*), двоеточие (:)
Чем надежнее общий секрет, тем более безопасными будут атрибуты таких
сущностей как пароли и ключи шифрования, которые его используют. Примером
надежного общего секрета может быть такой секрет: 8d#>9fq4bV)H7%a3-zE13sW.
Больше информации о создании надежных общих секретов можно найти в статье
Shared secrets (Общие секреты) на сайте TechNet.

Использовать протокол проверки подлинности PEAP или EAP-


TLS для аутентификации клиентских компьютеров и
пользователей
Операционные системы на базе Windows®, к которым относится и Windows
Server 2008, поддерживают разнообразнейшие протоколы проверки подлинности.
Самыми надежными из поддерживаемых протоколов проверки подлинности
являются Защищенный протокол расширенной проверки подлинности (Protected
Extensible Authentication Protocol, PEAP) и Расширяемый протокол проверки
подлинности - безопасность транспортного уровня (Extensible Authentication Protocol
- Transport Level Security, EAP-TLS). Оба этих протокола обеспечивают безопасную
инфраструктуру для взаимной аутентификации между NPS и клиентскими
компьютерами.
EAP-TLS – протокол типа EAP, используемый для проверки подлинности с
использованием смарт-карт или сертификатов. Обмен сообщениями EAP-TLS
обеспечивает взаимную аутентификацию, согласование комплекта шифров с
защитой целостности и определение и обмен закрытыми ключами между
подключаемым клиентом и сервером проверки подлинности. EAP-TLS может
использоваться для аутентификации пользователей или компьютеров.
PEAP не определяет метода аутентификации, но он обеспечивает дополнительную
безопасность для других протоколов проверки подлинности EAP, которые могут
использовать кодированный TLS канал, предоставляемый PEAP. PEAP
применяется как метод аутентификации для клиентских компьютеров с
беспроводным подключением по стандарту 802.11, но он не поддерживается для
сетей VPN или других клиентов удаленного доступа.
PEAP может использоваться со следующими протоколами:
 EAP-MS-CHAPv2 (PEAP-EAP-MS-CHAPv2), который легче развертывать,
чем EAP-TLS, потому что проверка подлинности пользователя выполняется
по учетным данным на базе пароля (имя пользователя и пароль), а не с
использованием сертификатов или смарт-карт. Сертификат должен иметь
только IAS-сервер или RADIUS-сервер.
 EAP-TLS (PEAP-EAP-TLS), которые использует сертификаты для проверки
подлинности сервера и любые сертификаты или смарт-карты для
аутентификации пользовательских и клиентских компьютеров.
Сертификаты открытого ключа обеспечивают намного более надежный
метод проверки подлинности, чем методы, в которых используются учетные
данные на базе пароля. Чтобы использовать PEAP-EAP-TLS, вы должны
развернуть инфраструктуру открытых ключей (PKI).
Microsoft рекомендует использовать EAP-TLS или PEAP-EAP-TLS для обеспечения
максимальной безопасности аутентификации. Больше информации о протоколе
проверки подлинности PEAP можно найти в статье Protected Extensible
Authentication Protocol (PEAP) (Защищенный протокол расширенной проверки
подлинности) на Веб-сайте MSDN®. Больше информации о EAP-TLS можно найти в
статье Extensible Authentication Protocol (Протокол расширенной проверки
подлинности) на сайте TechNet.

Соответствующие параметры групповой политики


В следующей таблице представлены параметры политики, касающиеся службы
роли NPS. Используйте их в своем решении для реализации соответствующей
конфигурации. Параметры политики, приведенные в следующей таблице, должны
настраиваться как политика удаленного доступа на серверах, выполняющих службу
роли NPS.
Таблица 10.3. Политика удаленного доступа службы роли NPS
Объект политики Описание
Ignore-User-Dialin-Properties Игнорируются любые связанные с
(игнорировать свойства удаленного удаленным доступом свойства учетной
подключения пользователя) записи пользователя или группы.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих роль NPS? можно найти на сайте Microsoft.com в
следующих источниках:
 Extensible Authentication Protocol (Расширяемый протокол проверки
подлинности).
 IPsec.
 Network Policy Server.
 Network Policy Server Infrastructure.
 Protected Extensible Authentication Protocol (PEAP).
 Server and Domain Isolation (Изоляция сервера и домена).
 Shared secrets.

Служба роли маршрутизации и удаленного


доступа
С помощью службы маршрутизации и удаленного доступа можно развертывать
VPN и службы коммутируемого удаленного доступа, а также службы
маршрутизации многопротокольной связи между локальными сетями (LAN-to-LAN),
между локальными и глобальными сетями (LAN-to-WAN), виртуальных частных
сетей (VPN), а также для преобразования сетевых адресов (NAT). Служба роли
маршрутизации и удаленного доступа включает следующие подсистемы:
 Служба удаленного доступа
 Маршрутизация
Каждой подсистеме службы роли посвящен отдельный раздел.
Больше информации о службе роли маршрутизации и удаленного доступа можно
найти в материалах:
 Routing and Remote Access (Маршрутизация и удаленный доступ).
 Routing and Remote Access Blog (Блог по маршрутизации и удаленному
доступу).

Служба удаленного доступа


Служба удаленного доступа является подсистемой службы роли маршрутизации и
удаленного доступа. Она отвечает за обеспечение служб коммутируемого
удаленного доступа и VPN.
Хотя многие из представленных здесь рекомендаций применимы к службам
коммутируемого удаленного доступа, основное внимание в данном руководстве
уделяется повышению уровня защиты серверов, предоставляющих службы
удаленного доступа для VPN.
Серверы, выполняющие эту службу роли, используются как NAS-устройства
(RADIUS-клиенты) и должны быть конфигурированы на использование служб
проверки подлинности и аудита, предоставляемых NPS. Больше информации о
повышении уровня защиты серверов, выполняющих службу роли NPS, можно найти
в данной главе выше в разделе «Служба роли NPS».
Больше информации о службе удаленного доступа представлено по следующим
ссылкам:
 Routing and Remote Access.
 Routing and Remote Access Blog.

Поверхность атаки
Служба удаленного доступа подвержена тем же атакам на систему безопасности,
что и любые пограничные службы сети, и службы VPN, в частности. К таким атакам
относятся попытки определения операционной системы VPN, угадывание имени
пользователя, автономный подбор пароля, атаки с перехватом и т.д. Чтобы
обозначить поверхность атаки этой службы роли, необходимо определить
следующее:
 Установленные файлы. Это файлы, установленные как часть службы
удаленного доступа.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
удаленного доступа.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой удаленного доступа
правила брандмауэра Windows.
Примечание Некоторые из используемых службой удаленного доступа правила
брандмауэра Windows деактивированы. Для их активации необходимо использовать
мастер Настроить и включить маршрутизацию и удаленный доступ (Configure
and Enable Routing and Remote Access). Больше информации о запуске этого мастера
можно найти в разделе «Установка и включение службы маршрутизации и удаленного
доступа» службы Справка и поддержка Windows Server 2008.
 Зависимости роли. Это зависимости службы удаленного доступа.
Подробная информация о поверхности атаки для службы удаленного доступа
включена в книгу «Справочник по поверхности атаки в Windows Server 2008»,
прилагаемой к данному руководству. Оценить поверхность атаки для данной роли
сервера можно при помощи вкладки NPAS книги в разделах, соответствующих
каждому из пунктов предыдущего списка.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу удаленного доступа. В случае возникновения трудностей с
выполнением каких-либо пунктов контрольного списка дополнительное описание и
рекомендации можно найти в следующих разделах данной главы.
Таблица 10.4. Контрольный список настройки
Задачи настройки
Защитить компьютеры, выполняющие службу удаленного доступа.
Настроить правила промежуточных брандмауэров.
Сделать компьютеры, выполняющие службу удаленного доступа, участниками
леса внешней сети.
Использовать IPsec для защиты соединений между службой удаленного
доступа и NPS.
Защитить общие секреты RADIUS.
Требовать многофакторной аутентификации для удаленных пользователей.
Ограничить круг пользователей, имеющих возможность удаленного доступа к
вашей интрасети.
Использовать для аутентификации пользователей и клиентских компьютеров
удаленного доступа протокол проверки подлинности PEAP или EAP-TLS.
Обеспечить безопасность связи клиентов удаленного доступа.
Задачи настройки
Использовать NPS для обеспечения централизованной аутентификации
пользователей.

Защитить компьютеры, выполняющие службу удаленного


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

Настроить правила промежуточных брандмауэров


Компьютеры, выполняющие службу удаленного доступа, обычно располагаются в
вашей внешней сети или на сетевом периметре. Компьютеры, выполняющие
службу роли NPS, как правило, размещаются в защищенных сетях. Между
компьютерами, выполняющими службы роли Служба удаленного доступа и NPS,
устанавливается один или более брандмауэров.
Правила промежуточных брандмауэров настраиваются на разрешение
соответствующего типа трафика. Больше информации о типах допускаемого
трафика представлено ранее в данной главе в разделах «Ограничить трафик на
основании предлагаемых служб» и «Запретить запросы от устройств,
поддерживающих устаревшие версии протокола RADIUS».

Сделать компьютеры, выполняющие службу удаленного доступа,


участниками леса внешней сети
Компьютеры, выполняющие службу удаленного доступа, обычно располагаются в
средах, менее безопасных, чем те среды, в которых находятся компьютеры,
выполняющие службу роли NPS, например, на сетевом периметре или во внешней
сети. Во многих внешних сетях есть лес AD DS (лес внешней сети), который
управляет учетными данными, используемыми службами, выполняющимися на
компьютерах внешней сети.
Разверните компьютеры, выполняющие службу удаленного доступа, как участников
леса внешней сети. Обычно между лесом внешней сети и лесом AD DS вашей
интрасети устанавливается одностороннее отношение доверия.

Использовать IPsec для защиты соединений между службой


удаленного доступа и NPS
Компьютеры, выполняющие службу удаленного доступа, обычно располагаются в
менее безопасных средах по сравнению со средой, в которой находится
компьютер, выполняющий службу роли NPS. Для предотвращения потенциальной
возможности просмотра трафика между компьютерами, выполняющими службу
роли Маршрутизация и удаленный доступ и NPS, необходимо защитить
соединения с помощью IPsec. Больше информации об обеспечении безопасности
обмена информацией между службами Маршрутизация и удаленный доступ и NPS
можно найти в данной главе выше в разделе «Использовать IPsec для защиты
соединений между NPS и RADIUS-клиентами».

Защитить общие секреты RADIUS


Посредством общих секретов RADIUS выполняется проверка того, что RADIUS-
сообщения, кроме сообщения запроса доступа, были отправлены устройством с
поддержкой RADIUS, конфигурированным таким же общим секретом. Служба
удаленного доступа выступает в роли NAS-устройства (RADIUS-клиент), которое
связывается с NPS (RADIUS-сервер). Больше информации о защите общих
секретов RADIUS представлено ранее в данной главе в разделе «Защитить общие
секреты RADIUS».

Требовать многофакторной аутентификации для удаленных


пользователей
Существует следующая классификация методов аутентификации пользователя:
 Пользователь располагает специальной информацией, такой как пароль,
парольная фраза или персональный идентификационный номер (PIN).
 Пользователь имеет специальное устройство, такое как смарт-карта,
маркер доступа, маркер программы или мобильный телефон.
 Пользователь предоставляет биометрический параметр, такое как
отпечаток пальца или узор сетчатки глаза, последовательность ДНК,
распознавание подписи или голоса, уникальные биоэлектрические сигналы
или другие биометрические показатели.
Часто в организациях используются сочетания этих методов. Например, платежная
карта и PIN, такой способ еще называют двухфакторной аутентификацией.
Аутентификация пользователей может проводиться только по паролю, но для
повышения уровня аутентификации в организации может использоваться
многофакторная аутентификация. В многофакторной аутентификации обычно
принимает участие физическое устройство, такое как устройство чтения смарт-
карт, USB-маркер доступа или устройство считывания отпечатков пальцев. Выбор
физических устройств для многофакторной аутентификации обычно
осуществляется на базе требований, не связанных с безопасностью.
Например, ваша организация могла бы потребовать, чтобы смарт-карты
пользователей включали идентификацию по фотографии, поскольку на смарт-карте
могут быть напечатаны фото и имя владельца. Однако для использования смарт-
карты необходимо устройство для чтения, что ведет к дополнительным расходам.
USB-маркер может включать флэш-память для хранения документов и файлов, и
пользователи могут подключать USB-маркер в существующие USB-порты своих
компьютеров.
Для учетных записей, обладающих привилегиями удаленного доступа, Microsoft
рекомендует применять двухфакторную или многофакторную аутентификацию.
Ограничить круг пользователей, имеющих возможность
удаленного доступа к вашей интрасети
В большинстве сценариев необходимость в удаленном доступе имеет только
определенная подгруппа пользователей. Следует ограничить количество
пользователей, имеющих возможность удаленного доступа к вашей интрасети,
исходя из индивидуальных деловых нужд каждого из них. Как дополнительный
уровень предосторожности рассмотрите возможность реализации следующих
вариантов:
 Учредить строгий процесс утверждения, при котором рассматривается
каждый запрос пользователя на удаленный доступ. Например,
запросы на удаленный доступ должны быть утверждены
руководством.
 Автоматически выключать возможность удаленного доступа по
прошествии определенного количества времени. Такой подход
вынуждает выполнять повторную оценку деловых нужд для всех
предоставленных пользователям прав удаленного доступа.

Использовать для аутентификации пользователей и клиентских


компьютеров удаленного доступа протокол проверки
подлинности PEAP или EAP-TLS
Операционные системы на базе Windows®, к которым относится и Windows
Server 2008, поддерживают разнообразнейшие протоколы проверки подлинности.
Самыми надежными из поддерживаемых протоколов проверки подлинности
являются Защищенный протокол расширенной проверки подлинности (PEAP) и
Расширяемый протокол проверки подлинности - безопасность транспортного
уровня (EAP-TLS).
EAP-TLS – протокол типа EAP, используемый для проверки подлинности с
использованием смарт-карт или сертификатов. Обмен сообщениями EAP-TLS
обеспечивает взаимную аутентификацию, согласование комплекта шифров с
защитой целостности и определение и обмен закрытыми ключами между
подключаемым клиентом и сервером проверки подлинности. EAP-TLS может
использоваться для аутентификации пользователей или компьютеров.
PEAP не определяет метода аутентификации, но он обеспечивает дополнительную
безопасность для других протоколов проверки подлинности EAP, которые могут
использовать кодированный TLS канал, предоставляемый PEAP. PEAP
применяется как метод аутентификации для клиентских компьютеров с
беспроводным подключением по стандарту 802.11, но он не поддерживается для
сетей VPN или других клиентов удаленного доступа.
PEAP может использоваться со следующими протоколами:
 EAP-MS-CHAPv2 (PEAP-EAP-MS-CHAPv2), который легче развертывать,
чем EAP-TLS, потому что проверка подлинности пользователя выполняется
по учетным данным на базе пароля (имя пользователя и пароль), а не с
использованием сертификатов или смарт-карт. Сертификат должен иметь
только IAS-сервер или RADIUS-сервер.
 EAP-TLS (PEAP-EAP-TLS), которые использует сертификаты для проверки
подлинности сервера и любые сертификаты или смарт-карты для
аутентификации пользовательских и клиентских компьютеров.
Сертификаты открытого ключа обеспечивают намного более надежный
метод проверки подлинности, чем методы, в которых используются учетные
данные на базе пароля. Чтобы использовать PEAP-EAP-TLS, вы должны
развернуть инфраструктуру открытых ключей (PKI).
Microsoft рекомендует использовать EAP-TLS или PEAP-EAP-TLS для обеспечения
максимальной безопасности аутентификации. Больше информации о протоколе
проверки подлинности PEAP можно найти в статье Protected Extensible
Authentication Protocol (PEAP). Больше информации о EAP-TLS представлено в
статье Extensible Authentication Protocol.

Обеспечить безопасность связи клиентов удаленного доступа


Клиенты удаленного доступа обычно подключаются к компьютерам, выполняющим
службу удаленного доступа, по Интернету. Это соединение должно быть защищено
путем обеспечения безопасности трафика между компьютерами, выполняющими
службу удаленного доступа, и клиентами удаленного доступа. Обезопасить этот
трафик можно следующими методами:
 IPsec. Для обеспечения безопасности трафика используйте протоколы
IPSec AH и IPSec ESP. Больше информации представлено в разделе IPsec
на сайте Microsoft TechNet.
 Протокол безопасного туннелирования сокетов (Secure Sockets
Tunneling Protocol, SSTP). SSTP – это новая форма туннеля VPN с
возможностями, позволяющими трафику проходить через брандмауэры,
блокирующие трафик PPTP и L2TP/IPsec. SSTP обеспечивает механизм
инкапсуляции PPP-трафика по SSL-каналу протокола HTTPS.
Использование PPP обеспечивает поддержку методов строгой проверки
подлинности, таких как EAP-TLS. Применение HTTPS означает, что трафик
будет направлен через TCP-порт 443, обычно используемый для Веб-
доступа. Протокол безопасных соединений (SSL) обеспечивает
безопасность транспортного уровня с улучшенным согласованием ключей,
шифрованием и контролем целостности. Больше информации можно найти
в Step-by-Step Guide: Deploying SSTP Remote Access (Пошаговое
руководство по развертыванию удаленного доступа по протоколу SSTP) на
странице Windows Server 2008 Step-by-Step Guides (Пошаговые руководства
Windows Server 2008) Центра загрузки Microsoft.

Использовать NPS для обеспечения централизованной


аутентификации пользователей
Служба удаленного доступа может проверять подлинность пользовательских
учетных записей в следующих местах:
 В локальной базе данных SAM на компьютере, выполняющем службу
удаленного доступа. Этот метод является нерекомендуемым, потому что в
случае незаконного проникновения на сервер локальная база данных SAM
может быть подвергнута атаке.
 В домене AD DS, участником которого является компьютер,
выполняющий службу удаленного доступа. Этот метод является
нерекомендуемым, потому что в случае незаконного проникновения на
сервер злоумышленник может получить доступ к учетным записям домена.
 В домене AD DS, подключенном через компьютер, выполняющий
службу роли NPS. Этот метод является рекомендованным, потому что
в данном случае между компьютером, выполняющим службу
удаленного доступа, и доменом AD DS имеется дополнительный уровень
абстракции. Проверка подлинности учетных данных в домене AD DS может
выполняться только компьютером, выполняющим службу роли NPS. В
случае незаконного проникновения на компьютер, выполняющий службу
удаленного доступа, доступной оказывается очень незначительная часть
конфиденциальных данных.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли Служба
удаленного доступа. Однако можно задать параметры политики NPS (RADIUS),
чтобы обеспечить безопасность пользователей, выполняющих удаленный доступ к
вашей сети.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих роль службы удаленного доступа, можно найти в
следующих источниках на сайте Microsoft.com:
 IPsec.
 Routing and Remote Access.
 Routing and Remote Access Blog.
 Server and Domain Isolation.
 Windows Server 2008 Step-by-Step Guides: Step-by-Step Guide: Deploying
SSTP Remote Access.
 Step-by-Step Guide: Deploying SSTP Remote Access.
 Virtual Private Networks (Виртуальные частные сети).
 Virtual Private Networking with Windows Server 2003: Deploying Remote Access
VPNs (Организация виртуальных частных сетей с Windows Server 2003:
развертывание VPN удаленного доступа).

Служба роли маршрутизация


Служба роли маршрутизация является подсистемой службы роли Маршрутизация
и удаленный доступ. Служба маршрутизации обеспечивает пограничные службы
маршрутизации (edge-of-network routing services). Обычно эти службы
маршрутизации обеспечивают соединения точка-точка между географически
удаленными узлами через использование соединений по телефонной линии или
VPN вместо традиционной маршрутизации.
Больше информации о службе роли Маршрутизация можно найти в следующих
ресурсах:
 Routing and Remote Access.
 Routing and Remote Access Blog.
Поверхность атаки
Служба маршрутизации подвержена тем же атакам на систему безопасности, что и
любые пограничные службы маршрутизации. К таким атакам относятся
сканирование портов, транзитный трафик, атаки с перехватом и т.д. Чтобы
обозначить поверхность атаки этой службы роли, необходимо определить
следующее:
 Установленные файлы. Это файлы, установленные как часть службы
маршрутизации.
 Выполняющиеся службы. Это сервисы, выполняющиеся как часть службы
маршрутизации.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службами, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это правила брандмауэра Windows, используемые
службой маршрутизации.
Примечание Некоторые из используемых службой удаленного доступа правила
брандмауэра Windows деактивированы. Для их активации необходимо использовать
мастер Настроить и включить маршрутизацию и удаленный доступ
(Configure and Enable Routing and Remote Access). Больше информации о
запуске этого мастера можно найти в разделе «Установка и активация службы
маршрутизации и удаленного доступа» службы Справка и поддержка Windows
Server 2008.
 Зависимости роли. Это зависимости службы маршрутизации.
Подробная информация о поверхности атаки для службы маршрутизации включена
в книгу «Справочник по поверхности атаки в Windows Server 2008», прилагаемой к
данному руководству. Оценить поверхность атаки для данной роли сервера можно
при помощи вкладки NPAS книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности для повышения уровня защиты серверов, выполняющих службу роли
Маршрутизация. При возникновении каких-либо трудностей по выполнению этих
задач, обратитесь к следующим разделам данной главы за дополнительной
информацией и рекомендациями.
Таблица 10.5. Контрольный список настройки
Задачи настройки
Разместить компьютеры, выполняющие службу роли маршрутизации, на
сетевом периметре.
Настроить правила промежуточных брандмауэров.
Ограничить соединения маршрутизации известными конечными точками.
Сделать компьютеры, выполняющие службу маршрутизации, участниками леса
внешней сети.
Использовать безопасные туннели для обеспечения безопасности связи между
маршрутизаторами.
Требовать многофакторную аутентификацию для проверки подлинности
маршрутизаторов.
Использовать для аутентификации маршрутизаторов протокол проверки
подлинности PEAP или EAP-TLS.

Разместить компьютеры, выполняющие службу роли


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

Настроить правила промежуточных брандмауэров


Компьютеры, выполняющие службу маршрутизации, обычно размещаются во
внешней сети или на сетевом периметре. Маршрутизаторы устанавливают
соединения со следующими ресурсами:
 Другими маршрутизаторами через внешние брандмауэры,
обеспечивающие вход и выход в интрасеть. Для этих брандмауэров
необходимо активировать соответствующие порты для одного из
следующих протоколов туннелирования:
o Туннельный протокол точка-точка (Point-to-Point Tunneling
Protocol, PPTP). Этот протокол использует TCP-порт 1723 и
протокол GRE (ID протокола 47)
o Туннельный протокол второго уровня (Layer 2 Tunneling
Protocol, L2TP). Этот протокол использует UDP-порт 1701 для
L2TP, UDP-порт 500 для обмена Интернет-ключами (Internet Key
Exchange, IKE) в IPsec и UDP 4500 для преобразования сетевых
адресов (Network Address Translation, NAT-T) с использованием
IPsec.
o SSTP. Этот протокол использует TCP-порт 443 для безопасного
туннелирования SSL.
o Туннельный режим IPsec (IPsec tunnel mode). Этот протокол
использует UDP-порт 500 для IKE в IPsec и UDP 4500 для IPsec
NAT-T.
 Интрасетью через внутренние брандмауэры, обеспечивающие вход и
выход в интрасеть. Для этих брандмауэров необходимо активировать все
протоколы, которые предполагается использовать. Или, как
альтернативный вариант, вместо подключения к внутренним брандмауэрам
сетевой интерфейс маршрутизатора, используемый для соединений в
интрасети, можно подключать прямо к интрасети.

Ограничить соединения маршрутизации известными конечными


точками
Типовым сценарием для службы маршрутизации является маршрутизация точка-
точка между филиалами организации. В таких сценариях конечные точки
маршрутов точка-точка четко определены и их количество ограничено. Служба
роли Маршрутизация и внешние брандмауэры должны быть конфигурированы так,
чтобы возможен был только трафик между конечными точками маршрутов точка-
точка.

Сделать компьютеры, выполняющие службу маршрутизации,


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

Использовать безопасные туннели для обеспечения


безопасности связи между маршрутизаторами
Компьютеры, выполняющие службу маршрутизации, обмениваются информацией с
другими компьютерами, выполняющими службу маршрутизации, по Интернету или
другим открытым сетям. Большинство организаций развертывают службу
маршрутизации для обеспечения безопасной маршрутизации точка-точка между
филиалами организации.
Безопасность трафика между маршрутизаторами может быть обеспечена
следующими протоколами:
 PPTP. Туннельный протокол VPN на базе Протокола точка-точка (Point-to-
Point Protocol, PPP), который обеспечивает возможность шифрования IP-
трафика с последующей инкапсуляцией в IP-заголовок для отправки по
частным или общедоступным IP-сетям. Больше информации представлено
в разделе MSDN Understanding Point-to-Point Tunneling Protocol (PPTP)
(Понимание туннельного протокола точка-точка).
 L2TP. Туннельный протокол VPN, который, как и PPTP, также основан на
протоколе PPP. L2TP обеспечивает возможность шифрования трафика с
последующей передачей на любом носителе, поддерживающем протоколы
доставки датаграмм точка-точка, такие как IP, X.25, ретрансляция кадров
(Frame Relay, FR) или режим асинхронной передачи (asynchronous transfer
mode, ATM). Шифрование для L2TP в IPsec обычно обеспечивает ESP.
 SSTP. Новый вид туннеля VPN с функциями, обеспечивающими
возможность передачи трафика через брандмауэры, блокирующие трафик
PPTP и L2TP/IPsec. SSTP обеспечивает механизм инкапсуляции PPP-
трафика по SSL-каналу HTTPS-протокола. Использование PPP
обеспечивает поддержку методов строгой проверки подлинности, таких как
EAP-TLS. HTTPS направляет трафик через TCP-порт 443, который обычно
используется для Веб-доступа. Протокол безопасных соединений (SSL)
обеспечивает безопасность транспортного уровня с улучшенным
согласованием ключей, шифрованием и контролем целостности. Больше
информации можно найти в «Step-by-Step Guide: Deploying SSTP Remote
Access» на странице Windows Server 2008 Step-by-Step Guides Центра
загрузки Microsoft.
 Туннельный режим IPsec. При маршрутизации протокол IPsec обычно
используется в сочетании с L2TP для шифрования. Однако IPsec может
выступать в роли туннельного протокола. IPsec в туннельном режиме
обеспечивает возможность шифрования IP-пакетов с последующей
инкапсуляцией в IP-заголовок для отправки по закрытым или
общедоступным сетям. Больше информации представлено в разделе IPsec
сайта TechNet.
Каждый из методов защиты трафика обеспечивает взаимную аутентификацию
маршрутизаторов и шифрование передаваемых пакетов.

Требовать многофакторную аутентификацию для проверки


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

Использовать для аутентификации маршрутизаторов протокол


проверки подлинности PEAP или EAP-TLS
Операционные системы на базе Windows®, к которым относится и Windows
Server 2008, поддерживают разнообразнейшие протоколы проверки подлинности.
Самыми надежными из поддерживаемых протоколов проверки подлинности
являются Защищенный протокол расширенной проверки подлинности (PEAP) и
Расширяемый протокол проверки подлинности - безопасность транспортного
уровня (EAP-TLS).
Оба этих протокола обеспечивают безопасную инфраструктуру для взаимной
аутентификации компьютеров, выполняющих службу маршрутизации. Протокол
PEAP не обеспечивает такой же безопасности, как протокол транспортного уровня
(Transport Level Security, TLS), но преимущество PEAP в применении проверки
подлинности по имени пользователя/паролю вместо аутентификации по
сертификату клиента.
Больше информации о протоколе проверки подлинности PEAP можно найти в
статье Protected Extensible Authentication Protocol (PEAP) на Веб-сайте MSDN®.
Больше информации о EAP-TLS можно найти в статье Extensible Authentication
Protocol на сайте TechNet.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли Маршрутизация.
Однако можно задать параметры политики NPS (RADIUS), чтобы обеспечить
безопасность аутентификации, используемой между маршрутизаторами.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службу маршрутизации, можно найти на сайте
Microsoft.com в следующих источниках:
 Configuring Firewalls (Настройка брандмауэров).
 Extensible Authentication (Расширяемая проверка подлинности).
 How to configure an L2TP/IPSec connection by using Preshared Key
Authentication (Как настроить соединение L2TP/IPSec с помощью проверки
подлинности с предварительным ключом).
 IPsec.
 Protected Extensible Authentication (Защищенная расширенная проверка
подлинности).
 Routing and Remote Access.
 Routing and Remote Access Blog.
 Server and Domain Isolation.
 Windows Server 2008 Step-by-Step Guides: Step-by-Step Guide: Deploying
SSTP Remote Access.
 Understanding Point-to-Point Tunneling Protocol (PPTP).
 Virtual Private Networks.
 Virtual Private Networking with Windows Server 2003: Deploying Site-to-Site
VPNs (Организация виртуальных частных сетей с Windows Server 2003:
развертывание VPN типа «сеть-сеть»).

Служба роли HRA


Центр регистрации работоспособности (HRA) – это компонент NAP, выдающий
сертификаты безопасности для клиентов, проходящих проверку политики
работоспособности клиента, которая осуществляется NPS с помощью протокола
Состояние работоспособности клиента (Statement of Health, SoH). В настоящее
время HRA используется только в случаях, когда NAP осуществляется посредством
IPsec.
Однако эту возможность можно расширить для выдачи сертификатов безопасности
клиента для сети для других применений в будущем. С помощью HRA можно
реализовывать особые требования к работоспособности через отказ выдачи
сертификатов или требование установления подключений IPsec.
В подобной конфигурации сервер, выполняющий службу роли HRA, выступает в
роли точки NAP (NAP enforcement point). Другими точками NAP являются:
 Серверы VPN с поддержкой NAP
 Серверы DHCP с поддержкой NAP
 Коммутаторы Ethernet, поддерживающие протокол проверки подлинности
802.1X или динамические назначения VLAN.
 Точки беспроводного доступа, поддерживающие протокол проверки
подлинности 802.1X
Больше информации о HRA представлено на сайте TechNet в разделах HRA Server
Role (Роль сервера HRA) и Health Registration Authority (HRA) (Центр регистрации
работоспособности). Дополнительную информацию по точкам NAP, HRA и NAP
можно найти в материалах Network Access Protection.

Поверхность атаки
Служба роли HRA подвержена тем же атакам на систему безопасности, что и
любое расширение ISAPI, выполняющееся в Internet Information Services (IIS),
которые предоставляются ролью Веб-сервер (IIS). Чтобы обозначить поверхность
атаки этой службы роли, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли HRA.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
роли HRA.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой роли HRA правила
брандмауэра Windows.
 Зависимости роли. Это зависимости службы роли HRA.
Подробная информация о поверхности атаки для роли HRA включена в книгу
«Справочник по поверхности атаки в Windows Server 2008», прилагаемой к данному
руководству. Оценить поверхность атаки для данной роли сервера можно при
помощи вкладки NPAS книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию службы роли HRA для защиты сервера от
злоумышленных атак. Приведенные ниже рекомендации предполагают, что на
странице Выбор служб роли Мастера добавления ролей выбрана только опция
HRA. Рекомендации для других служб роли не включены.
Контрольный список настройки
В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу роли HRA. В случае возникновения трудностей с
выполнением каких-либо пунктов контрольного списка дополнительное описание и
рекомендации можно найти в следующих разделах данной главы.
Таблица 10.6. Контрольный список настройки
Задачи настройки
Разместить компьютеры, выполняющие службу роли HRA в интрасети.
Сделать компьютеры, выполняющие службу роли HRA, участниками леса
интрасети.
Обеспечить безопасность связи службы роли HRA с помощью IPsec.
Использовать шифрование SSL для защиты запросов и откликов клиента HRA.
Выделить компьютер для выполнения службы роли HRA.
Разрешить получение сертификатов безопасности клиента для сети только
аутентифицированным пользователям.
Выполнить рекомендации по повышению уровня защиты для роли сервера
Веб-службы (IIS).

Разместить компьютеры, выполняющие службу роли HRA в


интрасети
Сервер, выполняющий службу роли HRA, получает сертификаты безопасности
клиента для сети от лица клиентов NAP, чтобы обеспечить их соответствие
требованиям работоспособности. Эти сертификаты безопасности аутентифицируют
NAP-клиентов при установлении защищенных IPsec-соединений с другими NAP-
клиентами в интрасети.
Кроме того, служба роли HRA должна обмениваться информацией с
компьютерами, выполняющими роли Центр сертификации и NPS. В среде домена
службе роли HRA необходимо устанавливать соединение также и с глобальным
каталогом Active Directory для проверки подлинности учетных данных клиента.
Поэтому Microsoft рекомендует размещать компьютер, выполняющий службу роли
HRA, в защищенной подсети интрасети.

Сделать компьютеры, выполняющие службу роли HRA,


участниками леса интрасети
Компьютеры, выполняющие службу роли HRA, обычно располагаются в
защищенных подсетях интрасети. Службу роли HRA можно развернуть на
изолированном компьютере, но Microsoft рекомендует развертывать компьютеры,
выполняющие службу роли HRA, как участников домена в лесу вашей интрасети.
Обеспечить безопасность связи службы роли HRA с помощью
IPsec
Компьютеры, выполняющие службу роли HRA, устанавливают соединения с
компьютерами, выполняющими роли Центр сертификации и NPS. Чтобы
предотвратить потенциальную возможность просмотра трафика между этими
компьютерами, связь между ними должна быть защищена IPsec. Больше
информации по обеспечению безопасности путем использования IPsec можно
найти в разделе IPsec сайта TechNet.

Использовать шифрование SSL для защиты запросов и откликов


клиента HRA
Служба роли HRA обменивается информацией с клиентскими компьютерами по
протоколам HTTP или HTTPS. Microsoft рекомендует всегда конфигурировать HRA
на использование протокола HTTPS для связи с клиентскими компьютерами. Такая
конфигурация обеспечивает шифрование трафика между службой роли HRA и
клиентскими компьютерами. Более подробно об этом рассказывается в подразделе
«Сертификаты для шифрования SSL» раздела «Общее представление о
требованиях к проверке подлинности для центра регистрации работоспособности»
службы Справка и поддержка Windows Server 2008.

Выделить компьютер для выполнения службы роли HRA


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

Разрешить получение сертификатов безопасности клиента для


сети только аутентифицированным пользователям
При установке службы роли HRA могут быть настроены требования проверки
подлинности для HRA. HRA можно конфигурировать так, чтобы получать
сертификаты работоспособности только аутентифицированные участники домена.
Также могут быть заданы такие параметры HRA, что получать сертификаты
работоспособности смогут все пользователи, включая анонимных.
Предоставляйте сертификаты работоспособности в своей интрасети только
аутентифицированным пользователям. Выдача таких сертификатов анонимным
пользователям допуcкается только в редких случаях, когда необходимо
предоставить доступ к части сети. Например, вы хотите обеспечить, чтобы
посетители, будучи подключенными к вашей интрасети, имели доступ в Интернет
как анонимные пользователи.
Больше информации по этой теме представлено в разделе «Общее представление
о требованиях к проверке подлинности для центра регистрации
работоспособности» службы Справка и поддержка Windows Server 2008.
Выполнить рекомендации по повышению уровня защиты для
роли сервера Веб-службы (IIS)
Данная служба роли использует IIS 7.0, поэтому обязательно должны быть
выполнены рекомендации по повышению уровня защиты для роли сервера Веб-
службы (IIS). Больше информации о повышении уровня защиты роли сервера Веб-
службы (IIS) можно найти в Главе 6 «Повышение уровня защиты Веб-сервисов»
данного руководства.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли HRA.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службу роли HRA, можно найти на сайте Microsoft.com в
следующих источниках:
 Часть «Сертификаты для шифрования SSL» раздела «Общее
представление о требованиях к проверке подлинности для центра
регистрации работоспособности» службы Справка и поддержка Windows
Server 2008.
 Health Registration Authority (HRA).
 HRA Server Role.
 IPsec.
 Network Access Protection.
 Server and Domain Isolation.
 Раздел «Общее представление о требованиях к проверке подлинности для
центра регистрации работоспособности» службы Справка и поддержка
Windows Server 2008.

Служба роли HCAP


Протокол авторизации учетных данных узла (HCAP) позволяет интегрировать
основанное на NAP решение с решениями на базе Cisco Network Admission Control
(NAC). При развертывании HCAP с NPS и NAP, NPS может выполнять оценку
работоспособности и проверку подлинности устройств сетевого доступа с
поддержкой Cisco NAC (таких как коммутаторы, маршрутизаторы, точки
беспроводного доступа и концентраторы VPN).
В данной конфигурации сервер, выполняющий службу роли HCAP, соединяется с
сервером управления доступом Cisco Secure Access Control Server (ACS), который
подтверждает подлинность устройства с поддержкой NAC. NPS занимается
проверкой достоверности атрибутов состояния работоспособности клиента и
назначением общего состояния работоспособности для устройств с поддержкой
NAC в гетерогенной архитектуре.
Больше информации о точках NAP, HCAP и NAP смотрите в разделе Network
Access Protection сайта TechNet. Больше информации о NAC можно найти в
разделе Network Admission Control (Управление доступом в сеть) на Веб-сайте
Cisco.

Поверхность атаки
Служба роли HCAP подвержена тем же атакам на систему безопасности, что и
любое расширение ISAPI, выполняющееся в Internet Information Services (IIS),
которые предоставляются ролью Веб-сервер (IIS).
Чтобы обозначить поверхность атаки этой службы роли, необходимо определить
следующее:
 Установленные файлы. Это файлы, установленные как часть службы
роли HCAP.
 Выполняющиеся службы. Это службы, выполняющиеся как часть службы
роли HCAP.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службой, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые службой роли HCAP правила
брандмауэра Windows.
 Зависимости роли. Это зависимости службы роли HCAP.
Подробная информация о поверхности атаки для роли HCAP включена в книгу
«Справочник по поверхности атаки в Windows Server 2008», прилагаемой к данному
руководству. Оценить поверхность атаки для данной роли сервера можно при
помощи вкладки NPAS книги в разделах, соответствующих каждому из пунктов
предыдущего списка.

Меры по обеспечению безопасности


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

Контрольный список настройки


В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих службу роли HCAP. В случае возникновения трудностей с
выполнением каких-либо пунктов контрольного списка дополнительное описание и
рекомендации можно найти в следующих разделах данной главы.
Таблица 10.7. Контрольный список настройки
Задачи настройки
Разместить компьютеры, выполняющие службу роли HCAP, в интрасети.
Сделать компьютеры, выполняющие службу роли HCAP, участниками леса
интрасети.
Задачи настройки
Обеспечить безопасность связи службы роли HCAP с помощью IPsec.
Использовать шифрование SSL для защиты запросов и откликов клиента HCAP.
Выделить компьютер для выполнения службы роли HCAP.
Выполнить рекомендации по повышению уровня защиты для роли сервера
Веб-службы (IIS).

Разместить компьютеры, выполняющие службу роли HCAP, в


интрасети
Компьютер-сервер, выполняющий службу роли HCAP, получает сертификаты
работоспособности от лица серверов Cisco Secure ACS, чтобы обеспечить их
соответствие требованиям работоспособности. Эти сертификаты безопасности
аутентифицируют Cisco Secure ACS при установлении защищенных IPsec
подключений с другими устройствами с поддержкой NAP и NAP-клиентами в
интрасети.
Кроме того, служба роли HCAP должна обмениваться информацией с
компьютерами, выполняющими роли Центр сертификации и NPS. В среде домена
службе роли HCAP необходимо устанавливать соединение также и с глобальным
каталогом Active Directory для проверки подлинности учетных данных клиента.
Поэтому Microsoft рекомендует размещать компьютер, выполняющий службу роли
HCAP, в защищенной подсети вашей интрасети.

Сделать компьютеры, выполняющие службу роли HCAP,


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

Обеспечить безопасность связи службы роли HCAP с помощью


IPsec
Компьютеры, выполняющие службу роли HCAP, устанавливают соединения с
компьютерами, выполняющими роли Центр сертификации и NPS. Чтобы
предотвратить потенциальную возможность просмотра трафика между этими
компьютерами, Microsoft рекомендует защитить связь между ними с помощью
IPsec. Больше информации по обеспечению безопасности путем использования
IPsec можно найти в разделе IPsec сайта TechNet.

Использовать шифрование SSL для защиты запросов и откликов


клиента HCAP
Служба роли HCAP обменивается информацией с клиентскими компьютерами по
протоколам HTTP или HTTPS. Microsoft рекомендует всегда конфигурировать HCAP
на использование протокола HTTPS для связи с клиентскими компьютерами. Такая
конфигурация обеспечивает шифрование трафика между службой роли HCAP и
клиентскими компьютерами.
Больше информации можно найти в подразделе «Сертификаты для шифрования
SSL» раздела «Общее представление о требованиях к проверке подлинности для
центра регистрации работоспособности» службы Справка и поддержка Windows
Server 2008.

Выделить компьютер для выполнения службы роли HCAP


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

Выполнить рекомендации по повышению уровня защиты для


роли сервера Веб-службы (IIS)
Данная служба роли использует IIS 7.0, поэтому обязательно должны быть
выполнены рекомендации по повышению уровня защиты для роли сервера Веб-
службы (IIS). Больше информации о повышении уровня защиты роли сервера Веб-
службы (IIS) можно найти в Главе 6 «Повышение уровня защиты Веб-сервисов»
данного руководства.

Соответствующие параметры групповой политики


Не существует параметров групповой политики для службы роли HCAP.

Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службу роли HCAP, можно найти на сайте Microsoft.com в
следующих источниках:
 Часть «Сертификаты для шифрования SSL» раздела «Общее
представление о требованиях к проверке подлинности для центра
регистрации работоспособности» службы Справка и поддержка Windows
Server 2008.
 Cisco Network (Сеть Cisco) в файле формата Portable Document Format
(PDF).
 IPsec.
 Network Access Protection.
 Network Policy Server.
 Server and Domain Isolation.
 Раздел «Общее представление о требованиях к проверке подлинности для
центра регистрации работоспособности» службы Справка и поддержка
Windows Server 2008.
Дополнительные ресурсы
Более подробные сведения из лучших практик по повышению уровня защиты
серверов, выполняющих службы роли NPAS, можно найти на сайте Microsoft.com в
следующих источниках:
 Для службы роли NPS:
o Extensible Authentication Protocol.
o IPsec.
o Network Policy Server.
o Network Policy Server Infrastructure.
o Protected Extensible Authentication Protocol (PEAP).
o Server and Domain Isolation.
o Shared secrets.
 Для службы роли Служба удаленного доступа:
o IPsec.
o Routing and Remote Access.
o Routing and Remote Access Blog.
o Server and Domain Isolation.
o Windows Server 2008 Step-by-Step Guides: Step-by-Step Guide:
Deploying SSTP Remote Access.
o Step-by-Step Guide: Deploying SSTP Remote Access.
o Virtual Private Networks.
o Virtual Private Networking with Windows Server 2003: Deploying
Remote Access VPNs.
 Для службы роли Маршрутизация:
o Configuring Firewalls.
o Extensible Authentication.
o How to configure an L2TP/IPSec connection by using Preshared Key
Authentication.
o IPsec.
o Protected Extensible Authentication.
o Routing and Remote Access.
o Routing and Remote Access Blog.
o Server and Domain Isolation.
o Windows Server 2008 Step-by-Step Guides: Step-by-Step Guide:
Deploying SSTP Remote Access.
o Understanding Point-to-Point Tunneling Protocol (PPTP).
o Virtual Private Networks.
o Virtual Private Networking with Windows Server 2003: Deploying Site-to-
Site VPNs.
 Для службы роли HRA:
o Часть «Сертификаты для шифрования SSL» раздела «Общее
представление о требованиях к проверке подлинности для центра
регистрации работоспособности» службы Справка и поддержка
Windows Server 2008.
o Health Registration Authority (HRA).
o HRA Server Role.
o IPsec.
o Network Access Protection.
o Server and Domain Isolation.
o Раздел «Общее представление о требованиях к проверке
подлинности для центра регистрации работоспособности» службы
Справка и поддержка Windows Server 2008.
 Для службы роли HCAP:
o Часть «Сертификаты для шифрования SSL» раздела «Общее
представление о требованиях к проверке подлинности для центра
регистрации работоспособности» службы Справка и поддержка
Windows Server 2008.
o Cisco Network (Сеть Cisco) в файле формата Portable Document
Format (PDF).
o IPsec.
o Network Access Protection.
o Network Policy Server.
o Server and Domain Isolation.
o Раздел «Общее представление о требованиях к проверке
подлинности для центра регистрации работоспособности» службы
Справка и поддержка Windows Server 2008.

Глава 11: Повышение уровня защиты служб терминалов


Службы терминалов в Windows Server® 2008 поддерживают протокол удаленного
рабочего стола (Remote Desktop Protocol, RDP) версии 6.0 или последующие.
Windows Server 2008 и Windows Vista® также включают версию 6.0 клиента
подключения к удаленному рабочему столу (Remote Desktop Connection, RDC) и
поддерживают его.
Примечание Для Windows Vista с пакетом обновления 1 (SP1) и Windows® XP SP3 доступно
программное обеспечение RDC версии 6.1. Для удобства использования Microsoft
рекомендует скачать пакет установки для обновления RDC-клиентов до последней версии.
Кроме основной роли Службы терминалов, Windows Server 2008 включает
следующие специальные службы роли:
 TS Licensing – лицензирование служб терминалов. Служба роли
лицензирование служб терминалов управляет клиентскими лицензиями
служб терминалов (TS CAL), которые необходимы устройствам и
пользователям для подключения к серверу терминалов. Эта служба роли
может использоваться для установки, выпуска и отслеживания наличия
лицензий TS CAL.
 TS Session Broker – посредник сеансов служб терминалов. Служба роли
посредник сеансов служб терминалов обеспечивает возможность
повторного подключения к существующему сеансу на сервере терминалов,
входящему в состав фермы серверов терминалов с балансировкой
нагрузки.
 TS Gateway – шлюз служб терминалов. Служба роли шлюз служб
терминалов позволяет авторизованным удаленным пользователям
подключаться по Интернету к серверам терминалов и компьютерам с
поддержкой удаленного рабочего стола, находящимся во внутренней
корпоративной или частной сети. Пользователи могут устанавливать
соединения с любого подключенного к Интернету устройства, способного
выполнять RDC-клиент. Служба роли TS Gateway не требует от
пользователей установления сеанса виртуальной частной сети (VPN).
Кроме того, данная служба роли для передачи трафика по туннелю HTTP
Secure Sockets Layer/Transport Layer Security (SSL/TLS) использует порт
443. Для использования этой службы роли нет необходимости открывать
дополнительные порты в брандмауэре.
Если для установки службы роли TS Gateway используется диспетчер
сервера, он также устанавливает и запускает прокси-сервер HTTP RPC,
службы политики сети и доступа, службу роли Веб-сервер (IIS) и службу
активации Windows.
 TS Web Access – Веб-доступ к службам терминалов. Служба роли Веб-
доступ к службам терминалов обеспечивает возможность доступа к
сеансам сервера терминалов через Веб-интерфейс. Авторизованные
пользователи могут получать доступ к серверам терминалов через свой
Веб-браузер. Можно так настроить Веб-интерфейс, чтобы он представлял
приложения и соединения, доступные пользователю.
Windows Server 2008 также включает компонент Удаленные приложения служб
терминалов (Terminal Services RemoteApp™, TS RemoteApp) и компонент Easy Print
служб терминалов.
TS RemoteApp обеспечивает пользователям возможность использовать службы
терминалов для удаленного доступа к программам. Создается впечатление, что
программы выполняются на локальном компьютере пользователя. TS RemoteApp
позволяет предоставить пользователям по удаленному соединению доступ всего к
одному приложению, а не ко всему рабочему столу.
Компонент Easy Print служб терминалов позволяет клиентским компьютерам
перенаправлять сеансы печати на локальный принтер. При этом нет
необходимости, чтобы администратор устанавливал какие-либо драйверы
принтера на сервере терминалов. Этот компонент не является компонентом
безопасности, но он существенно снижает для сервера риск организации атаки
типа Отказ в обслуживании (DoS) подставным драйвером принтера.
Каждая служба роли обеспечивает особую функциональность предприятию и
вводит дополнительные элементы, которые могут привести к расширению
поверхности атаки серверов, выполняющих эту роль. На следующем рисунке
представлены пять ролей, которые можно выбрать как часть роли Службы
терминалов Windows Server 2008
Сервер
терминалов

Лицензирование служб терминалов сертификации


через Интернет

Роль Службы Посредник сеансов служб


терминалов терминалов

Шлюз служб терминалов

Веб-доступ к службам
терминалов

Рис. 11.1. Иерархия служб роли Службы терминалов

Поверхность атаки
Роль сервера Службы терминалов обеспечивает клиентские компьютеры
технологиями для доступа к сеансам рабочего стола или конкретным приложениям,
выполняющимся на сервере терминалов. Чтобы обозначить поверхность атаки
этой роли сервера, необходимо определить следующее:
 Установленные файлы. Это файлы, установленные как часть роли
сервера службы терминалов.
 Выполняющиеся службы. Это службы, установленные как часть роли
сервера службы терминалов.
Примечание Для проверки целостности установленных файлов и файлов,
выполняемых службами, можно воспользоваться утилитами RootkitRevealer и
Sigcheck, являющимися частью пакета служебных программ Windows Sysinternals.
 Правила брандмауэра. Это используемые ролью сервера службы
терминалов правила брандмауэра Windows.
Подробная информация о поверхности атаки для роли службы терминалов
включена в книгу «Справочник по поверхности атаки в Windows Server 2008»,
прилагаемой к данному руководству. Оценить поверхность атаки для данной роли
сервера можно при помощи вкладки Службы терминалов (Terminal Services)
книги в разделах, соответствующих каждому из пунктов предыдущего списка.

Меры по обеспечению безопасности


В данном разделе описываются меры по обеспечению безопасности, которые
можно включить в конфигурацию роли сервера службы терминалов для защиты
сервера от злоумышленных атак. Приведенные ниже рекомендации предполагают,
что на странице Выбор служб роли Мастера добавления ролей выбрана только
опция Службы терминалов.
С точки зрения безопасности роль службы терминалов является наиболее
уязвимой и требует настройки большего количество параметров, чем остальные
роли и чем предлагает данное руководство по безопасности. Однако только служба
роли TS Gateway имеет специальные изменения конфигурации, касающиеся
безопасности. Для всех остальных служб роли, – TS Licensing, TS Session Broker и
TS Web Access, – никаких дополнительных шагов по обеспечению безопасности не
предусмотрено.

Контрольные списки настройки


При обеспечении безопасности серверов терминалов есть два вопроса, на которые
необходимо обратить особое внимание:
 Обеспечение безопасности подключений к серверам терминалов.
 Обеспечение безопасности TS Gateway.
При стандартном сценарии развертывания сервера терминалов во внутренней сети
необходимо установить только роль сервера службы терминалов. При этом в
список портов сервера, который слушает сервер, добавляется TCP-порт 3389, что
позволяет клиентским компьютерам устанавливать с сервером сеансы
подключения к удаленному рабочему столу по протоколу RDP. В последующих
разделах данной главы подробно рассматриваются все перечисленные в списке
ниже рекомендации.

Обеспечение безопасности подключений к серверам


терминалов
В следующей таблице представлены рекомендуемые действия по обеспечению
безопасности, направленные на повышение уровня защиты серверов,
выполняющих роль Службы терминалов. В случае возникновения трудностей с
выполнением каких-либо пунктов контрольного списка дополнительное описание и
рекомендации можно найти в следующих разделах данной главы.
Таблица 11.1. Контрольный список настройки сервера терминалов
Задачи настройки
Настроить проверку подлинности на сетевом уровне.
Включить единый вход для служб терминалов.
Обеспечить безопасное использование сохраненных учетных данных из RDP-
клиентов Windows Vista.
Изменить стандартный RDP-порт.
Использовать смарт-карты со службами терминалов.
Использовать файловую систему NTFS.
Использовать исключительно TS Easy Print.
Задачи настройки
Вынести пользовательские данные на отдельный диск.
Создать специальные подразделения для серверов терминалов.
Задать параметры групповой политики для серверов терминалов.
Задать параметры групповой политики для удаленных рабочих столов.
Разрешить пользователям работать только с определенными программами.
Ограничить аудит безопасности серверов терминалов.

Настроить проверку подлинности на сетевом уровне


Проверка подлинности на сетевом уровне – это новый метод проверки
подлинности, который завершает аутентификацию пользователя перед
установлением соединения с удаленным рабочим столом и выводом на экран окна
входа в систему. Это более безопасный метод аутентификации, который может
обеспечить защиту удаленного компьютера от злонамеренных пользователей и
программ. Проверка подлинности на сетевом уровне обладает следующими
преимуществами:
 Она изначально требует меньших ресурсов сервера. Пока подлинность
пользователя не подтверждена, сервер использует ограниченное число
ресурсов, а не устанавливает полное соединение с удаленным рабочим
столом, как это имело место в предыдущих версиях.
 Она может обеспечить лучшую безопасность за счет сокращения риска атак
DoS.
Чтобы использовать проверку подлинности на сетевом уровне, необходимо
выполнить следующие требования:
 Клиентский компьютер должен использовать Remote Desktop Connection
(RDC) 6.0 или боле позднюю версию.
 На клиентском компьютере должна выполняться операционная система,
такая как Windows Vista, поддерживающая протокол Поставщика услуг
безопасности CredSSP (Credential Security Support Provider).
 Сервер терминалов должен работать под управлением Windows
Server 2008.
Можно конфигурировать сервер терминалов на поддержку подключений только от
клиентских компьютеров, выполняющих проверку подлинности на сетевом уровне.
Настроить параметр проверки подлинности на сетевом уровне для сервера
терминалов можно следующими способами:
 Используя Диспетчер сервера для установки службы роли Сервер
терминалов с помощью страницы Укажите метод проверки подлинности
для сервера терминалов (Specify Authentication Method for Terminal
Server) Мастера добавления ролей.
 На вкладке Удаленное использование (Remote) диалогового окна
Свойства системы (System Properties) на сервере терминалов.
Если параметр Разрешать подключения от компьютеров с любой
версией рабочего стола (опаснее) (Allow connections from computers
running any version of Remote Desktop (less secure)) не выбран и не
активен, значит, для сервера терминалов был активирован и применен
параметр групповой политики Требовать аутентификации пользователя
для удаленных подключений путем проверки подлинности на уровне
сети (Require user authentication for remote connections by using
Network Level Authentication).
Как настраивать параметр Проверка подлинности на сетевом уровне с
помощью вкладки Удаленное использование диалогового окна Свойства
системы на сервере терминалов, рассказывается в части «Configuring
remote connection settings» (Настройка параметров удаленного соединения)
раздела Terminal Server Installation (Установка сервера терминалов)
Windows Server 2008 Technical Library.
 В инструменте Конфигурация служб терминалов (Terminal Services
Configuration) на вкладке Общие (General) диалогового окна Свойства
установить флажок Разрешить подключения только от компьютеров с
удаленным рабочим столом с проверкой подлинности на уровне сети
(Allow connections only from computers running Remote Desktop with
Network Level Authentication).
Если флажок напротив этого параметра установлен и параметр не активен,
значит, для сервера терминалов была активирована и применена групповая
политика Требовать аутентификации пользователя для удаленных
подключений путем проверки подлинности на уровне сети.
 Применяя параметр групповой политики Требовать аутентификации
пользователя для удаленных подключений путем проверки
подлинности на уровне сети.
Данный параметр групповой политики находится в разделе Конфигурация
компьютера\Административные шаблоны\Компоненты
Windows\Службы терминалов\Сервер терминалов\Безопасность. Этот
параметр может быть задан посредством Редактора локальных
групповых политик (Local Group Policy Editor) или Консоли управления
групповой политикой (Group Policy Management Console, GPMC).
Примечание Этот параметр групповой политики имеет приоритет над параметром,
заданным на вкладке Удаленное использование инструмента Конфигурация служб
терминалов.
Чтобы выяснить, поддерживает ли проверку подлинности на сетевом уровне
версия RDC, выполняющаяся на компьютере, запустите подключение к удаленному
рабочему столу, в верхнем левом углу диалогового окна щелкните значок
Подключение к удаленному рабочему столу и затем щелкните О программе
(About). В диалоговом окне О подключении к удаленному рабочему столу
(About Remote Desktop Connection) должна отображаться фраза
«Поддерживается проверка подлинности на уровне сети» (Network Level
Authentication supported).
Больше информации о безопасности и Службах терминалов можно найти на
странице Terminal Services (Службы терминалов) Веб-сайта Windows Server 2008
TechCenter.
Больше информации о параметрах групповой политики для служб терминалов
представлено в материалах Technical Reference: Terminal Services (Техническая
справочная документация: службы терминалов).
Большинство пользователей сервера терминалов, вероятнее всего, захотят, чтобы
пользовательский интерфейс (UI) сервера терминалов соответствовал UI их
настольных компьютеров. Например, если на компьютерах пользователей
установлена Windows Vista, на сервере терминалов придется установить такой же
рабочий стол, чтобы в сеансах подключения к удаленному рабочему столу
пользователи работали с таким же UI.

Включить единый вход для служб терминалов


Единая регистрация (Single sign-on, SSO) – это метод проверки подлинности,
благодаря которому пользователи, у которых есть учетная запись домена,
зарегистрировавшись один раз, получают доступ к удаленным серверам без
повторного предоставления своих учетных данных.
Чтобы реализовать SSO в службах терминалов, необходимо выполнить следующие
требования:
 Пользователь может использовать SSO для установления удаленных
соединений в любом из следующих сценариев:
o Поддержка пользователей, регистрирующихся на сервере
терминалов с Windows Server 2008 с компьютера с Windows Vista.
o Поддержка пользователей, регистрирующихся с одного сервера с
Windows Server 2008 на другом сервере с Windows Server 2008.
 Учетные записи пользователей должны обладать соответствующими
правами для регистрации, как на сервере терминалов, так и на клиентском
компьютере с Windows Vista.
 Клиентский компьютер и сервер терминалов должны быть присоединены к
домену.
Задачи настройки
Чтобы настроить рекомендуемые параметры для сервера терминалов, выполните
следующие задачи:
 Настройте проверку подлинности на сервере терминалов.
 Настройте компьютер с Windows Vista так, чтобы для регистрации на
заданном сервере терминалов могли использоваться стандартные учетные
данные.
Минимальным требованием для выполнения данной процедуры является членство
в локальной группе Администраторы или эквивалентной ей.
Чтобы настроить проверку подлинности на сервере терминалов
1. Щелкните Пуск, выберите Администрирование, выберите Службы
терминалов (Terminal Services) и затем щелкните Настройка служб
терминалов (Terminal Services Configuration).
2. Под Подключения щелкните правой кнопкой мыши соответствующее
подключение (например, RDP-Tcp) и затем щелкните Свойства.
3. Выберите вкладку Общие, убедитесь, что параметру Уровень
безопасности (Security Layer) задано либо значение Согласование
(Negotiate), либо SSL (TLS 1.0).
4. Убедитесь, что на вкладке Параметры входа в систему (Log on Settings)
не установлен флажок Всегда требовать пароль (Always prompt for
password), и затем щелкните OK.
Чтобы разрешить использование стандартных учетных данных для единой
регистрации
1. В компьютере с Windows Vista щелкните Пуск и затем в окне Начать поиск
(Start Search) введите gpedit.msc и нажмите ENTER.
2. Разверните Конфигурация компьютера, разверните Административные
шаблоны, разверните Система (System) и затем щелкните Передача
учетных данных (Credentials Delegation).
3. Щелкните двойным щелчком Разрешить передачу учетных данных,
установленных по умолчанию (Allow Delegating Default Credentials).
4. В диалоговом окне Свойства на вкладке Настройка (Setting) щелкните
Включен (Enabled) и затем щелкните Показать (Show).
5. В диалоговом окне Показать содержимое (Show Contents) щелкните
Добавить (Add).
6. В диалоговом окне Добавление элемента (Add Item) в поле Введите
добавляемый элемент (Enter the item to be added) введите termsrv/ и имя
сервера терминалов (например, termsrv/Server1), щелкните OK и затем
щелкните OK еще раз.
Минимальным требованием для выполнения данной процедуры является членство
в локальной группе Администраторы или эквивалентной ей. Подробно о том, какие
учетные записи должны использоваться, и членство в каких группах необходимо,
рассказывает статья Why you should not run your computer as an administrator
(Почему не следует запускать компьютер под учетной записью администратора) на
сайте Microsoft® TechNet.
Больше информации о Службах терминалов можно найти на странице Terminal
Services Веб-сайта Windows Server 2008 TechCenter.

Активировать безопасное использование сохраненных учетных


данных из RDP-клиентов Windows Vista
Согласно политике передачи учетных данных в Windows Vista RDP-клиент не может
отправлять сохраненные учетные данные на TS-сервер, если TS-сервер не прошел
проверку подлинности. По умолчанию для аутентификации серверов RDP-клиенты
Windows Vista используют протокол Kerberos. В качестве альтернативы могут
использоваться SSL-сертификаты сервера, но это не делается по умолчанию.
Существует три типовых сценария, в которых использование протокола Kerberos
для проверки подлинности сервера невозможно, но могут применяться SSL-
сертификаты сервера. Поскольку SSL-сертификаты сервера не развертываются по
умолчанию, сохраненные учетные данные не помогут в следующих случаях:
 Подключение к службам терминалов с домашнего компьютера через сервер
TS Gateway.
 Подключение к автономному (невходящему в домен) серверу.
 Подключение к ферме серверов терминалов.
При подключении к серверу терминалов, располагающемуся за брандмауэром
предприятия через сервер TS Gateway, TS-клиент не имеет прямого соединения с
центром распространения ключей, который находится на контроллере домена за
брандмауэром предприятия. В результате, проверка подлинности сервера с
использованием протокола Kerberos дает сбой. Протокол Kerberos не используются
для подключения к автономному серверу.
Для каждого из приведенных случаев необходимо активировать проверку
подлинности серверов, установить SSL-сертификаты, выданные надежным
центром сертификации (ЦС), и задать имя сервера в поле субъект. Разверните
сертификаты на все серверы терминалов, для которых предполагается
использовать проверку подлинности серверов. Для добавления сертификатов на
серверы терминалов используйте следующую процедуру.
Чтобы задать SSL-сертификат для подключения
1. Щелкните Пуск, щелкните Выполнить (Run) и затем в поле Открыть введите
tsconfig.msc и щелкните OK.
2. В окне Подключения панели Конфигурация сервера терминалов
(Configuration for terminal server) щелкните двойным щелчком RDP-Tcp.
3. На вкладке Общие щелкните Выбрать (Select).
4. Выберите сертификат, который хотите назначить для подключения, и щелкните
OK.
Кроме того, аутентификация Kerberos не работает для ферм серверов, потому что
имена ферм не имеют ассоциированных с ними учетных записей в Active
Directory®. Без этих учетных записей проверка подлинности с использованием
протокола Kerberos невозможна.
Чтобы сделать возможной проверку подлинности серверов фермы, используйте
SSL-сертификаты, выпущенные надежным ЦС, в которых в поле субъект указано
имя фермы. Разверните их на все серверы фермы. SSL-сертификат обеспечит
аутентификацию сервера для сервера терминалов, и политика передачи учетных
данных позволит использовать сохраненные учетные данные для удаленных
подключений.
Важно Если взломанный клиентский компьютер получит доступ к сеансу TS, он может
использоваться для атак на сервер Служб терминалов. Для уменьшения такого риска
Microsoft рекомендует гарантированно обеспечить соответствующую защиту всех клиентских
компьютеров и серверов организации от вредоносных программ и выполнение ими
последних обновлений ПО.

Изменить стандартный RDP-порт


Если вы не хотите подвергать атакам обычно используемый RDP-порт (TCP 3389),
можно для RDP-сеанса другой порт. Однако изменения необходимо вносить и на
самом сервере терминалов, и на всех TS-клиентах. Важно отметить, что изменение
этого порта усложняет как развертывание сервера терминалов, так и последующие
аудит и устранение неполадок. Поэтому Microsoft рекомендует прибегать к этому
лишь для сред, подверженных большим рискам, для которых такие издержки на
дополнительную сложность обоснованы.
Больше информации об изменении RDP-порта можно найти в статье 187623 How to
change Terminal Server’s listening port (Как изменить слушающий порт сервера
терминалов) Базы знаний Microsoft.

Использовать смарт-карты со службами терминалов


RDP-клиенты служб терминалов в Windows Server 2008 поддерживают
возможность проверки подлинности по смарт-катре для пользователей, входящих в
удаленные сеансы в домене, который использует доменную службу Active
Directory® (AD DS). Смарт-карта – это разновидность двухфакторной
аутентификации, при которой для получения доступа к сетевым ресурсам
пользователь должен иметь смарт-карту и знать PIN-код. Смарт-карты
обеспечивают безопасное, защищенное от несанкционированного вмешательства
хранение закрытых ключей и сертификатов безопасности X.509. Благодаря смарт-
картам вы можете требовать от пользователей предоставления надежных учетных
данных для обеспечения более безопасной среды.
В этом случае обеспечивается хорошая защита от злоумышленников,
использующих для доступа к хостам действительные учетные данные
пользователей. Если для входа на сервер терминалов необходима действительная
смарт-карт, злоумышленнику придется не только знать регистрационные данные и
пароль пользователя, но также позаимствовать смарт-карту пользователя. Поэтому
в случае реализации компанией политики двухфакторной аутентификации Microsoft
рекомендует использовать на сервере терминалов проверку подлинности по смарт-
карте.
Чтобы использовать смарт-карты для Служб терминалов Windows Server 2008, в
организации должны быть развернуты AD DS, на клиентские компьютеры должна
быть установлена клиентская операционная система Microsoft со встроенной
поддержкой смарт-карт, такая как Windows Vista или Windows XP, и большинство
устройств на базе Windows CE .NET. Также пользователям компьютеров
необходимо обеспечить возможность доступа сеансов сервера терминалов с
локально установленным устройствам чтения смарт-карт.
Если все эти требования выполнены, развертывание смарт-карт для Служб
терминалов Windows Server 2008 аналогично развертыванию смарт-карт для
использования со стандартной проверкой подлинности клиентов Windows

Использовать файловую систему NTFS


Microsoft настоятельно рекомендует использовать для жестких дисков сервера
терминалов исключительно файловую систему NTFS. Таблица размещения
файлов (file allocation table, FAT) не предлагает никакой безопасности ни
пользователей, ни каталогов, тогда как с NTFS доступ к подкаталогам может быть
разрешен только определенным пользователям или группам пользователей.
Это важно в многопользовательских системах, таких как та, которая использует
Службы терминалов. Без обеспечиваемой NTFS безопасности любой пользователь
имеет доступ ко всем каталогам и файлам сервера терминалов. Также существуют
дополнительные преимущества в быстродействии, доступные только при
использовании файловой системы NTFS, такие как дисковые квоты и аудит
файловой системы.

Использовать исключительно TS Easy Print


TS Easy Print – новый компонент Windows Server 2008, позволяющий
пользователям надежно выполнять печать из программы TS RemoteApp или сеанса
полного рабочего стола на локальном или сетевом принтере, установленном на
клиентском компьютере. Теперь для поддержки принтеров нет необходимости
устанавливать драйверы печати на сервере терминалов. При выполнении печати
из программы TS RemoteApp или сеанса удаленного рабочего стола пользователи
на локальном клиенте будут видеть полное диалоговое окно свойств принтера
(пользовательский интерфейс принтера) и иметь доступ ко всем функциям
принтера.
С помощью групповой политики можно обеспечить перенаправление только
принтера по умолчанию, и, таким образом, сократить накладные расходы,
улучшить надежность и масштабируемость. Чтобы сделать это, примените
параметр групповой политики Перенаправлять только используемый по
умолчанию принтер клиента (Redirect only the default client printer).
Данный параметр групповой политики находится в разделе Конфигурация
компьютера\Административные шаблоны\Компоненты Windows\Службы
терминалов\Сервер терминалов\Перенаправление принтеров.
Этот параметр можно задать либо через Редактор локальной групповой политики,
либо с помощью Консоли управления групповой политикой (GPMC). Включение
этого параметра политики гарантирует, что перенаправленным на сервер TS
сможет быть только принтер по умолчанию клиента TS.
Эта политика работает для соединений с любой версией клиента TS.

Вынести пользовательские данные на отдельный диск


Если пользователям разрешено загружать данные на системный диск сервера
терминалов, существует вероятность того, что это может серьезно повлиять на
производительность сервера, даже стать причинной атаки типа отказ в
обслуживании. Поэтому Microsoft рекомендует хранить данные пользователей на
специально выделенном для этого жестком диске, изолированном от данных
операционной системы.
Перенаправить профиль учетной записи пользователя сервера терминалов на диск
данных пользователей можно с помощью параметра групповой политики Профиль
пользователя сервера терминалов (Terminal Server User Profile).
Чтобы вручную настроить параметры профиля, касающиеся служб
терминалов
1. Откройте Active Directory – Пользователи и компьютеры.
2. Щелкните правой кнопкой мыши учетную запись пользователя, профиль
которой хотите настраивать, и щелкните Свойства.
3. Щелкните вкладку Профиль служб терминалов (Terminal services profile).
Используя следующие методы, вы можете вручную настроить параметры профиля,
касающиеся Служб терминалов:
 Путь к профилю. Этот путь можно использовать для выбора отличного от
стандартного места хранения профилей Служб терминалов.
 Домашняя папка служб терминалов. Можно задать путь к домашней
папке, которая будет использоваться сеансами Сервера терминалов. Это
может быть либо локальная папка, либо сетевой ресурс.
Также обе эти опции можно включить напрямую с помощью групповой политики,
находящейся в следующем разделе:
Конфигурация компьютера\Административные шаблоны\Компоненты
Windows\Службы терминалов\Сервер терминалов\Профили
Для обеспечения дополнительной защиты рассмотрите возможность применения
для управления дисковым пространством, предоставляемым пользователям,
управления квотами на жестком диске для пользовательских данных. Больше
информации об использовании дисковых квот можно найти в разделе Working with
Quotas (Работа с квотами) книги Step-by-Step Guide for File Server Resource Manager
(Пошаговое руководство по работе с диспетчером ресурсов файлового сервера).

Создать специальные подразделения для серверов терминалов


Там, где это возможно, Microsoft рекомендует размещать объекты-компьютеры
Сервера терминалов в специальных подразделениях. Это позволит создать
общесистемные ограничения для среды сервера терминалов. Таким образом, для
Сервера терминалов будут реализованы ограничения на уровне компьютера.
Администраторы могут применять ограничения учетных записей ко всем
пользователям, включая администраторов, регистрирующихся на сервере
терминалов. Эти ограничения можно добавлять или применять их вместо политик
для пользователей, когда они входят в домен. Дополнительная информация
представлена в документации, посвященной замыканию политики компьютера на
себя.
Примечание Упомянутые в данном разделе политики могут жестко ограничивать
функциональность даже для учетной записи администратора.
Если необходимо применять ограничения для каждого пользователя в
отдельности, поместите объект учетной записи в заблокированное подразделение.
Однако в этом случае ограничения учетных записей для данной учетной записи
пользователя будут действовать независимо от того, какой компьютер
используется для входа в домен.
При реализации групповой политики для этой цели Microsoft рекомендует
применять один из двух подходов:
 Поместить учетные записи пользователей в заблокированное
подразделение.
При таком подходе вы создаете учетные записи пользователей только для
сервера терминалов и помещаете их в заблокированное подразделение.
После этого с помощью оснастки Консоль управления Microsoft настройкой
сервера терминалов (Terminal Server Configuration MMC) можно разрешить
вход на сервер терминалов только этим пользователям. Проинструктируйте
пользователей о том, что на сервере терминалов они должны использовать
только эти учетные записи. Если необходимо применить какие-то
ограничения к компьютерам, отключите обработку замыкания и поместите
объект-компьютер Сервера терминалов в подразделение. Кроме
ограничивающих политик компьютера, на одном сервере терминалов к
пользователям могут применяться различные уровни ограничений. Такая
реализация позволяет администраторам выполнять на сервере терминалов
некоторые операции, пока пользователи активны.
 Поместить в заблокированное подразделение только объект-
компьютер Сервер терминалов.
При использовании данного подхода после установки и настройки всех
приложений на сервере терминалов компьютер-объект Сервера
терминалов можно поместить в заблокированное подразделение и после
этого включить обработку замыкания. Тогда все пользователи, входящие на
сервер терминалов, независимо от того, в каких подразделениях эти
пользователи размещаются, будут подчинены политикам, основанным на
учетных записях, определенным заблокированным объектом групповой
политики (GPO).
Таким образом, можно избежать необходимости внесения в настройки
сервера терминалов множества локальных изменений. Но администратор
по-прежнему может удаленно управлять сервером. Если администраторам
необходим доступ к серверу терминалов, выполните выход из системы для
всех пользователей и временно ограничьте возможность их входа на
сервер терминалов. Выведите компьютер-объект Сервера терминалов из
заблокированного подразделения и выполните вход в систему. Верните
компьютер-объект Сервера терминалов в заблокированное подразделение
и после завершения обслуживания возобновите возможность входа
пользователей. Для этой реализации не требуется, чтобы у пользователей
имелось множество учетных записей пользователя. Благодаря ей также
можно предотвратить изменение конфигурации сервера терминалов во
время его работы.
Следующий шаг после принятия решения о подходе к применению политики –
определение параметров групповой политики, которые должны быть реализованы
в конкретной среде. В данном руководстве представлены рекомендации для
параметров, которые могут быть наиболее эффективными для обеспечения
безопасности установки сервера терминалов в средах EC и SSLF. Однако из-за
возможных проблем с совместимостью и возможностью использования эти
параметры не применяются в объектах GPO, создаваемых инструментом
GPOAccelerator.
Важно Если решено применять данные рекомендации по настройке, важно тщательно
протестировать их, чтобы найти наиболее эффективные для конкретной среды. Возможно,
некоторые ограничения настроек могут привести к проблемам совместимости с рядом
приложений, необходимых вашей организации.

Задать параметры групповой политики для серверов терминалов


Существует ряд параметров групповой политики, которые могут использоваться
для настройки Служб терминалов на сервере терминалов. В данный раздел
включены имена объектов политики, описания и назначение параметров и
рекомендации по их применению
Редактировать объекты политики, оказывающие влияние на безопасность Служб
терминалов, можно с помощью GPMC. В следующем списке представлены
некоторые ключевые области:
 Опции безопасности
 Системные службы
 Подключения
 Перенаправление устройств и ресурсов
 Ограничение сеансов по времени
 Установщик Windows
 Групповая политика
Параметры политики опций безопасности
Для управления опциями безопасности Microsoft рекомендует использовать
параметры политики из следующего раздела GPMC:
Конфигурация компьютера\Параметры Windows\Параметры
безопасности\Локальные политики\Опции безопасности
В следующей таблице представлены имена объектов политики, рекомендуемые
значения, их описания и значения по умолчанию в Windows Server 2008.
Таблица 11.2. Параметры политики опций безопасности компьютера сервера
терминалов
Объект политики Описание Значение
по
умолчанию
Устройства: Рекомендуемое значение: Включен Не
разрешить доступ к Согласно данной политике доступ к дисководу определен
дисководам компакт- компакт-дисков разрешен только
дисков только пользователям, которые выполнили вход в
локальным консоль сервера терминалов. Microsoft
пользователям рекомендует активировать эту политику,
(Devices: Restrict CD- чтобы предотвратить возможность
ROM access to locally удаленного доступа пользователей и
logged-on user only) администраторов к программам или данным
компакт-дисков.
Устройства: Рекомендуемое значение: Включен Не
разрешить доступ к Согласно данной политике доступ к дисководу определен
дисководам гибких гибких дисков разрешен только
дисков только пользователям, которые выполнили вход в
локальным консоль сервера терминалов. Microsoft
пользователям рекомендует активировать эту политику,
(Devices: Restrict чтобы предотвратить возможность
floppy access to удаленного доступа пользователей и
locally logged-on user администраторов к программам или данным
only) гибких дисков.
Интерактивный вход Рекомендуемое значение: Включен Отключен
в систему: не Данная политика определяет, будет ли имя
отображать пользователя, выполнившего вход в систему
последнее имя последним, отображаться на экране входа в
пользователя Windows.
(Interactive logon: Do
Если данная политика активирована, имя
not display last user
пользователя, который успешно вошел в
name)
систему последним, не отображается в
диалоговом окне Вход в Windows (Log On to
Windows).
По умолчанию имя пользователя, вошедшего
в систему последним, отображается. Microsoft
рекомендует активировать этот параметр,
чтобы пользователи, выполняющие доступ к
серверу, не могли видеть имена входа в
систему.
Параметры политики системных служб
Для управления системными службами Microsoft рекомендует использовать
параметры политики из следующего раздела GPMC:
Конфигурация компьютера\Параметры Windows\Параметры
безопасности\Системные службы
В следующей таблице представлено имя объекта политики, рекомендуемое
значение, его описание и значение по умолчанию в Windows Server 2008.
Таблица 11.3. Параметр политики системных служб компьютера сервера
терминалов
Объект политики Описание Значение
по
умолчанию
Справка и Рекомендуемое значение: Отключен Не
поддержка (Help and Данная политика отключает службу Центра определен
Support) справки и поддержки. Она не дает
пользователям запускать приложение Центр
справки и поддержки Windows. Эта политика
не отключает файлы справки (такие как *.chm)
или Справку в других приложениях.
Отключение данной службы может привести к
возникновению проблем с другими
зависимыми от нее программами и службами.
Microsoft рекомендует отключать эту службу,
чтобы пользователи не могли запускать
другие приложения или просматривать
системную информацию о сервере
терминалов.

Параметры политики подключений


Для управления подключениями Microsoft рекомендует использовать параметры
политики из следующего раздела GPMC:
Конфигурация компьютера\Административные шаблоны\Компоненты
Windows\Службы терминалов\Сервер терминалов\Подключения
В следующей таблице представлены имена объектов политики, рекомендуемые
значения, их описания и значения по умолчанию в Windows Server 2008.
Таблица 11.4. Параметры политики подключений компьютера сервера
терминалов
Объект политики Описание Значение
по
умолчанию
Ограничить Рекомендуемое значение: Включен Не
пользователей Соответственно данной политике один определен
службы пользователь не может, используя одну
терминалов одним учетную запись, создавать множество сеансов
удаленным на сервере терминалов.
сеансом (Restrict
Terminal Services
users to a single
remote session)
Удалить элемент Рекомендуемое значение: Включен Не
«Отключение Данная политика убирает опцию отсоединения определен
сеанс» из диалога из диалогового окна Завершение работы
завершения Windows (Shut Down Windows). При этом
1
работы (Remove пользователи сохраняют возможность
Disconnect option отключать сеанс с Сервером терминалов.
from Shut Down Используйте эту политику, если хотите,
dialog box) чтобы пользователи не имели возможность
без труда отключаться от сеанса, и не
желаете удалять диалоговое окно
Завершение работы Windows.

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


Для управления перенаправлением устройств и ресурсов Microsoft рекомендует
использовать параметры политики из следующего раздела GPMC:
Конфигурация компьютера\Административные шаблоны\Компоненты
Windows\Службы терминалов\Сервер терминалов\Перенаправление
устройств и ресурсов
В следующей таблице представлены имена объектов политики, рекомендуемые
значения, их описания и значения по умолчанию в Windows Server 2008.
Таблица 11.5. Параметры политики перенаправления устройств и ресурсов
компьютера сервера терминалов
Объект политики Описание Значение по
умолчанию
Разрешить Рекомендуемое значение: Отключен Отключен
перенаправление Данная политика определяет, могут ли

1
Данная политика находится в разделе Конфигурация
компьютера\Административные шаблоны\Компоненты Windows\Службы
терминалов\Сервер терминалов\Среда удаленных сеансов (прим. научного
редактора).
Объект политики Описание Значение по
умолчанию
звука (Allow audio пользователи выбирать, где будет
redirection) воспроизводиться звук с удаленного
компьютера в сеансе служб терминалов. С
помощью опции Звук на удаленном
компьютере (Remote computer sound) на
вкладке Локальные ресурсы (Local
Resources) окна подключения к удаленному
рабочему столу пользователи могут
выбирать, где будет воспроизводиться
удаленный звук: на удаленном или на
локальном компьютере. Также пользователи
могут отключить звук.
Не разрешать Рекомендуемое значение: Включен Не
перенаправление По умолчанию службы терминалов допускают определен
буфера обмена (Do перенаправление буфера обмена. Данная
not allow clipboard политика определяет, будет ли в сеансе
redirection) служб терминалов запрещено разделение
содержимого буфера обмена между
удаленным и клиентским компьютерами. С
помощью этого параметра можно запретить
пользователям перенаправлять данные
буфера обмена на и с удаленного и
локального компьютера.
Не разрешать Рекомендуемое значение: Включен Не
перенаправление По умолчанию службы терминалов допускают определен
COM-портов (Do такое перенаправление COM-портов. Данная
not allow COM port политика определяет, будет ли в сеансе
redirection) служб терминалов запрещено
пернаправление данных на клиентские COM-
порты. С помощью этого параметра можно
запретить сопоставление локальных COM-
портов и перенаправление данных с
удаленного компьютера на периферийные
устройства, подключенные к локальным COM-
портам.
Не разрешать Рекомендуемое значение: Включен Не
перенаправление По умолчанию сервер терминалов определен
дисков (Do not allow автоматически отображает жесткие диски
drive redirection) клиента при подключении. Microsoft
рекомендует активировать эту политику,
чтобы пользователи не могли посредством
перенаправления дисков получать доступ к
приложениям на локальном компьютере.
Объект политики Описание Значение по
умолчанию
Не разрешать Рекомендуемое значение: Включен Не
перенаправление По умолчанию службы терминалов допускают определен
LPT-портов (Do not перенаправление LPT-портов. С помощью
allow LPT port данной политики можно запретить
redirection) перенаправление данных на клиентские LPT-
порты в сеансе служб терминалов. С
помощью этого параметра можно запретить
пользователям отображать локальные LPT-
порты и перенаправлять данные с удаленного
компьютера на периферийные устройства,
подключенные к локальным LPT-портам.
Не разрешать Рекомендуемое значение: Включен Не
перенаправление По умолчанию службы терминалов допускают определен
поддерживаемых перенаправление поддерживаемых устройств
устройств Plug and Plug and Play. С помощью опции Подробнее
Play (Do not allow (More) на вкладке Локальные ресурсы окна
supported Plug and подключения к удаленному рабочему столу
Play device пользователи могут выбирать
redirection) поддерживаемые устройства Plug and Play
для перенаправления на удаленный
компьютер.
Если отключить эту политику, пользователи
не смогут перенаправлять поддерживаемые
ими устройства Plug and Play на удаленный
компьютер.
Примечание: Также перенаправление
поддерживаемых устройств Plug and Play можно
запретить на вкладке Параметры клиента (Client
Settings) в инструменте настройки служб
терминалов.

Не разрешать Рекомендуемое значение: Отключен Не


перенаправление Данная политика позволяет включать или определен
устройства чтения выключать перенаправление устройств
смарт-карт (Do not чтения смарт-карт в сеансе служб
allow smart card терминалов. Microsoft рекомендует
device redirection) максимально широкое применение устройств
чтения смарт-карт, поэтому этот параметр не
следует включать.

Параметры политики ограничения сеансов по времени


Для управления ограничением сеансов по времени Microsoft рекомендует
использовать параметры политики из следующего раздела GPMC:
Конфигурация компьютера\Административные шаблоны\Компоненты
Windows\Службы терминалов\Сервер терминалов\Ограничение сеансов по
времени
В следующей таблице представлено имя объекта политики, рекомендуемое
значение, его описание и значение по умолчанию в Windows Server 2008.
Таблица 11.6. Параметр политики ограничения сеансов по времени
компьютера сервера терминалов
Объект политики Описание Значение по
умолчанию
Задать Рекомендуемое значение: Включен Не
ограничение по По умолчанию сервер терминалов допускает определен
времени для отключение сеансов пользователей и
отключенных сохранение всех их приложений в активном
сеансов (Set time состоянии неограниченное время. Эта
limit for политика задает лимит времени активности
disconnected приложений для отключенных сеансов
sessions) сервера терминалов. Microsoft рекомендует
включить эту политику, если вы не хотите,
чтобы отключенные сеансы сервера
терминалов оставались активными в течение
длительного времени.

Параметры политики Установщика Windows


Для управления Установщиком Windows® Microsoft рекомендует использовать
параметры политики из следующего раздела GPMC:
Конфигурация компьютера\Административные шаблоны\Компоненты
Windows\Установщик Windows
В следующей таблице представлено имя объекта политики, рекомендуемое
значение, его описание и значение по умолчанию в Windows Server 2008.
Таблица 11.7. Параметр политики установщика Windows компьютера сервера
терминалов
Объект политики Описание Значение
по
умолчанию
Запретить Рекомендуемое значение: Включен Не
установщик Если эта политика задана только для определен
Microsoft Windows управляемых приложений, Установщик
(Disable Microsoft Windows по-прежнему работает для
Windows Installer) приложений, опубликованных или назначенных
групповой политикой. Если этой политике
задано значение Always (Всегда), Установщик
Windows полностью отключен. Это может быть
полезно, если на сервере терминалов
нежелательно присутствие опубликованных
или назначенных приложений.
При отключенном Установщике Windows другие
программы установки или методы по-прежнему
могут выполнять установку приложений.
Microsoft рекомендует устанавливать и
настраивать приложения до активации этой
политики. После ее активации администраторы
не могут устанавливать приложения,
использующие Установщик Windows.

Параметры политики группы пользователей


Для управления группами пользователей Microsoft рекомендует использовать
параметры политики из следующего раздела GPMC:
Конфигурация компьютера\Административные шаблоны\Система\Групповая
политика
В следующей таблице представлено имя объекта политики, рекомендуемое
значение, его описание и значение по умолчанию в Windows Server 2008.
Таблица 11.8. Параметры политики группы пользователей компьютера
сервера терминалов
Объект политики Описание Значение
по
умолчанию
Режим обработки Если компьютер-объект сервера терминалов Не
замыкания помещен в заблокированное подразделение, а определен
пользовательской учетная запись пользователя нет, обработка
групповой политики замыкания применяет ограничительные
(User Group Policy политики настройки пользователей ко всем
loopback processing пользователям сервера терминалов.
mode) Если эта политика включена, ограничительные
политики настройки пользователей
распространяется на всех пользователей,
Объект политики Описание Значение
по
умолчанию
включая администраторов, выполняющих вход
на сервер терминалов, независимо от места
расположения их пользовательской учетной
записи.
Существует два режима этой политики:
 Режим слияния сначала применяется к
собственному GPO пользователя, затем к
заблокированной политике.
Заблокированная политика является
более приоритетной, чем GPO
пользователя.
 Режим замены использует только
заблокированную политику, собственный
GPO пользователя не учитывается. Эта
политика реализовывает ограничения на
основании компьютеров, а не учетных
записей пользователей.
Если эта политика выключена, и компьютер-
объект сервера терминалов располагается в
заблокированном подразделении, к серверу
терминалов применяются только политики
настройки компьютера. Чтобы ограничение
настройки пользователя распространялось на
данного пользователя, все его учетные записи
должны быть помещены в это подразделение.

Задать параметры групповой политики для удаленных рабочих


столов
Существует ряд важных шагов, которые можно предпринять для оптимизации
безопасности сеансов пользователей при планировании конфигурации рабочей
нагрузки. Microsoft рекомендует применение этих параметров к пользовательским
учетным записям в заблокированном подразделении служб терминалов. Если
применяется обработка замыкания, эти ограничения распространяются на все
пользовательские учетные записи, выполняющие вход на компьютеры в
заблокированном подразделении
Многие из представленных в данном руководстве параметров работают на
клиентских компьютерах с Windows Vista или Windows XP с SP2 или более
поздними версиями, но при создании руководства они были протестированы только
на компьютерах с Windows Vista. Обязательно самостоятельно протестируйте все
приведенные параметры на клиентских компьютерах в своей рабочей среде.
Редактировать объекты политики, оказывающие влияние на безопасность
удаленного рабочего стола, можно с помощью GPMC. В следующем списке
представлены некоторые ключевые области:
 Перенаправление папок
 Поиск в Internet Explorer
 Меню обозревателя Internet Explorer
 Совместимость приложений
 Internet Explorer
 Общее диалоговое окно открытия файлов
 Планировщик заданий
 Windows Messenger
 Боковая панель Windows
 Windows PowerShell™
 Центр обновления Windows
 Панель задач и меню Пуск
 Рабочий стол
 Панель управления
 Установка и удаление программ
 Принтер
 Система
 Возможности Ctrl+Alt+Del
 Сценарии
Параметры политики перенаправления папок
Для управления перенаправлением папок Microsoft рекомендует использовать
параметры политики из следующего раздела GPMC:
Конфигурация пользователя\Параметры Windows\Перенаправление папки
В следующей таблице представлены имена объектов политики, рекомендуемые
значения, их описания и значения по умолчанию в Windows Server 2008.
Таблица 11.9. Параметры политики перенаправления папок компьютера
сервера терминалов
Объект политики Описание Значение по
умолчанию
AppData(Roaming) Рекомендуемое значение: Перенаправлять Не
папки всех пользователей в одно место определен
(простая) и Создать папку для каждого
пользователя на корневом пути(Basic - Redirect
everyone’s folder to the same location and Create
a folder for each user under the root path).
Для этого на вкладке Параметры (Settings)
активируйте опцию для предоставления
пользователю эксклюзивных прав. Активируйте
опцию для перемещения содержимого папки в
новый каталог. Также определите поведение
при удалении политики, чтобы папка
перенаправлялась обратно в локальный каталог
профиля пользователя при удалении политики.
Рабочий стол Рекомендуемое значение: Перенаправлять