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

Введение

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

Аннотация

Использование беспроводных локальных сетей (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).

Трудности

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

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

Решения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор оптимального решения для обеспечения безопасности беспроводной сети

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

Сравнительная информация об основных вариантах (кроме наиболее популярного подхода — отказа от беспроводных сетевых технологий) приведена в следующей таблице.

Таблица 2. Сравнение подходов к обеспечению безопасности беспроводных сетей

Примечание.   По поводу строгой проверки подлинности следует отметить, что во многих реализациях VPN, в которых используется туннельный режим IPsec, применяется слабая схема проверки подлинности с помощью общих ключей, называемая XAuth.
Нынешние версии ОС Windows не поддерживают проверку подлинности пользователей с сопоставлениями IPsec, но эта функциональность будет реализована в ОС Windows Vista и Longhorn.
При проверке подлинности компьютера он остается подключенным к беспроводной и кабельной сетям, даже если в систему не вошел ни один пользователь. Это необходимо для нормальной работы некоторых функций, основанных на доменах, например перемещаемых профилей.

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

Ниже рассматриваются следующие варианты (список упорядочен по убыванию степени обеспечиваемой ими защиты):

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

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

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

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

Использование стандарта 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-решение для удаленных пользователей и стремятся интенсивнее использовать его ресурсы для оправдания расходов. В этом случае перед окончательным выбором данного решения рекомендуется принять во внимание перечисленные ниже факторы.

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

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

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

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

Самым простым методом обеспечения безопасности на основе стандарта 802.11 является применение статического протокола WEP, при котором управление доступом осуществляется с помощью общего ключа; этот же ключ используется еще и в качестве основы при шифровании трафика беспроводной сети. Главное преимущество этого метода — его простота. Если в сети не реализованы никакие другие средства обеспечения безопасности, он в какой-то степени защищает сеть, но при этом возникают серьезные проблемы управления и безопасности. При наличии ноутбука и простых средств, которые можно загрузить из Интернета, на определение открытого ключа и идентификатора SSID (если он распространяется не в широковещательных сообщениях) в беспроводной сети WEP требуется от нескольких минут до нескольких часов, после чего доступ к сети открыт.

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

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

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

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

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 (эта ссылка может указывать на содержимое полностью или частично на английском языке).
Кроме того, нынешние версии ОС Windows не поддерживают WPA2 на уровне объектов групповой политики, что с точки зрения управления является существенным недостатком, который делает реализацию WPA2 гораздо более сложной в сравнении с WPA. При выборе между WPA и WPA2 это может оказаться решающим фактором, так как оба стандарта обеспечивают сравнительно надежную защиту.

Разработка защищенного беспроводного сетевого решения

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

Новейшие стандарты защиты беспроводных сетей, а именно WPA и WPA2, устранили серьезные недостатки стандарта WEP и сделали, таким образом, ненужными способы обхода этих недостатков, такие как использование протокола IPsec или технологии VPN. Использовать статический или динамический алгоритм WEP теперь не рекомендуется ни в какой форме, а отказ от обеспечения безопасности выгоден лишь в немногих ситуациях. Таким образом, при разработке комплексного эффективного решения для защиты беспроводной сети достаточно рассмотреть всего лишь два подхода.

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

Алгоритм Microsoft для выбора подхода к защите беспроводной сети

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

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

Использование стандарта WPA или WPA2 с протоколом PEAP-MS-CHAPv2 предъявляет меньшие требования к оборудованию и техническим навыкам сотрудников, потому что при этом не нужна базовая инфраструктура сертификатов. Все доступные в настоящее время на рынке устройства сертифицированы в соответствии с требованиями WPA2 и не слишком дороги, поэтому лучше выбирать системы с поддержкой WPA2, даже если решено использовать стандарт WPA из-за его нынешнего превосходства над WPA2 в плане администрирования. Поддерживаемый в WPA2 метод шифрования AES считается более защищенным, чем используемый в WPA протокол TKIP, а если учесть еще и то, что в будущих версиях планируется реализовать поддержку WPA2 на уровне объектов групповой политики, имеет смысл создать основу для реализации WPA2 в будущем.

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

