В преобладающей сегодня архитектуре БЛВС безопасность беспроводного доступа обеспечивается многофункциональным контроллером и «тонкими» ТД. Такой централизованный подход к организации сети упрощает создание профилей БЛВС, предназначенных для гибкого управления правами беспроводного доступа, предоставляемыми разным группам пользователей. Если компания задействует несколько контроллеров, ей имеет смысл внедрить у себя систему управления беспроводной сетью, она сконцентрирует информацию обо всех компонентах инфраструктуры БЛВС в едином управляющем интерфейсе.
Существует несколько важных требований, которые обязательно должен учитывать разработчик БЛВС для удаленных офисов:
Действующие в удаленных офисах средства обеспечения информационной безопасности должны быть совместимыми с таковыми в штаб-квартире, причем во всех офисах следует реализовать идентичные методы аутентификации пользователей. Например, если в центральном офисе задействован протокол аутентификации EAP-TTLS, то же самое нужно сделать и в удаленных офисах. Совместимыми должны быть и средства шифрования данных.
Для выявления и устранения нелегальных ТД необходимо использовать беспроводные системы предотвращения вторжений. Хорошо спроектированная система сможет нейтрализовывать нелегальные ТД, отключая коммутаторные порты, к которым они подсоединены, временно перегружая трафиком их радиочастотные каналы и помогая ИТ-персоналу определять местоположение этих устройств.
Для посетителей предприятия нужно обеспечить гостевой доступ на базе веб-портала с использованием безопасных протоколов аутентификации — например, HTTPS.
Используйте связанную со средствами контроля доступа функцию ограничения сетевой полосы пропускания для конкретных пользователей и их групп, если она поддерживается вашим оборудованием.
Итак, теперь рассмотрим подробнее, почему же в удаленных офисах не следует устанавливать такие же «тонкие» ТД, какие используются в центральном офисе, и управлять ими посредством центрального контроллера. Все дело в том, как организована передача данных в централизованной архитектуре БЛВС.
При включении «тонкая» ТД получает IP-адрес и информацию о контроллере, с которым должна взаимодействовать. На основе этой информации удаленная ТД по WAN-сети создает туннель (с использованием протокола GRE, LWAPP или др.) с контроллером и получает от последнего обновленные информацию о конфигурации БЛВС и микрокод. В принципе все должно функционировать нормально, но, поскольку это оборудование не оптимизировано для связи по WAN-соединению, данное решение получается ненадежным и неэффективным в работе. Например, если из-за неполадок в WAN-сети потеряется связь с контроллером, «тонкая» ТД не «сумеет» самостоятельно обрабатывать трафик БЛВС и начнет искать резервный контроллер. При этом беспроводные клиенты будут отсоединены от ТД и не смогут обращаться ни к удаленным, ни к локальным информационным ресурсам.
И еще. Большинство простейших ТД туннелируют весь трафик своим целевым контроллерам. В результате отсутствия функций локальной коммутации трафика в такой ТД при передаче данных между беспроводными устройствами, находящимися в одном и том же удаленном офисе, кадры данных дважды проходят по WAN-сети. Простейшая ТД недостаточно «умна», чтобы селективно передавать трафик по WAN-каналу, основываясь на информации об адресах отправителей и получателей кадров.
Очевидно, что использование таких ТД (хотя это и реально) нельзя назвать оптимальным решением проблемы организации БЛВС в удаленных офисах. Как уже говорилось, в удаленных офисах лучше задействовать контроллеры на небольшое число ТД или продукты типа RAP и H-RЕAP компаний Aruba и Cisco соответственно. В любом из этих случаев обеспечивается выполнение стандартов безопасности корпоративной БЛВС на территориях удаленных офисов.
Типы компьютерных сетей
