Защищенная конфигурация точки доступа

Опубликовано 16 января 2007 г.

На этой странице

Введение Определение Трудности Решения Аннотация

Введение

Ознакомьтесь с этим руководством по безопасности для компаний среднего размера. Корпорация Майкрософт надеется, что приведенные в документе сведения помогут создать более безопасную и производительную вычислительную среду.

Аннотация

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

Раньше сомнения в безопасности беспроводных технологий были вполне обоснованными, но даже сегодня беспроводные сети по традиции считаются недостаточно защищенными, потому что в протоколах IEEE 802.11 первого поколения, разработанных для защиты беспроводных сетей, были обнаружены широко обсуждавшиеся изъяны. И хотя за прошедшие годы было разработано много способов компенсации этих изъянов, большинство предлагаемых решений были слишком дорогими или имели собственные недостатки.

Однако с тех пор многое изменилось, и по мере повышения пропускной способности и надежности беспроводных сетей совершенствовались и стандарты обеспечения их безопасности. WPA и WPA2 — новейшие протоколы обеспечения безопасности беспроводных сетей, разработанные на основе стандарта IEEE 802.11i, — помогают надежно защитить трафик в беспроводных сетях даже в ситуациях, предъявляющих повышенные требования к безопасности. При правильной настройке системы с поддержкой этих стандартов защищены гораздо надежнее, чем прежние решения, и их можно смело использовать в корпоративных системах среднего размера.

Обзор

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

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

Для кого предназначен этот документ

Этот документ ориентирован на сотрудников компаний среднего размера: технических специалистов и руководителей технических отделений, которые оценивают целесообразность использования протокола Wi-Fi Protected Access (WPA) или Wi-Fi Protected Access 2 (WPA2) для защиты беспроводной инфраструктуры. Предполагается, что читатель имеет общие технические знания о беспроводных устройствах и сетевых технологиях, имеет опыт работы с ОС Microsoft® Windows Server™ 2003, службой проверки подлинности в Интернете (Internet Authentication Service, IAS), службами сертификации и службой каталогов Active Directory® и знает, как настраивать и применять групповую политику.

К началу страницы

Определение

Для понимания изложенных в документе сведений необходимо знать следующие термины.

AES. В стандарте AES (Advanced Encryption Standard), входящем в состав спецификации WPA2, используется симметричное блочное шифрование данных.

EAP. Extensible Authentication Protocol (EAP) — это стандарт 802.1X, позволяющий разработчикам передавать используемые при проверке подлинности данные между серверами RADIUS и точками беспроводного доступа. Протокол EAP имеет ряд вариантов, в число которых входят EAP MD5, EAP-TLS, EAP-TTLS, LEAP и PEAP.

EAP-TLS. Протокол EAP Transport Layer Security (EAP-TLS) был разработан корпорацией Майкрософт на основе стандарта 802.1X для использования цифровых сертификатов при проверке подлинности. В настоящее время он является отраслевым стандартом проверки подлинности для спецификации 802.11i.

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

IEEE 802.11. Стандарт IEEE 802.11 регламентирует передачу данных в беспроводных сетях и включает несколько спецификаций: от 802.11g, которая позволяет передавать данные со скоростью более 20 Мбит/с в частотном диапазоне 2,4 ГГц, до 802.11i, которая определяет механизмы шифрования и проверки подлинности по протоколу WPA2.

IEEE 802.11i. Поправка IEEE 802.11i к стандарту 802.11 определяет методы обеспечения безопасности (WPA2), предусматривающие применение блочного шифра AES для защиты процессов проверки подлинности (EAP). Это устраняет некоторые существовавшие ранее недостатки стандартов и спецификаций обеспечения безопасности беспроводных сетей.

MS-CHAP v2. Microsoft Challenge Handshake Authentication Protocol, версия 2 (MS-CHAP v2) — это основанный на использовании паролей протокол взаимной проверки подлинности по схеме «запрос-ответ» с шифрованием данных по алгоритмам MD4 и DES. Он используется вместе с протоколом PEAP (PEAP-MS-CHAP v2) для защиты сеансов беспроводной связи.

PEAP. Защищенный протокол расширенной проверки подлинности (Protected Extensible Authentication Protocol, PEAP) — это вариант протокола расширенной проверки подлинности (EAP), устраняющий проблемы безопасности, связанные с передачей незашифрованного текста по протоколу EAP. Для этого создается безопасный канал связи, который шифруется и защищается с использованием протокола TLS.

SSID. Идентификатор беспроводной сети (SSID) — это имя, назначаемое беспроводной сети и используемое клиентом для определения корректных параметров и учетных данных, необходимых для доступа к ней.

TKIP. Протокол TKIP (Temporal Key Integrity Protocol) входит в стандарт шифрования WPA для беспроводных сетей. Этот протокол представляет собой модернизированную версию стандарта WEP, которая устраняет обнаруженные в WEP недостатки за счет поддержки смешения ключей для каждого пакета.

WEP. Спецификация Wired Equivalent Privacy (WEP) входит в стандарт IEEE 802.11 и предусматривает 64-битное или 128-битное шифрование по алгоритму RC4. В 2001 году в стандарте WEP были обнаружены серьезные недостатки, связанные преимущественно с длиной вектора инициализации поточного шифра RC4 и делающие возможным пассивное декодирование ключа RC4.

WLAN. Беспроводная локальная сеть.

WPA. Для устранения найденных в стандарте WEP изъянов в 2003 году был представлен стандарт Wi-Fi Protected Access (WPA) — совместимая с другими версиями спецификация обеспечения безопасности в беспроводных сетях, являющаяся подмножеством стандарта IEEE 802.11. Данный стандарт включает механизмы проверки подлинности и использует для шифрования данных протокол TKIP.

WPA2. Стандарт WPA2 был принят в сентябре 2004 года организацией Wi-Fi Alliance и представляет собой сертифицированную совместимую версию полной спецификации IEEE 802.11i, принятой в июне 2004 года. Как и предшествующий ему стандарт, WPA2 поддерживает проверку подлинности по протоколу IEEE 802.1X/EAP или технологию предварительных ключей, но, в отличие от своего предшественника, содержит новый усовершенствованный механизм шифрования AES (Advanced Encryption Standard), основанный на использовании протокола Counter-Mode/CBC-MAC Protocol (CCMP).

К началу страницы

Трудности

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

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

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

К началу страницы

Решения

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

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

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

Преимущества беспроводных сетевых технологий

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

Экономические преимущества

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

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

Функциональные преимущества

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

Благодаря ослаблению зависимости от кабельной сетевой инфраструктуры сокращаются расходы на развертывание и обслуживание сети. Развертывание беспроводной сети позволяет без больших затрат организовать доступ к сети в тех областях, в которых раньше внедрять сетевые технологии было невыгодно, в том числе вне помещений и в распределенных офисах.
Сеть можно эффективнее и быстрее адаптировать к изменениям потребностей, потому что установить или переместить точки беспроводного доступа гораздо проще, чем увеличить число сетевых портов.
Сокращается объем средств, «замороженных» в инфраструктуре, поскольку оборудование для беспроводных сетей превосходят по гибкости кабельную сетевую инфраструктуру. Это обеспечивает больше возможностей при расширении офиса или его переносе в другое место. Беспроводные сети с высокой пропускной способностью (802.11a/g/n) являются также экономически привлекательной альтернативой старым низкоскоростным сетям Ethernet и Token Ring.

Уязвимости беспроводных сетей

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

Таблица 1. Типичные угрозы, которым подвергаются беспроводные сети

Угроза	Описание
Раскрытие информации вследствие прослушивания каналов связи	Атаки, основанные на прослушивании незащищенных каналов беспроводной связи, иногда позволяют злоумышленникам получить конфиденциальные сведения, узнать учетные данные пользователей и даже присвоить их. Высококвалифицированные хакеры могут использовать полученные таким образом сведения для проведения атак на системы, проникнуть в которые при иных условиях было бы очень сложно.
Перехват и изменение передаваемых данных	Хакер, получивший доступ к сетевым ресурсам, может также подключить к сети свои компьютеры для перехвата и изменения данных, которыми обмениваются два законных пользователя.
Подделка пакетов	Доступ к внутренней сети позволяет хакеру подделывать данные и выдавать их за нормальный трафик. Примером такой атаки может служить подделка корпоративных электронных писем, которым пользователи доверяют больше, чем информации, полученной из внешних источников. Это облегчает проведение атак, основанных на использовании социотехники и троянских программ.
Отказ в обслуживании	Какое бы решение не использовалось для обеспечения безопасности беспроводных сетей, они очень уязвимы перед умышленными или случайными атаками типа «отказ в обслуживании» (Denial of Service, DoS). Причиной нарушения работы беспроводных сетей могут стать всего лишь помехи со стороны микроволновой печи или устройства, переполняющего сеть беспорядочным трафиком.
Паразитирование (кража ресурсов)	Некоторые хакеры вторгаются в беспроводные сети просто ради бесплатного доступа в Интернет. Сами по себе такие действия не представляют угрозы, однако они отнимают сетевые ресурсы у законных пользователей и делают сеть менее защищенной от вредоносного ПО.
Случайные угрозы и неуправляемые соединения	В незащищенных беспроводных сетях любой посетитель может получить доступ к внутренней сети, просто включив устройство, позволяющее подключаться к беспроводным сетям. Эти неуправляемые устройства могут быть уже взломаны или хакер может использовать их как точку проникновения при атаке на сеть.
Нелегальные точки беспроводного доступа	Даже если в компании нет беспроводной сети, она может быть уязвима перед угрозами, которые связаны с неуправляемыми беспроводными сетями. Оборудование для беспроводных сетей стоит сравнительно недорого, поэтому любой сотрудник компании может развернуть в корпоративной среде неуправляемую и незащищенную сеть.

Сейчас, когда такое большое внимание уделяется безопасности, многие из этих факторов риска, связанных с беспроводной передачей данных, очевидны, но при разработке первых технологий защиты беспроводных сетей это было далеко не так. Когда для обеспечения безопасности при широковещательной передаче данных по беспроводным сетям была разработана спецификация WEP, казалось, что компенсировать изначальную незащищенность беспроводных сетей в сравнении с проводными не требуется, потому что технология была настолько новой, что мало кто задумывался о возможных угрозах, в которыми могут столкнуться такие сети. Однако по мере появления все более изощренных методов проведения атак стало ясно, что данные, передаваемые через беспроводные соединения, необходимо защищать не менее надежно, чем трафик традиционных сетей. Широкое распространение информации о недостатках WEP привело к быстрым изменениям в системах безопасности сетей. В популярных изданиях часто публиковались истории об «охотниках за сетями», а государственные органы работали над законами, регламентирующими защиту идентификационных и рабочих данных в различных отраслях. В ответ на эти тенденции многие компании или признали использование беспроводных технологий в корпоративной среде бесперспективным и небезопасным, или разработали сложные решения, компенсирующие недостатки стандарта WEP. Некоторые из этих сложных решений все еще используются и даже продаются. Однако, как будет показано в следующих разделах, вследствие развития беспроводных технологий и их адаптации к изменившимся требованиям к безопасности потребность в использовании подобных решений для защиты беспроводных сете пропала, и целесообразность их применения рекомендуется оценить заново. ##### Выбор оптимального решения для обеспечения безопасности беспроводной сети Как только были обнаружены технологические недостатки беспроводных сетей первого поколения, началась активная работа по их устранению. Пока одни компании, в том числе корпорация Майкрософт, работали над совершенствованием стандартов беспроводной связи, многие аналитические фирмы, производители средств обеспечения сетевой безопасности и т. д. пытались обойти недостатки, присущие прежним стандартам. В результате было разработано несколько подходов к обеспечению безопасности беспроводных сетей. Сравнительная информация об основных вариантах (кроме наиболее популярного подхода — отказа от беспроводных сетевых технологий) приведена в следующей таблице. **Таблица 2. Сравнение подходов к обеспечению безопасности беспроводных сетей**

Характеристики	WPA и WPA2	Статический алгоритм WEP	VPN	IPsec
Строгая проверка подлинности (см. примечание)	Да	Нет	Да, только если не используется проверка подлинности с помощью общих ключей	Да, если используется проверка подлинности с помощью сертификатов или по протоколу Kerberos
Надежное шифрование данных	Да	Нет	Да	Да
Прозрачное подключение и восстановление подключения	Да	Да	Нет	Да
Проверка подлинности пользователей (см. примечание)	Да	Нет	Да	Нет
Проверка подлинности компьютеров (см. примечание)	Да	Да	Нет	Да
Защита трафика при широковещательной и многоадресной передаче	Да	Да	Да	Нет
Потребность в дополнительных сетевых устройствах	Да, требуются серверы RADIUS	Нет	Да, требуются системы VPN и серверы RADIUS	Нет
Защита доступа к беспроводной сети помимо доступа к пакетам	Да	Да	Нет	Нет

