CC BY
697
Калейдоскоп VPN-технологий
Рябко Е.И.,
президент группы компаний "С-Терра", к.ф.-м.н.
Проблема
VPN-технологии, казалось бы, становятся общим местом. Они широко распропагандированы производителями, интеграторами и консультантами. Однако на практике мы сплошь и рядом сталкивается с тем, что
• словом "VPN" называют слишком много разных вещей;
• технические особенности всех этих VPN-технологий массовому пользователю не ясны;
• проектирование и оценка механизмов безопасности VPN при аттестации систем методически недообеспечены.
Результатом недопонимания роли массово внедряемой технологии является неполное использование возможностей продуктов и технологий.
Структура и архитектура системы
Начать следует с того, что сетевая безопасность — это коммуникационная дисциплина.
Коммуникационное управление принято декомпозировать в виде иерархической логической структуры — стека протоколов (неважно, идет речь о семиуровневой декомпозиции управления OSI/ISO или о пятиуровневом стеке TCP/IP).
Важен факт, что каждый уровень управления специализируется на своих задачах, эти задачи и логические (информационные) объекты для каждого уровня существенно различны.
Непосредственным следствием этого положения вещей является модульность систем безопасности. Дело в том, что атаки (и меры защиты), применяемые, скажем, на канальном уровне, не применимы к прикладному уровню и наоборот.
Это деление объективно. Даже бизнес коммуникационных услуг распределен по стеку коммуникационных протоколов. Предприятия, занятые в этом стеке, выполняют независимые задачи. Например, на физическом уровне работают предприятия, занятые прокладкой и сопровождением СКС и кабельного хозяйства, подключение к системам канального уровня обеспечивают телефонные компании, держатели модемных пулов, GPRS. Сетевой и транспортный оккупировали Интернет-сервис-про-вайдеры. На сеансовом уровне "живут" аутентификация и связанные с ней службы, например, биллинг. Нишу уровня представления занимают портальные интерфейсы к базам данных, XML, сами же базы данных, web, почта и прочий контент — обитают на прикладном уровне.
Сетевая безопасность в широком смысле
— это комплекс мер защиты от атак, осуществляемых методами сетевого доступа. Сетевая безопасность в узком смысле — это сред-
сетевом и транспортном уровнях, в первую очередь — межсетевые экраны и VPN.
Мощь этого инструментария, с точки зрения безопасности, поразительна. Средства сетевой защиты обрабатывают каждый сетевой пакет, обойти их невозможно, они обеспечивают полный контроль над коммуникациями каждого компьютера, отдельно взятого приложения или пользователя. На уровне системы — это полный контроль над коммуникациями, что сегодня, когда несетевых компьютеров уже попросту нет, тождественно контролю над информационной системой в целом.
Но сам взгляд технического сообщества на роль этих инструментов безопасности сегодня не гармоничен.
Бытует мнение, что "VPN — это средство шифрования данных при их распространении по открытым (недоверенным) каналам связи". Но это — не зрелая системно-техническая классификация, а поверхностная морфологическая аналогия: "шифрует — значит средство шифрования".
Пример. Вы формируете защищенное почтовое сообщение. Пишете текст, шифруете, подписываете и оправляете адресату, причем он, и только он, может его расшифровать и проверить вашу подпись. В этом случае вы, безусловно, осуществляете криптографическую защиту данных, именно — письма.
Но, предположим, вы решили не защищать письмо, полагаясь на VPN. Можете ли вы быть уверены в его конфиденциальности? Нет: письмо ваше, прежде чем его зашифрует VPN-шлюз, пройдет по сети цепью открытых пакетов, и не факт, что его не прочтет злоумышленник.
Далее, для пакетов мы обеспечим целостность и аутентификацию источника данных. Но признает ли суд цифровую подпись на пакете, содержащем ваше письмо? — Нет. И будет прав: подписан ведь пакет, а не письмо, данные при обработке изменились. Да и подпись-то на нем не ваша, а какого-то шлюза безопасности, вы от нее легко откажетесь...
Наконец, получил ваш адресат "расшифрованное" из VPN-пакетов письмо. Неизвестно — было оно шифровано или нет? Не скомпрометировано ли? Да от кого оно?
Можно ли тогда трактовать VPN, как систему криптографической защиты прикладного документа? Однозначно нет. Зачем же тогда мы применяем криптографию, если не для защиты данных? Для защиты инфраструктуры, сети в целом. Для того, чтобы ни к
ства защиты информации, применяемые на СТЕК ИНФОРМАЦИОННЫХ ОБЪЕКТОВ, УГРОЗ И СРЕДСТВ ЗАЩИТЫ
OSI/ISO TCP/IP
ЕВ
Я
N I
L NI
II Hw
т 1<
Рис. 1
Объекты: ДОКУМЕНТЫ. ПРИКЛАДНОЙ КОНТЕНТ Угрозы: компрометация документов, опасный контент Защита: авторизация доступа, анти-вирус
Объекты: Т-ЗАГОЛОВОК. Т-СОЕДИНЕНИЕ Угрозы:перехват соединения Защита: межсетевой экран, SSL/TLS
Объекты: IP-ПАКЕТ, СИСТЕМА МАРШРУТИЗАЦИИ Угрозы: подмена адресов, НСД, перехват пакетов Защита: IPsec VPN, межсетевой экран
Объекты: МАС-ИНТЕРФЕЙС, ФРЕЙМ/КАДР Угрозы: НСД к среде передачи данных, перехват Защита: ARP/RARP мониторинг, канальный шифратор
Объекты: СРЕДА ПЕРЕДАЧИ ДАННЫХ, СИГНАЛ Угрозы: несанкционированные подключения, ПЭМИН Защита: физическая безопасность, экранирование
PPP: Point-to-Point Protocol — протокол двухточечной связи. Стандарт: RFC 1661, 1994. Класс: ВЧС. Цель: простой протокол для передачи данных, преимущественно по коммутируемому каналу. Безопасность: на фазе установления соединения производится односторонняя (клиент к серверу) или взаимная аутентификация участников, для чего могут модульно применяться протоколы РАР, СНАР или MS-CHAR
вашим прикладным данным, ни к ключам их защиты не смог подойти посторонний.
VPN — это стойкая граница частного сетевого пространства, средство защиты сетевой инфраструктуры в совокупности. Классическое определение [1] звучит так : "VPN
— это "способ использования открытых или частных сетей таким образом, чтобы пользователи VPN были отделены от других пользователей и могли взаимодействовать между собой, как если бы они находились в единой закрытой (выделенной) сети".
"Две большие разницы"
Понятие "VPN" в большинстве случаев связано с понятием "туннелирование". Образность слова "туннелирование" оправдана тем, что трафик принимается в одной точке сети, "упаковывается" в тот или иной транспорт, далее посредством этого транспорта переносится в другую точку и там "выпускается" на свободу в исходном виде. Ясно, что при переносе по туннелю трафик ограничен в своем распространении "стенками" туннеля. Он "не замечает" ландшафт сети, по которой проложен туннель. И наоборот, извне сети в этот туннель проникнуть также бывает непросто.
Технически туннелирование обычно обеспечивается тем, что пакеты данных упаковываются в некую "оболочку". Как правило, "оболочку" представляет собой заголовок другого протокола, обеспечивающего транспортировку трафика по туннелю. Но иногда — например, в транспортном режиме IPsec, в MPLS — исходный заголовок пакета не подменяется, а снабжается дополнительными данными.
Большую путаницу в интерпретации понятия "VPN" вносит дуализм английского "private". В сущности, "VPN" на русский язык лучше переводить, в зависимости от применяемой технологии, двумя разными аббревиатурами: ВЧС, виртуальная частная сеть
— для некриптографических технологий и ВЗС, виртуальная защищенная сеть — для протоколов с применением СКЗИ.
Строго говоря, ВЗС и ВЧС с точки зрения информационной безопасности следует трактовать как два принципиально различных класса средств защиты информации. Однако, с точностью до механизмов, обе технологии решают одну задачу: изоляция корпоративного информационного пространства (или, иногда, отдельного звена этого пространства).
Да сколько же их, этих VPN?
Технологии VPN — это целый комплекс технически и исторически разнородных протоколов. Различают VPN канального, сетевого и транспортного уровней (говорят — L2, L3, L4 VPN). Реализуются эти технологии при помощи различных протоколов. На канальном уровне — это протоколы PPP и гибриды "PPP over ...", L2TP. На сетевом — традиционно говорят об MPLS и IPsec, хотя формально к списку технологий можно бы добавить еще несколько туннельных протоколов, например, GRE. На транспортном — VPN строят на базе протоколов SSL и TLS. Для простоты мы ограничимся списком популярных технологий, хотя претендентов на именование "VPN" намного больше. Свойства безопасности этих технологий существенно различны.
VPN на канальном уровне
Исторические корни VPN-технологий канального уровня восходят к протоколам установления соединения по коммутируемому каналу. Дело в том, что доступ по коммутируемой линии невольно ассоциируется с технологиями не канального, а сетевого уровня. "Обычный" канальный протокол передает данные по одному звену между двумя смежными узлами сети. Сетевой же уровень должен переносить информацию по многозвенной сети, обеспечивая сквозную маршрутизацию от отправителя до получателя. В случае, когда мы используем модем на коммутируемой линии, информация передается не по единому звену провода, оптоволокна или радиоэфира. Ее нужно "прокачать", возможно, через впечатляющую по масштабу сеть телефонии с промежуточными городскими и офисными АТС, различным по скорости и физической природе линиям связи, через цифровые и/или аналоговые системы и шлюзы между таковыми. Протокол канального уровня, решающий задачи
передачи данных по такой, принципиально сетевой, среде, так и хочется сделать туннельным.
Изначально такими и были ныне усопший протокол SLIP и по сию пору здравствующий протокол PPP, а также его потомок PPTP
Первые реализации этих протоколов обслуживали все-таки одно звено передачи данных, построенное на телефонной сети и в этом смысле не являлись, строго говоря, VPN-протоколами. Однако парадоксальное развитие РРР как транспорта для других протоколов канального и сетевого уровней (т.н. архитектура "Multiple protocol over PPP") вывело семейство этих протоколов в распространенных L2 VPN (в смысле ВЧС) технологий. Забавно, что целевая задача, часто решаемая в этой архитектуре сегодня, лежит не на канальном, даже не на сетевом или транспортном, а на сеансовом (в декомпозиции OSI/ISO) уровне. Это — учет потребления ресурсов отдельным узлом сети и часто связываемый с этим учетом биллинг.
Другой член семейства VPN-протоколов канального уровня — L2TP (существующий в настоящее время гибрид протоколов L2F от Cisco и PPTP от Microsoft). Он разрабатывался как для туннелирования того же РРР, так и с целью объединить удаленные локальные сети не на сетевом (как это делает IP), а на канальном уровне. Преимущества такого объединения в том, что по туннелю канального уровня можно передавать не-IP протоколы, рассылки по широковещательным и групповым адресам (не выходящим в нормальном режиме эксплуатации в WAN-каналы), эксплуатировать в географически распределенных ЛВС приложения, которые обычно доступны в пределах одной локалки — разделяемые ресурсы файловых систем Windows, сервисы начальной загрузки устройств, печати и т.п.
Где-то рядом с VPN канального уровня лежит функциональность т.н. VLAN — техно-
PPTP: Point-To-Point Tunneling Protocol - протокол двухточечного туннелирования.
Стандарт: RFC 2637, 1999. Класс: ВЧС.
Цель: туннелировать кадры РРР через IP-сети. (Для этого используются два GRE-туннеля — для передачи потока данных и для управления).
Безопасность: аутентификация, модульное применение протоколов, используемых в PPP, а также EAP-TLS.
Работа [2], несколько ранее определившая понятия и требования к VPN, содержит эквивалентное, но менее афористичное определение VPN.
е
L2TP: Layer 2 Tunneling Protocol — протокол туннелирования канального уровня.
Стандарты: RFC 3931, 2005 (последняя, обновленная и расширрасширенная версия).
Класс: ВЧС (при этом стандартизован гибрид L2TP-IPsec, RFC 3193, обладающий свойствами ВЗС). Цель (в последней редакции): обеспечить возможность туннелирования данных произвольных протоколов канального уровня с развитым спектром возможностей управления соединением. Безопасность: механизмы безопасности не предусмотрены, обеспечиваются в гибриде с IPsec.
логий разделения сетевых ресурсов средствами коммутации. По функциональности технологии VLAN вполне подпадают под определение VPN [1], обладают достаточно стойкими свойствами контроля доступа, имеют уникальную зону применения и в ряде случаев заслуженно вытесняют межсетевой экран из локальной сети. Однако классификаторы из буквоедских соображений не решаются говорить о VLAN, как о классе VPN-технологий по той причине, что механизм IP-туннелирования, присущий VPN, в VLAN отсутствует.
Сетевой уровень
Наиболее распространенные VPN-протоколы сетевого уровня имеют два существенно различных генеалогических корня. Протоколы IPsec (IP Security Architecture), безусловно, из класса ВЗС, с самого начала разрабатывались с целями обеспечения информационной безопасности, причем для них задачи защиты информации являлись первостепенными. Невозможности подробно разобрать их свойства и историю, сошлемся на работы [3, 4].
Другая распространенная ветка VPN-протоколов третьего уровня — MPLS — типичный представитель класса ВЧС. История этого семейства протоколов более сложна и извилиста, хотя сегодняшнее поколение пользуется весьма заслуженной славой и незаменимо для коммуникационных провайдеров. Изначально эти протоколы были частным решением компании Cisco, которая, в одно время, являлась почти единственным поставщиком решений масштаба коммуникационных провайдеров, столкнулась с проблемой роста населения Интернета и, как следствие, падением производительности сетевых магистралей. Дело в том, что рост размера маршрутных таблиц для магистральных маршрутизаторов чрезме-
рен. Для каждого пакета им приходится перебирать довольно большой набор правил маршрутизации, что катастрофически ограничивает их производительность. А с ростом размеров сети таких правил становится все больше. Идея спасения от этой ситуации заключалась в том, чтобы распределить задачи маршрутизации между тремя классами устройств: клиентскими маршрутизаторами (Customer Edge, CE), устройствами подключения к провайдеру (Provider Edge, PE) и, собственно, устройствами магистрали (Provider, P). При этом клиентские устройства, СЕ, должны были "знать" только структуру "своей" клиентской сети (на рисунке разные сети одних и тех же клиентов показаны одним цветом) и "свою" точку подключения к провайдеру PE. Устройства подключения к провайдеру, РЕ, должны были "знать" друг друга и своих подопечных клиентов СЕ и передавать их трафик между собой через магистраль. Магистральные устройства, которых немного, должны были маршрутизировать трафик только между собой и пограничными устройствами. Таким образом реализованы специализация и разделение труда.
Распределив, таким образом, задачи маршрутизации, необходимо было предусмотреть и нечто вроде механизма туннелирования: трафик через магистраль от одного PE-маршрутизатора к другому должен был перенаправляться уже не по IP-адресам в заголовках пакетов (иначе машрутные таблицы не уменьшились бы), а по некоей другой информации. Информационную базу такой "магистральной маршрутизации" составили динамические суррогаты адресов — метки, — которые не заменяли IP-адреса исходных пакетов, а просто дописывались в дополнительный заголовок.
Это усовершенствование, возможно, даже неожиданно для его авторов, оказалось весьма функционально емким. В рамках тех-
нологии ВЧС, т.н. IP VPN или MPLS VPN, клиенты стали получать сервис взаимодействия между своими локальными сетями, даже если внутри их не используется IP, управление качеством сетевого обслуживания по всему тракту распространения данных, управление полосой пропускания и прочее.
Защитные свойства MPLS, как ВЧС-техно-логии, также представляются вполне надежными, во всяком случае я не встречал публикаций об уязвимостях построенного на метках MPLS контроля доступа между различными MPLS VPN. Однако, применяя ВЧТ-техноло-гию, следует понимать, что, если клиент MPLS-провайдера может быть спокоен относительно проникновения к нему из сети другого клиента, то конфиденциальность его трафика по отношению, например, к провайдеру или к злоумышленнику, прослушивающему канал, никак не обеспечена.
На сетевом уровне есть и другие претенденты на то, чтобы выступить в качестве VPN-технологии. К ним относится, например, протокол т.н. IP-IP инкапсуляции GRE. Используется он для технологических целей, например, для того, чтобы ограничить пространство динамической маршрутизации корпоративной сети. Протоколы динамической маршрутизации перенастраивают маршрутные таблицы на корпоративные маршрутизаторы, однако, чтобы они не "прощупывали" и не "подкручивали" Интернет, трафик через него "пробрасывают" из одной корпоративной подсети в другую по GRE-туннелю.
Транспортный уровень
VPN-технологии четверного, транспортного уровня базируются на двух родственных протоколах — SSL (родитель) и TLS (потомок). Оба относятся к категории ВЗС, поскольку ориентированы на решение задач безопасности и используют криптографические алгоритмы.
Изначально эти протоколы позиционировались, как средство защиты TCP-соединения (причем речь шла только о TCP — ни ICMP, ни IP, ни UDP-трафик, как объект за-
1Раес: 1Р БесипТу АсЬИеСипе — архитектуре безопасности протокола 1Р.
Стандарты: RFC 2401 (общая архитектура), 2401 (протокол аутентификации данных АН), 2405 (протокол шифрования ЕБР), 2409 (протокол управления ключами 1КЕ), выпущенные в 1998 г. и их обновления от 2005 г. в кЯС 4301, 4302 4303 4306, соответственно. Обновления пока практически не выпущены на рынок в составе коммерческих продуктов. Класс: ВЗС.
Цель: обеспечить функции конфиденциальности, целостности, аутентификации участников взаимодействия и управление ключами при передаче 1Р-пакетов.
Безопасность: стандарты криптографически нейтральны, функции безопасности обеспечиваются общими алгоритмами шифрования, хэширования и электронно-цифровой подписи. В России -применяются национальные криптографические стандарты.
SSL: Secure Socket Layer - уровень защищенного соединения.
Стандарт: индустриальная (не утвержденная каким либо стандартизационным комитетом) спецификация компании Netscape. С незначительными изменениями был принят в IETF, как стандарт TLS.
TLS: Transport Layer Security — безопасность транспортного уровня.
Стандарт: RFC 2246, 1999. Класс: ВЗС.
Цель: изначально — защита отдельных TCP-соединений; с некоторыми функциональными дополнениями применяется для построения ВЗС.
Безопасность: аутентификация (одно- или двусторонняя) участников соединения, конфиденциальность и целостность информации, передаваемой по TCP-соединению. Модульная декомпозиция криптографических функций, в России — применяются национальные криптографические стандарты.
щиты, не рассматривались). Это существенно сказалось впоследствии на архитектуре так называемых "SSL VPN" .
Решения "SSL VPN" разделяются, строго говоря, на два класса.
Первый — веб-VPN, в нем в качестве VPN-клиента выступает браузер, который устроен следующим образом. Веб-браузер устанавливает защищенное при помощи протоколов SSL или TLS соединение с веб-сервером. На веб-сервере публикуются доступные удаленному пользователю ресурсы, такие, как отдельные файлы или сегменты сетевых файловых систем, приложения — электронная почта и другие. Этот вариант — "не совсем VPN", поскольку в нем, если принимать как классическое определение [1], не реализуется "сосуществование сетевых ресурсов, как в отдельной сети". Пользователю доступны только ресурсы, опубликованные на вебсервере, подключение непроксируемых приложений (ресурсов) и дополнительных протоколов в этой архитектуре невозможно.
Второй класс — инкапсуляции паетов в SSL/TLS — "вполне VPN, но не совсем SSL". В этом классе решений поток IP-пакетов перехватывается целиком и инкапсулируется в TCP-соединение, которое и защищается при помощи протоколов SSL или TLS. Представителем этого класса является продукт Cisco AnyConnect client в решении, обеспечивающем удаленный доступ по протоколу SSL. Продукты этого типа обладают почти всеми достоинствами классического VPN (хотя некоторые неудобства все же остаются, например, затруднена поддержка QoS). Недостатком этого решения является то обстоятельство, что способ инкапсуляции I P-трафика в SSL или TLS не стандартизован и поэтому совместимость между решениями различных производителей в этом режиме не обеспечивается.
Броня ... крепка?
Хотя все VPN-технологии обеспечивают тот или иной режим изоляции объектов/трафика "внутри VPN" от объектов/трафика "снаружи VPN" (т.е реализуют тот или иной режим сетевого контроля доступа), свойства безопасности VPN-решений существенно различаются. Заключение о том, что трафик ВЧС не защищен от перехвата, будет, наверное тривиальным. Тем не менее, и при продаже ВЧС лозунг безопасности играет немалую роль. Например, MPLS-провайдеры вполне справедливо отмечают, что ресурсы различных MPLS VPN надежно разделены и проникновение из одной виртуальной сети в другую исключено. Т.е., если мо-
дель угроз клиента не включает риск компрометации информации недобросовестным сотрудником организации-провайдера
— то можно считать, что корпоративная среда клиента надежно защищена.
Задачи безопасности в комплексе, включая обеспечение конфиденциальности и целостности пакетов, а также целостности потока пакетов (а это — защита от атаки повторной передачи пакета) полностью решают VPN из класса ВЗС — IPsec и SSL VPN.
Детальный анализ их свойств в эту статью не поместится, поэтому приведем лишь несколько коротких тезисов.
Технологии IPsec всем своим фундаментальным дизайном ориентированы на сеть и более "комфортны" для построения любых топологических сценариев для всех без исключения IP-протоколов. Возможности SSL VPN функционально приближаются к ним в режиме полной инкапсуляции IP-трафика. SSL VPN тяготеет к сценариям удаленного доступа, но может проигрывает позиции в защите межсетевых взаимодействий.
IPsec предлагает массу способов аутентификации и построения сложных, адаптивных и поливариантных политик безопасности. SSL реализует практически не параметризуемую в сравнении с IPsec политику безопасности, зато управление такой полити-
кой подкупающе просто.
Умствования большинства консультантов о том, что "IPsec не проходит сквозь NAT", "порты IKE/IPsec могут быть запрещены провайдером", а также о том, что "SSL не требует перенастройки защиты на корпоративном периметре" — сегодня следует классифицировать, скорее, как ангажированный маркетинг под прикрытием консалтинга. Нормальный заказчик уже контролирует поток на 80-й порт TCP или SSL-соединения на периметре своей сети. Не станет же он, в самом деле, впускать вас в свой периметр, оставляя для вас, чужака, неконтролируемый канал утечки под защитой неподвластного ему SSL! По-моему, в части требований совместимости с условиями эксплуатации в сети хорошие VPN-продукты, базирующиеся на протоколах что сетевого, что транспортного уровней, обладают очень близкими возможностями.
Тот тезис, что SSL VPN не требует установки клиента — тоже очень скользкая тема. Если вы не установили клиентское программное ПО, то вам доступен только браузер. В этом случае следует обратить особое внимание на схему аутентификации — односторонняя или двусторонняя, чем обеспечивается, устоит ли по отношению к атакам подмены веб-сервера и "злоумышлен-
L3 VPN (MPLS):
• только ВЧС
• К: НЕТ
• АП: НЕТ, АУ: ЕСТЬ, нестойка
• АД, Ц: НЕТ
• КД: ЕСТЬ, стоек?
L2 VPN:
• только ВЧС
• К: НЕТ
• АП (У): ЕСТЬ, стойка
• АД, Ц: НЕТ
• КД: ЕСТЬ, стоек?
L4 VPN:
• только ВЗС?
• К: ЕСТЬ
• АП: ЕСТЬ, АУ: ЕСТЬ?, стойка
• АД, Ц: ЕСТЬ
• КД: ЕСТЬ, стоек
L3 VPN (IPsec):
• ВЗС (и ВЧС?)
• К: ЕСТЬ
• АП(У): ЕСТЬ, стойка
• АД. Ц: ЕСТЬ
• КД: ЕСТЬ, стоек
Рис. 3
ФУНКЦИИ БЕЗОПАСНОСТИ:
К - конфиденциальность; Ц - целостность;
АП - аутентификация пользователя; АУ - аутентификация устройства; КД - контроль доступа
GRE: Generic Routing Encapsulation - обобщенная инкапсуляция маршрутизации Стандарт: RFC 2784, 2000.Класс: ВЧС.
Цель: изначально — ограничить зону применения маршрутизации, в результате эволюции, по тексту RFC 2784 — предложить наиболее общный формат для инкапсуляции "одного произвольного протокола сетевого уровня в другой произвольный протокол сетевого уровня". Безопасность: механизмы безопасности не предусмотрены.
ник посередине". (В литературе присутствует ряд дизайнов, которые являются объективно опасными). Когда же безопасность SSL доводится до уровня IPsec (строгая двустороння, при необходимости — многофакторная аутентификация объектов), простота SSL часто перестает фигурировать в списке преимуществ решения...
Другое дело — простота системы для администрирования. Подчеркну — администрирования, а не пользования. Продукт для пользователя можно сделать одинаково простым, что для IPsec, что для SSP VPN. Так вот, администрирование IPsec всегда сложнее: нужно настроить средства аутентификации, топологию виртуальной сети, средства событийного протоколирования и мониторинга. Но за эти труды вам воздастся качеством контроля над обстановкой в защищаемой сети.
Суммировать данные по сравнению свойств безопасности различных VPN-технологий (детальный анализ все равно не уместится в разумные объемы статьи) постараемся при помощи символической схемы (ш. рис. 3): Вопросительные знаки на этой схеме означают не "нет информации", а "возможны различные реализации и интерпретации".
Калейдоскопическое разнообразие гибридов
Ввиду различных свойств безопасности и целевых задач разных VPN-технологий, на практике часто применяют их суперпозиции. Приведем наиболее распространенные из них, такие как схемы последовательных инкапсуляций (символика этого рисунка такова, что протокол "в скобках" включен в пакет "наружного" протокола, знак "+" следует читать как "и другие"):
IP[IPsec[IP[L2TP[Ethernet+]]]] IP[IPsec[PPP[IP]]] IP[IPsec[GRE[IP+]]] IP/MPLS[IPsec[IP]]
Первый гибрид — защита взаимодействия между двумя локальными сетями на канальном уровне.
Второй — туннель на доступе удаленного пользователя в корпоративную сеть по коммутируемому каналу.
Третий — многофункционален. Может применяться для того, чтобы реализовать заданную схему динамической маршрутизации в сложной сети, где каналы вне контролируемой зоны защищены IPsec. Другая возможная цель этого гибрида в том, чтобы абстрагировать политику безопасности IPsec от информационно-технического наполнения сети. Политика безопасности IPsec в этом случае "видит" только объекты, несущие концы GRE-туннелей. Внутри же них обстановку можно изменять как угодно — взаимовлияния между этими изменениями и топологией IPsec VPN не будет.
Наконец, гибрид 4 — это конфиденциальность данных пользователя в сети MPLS-провайдера.
В связи с применением такого разнообразия гибридов встает вопрос о стойкости защиты гибридной VPN-среды в целом. Ухудшается или улучшается ее защита гибридной системы? как оценить ее стойкость?
Вопрос сложный, причем ответ зависит более от условий применения технологий, нежели от самих технологий. Но если все построено правильно, то я для себя держу следующее консервативное оценочное правило: стойкость стека VPN-протоколов равна стойкости наиболее защищенного протокола в стеке.
Резюме
Боюсь, что, пытаясь краткой статьей охватить сложную и многообразную тему, я оставляю читателя в недоумении: что и как ему следует применять на практике? И как все это оценит регулятор, особенно в контексте надвигающегося аврала по защите персональных данных?
Попытаюсь дать короткие резюмирующие ответы:
1. Описанные в статье технологии отработаны. Поэтому подбор стека протоколов, оптимальным образом решающего вашу задачу — проектная задача, как правило, не выше средней сложности. Но, выбирая продуктовое решение, уделите внимание его качеству — простоте эксплуатации и устойчивости. Не промахнуться по этим характеристикам сегодня сложнее, чем нарисовать правильную топологию и разбросать по ней правильные протоколы.
2. Огромное значение имеет взгляд на защиту сети в целом. Здесь очень помогает одна простая метафора. Рассматривайте VPN, как "забор" вокруг своей территории. Если забор построен без дыр, кроме ворот, которые вы закрываете на ключ — ваша система спроектирована правильно. В терминах сети это означает: за пределами контролируемой зоны корпоративный трафик распространяется только в защищенном виде. Открытого трафика, за исключением выхода в Интернет и во внешние организации, нет. (Ну а шлюз в Интернет — это уже те самые ворота в заборе, средства защиты для них известны).
3. На сегодня требования регуляторов по защите персональных данных пока не доведены до рекомендации по применению тех или иных технологий VPN. Однако их применение дает вам, тем не менее, ряд преимуществ при аттестации ИСПДн. В контексте защиты персональных данных большое значение имеют не только изоляция внешнего периметра, но и методики построения "вложенных" VPN. Они помогут вам построить "заборчик", изолирующий зону обработки персональных данных внутри "большого забора", ограничивающего вашу информационную систему в целом. В терминах документов технического регулирования это обеспечивает сегментирование ИСПДн, повышает качество организации персональных данных (обеспечивается локализация хранения и обработки), дает основание исключить из модели угроз те, которые вы "оставили за забором", построенным при помощи сертифицированного для защиты персональных данных VPN-продукта.
Литература
1. RFC 4026. L. Andersson, T. Madsen, Acreo AB//Provider Provisioned Virtual Private Network (VPN) Terminology.
2. RFC 2764. B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis//A Framework for IP Based Virtual Private Networks.
3. Рябко СД Криптографические протоколы на страже Сети. — Connect!. — 2007. — №8.
4. Рябко СД, Смыслов ВА Безопасность IP: таинство творения. — ИнфомКурьер-Связь. — 2007. — №12.
MPLS: Multiprotocol Label Switching - многопротокольная коммутация на основе меток. Стандарты: RFC 2917, 2000, RFC 3031, 2001, RFC 3945, 2004. Класс: ВЧС.
Цель: по RFC 2917 — "обеспечить сервис виртуальной маршрутизации для клиентских сетей". На сегодня эти цели существенно расширены.
Безопасность: аутентификация при доступе к ресурсу IP VPN и контроль доступа на основе меток, конфиденциальность и целостность трафика не обеспечиваются.
