Мобильные сотрудники хотят иметь доступ в любое время и из любого места. Виртуальные частные сети SSL якобы сразу устраняют все трудности и освобождают администратора от «проблемы с клиентом» — однако в действительности эту технологию следует рассматривать несколько более дифференцированно.

С повышением требований к удаленному доступу отвечать на вопросы о безопасности подобных соединений стало сложнее. Если ранее для защиты использовались почти исключительно решения на базе IPSec, то сегодня главные надежды связывают с виртуальными частными сетями (Virtual Private Network, VPN) SSL. Главные аргументы производителей состоят в том, что построение зашифрованного соединения при помощи SSL более не требует отдельного клиента, а сам доступ к внутренним ресурсам защищается лучше, чем в случае классической VPN. Оба пункта заслуживают критичного рассмотрения.

VPN между двумя офисами в этой статье не рассматривается, поскольку в такой ситуации по чисто техническим причинам IPSec является лучшим решением, даже если и не более надежным. Таким образом в центре внимания находятся классические удаленные и мобильные пользователи, отличие которых заключается лишь в наличии или отсутствии контроля над используемым устройством доступа со стороны администратора.

НЕ ВСЕГДА БЕЗ КЛИЕНТА

Для построения защищенного при помощи SSL соединения на стороне клиента необходим обычный браузер — в том виде, в каком он имеется практически на всех современных устройствах, используемых для удаленного доступа. Тогда дополнительного специализированного клиентского программного обеспечения действительно не понадобится.

Однако — и здесь нас ждет первое разочарование — предполагаемая свобода всех пользователей касается только одного случая: доступа по SSL исключительно к «родным» приложениям Web, для которых действительно не нужно никакого дополнительного ПО. Между тем обычные каждодневные требования предприятий совсем иные. Почти каждый удаленный пользователь кроме основных применяет и небольшие программы, в частности telnet, SSH и FTP, а также работает с терминальными клиентами и настоящими толстыми клиентами, такими, например, как SAP.

В подобном случае одного браузера уже недостаточно для использования всех преимуществ SSL VPN. Наряду с «родными» приложениями Web различают четыре режима, три из которых требуют наличия либо дополнительных апплетов, либо отдельного клиента SSL VPN.

Первый называют «отображение HTML» — это представление данных внутреннего ресурса в браузере Web. Наиболее известным является воспроизведение разделов дисков с каталогами и файлами в стиле Windows Explorer, причем обычно пользователю доступны все те же функции, что и в Explorer. Отображение HTML предоставляется всеми производителями шлюзов SSL.

Следующая ступень — «переадресация портов», для чего клиентский браузер автоматически загружает с шлюза SSL на устройство доступа апплет Java. Эта небольшая программа направляет все запросы приложения, работающего через определенные порты, в существующий туннель SSL. Возможно, самый распространенный пример — туннелирование SSH.

В «терминальном клиентском режиме» пользователь в окне браузера видит виртуальный рабочий стол и может либо зарегистрироваться на находящемся в локальной сети терминальном сервере, либо запускать отдельные приложения непосредственно с этого рабочего стола. Для того чтобы представить в браузере виртуальный рабочий стол, клиентская машина сначала запускает с шлюза SSL апплет Java.

И наконец, существует еще нечто вроде «режима толстого клиента» — на клиентской машине устанавливается полноценный клиент SSL VPN. Он перехватывает все запросы к находящимся в локальной сети ресурсам любых приложений и по туннелю отправляет их посредством HTTPS на шлюз SSL. Там все запросы переводятся на изначальные порты и передаются на соответствующий сервер для обработки. Приходящие с него ответы отправляются обратным путем клиенту. Этот сценарий во многом совпадает с моделью клиента IPSec.

ПРОБЛЕМА МАШИНЫ ДОСТУПА

