Стандарт NEA

Стивен Шухарт-младший

Фирмы-производители всячески заманивают покупателей достоинствами, которыми обладают технологии, обеспечивающие оценку безопасно-сти сетевых конечных узлов — NEA (Network Endpoint Assessment). Действительно, имеющиеся архитектуры NEA повышают безопасность систем, но одновременно они «привязывают» пользователей к фирменным решениям. Организация IETF ставит перед собой цель решить эту проблему, предложив стандарт, который позволит любому ПО конечного узла обмениваться информацией с любой системой аутентификации и принудительной реализации правил безопасности.

Для отдельных потребителей и отрасли в целом инициатива IETF в области NEA, безусловно, важна. Компании Cisco Systems и Microsoft имеют свои фирменные технологии, именуемые соответственно Network Admission Control и Network Access Protection, которые могут жестко «привязать» к себе потенциальных потребителей. Стандарт NEA представляет собой некий «нейтральный» вариант, который позволит вступить в игру большему числу участников. Предлагаемая концепция делает упор на стандартизации ряда протоколов, в том числе PB (Posture Broker — протокол брокера состояния), PA (Posture Attribute — протокол атрибута состояния) и PT (Posture Transport — протокол транспортировки информации о состоянии). Другие протоколы, служащие для связи между различными частями сервера NEA, Рабочая группа IETF в настоящее время определять не планирует, считая их не очень важными для конечных потребителей.

Возникает практический вопрос: какую пользу принесут усилия IETF? Тот факт, что сопредседателями Рабочей группы NEA являются Стив Ханна из компании Juniper Networks и Сьюзан Томсон из компании Cisco, говорит о том, что эта работа воспринимается отраслью очень серьезно. Показательно, что г-н Ханна является также сопредседателем группы, занимающейся архитектурой Trusted Network Connect (TNC) в рамках организации Trusted Computing Group, сделавшей большую ставку на NEA. Однако участие в разработке стандарта не всегда равносильно принятию его к практическому применению. Выгоды потребителей от стандартизации протоколов PA и PB вполне очевидны. Для производителей основной мотивацией является возможность расширить круг пользователей, принявших идеи NEA. Реальный интерес и деньги для производителей находятся в сфере серверных систем, а не в области программ-агентов, действующих на настольных системах.

Сценарии применения

Представители Cisco и Microsoft много говорят об интероперабельности своих систем и работают над ее обеспечением, но при этом игнорируют сторонние инициативы — например, архитектуру TNC. Цель IETF состоит в обеспечении совместимости всех продуктов NEA, что позволит заказчикам, например, выполнять оценку компьютеров посетителей компании независимо от используемого ими клиента NEA. Стандарт NEA будет также полезен в случае слияния компаний: если поглощаемая компания использует на своих компьютерах NEA-продукт, отличающийся от того, который применяется «материнской» компанией, то поддержка стандарта упростит включение их в новую систему. Можно привести другой пример (правда, менее актуальный): если компания предпочитает NEA-решения для конечных узлов от одного поставщика, а серверные NEA-решения — от другого, то поддержка стандарта IETF позволит этим средствам работать совместно.

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

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

Протокол PB «занимается» переносом атрибутов, собранных от одного и того же клиента и оформленных в сообщения, по тракту между коллектором (на стороне клиента) и контроллером состояний (на стороне NEA-сервера). Он запускает сеанс, предусматривающий многократный обмен сообщениями. Протокол может также связывать многократные запросы/ответы разных контроллеров и коллекторов состояний, участвующих в оценке одного конечного узла. Это важно, особенно если имеется несколько контроллеров, «занимающихся» разными задачами, например один — антивирусной защитой, а другой — программными заплатами ОС. Протокол PB может также доставлять результирующие решения клиенту-брокеру состояний.

Протокол PT переносит генерируемые PB сообщения в тракте между клиентом NEA и сервером NEA. Эти сообщения должны доставляться надежно, и соответствующий информационный обмен необходимо защитить аутентификацией и шифрованием при передаче в обоих направлениях. Информационные блоки протокола, в свою очередь, переносятся протоколами более низкого уровня (RADIUS, 802.1X, IKE или TLS). Протокол PT не имеет доступа к сообщениям протокола PB, которые он доставляет, и работает независимо от их содержания.

Реализация на практике

Чаще всего корпоративные заказчики не желают задумываться об особенностях реализации описанных выше протоколов IETF. Однако их ИТ-подразделения должны держать руку, что называется, на пульсе и поддерживать контакты с производителями, с тем чтобы быть в курсе, соответствуют ли их продукты спецификациям NEA. Даже если компания не имеет никаких планов воспользоваться преимуществами такого рода интероперабельности, в случае, когда она станет реальностью, вполне возможно появление причин (в частности, ситуация поглощения), которые могут сделать ее важным и актуальным фактором в будущем.

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