Технический обзор
Перспективы повышения безопасности Сети для бизнеса
Вам не кажется, что выражение "открытая безопасная сеть" звучит несколько противоречиво? Сегодня, пожалуй, так оно и есть, но уже предпринимаются усилия по превращению общедоступной Сети в универсальное и безопасное средство деловых коммуникаций.
Одним из новых направлений стало создание виртуальных частных сетей, или ВЧС, которые пользователи могут создавать в Internet и применять для связи между корпоративными узлами как альтернативу дорогостоящим арендованным каналам.
Но прежде чем ВЧС получат распространение, деловые люди должны быть уверены, что информация в процессе пересылки по открытой архитектуре Сети не попадет в чужие руки, что она надежно защищена от подслушивания и других посягательств.
На сегодняшний день не обеспечено безопасное софункционирование маршрутизаторов и брандмауэров различных поставщиков, что зачастую вынуждает оснащать все корпоративные узлы ВЧС аппаратными средствами одного производителя.
Три элемента безопасности
IETF (Целевая группа инженерной поддержки Internet) и ряд других организаций ведут работы по созданию средств обеспечения безопасности сетей на сетевом уровне (например, с помощью протокола IP).
Архитектура безопасности должна включать такие элементы, как стандартные средства идентификации отправителя сообщения (аутентификация), базовый алгоритм предотвращения несанкционированного доступа к содержанию дейтаграмм с других узлов (шифрование), а также удобные методы обмена криптографическими ключами, необходимыми для аутентификации и шифрования (распространение ключей).
Рабочая группа создания безопасного протокола IPSec (IP Security - безопасный IP), входящая в IETF, предложила, а последняя одобрила набор стандартов Internet в области аутентификации и шифрования содержимого IP-дейтаграмм (эти стандарты опубликованы в документах RFC с № 1825 по № 1829). Однако эффективность развертывания системы безопасности во многом зависит от третьего элемента архитектуры - системы распространения ключей, а усилия в этом направлении успехом пока не увенчались.
Параллельно с проектом IETF ведутся работы и над другой системой, которая, по мнению некоторых специалистов, более пригодна для практического применения. Речь идет о защищенной глобальной сети S/WAN (Secure Wide Area Networks), создаваемой под эгидой фирмы RSA Data Security. Она базируется на стандарте IPSec и должна повысить уровень совместимости брандмауэрных и программных продуктов различных производителей.
Не оставила без внимания вопросы безопасности сетей и корпорация Microsoft, разрабатывающая протокол Point-to-Point Tunnelling Protocol. Однако ее проект рассчитан скорее на сервис-провайдеров Internet, которые обеспечивают удаленный доступ к глобальной сети, чем на корпоративные узлы.
Рабочая группа IPSec Working Group и консорциум S/WAN Initiative пока не могут прийти к единому мнению о том, какие криптографические алгоритмы выбрать - свободно распространяемые или лицензированные. Однако консорциум делает все возможное, чтобы предложить разработчикам общую схему софункционирования, которую те смогут использовать на практике уже сейчас. Авторы этого проекта намерены к концу нынешнего года рекомендовать продукты, соответствующие предлагаемым стандартам.
Защита дейтаграмм
IPSec Working Group разработала два типа заголовка для дейтаграмм, каждый из которых несет собственные функции. На IP Authentication Header (IP АН) возлагается задача аутентификации и проверки целостности полученных данных. Он призван убедить получателя, что принятая дейтаграмма в действительности передана из указанного в ней источника и в ходе пересылки по сети не подверглась никаким изменениям. Заголовок ESP (Encapsulating Security Payload - безопасное закрытие содержания) выполняет другую задачу - он обеспечивает защиту содержимого IP-дейтаграмм.
Оба эти протокола в значительной мере зависят от так называемого "соглашения безопасности" (Security Association) между отправителем и получателем данных. Оно содержит скоординированную информацию, необходимую для проведения аутентификации и шифрования: алгоритмы этих процессов, сроки использования криптографических ключей и другие детали.
При получении дейтаграммы ее верификация и дешифрирование возможны лишь в том случае, если элементы "соглашения безопасности" подтвердят, что она поступила от указанного в ней отправителя. В архитектуре IPSec обмен подобной информацией осуществляется в ходе сеанса сопоставления ключей, проводимого непосредственно перед каждой пересылкой секретных данных.
Заголовок IP AH способен гарантировать целостность и аутентификацию данных, но не скрывает их от посторонних глаз. Злоумышленник, вооруженный анализатором пакетов, вполне может перехватить проходящую по сети дейтаграмму и прочесть ее содержание.
По этой причине разработчикам средств безопасности приходится прибегать к помощи ESP, второго протокола IPSec, применяя его либо автономно, либо совместно с IP AH. Он может использоваться для шифрования как сегмента на транспортном уровне (тогда его называют транспортным ESP), так и всей IP-дейтаграммы (в этом случае говорят о туннельном ESP). Различия между тем и другим рассматриваются в таблице.
Однако ни один из этих протоколов не затрагивает важнейшей проблемы обеспечения безопасности ВЧС - обслуживания ключей. Как АН, так и ESP считают, что пользователи располагают средствами обмена и верификации криптографических ключей, необходимых для создания заголовков. Взаимосвязь между заголовками и ключами определяется условиями "соглашения безопасности", которое является обязательным элементом процесса обмена криптоключами, предшествующего пересылке любой секретной дейтаграммы.
Уже предложено несколько различных методов такого обмена, но ни один из них Целевая группа IETF в качестве стандарта пока не приняла.
IPSec Working Group подготовила протокол ISAKMP (Internet Security Association and Key Management - обслуживание "соглашений безопасности" и ключей в Internet), определяющий архитектуру обслуживания "соглашений безопасности" и криптографических ключей. Однако он позволяет использовать различные методы обмена, не отдавая предпочтения ни одному из них.
Предложены и другие протоколы обслуживания ключей, в том числе Photuris, Oakley и SKIP (Simple Key management for Internet Protocols - простое обслуживание ключей для протоколов Internet). Сегодня, как нам кажется, симпатии IPSec Working Group склоняются к Oakley и SKIP. По всей вероятности, документы, содержащие описание этих протоколов, а также ISAKMP, вскоре получат статус экспериментальных RFC, но не будут включены в описания стандартов IETF. Кроме того, фирма Cisco Systems выпустила недавно бесплатное справочное руководство по структуре ISAKMP-Oakley.
И все же проблема обслуживания ключей пока далека от решения. Во всех предлагаемых системах обмена ключами специалисты-криптографы находят слабые места. На этом фоне настораживающе выглядит позиция S/WAN Initiative. При проведении последних тестов совместимости систем этот консорциум вообще отказался касаться вопросов обслуживания ключей, перейдя на ручной обмен ими.
Дейв Козюр
Дейв Козюр - директор консультационной фирмы NetReality
(Рестон, шт. Виргиния), специализирующейся в области вычислительных сетей. Связаться с ним можно через Internet по адресу: drkosiur@ix.netcom.com.
Два проекта
Как IPSec Working Group, так и S/WAN Initiative работают над созданием стандартов софункционирования безопасных ВЧС
Что внутри
Различия между структурой дейтаграмм туннельного и транспортного ESP
Туннельный ESP
IP-заголовок участка "шлюз - шлюз"
Вспомогательные заголовки участка "шлюз - шлюз" (АН)
Служебная информация пакета
Заголовки ESP
Информация преобразования
IP-заголовок участка "адрес - адрес"
Вспомогательные заголовки участка "адрес - адрес" (AH, ESP и т. п.)
Содержимое в формате IP (TCP, UDP и т. п.)
Транспортный ESP
IP-заголовок участка "адрес - адрес"
Вспомогательные заголовки участка "адрес - адрес"
Служебная информация пакета
Заголовки ESP
Информация преобразования
Содержимое в формате IP (TCP, UDP и т. п.)
