Огромное количество компаний нацелены на расширение присутствия в различных частях города, страны и даже всего мира. Если раньше для того чтобы объединить центральный офис, удалённые филиалы и узлы в единое информационное пространство, компаниям необходимо было прокладывать специальные выделенные линии связи и тратить большие средства, то с развитием глобальных сетей ситуация изменилась. Зачем заниматься организацией альтернативных каналов связи, если можно воспользоваться уже существующими, например интернетом? Все не так просто. При использовании общедоступных линий и средств связи возникают естественные угрозы для передаваемой информации, а значит и угрозы для самой компании. Разрешением этих угроз является обеспечение защиты передаваемых данных.
Существует множество способов организации защищённых информационных потоков в открытых сетях. Мы обратим свое внимание на наиболее распространённые: развёртывание виртуальных частных сетей (VPN) и использование протокола SSL/TLS. Данные технологии иногда прямо противопоставляются друг другу и рассматриваются как технологии, предназначенные для решения аналогичных задач, что с нашей точки зрения не совсем верно.
Перед тем как перейти к рассмотрению особенностей каждой из технологий, дадим их определения и приведём краткую историческую справку.
В качестве одного из первых шагов в процессе эволюции технологий VPN можно отметить принятие в 1976 году стандарта протокола X.25, предназначенного для организации WAN поверх телефонных сетей. Дальнейшее развитие технологий связи привело к появлению целого ряда протоколов, позволяющих осуществлять развёртывание VPN, в частности PPTP, L2TP, IPsec, IPlir.
Каждый из протоколов VPN имеет свои особенности функционирования и степень защищённости передаваемых данных (например, L2TP вообще не обеспечивает защиту данных сам по себе), что обусловлено как историей их возникновения, так и целями их создания.
Протоколы IPsec и IPlir можно отнести к наиболее защищённым, универсальным и перспективным, поэтому при дальнейшем исследовании свойств технологии VPN будем ориентироваться в большей степени именно на них.
Отправной точкой процесса развития семейства протоколов SSL/TLS является протокол SSL 1.0, разрабатываемый компанией Netscape, но так и не увидевший свет в силу наличия в нём ряда серьёзных проблем с безопасностью. Первой обнародованной версией семейства является протокол SSL 2.0, появившийся в 1995 году. Практически незамедлительно, опять же из-за имеющихся во второй версии протокола уязвимостей, был осуществлён его редизайн, результатом которого стало появление в 1996 году SSL 3.0. Следующим шагом стала модернизация третьей версии протокола наряду со сменой его названия с Secure Sockets Layer на Transport Layer Security. Так в 1999 году был выпущен протокол TLS 1.0, который в дальнейшем ещё дважды претерпевал изменения: в 2006 году появился протокол TLS 1.1, а в 2008 году — TLS 1.2. В настоящее время ведётся активная разработка спецификации для очередной версии протокола — TLS 1.3.
Технологии VPN и SSL/TLS, безусловно, имеют общие черты, например в каждой из них используются криптографические методы защиты информации. Тем не менее между ними существует и ряд принципиальных отличий, некоторые мы рассмотрим подробнее.
Прежде всего необходимо отметить, что данные технологии относятся к различным уровням эталонной сетевой модели ISO/OSI. Протоколы VPN обычно соответствуют канальному или сетевому уровням, тогда как протокол SSL/TLS находится между транспортным и прикладным уровнями (как правило, его причисляют к уровню представления). Это во многом определяет возможности технологий и сценарии их применения.
VPN-протоколы IPSec и IPlir защищают весь трафик между двумя узлами, позволяя пользователю в случае удалённого подключения к доверенной сети быть её полноправным членом, как если бы он находился непосредственно в ней.
Протокол SSL/TLS устанавливает безопасную связь между приложениями, запущенными на взаимодействующих узлах, открывая возможность организации удалённого защищённого доступа к конкретному приложению. Данное отличие, как и многие из тех, что мы будем рассматривать далее, нельзя однозначно интерпретировать в пользу той или иной технологии. Оно лишь позволяет судить о степени соответствия конкретной технологии конкретной задаче. Например, в случае необходимости защиты всего трафика приоритет, очевидно, должен быть отдан технологии VPN, тогда как в случае необходимости доступа только к одному приложению более рациональным может оказаться применение SSL/TLS. При этом не стоит забывать и про такие сопутствующие нюансы, как последствия взлома защиты для каждого из случаев (получение доступа ко всей сети или только к одному приложению) или особенности работы конкретных приложений, некоторые из которых могут не обеспечивать важные с точки зрения безопасности функции, например проверку списка отозванных сертификатов. Отметим также, что контроль доступа при защите с помощью SSL/TLS может быть настроен более тщательным образом, ведь организация защищённого соединения непосредственно между приложениями позволяет устанавливать различные права доступа пользователя для каждого из приложений. Кроме того, упрощается и дифференциация прав доступа для различных пользователей.
Принадлежность рассматриваемых технологий разным сетевым уровням также накладывает свой отпечаток на специфику их работы с NAT-устройствами. Данные устройства изменяют IP-адреса в IP-пакетах, что может вызывать трудности при передаче через них защищённого трафика в случае использования VPN-протоколов, следящих за целостностью IP-пакетов. К таким протоколам относится, например, IPsec. В качестве решения данной проблемы может рассматриваться использование технологии NAT-T, позволяющей защищённым пакетам успешно проходить через NAT-устройства. Тем не менее технология NAT-T поддерживается далеко не всеми реализациями VPN, что отрицательно сказывается на совместимости используемых решений. Протокол SSL/TLS не имеет описанных проблем с NAT-устройствами, так как лежит выше транспортного уровня и корректность его работы не зависит от смены IP-адресов и номеров портов. Еще одним важным отличием между рассматриваемыми технологиями является то, что VPN-решения могут использовать в качестве транспортного протокола как TCP, так и UDP, в то время как классические SSL/TLS решения — только TCP. Это ограничивает применение SSL/TLS в сценариях, для которых задержка трафика, вызванная потерями пакетов, является критичной. Стоит отметить, что для таких случаев был разработан альтернативный протокол под названием DTLS, представляющий собой переработанную с целью поддержки транспортного протокола UDP версию TLS 1.1. Однако поддержка DTLS обеспечивается далеко не всеми распространёнными реализациями SSL/TLS.
Среди основных параметров, на которые обращают внимание пользователи при выборе конкретного решения, несомненно присутствуют простота настройки и эксплуатации этих решений, а также их цена.
Данные параметры напрямую коррелируют с необходимостью установки какого-либо дополнительного обеспечения и осуществления его настройки. Развёртывание VPN, как правило, требует установки специализированного аппаратного или программного обеспечения с последующим проведением его довольно сложного конфигурирования. Реализация и настройка защищённых взаимодействий посредством SSL/TLS, на первый взгляд, представляет собой гораздо более простую задачу. Во многом это объясняется тем, что роль клиента в SSL/TLS может исполнять любой современный браузер.
Преимущества, вытекающие из отсутствия необходимости установки клиентского программного обеспечения, очевидны и выражаются в уменьшении как финансовых, так и организационных затрат. Но и здесь имеются свои особенности. Прежде всего необходимо отметить, что использование браузера в качестве клиента позволяет получить доступ только к веб-приложениям. Для организации работы с другими приложениями дополнительно потребуется наличие специальных Java-апплетов или ActiveX-плагинов для браузера, которые, во-первых, могут иметь собственные уязвимости, а во-вторых, их установка может противоречить политике безопасности браузера, внесение изменений в которую потенциально может привести к угрозам со стороны иных, уже зловредных плагинов.
Помимо этого, необходимость установки клиентского программного обеспечения в случае VPN наряду с проведением его предварительной квалифицированной настройки может рассматриваться как дополнительная мера безопасности, затрудняющая несанкционированный доступ к целевым данным.
Что касается простоты настройки клиентской стороны при использовании SSL/TLS, то данное утверждение верно лишь в случае взаимодействия, в процессе которого выполняется только аутентификация сервера. Если же дополнительно требуется осуществление аутентификации клиента, то такие проблемы, как первичная доставка секретных/закрытых ключей и организация их надежного хранения, возникающие при развертывании VPN, имеют место и для SSL/TLS.
Другой особенностью, влияющей на цену решения, является совместимость технологий. Различные реализации VPN далеко не всегда совместимы друг с другом, даже в том случае, если базируются на одном и том же протоколе. Это приводит к необходимости использования однотипного оборудования, что усложняет процессы расширения системы и слияния нескольких систем в одну. Реализации SSL/TLS являются более унифицированными, но также зачастую различаются в части поддержки тех или иных криптографических алгоритмов, функций и параметров.
Аутентификация сторон при использовании технологии VPN обычно выполняется на основе сертификатов (IPsec) или предварительно распределённых секретных ключей (IPsec, IPlir). Это позволяет выбрать наиболее подходящий способ аутентификации в зависимости от конкретного сценария.
В SSL/TLS классическим подходом, применяющимся для аутентификации, является использование сертификатов. При этом существуют и альтернативные способы, в частности аутентификация на основе паролей и аутентификация на основе предварительно распределённых секретных ключей, однако они поддерживаются весьма ограниченным числом реализаций SSL/TLS. Соответственно, подавляющему большинству систем, использующих протокол SSL/TLS, присущи все основные недостатки систем, защита в которых базируется на сертификатах и PKI.
Еще одним нюансом безопасности является защита клиентского устройства. Компании, занимающиеся внедрением VPN, зачастую предлагают дополнительные сопутствующие решения, такие как антивирусы, межсетевые экраны, средства обнаружения вторжений или шифрования файлов. Использование данных решений вкупе с грамотной настройкой соответствующих политик безопасности позволяет минимизировать возможность несанкционированного доступа к клиентскому устройству.
При применении SSL/TLS также существует возможность выполнения ряда проверок клиентского устройства перед предоставлением ему прав доступа. Однако осуществление таких проверок обычно также требует установки дополнительных апплетов к браузеру.
Широкая распространенность протокола SSL/TLS послужила основанием для его детального изучения, что привело к обнаружению целого ряда уязвимостей, имеющихся в этом протоколе. Уязвимости можно разделить на архитектурные, то есть основанные на недостатках самой спецификации протокола SSL/TLS, и на присущие только конкретным реализациям протокола. Такое разделение можно назвать условным, поскольку большинство архитектурных уязвимостей основаны на теоретических особенностях спецификации SSL/TLS, но для своей эксплуатации требуют выполнения ряда практических требований. К основным атакам на SSL/TLS можно отнести BEAST, Padding Oracle Attacks (атака Водонея, Lucky 13, POODLE), атаки на поточный шифр RC4, атака при «пересогласовании», атаки на основе сжатия данных (CRIME, TIME, BREACH), атаки, основанные на навязывании небезопасных криптографических параметров (FREAK, Logjam), атаки, основанные на понижении версии используемого протокола SSL/TLS, Heartbleed.
Большинство из перечисленных атак были реализуемы только на момент своего обнародования и впоследствии устранялись. Можно сказать, что обнаружение новых уязвимостей в SSL/TLS сыграло и положительную роль в становлении этого протокола, поскольку во многом обуславливало его развитие, приводя либо к разработке дополнительных рекомендаций по его использованию, либо к выпуску новых версий протокола с иммунитетом к найденным недостаткам. Несмотря на это, на большом количестве узлов в сети до сих пор используются старые версии протоколов SSL/TLS или же попросту игнорируются имеющиеся рекомендации, что, наряду с большой вероятностью обнаружения новых атак, не позволяет говорить о гарантированной надёжности при использовании технологий на основе SSL/TLS. Некоторые протоколы, применяющиеся для развёртывания VPN, также могут быть подвержены разного рода атакам, в частности протокол PPTP имеет целый ряд серьезных уязвимостей. Тем не менее считается, что такие протоколы, как IPsec и IPlir, обеспечивают достаточный уровень безопасности, поскольку на данный момент не имеют каких-либо существенных выявленных уязвимостей.
В заключение хотелось бы ещё раз обратить внимание на некорректность трактовки VPN и SSL/TLS как технологий, решающих одну и ту же задачу. VPN и SSL/TLS решают различные задачи, обладают разными свойствами и могут даже использоваться совместно, дополняя друг друга, а не конкурируя. Более правильным было бы утверждать, что каждая из них имеет собственное место в отрасли защиты информации. При этом выбор конкретной технологии необходимо осуществлять, сопоставляя собственные нужды, цели и условия с особенностями функционирования каждой из технологий.
