В рубрику "Защита информации и каналов связи" | К списку рубрик | К списку авторов | К списку публикаций
С.Д. Рябко
Генеральный директор ЗАО "С-Терра СиЭсПи", к.ф.-м.н.
В современном мире стремительно растет число мобильных пользователей информационных систем и "информационных надомников". Эта тенденция нашла отражение даже в лингвистике - в обиход технического английского языка прочно вошли неологизмы telecommuter и teleworker.
При этом на сегодня стали массово доступными коммуникационные ресурсы удаленного доступа. Если 5-10 лет назад удаленный пользователь мог воспользоваться только модемом на коммутируемой линии (который остается распространенным и недорогим инструментом), то сегодня практически повсеместно распространены GPRS, xDSL и быстро растет зона покрытия сервисов мобильной телефонии 3G, сочетающих высокую скорость передачи данных, надежность канала и очень разумные цены.
Если вопросы коммуникаций на сегодня, таким образом, решены, то на передний план выходят вопросы информационной безопасности удаленного пользователя.
В чем же специфика удаленного доступа с точки зрения информационной безопасности? Чем задача защиты удаленного пользователя отличается от задачи защиты "внутреннего" пользователя корпоративной сети?
Удаленность рабочего места внешнего пользователя порождает, в сравнении с локальным офисным рабочим местом, три дополнительных фактора угроз:
Возникает вопрос - в какой мере можно нейтрализовать влияние этих негативных факторов?
На мой взгляд, современные технологии защиты информации позволяют обеспечить для удаленного рабочего места практически тот же уровень безопасности, что и для локального офисного. Принципы построения такого безопасного решения изложены в этой статье.
Сегодня в области защиты удаленного доступа довольно жестко конкурируют технологии безопасности сетевого (IPsec) и транспортного (SSL/TLS) уровня.
Чтобы пояснить суть различий этих решений, необходимо ввести некоторую классификацию. На рис. 1 показаны три принципиально различные системные архитектуры:
В чем различия? Прежде всего следует сказать, что все три архитектуры используют примерно одинаковый набор сравнимых по стойкости криптографических алгоритмов. Таким образом, по критерию криптографической стойкости решения можно считать примерно одинаковыми.
Что же касается коммуникационного протокола - решение IPsec одновременно и более гибко, и более сложно как по реализации, так и в эксплуатации. В архитектуре IPsec (рис. 1, а): трафик приложений передается на сетевой уровень в виде пакетов, пакеты перехватываются, шифруются и подписываются. Специальный протокол, Internet Key Exchange, IKE, заботится об управлении ключами и согласовании политик безопасности.
Консалтинговая компания The Burton group в одном из аналитических отчетов утверждала, что VPN-решения на базе протокола IPsec для систем с более высокими требованиями по безопасности предпочтительны в сравнении с SSL/TLS VPN.
Что касается "классической" схемы применения протоколов SSL/TLS (рис. 1, б), то это вовсе не VPN.
Как утверждает один из последних по сроку публикации глоссариев IETF [1], VPN - это "способ использования открытых или частных сетей таким образом, чтобы пользователи VPN были отделены от других пользователей и могли взаимодействовать между собой, как если бы они находились в единой закрытой сети".
Классическое SSL/TLS-решение не соответствует этому определению. Оно обеспечивает целостность и конфиденциальность одного транспортного соединения (трафик приложения 3 на рис. 1, б). Другие же приложения (1 и 2 на рис. 1, б) передают открытый трафик, и доступ к их "незашифрованным" портам никто не контролирует. Такая незамкнутость контура защиты компьютера в SSL/TLS меня всегда очень смущала...
Но у этого решения есть своя, практически неконкурентная, "экологическая ниша". В системах защиты массового (не корпоративного) удаленного доступа, где мы не можем установить каждому пользователю "наш" VPN-клиент, альтернативы Web-браузеру, поддерживающему SSL- или TLS-сое-динение, просто нет. Поэтому электронная коммерция, системы доступа частных лиц к банковским ресурсам и прочие системы с массовым и неподконтрольным парком пользователей построены по схеме Web-браузер - защищенное SSL/TLS соединение - портал.
IPsec, напротив, представляет собой архитектуру, исчерпывающим образом покрывающую функциональность VPN. Здесь трафик всех приложений, передаваемый ими через "свои" транспортные порты, превращается в IP-пакеты, которые шифруются, подписываются и туннелируются через недоверенные сети. При "изолирующей" политике безопасности IPsec, когда открытый IP-трафик полностью защищен, доступ в сеть получает строго определенный круг владельцев секретных ключей. Пробить эту "броню" постороннему невозможно.
Технологии SSL/TLS VPN (рис. 1, в) получили распространение относительно недавно, около 5 лет назад. Мотивом для создания VPN-продуктов на основе транспортных протоколов была идея создать более простое и дешевое в эксплуатации VPN-решение. Однако здесь, как это часто случается в сюжете "хотели как лучше", возникли нюансы. Решение "расползлось" в две сугубо различные архитектуры: "псевдо-VPN" и "честный VPN", которые существенно различаются по своим свойствам.
Архитектура "псевдо-VPN" показана на рис. 2.
В качестве VPN-клиента в "псевдо-VPN" выступает простой Web-браузер. Шлюз безопасности на внешнем периметре корпоративной сети представляет собой защищенный Web-сервер, который "показывает" VPN-клиентам ресурсы защищаемой им сети в виде Web-ресурсов. При этом защищаемые ресурсы вовсе не обязательно должны представлять собой Web-странички. Это могут быть файловые системы, даже чат, голос и видео. Чтобы сделать эти ресурсы доступными через браузер, "позади" Web-сервера располагается прокси-сервер, транслирующий данные ресурсы в HTTP и обратно.
В чем прелесть такого решения? В том, что для построения VPN с клиентской стороны вовсе ничего не нужно. Браузер есть на любой машине. SSL или TLS есть почти в каждом браузере. Сертификат (ключ) не обязателен: и SSL и TLS "умеют" выработать временный сеансовый ключ "на лету". Аутентифицировать пользователя можно позднее, под защитой сеансового ключа, например, при помощи пароля.
В чем основные недостатки? Их два.
Теперь становится яснее озабоченность аналитиков из The Burton group, рекомендовавших для защиты критичных ресурсов IPsec - он не делает исключений.
Осознавая эти недостатки, индустрия SSL/TLS VPN пошла на усложнение архитектуры, предлагая "честный" VPN. Наиболее ярким примером такого решения является прекрасно проработанный и описанный в нескольких книгах проект OpenVPN (http://openvpn.net). Архитектуру этого (и подобных) решений можно понять из диаграммы на рис. 1, в. Трафик приложений (всех или части) упаковывается в открытый транспортный протокол, потом в IP-пакеты, которые перехватываются и повторно инкапсулируются в протокол транспортного уровня с применением средств защиты SSL или TLS. Что мы получаем в итоге? Полнофункциональный "честный" VPN, очень похожий на решение IPsec. Однако платой за такое решение является необходимость установки VPN-клиента. Никуда не денешься - браузер не умеет перехватывать и упаковывать в транспортный протокол IP-пакеты...
Каковы преимущества "честного" SSL/TLS VPN? Разработчики продуктов в этой технологии говорят, что он "намного легче" IPsec. Я бы сказал "несколько легче" - и то с натяжкой:
Собственно, установка и конфигурирование VPN-клиента считается главной трудностью внедрения IPsec в массовом парке удаленных пользователей. Где же "облегчение"?
Некоторое облегчение есть в простоте протокола и политики безопасности. Некоторое облегчение есть в цене: SSL/TLS VPN-продукты бывают несколько дешевле. Но, с другой стороны, - технические возможности этих продуктов более узки. Продукты разных производителей (в силу нестандартности инкапсуляции пакетов в транспортный протокол) практически несовместимы, чего не скажешь об IPsec-продуктах...
Каков же "сухой осадок"? Какие технологии следует выбрать заказчику, заинтересованному в построении защищенной системы удаленного доступа? Неявно ответ на этот вопрос изложен выше:
Последующие разделы - о том, как строить решение, - теоретически применимы, если не оговорено иное, к любому "честному" VPN-решению.
Как учесть риски "человеческого фактора"?
Как-то в фундаментальной работе [2] "Cisco SAFE: IPsec VPNs in depth"1 меня поразила одна фраза: "Может ли ваша организация доверять VPN в той же мере, что и выделенному WAN-каналу? <...> Cisco и большинство заказчиков исходят из того, что VPN-канал заслуживает несколько меньшего доверия". Это как же? Шифрование на ключах 128 бит и ЭЦП авторы считают защитой, которая менее надежна, чем открытый канал за пределами контролируемой зоны организации?! Звучит, мягко говоря, странно. Но, внимательно перечитав текст, я понял, чего недоставало в этой фразе: "Cisco и большинство заказчиков исходят из того, что VPN-канал [эксплуатируемый реальными, немотивированными, возможно - неквалифицированными, в какой-то части - прямо злоумышленными пользователями] заслуживает несколько меньшего доверия".
Дело в том, что сети удаленного доступа часто характеризуются двумя чертами: высокой размерностью и разнородностью парка пользователей.
Поэтому при построении массовой сети удаленного доступа на первый план выходят:
Здесь каждый волен поступать, как хочет, но мы обычно даем строго однозначную рекомендацию: политику безопасности защищенной корпоративной сети удаленного доступа всегда следует строить на предположении, что пользователь несведущ в области информационной безопасности и, возможно, потенциально нелоялен. Поэтому:
К счастью, технические средства защиты информации от многих производителей позволяют реализовать эти принципы на практике.
Пустите пользователя "внутрь ЛВС"
Как уже говорилось выше, "честное" VPN-решение позволяет "распространить" нашу локальную сеть в удаленную зону. Или, что эквивалентно, виртуально "усадить" удаленного пользователя в офисную локальную сеть. Из этой функциональности вытекают два удобства:
Последняя возможность заслуживает краткого пояснения. Дело в том, что все VPN-протоколы обеспечивают строгую взаимную аутентификацию партнеров по взаимодействию. Мы можем практически с юридически значимой достоверностью утверждать, что данный IPsec-пакет принадлежит, скажем, Ивану Ивановичу Иванову. Когда же IPsec-пакет прибывает на шлюз безопасности и передается в локальную сеть предприятия как открытый IP-пакет - аутентифи-кационная информация теряется: в IP-заголовке нет полей, несущих информацию об издателе пакета. Обидно! Однако связать аутентификацион-ную информацию IPsec с открытым IP-пакетом все-таки можно. Это остроумное решение первой внедрила, по моим сведениям, компания Cisco Systems в конце 1990-х. Реализуется оно так.
Эта общая схема может реализовы-ваться в продуктах разных производителей по-разному. "Пригласить" удаленного пользователя внутрь корпоративной VPN можно при помощи:
Иерархические конструкции сетевой защиты
В некоторых случаях заказчик работает с информационными активами, которые существенно различаются по уровням конфиденциальности.
Структура информационной системы при этом может быть произвольной. Однако и по простоте осмысления политики безопасности и по логике эксплуатации системы часто представляется привлекательным техническое решение, в котором контур обработки открытых информационных активов включает в себя контур обработки конфиденциальной информации, а внутри контура обработки конфиденциальной информации находится контур обработки строго конфиденциальной информации (рис. 4). В терминах задач информационной безопасности это называется "принцип эшелонирования средств защиты информации".
Интересно, что политика безопасности VPN хорошо настраивается на построение таких эшелонированных систем.
Дело в том, что каждый "вышестоящий" периметр должен относиться к "нижележащему" как к недоверенной среде. Таким образом, контуры обработки конфиденциальной информации нужно изолировать от "нижележащих" точно так же, как мы при помощи VPN изолируем корпоративное информационной пространство при передаче данных через открытые сети.
Построить такие иерархические, "вложенные" VPN в межсетевых сценариях не составляет никакого труда. В простейшей политике безопасности VPN-шлюзы внешнего периметра должны шифровать трафик внутреннего периметра, особо не задумываясь, какие данные в нем передаются и были ли они уже шифрованы в более конфиденциальном периметре (рис. 5, а).
Однако при удаленном доступе пользователей все становится не так просто. Рассмотрим удаленного пользователя, который должен получить доступ из открытой сети к ресурсам наиболее конфиденциального внутреннего периметра. В этом случае VPN-клиент удаленного пользователя должен установить вложенные VPN-туннели последовательно со шлюзом внешнего контура ("ОИ"), шлюзом конфиденциального контура ("К") и шлюзом строго конфиденциального контура ("СК", рис. 5, б). Хорошее VPN-решение должно обеспечивать возможность построения такой асимметричной системы вложенных VPN-туннелей.
Однако дизайн "вложенных VPN", показанный на рис. 5, часто вызывает ряд вопросов:
Ответы на эти вопросы не совсем однозначны. Высокая теория говорит, что нам по мере возможности следует обеспечивать сквозное шифрование трафика. То есть устанавливать средство шифрования возможно ближе к конфиденциальному ресурсу и исключать точки перешифрования (открытой обработки) трафика по тракту его распространения.
Это означает, что во вложенной VPN с рис. 5 разумно обеспечить прежде всего шифрование трафика на контуре обработки информации с грифом "строго конфиденциально" на шлюзе "СК".
Но что даст нам в плане защиты второе шифрование "строго конфиденциального" трафика на периметре обработки конфиденциальной информации (шлюз "К")? Теоретически, дополнительное шифрование обеспечивает дополнительную защиту. Практически - трафик уже шифрован по ГОСТ 28147 на ключе 256 бит. Повторное шифрование увеличит нам эффективную длину ключа ориентировочно до 512 бит. Но зачем нам это нужно, если шифрование только на ключе 256 бит уже обеспечивает нам более чем достаточную стойкость защиты контура "строго конфиденциально"?
Прагматичный ответ на этот вопрос: увеличивать криптостойкость защиты методом второго шифрования ни к чему. Однако построение второго (и других, при необходимости) уровня вложенности VPN может быть оправдано соображениями простоты эксплуатации системы.
"Свобода доступа" удаленного пользователя
Следующим по важности вопросом дизайна сети удаленного доступа является проблема доступа пользователя в Интернет. В уже цитированной работе Cisco [1] рассматривается архитектура split tunnel, в которой пользователь может получать доступ одновременно в корпоративную сеть и в Интернет.
Опасность такой конструкции в том, что пользователь, нахватав в Интернете вирусов и прочей грязи типа spyware, может стать агентом транзитной атаки на корпоративную сеть (рис. 6).
Во избежание такой угрозы коллеги из Cisco рекомендуют использовать дополнительные средства защиты: антивирус (сегодня сюда бы нужно добавить и анти-spyware), персональный межсетевой экран на клиентском компьютере и усиленные средства контроля безопасности (IDS) на концентраторе доступа.
Предлагаю рассмотреть несколько другой подход, основанный на том, что VPN обладает высокой изолирующей способностью (которую, упершись только в механизмы целостности и конфиденциальности, индустрия в целом недооценивает).
Рассмотрим, к примеру, традиционное периметрическое устройство - межсетевой экран. Политику безопасности межсетевого экрана довольно легко разведать, пассивно наблюдая за проходящим сквозь него трафиком или активно сканируя открытые порты. Выяснив политику безопасности межсетевого экрана, я без особого труда смогу вбросить внутрь корпоративной сети нелегитимный пакет. VPN напрочь исключает такую возможность. Сквозь шлюз безопасности пройдет только пакет, изданный владельцем секретного ключа. "Отгадать" его невозможно, поэтому посторонний в вашу сеть не войдет никогда.
Рекомендуется на сегменте удаленного доступа применять только изолирующую политику VPN, в соответствии с которой удаленный пользователь может получить доступ только в корпоративную сеть и никуда более. На первый взгляд, такой подход вызывает ряд вопросов. Первый из них: как быть, если удаленному пользователю требуется доступ в Интернет?
Ответ прост: пропустите ваших удаленных пользователей по защищенному каналу в корпоративную сеть, а затем выпустите удаленных пользователей в Интернет "на общих основаниях", применяя те же меры защиты, что и для рядовых пользователей локальной вычислительной сети офиса (рис. 7).
Такое решение предоставляет два важнейших преимущества:
Недостатком этой схемы являются дополнительные расходы на коммуникации, поскольку трафик удаленных пользователей дважды проходит через Интернет: в защищенном и в открытом виде. Однако трафик удаленных пользователей обычно составляет относительно небольшую долю в общей цене корпоративных коммуникаций. Интернет дешев, и двойная цена Интернет-трафика удаленных пользователей представляется вполне обоснованной платой за высокую защищенность корпоративной сети.
Другой вопрос, который часто задают применительно к схеме, показанной на рис. 7 - достаточно ли надежна система, где все удаленные пользователи "завязаны" на единственный концентратор доступа?
Тут ответ так же прост: надежность регулируема по потребностям заказчика. Во-первых, VPN-концентратор удаленного доступа легко резервируется, причем - по схеме N + 1 с выравниванием нагрузки. Во-вторых, если ваша сеть регионально распределена, то никто не мешает вам установить концентраторы доступа в 2-3 городах. Поскольку цена за трафик внутри страны практически не зависит от того, подключены вы к шлюзу безопасности в Москве, Санкт-Петербурге или во Владивостоке - дайте пользователям возможность входить в корпоративную сеть через несколько региональных концентраторов доступа. И вы практически без дополнительных затрат получите надежность на уровне катастрофоустойчивости.
В современных VPN-решениях доступен весьма широкий набор средств аутентификации удаленного пользователя: симметричный секретный ключ (пароль), средства аутентификации на одноразовых паролях, сертификаты Х.509, а также комбинации этих средств аутентификации с аппаратным носителем секретного ключа.
Перечисленные решения могут несколько различаться по показателям защищенности, однако параметры стойкости защиты (такие, например, как длина пароля/ключа) могут регулироваться. Это приводит к тому, что стойкость защиты в криптографическим смысле перестает быть практическим критерием для выбора технического решения. Важнейшими практическими критериями становятся вопросы: 1) цены и 2) удобства пользования.
Исходя из этих критериев, для организации аутентификации в VPN удаленного доступа можно рекомендовать как масштабируемое и достаточно удобное малобюджетное решение сертификаты Х.509, встроенные в VPN-клиент или в операционную систему.
В случае если бюджет системы допускает аппаратную поддержку аутентификации пользователей, - решение следует выбирать по критериям совместимости с существующей корпоративной инфраструктурой аутентификации. Если в ней уже применяются средства аутентификации на одноразовых паролях (например, SecurID компании RSA), то разумно предпочесть их в комбинации с групповым симметричным ключом или с сертификатом. В качестве альтернативы можно рекомендовать аппаратный носитель ключа - токен, подобный тем, который выпускает компания Aladdin. Это устройство защищено от вскрытия, не экспортирует секретный ключ, снабжено PIN-кодом с ограниченным числом попыток ввода и очень просто в эксплуатации.
Существуют и комбинированные устройства, сочетающие в себе токен и аппаратные генераторы разовых паролей. Такое устройство может быть средством многофакторной аутентификации для целой вертикали приложений: для аутентификации при входе в операционную систему, в VPN, для интеграции с приложениями, использующими электронную цифровую подпись.
В сетях удаленного доступа задачи защиты долгое время исчерпывались аутентификацией удаленного пользователя, обеспечением конфиденциальности и целостности его трафика.
Однако этого недостаточно. Мы можем быть уверены, что в сеть приходят только авторизованные пользователи. Мы можем быть уверены, что их трафик надежно защищен. Но мы не можем быть уверены в том, что их компьютеры "стерильны" и что, присоединяясь к сети, они не занесут в нее никакой грязи. Требуется управление конфигурациями.
Такая технология появилась около двух лет назад. Компания Cisco Systems предложила идеологию Network Admission Control (NAC). Суть NAC сводится к тому, чтобы при допуске в сеть через удаленное устройство, у него проверялось соответствие конфигурации требованиям корпоративной политики безопасности. Например, от удаленного пользователя может требоваться наличие определенного набора установленных средств защиты, своевременного обновления антивирусных баз данных, активности, или, наоборот, запрета определенных приложений. В случае, если конфигурация рабочего места удаленного пользователя не соответствует требованиям корпоративной политики, он не получает доступа в корпоративную сеть или получает доступ только в карантинную зону, где он сможет "привести себя в порядок": например, загрузить требуемые обновления, провести антивирусное сканирование и т.п.
Эта технология получила повсеместное распространение и в настоящее время поддерживается множеством производителей программного обеспечения и средств защиты информации.
Объемы этой статьи не позволяет разобрать детали сценариев построения корпоративных VPN удаленного доступа. Поэтому в заключение разумно перечислить основные принципы, следуя которым вы не "промахнетесь" при разработке конкретных систем:
Последовательно следуя этим принципам, вы сможете обеспечить для сетей удаленного доступа тот же уровень безопасности, который обеспечивается для офисных сетей.
1 Стр. 10. Сегодня эта книга отсутствует на сайте Cisco. Предполагаю – по причине обновления стандартов IPsec. Книга была написана для архитектуры IPsec RFC 2401 и не была обновлена для новой архитектуры RFC 4301. Жаль, работа представляла интересное руководство по дизайну VPN, которое не стареет с выходом новой версии протокола.
Опубликовано: Журнал "Технологии и средства связи" #2, 2007
Посещений: 28447
Автор
| |||
В рубрику "Защита информации и каналов связи" | К списку рубрик | К списку авторов | К списку публикаций