В функциональном отношении все перечисленные режимы некритичны. Однако, если необходим доступ из любого места к любым данным, все оказывается сложнее. Одного браузера для доступа к «родным» приложениям Web вполне достаточно, но условием расширенной функциональности является наличие среды Java, из-за чего могут возникать проблемы у таких устройств доступа, как некоторые карманные компьютеры. Кроме того, для использования самих апплетов, функциональность которых во многом тесно увязана с операционной системой, пользователи, как правило, должны быть наделены более широкими правами, хотя бы для их инсталляции. Отсюда ясно, что полнофункциональный клиент SSL VPN может применяться только на тех системах, где пользователю предоставляются права администратора. Поэтому действительно «бесклиентской» виртуальная частная сеть SSL является только в редчайших случаях, что, правда, никоим образом не ущемляет ее прав на существование.

ВОПРОС БЕЗОПАСНОСТИ

На уровне процессов SSL заметно отличается от IPSec, поскольку последний представляет собой протокол третьего уровня, а SSL работает на прикладном и, тем самым, на пользовательском уровне. Однако эти различия в узком смысле не имеют отношения к безопасности.

С исторической точки зрения SSL — старший из двух протоколов. Netscape выпустила вторую версию SSL в 1994 г., в то время как IPSec появился в 1995 г. или, соответственно, в 1998 г. SSL распространен гораздо шире: каждый браузер и сервер Web способен работать с ним. То же самое можно сказать о многочисленных реализациях в прочих приложениях — SMTP, POP, IMAP, telnet или LDAP. Кроме того, при помощи SSL защищаются графические пользовательские интерфейсы (Graphical User Interface, GUI) для администрирования бесчисленного множества аппаратного и программного обеспечения: не считая программ Microsoft, едва ли найдется серверное программное обеспечение или узко специализированное устройство, которое нельзя администрировать через браузер или внешний интерфейс HTTPS. Широчайшее распространение способствует тому, что какая-либо несовместимость серверов и клиентов не наблюдается в принципе. Тот, кто уже пытался построить крупные сложные структуры IPSec VPN, используя компоненты различных производителей, наверняка оценит подобное преимущество.

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

КОНТРОЛЬ НАД УСТРОЙСТВОМ ДОСТУПА

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

Если администратор не может или не хочет снабдить своих клиентов сертификатами, то при обращении пользователя к шлюзу SSL у него, как правило, запрашивается имя и пароль. Ответственный администратор наверняка не станет полагаться на статичные пароли, а предпочтет, скорее, двухфакторную аутентификацию на основе токенов или «метод одноразового пароля», к примеру S/KEY.

Даже при успешной аутентификации пользователь не должен иметь неограниченный доступ к находящимся в сети ресурсам. Как и в случае IPSec, шлюз SSL должен быть размещен в контролируемой брандмауэром демилитаризованной зоне DMZ. Однако SSL позволяет адаптировать специфические пользовательские правила безопасности к наличествующим условиям гораздо точнее и элегантнее. Вследствие ориентации протокола на соединение, обслуживающий SSL брандмауэр должен проверять не каждый отдельный пакет, а только принадлежность пакетов к успешно установленному соединению. Это заметно повышает производительность системы брандмауэра, особенно в крупных средах.

SSL работает на уровне приложений, поэтому доступ пользователя к какому-либо отдельному ресурсу может дифференцироваться и далее. Если, к примеру, одному пользователю в случае IPSec разрешается доступ к определенному серверу Internet, то ему разрешается доступ и ко всей системе. Однако правило на шлюзе SSL может звучать следующим образом: «не разрешать доступ к URL «http://:intranet/mycompany.de/HR/confidential/*», в то время как на все остальные области URL ограничения не накладываются.

КРАЙНИЙ СЛУЧАЙ — INTERNET-КАФЕ

Охотно и часто цитируемым, однако практически бесполезным для реалий корпоративного использования сценарием является доступ по VPN с общедоступного устройства. В более точной формулировке: насколько это безопасно, если генеральный директор вознамерился просмотреть последний отчет об обороте компании из китайского Internet-кафе? Ответ прост: такая попытка чревата неприятностями и должна быть запрещена политикой безопасности! При помощи «управления конечной точкой» администратор должен быть в состоянии управлять возможностью обращения пользователя к конкретным ресурсам в зависимости от идентифицированного уровня безопасности устройства доступа (см. Рисунок 1).

