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

Отдельные составные части инфраструктуры аутентификации, авторизации и учета (Authentication, Authorisation, Accounting, AAA) находятся на разных стадиях стандартизации. Аутентификация осуществляется под контролем протокола IEEE 802.1х и соответствующих реализаций открытого протокола аутентификации (Extensible Authentication Protocol, EAP). Функции учета обычно реализуются при помощи протокола RADIUS в соответствии с RFC 2866, RFC 2867 и RFC 2869, дополненных RFC 3580. Однако в области авторизации и управления правилами реализации разных производителей сильно отличаются по концепции и функциональному охвату. Универсальное сетевое решение на базе правил (см. Рисунок 1) должно предоставлять следующие функции:

  • разработку правил и политики;
  • распознавание конфликтов между правилами;
  • хранение правил;
  • распределение правил;
  • преобразование правил в понятные сетевым компонентам команды;
  • распределение команд между сетевыми компонентами;
  • проверку этого распределения.

АУТЕНТИФИКАЦИЯ И EAP

ЕАР и его варианты (см. Таблицу 1) приобретают все большую известность и признание. Толчком стал пока еще достаточно новый стандарт на аутентификацию в сети на базе портов — IEEE 802.1х. Среди прочего он описывает вариант ЕАР для аутентификации по локальной сети (EAP over LAN, EAPoL; EAP в формате Ethernet). Интерес к EAP возник в связи с требованиями стандартов беспроводных локальных сетей 802.11 a/b/g/h к аутентификации, шифрованию и управлению ключами для TKIP (802.11i и WPA). Однако 802.1х с ЕАР привлекает внимание и применительно к традиционным сетям Ethernet. Кроме того, EAP позволяет реализовать единую идентификацию пользователей в локальных, беспроводных и глобальных инфраструктурах в поддерживаемом Microsoft варианте VPN в рамках IPSec/L2TP.

Посредством открытой коммуникации на базе запросов и ответов EAP позволяет осуществить аутентификацию обеих сторон. Например, аутентифицирующая сторона при использовании карт с маркерами доступа (Security Token Card) может по отдельности запрашивать имя, идентификационный номер и значение маркера. Аутентифицируемая сторона получает всякий раз иной статус аутентификации. Собственно аутентификация происходит при помощи EAP RADIUS (RFC 2869) путем эстафетной передачи пакета EAP серверу RADIUS. Он в свою очередь обращается к службам каталогов (в зависимости от производителя интерфейса это может быть Active Directory от Microsoft, eDirectory от Novell и т. п.) посредством LDAP или XML, а также подключаемых модулей для интеграции карт с маркерами доступа. С учетом требований и приложения предлагается множество вариантов EAP.

EAP TLS

Традиционная аутентификация по протоколу защищенных сокетов (Secure Sockets Layer, SSL) — к примеру при построении соединения HTTPS — ограничивается в большинстве случаев лишь односторонней аутентификацией, или аутентификацией сервера. При этом клиент проверяет идентичность сервера и его сертификата по локальному списку так называемых доверенных сертификационных центров (Trusted Root СА). Указанный список, о котором при соединении HTTP-S обычно заботится браузер клиента, также называется доверительным списком сертификатов (Сertificate Trust List, CTL). «Квитирование» SSL происходит посредством TCP.

В случае безопасности EAP на транспортном уровне (EAP Transport Level Security, EAP TLS) «квитирование» осуществляется при помощи EAP или EAPoL. В отличие от «квитирования» SSL, EAP TLS проводит аутентификацию как клиента, так и сервера, для чего используют следующие обозначения:

  • проситель (supplicant) — клиентская система;
  • аутентификатор — компонент, передающий данные аутентификации;
  • сервер аутентификации — компонент, проводящий аутентификацию.

После успешной аутентификации происходит — в зависимости от используемой архитектуры — назначение правил доступа к сети и параметров качества услуг (Quality of Services, QoS). Число возможностей при этом достаточно велико:

  • общая открытая служба правил для предоставления правил (Common Open Policy Provisioning for Policy Service, COPS-PR): http://www.faqs.org/rfcs/rfc3084.html;
  • управление конфигурацией посредством SNMP (Configuration Management with SNMP, snmpconf): http://www.ietf.org/rfc/rfc3512.html;
  • служба аутентификации удаленного пользователя (Remote Authentication Dial-In User Service, RADIUS) для аутентификаторов 802.1x: http://www.faqs.org/rfcs/rfc3580;
  • общая информационная модель (Common Information Model, CIM) и каталого-ориентированные сети (Directory Enabled Networking, DEN) рабочей группы по управлению настольными системами (Desktop Management Task Force, DMTF): http://www.wbemsolutions.com/tutorials/ CIM/den.html;
  • сетевая конфигурация (Network Configuration, netconf): http://www.ietf.org/internetdrafts/-draftietfnetconf-prot-01.txt;
  • задание статических правил через интерфейс командной строки и/или SNMP.

