Network World, США
В IETF сформирована группа NEA Working Group, задача которой — стандартизация протоколов, общих для различных инфраструктур контроля сетевого доступа
Контроль сетевого доступа (Network Access Control, NAC) предполагает использование технологии, которая дает предприятиям возможность устанавливать политики защиты на оконечных устройствах, подключаемых к их сетям. Корпоративная политика защиты, в частности, может предусматривать, чтобы на оконечных устройствах были установлены актуальные заплаты и антивирусный инструментарий, либо запрещать использование таких программных средств, как одноранговый обмен файлами или мгновенный обмен сообщениями.
Политики защиты для поддержки контроля доступа на оконечных устройствах могут быть проверены только путем сканирования оконечных устройств извне. Этот процесс предусматривает снятие параметров на оконечных устройствах, таких как версии файлов или контрольные суммы, и сравнение их с эталонными значениями. Но для того, чтобы можно было получать актуальную информацию от производителей антивирусных средств, обновляющих свои сигнатуры, или от производителей операционных систем, выпускающих заплатки для укрепления защиты, базу данных эталонных значений приходится менять практически ежедневно. Отсюда следует, что необходимо иметь определенную инфраструктуру для поддержки всех этих меняющихся компонентов контроля сетевого доступа.
Многие производители предлагают схожие решения в области контроля сетевого доступа, однако зачастую они плохо совместимы друг с другом. Такая ситуация делает вопрос о стандартизации как никогда актуальным. Осенью прошлого года в рамках IETF была сформирована рабочая группа Network Endpoint Assessment (NEA) Working Group для стандартизации протоколов, общих для некоторых архитектур инфраструктуры контроля сетевого доступа, таких как Network Access Protection от Microsoft, Cisco Network Admission Control и Trusted Network Connect, предложения Trusted Computing Group. Эти протоколы должны обеспечить беспроблемное взаимодействие таких инфраструктур.
Сначала приоритетной задачей была стандартизация протоколов, используемых для передачи информации о статусе различных атрибутов оконечных устройств (в NEA их называют атрибутами состояния), между коллекторами на клиентах и различными подсистемами подтверждения состояний, или контролерами, которые работают на серверах поддержки политик.
NEA поставила для подгруппы задачу подготовить первый предварительный вариант требований к стандартному протоколу, и этот документ в январе был разослан по списку рассылки. Он включает в себя предлагаемую терминологию, порядок применения и эталонную модель, а также требования к конкретным протоколам, которые предполагается стандартизовать.
Эталонная модель содержит коллекторы состояний и контролеры для конкретных компонентов политики, таких как антивирусный инструментарий определенного производителя. Коллектор состояний объединяет значения атрибутов состояния (Posture Attribute, PA); соответствующий контролер состояния знает, как их оценивать. Клиент и сервер брокера состояний мультиплексируют сообщения, которыми обмениваются пары коллектор-контролер. Клиент и сервер передачи состояния устанавливают коммуникационный канал между оконечным устройством (клиентом NEA) и сервером политик (сервером NEA).
Документ NEA предлагает стандартизовать протокол PA, который передает специфические для компонента атрибуты из конца в конец между коллекторами и контролерами, и протокол брокера состояния (Posture Broker, PB), который передает из конца в конец агрегированные сообщения PA. Кроме того, в нем закреплены требования к приемлемому протоколу передачи состояния, который служит для передачи сообщений PB между клиентом NEA и сервером NEA.
Стоит отметить, что другие возможности и протоколы, которые могут повлиять на интероперабельность, по-видимому, пока исключены из сферы рассмотрения NEA. Самые заметные из них те, что связаны с механизмами исполнения политик и коррекцией.
Кроме того, NEA предлагает только стандартизовать «инфраструктуру» протоколов NAC, несмотря на то что многие производители предлагают решения, значительно отличающиеся от этой модели. К примеру, реализация NAP IPSec, которая использует сертификаты открытого ключа X.509, получаемые клиентом для того, чтобы предоставить свое заключение о состоянии уполномоченному серверу, выполняющему регистрацию состояний, а затем использующему сертификат состояния для организации защищенных связей с одноранговыми серверами.
Сейчас, на первых этапах, можно считать, что работа NEA в самом разгаре, когда традиционно ведутся самые яростные споры, возникают разные точки зрения и формируется сообщество. В последнее время эти дискуссии касались сферы действия и целей и вопросов конфиденциальности при использовании активного корпоративного клиентского программного обеспечения, сканирующего подключенные оконечные устройства.
Однако участники по-прежнему надеются, что NEA завершит начатую работу над программой в срок, то есть утвержденный запрос на комментарии (RFC) с информацией о требованиях появится к декабрю.
Джозеф Тардо — старший архитектор систем защиты компании Nevis Networks