Все большее количество важных деловых процессов выносится за пределы предприятия, и перед администраторами ИТ встает дилемма: с одной стороны, они уже не могут контролировать хостируемые вовне приложения, к примеру, популярную систему управления взаимоотношениями с клиентами и партнерами (Customer Relationship Management, CRM) от Salesforce.com (см. Рисунок 1). С другой, им приходится обеспечивать стабильную работу этих приложений с такой же производительностью, с которой функционируют внутренние важные приложения. Причем обмен данными между пользователями и приложениями должен оставаться надежным и конфиденциальным.
Соединение по глобальной сети при доступе к централизованным ресурсам ИТ из филиалов, домашних офисов и удаленных сотрудников обычно увеличивает время отклика как внутренних, так и внешних приложений Web. Децентрализованные предприятия, как правило, направляют весь трафик Internet из филиалов и от внешних сотрудников сначала по глобальной сети в свой основной вычислительный центр и лишь оттуда передают его в Internet, чтобы контролировать весь этот трафик централизованно. Но все важные приложения зависят от условий в глобальной сети и вынуждены делить имеющуюся пропускную способность с остальным трафиком, передаваемым между филиалом и центром. В этом случае можно использовать решения для оптимизации работы глобальной сети, чтобы более эффективно задействовать доступную пропускную способность, снизить время задержки, улучшить функционирование протоколов и назначить приложениям приоритет в соответствии с их статусом. Для ускорения трафика SSL в глобальной сети применяются разные подходы, обладающие как преимуществами, так и недостатками.
СОЕДИНЕНИЕ SSL
Чтобы разобраться в особенностях этих подходов, сначала вспомним, что собой представляет соединение SSL. Клиентский компьютер отправляет сообщение с приветствием выбранному серверу, который работает со всеми поддерживаемыми клиентами алгоритмами шифрования. Сервер отвечает на сообщение и передает клиенту сведения о лучшем из доступных алгоритмов шифрования. Начиная
с третьей версии протокола SSL сервер отсылает клиенту еще и сертификат, в котором содержатся открытые ключи сервера, а также информация об инстанции, выдавшей и подписавшей этот сертификат.
РАЗГРУЗКА SSL
Описанное «рукопожатие SSL» и связанный с ним обмен ключами между клиентом и сервером требует множества вычислений, которые в случае большого количества одновременных соединений заметно загружают процессор сервера Web.
КАРТЫ PCI И СЕТЕВЫЕ УСКОРИТЕЛИ
Чтобы освободить центральный процессор от решения этой задачи, используются так называемые карты ускорения SSL. Они выпускаются в форме карт PCI и обычно берут на себя асимметричную часть квитирования связи SSL, в то время как симметричная часть шифрования, требующая намного меньшего объема вычислений, выполняется сервером. Иначе говоря, карты ускорения SSL хорошо подходят для того, чтобы разгрузить отдельные серверы от некоторых задач SSL — отсюда и термин «разгрузка» (offload).
Так называемые сетевые ускорители работают по схожему принципу. Но разгрузчики этого типа представляют собой самостоятельные устройства, они обслуживают один или несколько серверов Web и берут на себя обработку всего трафика SSL. Оба вида разгрузчиков SSL служат исключительно для снятия нагрузки с серверов Web. Нехватку пропускной способности и проблемы с задержкой они не устраняют и трафик SSL не контролируют.
ПОСРЕДНИКИ SSL
Стремясь не только разгрузить процессор сервера Web, но, кроме того, оптимизировать и ускорить трафик SSL, производители решений для оптимизации глобальных сетей полагаются на так называемых посредников SSL. Обычно такие посредники проводят санкционированную атаку на соединение между клиентом и сервером, которая получила название «человек в середине»: по отношению к клиенту посредник ведет себя как сервер, по отношению к серверу — как клиент. В результате посредник может просматривать передаваемые данные и на основе этой и прочей информации, к примеру, о времени суток или сведений о пользователе, принимать решения, а также сокращать объем передаваемых данных путем сжатия. Посредники SSL сталкиваются с необходимостью расшифровки поступающего с обеих сторон трафика для контроля и оптимизации. Затем посредник SSL должен снова зашифровать данные и отправить получателю. Проблема в том, что посредник не знает частного ключа сервера Web, и поэтому сгенерировать симметричный ключ путем анализа квитирования SSL он не может. Чтобы решить эту проблему, производители оптимизаторов глобальной сети пользуются двумя разными методами.
ДВА ПОДХОДА К РЕШЕНИЮ ПРОБЛЕМ SSL
Первый подход заключается в передаче сертификата сервера Web вместе с персональным ключом от сервера посреднику. Это во многом соответствует принципу работы разгрузчиков SSL, которые проводят квитирование SSL с оригинальным сертификатом. Однако указанный метод обладает несколькими существенными недостатками. Прежде всего, он предполагает возможность доступа отвечающего за посредника подразделения к персональному ключу сервера приложений, трафик которого необходимо оптимизировать. В случае внешних приложений это невозможно, поскольку првайдер услуги никогда не передаст сертификаты своих серверов. Проблемы могут возникнуть даже с внутренними приложениями предприятия, если они размещаются в другом подразделении. Однако преимущество подхода заключается в том, что на клиентах не нужно проводить никаких изменений, поскольку посредник с персональным сертификатом сервера ведет себя с клиентом так же, как и исходный сервер. Но следует помнить, что посредник, как и сервер Web, должен быть защищен от атак на сертификат. Иначе говоря, для тех, кто заинтересован в оптимизации отдельных внутренних приложений, этот метод предпочтителен. Однако внешние приложения Web, шифруемые при помощи SSL, остаются без внимания.
В случае второго подхода (см. Рисунок 2) посредник не использует сертификат сервера для построения соединения SSL — на базе исходного сертификата сервера он генерирует эмулируемый сертификат сервера для каждого квитирования SSL, в котором содержатся те же данные, что и в сертификате сервера — вплоть до открытого ключа. Но теперь открытый ключ исходит от посредника. Затем он подписывает временный сертификат сервера и представляет его клиенту. Со стороны сервера посредник строит самое обычное соединение SSL с сервером назначения. Чтобы клиент не сообщал пользователю о ненадежности эмулированного сертификата посредника, администратор должен добавить его в списки заслуживающих доверия центров сертификации (Certificate Authority, CА) на всех клиентах. В большинстве случаев это выполняется единожды при помощи принятых на предприятии механизмов развертывания программного обеспечения. Преимущество рассматриваемой архитектуры состоит в том, что посредник может контролировать и оптимизировать весь трафик SSL внешних и внутренних приложений.
Однако при некоторых обстоятельствах предприятия не хотят или не имеют права обрабатывать определенный трафик SSL, — к примеру, когда сотрудники запрашивают состояние своего счета в интерактивном режиме. Поэтому в отношении каждого пользователя посредник должен различать URL или категории вызываемого сайта, проходит ли данный сеанс через него или пропускается без изменений и без оптимизации. Какими же возможностями обладают посредники в оптимизаторах глобальных сетей для ускорения зашифрованного трафика SSL?
ОПТИМИЗАЦИЯ SSL
Прежде всего, устройства, располагающие информацией о содержимом трафика, могут предоставлять определенным внутренним и внешним приложениям большую пропускную способность, чем остальному трафику. Иначе говоря, оптимизация пропускной способности позволяет не пропускать в глобальную сеть нежелательные протоколы и приложения, которые тоже используют SSL. Важные приложения получают гарантированную пропускную способность, в то время как менее критичные — при необходимости —
«притормаживаются». В случае приложений на базе Web оптимизаторы глобальных сетей могут оптимизировать протоколы HTTP и TCP. При использовании HTTP посредник пытается, к примеру, параллельно выполнить максимальное количество передач и таким образом ускорить построение страницы Web. Если данные шифруемых посредством SSL приложений Web представлены на посреднике в открытом виде, то он может сохранять отдельные объекты или части (кэширование объектов или кэширование байтов).
КЭШИРОВАНИЕ ОБЪЕКТОВ ИЛИ КЭШИРОВАНИЕ БАЙТОВ
Если кэширование объектов позволяет временно сохранять целые файлы и лишь один раз отправлять их по сети в случае многократного запроса, то кэширование байтов позволяет делать то же самое для отдельных фрагментов файлов. Если, к примеру, в презентацию PowerPoint на сервере SharePoint со времени последней загрузки были добавлены еще два слайда, оптимизатор передает по глобальной сети только новые слайды, а остальные извлекает из кэша. Объем текста со страниц HTML, наконец, можно сократить троекратно, что, безусловно, экономит пропускную способность глобальной сети.
ЗАКЛЮЧЕНИЕ
Доля трафика Web, который шифруется с помощью протокола защищенных сокетов (Secure Sockets Layer, SSL), ежегодно растет на 30%. Все большее количество шифруемых при помощи SSL приложений Web вынуждают предприятия пользоваться методами ускорения SSL в глобальной сети. Тем, кто намерен ускорить только внутренние приложения и обладает доступом к серверным сертификатам, достаточно решений с архитектурой, схожей с разгрузкой SSL. Если же наряду с внутренними приложениями необходимо ускорять и внешние, на помощь придут решения, поддерживающие эмуляцию серверных сертификатов.
Мартин Вальцер — старший консультант по сетям в компании Blue Coat Systems.
© AWi Verlag