**Примечание**. По поводу строгой проверки подлинности следует отметить, что во многих реализациях VPN, в которых используется туннельный режим IPsec, применяется слабая схема проверки подлинности с помощью общих ключей, называемая XAuth. Нынешние версии ОС Windows не поддерживают проверку подлинности пользователей с сопоставлениями IPsec, но эта функциональность будет реализована в ОС Windows Vista и Longhorn. При проверке подлинности компьютера он остается подключенным к беспроводной и кабельной сетям, даже если в систему не вошел ни один пользователь. Это необходимо для нормальной работы некоторых функций, основанных на доменах, например перемещаемых профилей. Как ясно из приведенной таблицы, есть много факторов, которые нужно проанализировать при оценке возможных способов защиты беспроводной сети. При выполнении этой оценки нужно учесть самые разные показатели: от расходов на реализацию и администрирование решения до его общей защищенности. Все указанные выше подходы имеют свои преимущества и недостатки, поэтому, чтобы можно было принять обоснованное решение, нужно лучше ознакомиться с каждым из них. Ниже рассматриваются следующие варианты (список упорядочен по убыванию степени обеспечиваемой ими защиты): - Отказ от развертывания беспроводной сети - Использование стандарта WPA с протоколом EAP-TLS - Использование стандарта WPA с протоколом PEAP-MS-CHAP v2 - Использование стандарта WPA с протоколом PEAP-MS-CHAP v2 и службами сертификации - Использование технологии VPN - Использование протокола IPsec - Использование протокола WEP - Отказ от защиты беспроводной сети ###### Отказ от развертывания беспроводной сети В среде специалистов по обеспечению безопасности бытует высказывание, которое гласит: «Лучше всего защищена та система, которую никто никогда не включает». Таким образом, самым надежным способом защиты от уязвимостей, присущих беспроводным сетям или любым другим технологиям, является отказ от их внедрения. Недостаток этого подхода очевиден: компания, отказывающаяся от внедрения любой технологий, может оказаться неконкурентоспособной в современных экономических условиях, когда любое преимущество, в том числе технологическое, может оказаться решающим фактором успеха. Как уже говорилось, перед внедрением любой новой технологии в конкретной компании нужно оценить потребности компании, ее устойчивость к риску и фактический риск. Беспроводные технологии — не исключение. Беспроводные сети имеют целый ряд преимуществ, но для конкретной организации эти преимущества могут быть не так важны или вообще не иметь значения. При выборе защищенного беспроводного решения для бизнеса примите во внимание все возможные варианты, в том числе отказ от беспроводных технологий. Если будет сделан вывод, что организация не готова к развертыванию беспроводной сети, это решение следует отразить в действующей корпоративной политике, чтобы предотвратить ослабление защиты корпоративной сетевой среды из-за самовольного создания беспроводных сетей конечными пользователями. ###### Использование стандарта WPA с протоколом EAP-TLS Использование стандарта WPA или WPA2 с протоколом EAP-TLS (Extensible Authentication Protocol Transport Layer Security, EAP-TLS) и сертификатами пользователей и компьютеров является наиболее надежным методом проверки подлинности стандарта 802.1X из тех, что поддерживаются беспроводными клиентами, работающими под управлением нынешних версий ОС Windows. Цифровые сертификаты используются в протоколе EAP-TLS для взаимной проверки подлинности, при которой беспроводная клиентская система подтверждает свою подлинность серверу проверки подлинности и наоборот. Для проверки подлинности по протоколу EAP-TLS необходимо, чтобы инфраструктура открытого ключа (PKI) выдавала сертификаты и поддерживала их актуальность. Для достижения наивысшего уровня защиты инфраструктуру открытого ключа нужно сконфигурировать так, чтобы она выдавала сертификаты беспроводного доступа и пользователям, и компьютерам. Из-за высоких затрат на реализацию и накладных расходов, связанных с администрированием инфраструктуры открытого ключа, это очень хорошо защищенное решение обычно применяется только в компаниях среднего и крупного размера. Однако благодаря выпуску сервера Microsoft Small Business Server, который предоставляет базовые службы сертификатов, требуемые протоколом EAP-TLS, открываются широкие возможности для применения этого решения в небольших компаниях. **Примечание**. В настоящее время не существует объектов групповой политики (GPO), поддерживающих стандарт WPA2, что может затруднить реализацию этого стандарта в сравнительно крупных системах. Однако сейчас разрабатываются обновления для ОС Windows Server 2003 и Windows XP, необходимые для обеспечения поддержки WPA2 на уровне GPO. ОС нового поколения Windows Vista и Longhorn будут снабжены интегрированной поддержкой стандарта WPA2. ###### Использование стандарта WPA с протоколом PEAP-MS-CHAP v2 Использование стандарта WPA или WPA2 с протоколами PEAP (защищенный протокол расширенной проверки подлинности) и MS-CHAPv2 (протокол проверки пароля Microsoft, версия 2) и строгими требованиями к паролям — второй по степени защиты метод обеспечения безопасности беспроводной сети из поддерживаемых нынешними версиями клиентских ОС Windows. Если создание инфраструктуры открытых ключей представляется невозможным, использование PEAP-MS-CHAPv2 является реальным и безопасным альтернативным вариантом развертывания надежной беспроводной сети. Протокол PEAP представляет собой схему односторонней проверки подлинности, в которой технология TLS используется для создания зашифрованного канала связи с сервером, по которому клиент подтверждает свою подлинность, используя другой протокол. Разработанный изначально для коммутируемого доступа и доступа через VPN протокол MS-CHAP v2 поддерживает проверку подлинности беспроводных клиентов с применением надежных паролей, но только в том случае, если в сети действуют политики, заставляющие использовать такие пароли. ###### Использование стандарта WPA с протоколом PEAP-MS-CHAP v2 и службами сертификации Службы сертификации можно использовать вместе с решением PEAP-MS-CHAP v2, основанным на применении паролей, если компании нужны элементы обоих подходов. Однако на момент написания этого документа дополнение и без того достаточно хорошо защищенного решения EAP-TLS протоколом PEAP-MS-CHAP v2 не дает с точки зрения безопасности никаких общепризнанных преимуществ. На самом деле совместное использование протоколов PEAP-MS-CHAP v2 и EAP-TLS замедляет процесс проверки подлинности, потому что при этом создаются два канала TLS, один внутри другого. Такое двойное шифрование не обеспечивает никакой выгоды. ###### Использование технологии VPN Когда были обнаружены первые бреши в защите протокола WEP, многие эксперты по безопасности и отраслевые лидеры первоначально предложили использовать для защиты беспроводных сетей технологию VPN. Технологии VPN — это надежный и проверенный временем способ защиты каналов связи, проходящих поверх небезопасных сетей (таких как Интернет), и этот метод решения проблем, связанных с протоколом WEP, все еще широко используется. Несмотря на то, что с точки зрения обеспечения безопасности это решение кажется удачным, оно имеет очевидные недостатки, делающие его непривлекательным в сравнении с гибкими решениями, основанными на протоколе WPA, который был специально разработан для защиты беспроводных сетей. Реализация решений WPA в сочетании с технологией VPN вполне возможна, однако такое решение не имеет никаких преимуществ перед решениями, основанными только на WPA, особенно если учесть усложнение беспроводной среды, связанное с интеграцией в нее VPN-решения. При анализе целесообразности интеграции технологии VPN в решение для защиты беспроводной сети нужно также учесть удобство использования итогового решения. Если со связанными с использованием VPN дополнительными требованиями к проверке подлинности и ограничениями времени при подключении к корпоративной сети через Интернет еще можно смириться, то при обращении к ресурсам из локальной сети эти сложности могут раздражать не привыкших к ним пользователей. Некоторые компании выбирают этот вариант, поскольку уже реализовали VPN-решение для удаленных пользователей и стремятся интенсивнее использовать его ресурсы для оправдания расходов. В этом случае перед окончательным выбором данного решения рекомендуется принять во внимание перечисленные ниже факторы. - VPN-соединение должно быть установлено до разрешения передачи данных через туннель, поэтому, если пользователь подключается к виртуальной частной сети после входа в локальную систему, групповая политика компьютера не применяется. (Если при входе в систему пользователь выбирает вариант **«Вход в систему с использованием коммутируемого соединения» (Logon with dialup networking)**, сначала устанавливается соединение VPN, и групповая политика применяется). - Большинство VPN-серверов рассчитаны на защиту низкоскоростных соединений (например коммутируемых и широкополосных), что может привести к появлению «узких мест» при установлении большого числа высокоскоростных соединений. - При некоторых конфигурациях VPN пользователи могут столкнуться с проблемами при перемещении между точками доступа, потому что соединения VPN часто аннулируются даже после малейших перерывов связи. Это вынуждает пользователей вручную инициировать проверку подлинности при каждом переключении на новую точку доступа. То же самое происходит при переключении компьютера в режим ожидания. ###### Использование протокола IPsec Использовать протокол IPsec для защиты беспроводных сетей стали по той же причине, что и технологию VPN: для обхода недостатков стандарта WEP. Протокол IPsec обеспечивает надежную защиту многих специфических видов сетевого трафика и имеет ряд достоинств, оправдывающих его использование в беспроводной сети. В их число входят прозрачность, независимость от аппаратных ограничений беспроводных сетей и небольшие накладные расходы, связанные с отсутствием потребности в дополнительных серверах и программном обеспечении. К сожалению, с использованием протокола IPsec для защиты беспроводных сетей связаны некоторые проблемы. - Протокол IPsec не позволяет защищать трафик при широковещательной или многоадресной передаче, потому что его действие может распространяться только на взаимодействие двух сторон, обменявшихся ключами и выполнивших взаимную проверку их подлинности. - Протокол IPsec защищает только сетевые пакеты, но не саму беспроводную сеть. - Несмотря на прозрачность протокола IPsec для пользователей, для сетевых устройств он прозрачен не полностью, потому что работает на сетевом уровне, а не на MAC-уровне. Это предъявляет дополнительные требования к правилам для брандмауэров. - Все устройства, не поддерживающие IPsec, уязвимы перед зондированием или атаками со стороны любых пользователей, способных осуществлять мониторинг трафика в беспроводной сети. - Если протокол IPsec используется в крупной системе не только для защиты трафика беспроводной сети, но и для комплексной защиты трафика других приложений, управлять политиками IPSec будет сложно. ###### Использование протокола WEP Самым простым методом обеспечения безопасности на основе стандарта 802.11 является применение статического протокола WEP, при котором управление доступом осуществляется с помощью общего ключа; этот же ключ используется еще и в качестве основы при шифровании трафика беспроводной сети. Главное преимущество этого метода — его простота. Если в сети не реализованы никакие другие средства обеспечения безопасности, он в какой-то степени защищает сеть, но при этом возникают серьезные проблемы управления и безопасности. При наличии ноутбука и простых средств, которые можно загрузить из Интернета, на определение открытого ключа и идентификатора SSID (если он распространяется не в широковещательных сообщениях) в беспроводной сети WEP требуется от нескольких минут до нескольких часов, после чего доступ к сети открыт. Один из способов усовершенствования статического алгоритма WEP предполагает, что точки доступа нужно сконфигурировать так, чтобы они путем фильтрации MAC-адресов предоставляли доступ к сети только предварительно определенной группе клиентов. Однако этот защитный барьер также легко устраняется с помощью средств, позволяющих определять и подделывать MAC-адреса компьютеров, подключенных к беспроводной сети. Дополнив протокол WEP другими технологиями обеспечения безопасности, можно в некоторой степени защитить сети, не поддерживающие WPA или WPA2, но даже эти методы рекомендуется использовать лишь на этапе перехода от незащищенной беспроводной сети к защищенной, основанной на стандарте WPA. Ниже перечислены эти методы в порядке убывания их защищенности. - Использование протокола WEP с проверкой подлинности 802.1X по протоколу EAP-TLS с сертификатами пользователей и компьютеров и принудительным периодическим выполнением проверки подлинности заново. - Использование протокола WEP с проверкой подлинности 802.1X по протоколу PEAP-MS-CHAP v2 с политиками, требующими применения надежных паролей пользователей, и принудительным периодическим выполнением проверки подлинности заново. ###### Отказ от защиты беспроводной сети Развертывать незащищенные беспроводные сети в компаниях средних размеров настоятельно не рекомендуется. Лишь в некоторых редких ситуациях такое решение может быть оправданным. Например, мэрии многих городов рассматривают возможность организации свободных зон беспроводного доступа или уже организовали их. Возможно, в таких ситуациях иногда лучше использовать сеть незащищенных точек доступа, просто позволяющих непосредственно подключаться к Интернету. Как бы то ни было, следует помнить, что незащищенные беспроводные сети чрезвычайно уязвимы перед самыми разными атаками. ##### WPA или WPA2? Протоколы Wi-Fi Protected Access (WPA) и Wi-Fi Protected Access 2 (WPA2) специально разработаны для блокирования угроз, которым подвергаются беспроводные сети, основанные на стандарте IEEE 802.11. Однако между ними есть некоторые различия. Протокол WPA был разработан в 2003 году для устранения недостатков стандарта WEP. Разработчики WPA хорошо справились с задачей, реализовав в этом протоколе поддержку взаимной проверки подлинности, шифрование данных с использованием протокола TKIP и проверку целостности подписанных сообщений, которая обеспечивает защиту от атак, основанных на подмене или повторении пакетов. Протокол WPA2 обеспечивает еще более высокий уровень безопасности, потому что в нем для защиты сетевого трафика используется стандарт AES, а не протокол TKIP. Поэтому ему всегда следует отдавать предпочтение перед WPA. Протоколы WPA и WPA2 значительно превосходят WEP по степени защиты, и при правильной настройке системы безопасности ни в первом, ни во втором нет никаких известных уязвимостей. Тем не менее, протокол WPA2 считается более защищенным, чем WPA, и, если инфраструктура его поддерживает, а дополнительные накладные расходы, связанные с администрированием решения WPA2, приемлемы, выбор следует делать в его пользу. Большинство производимых сегодня точек доступа и новейшие версии ОС Windows, а именно Windows XP с пакетом обновления 2 и Windows Server 2003 с пакетом обновления 1, сертифицированы в соответствии с требованиями протокола WPA2. Если в имеющейся среде какие-то точки доступа или клиентские компьютеры не поддерживают WPA2, беспроводные устройства и клиентские системы, поддерживающие WPA2, могут использовать более старый стандарт WPA. **Примечание**. Для обеспечения поддержки сертификации WPA2 на клиентских компьютерах, работающих под управлением ОС Windows XP с пакетом обновления 2 (SP2), необходимо установить дополнительный пакет обновления — [обновление протокола WPA2 и информационного элемента службы обеспечения беспроводной связи (WPS IE) для Windows XP с пакетом обновления 2](http://support.microsoft.com/default.aspx?scid=kb;en-us;893357). Информацию об этом пакете обновления можно найти по адресу http://support.microsoft.com/default.aspx?scid=kb;en-us;893357 (эта ссылка может указывать на содержимое полностью или частично на английском языке). Кроме того, нынешние версии ОС Windows не поддерживают WPA2 на уровне объектов групповой политики, что с точки зрения управления является существенным недостатком, который делает реализацию WPA2 гораздо более сложной в сравнении с WPA. При выборе между WPA и WPA2 это может оказаться решающим фактором, так как оба стандарта обеспечивают сравнительно надежную защиту. #### Разработка защищенного беспроводного сетевого решения В предыдущем разделе были описаны некоторые исторические предпосылки возникновения разных подходов к защите беспроводных сетей, распространенные угрозы, которым подвергаются беспроводные сети, и способы борьбы с этими угрозами, возможные при использовании каждого подхода. Имея в распоряжении эту информацию, можно принимать обоснованные решения по поводу применения тех или иных подходов в конкретных корпоративных системах. Новейшие стандарты защиты беспроводных сетей, а именно WPA и WPA2, устранили серьезные недостатки стандарта WEP и сделали, таким образом, ненужными способы обхода этих недостатков, такие как использование протокола IPsec или технологии VPN. Использовать статический или динамический алгоритм WEP теперь не рекомендуется ни в какой форме, а отказ от обеспечения безопасности выгоден лишь в немногих ситуациях. Таким образом, при разработке комплексного эффективного решения для защиты беспроводной сети достаточно рассмотреть всего лишь два подхода. Данный раздел поможет специалистам, принимающим решения, поближе познакомиться с рекомендуемыми способами защиты беспроводной сети. Многие отраслевые аналитики, эксперты по безопасности и ведущие производители считают эти решения, рекомендуемые корпорацией Майкрософт, наиболее надежными методами развертывания защищенных и эффективных беспроводных сетей. Несмотря на то, что этот документ посвящен методу, лучше всего подходящему для защиты корпоративных сетей среднего размера, рекомендуется рассмотреть все возможные варианты и полностью пройти через процесс принятия решения, так как любые правила имеют исключения. ##### Алгоритм Microsoft для выбора подхода к защите беспроводной сети Существует два рекомендуемых подхода к защите беспроводной сети. Кроме того, возможен еще и третий, смешанный подход. Ниже перечислены (в порядке убывания обеспечиваемой ими безопасности) два основных решения. - Использование стандарта WPA2 с протоколом EAP-TLS и службами сертификации. - Использование стандарта WPA2 с протоколом PEAP-MS-CHAPv2. Если не считать уровень безопасности, выбор одного из этих двух подходов сводится большей частью к ресурсам, необходимым для реализации и поддержки каждого решения. Использование стандарта WPA или WPA2 с протоколом PEAP-MS-CHAPv2 предъявляет меньшие требования к оборудованию и техническим навыкам сотрудников, потому что при этом не нужна базовая инфраструктура сертификатов. Все доступные в настоящее время на рынке устройства сертифицированы в соответствии с требованиями WPA2 и не слишком дороги, поэтому лучше выбирать системы с поддержкой WPA2, даже если решено использовать стандарт WPA из-за его нынешнего превосходства над WPA2 в плане администрирования. Поддерживаемый в WPA2 метод шифрования AES считается более защищенным, чем используемый в WPA протокол TKIP, а если учесть еще и то, что в будущих версиях планируется реализовать поддержку WPA2 на уровне объектов групповой политики, имеет смысл создать основу для реализации WPA2 в будущем. Использование стандарта WPA или WPA2 с протоколом EAP-TLS является в настоящее время самым надежным способом защиты беспроводной сети, но при этом приходится тратить дополнительные средства на реализацию и управление, потом что при таком подходе необходима инфраструктура сертификатов. Однако во многих компаниях среднего размера уже есть системы, необходимые для использования стандарта WPA2 с протоколом EAP-TLS, поэтому данный вариант может быть для них более привлекательным. Даже если необходимые системы отсутствуют, многие компании в силу других причин испытывают потребность в тех же технологиях, на которых основано данное решение (сертификаты и RADIUS-серверы), поэтому даже в таких ситуациях есть экономические и технические доводы в пользу реализации именно этого решения. [![](/security-updates/images/Cc875845.SWCG1(ru-ru,TechNet.10).gif)](https://technet.microsoft.com/ru-ru/cc875845.swcg1_big(ru-ru,technet.10).gif) **Рис. 1. Алгоритм корпорации Майкрософт для выбора подхода к защите беспроводной сети** Схема на рис. 1 уже использовалась в других руководствах корпорации Майкрософт по выбору подхода к защите беспроводных сетей и основана на некоторых предположениях относительно того, какую компанию можно считать крупной. Здесь предполагается, что крупная компания насчитывает не менее 500 сотрудников и имеет ИТ-службу, в которой работает не менее пяти специалистов. Как было сказано выше, в данном случае этот алгоритм немного дезориентирует, потому что многие компании среднего размера, для которых и написан этот документ, наверняка владеют ресурсами, нужными для реализации стандарта WPA2 с протоколом EAP-TLS и службами сертификации, если предположить, что большинство таких компаний включают как минимум пять ИТ-специалистов и могут выполнить дополнительные требования базового подхода EAP-TLS к инфраструктуре (четыре дополнительных сервера, один из которых не будет подключен к сети). Таким образом, наилучшим решением для большинства компаний среднего размера является использование стандарта WPA2 с протоколом EAP-TLS и службами сертификации. Ему и будут посвящены остальные разделы этого документа. Однако из любых правил есть исключения, и, если организация нуждается в другом подходе, ее специалистам следует обратиться к другим руководствам, недостатка в которых нет. Если принято решение использовать WPA с протоколом PEAP-MS-CHAP v2, дополнительные сведения можно найти в документе [«Защита беспроводных сетей с использованием протокола PEAP и паролей»](http://go.microsoft.com/fwlink/?linkid=23459), который находится по адресу http://go.microsoft.com/fwlink/?linkid=23459 (эта ссылка может указывать на содержимое полностью или частично на английском языке). ###### Требования протокола EAP-TLS к серверам Как уже было сказано, для реализации протокола EAP-TLS нужны как минимум четыре сервера (в распределенной или более крупной среде больше), два из которых будут выполнять функции резервных серверов службы проверки подлинности в Интернете (IAS — предлагаемая корпорацией Майкрософт реализация службы удаленной проверки пользователей RADIUS), а два других будут использоваться как компоненты базовой инфраструктуры сертификатов (PKI). Один из двух серверов сертификатов, а именно сервер корневого центра сертификации, будет отключен от сети для защиты корневого сертификата. **Таблица 3. Рекомендуемые требования к оборудованию сервера корневого центра сертификации**

Компонент	Требование
Процессор	Один процессор с тактовой частотой не менее 733 МГц
Память	256 МБ оперативной памяти
Сетевой адаптер	Отсутствует (или отключен)
Подсистема хранения данных на жестких дисках	RAID-контроллер IDE или SCSI 2 жестких диска объемом по 18 ГБ, сконфигурированные как один том RAID-массива уровня 1 (диск C) Съемный носитель для переноса данных (корневого сертификата).

Как ясно из таблицы, требования к серверу корневого центра сертификации, основанные на требованиях, предъявляемых ОС Windows Server 2003 Standard Edition, совсем невелики, и при необходимости его можно создать даже на базе старой платформы, которую планируется списать, или виртуальной машины. Во многих компаниях для этого используют ноутбук, потому что вопрос с его физической защитой можно решить, просто заперев его в сейфе. Какой бы подход к созданию корневого центра сертификации не был выбран, важно гарантировать, что в случае надобности можно будет загрузить соответствующий компьютер или восстановить хранящиеся на нем данные.

Требования к аппаратным средствам выдающего центра сертификации похожи, только этот сервер должен включать дисковую подсистему большего объема и должен быть подключен к сети. Этот сервер должен хранить все выданные сертификаты, поэтому желательно, чтобы объем его дисковой подсистемы составлял как минимум 2 ГБ на каждую тысячу пользователей.

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

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

При определении требований к RADIUS-серверам следует также принять во внимание перемещение при сбоях, избыточность и наличие в компании удаленных филиалов. Рекомендуется использовать как минимум два сервера службы проверки подлинности в Интернете, но если удаленных филиалов много, возможно, в некоторых из них нужно будет установить дополнительные серверы службы проверки подлинности в Интернете. Кроме того, некоторые компании могут предъявлять более высокие требования к избыточности серверов или балансировке нагрузки.

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

Сертификаты

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

Поддерживаемая в ОС Windows реализация протокола EAP-TLS с использованием служб сертификации позволяет выдавать сертификаты и без инфраструктуры открытого ключа, но поскольку для проверки подлинности с помощью RADIUS-сервера каждый клиент должен иметь сертификат, применение сертификатов сторонних фирм может оказаться приемлемым по цене только для самых небольших компаний. Это справедливо и для подхода, основанного на использовании протокола PEAP со службами сертификации.

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