Рисунок 1. "Политика доступа" играет центральную роль: при управлении виртуальной частной сетью SSL (в данном случае - Aventail) администратор предоставляет пользователю права в соответствии с уровнем безопастности его машины доступа.

Если предприятие в виртуальной частной сети SSL работает с сертификатами браузера, то классификация уровня безопасности достаточно проста. Если же пользователь регистрируется успешно, но без сертификата, то полный доступ к ресурсам ему не предоставляется. К этому добавляется так называемая «проверка целостности клиента». При помощи автоматически загружаемого шлюзом SSL апплета могут быть установлены, к примеру, наличие и активность антивирусной программы или персонального брандмауэра. В зависимости от результата в доступе к VPN либо отказывают полностью, либо вводят ограничение по отношению к выбранным ресурсам. Правда, производители утверждают, что их апплеты, к примеру, уже очищают историю или кэш браузера либо автоматически удаляют все загруженные данные после окончания сеанса. Но такая автоматизация часто требует наличия на удаленном устройстве прав, которыми обычный пользователь не обладает. Кроме того, успешность этих процедур невозможно проверить со шлюза SSL. Поэтому «контроль защищенности конечной точки» неизбежно означает, что ненадежным удаленным средам может быть предоставлен только ограниченный доступ к внутренним ресурсам либо в нем вовсе отказано. Ответственный администратор разрешит своему генеральному директору в китайском Internet-кафе в лучшем случае доступ к Outlook и Web — не более того.

ЗАКЛЮЧЕНИЕ.

В конце стоит отметить, что в криптографическом отношении виртуальная частная сеть SSL столь же надежна, как и VPN на базе IPSec. Однако администратор должен следить за тем, чтобы в соответствии с уровнем безопасности устройства доступа разрешался только установленный правилами доступ к локальной сети и имеющимся в ней ресурсам. Маркетинговая фраза «в любой момент и в любом месте», может быть, и корректна с технической точки зрения, однако не учитывает глобальную потребность предприятия в обеспечении безопасности.

На контролируемой или, по крайней мере, классифицированной удаленной системе SSL способен полностью проявить свои сильные стороны. Путаница с различными IP-адресами по причине смены точек доступа в Internet или ошибки из-за многократной трансляции сетевых адресов через несколько proxy-серверов и брандмауэров — все эти трудности перестанут докучать пользователям, администраторам и службе поддержки. Кроме того, для пользователя удаленный доступ станет заметно более дружественным.

Таким образом, виртуальная частная сеть SSL предлагает надежный, менее трудоемкий, дружественный пользователю и недорогой, в отношении полной стоимости владения, удаленный доступ.

Франк Гревен — независимый автор. С ним можно связаться по адресу: wj@lanline.awi.de.

? AWi Verlag

Что такое «разделяемое туннелирование»?

«Разделяемое туннелирование» требует особого внимания в отношении обеспечения информационной безопасности. Оно имеет место, когда успешно аутентифицированный пользователь персонального компьютера со всеми необходимыми правами строит соединение VPN с локальной сетью своего предприятия и получает неограниченный доступ к определенным ресурсам. Может оказаться, что компьютер пользователя одновременно — через дополнительный интерфейс или тот же интерфейс и то же соединение — связан с другой сетью или Internet. Тогда у злоумышленника появляется возможность попасть в корпоративную сеть через клиентский компьютер как через ретранслятор, причем нzи брандмауэр, ни какое-либо другое средство обеспечения безопасности не распознает несанкционированный доступ, не говоря уже о его предотвращении.

Для предотвращения «разделяемого туннелирования» требуется отделить трафик данных в VPN от коммуникаций с Internet. Ряд имеющихся клиентов IPSec, кроме того, могут выявлять и пресекать ретранслируемые соединения, причем «пресечение» означает, что при наличии других сетевых соединений построение туннеля VPN не разрешается. Однако большинство производителей шлюзов SSL обеспечивают «контроль конечной точки» в этой же форме и предотвращают разделение туннеля.