Типы сетевой политики также могут варьироваться:

  • списки контроля доступа (Access Control List, ACL) для второго/третьего/четвертого уровней и правила для брандмауэров: этот метод динамично доставляет типичные для маршрутизаторов ACL на порты доступа в сеть. Таким образом, обеспечение безопасности возможно и между пользователями в одной подсети. Распространение вирусов может быть остановлено напрямую, а на маршрутизаторах и брандмауэрах больше не надо управлять списками контроля доступа;
  • выделение виртуальных локальных сетей (Virtual Local Area Network, VLAN): после успешной аутентификации клиенту назначается VLAN. Благодаря этому подходу обеспечивается простое разделение групп пользователей, но применить специализированные правила к отдельным пользователям не удастся. Качество услуг для каждого приложения определить нельзя — возможно лишь общее назначение приоритетов, к примеру IP-телефонам, но не ПК с поддержкой голоса по IP (Voice over IP, VoIP), видео по IP и прочих приложений;
  • качество услуг для второго/третьего/четвертого уровней позволяет осуществлять динамическую (ре-)классификацию и назначение приоритетов трафику. QoS назначается каждому пользователю и приложению дискретно. Маркировка точки управления дифференцированными услугами (Differentiated Services Control Point, DFCP) возможна уже на порту доступа, тем самым разгружается магистральный маршрутизатор;
  • ограничение скорости: ограничение пропускной способности входящего и исходящего трафика. Контроль величины выделяемой доли пропускной способности позволяет защитить сеть, к примеру, от атак по типу «отказ в обслуживании». Ограничение скорости является обязательным для концепций качества услуг на базе DiffServ/DFCP;
  • правила трансляции сетевых адресов (Network Address Translation, NAT);
  • правила службы имен доменов (Domain Name Service, DNS);
  • правила аутентификации.

COPS-PR

В 1999 г. в IETF появилась рабочая группа по разработке инфраструктуры правил (Policy Framework Working Group). Рабочая группа по правилам допуска к ресурсам (Resource Admission Policy Working Group) тогда занималась стандартизацией общей открытой службы правил (COPS). IETF готовила COPS в расчете на взаимодействие со средой поддержки интегрированных услуг (Integrated Services, IntServ) и протоколом резервирования ресурсов (Resource Reservation Protocol, RSVP). Взаимодействие между точкой выбора правила (Policy Decision Point, PDP) и точкой применения правила (Policy Enforcement Point, PEP) происходит путем передачи и одобрения запросов (см. Рисунок 2). Эта концепция, как и RSVP, не масштабируется на крупные сети, поэтому реализации COPS встречаются очень редко.

Рисунок 2. Примеры концепций применения правил.

С выпуском COPS-PR появился новый протокол на базе COPS — сначала только для сред DiffServ. Причем PDP постоянно выписывает правила для PEP, а не только по запросу, как в случае с COPS. COPS-PR стандартизирован в полном объеме, чего, однако, нельзя сказать о передаваемых правилах.

Используемая в COPS-PR концепция информационной базы правил (Policy Information Base, PIB) очень схожа с основанной на SNMP концепцией базы управляющей информации (Management Information Base, MIB), а также с ее структурным описанием — структурой управляющей информации (Structure of Management Information, SMIv2). Поэтому COPS-PR можно применять для самых различных правил: от IPSec PIB до MPLS RFC 2547bis PIB.

Тогда почему наряду с уже введенным протоколом SNMP необходим еще один протокол, делающий, в принципе, то же самое? Дело в том, что SNMP ориентирован на транзакции, он не учитывает состояние и базируется на UDP, а COPS-PR — напротив — предполагает активное соединение между PDP и PEP. Но оправдывает ли это дополнительные затраты с учетом стабильности сегодняшних сетей? Большинство провайдеров услуг отвечают на этот вопрос отрицательно.

SNMPCONF

Snmpconf находится в процессе стандартизации. Он создавался с целью интеграции MIB и PIB. Но разработчики пошли дальше и предложили абсолютно новый язык сценариев для описания правил, а также относящихся к ним условий и операций. Однако концепция, как и прежде, остается слишком изменчивой, чтобы найти применение в качестве независимого от производителей языка управления правилами: как и сценарии CLI, snmpconf пригоден лишь для отдельных систем. Эта изменчивость усложняет проверку установленных правил на соответствие спецификации snmpconf. До сих пор неизвестно ни об одном производителе, кто поддерживал бы snmpconf.

RADIUS И 802.1X

Стандарт RFC 3580 описывает поведение аутентификатора 802.1x (обычно это точка доступа к беспроводной локальной сети или коммутатор) как ААА-клиента RADIUS. Кроме того, он включает расширение атрибутов учета RADIUS из RFC 2866, RFC 2867 и RFC 2869 со специфическими атрибутами 802.1x. Можно ожидать, что многие простые реализации RADIUS 802.1x будут опираться на этот стандарт. Кроме того, в атрибуте туннеля ответа RADIUS специфицирован так называемый «тип», он используется в качестве идентификатора виртуальной локальной сети стандарта 802.1Q. С его помощью можно реализовать простые правила. Атрибуты туннеля выглядят следующим образом:

  • Tunnel-Type=VLAN(13);
  • Tunnel-Medium-Type=802;
  • Tunnel-Private-Group-ID= VLANID.

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