Подписание кода
Защищенная доставка электронной почты
Защищенная доставка веб-содержимого
Обеспечение безопасности VPN
Шифрование файлов

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

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

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

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

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

Иерархия центров сертификации

В подходе, который описывается в данном руководстве, используется иерархическая модель доверия с единственным внутренним корневым центром сертификации. Такой подход имеет и достоинства, и недостатки, поэтому для определения того, насколько он выгоден в конкретной ситуации, иногда требуется провести более тщательный анализ. Чтобы получить дополнительные сведения об этом, обратитесь к главе Designing a Public Key Infrastructure («Проектирование инфраструктуры открытых ключей») руководства Windows Server 2003 Deployment Kit по адресу http://technet2.microsoft.com/WindowsServer/en/library/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b1033.mspx (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Рис. 2. Иерархия центров сертификации

Защита корневого центра сертификации

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

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

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

Проверка подлинности в Интернете

Служба проверки подлинности в Интернете (Internet Authentication Service, IAS) — это предлагаемая корпорацией Майкрософт реализация службы RADIUS и прокси-сервера. Она позволяет централизованно выполнять проверку подлинности, авторизацию и учет использования ресурсов для различных сетевых подключений. Службу проверки подлинности в Интернете можно использовать с другими RADIUS-серверами для делегирования проверки подлинности, авторизации и учета использования ресурсов, с другими VPN-серверами (такими как серверы маршрутизации и удаленного доступа), а также с другими компонентами сетевой инфраструктуры, такими как точки беспроводного доступа.

При составлении плана развертывания инфраструктуры службы проверки подлинности в Интернете важно воспользоваться преимуществами основанной на ней инфраструктуры RADIUS, потому что она не рассчитана на предоставление доступа к единственной изолированной сети. Таким образом, при планировании и развертывании инфраструктуры службы проверки подлинности в Интернете следует принять решение о том, будет ли использоваться для управления сетевым доступом централизованный сервис, в том числе централизованная база учетных записей, такая как Active Directory, а также обеспечить удовлетворение текущих и будущих потребностей организации. Иначе говоря, развертывание инфраструктуры службы проверки подлинности в Интернете должно быть стратегическим, а не только тактическим проектом.