Рис. 1. Алгоритм корпорации Майкрософт для выбора подхода к защите беспроводной сети

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

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

Таким образом, наилучшим решением для большинства компаний среднего размера является использование стандарта WPA2 с протоколом EAP-TLS и службами сертификации. Ему и будут посвящены остальные разделы этого документа. Однако из любых правил есть исключения, и, если организация нуждается в другом подходе, ее специалистам следует обратиться к другим руководствам, недостатка в которых нет. Если принято решение использовать WPA с протоколом PEAP-MS-CHAP v2, дополнительные сведения можно найти в документе «Защита беспроводных сетей с использованием протокола PEAP и паролей», который находится по адресу http://go.microsoft.com/fwlink/?linkid=23459 (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Требования протокола EAP-TLS к серверам

Как уже было сказано, для реализации протокола EAP-TLS нужны как минимум четыре сервера (в распределенной или более крупной среде больше), два из которых будут выполнять функции резервных серверов службы проверки подлинности в Интернете (IAS — предлагаемая корпорацией Майкрософт реализация службы удаленной проверки пользователей RADIUS), а два других будут использоваться как компоненты базовой инфраструктуры сертификатов (PKI). Один из двух серверов сертификатов, а именно сервер корневого центра сертификации, будет отключен от сети для защиты корневого сертификата.

Таблица 3. Рекомендуемые требования к оборудованию сервера корневого центра сертификации

Как ясно из таблицы, требования к серверу корневого центра сертификации, основанные на требованиях, предъявляемых ОС 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 со службами сертификации.

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

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

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

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

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

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

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

