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

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

Служба проверки подлинности в Интернете (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) соответственно.