В данном руководстве планирование и развертывание службы проверки подлинности в Интернете рассматриваются только в контексте защиты беспроводной инфраструктуры. Описание других возможностей и проблем при планировании и развертывании инфраструктуры службы проверки подлинности в Интернете см. в разделе «Deployment Resources» на странице службы проверки подлинности в Интернете по адресу www.microsoft.com/technet/itsolutions/network/ias/default.mspx (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Имеющиеся RADIUS-серверы

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

Для получения подробных инструкций по планированию переноса существующей инфраструктуры RADIUS на RADIUS-серверы, организованные на базе ОС Windows Server 2003, обратитесь к техническому руководству по службе проверки подлинности в Интернете, которое находится по адресу http://technet2.microsoft.com/WindowsServer/en/Library/8f5c89d5-fdaf-430c-9ef4-318f8c15baf11033.mspx (эта ссылка может указывать на содержимое полностью или частично на английском языке), или свяжитесь с представителем корпорации Майкрософт по работе с заказчиками или со специалистом из консалтинговой службы корпорации Майкрософт.

Перемещение при сбое RADIUS-сервера и балансировка нагрузки

RADIUS-серверы — критически важные компоненты любого решения для защиты беспроводных сетей, основанного на стандарте 802.1X, и от их доступности зависит доступность беспроводной сети. Решение RADIUS, поддерживающее беспроводные сети, должно быстро реагировать на запросы и обладать надежностью и избыточностью, чтобы обеспечивать доступность и производительность, сравнимую с проводными сетями. Именно поэтому службу проверки подлинности в Интернете рекомендуется устанавливать на имеющиеся контроллеры доменов.

Перед выбором стратегии балансировки нагрузки важно понять, что в стандарте 802.1X протокол EAP в RADIUS (EAP-RADIUS) реализуется между точкой доступа и RADIUS-сервером. Хотя RADIUS-сервер использует протокол UDP, в нем осуществляется туннелирование протокола EAP, ориентированного на установление сеанса. Это означает, что пакеты EAP-RADIUS, составляющие одну операцию проверки подлинности, должны быть возвращены тому же RADIUS-серверу, в противном случае эта попытка проверки подлинности завершится неудачей.

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

Таблица 4. Перемещение при сбоях RADIUS-сервера и балансировка нагрузки на него при использовании протокола EAP

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

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

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

Рис. 3. Методы перемещения при сбоях RADIUS-серверов и балансировки нагрузки на них в беспроводной сети

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

Требования к ведению журналов RADIUS

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

Успешные и неудачные попытки проверки подлинности.
Данные RADIUS, связанные с проверкой подлинности и учетом.

События проверки подлинности генерируются устройствами и пользователями при попытке доступа к беспроводной сети и регистрируются службой проверки подлинности в Интернете в журнале системных событий Windows Server 2003. Эта информация может пригодиться при устранении неполадок, обнаружении вторжений и аудите безопасности. Первоначально следует активировать регистрацию событий, извещающих и об успешных, и о неудачных попытках проверки подлинности, но рано или поздно нужно начать фильтровать эту информацию, чтобы избежать переполнения журнала системных событий. Использование регистрации запросов проверки подлинности RADIUS может сделать ненужным использование этих событий для обеспечения безопасности.

Централизованные или распределенные серверы службы проверки подлинности в Интернете

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

Но даже при выполнении этих условий перед выбором централизованной архитектуры нужно проанализировать текущие характеристики имеющихся каналов связи через глобальную сеть, потому что при перегрузке этих каналов время ожидания для некоторых видов трафика, например трафика DHCP, может истечь при ожидании завершения попыток проверки подлинности по стандарту 802.1X. Помимо связи с клиентами есть и другие факторы, на которые следует обратить внимание при рассмотрении централизованной архитектуры службы проверки подлинности в Интернете, потому что для взаимодействия серверов службы проверки подлинности в Интернете с контроллерами домена нужны надежные сетевые соединения. Это требуется для того, чтобы предотвратить истечение временных интервалов, отпущенных на выполнение операций, при определении прав доступа к сети и членства в группах.

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

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

Рис. 4. Смешанный подход к созданию серверной инфраструктуры службы проверки подлинности в Интернете в беспроводной сети

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

Примечание. В этом случае наличие доступа к беспроводной сети из удаленных офисов, в которых нет серверной инфраструктуры, также будет зависеть от доступности глобальной сети.

Размещение серверов службы проверки подлинности в Интернете и соображения по поводу совмещения функций

Для поддержания доступности служб глобальной сети требуются как минимум два RADIUS-сервера на каждый независимый лес Active Directory. Кроме этого базового требования есть ряд других факторов, от которых зависит число необходимых серверов и возможность их использования для выполнения других серверных функций.

Как правило, размещать серверы службы проверки подлинности в Интернете следует в соответствии с размещением контроллеров домена, то есть, если в офисе уже используется соединение через глобальную сеть с другим офисом для доступа к службам домена, скорее всего, следует использовать и удаленный RADIUS-сервер. В крупных офисах со своими контроллерами домена, скорее всего, нужно будет установить хотя бы по одному RADIUS-серверу. При наличии возможности его следует дополнить резервной системой, расположенной в другом месте, с которым имеется канал связи через глобальную сеть. При планировании размещения RADIUSсерверов для обеспечения надежной проверки подлинности локальных пользователей, а также размещения контроллеров домена, используемых для проверки подлинности, следует оценить пропускную способность канала связи через глобальную сеть, потому что реализация решения приведет к увеличению объема трафика. Кроме того, для повышения производительности RADIUS-серверы следует устанавливать в корневом домене леса; чтобы оптимизировать операции Kerberos.

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

Таблица 5. Соображения по совмещению сервера службы проверки подлинности в Интернете и контроллера домена

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

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

Чтобы исключить расходы на приобретение дополнительных серверов для удаленных офисов, в качестве серверов службы проверки подлинности в Интернете можно использовать контроллеры домена, которые, возможно, уже есть в удаленных офисах. Это можно сделать или непосредственно, или установив на имеющийся контроллер домена виртуальную машину.

Оценка нагрузки на серверы и требований к аппаратным средствам

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

При планировании нагрузки на серверы службы проверки подлинности в Интернете и составлении требований к ним следует принять во внимание следующее:

Число пользователей и устройств, нуждающихся в услугах проверки подлинности и учета.
Параметры проверки подлинности, такие как тип EAP и частота повторения проверки подлинности.
Параметры RADIUS, такие как характеристики ведения журналов и программной трассировки службы проверки подлинности в Интернете.

Описывая данное решение, основанное на использовании стандарта WPA или WPA2 с протоколом EAP-TLS и службами сертификации, важно отметить, что, в отличие от WEP, стандарты WPA и WPA2 устраняют необходимость принудительного выполнения повторной проверки подлинности для обновления ключей сеанса, что сокращает накладные расходы. Кроме того, надо сказать, что при первоначальной проверке подлинности по протоколу EAP-TLS выполняются требовательные к вычислительным ресурсам операции над открытым ключом, после чего для ускорения переподключения при последующих попытках входа в систему используются кэшированные учетные данные вплоть до окончания срока их действия, который по умолчанию составляет 8 часов. Заслуживает внимания и то, что повторная проверка подлинности при переключении клиента с точки доступа, подтверждающей свою подлинность одному RADIUS-серверу, на точку доступа, которая подтверждает подлинность другому серверу, выполняется только один раз на каждый сервер проверки подлинности и прозрачна для пользователя.

При оценке требований к серверу службы проверки подлинности в Интернете в качестве единицы измерения потенциальной нагрузки можно использовать число проверок подлинности в секунду. Примерная производительность сервера службы проверки подлинности в Интернете со службой Active Directory, созданного на основе платформы с процессором Intel Pentium 4 с тактовой частотой 2 ГГц, указана в следующей таблице.

Таблица 6. Число проверок подлинности в секунду

Тип проверки подлинности	Число проверок подлинности в секунду
Новые проверки подлинности по протоколу EAP-TLS	36
Новые проверки подлинности по протоколу EAP-TLS с поддержкой разгрузочных карт	50
Проверки подлинности с быстрым переподключением	166

**Примечание**. Приведенную в этой таблице информацию следует рассматривать при определении требований к ресурсам лишь как примерный ориентир. Как указано в таблице, при пиковой нагрузке или в ходе перемещения при сбое такой сервер может обработать 36 новых запросов проверки подлинности в секунду. Иначе говоря, проверить подлинность 100 пользователей такая система смогла бы примерно за 3 секунды. Еще одним фактором, который нужно учесть, является влияние записи данных в журнал на жестком диске на продолжительность проверки подлинности. Медленная подсистема хранения данных может ощутимо ухудшить время проверки подлинности, если мониторинг операций проверки подлинности выполняется с подробным протоколированием событий в журнале. Для поддержания приемлемого времени отклика следует использовать во всех серверах службы проверки подлинности в Интернете быстродействующие подсистемы хранения данных. ##### Проверка подлинности по стандарту WPA 802.11 Мы рассмотрели использование инфраструктуры сертификатов и службы RADIUS для защиты беспроводных коммуникаций за счет проверки подлинности пользователей и устройств, и теперь пришло время обсудить, как осуществляется защита данных, передаваемых между беспроводными устройствами, от зондирования и других угроз. Использование радиопередатчиков всегда считалось менее защищенным способом коммуникации в сравнении с кабельными каналами связи, потому что перехватить данные, передаваемые через эфир, гораздо легче, чем подключиться к кабелю или коммутационной панели, особенно если используются средства обеспечения безопасности на уровне портов. Для решения проблем, связанных с самой сутью беспроводной связи, нужно шифровать данные, чтобы даже при их перехвате нельзя было легко получить исходную информацию в понятной форме. Первоначальные спецификации WEP, определяющие механизм шифрования данных в беспроводных сетях, плохо справлялись со своей задачей, и для исправления ситуации в качестве временной меры был разработан стандарт WPA, являющийся подмножеством спецификации 802.11i, которая в то время еще не была утверждена. Несколько позднее был разработан стандарт WPA2 — полная реализация ставшего к тому времени официальным стандарта 802.11i. Главное различие между стандартами WPA и WPA2 — метод шифрования данных. В стандарте WPA используется протокол TKIP, а в WPA2 — стандарт AES-CCMP, обеспечивающий более надежную защиту. Несмотря на то, что в описываемом решении можно использовать и WEP, и WPA, при наличии возможности рекомендуется выбирать стандарт WPA2 — самый надежный способ обеспечения безопасности беспроводной передачи данных. Если это невозможно, используйте стандарт WPA, который в сочетании с изложенным в данном руководстве решением также позволяет добиться достаточно высокого уровня безопасности. ###### Требования к клиентским системам Описанное в этом руководстве решение было разработано для клиентских компьютеров со средствами беспроводной связи, работающих под управлением ОС Windows XP Professional с пакетом обновления 2 (SP2) или ОС Windows XP Tablet Edition. В ОС Windows этих версий интегрирована поддержка стандарта 802.1X и беспроводных сетей. Кроме того, клиенты, работающие под управлением ОС Windows XP, поддерживают автоматическую подачу заявок на сертификаты и автоматическое обновление сертификатов, что делает такое решение, основанное на сертификатах, особенно выгодным с экономической точки зрения, если оно связано с инфраструктурой сертификатов. В ОС Windows XP с пакетом обновления 2 (SP2) также интегрирована поддержка протокола WPA, но для обеспечения поддержки протокола IEEE 802.11i WPA2 на клиентах, работающих под управлением ОС Windows XP с пакетом обновления 2, нужно установить дополнительное обновление. Информацию об этом обновлении и инструкции по его загрузке можно найти в документе [«Обновление протокола WPA2 и информационного элемента службы обеспечения беспроводной связи для Windows XP с пакетом обновления 2»](http://support.microsoft.com/default.aspx?scid=kb;en-us;893357), который находится по адресу http://support.microsoft.com/default.aspx?scid=kb;en-us;893357 (эта ссылка может указывать на содержимое полностью или частично на английском языке). ###### Требования к серверной инфраструктуре Как уже было сказано, в рассматриваемом решении используются входящие в ОС Windows Server 2003 службы сертификации и служба проверки подлинности в Интернете. Эти компоненты Windows Server 2003 поддерживают некоторые функции, специфичные для беспроводных сетей стандарта 802.1X. Данное руководство написано специально для среды Windows Server 2003 Active Directory, но службы сертификации и служба проверки подлинности в Интернете могут быть развернуты и под управлением более старых версий ОС Windows. ###### Требования к точкам беспроводного доступа Это руководство посвящено защите беспроводной сети, поэтому размещение точек беспроводного доступа, их установка, выбор каналов и другие подобные темы в нем не рассматриваются. Для получения сведений о конфигурировании и размещении точек доступа, а также о проблемах, которые могу возникнуть при их использовании, обратитесь к инструкции производителя или материалам на его веб-узле. Описываемое решение будет защищено максимально надежно, если использовать точки доступа, сертифицированные в соответствии со стандартом IEEE 802.11i WPA2 и оснащенные встроенными функциями перемещения при сбое и отказовозвращения. Кроме того, его можно реализовать, используя оборудование, сертифицированное в соответствии со стандартом WPA, при этом сильно отступать от данного руководства не придется, а степень защиты тоже будет очень высокой. Это решение можно также реализовать на основе стандарта WEP, но делать это не рекомендуется, и рассматриваться этот вариант не будет. #### Развертывание и управление Хотя этот раздел содержит пошаговые инструкции по установке и конфигурированию используемых в решении серверов и служб, в нем не описываются сами действия по установке и конфигурированию, которые необходимо выполнить при использовании ОС Windows Server 2003 или Windows XP Professional. Предполагается, что в большинстве компаний уже реализованы процессы настройки среды и утверждены принципы укрепления ее защиты. ##### Сертификаты Этот раздел включает подробные инструкции по созданию инфраструктуры открытого ключа, но не содержит никакой информации о настройке и укреплению защиты сервера: предполагается, что эти процедуры уже стандартизированы. Кроме того, предполагается, что перед началом этого этапа развертывания решения серверы центров сертификации уже сконфигурированы с использованием основного образа и защищены в соответствии со стандартным процессом, принятым в организации. **Примечание**. Помните, что корневой центр сертификации никогда не будет подключен к сети, поэтому все этапы конфигурирования и защиты серверов, выполняемые с подключением к сети, нужно изменить соответствующим образом. ###### Конфигурационные данные, задаваемые пользователем В следующей таблице приведены специфичные для организации параметры, которые следует определить перед началом развертывания решения, описываемого далее. Во многих местах при этом будут использоваться заполнители, характеризующие параметры в формате, похожем на формат их имен. Например, DNS-имя корневого домена леса Active Directory может быть отображено как *ИмяДомена*.ru. Значения, набранные курсивом, следует заменить конкретными параметрами корпоративной среды, собранными в процессе развертывания. **Таблица 7. Конфигурационные параметры, задаваемые пользователем**

Параметр	Ссылка	Значение
DNS-имя леса Active Directory
Различающееся имя корня леса	Pkiparams.vbs
NetBIOS-имя домена
NetBIOS-имя рабочей группы корневого центра сертификации
Имя сервера корневого центра сертификации
Имя сервера выдающего центра сертификации
Общее имя X.500 корневого центра сертификации
Общее имя X.500 выдающего центра сертификации
Полное имя веб-сервера, используемого для публикации сертификатов центров сертификации	Pkiparams.vbs

###### Конфигурационные параметры, определяемые решением Параметры, указанные в следующей таблице, не следует изменять, если нет уверенности в правильности запланированных действий. Перед их изменением нужно полностью разобраться с любыми последствиями этого и всеми зависимостями, которые могут быть при этом нарушены. **Таблица 8. Конфигурационные параметры, определяемые решением**

Параметр	Ссылка	Значение
Группы безопасности административных ролей
Администраторы контейнера конфигурации службы открытых ключей.	ca_setup.wsf	Enterprise PKI Admins
Группа администраторов с правом публикации списков отзыва сертификатов и сертификатов центров сертификации в корпоративном контейнере конфигурации.	ca_setup.wsf	Enterprise PKI Publishers
Группа администраторов, которые конфигурируют и обслуживают центры сертификации, а также контролируют возможность назначения всех остальных ролей центра сертификации и обновления сертификата центра сертификации.	ca_setup.wsf	CA Admins
Группа администраторов, утверждающих заявки на сертификаты и запросы отзыва сертификатов (роль должностного лица центра сертификации).	ca_setup.wsf	Certificate Managers
Группа администраторов, управляющих журналами аудита и безопасности центров сертификации.	ca_setup.wsf	CA Auditors
Группа администраторов, управляющих резервным копированием данных центров сертификации.	ca_setup.wsf	CA Backup Operators
Конфигурация служб IIS
Имя виртуального каталога IIS, используемого для публикации сертификата центра сертификации и списка отзыва сертификатов.	Pkiparams.vbs	pki
Физический путь в выдающем центре сертификации, сопоставленный с виртуальным каталогом IIS.	C:\CAWWWPub	Pkiparams.vbs
Общие параметры центра сертификации
Имя диска, на котором хранятся файлы запросов служб сертификации, и путь к этим файлам.	C:\CAConfig	Pkiparams.vbs
Имя диска, на котором хранятся журналы баз данных служб сертификации, и путь к этим журналам.		%windir%\System32\CertLog
Конфигурация корневого центра сертификации
Длина ключа корневого центра сертификации (см. примечание)	4096
Срок действия сертификата корневого центра сертификации (в годах)	Pkiparams.vbs	16
Максимальный срок действия сертификатов, выданных корневым центром сертификации (в годах)	Pkiparams.vbs	8
Интервал публикации списка отзыва сертификатов корневым центром сертификации (в месяцах)	Pkiparams.vbs	6
Период перекрытия списков отзыва сертификатов (в днях)	Pkiparams.vbs	10
Период публикации разностных списков отзыва сертификатов корневым центром сертификации (в часах, 0=отключить)	Pkiparams.vbs	0
Конфигурация выдающего центра сертификации
Имя диска, на котором хранится база данных служб сертификации, и путь к ней		D:\CertLog
Длина ключа выдающего центра сертификации		2048
Срок действия сертификата выдающего центра сертификации (в годах)	Pkiparams.vbs	8
Максимальный срок действия сертификатов выдающего центра сертификации (в годах)	Pkiparams.vbs	4
Интервал публикации списка отзыва сертификатов выдающим центром сертификации (в днях)	Pkiparams.vbs	7
Период перекрытия списков отзыва сертификатов (в днях)	Pkiparams.vbs	4
Период публикации разностных списков отзыва сертификатов выдающим центром сертификации (в днях, 0=отключить)	Pkiparams.vbs	1
Период перекрытия разностных списков отзыва сертификатов (в днях)	Pkiparams.vbs	1
Прочие параметры
Путь к сценариям установки		C:\MSSScripts

**Примечание**. Использование ключей длиной 4096 бит некоторыми устройствами или старыми приложениями других компаний может привести к проблемам с совместимостью. Все приложения, которые, возможно, будут использовать сертификаты, выдаваемые корневым центром сертификации, следует протестировать с ключами сертификатов этого размера. Если возникнут сомнения в совместимости длины ключа корневого центра сертификации, ее можно уменьшить до 2048 бит. ###### Установка конфигурационных сценариев на серверы центров сертификации Сценарии, прилагаемые к этому руководству, облегчают установку решения, описанную в следующих разделах. Эти сценарии должны быть установлены на каждом сервере центра сертификации. Удалять их после использования не следует — это поможет управлять серверами. Чтобы установить эти сценарии, сначала создайте папку C:\\MSSScripts, после чего скопируйте их в нее. ###### Установка и конфигурирование служб IIS на сервере выдающего центра сертификации Службы IIS (Internet Information Services) используются клиентами, работающими под управлением ОС, отличных от Windows, для получения сертификатов центров сертификации и списков отзыва сертификатов. Корневой центр сертификации может не предоставлять доступ к этим службам, потому что он не будет подключен к сети, но выдающий центр сертификации должен иметь доступ к ним. Службы IIS можно также использовать для размещения страниц службы подачи заявок на сертификат через Интернет, но в рассматриваемом решении это не используется. Если страницы подачи заявок на сертификаты через Интернет установлены на сервере, отличном от сервера выдающего центра сертификации, нужно установить для этого сервера отметку «Делегирование разрешено» в объекте сервера в службе Active Directory. Службы IIS можно установить с помощью диспетчера дополнительных компонентов Windows, доступ к которому осуществляется через панель управления (элемент «Установка и удаление компонентов»). В следующем списке указаны компоненты, которые необходимо установить. - Сервер приложений - Модуль поддержки сетевого доступа COM+ - Службы Internet Information Services - Общие файлы - Диспетчер служб Internet Information Services - Служба WWW **Чтобы установить службы IIS, выполните следующие действия.** 1. Введите в командной строке следующую команду: ``` Sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_AddIIS.txt ``` Эта команда указывает диспетчеру дополнительных компонентов Windows на необходимость использовать следующие конфигурационные параметры компонентов, заданные в файле автоматической установки C:\\MSSScripts\\OC\_AddIIS.txt: ``` \[Components\] complusnetwork = On iis\_common = On iis\_asp = On iis\_inetmgr = On iis\_www = On ``` **Примечание**. При использовании этого конфигурационного файла будет установлен и компонент Active Server Pages (ASP). Если страницы службы подачи заявок на сертификаты через Интернет не нужны, перед запуском файла sysocmgr.exe установку ASP следует отменить, удалив из приведенного выше файла строку **iis\_asp = on**. В случае надобности этот параметр можно будет задать позднее. 2. Запустите диспетчер дополнительных компонентов еще раз с указанным ниже ключом и убедитесь в том, что установленные компоненты соответствуют приведенному выше списку. ``` sysocmgr /i:sysoc.inf ``` Никакие другие дочерние компоненты сервера приложений не нужны, и устанавливать их не требуется. Настройка IIS для доступа к сведениям о центрах сертификации (AIA) и публикации точки распространения списков отзыва сертификатов на выдающем центре сертификации На сервере IIS необходимо создать виртуальный каталог, который будет использоваться как HTTP-контекст пунктов публикации сертификатов центров сертификации и списков отзыва сертификатов. Эти пункты называются точкой доступа к сведениям о центрах сертификации (Authority Information Access, AIA) и точкой распространения списков отзыва сертификатов (CRL Distribution Point, CDP) соответственно. **Чтобы создать виртуальный каталог на сервере IIS, выполните следующие действия.** 1. Войдите на сервер IIS с правами локального администратора. 2. Создайте папку **C:\\CAWWWPub**, в которой будут храниться сертификаты центров сертификации и списки отзыва сертификатов. 3. Настройте параметры безопасности этой папки в соответствии со следующей таблицей. **Таблица 9. Разрешения на доступ к виртуальному каталогу**

<table style="border:1px solid black;">
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >Пользователь / группа</th>
<th style="border:1px solid black;" >Разрешение</th>
<th style="border:1px solid black;" >Предоставить / отказать</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">Администраторы</td>
<td style="border:1px solid black;">Полный доступ</td>
<td style="border:1px solid black;">Предоставить</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">System</td>
<td style="border:1px solid black;">Полный доступ</td>
<td style="border:1px solid black;">Предоставить</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">Владельцы-создатели</td>
<td style="border:1px solid black;">Полный доступ (только к вложенным папкам и файлам)</td>
<td style="border:1px solid black;">Предоставить</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">Пользователи</td>
<td style="border:1px solid black;">Чтение и просмотр содержимого папки</td>
<td style="border:1px solid black;">Предоставить</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">IIS_WPG</td>
<td style="border:1px solid black;">Чтение и просмотр содержимого папки</td>
<td style="border:1px solid black;">Предоставить</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">Гостевая учетная запись Интернета</td>
<td style="border:1px solid black;">Запись</td>
<td style="border:1px solid black;">Отказать</td>
</tr>
</tbody>
</table>

Используя консоль управления IIS, создайте новый виртуальный каталог на веб-узле по умолчанию:
- Назначьте виртуальному каталогу имя pki
- Укажите в качестве пути C:\CAWWWPub
Снимите в окне разрешений на доступ к виртуальному каталогу флажок «Запуск сценариев».
Убедитесь в том, что для виртуального каталога включена анонимная проверка подлинности.

Выбор DNS-псевдонима для пункта публикации HTTP

Для разрешения сервера IIS, на котором размещены точки доступа к сведениям о центрах сертификации и распространения списков отзыва сертификатов, нужно создать общий DNS-псевдоним (CNAME). Этот псевдоним будет использован в следующих разделах при настройке путей к этим точкам для центров сертификации. Используя псевдонимы, можно легко перемещать пункты публикации центров сертификации на другие серверы или сетевые устройства без выдачи новых сертификатов центров сертификации.

Другие операции по конфигурированию решения и компонентов операционной системы

Кроме уже описанных действий по настройке, рекомендуется также выполнить перечисленные ниже.

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

sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_RemoveRootUpdate.txt

  
    Файл OC\_RemoveRootUpdate.txt содержит следующие строки:
  
    ```  
\[Components\] rootautoupdate = off

Убедитесь в том, что корневой центр сертификации не подключен к сети и что выдающий центр сертификации не связан с Интернетом входящим или исходящим соединением.
Проверьте, нужно ли установить после установки IIS какие-либо дополнительные обновления.
Установите служебные программы Windows Server 2003. Делать это необязательно, но они пригодятся при выполнении некоторых операций с использованием центра сертификации, а также при поиске и устранении неполадок.
Установите библиотеку CAPICOM. Для выполнения некоторых сценариев установки и управления, распространяемых с этим руководством, в корневом и выдающем центрах сертификации должна быть установлена библиотека CAPICOM 2.1. Сведения о библиотеке CAPICOM и ссылку на ее загрузку можно найти по адресу www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=en (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Подготовка службы Active Directory к использованию инфраструктуры открытого ключа

Фундаментальные требования к инфраструктуре домена Active Directory, описанные в этом разделе, основаны на архитектуре службы Microsoft Windows Server 2003 Active Directory. Если используется служба Active Directory, реализованная в Windows 2000, требования могут быть другими. Дополнительные требования к структуре доменов, основанных на ОС Windows 2000, см. в документе «Повышение функционального уровня домена и леса в ОС Windows Server 2003», который можно найти по адресу http://support.microsoft.com/kb/322692 (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Кроме того, для использования рассматриваемого решения нужен функциональный уровень домена не ниже основного режима Windows 2000 — по крайней мере, в том домене, в котором будут установлены серверы центров сертификации. Это требование объясняется тем, что в решении используются универсальные группы Active Directory, которые доступны в основном режиме ОС Windows 2000 и более поздних версий.

Создание административных групп инфраструктуры открытого ключа и центров сертификации

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

Чтобы создать административные группы центра сертификации в домене, выполните следующие действия.

Войдите на компьютер, являющийся членом домена, используя учетную запись, которая позволяет создавать объекты пользователей и групп в контейнере «Пользователи» (Users).
Выполните для создания групп управления центром сертификации домена следующую команду:

Cscript //job:CertDomainGroups C:\MSSScripts\ca_setup.wsf

  
    Этот сценарий создаст группы безопасности, указанные в следующей таблице. Они будут созданы как универсальные группы в контейнере «Пользователи» (Users) домена, и их можно будет переместить в другие подразделения, если того потребуют какие-либо принятые в организации политики.
  
    **Таблица 10. Названия и описания групп**

 
    <table style="border:1px solid black;">
    <colgroup>
    <col width="50%" />
    <col width="50%" />
    </colgroup>
    <thead>
    <tr class="header">
    <th style="border:1px solid black;" >Название группы</th>
    <th style="border:1px solid black;" >Описание</th>
    </tr>
    </thead>
    <tbody>
    <tr class="odd">
    <td style="border:1px solid black;">Enterprise PKI Admins</td>
    <td style="border:1px solid black;">В эту группу входят администраторы контейнера конфигурации служб открытых ключей.</td>
    </tr>
    <tr class="even">
    <td style="border:1px solid black;">Enterprise PKI Publishers</td>
    <td style="border:1px solid black;">Члены этой группы могут публиковать списки отзыва сертификатов и сертификаты центров сертификации для контейнера конфигурации «Предприятие» (Enterprise).</td>
    </tr>
    <tr class="odd">
    <td style="border:1px solid black;">CA Admins</td>
    <td style="border:1px solid black;">Члены этой группы имеют полный административный контроль над центром сертификации, в том числе возможность определять членство других ролей.</td>
    </tr>
    <tr class="even">
    <td style="border:1px solid black;">Certificate Managers</td>
    <td style="border:1px solid black;">Члены этой группы управляют выдачей и отзывом сертификатов.</td>
    </tr>
    <tr class="odd">
    <td style="border:1px solid black;">CA Auditors</td>
    <td style="border:1px solid black;">Члены этой группы управляют данными об аудите центра сертификации.</td>
    </tr>
    <tr class="even">
    <td style="border:1px solid black;">CA Backup Operators</td>
    <td style="border:1px solid black;">Члены этой группы имеют разрешения на резервное копирование и восстановление ключей и данных центров сертификации.</td>
    </tr>
    </tbody>
    </table>
  
В процедурах установки, описываемых в оставшейся части документа, должны использоваться учетные записи из групп Enterprise PKI Admins, Enterprise PKI Publishers и CA Admins, поэтому перед продолжением их нужно заполнить этими учетными записями. Если все роли, имеющие отношение к центру сертификации, возложены на одного человека, всем группам можно назначить одну учетную запись, однако в большинстве компаний роли и обязанности сотрудников в той или иной степени разделены, хотя и не по такой сложной схеме, как в приведенной выше таблице. В компаниях с упрощенным разделением служебных обязанностей часто делят области ответственности следующим образом.
  
**Таблица 11. Упрощенная модель администрирования**

 
<table style="border:1px solid black;">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >Административная роль</th>
<th style="border:1px solid black;" >Членство в группах</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">CA Administrator</td>
<td style="border:1px solid black;">Enterprise PKI Admins, CA Admins, Certificate Managers, Administrators</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">CA Auditor</td>
<td style="border:1px solid black;">CA Auditors, Administrators</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">CA Backup Operator</td>
<td style="border:1px solid black;">CA Backup Operators</td>
</tr>
</tbody>
</table>
  
###### Рекомендуемая структура подразделений домена
  
Управлять инфраструктурой открытых ключей и использовать ее будут несколько групп и пользовательских учетных записей. Возможно, их потребуется организовать в ту или иную структуру подразделений — это зависит от действующих политик. Так как эта структура может определяться уже используемыми корпоративными политиками, ниже предлагается один из вариантов, который можно изменять в соответствии с конкретными потребностями.
  
**Чтобы создать иерархию подразделений, работающих со службами сертификации, выполните следующие действия.**
  
1.  Войдите в систему, используя учетную запись, позволяющую создавать подразделения и делегировать в них разрешения.
  
2.  Создайте структуру подразделений в соответствии со следующей таблицей.
  
    **Таблица 12. Пример структуры подразделения**

 
    <table style="border:1px solid black;">
    <colgroup>
    <col width="50%" />
    <col width="50%" />
    </colgroup>
    <thead>
    <tr class="header">
    <th style="border:1px solid black;" >Подразделение</th>
    <th style="border:1px solid black;" >Описание</th>
    </tr>
    </thead>
    <tbody>
    <tr class="odd">
    <td style="border:1px solid black;">Certificate Services</td>
    <td style="border:1px solid black;">Родительское подразделение</td>
    </tr>
    <tr class="even">
    <td style="border:1px solid black;">\-Certificate Services Administration</td>
    <td style="border:1px solid black;">Содержит административные группы, управляющие центрами сертификации и конфигурацией корпоративной инфраструктуры открытых ключей.</td>
    </tr>
    <tr class="odd">
    <td style="border:1px solid black;">\-Certificate Template Management</td>
    <td style="border:1px solid black;">Содержит группы, управляющие отдельными шаблонами сертификатов.</td>
    </tr>
    <tr class="even">
    <td style="border:1px solid black;">\-Certificate Template Enrollment</td>
    <td style="border:1px solid black;">Содержит группы, имеющие разрешения на подачу заявок или автоматическую подачу заявок в одноименных шаблонах. Контроль над этими группами можно делегировать соответствующим сотрудникам без изменения самих шаблонов.</td>
    </tr>
    <tr class="odd">
    <td style="border:1px solid black;">\-Certificate Services Test Users</td>
    <td style="border:1px solid black;">Содержит временные тестовые учетные записи.</td>
    </tr>
    </tbody>
    </table>
  
3.  Предоставьте группе Enterprise PKI Admins разрешения на создание и удаление групп в подразделении служб сертификации и его дочерних контейнерах.
  
###### Предоставление разрешений контейнеру служб открытых ключей
  
Параметры безопасности контейнера служб открытых ключей нужно изменить так, чтобы члены группы Enterprise PKI Admins могли устанавливать центры сертификации предприятия и конфигурировать шаблоны сертификатов, не являясь при этом членами группы Enterprise Admins. Кроме того, членам группы Enterprise PKI Publishers нужно разрешить публиковать списки отзыва сертификатов и сертификаты центров сертификации без прав Enterprise Admin.
  
Для внесения следующих изменений нужно использовать учетную запись, эквивалентную Active Directory Enterprise Admin.
  
**Чтобы предоставить разрешения членам группы Enterprise PKI Admins, выполните следующие действия.**
  
1.  Войдите в систему как член группы безопасности Enterprise Admins.
  
2.  В оснастке консоли управления «Active Directory — сайты и службы» откройте в меню **«Вид»** узел **«Службы»**, после чего найдите вложенный контейнер Public Key Services и откройте его свойства.
  
3.  Добавьте на вкладке **«Безопасность»** группу безопасности Enterprise PKI Admins и предоставьте ей полный контроль.
  
4.  В **режиме расширенного просмотра** измените разрешения этой группы так, чтобы разрешение на полный доступ относилось к данному объекту и всем дочерним объектам.
  
5.  Выберите контейнер **«Службы»** и откройте его свойства.
  
6.  Добавьте на вкладке **«Безопасность»** группу безопасности Enterprise PKI Admins и предоставьте ей полный доступ.
  
7.  В **режиме расширенного просмотра** измените разрешения этой группы так, чтобы разрешение на полный доступ относилось только к данному объекту.
  
**Чтобы предоставить разрешения членам группы Enterprise PKI Publishers, выполните следующие действия.**
  
1.  Войдите в систему как член группы безопасности Enterprise Admins.
  
2.  В оснастке консоли управления «Active Directory — сайты и службы» отобразите узел **«Службы»** и откройте свойства контейнера Public Key Services\\AIA.
  
3.  Добавьте на вкладке **«Безопасность»** группу безопасности Enterprise PKI Publishers и предоставьте ей разрешения на выполнение перечисленных ниже операций.
  
    -   Чтение
  
    -   Запись
  
    -   Создание всех дочерних объектов
  
    -   Удаление всех дочерних объектов
  
4.  В **режиме расширенного просмотра** измените разрешения этой группы так, чтобы они относились к данному объекту и всем дочерним объектам.
  
5.  Повторите этапы 2—4 для следующих контейнеров:
  
    -   Public Key Services\\CDP
  
    -   Public Key Services\\Certification Authorities
  
###### Предоставление разрешений членам группы Cert Publishers
  
Все учетные записи компьютеров центра сертификации предприятия в домене будут относиться к группе безопасности Cert Publishers. Эта группа будет использоваться для применения разрешений к объектам пользователей и компьютеров, а также к объектам в контейнере CDP, упомянутом в описании предыдущей процедуры. При каждой установке центра сертификации учетную запись его компьютера нужно будет добавлять в эту группу.
  
Чтобы члены группы Enterprise PKI Admins могли устанавливать центры сертификации предприятия, нужно изменить разрешения этой группы.
  
**Чтобы предоставить разрешения на изменение членства группе Cert Publishers, выполните следующие действия.**
  
1.  Войдите в систему как член группы Domain Admins в домене, в котором будут установлены выдающие центры сертификации.
  
2.  Запустите оснастку консоли управления «Active Directory — пользователи и компьютеры».
  
3.  Откройте меню **«Вид»** и убедитесь в том, что элемент **«Дополнительные параметры»** выбран.
  
4.  Найдите группу Cert Publishers (по умолчанию она находится в контейнере Users) и отобразите ее свойства.
  
5.  На вкладке **«Безопасность»** добавьте группу Enterprise PKI Admins и нажмите кнопку **«Дополнительно»**.
  
6.  Выберите из списка группу Enterprise PKI Admins и нажмите кнопку **«Изменить»**.
  
7.  Откройте вкладку **«Свойства»** и убедитесь в том, что в поле **«Применять»** выбран вариант **«Только для этого объекта»**.
  
8.  Прокрутите столбец **«Разрешить»** и щелкните в нем поле **«Запись членов» (Write Members)**.
  
9.  Сохраните изменения и закройте по очереди все диалоговые окна, нажимая кнопку **ОК**.
  
10. Перезапустите сервер выдающего центра сертификации перед установкой компонента «Службы сертификации». После перезапуска сервер сможет выбрать членство в новой группе в своем маркере доступа.
  
###### Предоставление разрешений на восстановление группе Enterprise PKI Admins
  
Для установки служб сертификации необходимо право на восстановление файлов и каталогов в том домене, в котором будет размещен центр сертификации предприятия. Оно необходимо для объединения дескрипторов безопасности шаблонов и других объектов каталогов, что позволяет предоставить корректные разрешения объектам инфраструктуры открытых ключей домена. Имеющиеся в домене группы администраторов, операторов сервера и операторов архива имеют это право по умолчанию.
  
Так как для установки центра сертификации будет использована группа Enterprise PKI Admins, ей нужно предоставить право на восстановление файлов и каталогов.
  
**Чтобы предоставить разрешения на восстановление файлов и каталогов группе Enterprise PKI Admins, выполните следующие действия.**
  
1.  Войдите в систему как член группы администраторов домена, в котором будет установлен выдающий центр сертификации.
  
2.  Запустите оснастку консоли управления «Active Directory — пользователи и компьютеры».
  
3.  Выберите подразделение контроллеров домена и откройте его свойства.
  
4.  На вкладке **«Групповая политика»** выберите пункт **«GPO — политика контроллеров домена по умолчанию»** и нажмите на кнопку **«Изменить»**.
  
5.  Откройте папку Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment и дважды щелкните **«Восстановление файлов и каталогов»**.
  
6.  Добавьте в отображенный список группу Enterprise PKI Admins.
  
7.  Закройте диалоговое окно и консоль управления объектами групповой политики.
  
    **Примечание**.   Если есть другие объекты групповой политики, задающие на контроллерах домена право пользователя на восстановление файлов и каталогов, эту процедуру нужно выполнять с использованием объекта с наивысшим приоритетом, а не с использованием политики контроллеров домена по умолчанию. Параметры прав пользователей не накапливаются, и будет действовать только последний примененный объект групповой политики, имеющий это право.
  
###### Конфигурирование сервера корневого центра сертификации
  
Как было сказано выше, в этом руководстве не приводятся пошаговые инструкции по установке ОС Windows Server 2003, потому что в большинстве компаний уже имеется документированный процесс установки серверов. Серверы корневых центров сертификации отличаются от других серверов в том смысле, что их никогда не подключают к сети; это нужно для того, чтобы они не были скомпрометированы.
  
Таким образом, при установке и настройке сервера корневого центра сертификации нужно гарантировать, что он не будет подключен к сети. На некотором этапе для предотвращения случайного подключения нужно отключить его сетевые адаптеры. Из-за того, что этот сервер не будет подключен к сети, он будет находиться в рабочей группе, имя которой следует выбрать и зафиксировать перед установкой сервера.
  
**Примечание**.   Несмотря на то, что корневой центр сертификации создается и работает в автономном режиме, его имя должно быть уникальным в сетевой среде.
  
###### Файл CAPolicy.inf
  
Выбрав подходящий сервер для создания корневого центра сертификации и установив на него операционную систему, следует создать файл capolicy.inf. Этот файл необходим для создания корневого центра сертификации, потому что он определяет характеристики сертификата корневого центра сертификации с собственной подписью, такие как длина ключа и срок действия сертификата.
  
Информация о списках отзыва сертификатов и доступа к сведениям о центрах сертификации не нужна для сертификата корневого центра сертификации, поэтому в файле capolicy.inf параметры CRLDistributionPoint и AuthorityInformationAccess имеют значение Empty.
  
**Чтобы создать файл CAPolicy.inf, выполните следующие действия.**
  
1.  Используя Блокнот или другой текстовый редактор, создайте обычный текстовый файл со следующим текстом:
  
    ```  
\[version\] Signature=”$Windows NT$” \[Certsrv\_server\] RednewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=16 \[CRLDistributionPoint\] Empty=true \[AuthorityInformationAccess\] Empty=true

Если для центра сертификации определено заявление об использовании сертификатов, включите в файл capolicy.inf следующий текст, заменяя значения, набранные курсивом, значениями, специфичными для используемой реализации:

[CAPolicy] Policies=company CPS name [company CPS name] OID=the.company.OID URL=”http://www.companyurl.com/cpspagename.htm”

  
3.  Сохраните этот текстовый файл как *%windir%*\\Capolicy.inf (замените *%windir%* абсолютным путем к папке установки Windows, например C:\\Windows). Для сохранения этого файла в папке Windows нужно использовать учетную запись администратора или учетную запись с эквивалентными разрешениями.
  
###### Установка программных компонентов служб сертификации
  
Воспользуйтесь для установки программных компонентов центра сертификации мастером компонентов Windows. Имейте в виду, что для их установки необходим доступ к носителю с установочными файлами ОС Windows Server 2003.
  
**Чтобы установить службы сертификации, выполните следующие действия.**
  
1.  Войдите в систему как член группы локальных администраторов и запустите диспетчер дополнительных компонентов или откройте панель управления, дважды щелкните значок «Установка и удаление программ» и выберите установку компонентов Windows.
  
    ```  
sysocmgr /i:sysoc.inf

Выберите службы сертификации (чтобы проигнорировать предупреждение об изменении имени, нажмите на кнопку «Да»).
Выберите в качестве типа центра сертификации «Изолированный корневой ЦС» и убедитесь в том, что флажок «Использовать пользовательские параметры» установлен.
Оставьте значения по умолчанию в диалоговом окне «Пара из открытого и закрытого ключей» неизменными за исключением поля «Длина ключа», в котором нужно задать значение 4096, и поля «Тип поставщика (CSP)», в котором нужно задать значение Microsoft Strong Cryptographic Provider.
Введите в следующие поля идентификационную информацию о центре сертификации, собранную на этапе подготовки.
- Общее имя центра сертификации:
- Суффикс различающегося имени:
- Срок действия: 8 лет
После этого поставщик службы криптографии сгенерирует пару ключей, которая будет сохранена в локальном хранилище ключей.

Примечание. Если в системе ранее был установлен центр сертификации, появится диалоговое окно с предупреждением о перезаписи имеющегося закрытого ключа. Прежде чем продолжить, убедитесь в том, что этот ключ больше никогда не потребуется.
Местоположения базы данных сертификатов, журналов базы данных и конфигурационной папки оставьте без изменений. После этого диспетчер дополнительных компонентов установит компоненты служб сертификации, и для продолжения процесса потребуется носитель с установочными файлами ОС Windows Server 2003.
Нажмите кнопку ОК, чтобы проигнорировать предупреждения, связанные со службами IIS, и продолжите процесс установки до его завершения.

Настройка свойств корневого центра сертификации

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

Чтобы настроить свойства корневого центра сертификации, выполните следующие действия.

Войдите на сервер центра сертификации как член группы локальных администраторов.
Измените сценарий C:\MSSScripts\pkiparams.vbs следующим образом:
- Назначьте параметру AD_ROOT_DN различающееся имя домена корня леса Active Directory.
- Измените параметр HTTP_PKI_VROOT в соответствии с HTTP-путем к виртуальному каталогу IIS, созданному ранее.
Выполните следующий сценарий:

Cscript //job:RootCAConfig C:\MSSScripts\ca_setup.wsf

  
###### Настройка административных ролей
  
Чтобы можно было использовать группы безопасности, созданные ранее, их нужно сопоставить с административными ролями, такими как аудитор и диспетчер сертификатов.
  
**Примечание**.   Скорее всего, в большинстве компаний будет реализована упрощенная модель делегирования, упомянутая выше, но на тот случай, если потребуется дополнительное разделение, ниже описывается более гибкая модель.
  
**Чтобы настроить административные роли корневого центра сертификации, выполните следующие действия.**
  
1.  Запустите консоль управления центром сертификации и щелкните пункт **«Свойства»**.
  
2.  Откройте вкладку **«Безопасность»** и добавьте локальные группы безопасности, указанные в следующей таблице, с соответствующими разрешениями.
  
    **Таблица 13. Разрешения на работу с центром сертификации**

 
    <table style="border:1px solid black;">
    <colgroup>
    <col width="33%" />
    <col width="33%" />
    <col width="33%" />
    </colgroup>
    <thead>
    <tr class="header">
    <th style="border:1px solid black;" >Группа</th>
    <th style="border:1px solid black;" >Разрешение</th>
    <th style="border:1px solid black;" >Предоставить / отказать</th>
    </tr>
    </thead>
    <tbody>
    <tr class="odd">
    <td style="border:1px solid black;">CA Admins</td>
    <td style="border:1px solid black;">Управление центром сертификации</td>
    <td style="border:1px solid black;">Предоставить</td>
    </tr>
    <tr class="even">
    <td style="border:1px solid black;">Certificate Managers</td>
    <td style="border:1px solid black;">Выдача сертификатов и управление ими</td>
    <td style="border:1px solid black;">Предоставить</td>
    </tr>
    </tbody>
    </table>
  
3.  Другие роли безопасности центра сертификации уже были определены для этого сервера с помощью политики безопасности.
  
###### Запись сертификата и списка отзыва сертификатов корневого центра сертификации на диск
  
Сертификат и список отзыва сертификатов корневого центра сертификации нужно скопировать с центра сертификации, чтобы их можно было опубликовать в Active Directory и на сервере публикаций сертификатов IIS и списков отзыва сертификатов. В приведенном ниже примере используется диск, но вместо него можно использовать любой съемный носитель, в том числе накопители с интерфейсом USB.
  
**Запись сертификата и списка отзыва сертификатов корневого центра сертификации на диск**
  
1.  Войдите на сервер корневого центра сертификации как член локальной группы CA Admins и вставьте в систему съемный носитель.
  
2.  Выполните следующий сценарий, чтобы скопировать сертификат центра сертификации на диск:
  
    ```  
Cscript //job:GetCACerts C:\\MSSScripts\\CA\_Operations.wsf

Выполните следующий сценарий, чтобы скопировать сертификат центра сертификации на диск:

Cscript //job:GetCRLs C:\MSSScripts\CA_Operations.wsf

  
4.  Пометьте диск, укажите на нем дату и сохраните для использования в будущем.
  
###### Публикация сведений о корневом центре сертификации
  
Перед установкой выдающего центра сертификации нужно опубликовать сертификат корневого центра сертификации в хранилище доверенного корня службы Active Directory, а список отзыва сертификатов корневого центра сертификации — в контейнере CDP службы Active Directory. В ходе этого все члены домена импортируют сертификаты корневого центра сертификации в свои хранилища доверенного корня, что позволяет им проверять статус отзыва любых сертификатов, выданных корневым центром сертификации.
  
Для выполнения этой процедуры лучше всего использовать выдающий центр сертификации, потому что в нем установлены необходимые библиотеки Certutil.exe, certadm.dll и certcli.dll, но с этой же целью можно использовать любой сервер, являющийся членом домена и работающий под управлением ОС Windows Server 2003, если на нем есть файл certutil.exe и установлены поддерживающие DLL-библиотеки.
  
**Чтобы опубликовать сертификат и список отзыва сертификатов корневого центра сертификации в службе Active Directory, выполните следующие действия.**
  
1.  Войдите в систему, которая является членом домена и отвечает приведенным выше требованиям, как член группы Enterprise PKI Admins и вставьте диск, на котором были сохранены сертификат и список отзыва сертификатов корневого центра сертификации.
  
2.  Выполните следующий сценарий, чтобы опубликовать сертификат центра сертификации в службе Active Directory:
  
    ```  
Cscript //job:PublishCertstoAD C:\\MSSScripts\\CA\_Operations.wsf

Выполните следующий сценарий, чтобы опубликовать список отзыва сертификатов в службе Active Directory:

Cscript //job:PublishCRLstoAD C:\MSSScript\CA_Operations.wsf

  
###### Публикация сертификата и списка отзыва сертификатов корневого центра сертификации на веб-сервере
  
Выполнить эту задачу необходимо потому, что в расширениях сертификатов, выдаваемых этим центром сертификации, указываются HTTP-версии URL-адресов CDP и AIA. Если эти расширения указаны, они должны быть соблюдены за счет публикации сертификатов и списков отзыва сертификатов по указанным URL-адресам.
  
**Примечание**.   Эта процедура не зависит от того, установлен ли веб-сервер публикации CDP и AIA на выдающем центре сертификации, но она предполагает, что виртуальный каталог соответствует каталогу, созданному ранее для конфигурирования IIS (C:\\CAWWWPub). Если был выбран другой путь, значение WWW\_LOCAL\_PUB\_PATH в сценарии PKIParams.vbs нужно будет изменить.
  
**Чтобы опубликовать сертификат и список отзыва сертификатов корневого центра сертификации на веб-сервере, выполните следующие действия.**
  
1.  Войдите на веб-сервер, используя учетную запись локального администратора или эквивалентную ей.
  
2.  Убедитесь в наличии в компьютере диска с сертификатом и списком отзыва сертификатов корневого центра сертификации.
  
3.  Выполните следующий сценарий, чтобы опубликовать сертификат центра сертификации в папке веб-сервера:
  
    ```  
Cscript //job:PublishRootCerttoIIS C:\\MSSScripts\\CA\_Operations.wsf

Выполните следующий сценарий, чтобы опубликовать список отзыва сертификатов центра сертификации в папке веб-сервера:

Cscript //job:PublishRootCRLstoIIS C:\MSSScripts\CA_Operations.wsf

  
###### Развертывание сервера выдающего центра сертификации
  
После установки корневого центра сертификации и публикации его сертификатов можно развернуть сервер выдающего центра сертификации. Установка служб сертификации включает сложную совокупность взаимодействий между выдающим и корневым центрами сертификации, службой Active Directory и веб-сервером. Эти взаимодействия поясняет следующая диаграмма.
  
[![](/security-updates/images/Cc875845.SWCG5(ru-ru,TechNet.10).gif)](https://technet.microsoft.com/ru-ru/cc875845.swcg5_big(ru-ru,technet.10).gif)
  
**Рис. 5.Процесс установки сертификата**
  
Цифры на диаграмме обозначают указанные ниже взаимодействия.
  
1.  Публикация сертификата и списка отзыва сертификатов корневого центра сертификации в службе Active Directory с использованием съемного носителя.
  
2.  Публикация сертификата и списка отзыва сертификатов корневого центра сертификации на веб-сервере с использованием съемного носителя.
  
3.  Установка служб сертификации, генерирующих запрос сертификата, который нужно будет доставить с использованием съемного носителя в корневой центр сертификации, где на основе этого запроса будет выдан сертификат.
  
4.  Установка соответствующего сертификата выдающего центра сертификации с использованием съемного носителя.
  
5.  Публикация сертификата и списка отзыва сертификатов выдающего центра сертификации на веб-сервере.
  
    x.   Этот этап выполняется автоматически в ходе установки центра сертификации предприятия.
  
###### Подготовка файла Capolicy.inf для выдающего центра сертификации
  
Вообще говоря, выдающему центру сертификации файл CAPolicy.inf не нужен. Он требуется, если нужно изменить размер ключа, используемого центром сертификации. Этот файл следует создать перед установкой выдающего центра сертификации, хотя в случае необходимости его можно будет добавить позднее, а затем обновить сертификат центра сертификации.
  
**Чтобы создать файл CAPolicy.inf, выполните следующие действия.**
  
1.  Войдите на сервер выдающего центра сертификации, используя учетную запись локального администратора или эквивалентную ей.
  
2.  Используя Блокнот или другой текстовый редактор, создайте обычный текстовый файл со следующим содержимым:
  
    ```  
\[Version\] Signature= “$Windows NT$” \[Certsrv\_Server\] RenewalKeyLength=2048

Если для центра сертификации определено заявление об использовании сертификатов, включите в файл Capolicy.inf следующие строки:

[CAPolicy] Policies=policyname [policyname] OID=the.org.oid URL=”http://the.org.url/TheCPSPage.htm”

  
    **Примечание**.   Значения, набранные курсивом, нужно заменить информацией, специфичной для конкретной организации.
  
4.  Сохраните этот файл как *%windir%*\\Capolicy.inf (замените *%windir%* абсолютным путем к папке установки Windows, например C:\\Windows).
  
###### Установка программных компонентов служб сертификации
  
Как и при установке служб сертификации на корневой центр сертификации, для выполнения этого этапа нужно будет использовать носитель с установочными файлами ОС Windows Server 2003, а также мастер компонентов Windows.
  
**Чтобы установить службы сертификации, выполните следующие действия.**
  
1.  Войдите в систему выдающего центра сертификации, используя учетную запись члена группы локальных администраторов или эквивалентную ей, и запустите диспетчер дополнительных компонентов:
  
    ```  
sysocmgr /i:sysoc.inf

Выберите службы сертификации и нажмите на кнопку ОК, чтобы проигнорировать предупреждение об изменении имени.
Выберите в качестве типа центра сертификации «Подчиненный ЦС предприятия» и убедитесь в том, что флажок «Использовать пользовательские параметры» установлен.
Большинство значений по умолчанию в диалоговом окне «Пара из открытого и закрытого ключей» следует оставить неизменными. Внесите только следующие изменения:
- Установите длину ключа равной 2048 битам
- Задайте в качестве типа поставщика (CSP) значение Microsoft Strong Cryptographic Provider
Введите указанные ниже сведения о центре сертификации.
- Общее имя центра сертификации
- Суффикс различающегося имени
- Срок действия: (определенный родительским центром сертификации)
После этого поставщик службы криптографии сгенерирует пару ключей и запишет ее в хранилище ключей на локальном компьютере.
Введите предложенные ниже местоположения базы данных сертификатов, журналов базы данных и конфигурационной папки.
- База данных сертификатов: D:\CertLog
- Журнал базы данных сертификатов: %windir%\System32\CertLog
- Общая папка: Disabled
Ради повышения производительности и надежности базу данных центра сертификации и журналы следует по мере возможности хранить на разных физических дисках. База данных сертификатов и журналы базы данных должны находиться на локальных дисках с файловой системой NTFS.
Теперь будет создан файл запроса сертификата, который следует скопировать на диск. После этого диспетчер дополнительных компонентов начнет установку компонентов служб сертификации, для чего потребуется носитель с установочными файлами ОС Windows Server 2003.
Нажмите на кнопку ОК, чтобы проигнорировать предупреждение о службах IIS, и продолжите процесс установки до его завершения. Мастер установки отобразит уведомление о том, что для продолжения необходим сертификат родительского центра сертификации.

Запрос сертификата у корневого центра сертификации

Теперь нужно доставить запрос сертификата выдающего центра сертификации корневому центру сертификации, чтобы этот запрос был подписан, а выдающему центру сертификации был выдан сертификат.

Чтобы отправить запрос сертификата корневому центру сертификации, выполните следующие действия.

Войдите в систему корневого центра сертификации, используя учетную запись члена группы Certificate Managers.
Убедитесь в том, что в компьютере находится диск, на котором был сохранен файл запроса сертификата.
Выберите в меню «Задачи ЦС» консоли управления центром сертификации пункт «Выдать новый запрос» и отправьте запрос, полученный от выдающего центра сертификации.
Найдите выданный сертификат в контейнере выданных сертификатов и откройте его.
Убедитесь в том, что сведения о сертификате верны, и экспортируйте сертификат в файл, нажав кнопку «Копировать в файл». Сохраните файл на диске в виде файла PKCS#7 и укажите, что в цепочку нужно включить все возможные сертификаты, задав соответствующий параметр.

Обновление информации о сертификатах в выдающем центре сертификации

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

Чтобы обновить и проверить информацию о доверии сертификатов в выдающем центре сертификации, выполните следующие действия.

Войдите в систему выдающего центра сертификации, используя учетную запись локального администратора или эквивалентную ей.
Введите в командной строке следующую команду:

certutil –pulse

  
    Эта команда указывает центру сертификации загрузить новую информацию о доверенном корне из каталога и поместить сертификат корневого центра сертификации в собственное хранилище доверенного корня. Этот этап необязателен, но игнорировать его не следует, так как он позволяет убедиться в том, что предыдущие этапы публикации были выполнены успешно.
  
3.  Запустите файл mmc.exe и добавьте оснастку «Сертификаты».
  
4.  Выберите в качестве хранилища сертификатов, которым нужно управлять, вариант **«Учетная запись компьютера»**.
  
5.  Убедитесь в том, что сертификат корневого центра сертификации находится в папке Trusted Root Certificate Authorities.
  
###### Установка сертификата в выдающем центре сертификации
  
Подписанный ответ корневого центра сертификации уже создан как пакет сертификатов PKCS\#7, и теперь его можно установить в выдающем центре сертификации. Для публикации сертификата центра сертификации в хранилище NTAuth службы Active Directory, которое идентифицирует центр сертификации как центр сертификации предприятия, этот сертификат нужно установить, используя учетную запись, входящую в выдающем центре сертификации в группу Enterprise PKI Admins и локальную группу Administrators. Первая группа имеет права на установку сертификата центра сертификации в каталог, а вторая — на установку сертификата на сервере центра сертификации. Если используется уже упоминавшаяся простая модель администрирования, роль CAAdmin уже является членом обеих этих групп.
  
**Чтобы установить сертификат выдающего центра сертификации, выполните следующие действия.**
  
1.  Войдите в систему выдающего центра сертификации, используя учетную запись, входящую в группу Enterprise PKI Admins и локальную группу Administrators.
  
2.  Вставьте диск с подписанным сертификатом, выданным корневым центром сертификации.
  
3.  Выберите в меню **«Задачи ЦС»** консоли управления центром сертификации пункт **«Установить сертификат»**, чтобы установить сертификат выдающего центра сертификации с дискеты.
  
    После этого центр сертификации должен начать работу.
  
###### Настройка свойств выдающего центра сертификации
  
При выполнении следующей процедуры будут сконфигурированы специфичные для среды параметры, информация о которых была собрана при подготовке к созданию выдающего центра сертификации. Перед выполнением этого этапа важно убедиться в том, что собранная информация об организации включена в файл C:\\MSSScripts\\pkiparams.vbs в корневом центре сертификации и что эти изменения были также распространены на выдающий центр сертификации.
  
**Чтобы настроить свойства корневого центра сертификации, выполните следующие действия.**
  
1.  Войдите на сервер выдающего центра сертификации как член локальной группы администраторов.
  
2.  Убедитесь в том, что изменения, внесенные в файл C:\\MSSScripts\\pkiparams.vbs, соответствуют специфическим параметрам среды, описанным выше в этом разделе.
  
3.  Выполните следующий сценарий:
  
    ```  
Cscript //job:IssCAConfig C:\\MSSScripts\\ca\_setup.wsf

Настройка административных ролей выдающего центра сертификации

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

Чтобы настроить роли в выдающем центре сертификации, выполните следующие действия.

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

Откройте вкладку «Безопасность» и добавьте группы безопасности домена, указанные в следующей таблице, с соответствующими разрешениями.

Таблица 14. Разрешения на работу с выдающим центром сертификации

Группа	Разрешение	Предоставить / отказать
CA Admins	Управление центром сертификации	Предоставить
Certificate Managers	Выдача сертификатов и управление ими	Предоставить

Группу CA Auditors следует добавить в локальную группу администраторов, несмотря на то, что она уже была частично определена с помощью политики безопасности, заданной ранее.

Публикация сведений о выдающем центре сертификации

Сертификаты и списки отзыва сертификатов выдающего центра сертификации автоматически публикуются в службе Active Directory, но не по HTTP-путям CDP и AIA. Для автоматизации публикации сертификата центра сертификации по HTTP-путям CDP и AIA необходимо запланировать выполнение соответствующего задания.

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

Чтобы установить сертификат выдающего центра сертификации, выполните следующие действия.

Войдите в систему выдающего центра сертификации, используя учетную запись с разрешениями на запись данных в опубликованную папку веб-сервера.
Обновите параметр WWW_REMOTE_PUB_PATH в файле C:\MSSScripts\PKIParams.vbs, присвоив ему путь к папке веб-сервера.
1. Если веб-сервер установлен на удаленном сервере, убедитесь в том, что папка веб-сервера является общей, и запишите UNC-путь к этой папке.
2. Если веб-сервер установлен на том же сервере, что и центр сертификации, запишите локальный путь к этой папке (по умолчанию используется локальный путь C:\CAWWWPub).
Выполните следующий сценарий, чтобы опубликовать сертификат центра сертификации на веб-сервере:

Cscript //job:PublishIssCertsToIIS C:\MSSScripts\CA_Operations.wsf

  
    **Примечание**.   Эта процедура разработана для внутренних веб-серверов. Если сертификаты будут опубликованы на веб-сервере, подключенном к Интернету, нужно будет выполнить ряд дополнительных действий, потому что данное решение основано на совместном доступе к файлам через сеть Windows, который обычно блокируется брандмауэрами.
  
Списки отзыва сертификатов публикуются чаще, чем сертификаты центра сертификации, поэтому их публикацию на веб-сервере следует автоматизировать.
  
**Чтобы автоматизировать публикацию списков отзыва сертификатов, выполните следующие действия.**
  
1.  Войдите на сервер выдающего центра сертификации, используя учетную запись из группы локальных администраторов.
  
2.  Убедитесь в том, что с этого сервера доступна папка веб-сервера.
  
3.  Если веб-сервер является удаленным, выдающему центру сертификации потребуются права на запись данных в папку файловой системы (доступ с правом Modify) и в общее хранилище (доступ с правом Change). Если удаленный веб-сервер является членом леса, для предоставления доступа следует использовать группу Cert Publishers домена; это гарантирует, что любой центр сертификации предприятия сможет публиковать сертификаты и списки отзыва сертификатов.
  
4.  Создайте для копирования списков отзыва сертификатов запланированное задание, выполнив следующую команду:
  
    **Примечание**.   Следующий фрагмент кода разбит на строки исключительно ради удобства чтения. Его нужно ввести как одну строку.
  
    ```  
schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\\ MSSScripts\\CA\_Operations.wsf” /sc Hourly /ru “System”

Удаление ненужных шаблонов выдающего центра сертификации

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

Чтобы удалить ненужные сертификаты в выдающем центре сертификации, выполните следующие действия.

Войдите в систему как член группы CA Admins домена.
Выберите в консоли управления центром сертификации контейнер шаблонов сертификатов.
Удалите шаблоны следующих типов:
- Агент восстановления EFS
- Базовое шифрование EFS
- Веб-сервер
- Компьютер
- Пользователь
- Подчиненный центр сертификации
- Администратор

Проверка подлинности в Интернете

В этом разделе приводятся сведения о внедрении инфраструктуры RADIUS, обеспечивающей поддержку защищенного решения для беспроводных сетей, которое описывается в данном руководстве. Инфраструктура RADIUS, реализация которой описана в данном руководстве, основана на серверах проверки подлинности в Интернете ОС Windows Server 2003.

Проектирование инфраструктуры RADIUS

Приведенные ниже таблицы можно использовать для накопления необходимых данных, к которым мы будем обращаться в этом руководстве. Некоторые из этих данных задаются с использованием сценариев, прилагаемых к данному руководству, а другие устанавливаются вручную. Как это сделать, описано в соответствующих разделах.

Конфигурационные данные, задаваемые пользователем

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

Таблица 15. Параметры конфигурации, задаваемые пользователем

Параметр	Значение
DNS-имя корневого домена леса Active Directory
NetBIOS-имя домена
Имя основного сервера IAS
Имя дополнительного сервера IAS

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

Параметр	Значение
Полное имя административной группы, которой принадлежит контроль над конфигурацией службы проверки подлинности в Интернете	IAS Admins
Полное имя группы, члены которой проверяют журналы запросов и учета службы проверки подлинности в Интернете	IAS Security Auditors
Путь к сценариям установки	C:\MSSScripts
Командный файл экспорта конфигурации службы проверки подлинности в Интернете	IASExport.bat
Командный файл импорта конфигурации службы проверки подлинности в Интернете	IASImport.bat
Командный файл экспорта конфигурации клиента службы проверки подлинности в Интернете RADIUS	IASClientExport.bat
Командный файл экспорта конфигурации клиента службы проверки подлинности в Интернете RADIUS	IASClientImport.bat
Путь к файлам резервной копии конфигурации	D:\IASConfig
Путь к журналам запросов проверки подлинности и аудита службы проверки подлинности в Интернете	D:\IASLogs
Общее имя журналов запросов RADIUS	IASLogs

###### Создание серверов службы проверки подлинности в Интернете Рассматриваемое решение включает два центральных сервера службы проверки подлинности в Интернете, сконфигурированных как RADIUS-серверы для управления доступом к беспроводной сети. С учетом этого, прежде чем двигаться дальше, необходимо выполнить следующие задачи. - Выделить и настроить серверное оборудование. - Установить серверную ОС и настроить ее в соответствии с принятыми в организации процедурами. - Убедиться в наличии и нормальной работе службы Active Directory. - Проверить, заданы ли в организации процедуры укрепления защиты серверов, и установлены ли дополнительные приложения, требуемые утвержденными политиками. ###### Установка сценариев конфигурации К данному решению прилагаются многочисленные вспомогательные сценарии, упрощающие его реализацию. Прежде чем продолжить, эти сценарии нужно установить на каждый сервер. Удалять их не следует даже после выполнения всех действий, описанных в данном руководстве. **Чтобы установить конфигурационные сценарии, выполните следующие действия.** 1. Создайте папку C:\\MSSScripts. 2. Скопируйте сценарии в созданную папку. ###### Дополнительные требования к программному обеспечению сервер Кроме серверной операционной системы и всех приложений, использовать которые требуется в соответствии с утвержденной политикой создания серверов, на систему нужно установить исполняемый файл CAPICOM 2.1 и вспомогательные DLL-библиотеки для обеспечения поддержки сценариев, прилагаемых к данному руководству. Сведения о библиотеке [CAPICOM](http://www.microsoft.com/downloads/details.aspx?familyid=860ee43a-a843-462f-abb5-ff88ea5896f6&displaylang=en) и инструкции по ее загрузке можно найти по адресу www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=en (эта ссылка может указывать на содержимое полностью или частично на английском языке). ###### Настройка групп администрирования службы проверки подлинности в Интернете Следующая команда создает группы безопасности IAS Admins и IAS Security Auditors: ``` Cscript //job:CreateIASGroups C:\\MSSScripts\\IAS\_Tools.wsf ``` В средах с несколькими доменами эти группы следует создать в том же домене, в котором будут находиться серверы службы проверки подлинности в Интернете. После создания необходимых групп их нужно настроить так, чтобы он могли выполнять задачи конфигурирования службы проверки подлинности в Интернете. Это делается следующим образом. - Добавьте глобальную группу домена IAS Admins в локальную группу администраторов на каждом сервере службы проверки подлинности в Интернете. - Если серверы службы проверки подлинности в Интернете установлены на контроллерах домена, группу IAS Admins нужно добавить в группу администраторов домена. - Группы IAS Admins и IAS Security Auditors нужно заполнить соответствующими учетными записями пользователей. ###### Настройка параметров защиты сервера Как уже было сказано, в данном руководстве предполагается, что в большинстве компаний среднего размера уже утверждены и реализованы процедуры и политики укрепления защиты серверов. Таким образом, подробные инструкции по защите серверов, входящих в данное решение, здесь не приводятся. Если процедуры и политики укрепления защиты серверов не реализованы или необходима дополнительная информация о защите серверов службы проверки подлинности в Интернете, обратитесь к документу [«Руководство по обеспечению безопасности Windows 2003»](http://go.microsoft.com/fwlink/?linkid=14846), который находится по адресу http://go.microsoft.com/fwlink/?LinkId=14846 (эта ссылка может указывать на содержимое полностью или частично на английском языке). ###### Установка и конфигурирование службы проверки подлинности в Интернете В этом разделе рассматривается установка службы проверки подлинности в Интернете на серверы. Каждый этап установки и конфигурирования необходимо выполнить на каждом сервере службы проверки подлинности в Интернете. Для установки службы проверки подлинности в Интернете нужно выбрать в диспетчере дополнительных компонентов Windows (доступ к которому осуществляется через пункт «Установка и удаление компонентов» панели управления) компонент «Сетевые службы — служба проверки подлинности в Интернете». Чтобы упростить этот процесс, воспользуйтесь следующим сценарием: ``` sysocmgr /i:sysoc.inf /u:C:\\MSSScripts\\OC\_AddIAS.txt ``` ###### Регистрация службы проверки подлинности в Интернете в Active Directory Серверы службы проверки подлинности в Интернете нужно зарегистрировать в каждом домене, включив учетную запись каждого сервера службы проверки подлинности в Интернете в группу безопасности «Серверы RAS и IAS» в каждом домене, в котором они будут использоваться для проверки подлинности. Членство в этих группах гарантирует, что у серверов службы проверки подлинности в Интернете будет разрешение на чтение свойств удаленного доступа всех учетных записей пользователей и компьютеров в доменах. **Чтобы зарегистрировать серверы службы проверки подлинности в Интернете в Active Directory, выполните следующие действия.** 1. Зайдите на каждый сервер, используя учетную запись с правами администратора домена в тех доменах, в которых нужно зарегистрировать сервер службы проверки подлинности в Интернете. 2. Для домена по умолчанию введите в командной строке следующую команду: ``` netsh ras add registeredserver ``` 3. Для других доменов введите в командной строке следующую команду: ``` netsh ras add registeredserver domain = DomainName ``` **Примечание**. Объект сервера службы проверки подлинности в Интернете можно также добавить в группу безопасности «Серверы RAS и IAS» с помощью оснастки консоли управления «Active Directory — пользователи и компьютеры». ###### Создание и защита каталогов данных службы проверки подлинности в Интернете К каталогам, в которых будут храниться конфигурационные данные и данные журналов на серверах службы проверки подлинности в Интернете, предъявляются определенные требования. Чтобы упростить создание и защиту этих каталогов, запустите в командной строке следующий командный файл: ``` C:\\MSSScripts\\IAS\_Data.bat ``` **Примечание**. Возможно, перед выполнением этого файла его придется отредактировать, заменив записи %*DomainName*% в соответствии с NETBIOS-именем домена конкретной среды. ###### Конфигурирование основного сервера службы проверки подлинности в Интернете Сервер, выбранный в качестве основного сервера службы проверки подлинности в Интернете, нужно сконфигурировать раньше всех остальных серверов службы проверки подлинности в Интернете в среде, потому что он будет использоваться в качестве шаблона при их настройке. ###### Запись запросов проверки подлинности и учета в журналы По умолчанию служба проверки подлинности в Интернете не записывает запросы проверки подлинности и учета RADIUS в журнал, но эти функции необходимо активировать, чтобы обеспечить регистрацию событий безопасности и возможность их использования при необходимости проведения расследований. **Чтобы настроить запись запросов проверки подлинности и учета в журналы, выполните следующие действия.** 1. Выберите в оснастке консоли управления «Служба проверки подлинности в Интернете» журнал удаленного доступа и отобразите свойства метода ведения журнала «Локальный файл». 2. Выберите запросы учета и запросы проверки подлинности. 3. Убедитесь в том, что в качестве каталога файла журнала задан каталог D:\\IASLogs и что выбран формат, совместимый с базой данных (это позволяет импортировать журналы непосредственно в базы данных, такие как Microsoft SQL Server™). ##### Проверка подлинности в беспроводной сети с использованием протокола 802.1X В этом разделе описывается защита беспроводной сети на основе спецификации протокола 802.1X на платформах Windows Server 2003 и Windows XP с пакетом обновления 1 (SP1). В нем приводится информация о настройке групп Active Directory, развертывании сертификатов X.509, изменении параметров серверов службы проверки подлинности в Интернете и реализации групповой политики беспроводной сети, а также даются некоторые рекомендации по конфигурированию точек доступа для поддержки реализации протокола 802.1X EAP-TLS, которая лежит в основе описываемого решения. ###### Подготовка среды к развертыванию защищенной беспроводной сети После развертывания базовых инфраструктур сертификатов и RADIUS можно приступать к выполнению конкретных действий по настройке протокола 802.1X. Приведенные ниже таблицы предварительных настроек помогут собрать данные, которые понадобятся, чтобы приступить непосредственно к реализации решения. Некоторые из этих параметров задаются вручную, а другие — с помощью сценариев, прилагаемых к данному руководству. ###### Параметры конфигурации, задаваемые пользователем В следующей таблице указаны специфичные для организации параметры, которые следует определить перед дальнейшим развертыванием защищенной беспроводной сети. Можете вписать фактические значения этих параметров в конкретной среде в пустые ячейки таблицы. **Таблица 17. Параметры, которые должны быть заданы пользователем**

Параметр	Значение
DNS-имя корневого домена леса Active Directory
NetBIOS-имя домена
Имя основного сервера IAS
Имя дополнительного сервера IAS

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

Параметр	Значение
Глобальная группа Active Directory, контролирующая развертывание сертификатов проверки подлинности пользователей стандарта 802.1X.	AutoEnroll Client Authentication — User Certificate
Глобальная группа Active Directory, контролирующая развертывание сертификатов проверки подлинности компьютеров стандарта 802.1X.	AutoEnroll Client Authentication — Computer Certificate
Глобальная группа Active Directory, содержащая сервер службы проверки подлинности в Интернете, который нуждается в сертификатах проверки подлинности по стандарту 802.1X.	AutoEnroll RAS and IAS Server Authentication Certificate
Глобальная группа Active Directory, содержащая пользователей, которым разрешен доступ к беспроводной сети.	Remote Access Policy — Wireless Users
Глобальная группа Active Directory, содержащая компьютеры, которым разрешен доступ к беспроводной сети.	Remote Access Policy — Wireless Computers
Универсальная группа Active Directory, содержащая группы Wireless Users и Wireless Computers.	Remote Access Policy — Wireless Access
Глобальная группа Active Directory, содержащая компьютеры, нуждающиеся в конфигурировании свойств беспроводной сети.	Wireless Network Policy — Computer
Шаблон сертификатов, используемый для создания сертификатов для проверки подлинности пользователей-клиентов.	Client Authentication — User
Шаблон сертификатов, используемый для создания сертификатов для проверки подлинности компьютеров-клиентов.	Client Authentication — Computer
Шаблон сертификатов, используемый для создания серверных сертификатов проверки подлинности для службы проверки подлинности в Интернете.	RAS and IAS Server Authentication
Путь к сценариям установки	C:\MSSScripts
Путь к файлам резервной копии конфигурации	D:\IASConfig
Путь к журналам проверки подлинности и учета службы проверки подлинности в Интернете	D:\IASLogs
Название политики	Allow Wireless Access
Имя объекта групповой политики Active Directory	Wireless Network Policy
Политика беспроводной сети в указанном выше объекте групповой политики	Client Computer Wireless Configuration

###### Создание групп Active Directory, необходимых для доступа к беспроводной сети Используя учетную запись с разрешением на создание групп безопасности Active Directory, нужно выполнить следующий сценарий. Он создает группы, необходимые для подачи заявок на сертификаты проверки подлинности в беспроводной сети, а также реализации политики удаленного доступа и групповой политики беспроводной сети. ``` Cscript //job:CreateWirelessGroups C:\\MSSScripts\\wl\_tools.wsf ``` **Примечание**. В средах лесов с несколькими доменами эти группы нужно создать в том же домене, что и группу пользователей беспроводной сети. Проверка параметров серверов DHCP Чтобы адаптировать серверы DHCP к беспроводной сети, им надо назначить области действия, специфические для беспроводной сети, а время выделения IP-адресов следует сократить в сравнении с клиентами в кабельной сети. Для проверки того, правильно ли сконфигурированы серверы DHCP, обратитесь к их администраторам. Дополнительные сведения о настройке серверов DHCP в беспроводных сетях см. в [руководстве по развертыванию сервера Windows Server 2003](http://www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx) по адресу www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx (эта ссылка может указывать на содержимое полностью или частично на английском языке). ###### Настройка сертификатов проверки подлинности в беспроводной сети Для реализации рассматриваемой системы обеспечения безопасности беспроводной сети на основе протокола EAP-TLS необходимо создать и выполнить развертывание сертификатов следующих типов: - Client Authentication — Computer - Client Authentication — User - RAS and IAS Server Authentication ###### Создание шаблона сертификатов для проверки подлинности серверами службы проверки подлинности в Интернете Для проверки подлинности компьютеров на клиентских системах на этапе подтверждения соединения EAP-TLS серверам службы проверки подлинности в Интернете необходим серверный сертификат. Чтобы создать шаблон сертификатов проверки подлинности серверов для серверов службы проверки подлинности в Интернете, администратор служб сертификации должен выполнить процедуру, описанную ниже. **Чтобы создать шаблон сертификатов проверки подлинности серверов, выполните следующие действия.** 1. Войдите в систему выдающего центра сертификации, используя учетную запись административной группы центра сертификации, и запустите консоль управления шаблонами сертификатов. 2. Создайте дубликат шаблона сертификатов серверов RAS и IAS. В окне свойств нового шаблона откройте вкладку **«Общие»** и введите в поле **«Отображаемое имя шаблона»** строку **RAS and IAS Server Authentication**. 3. Откройте вкладку **«Расширения»** и убедитесь в том, что политики выдачи содержат только элемент «Проверка подлинности сервера (OID 1.3.6.1.5.5.7.3.1)». 4. На вкладке **«Расширения»** добавьте в список политик выдачи политику «Средняя надежность». 5. На вкладке **«Имя субъекта»** выберите вариант **«Строится на основе данных Active Directory»**. Убедитесь также в том, что параметру **«Формат имени субъекта»** присвоено значение **«Общее имя»** и что только элемент **«DNS-имя»** выбран в списке **«Включить эту информацию** в разделе **«Дополнительное имя субъекта»**. 6. На вкладке **«Обработка запроса»** нажмите кнопку **«Поставщики»** и убедитесь в том, что задан параметр **«Запросы должны использовать один из следующих CSP»** и выбран только поставщик **Microsoft RSA SChannel Cryptographic Provider**. 7. Добавьте на вкладке **«Безопасность»** группу безопасности **AutoEnroll RAS and IAS Server Authentication Certificate** с разрешениями на чтение, подачу заявок и автоматическую подачу заявок и удалите все остальные группы, которые могут иметь разрешения на подачу заявок или автоматическую подачу заявок на этот шаблон сертификатов. **Примечание**. Возможно, имеет смысл указать, что этот сертификат должен быть утвержден диспетчером сертификатов, потому что считается, что он имеет сравнительно высокую важность для обеспечения безопасности. Задание этого параметра поможет предотвратить регистрацию нелегального сервера службы проверки подлинности в Интернете, но после выдачи и автоматической отправки сертификатов сервером службы проверки подлинности в Интернете их нужно будет утверждать вручную. ###### Создание шаблона сертификатов для проверки подлинности пользователей Для успешного прохождения проверки подлинности, выполняемой сервером службы проверки подлинности в Интернете во время подтверждения соединения EAP-TLS, пользователи должны иметь пользовательские сертификаты. Следующие этапы также должны быть выполнены владельцем учетной записи, назначенным администратором служб сертификации. **Чтобы создать шаблон сертификатов для проверки подлинности пользователей, выполните следующие действия.** 1. Запустите на сервере выдающего центра сертификации оснастку консоли управления «Шаблоны сертификатов». 2. Создайте дубликат шаблона «Сеанс, прошедший проверку подлинности» и введите на вкладке **«Общие»** в поле **«Отображаемое имя шаблона»** строку **Client Authentication — User**. 3. На вкладке **«Обработка запроса»** установите флажок **«Поставщики»** и снимите флажки **Microsoft Base DSS** **Cryptographic Provider**. 4. Убедитесь в том, что на вкладке **«Имя субъекта»** выбран вариант **«Строится на основе данных Active Directory»**. Присвойте параметру **«Формат имени субъекта»** значение **«Общее имя»**. Убедитесь в том, что в списке **«Включить эту информацию в дополнительное имя субъекта»** выбран только элемент **«Имя** **участника-пользователя (UPN)»**. 5. Откройте вкладку **«Расширения»** и убедитесь в том, что список **«Политики приложения»** содержит только элемент **«Проверка подлинности клиента (OID 1.3.6.1.5.5.7.3.2»**. Добавьте в список политик выдачи политику **«Низкая надежность»**. 6. На вкладке **«Безопасность»** добавьте группу безопасности **«AutoEnroll Client Authentication — User Certificate»** с разрешениями на чтение, подачу заявок и автоматическую подачу заявок. Любые другие группы с разрешениями на подачу заявок или автоматическую подачу заявок следует удалить. ###### Создание шаблона сертификатов для проверки подлинности компьютеров Этот шаблон используется компьютерами при прохождении проверки подлинности, выполняемой сервером службы проверки подлинности в Интернете во время подтверждения соединения EAP-TLS. Опять-таки, администратор служб сертификации должен выполнить следующие задачи. **Чтобы создать шаблон сертификатов для проверки подлинности пользователей, выполните следующие действия.** 1. Запустите на сервере выдающего центра сертификации оснастку консоли управления «Шаблоны сертификатов». 2. Создайте дубликат шаблона «Проверка подлинности рабочей станции». На вкладке **«Общие»** нового шаблона введите в поле **«Отображаемое имя шаблона»** строку **«Client Authentication — Computer»**. 3. Убедитесь в том, что на вкладке **«Имя субъекта»** выбран вариант **«Строится на основе данных Active Directory»**. Присвойте параметру **«Формат имени субъекта»** значение **«Общее имя»**. Убедитесь в том, что в списке **«Включить эту информацию в дополнительное имя субъекта»** выбран только элемент **«DNS-имя»**. 4. Откройте вкладку **«Расширения»** и убедитесь в том, что список политик приложения включает только элемент **«Проверка подлинности клиента (OID 1.3.6.1.5.5.7.3.2)»**. Добавьте в список **«Политики выдачи»** политику **«Низкая надежность»**. 5. На вкладке **«Безопасность»** добавьте группу безопасности **«AutoEnroll Client Authentication — Computer Certificate»** с разрешениями на чтение, подачу заявок и автоматическую подачу заявок. Любые другие группы с этими разрешениями следует удалить. ###### Добавление сертификатов проверки подлинности в беспроводной сети в центр сертификации Теперь шаблоны сертификатов сконфигурированы, и их нужно добавить в центр сертификации, чтобы можно было подавать заявки на сертификаты. Для этого администратор служб сертификации должен выполнить следующие задачи. **Чтобы добавить шаблоны сертификатов в центр сертификации, выполните следующие действия.** - Запустите на выдающем центре сертификации оснастку консоли управления «Центр сертификации», щелкните правой кнопкой мыши папку **«Шаблоны сертификатов»**, выберите **«Создать»** и щелкните **«Выдаваемый шаблон сертификата»**. Выберите следующие сертификаты, после чего нажмите кнопку **ОК**. - Client Authentication — Computer - Client Authentication — User - RAS and IAS Server Authentication ###### Подача заявки на сертификат сервера службы проверки подлинности в Интернете Процесс развертывания серверных сертификатов проверки подлинности на серверах службы проверки подлинности в Интернете достаточно прост и в значительной степени автоматизирован. **Чтобы развернуть серверные сертификаты проверки подлинности на сервере службы проверки подлинности в Интернете, выполните следующие действия.** 1. Запустите оснастку консоли управления «Active Directory — пользователи и компьютеры» и добавьте учетные записи серверов службы проверки подлинности в Интернете в группу безопасности AutoEnroll RAS and IAS Server Authentication Certificate. 2. Перезапустите сервер службы проверки подлинности в Интернете и войдите в систему как член локальной группы администраторов. 3. Введите в командной строке команду GPUPDATE /force. 4. Откройте консоль управления MMC и добавьте оснастку «Сертификаты». Когда будет выведено соответствующее предложение, выберите вариант «Учетная запись компьютера», а затем — «Локальный компьютер». 5. Выберите в древовидном списке консоли элемент **«Сертификаты (локальный компьютер»**, выберите в меню **«Действие»** пункт **«Все задачи»** и щелкните команду **«Подавать заявки на сертификаты автоматически»**. **Примечание**. Если параметр, требующий утверждения сертификата диспетчером сертификатов, задан, администратор центра сертификации должен будет проверить корректность этого запроса и выдать сертификат. ###### Добавление пользователей и компьютеров в группы автоматической подачи заявок на сертификаты Пользователи и компьютеры смогут подтвердить свою подлинность и получить доступ к беспроводной сети только при наличии выданных сертификатов пользователей и компьютеров. Процесс выдачи и обновления этих сертификатов прозрачен для пользователей благодаря ранее настроенным группам автоматической подачи заявок на сертификаты. Для добавления пользователей и их компьютеров в группы автоматической подачи заявок на сертификаты воспользуйтесь оснасткой консоли управления «Active Directory — пользователи и компьютеры». Добавьте учетные записи пользователей в группу AutoEnroll Client Authentication — User Certificate, а их компьютеры — в группу AutoEnroll Client Authentication — Computer Certificate. В результате эти пользователи после перезагрузки своих компьютеров и повторного входа в сеть получат сертификаты пользователей и компьютеров. **Примечание**. В рассматриваемом решении для контроля над тем, какие пользователи и компьютеры могут получить сертификаты, применяются пользовательские группы. Если нужно, чтобы все пользователи и компьютеры имели сертификаты, просто добавьте пользователей домена (Domain Users) в группу AutoEnroll Client Authentication — User Certificate, а компьютеры домена (Domain Computers) — в группу AutoEnroll Client Authentication —Computer Certificate. ###### Конфигурирование инфраструктуры доступа к беспроводной сети Для основного сервера службы проверки подлинности в Интернете нужно задать политику удаленного доступа и параметры запроса подключения, определяющие процессы проверки подлинности и авторизации клиентов при доступе к беспроводной сети. Затем эти параметры нужно воспроизвести на других серверах службы проверки подлинности в Интернете, после чего каждый сервер службы проверки подлинности в Интернете нужно по отдельности сконфигурировать для приема соединений клиентов RADIUS, таких как точки беспроводного доступа. Далее сами точки беспроводного доступа нужно настроить для использования сервера службы проверки подлинности в Интернете в качестве поставщика услуг проверки подлинности и авторизации в беспроводной сети стандарта 802.1X. ###### Создание политики удаленного доступа службы проверки подлинности в Интернете для беспроводной сети Запустите оснастку консоли управления «Служба проверки подлинности в Интернете» на основном сервере службы проверки подлинности в Интернете и настройте эту службу с помощью политики удаленного доступа, следуя приведенным ниже инструкциям. **Чтобы создать политику удаленного доступа, выполните следующие действия.** 1. Щелкните правой кнопкой мыши папку **«Политика удаленного доступа»** и выберите пункт **«Создать политику удаленного доступа»**. 2. Назначьте новой политике имя **Allow Wireless Access** и укажите мастеру настроить **типовую политику для общего сценария**. 3. Выберите в качестве метода доступа **«Беспроводной доступ»**. 4. Предоставьте доступ на основе групп и воспользуйтесь группой безопасности Remote Access Policy — Wireless Access. 5. Выберите тип **«Смарт-карта или иной сертификат для протокола EAP»**, а затем — серверный сертификат проверки подлинности, установленный для службы проверки подлинности в Интернете. 6. Завершите работу мастера. 7. Откройте свойства политики Allow Wireless Access и щелкните **«Изменить профиль»**. 8. На вкладке **«Дополнительно»** добавьте атрибут **Ignore-User-Dialin-Properties** и присвойте ему значение **True**, после чего добавьте атрибут **Termination-Action** со значением **RADIUS Request**. **Примечание**. Политику Allow Wireless Access можно использовать вместе с другими пользовательскими политиками или политиками доступа по умолчанию, но чтобы политика удаленного доступа по умолчанию работала корректно, она должна быть указана в папке «Политики удаленного доступа» после политики Allow Wireless Access. ###### Чтобы добавить клиенты RADIUS в конфигурацию сервера службы проверки подлинности в Интернете, выполните следующие действия. Точки доступа и прокси-серверы RADIUS должны быть добавлены в конфигурацию сервера службы проверки подлинности в Интернете как клиенты RADIUS — только после этого они смогут использовать службы проверки подлинности и учета по протоколу RADIUS. **Процесс добавления клиентов RADIUS в конфигурацию сервера службы проверки подлинности в Интернете** 1. Запустите оснастку консоли управления «Сервер службы проверки подлинности в Интернете». 2. Щелкните правой кнопкой мыши папку **«Клиенты RADIUS»** и выберите пункт **«Новый клиент RADIUS»**. 3. Введите описательное имя и IP-адрес точки беспроводного доступа. 4. Укажите «RADIUS Standard» в качестве атрибута «Клиент-вендор» и введите совместно используемый секрет для конкретной точки доступа. Затем выберите атрибут **«Запрос должен содержать атрибут проверки подлинности сообщения»**. **Примечание**. Этот процесс следует повторить на каждом сервере службы проверки подлинности в Интернете, чтобы гарантировать, что каждый сервер будет иметь уникальный набор клиентов и совместно используемых секретов точек доступа. Для упрощения этого процесса к данному руководству прилагается сценарий, который можно использовать для создания совместно используемых секретов. Эти секреты можно затем сохранить в надежном месте на случай возникновения необходимости в восстановлении системы. Чтобы выполнить этот сценарий, просто введите в командной строке следующую команду: ``` Cscript //job:GenPWD C:\\MSSScripts\\wl\_tools.wsf /client:ClientName ``` ###### Распространение конфигурации на несколько серверов службы проверки подлинности в Интернете После конфигурирования указанных ниже параметров на основном сервере службы проверки подлинности в Интернете их можно экспортировать в текстовые файлы с помощью команды **netsh**. Как только это сделано, полученные текстовые файлы можно импортировать на каждый сервер службы проверки подлинности в Интернете, выполняющий в среде подобные функции. Это обеспечит единообразие конфигураций серверов во всей среде. Конфигурационные данные, которые можно экспортировать: - Настройки сервера - Конфигурация журналов - Политики удаленного доступа - Клиенты RADIUS - Все конфигурационные данные Каждый сервер службы проверки подлинности в Интернете должен иметь собственный уникальный список клиентов RADIUS и совместно используемых секретов, поэтому данные параметры нужно задать по отдельности на каждом сервере. Создавать их резервные копии также нужно по отдельности. При создании копии всех конфигурационных данных в нее включается и конфиденциальная информация, которую нужно надежно защитить, иначе в случае ее кражи возникнет угроза несанкционированного доступа к беспроводной сети. ###### Экспорт конфигурации основного сервера службы проверки подлинности в Интернете Следующие типы параметров следует экспортировать в текстовые файлы для репликации на других серверах службы проверки подлинности в Интернете. - Конфигурация сервера - Параметры ведения журналов - Политика удаленного доступа - Политики запроса соединения Для облегчения этого процесса к данному руководству прилагаются командные файлы, экспортирующие с помощью команд **netsh** конфигурационную информацию в текстовые файлы, которые сохраняются в каталоге D:\\IASConfig. Введите для этого в командной строке следующую команду: ``` C:\\MSSScripts\\IASExport.bat ``` ###### Импорт конфигурационной информации с основного сервера службы проверки подлинности в Интернете Как уже было сказано, для передачи конфигурационной информации между серверами служба проверки подлинности в Интернете использует команду **netsh**. Это делает развертывание более эффективным, снижая при этом вероятность ошибок в ходе конфигурирования. Теперь конфигурационные данные основного сервера службы проверки подлинности в Интернете экспортированы, и дополнительные серверы службы проверки подлинности в Интернете могут импортировать их. **Чтобы импортировать основную конфигурацию службы проверки подлинности в Интернете на другие серверы службы проверки подлинности в Интернете, выполните следующие действия.** 1. Скопируйте все конфигурационные файлы из каталога D:\\IASConfig основного сервера службы проверки подлинности в Интернете в каталог D:\\IASConfig на других серверах службы проверки подлинности в Интернете. 2. Импортируйте на дополнительных серверах конфигурационную информацию, выполнив в командной строке следующий командный файл, прилагаемый к данному руководству: ``` C:\\MSSScripts\\IASImport.bat ``` ##### Точки и клиенты беспроводного доступа Процедура настройки точек беспроводного доступа может значительно различаться в зависимости от их моделей и версий. Как правило, производители точек доступа прилагают к ним подробные инструкции по настройке, предоставляя указанную ниже необходимую информацию. - Сетевые параметры 802.1X - Описание настройки адреса основного RADIUS-сервера - Описание настройки адреса дополнительного RADIUS-сервера - Секрет RADIUS, используемый совместно с основным RADIUS-сервером - Секрет RADIUS, используемый совместно с дополнительным RADIUS-сервером Описание конфигурирования конкретной точки доступа см. в прилагаемой к ней инструкции или на веб-узле производителя. ###### Развертывание сертификатов проверки подлинности в беспроводной сети В этом разделе описаны задачи по настройке, которые нужно выполнить для активации автоматической подачи заявок на сертификаты клиентами, работающими под управлением ОС Windows XP. В предыдущих разделах рассматривалась настройка политик и шаблонов для поддержки автоматической подачи заявок на сертификаты в инфраструктуре сертификатов, но в ОС Windows XP поддержка этих функций по умолчанию отключена. Чтобы включить поддержку автоматической подачи заявок на сертификаты, нужно настроить соответствующие параметры с использованием групповой политики. Используя группы безопасности для контроля автоматической подачи заявок на сертификаты, эту функцию можно активировать для всех пользователей и компьютеров в домене. Группы безопасности при этом могут определять, кто получит сертификаты каждого типа. **Чтобы включить автоматическую подачу заявок на сертификаты для всех пользователей и компьютеров в домене, выполните следующие действия.** 1. Зарегистрируйтесь в системе, используя учетную запись с разрешениями на создание объектов групповой политики (GPO) и связывание GPO с доменом. 2. Выберите в оснастке «Active Directory — пользователи и компьютеры» объект домена, щелкнув его правой кнопкой мыши, после чего выберите пункт «Свойства». 3. На вкладке **«Групповая политика»** нажмите кнопку **«Создать»**, после чего введите имя GPO (например Domain PKI Policies). 4. Щелкните **«Изменить»** и найдите пункт **«Политики открытых ключей»** в разделе Computer Configuration\\Windows Settings\\Security Settings. 5. На панели **«Сведения»** дважды щелкните элемент **«Параметры автоматической подачи заявок»**. 6. Убедитесь в том, что выбраны перечисленные ниже элементы. - Подавать заявки на сертификаты автоматически - Возобновлять сертификаты с истекшим сроком действия, обновлять сертификаты в состоянии ожидания и удалять отозванные сертификаты - Обновлять сертификаты, в которых используются шаблоны сертификатов 7. Повторите этапы 5 и 6 для пользовательских параметров автоматической подачи заявок на сертификаты в разделе User Configuration\\Windows Settings\\Security Settings\\Public Key Policies. 8. Закройте объект групповой политики 9. Убедитесь в том, что этот объект групповой политики имеет более высокий приоритет, чем используемый по умолчанию объект групповой политики домена. 10. Если используется лес с несколькими доменами, повторите процесс для каждого домена, в котором будет включена автоматическая подача заявок на сертификаты. **Примечание**. Если пользователи не используют перемещаемые профили, а автоматическая подача заявок на сертификаты разрешена во всей среде, сертификаты будут выдаваться пользователям при входе на каждый компьютер. При входе администраторов на серверы это может быть нежелательно. Чтобы это не происходило, рекомендуется создать для серверов объект групповой политики с целью отключения автоматической подачи заявок на сертификаты. Если нежелательно активировать автоматическую подачу заявок на сертификаты для всех пользователей, можно связать объект групповой политики с подразделениями, к которым относится подмножество пользователей, нуждающихся в автоматической подаче заявок. ###### Обеспечение доступа к беспроводной сети для пользователей и компьютеров Заключительные этапы обеспечения защищенного доступа к беспроводной сети для пользователей и компьютеров включают несколько операций над объектами Active Directory. В число этих операций входят изменение разрешений учетных записей и разрешений групп и реализация параметров групповой политики беспроводной сети. ###### Добавление пользователей в группы политик удаленного доступа В политике удаленного доступа службы проверки подлинности в Интернете группы безопасности, основанные на Active Directory, используются для определения того, разрешается ли пользователям и компьютерам устанавливать соединения с беспроводной сетью. В число этих групп безопасности, созданных в предыдущих разделах, входят: - Remote Access Policy — Wireless Users - Remote Access Policy — Wireless Computers - Remote Access Policy — Wireless Access **Чтобы добавить пользователей и компьютеры в группы доступа к беспроводной сети, выполните следующие действия.** 1. Запустите оснастку консоли управления «Active Directory — пользователи и компьютеры». 2. Добавьте группы Remote Access Policy — Wireless Users и Remote Access Policy — Wireless Computers в группу Remote Access — Wireless Access. 3. Добавьте пользователей, которым разрешен доступ к беспроводной сети, в группу Remote Policy — Wireless Users. 4. Добавьте компьютеры, которым разрешен доступ к беспроводной сети, в группу Remote Policy — Wireless Computers. **Примечание**. Если решено по умолчанию разрешить всем пользователям и компьютерам доступ к беспроводной сети, ради упрощения администрирования можно добавить группы пользователей домена и компьютеров домена в соответствующие группы политик. ###### Создание групповой политики беспроводной сети Active Directory Для автоматизации настройки и применения конфигурационных параметров беспроводной сети на клиентских компьютерах можно использовать групповую политику. Это возможно благодаря тому, что консоль управления групповой политикой в ОС Windows Server 2003 содержит параметры политики беспроводной сети, основанные на стандартах 802.1X и 802.11. **Чтобы создать групповую политику беспроводной сети, выполните следующие действия.** 1. Запустите оснастку консоли управления «Active Directory — пользователи и компьютеры» на сервере или рабочей станции под управлением ОС Windows Server 2003 с установленными инструментами администрирования Windows Server 2003. 2. Выберите свойства объекта домена, откройте вкладку **«Групповая политика»**, щелкните **«Создать»** и назовите объект групповой политики Wireless Network Policy. 3. zrfНажмите кнопку **«Свойства»** и на вкладке **«Безопасность»** предоставьте группе безопасности Wireless Network Policy — Computer разрешения на чтение и применение групповой политики. Удалите в объекте групповой политики разрешения на применение групповой политики у группы пользователей, прошедших проверку подлинности. 4. На вкладке **«Общие»** задайте для объекта политики параметр **«Отключить параметры конфигурации пользователя»**. Если появятся какие-либо предупреждения, выбирайте **«Да»**. Примените изменения и закройте окно. 5. Нажмите кнопку **«Изменить»** и откройте раздел \\Computer Configuration\\Windows Settings\\Security Settings\\Wireless Network (IEEE 802.11) Policies. 6. Выберите на панели навигации объект «Политики беспроводной сети (IEEE 802.11)», после чего в меню **«Действие»** выберите пункт **«Создать политику беспроводной сети»**. С помощью мастера назначьте политике имя **Client Computer Wireless Configuration**. Оставьте флажок **«Изменить свойства»** установленным и нажмите кнопку **«Готово»**, чтобы закрыть окно мастера. 7. На вкладке **«Сети и предпочтения»** политики **Client Computer Wireless Configuration** выберите **«Добавить»**, после чего введите имя беспроводной сети или ее идентификатор SSID. 8. Откройте вкладку **IEEE 802.1X**, а затем окно параметров для элемента **«Смарт-карта или другой EAP-тип сертификата»**. В разделе **«Доверенные корневые центры сертификации»** выберите сертификат корневого центра сертификации для инфраструктуры открытого ключа, который выдал сертификаты серверам службы проверки подлинности в Интернете. 9. Закройте окно свойств политики «Client Computer Wireless Configuration» и редактор объектов групповой политики. **Примечание.** Протокол WPA2 в настоящее время невозможно использовать с объектом групповой политики. Ожидается, что поддержка WPA2 на уровне объекта групповой политики будет реализована в ОС Windows Vista и Longhorn, а для нынешних версий ОС Windows будут выпущены соответствующие обновления. ###### Добавление компьютеров в группы безопасности для групповой политики беспроводной сети Группы безопасности, основанные на Active Directory, используются для определения того, на каких компьютерах политики беспроводной сети применяются для автоматического конфигурирования необходимых параметров 802.11 и 802.1X. Эти параметры должны быть заданы перед настройкой параметров 802.1X на какой-либо из точек доступа и активацией беспроводной сети. Такой подход гарантирует, что у клиентских компьютеров будет адекватная возможность загрузить и применить групповую политику, даже если они редко подключаются к кабельной сети. Параметры групповой политики можно применить даже до установки беспроводного сетевого адаптера, потому что он автоматически получит и применит корректные параметры групповой политики беспроводной сети. Чтобы добавить компьютеры в группы для групповой политики беспроводной сети, запустите оснастку консоли управления «Active Directory — пользователи и компьютеры» и добавьте авторизованные компьютеры в группу «Wireless Network Policy — Computer». **Примечание**. Параметры объекта групповой политики беспроводной сети будут обновлены на клиентских компьютерах во время следующего интервала обновления групповой политики. Чтобы выполнить принудительное обновление, просто введите команду GPUPDATE /force. ###### Требования к клиентским системам WPA2 Описанное в этом руководстве решение было разработано для клиентских компьютеров со средствами беспроводной связи, работающих под управлением ОС Windows XP Professional с пакетом обновления 2 (SP2) или ОС Windows XP Tablet Edition. В ОС Windows этих версий интегрирована поддержка стандарта 802.1X и беспроводных сетей. Кроме того, клиенты, работающие под управлением ОС Windows XP, поддерживают автоматическую подачу заявок на сертификаты и автоматическое обновление сертификатов, что делает такое решение, основанное на сертификатах, особенно выгодным с экономической точки зрения, если оно связано с инфраструктурой сертификатов. В ОС Windows XP с пакетом обновления 2 также интегрирована поддержка протокола WPA, но для обеспечения поддержки протокола IEEE 802.11i WPA2 на клиентах, работающих под управлением ОС Windows XP с пакетом обновления 2, нужно установить дополнительное обновление. Информацию об этом обновлении и инструкции по его загрузке можно найти в документе [Обновление протокола WPA2 и информационного элемента службы обеспечения беспроводной связи для Windows XP с пакетом обновления 2](http://support.microsoft.com/default.aspx?scid=kb;en-us;893357) по адресу http://support.microsoft.com/default.aspx?scid=kb;en-us;893357 (эта ссылка может указывать на содержимое полностью или частично на английском языке). [](#mainsection)[К началу страницы](#mainsection) ### Аннотация После обзора множества решений, разработанных для обхода недостатков прежних стандартов обеспечения безопасности в беспроводных сетях, и анализа того, как отраслевые стандарты сделали эти обходные пути ненужными, в этом документе было представлено оптимальное решение для защиты беспроводных сетей в компаниях среднего размера. Используя протоколы WPA или описанное в данном документе решение на базе WPA2 EAP-TLS со службами сертификации, компании среднего размера могут теперь эффективно внедрять в своих сетях передовые технологии, обеспечивающие целый ряд преимуществ, таких как повышенная производительность, надежность и безопасность. Выполнив описанные в данном документе действия с использованием предлагаемых инструментов, вы получите надежное и защищенное беспроводное решение, повышающее производительность труда без каких-либо неудобств для пользователей. **Загрузить** [Загрузить статью «Защищенная конфигурация точки беспроводного доступа»](http://go.microsoft.com/fwlink/?linkid=71716) [](#mainsection)[К началу страницы](#mainsection)

Last updated on 2018-11-21

Защищенная конфигурация точки доступа

На этой странице

Введение

Аннотация

Обзор

Для кого предназначен этот документ

Определение

Трудности

Решения

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

Преимущества беспроводных сетевых технологий

Экономические преимущества

Функциональные преимущества

Уязвимости беспроводных сетей

Сертификаты

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

Иерархия центров сертификации

Защита корневого центра сертификации

Проверка подлинности в Интернете

Имеющиеся RADIUS-серверы

Перемещение при сбое RADIUS-сервера и балансировка нагрузки

Требования к ведению журналов RADIUS

Централизованные или распределенные серверы службы проверки подлинности в Интернете

Размещение серверов службы проверки подлинности в Интернете и соображения по поводу совмещения функций

Оценка нагрузки на серверы и требований к аппаратным средствам

Выбор DNS-псевдонима для пункта публикации HTTP

Другие операции по конфигурированию решения и компонентов операционной системы

Подготовка службы Active Directory к использованию инфраструктуры открытого ключа

Создание административных групп инфраструктуры открытого ключа и центров сертификации

Настройка свойств корневого центра сертификации

Запрос сертификата у корневого центра сертификации

Обновление информации о сертификатах в выдающем центре сертификации

Настройка административных ролей выдающего центра сертификации

Публикация сведений о выдающем центре сертификации

Удаление ненужных шаблонов выдающего центра сертификации

Проверка подлинности в Интернете

Проектирование инфраструктуры RADIUS

Конфигурационные данные, задаваемые пользователем

Дополнительные ресурсы