В подходе, который описывается в данном руководстве, используется иерархическая модель доверия с единственным внутренним корневым центром сертификации. Такой подход имеет и достоинства, и недостатки, поэтому для определения того, насколько он выгоден в конкретной ситуации, иногда требуется провести более тщательный анализ. Чтобы получить дополнительные сведения об этом, обратитесь к главе Designing a Public Key Infrastructure («Проектирование инфраструктуры открытых ключей») руководства Windows Server 2003 Deployment Kit (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Рис. 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, обратитесь к техническому руководству по службе проверки подлинности в Интернете (эта ссылка может указывать на содержимое полностью или частично на английском языке), или свяжитесь с представителем корпорации Майкрософт по работе с заказчиками или со специалистом из консалтинговой службы корпорации Майкрософт.

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

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

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

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

Требования к ведению журналов 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 в этом случае нет. Перед принятием решения о совмещении сервера службы проверки подлинности в Интернете с контроллером домена нужно проанализировать подобные факторы. С другой стороны, совмещение этих компонентов среды обеспечивает повышение производительности, не говоря уж об очевидной экономии, особенно в удаленных филиалах.

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

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

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

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

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

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

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

Примечание.   Приведенную в этой таблице информацию следует рассматривать при определении требований к ресурсам лишь как примерный ориентир.

Как указано в таблице, при пиковой нагрузке или в ходе перемещения при сбое такой сервер может обработать 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» (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Требования к серверной инфраструктуре

Как уже было сказано, в рассматриваемом решении используются входящие в ОС 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. Конфигурационные параметры, задаваемые пользователем

Конфигурационные параметры, определяемые решением

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

Таблица 8. Конфигурационные параметры, определяемые решением

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

Установка конфигурационных сценариев на серверы центров сертификации

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

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

Службы IIS (Internet Information Services) используются клиентами, работающими под управлением ОС, отличных от Windows, для получения сертификатов центров сертификации и списков отзыва сертификатов. Корневой центр сертификации может не предоставлять доступ к этим службам, потому что он не будет подключен к сети, но выдающий центр сертификации должен иметь доступ к ним.

Службы IIS можно также использовать для размещения страниц службы подачи заявок на сертификат через Интернет, но в рассматриваемом решении это не используется. Если страницы подачи заявок на сертификаты через Интернет установлены на сервере, отличном от сервера выдающего центра сертификации, нужно установить для этого сервера отметку «Делегирование разрешено» в объекте сервера в службе Active Directory.

Службы IIS можно установить с помощью диспетчера дополнительных компонентов Windows, доступ к которому осуществляется через панель управления (элемент «Установка и удаление компонентов»). В следующем списке указаны компоненты, которые необходимо установить.

Чтобы установить службы IIS, выполните следующие действия.

Sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIIS.txt

[Components]
complusnetwork = On
iis_common = On
iis_asp = On
iis_inetmgr = On
iis_www = On

sysocmgr /i:sysoc.inf

Настройка IIS для доступа к сведениям о центрах сертификации (AIA) и публикации точки распространения списков отзыва сертификатов на выдающем центре сертификации

На сервере IIS необходимо создать виртуальный каталог, который будет использоваться как HTTP-контекст пунктов публикации сертификатов центров сертификации и списков отзыва сертификатов. Эти пункты называются точкой доступа к сведениям о центрах сертификации (Authority Information Access, AIA) и точкой распространения списков отзыва сертификатов (CRL Distribution Point, CDP) соответственно.

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

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

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

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

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

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

[Components]
rootautoupdate = off

Подготовка службы 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 и более поздних версий.

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

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

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

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

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

Таблица 11. Упрощенная модель администрирования

Рекомендуемая структура подразделений домена

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

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

Предоставление разрешений контейнеру служб открытых ключей

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

Для внесения следующих изменений нужно использовать учетную запись, эквивалентную Active Directory Enterprise Admin.

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

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

Предоставление разрешений членам группы Cert Publishers

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

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

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

Предоставление разрешений на восстановление группе Enterprise PKI Admins

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

Так как для установки центра сертификации будет использована группа Enterprise PKI Admins, ей нужно предоставить право на восстановление файлов и каталогов.

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

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

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

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

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

Файл CAPolicy.inf

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

Информация о списках отзыва сертификатов и доступа к сведениям о центрах сертификации не нужна для сертификата корневого центра сертификации, поэтому в файле capolicy.inf параметры CRLDistributionPoint и AuthorityInformationAccess имеют значение Empty.

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

[version]
Signature=” NT

[Certsrv_server]
RednewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=16

[CRLDistributionPoint]
Empty=true

[AuthorityInformationAccess]
Empty=true

[CAPolicy]
Policies=company CPS name

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

Установка программных компонентов служб сертификации

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

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

sysocmgr /i:sysoc.inf

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

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

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

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

Настройка административных ролей

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

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

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

Запись сертификата и списка отзыва сертификатов корневого центра сертификации на диск

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

Запись сертификата и списка отзыва сертификатов корневого центра сертификации на диск

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

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

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

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

Для выполнения этой процедуры лучше всего использовать выдающий центр сертификации, потому что в нем установлены необходимые библиотеки Certutil.exe, certadm.dll и certcli.dll, но с этой же целью можно использовать любой сервер, являющийся членом домена и работающий под управлением ОС Windows Server 2003, если на нем есть файл certutil.exe и установлены поддерживающие DLL-библиотеки.

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

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

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

Публикация сертификата и списка отзыва сертификатов корневого центра сертификации на веб-сервере

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

Примечание.   Эта процедура не зависит от того, установлен ли веб-сервер публикации CDP и AIA на выдающем центре сертификации, но она предполагает, что виртуальный каталог соответствует каталогу, созданному ранее для конфигурирования IIS (C:\CAWWWPub). Если был выбран другой путь, значение WWW_LOCAL_PUB_PATH в сценарии PKIParams.vbs нужно будет изменить.

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

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

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

Развертывание сервера выдающего центра сертификации

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

Рис. 5.Процесс установки сертификата

Цифры на диаграмме обозначают указанные ниже взаимодействия.

    x.   Этот этап выполняется автоматически в ходе установки центра сертификации предприятия.

Подготовка файла Capolicy.inf для выдающего центра сертификации

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

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

[Version]
Signature= “ NT

[Certsrv_Server]
RenewalKeyLength=2048

[CAPolicy]
Policies=policyname

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

Установка программных компонентов служб сертификации

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

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

sysocmgr /i:sysoc.inf

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

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

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

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

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

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

certutil –pulse

Установка сертификата в выдающем центре сертификации

Подписанный ответ корневого центра сертификации уже создан как пакет сертификатов PKCS#7, и теперь его можно установить в выдающем центре сертификации. Для публикации сертификата центра сертификации в хранилище NTAuth службы Active Directory, которое идентифицирует центр сертификации как центр сертификации предприятия, этот сертификат нужно установить, используя учетную запись, входящую в выдающем центре сертификации в группу Enterprise PKI Admins и локальную группу Administrators. Первая группа имеет права на установку сертификата центра сертификации в каталог, а вторая — на установку сертификата на сервере центра сертификации. Если используется уже упоминавшаяся простая модель администрирования, роль CAAdmin уже является членом обеих этих групп.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\
MSSScripts\CA_Operations.wsf” /sc Hourly /ru “System”

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

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

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

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

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

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

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

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

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

Данные конфигурации, определяемые решением

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

Таблица 16. Параметры конфигурации, определяемые решением

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

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

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

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

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

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

Кроме серверной операционной системы и всех приложений, использовать которые требуется в соответствии с утвержденной политикой создания серверов, на систему нужно установить исполняемый файл CAPICOM 2.1 и вспомогательные DLL-библиотеки для обеспечения поддержки сценариев, прилагаемых к данному руководству.

Сведения о библиотеке CAPICOM и инструкции по ее загрузке можно найти по адресу 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

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

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

Настройка параметров защиты сервера

Как уже было сказано, в данном руководстве предполагается, что в большинстве компаний среднего размера уже утверждены и реализованы процедуры и политики укрепления защиты серверов. Таким образом, подробные инструкции по защите серверов, входящих в данное решение, здесь не приводятся. Если процедуры и политики укрепления защиты серверов не реализованы или необходима дополнительная информация о защите серверов службы проверки подлинности в Интернете, обратитесь к документу «Руководство по обеспечению безопасности Windows 2003», который находится по адресу http://go.microsoft.com/fwlink/?LinkId=14846 (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Установка и конфигурирование службы проверки подлинности в Интернете

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

Для установки службы проверки подлинности в Интернете нужно выбрать в диспетчере дополнительных компонентов Windows (доступ к которому осуществляется через пункт «Установка и удаление компонентов» панели управления) компонент «Сетевые службы — служба проверки подлинности в Интернете». Чтобы упростить этот процесс, воспользуйтесь следующим сценарием:

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

Регистрация службы проверки подлинности в Интернете в Active Directory

Серверы службы проверки подлинности в Интернете нужно зарегистрировать в каждом домене, включив учетную запись каждого сервера службы проверки подлинности в Интернете в группу безопасности «Серверы RAS и IAS» в каждом домене, в котором они будут использоваться для проверки подлинности. Членство в этих группах гарантирует, что у серверов службы проверки подлинности в Интернете будет разрешение на чтение свойств удаленного доступа всех учетных записей пользователей и компьютеров в доменах.

Чтобы зарегистрировать серверы службы проверки подлинности в Интернете в Active Directory, выполните следующие действия.

netsh ras add registeredserver

netsh ras add registeredserver domain = DomainName

Создание и защита каталогов данных службы проверки подлинности в Интернете

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

C:\MSSScripts\IAS_Data.bat

Примечание.   Возможно, перед выполнением этого файла его придется отредактировать, заменив записи %DomainName% в соответствии с NETBIOS-именем домена конкретной среды.

Конфигурирование основного сервера службы проверки подлинности в Интернете

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

Запись запросов проверки подлинности и учета в журналы

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

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

Проверка подлинности в беспроводной сети с использованием протокола 802.1X

В этом разделе описывается защита беспроводной сети на основе спецификации протокола 802.1X на платформах Windows Server 2003 и Windows XP с пакетом обновления 1 (SP1). В нем приводится информация о настройке групп Active Directory, развертывании сертификатов X.509, изменении параметров серверов службы проверки подлинности в Интернете и реализации групповой политики беспроводной сети, а также даются некоторые рекомендации по конфигурированию точек доступа для поддержки реализации протокола 802.1X EAP-TLS, которая лежит в основе описываемого решения.

Подготовка среды к развертыванию защищенной беспроводной сети

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

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

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

Конфигурационные параметры, определяемые решением

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

Таблица 18. Параметры конфигурации, определяемые решением

Создание групп Active Directory, необходимых для доступа к беспроводной сети

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

Cscript //job:CreateWirelessGroups C:\MSSScripts\wl_tools.wsf

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

Проверка параметров серверов DHCP

Чтобы адаптировать серверы DHCP к беспроводной сети, им надо назначить области действия, специфические для беспроводной сети, а время выделения IP-адресов следует сократить в сравнении с клиентами в кабельной сети. Для проверки того, правильно ли сконфигурированы серверы DHCP, обратитесь к их администраторам. Дополнительные сведения о настройке серверов DHCP в беспроводных сетях см. в руководстве по развертыванию сервера Windows Server 2003 по адресу www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Настройка сертификатов проверки подлинности в беспроводной сети

Для реализации рассматриваемой системы обеспечения безопасности беспроводной сети на основе протокола EAP-TLS необходимо создать и выполнить развертывание сертификатов следующих типов:

Создание шаблона сертификатов для проверки подлинности серверами службы проверки подлинности в Интернете

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

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

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

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

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

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

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

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

Добавление сертификатов проверки подлинности в беспроводной сети в центр сертификации

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

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

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

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

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

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

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

Для добавления пользователей и их компьютеров в группы автоматической подачи заявок на сертификаты воспользуйтесь оснасткой консоли управления «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.

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

Запустите оснастку консоли управления «Служба проверки подлинности в Интернете» на основном сервере службы проверки подлинности в Интернете и настройте эту службу с помощью политики удаленного доступа, следуя приведенным ниже инструкциям.

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

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

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

Процесс добавления клиентов RADIUS в конфигурацию сервера службы проверки подлинности в Интернете

Cscript //job:GenPWD C:\MSSScripts\wl_tools.wsf /client:ClientName

Распространение конфигурации на несколько серверов службы проверки подлинности в Интернете

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

Конфигурационные данные, которые можно экспортировать:

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

Экспорт конфигурации основного сервера службы проверки подлинности в Интернете

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

Для облегчения этого процесса к данному руководству прилагаются командные файлы, экспортирующие с помощью команд netsh конфигурационную информацию в текстовые файлы, которые сохраняются в каталоге D:\IASConfig. Введите для этого в командной строке следующую команду:

C:\MSSScripts\IASExport.bat

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

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

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

C:\MSSScripts\IASImport.bat

Точки и клиенты беспроводного доступа

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

Описание конфигурирования конкретной точки доступа см. в прилагаемой к ней инструкции или на веб-узле производителя.

Развертывание сертификатов проверки подлинности в беспроводной сети

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

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

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

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

Добавление пользователей в группы политик удаленного доступа

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

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

Создание групповой политики беспроводной сети Active Directory

Для автоматизации настройки и применения конфигурационных параметров беспроводной сети на клиентских компьютерах можно использовать групповую политику. Это возможно благодаря тому, что консоль управления групповой политикой в ОС Windows Server 2003 содержит параметры политики беспроводной сети, основанные на стандартах 802.1X и 802.11.

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

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

Группы безопасности, основанные на 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 (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Аннотация

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