DMTF DEN

Специальная группа по разработке стандарта на каталого-ориентированные сетевые технологии была создана еще в 1997 г. В 1998 г. спецификацию DEN заимствовала DMTF и интегрировала ее в общую информационную модель. Это была первая волна сетевых технологий с поддержкой каталога или на базе правил. Она не получила широкого применения прежде всего потому, что схемы DEN очень сложны и исповедуют слишком уж теоретический подход. Недавно рабочая группа правил IETF подготовила ряд документов, уже представленных для стандартизации. Все они базируются на схемах LDAP, которые, в свою очередь, очень схожи с DMTF CIM. Несмотря на то что некоторые производители, в частности Sun и HP, реализовали схожие с CIM решения, ее широкое распространение в сетевом мире маловероятно.

NETCONF

Многие провайдеры услуг заинтресованы в деятельности этой относительно новой рабочей группы IETF. Ее появление в мае 2003 г. стало результатом диалога между IETF и провайдерами. Группа отвечает за описание и распределение правил посредством XML и рассматривает следующие проекты стандартов:

  • протокол конфигурации Netconf (Netconf Configuration Protocol): draft-ietf-netconf-prot-01.txt;
  • отображение прикладного протокола BEEP (BEEP Application Protocol Mapping) для Netconf: draft-ietf-netconf-beep-00.txt;
  • Netconf поверх простого протокола доступа к объектам (Simple Object Access Protocol, SOAP): draft-ietf-netconf-soap-00.txt;
  • использование протокола конфигурации Netconf поверх SSH: draft-ietf-netconf-ssh-00.txt;
  • интерфейс управления сетями XML: draft-weijing-netconf-interface-01.txt;
  • протокол сценариев SYMPLE и архитектура для единого управления мобильными устройствами на базе XML и устройствами на базе SNMP: draft-adwankar-netconf-symple-00.txt.

Цель — стандартизация среды для написания сценариев CLI, а также создание формата XML для описания всей конфигурации сетевого компонента. Участники группы делают ставку на существующие стандарты, уже используемые большинством организаций ИТ, к примеру SSH, TLS, SOAP и язык описания служб Web (Web Services Description Language, WSDL). В качестве преимуществ обещается снижение затрат при реализации. Этому должен способствовать текстовый подход на базе XML, который пользователь может интерпретировать гораздо проще, чем кодировку ASN.1 или SMIv2, что облегчает проверку соответствия конфигурации компонента желаемой. Netconf очень похож на статичные правила при конфигурации посредством CLI или SNMP. В отличие от динамических протоколов правил, в нем значительно улучшена предсказуемость поведения сетевых компонентов.

ДИНАМИЧЕСКОЕ НАЗНАЧЕНИЕ ПРАВИЛ

В большинстве случаев администратор распределяет правила при помощи CLI или SNMP (см. Рисунок 3). Эта статичная конфигурация предлагает наибольшую безопасность при предсказуемом поведении сетевых компонентов. Пользовательская персонифицированная сетевая архитектура от Enterasys, например, опирается на разделение управления аутентификацией и правилами: при успешной аутентификации стандартный сервер RADIUS передает внутри атрибута идентификатора фильтра так называемую роль (пользовательскую роль), аналогичную параметру туннеля в RFC 3580.

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

В зависимости от значения идентификатора фильтра в ответе RADIUS роль динамически резервирует порт пользователя. Она может содержать следующие параметры:

  • управление доступом на втором/ третьем/четвертом уровнях;
  • назначение идентификаторов портов VLAN и/или классификация виртуальных сетей на втором/третьем/четвертом уровнях;
  • качество услуг, т. е. формирование очередей с классификацией по второму/третьему/четвертому уровням, назначение приоритетов и ремаркировка, а также ограничение скорости для порта, потока приложения, протокола и пользователя.

Уровень абстракций позволяет комбинировать различные сетевые правила для отдельной службы. Например, VOIP = DSCP EF, т. е. срочная доставка данных и минимальное время задержки при наивысшем приоритете, однако максимальная пропускная способность ограничена величиной 360 Кбит/с (что соответствует ведению трех разговоров одновременно).

Подчеркнем, что применяемый подход по принципу работы очень схож с Netconf.

ЗАКЛЮЧЕНИЕ

Такие концепции, как COPS-PR, snmpconf и DMTF DEN, скорее всего, не получат широкого признания по причине своей сложности. Простые стандарты, наподобие RFC 3580, позволяют дополнить статичные правила CLI и SNMP, которые еще долго будут доминировать на рынке управления на базе правил.

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

Маркус Нишпель — сотрудник технического отдела немецкого офиса Enterasys. С ним можно связаться по адресу: http://www.enterasys.com.

? AWi Verlag