СИСТЕМА И СПОСОБ ИСПОЛЬЗОВАНИЯ БЕЗОПАСНОСТИ, ПРИСУЩЕЙ ЗАЩИЩЕННОМУ КОММУНИКАЦИОННОМУ КАНАЛУ, ДЛЯ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ НЕЗАЩИЩЕННОГО КОММУНИКАЦИОННОГО КАНАЛА Российский патент 2006 года по МПК H04L29/06 

Область техники, к которой относится изобретение

Настоящее изобретение относится к компьютерным сетям типа клиент-сервер. Более конкретно, оно относится к системе и способу безопасного (защищенного) доступа к программным приложениям (прикладным программам) с использованием протокола RDP (Remote Display Protocol).

Уровень техники

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

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

Чтобы избежать этих проблем, клиент и сервер обычно аутентифицируют (верифицируют) друг друга, используя различные криптографические методы, как это описано, например, в патентных документах US 5706349, 1998 и WO 9838762, 1998. Одним из криптографических методов, используемых в сетях, является аутентификация, основанная на использовании так называемых "разрешений" (tickets). В большинстве подобных схем аутентификации производится передача разрешения, которое в типичном случае может быть одноразовым, может содержать ключ шифрования, предназначенный для будущего использования. Альтернативно или дополнительно разрешение может содержать секретный пароль для поддержки будущих коммуникаций. Когда и клиент, и сервер располагают ключом шифрования, между ними может осуществляться безопасная (защищенная) коммуникация. Способ и коммуникационная система для формирования защищенного коммуникационного канала между клиентом и сервером приложений, которые осуществляются с использованием подобных разрешений (в дополнение к традиционным средством идентификации и сертификации), могут рассматриваться в качестве ближайших аналогов настоящего изобретения, описаны в документе WO 9935783, H 04 L 9/30, 15.07.1999.

Однако существующие схемы аутентификации, основанные на применении разрешений, имеют несколько ограничений.

Во-первых, в типичном случае разрешение передается клиенту по незащищенному коммуникационному каналу, что позволяет оператору перехвата сообщений перехватить разрешение и извлечь ключ шифрования. Используя ключ шифрования, оператор перехвата сообщений может выступать в качестве сервера по отношению к клиенту или в качестве клиента по отношению к серверу. Во-вторых, существующие схемы не используют преимуществ защищенных веб-страниц. В частности, современные схемы верификации с применением разрешений делают трансакции через Интернет, такие как покупки, небезопасными, поскольку конфиденциальная информация, например данные о кредитной карте покупателя, может быть передана на неаутентифицированный сервер. В-третьих, прикладные программы, исполняемые на сервере, обычно передаются для отображения на дисплее компьютера-клиента в рамках соответствующего протокола по незащищенному коммуникационному каналу. Так, сети могут быть основаны на серверах специализированных приложений (таких как серверы Metaframe for Windows, выпускаемые заявителем настоящего изобретения), предназначенных для выполнения определенных программ, которые в типичном случае передаются на удаленный дисплей по незащищенному коммуникационному каналу. В-четвертых, хотя в типичном случае разрешение может быть использовано только один раз (т.е. является "одноразовым") и после своего первого использования не представляет никакой ценности, такое одноразовое разрешение не защищает пароль пользователя (который используется в качества регистрационного имени (login) при входе в операционную систему или в приложение) от перехвата при первой передаче разрешения. Как следствие, пароль пользователя оказывается не полностью защищенным от перехвата, так что сервер не может рассматриваться клиентом как аутентифицированный.

Раскрытие изобретения

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

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

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

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

Краткое описание чертежей

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

Фиг.1 - это блок-схема одного из вариантов коммуникационной системы, обеспечивающей защищенную связь между клиентом и сервером приложений в соответствии с изобретением.

Фиг.2 представляет собой схему, иллюстрирующую вариант коммуникаций, осуществляемых коммуникационной системой по фиг.1 с целью установления защищенной связи между клиентом и сервером приложений.

Осуществление изобретения

На фиг.1 приведена блок-схема одного из вариантов коммуникационной системы 100, в состав которой входит клиент 10, осуществляющий по каналу 25 коммуникации приложений коммуникацию с сервером 15 приложений и по коммуникационному каналу 30 коммуникацию с коммуникационным устройством 20. Коммуникационный канал 30 и канал 25 коммуникации приложений реализуются через сеть 27. В других вариантах осуществления коммуникационный канал 30 и канал 25 коммуникации приложений реализуются через различные сети. Например, коммуникационный канал 30 может проходить через Всемирную паутину (WWW), a канал 25 коммуникации приложений - через другую сеть (например, на основе прямого соединения через модем). Коммуникационный канал 30 является защищенным, поскольку передаваемые по нему сообщения шифруются. Сервер 15 приложений дополнительно связан с коммуникационным устройством 20 через серверный коммуникационный канал 35. Сервер 15 приложений и коммуникационное устройство 20 являются частями серверной сети 33. Используя защищенность защищенного коммуникационного канала 30, коммуникационная система 100 организует защищенную связь по незащищенному каналу 25 коммуникации приложений для того, чтобы безопасно отображать приложения на удаленном дисплее клиента 10.

Сеть 27 и серверная сеть 33 могут представлять собой локальную сеть (LAN) или более крупную (глобальную) сеть (WAN), или же сеть, состоящую из множества сетей (такую как Интернет или Глобальная паутина). Коммуникационный канал 30 может представлять собой любой защищенный коммуникационный канал. В одном из вариантов изобретения коммуникационный канал 30 осуществляет коммуникацию через глобальную сеть (т.е. является глобальным коммуникационным каналом). В одном из вариантов серверная сеть 33 представляет собой защищенную сеть, т.е. не имеет открытого доступа. Серверный коммуникационный канал 35 проходит через серверную коммуникационную сеть 33 и, следовательно, сам по себе может являться незащищенным коммуникационным каналом. В качестве вариантов выполнения коммуникационных каналов 25, 30 и 35 могут быть названы стандартные телефонные каналы локальных или глобальных сетей (LAN, WAN), в частности каналы Т1, Т3, 56kb, X.25, а также широкополосные линии (ISDN, Frame Relay, ATM), а также линии беспроводной связи. Связь через коммуникационные каналы 25, 30, 35 может осуществляться с использованием широкого набора протоколов (например, HTTP, TCP/IP, IPX, SPX, NetBIOS, Ethernet, RS232 и прямые асинхронные соединения).

Клиент 10 может представлять собой любой персональный компьютер (включая 286, 386, 486, Pentium, Pentium II, Macintosh), терминал на базе системы Windows, сетевой компьютер (Network Computer), беспроводное устройство (например, мобильный телефон), информационную приставку, персональный компьютер на базе процессора RISC Power, Х-устройство (X-device), рабочую станцию, мини-компьютер, большую ЭВМ, компьютеризованную записную книжку или любое другое коммуникационное устройство, способное осуществлять коммуникацию через защищенный коммуникационный канал 30. В одном из вариантов клиент 10 функционирует в соответствии с моделью клиент/сервер. В рамках данной модели выполнение приложений (прикладных программ) происходит полностью на сервере 15 приложений, а пользовательский интерфейс и информация, задаваемая нажатием клавиш или движением мыши, передается клиенту 10 по коммуникационному каналу 25 приложений. Пользовательский интерфейс может работать в текстовом режиме (например, в DOS) или в графическом режиме (например, в Windows). Платформы, которые могут быть применены в составе клиента, включают DOS и Windows СЕ для терминалов, работающих в системе Windows.

Согласно одному из вариантов в составе 10 имеется веб-браузер 40, такой как Internet Explorer™, разработанный фирмой Microsoft Corporation, для того, чтобы обеспечить подключение к глобальной сети. В другом варианте веб-браузер 40 использует протокол SSL (Secure Socket Layer), разработанный фирмой Netscape, для того, чтобы организовать защищенный коммуникационный канал 30 к коммуникационному устройству 20 через глобальную сеть.

Веб-браузер 40 включает в себя также пользовательский интерфейс с текстовым или графическим драйвером. Выходная информация от приложения, выполняемого на сервере 15 приложений, может отображаться у клиента 10 с помощью пользовательского интерфейса клиента 10 или пользовательского интерфейса веб-браузера 40. Кроме того, в состав клиента 10 входит также клиент 41 приложений для создания коммуникации и обмена информацией с сервером 15 приложений по коммуникационному каналу 25 приложений. Согласно одному из вариантов клиент 41 приложений относится к типу клиентов с архитектурой ICA (Independent Computing Architecture), разработанных заявителем настоящего изобретения (и далее обозначаемых, как ICA-клиенты). Другие варианты реализации клиента 41 приложений могут быть основаны на протоколе RDP (Remote Display Protocol), разработанном фирмой Microsoft Corporation, X-Windows (разработка института Massachusetts Institute of Technology, США), на клиенте ввода данных в традиционном приложении клиент/сервер или на Java-апплете.

Сервер 15 приложений является хостом для одного или более программных приложений (прикладных программ), к которым может иметь доступ клиент 10. Прикладные программы, которые являются доступными клиенту 10, обычно называются опубликованными приложениями. В качестве примеров таких приложений можно назвать программы обработки текстов, например MICROSOFT WORD®, и электронные таблицы, например MICROSOFT EXCEL®, разработанные фирмой Microsoft Corporation, программы финансовой отчетности, программы регистрации пользователей, программы, представляющие информацию по технической поддержке, базы данных для обслуживания пользователей, а также менеджеры приложений. В другом варианте сервер 15 приложений является членом серверной фермы (не изображена), которая представляет собой группу серверов, управляемую как единое целое.

В соответствии с одним из вариантов осуществления изобретения коммуникационное устройство 20 (в качестве которого далее рассматривается веб-сервер 20) является компьютером, который посылает веб-страницы клиенту 10. В других вариантах коммуникационным устройством 20 может служить любой персональный компьютер (включая 286, 386, 486, Pentium, Pentium II, Macintosh), терминал на базе системы Windows, сетевой компьютер (Network Computer), беспроводное устройство (например, мобильный телефон), информационная приставка, персональный компьютер на базе процессора RISC Power, Х-устройство (X-device), рабочая станция, мини-компьютер, большая ЭВМ, компьютеризованная записная книжка или любое другое коммуникационное устройство, способное организовать защищенный коммуникационный канал 30 с клиентом 10 через глобальную сеть.

В одном из вариантов веб-сервер 20 включает в себя также службу 60 выдачи разрешений (на фиг.1 и 2 для обозначения термина "разрешение" используется символ "Р"). Служба 60 выдачи разрешений контролирует защищенность коммуникации. Эта служба 60 генерирует разрешение, содержащее ключ шифрования. Разрешение передается клиенту 10 (т.е. веб-браузеру 40) по защищенному глобальному коммуникационному каналу 30. Передача разрешения клиенту 10 по защищенному глобальному коммуникационному каналу 30 облегчает осуществление защищенной коммуникации по коммуникационному каналу 25 коммуникации приложений между клиентом 10 и сервером 15 приложений в соответствии с принципами настоящего изобретения. В другом варианте служба 60' выдачи разрешений локализована на другом сервере 20'. При этом обеспечивается коммуникация между сервером 20' (и службой 60' выдачи разрешений) и сервером 15 приложений по серверному коммуникационному каналу 35'.

Согласно еще одному варианту служба 60 выдачи разрешений является отдельным (не изображенным) компонентом серверной сети 33. В этом случае веб-браузер 40 передает разрешение ICA-клиенту 41. Метод, который часто используется для того, чтобы передать данные от приложений, исполняемых на сервере 15 приложений по защищенной линии связи клиенту 10, заключается в том, чтобы передавать эти данные клиенту 10 через веб-сервер 20 по защищенной линии, соединяющей клиента 10 и веб-сервер 20. Данный метод неэффективен, потому что в коммуникации между сервером 15 приложений и клиентом 10 участвует дополнительный компонент, а именно веб-сервер 20. Настоящее изобретение предусматривает использование разрешений для осуществления защищенной связи непосредственно между сервером 15 приложений и клиентом 10, т.е. исключает промежуточную передачу данных, связанных с приложением, от сервера 15 приложений к веб-серверу 20.

Пользователь, пользующийся клиентом и желающий отобразить на удаленном дисплее клиента 10, например, какое-либо приложение или рабочий стол сервера, сначала устанавливает соединение 32 с веб-сервером 20 через глобальный коммуникационный канал 30 и передает свое регистрационное имя и пароль на веб-сервер 20. В одном из вариантов пользователь использует веб-браузер 40 клиента для того, чтобы запросить у веб-сервера 20 приложение, которое представлено на веб-странице, отображаемой веб-браузером 40.

Согласно следующему варианту веб-браузер 40 использует протокол SSL для создания защищенного коммуникационного канала 30. С этой целью веб-браузер 40 или приложение, исполняемое у клиента 10, пытается установить соединение с защищенной веб-страницей на веб-сервере 20. В ответ веб-сервер 20 подтверждает клиенту 10 идентификацию веб-сервера путем отправки клиенту 10 защищенного сертификата веб-сервера. Этот сертификат выдается веб-серверу центром выдачи сертификатов (СА, Certification Authority). Список надежных СА, например, в форме их публичных (открытых) ключей включен в программное обеспечение веб-браузера 40. Клиент 10 производит проверку сертификата веб-сервера путем дешифрования подписи СА, входящей в сертификат веб-сервера, используя публичный ключ СА, встроенный в веб-браузер 40 (или в приложение).

Таким образом, для того, чтобы организовать защищенный коммуникационный канал с использованием SSL, до того, как будет осуществлена попытка установить соединение с защищенной веб-страницей, веб-браузер 40 или приложение, исполняемое у клиента 10, должны располагать публичным ключом СА, встроенным в их программное обеспечение. В качестве альтернативы применению протокола SSL для организации защищенного глобального коммуникационного канала 30 веб-браузер 40 может связаться с веб-сервером 20 по глобальному коммуникационному каналу 30, используя другие протоколы защиты. Неисчерпывающий список таких протоколов включает Secure Hypertext Transfer Protocol (SHTTP), разработанный фирмой Terisa Systems (США), HTTP over SSL (HTTPS), Private Communication Technology (PCT), разработанный фирмой Microsoft Corporation, Secure Electronic Transfer (SET), разработанный американскими фирмами Visa International, Incorporated Mastercard International, Incorporated, и Secure-MIME (S/MIME), разработанный фирмой RSA Security (США).

После того, как соединение 32 установлено, веб-сервер 20 генерирует разрешение для сеанса коммуникации. У разрешения имеются первая часть и вторая часть. В соответствии с одним из вариантов первая часть, называемая также идентификатором сеанса (ИД сеанса), представляет собой случайное криптографическое число, которое может быть использовано в течение определенного периода времени, задаваемого веб-сервером 20. Вторая часть является ключом шифрования, который далее именуется "сеансовым ключом".

Веб-сервер 20 записывает разрешение в свою локальную память и затем передает (см. стрелку 34 на фиг.1) копию разрешения на веб-браузер 40 клиента 10.

В одном из вариантов разрешение содержит также дополнительную информацию, такую как сетевой адрес сервера 15 приложений. В другом варианте веб-сервер 20 отдельно передает клиенту 10 адрес сервера 15 приложений. Например, если клиент 10 запрашивает у веб-сервера 20 приложение с определенным именем, веб-сервер преобразует имя приложения в его сетевой адрес. Неисчерпывающий перечень дополнительных сведений, вносимых в разрешение, включает период времени, в течение которого разрешение является действительным; размер экрана для приложения, подлежащего отображению у клиента 10, пределы ширины полосы коммуникационного канала 30 и/или коммуникационного канала 25 приложений, а также биллинговую информацию. Как будет более подробно описано далее, веб-сервер 20, кроме того, ассоциирует регистрационные данные пользователя (например, его пароль) с разрешением, хранящимся в локальной памяти, для последующего извлечения этой информации сервером 15 приложений.

ICA-клиент 41 получает разрешение от веб-браузера 40 и затем передает (как это изображено стрелкой 42) ИД сеанса (т.е. первую часть разрешения) на сервер 15 приложений. ИД сеанса может передаваться в зашифрованном виде или открытым текстом. Сервер 15 приложений дешифрует ИД сеанса (если он был зашифрован) и передает запрос (как это обозначено стрелкой 44) на веб-сервер 20 для получения сеансового ключа, который соответствует ИД сеансу, полученному от клиента 10. Веб-сервер 20 верифицирует ИД сеанса, как это будет пояснено далее, и посылает (как это обозначено стрелкой 48) соответствующий сеансовый ключ серверу 15 приложений по серверному коммуникационному каналу 35.

Теперь и сервер 15 приложений, и клиент 10 (т.е. ICA-клиент 41) обладают копией сеансового ключа, хотя они не обращались за передачей разрешения или сеансового ключа по незащищенному каналу 25 коммуникации приложений. Благодаря использованию сеансового ключа для шифрования и дешифрования коммуникаций по ранее незащищенному каналу 25 коммуникации приложений клиент 10 и сервер 15 приложений осуществляют защищенную коммуникацию 50 через канал 25 коммуникации приложений. При этом не производится передачи регистрационной информации (например, пароля) от клиента 10 серверу 15 приложений по незащищенному каналу 25 коммуникации приложений. Таким образом, использование изобретения усиливает защищенность коммуникации 50 по незащищенному каналу 25 коммуникации приложений, поскольку не позволяет операторам перехвата сообщений, передаваемых по незащищенному каналу 25 коммуникации приложений, получить доступ к чувствительной информации, такой как пароль.

Кроме того, поскольку сервер 15 приложений и клиент 10 общаются с использованием одного и того же сеансового ключа, они совместно владеют секретом, который был передан им службой 60 выдачи разрешений. Служба 60 выдачи разрешений косвенным образом аутентифицирует сервер 15 приложений и клиента 10, т.е. подтверждает их подлинность. Тем самым сервер 15 приложений и клиент 10 осуществляют взаимную аутентификацию. В одном из вариантов клиент 10 снова передает пароль пользователя через глобальный коммуникационный канал 30 на веб-сервер 20 для того, чтобы достичь совместимости с системами обеспечения преемственности данных (например, с немодифицированной регистрационной последовательностью операционной системы на веб-сервере 20, которая требует от клиента 10 многократно передать пароль пользователя).

На фиг.2 более подробно проиллюстрированы варианты способа, осуществляемого коммуникационной системой 100 для установления защищенной коммуникации 50 по каналу 25 коммуникации приложений между клиентом 10 и сервером 15 приложений. На шаге 200 веб-браузер 40 отображает на веб-странице, которую видит пользователь клиентом 10, список сетевых контактов (адресов) программных приложений или рабочих столов серверов. Пользователь клиентом 10 с помощью веб-браузера 40 запрашивает (шаг 205) программное приложение у веб-сервера 20. Согласно одному из вариантов веб-браузер 40 организует защищенный глобальный коммуникационный канал 30, используя описанный ранее протокол SSL. В этом варианте клиент 10 (в частности, его веб-браузер 40) аутентифицирует веб-сервер 20, используя сертификат публичного ключа (например, Х509). В модифицированном варианте клиент 10 также аутентифицируется перед веб-сервером 20 с помощью сертификата публичного ключа.

Согласно другому варианту веб-сервер 20 аутентифицирует пользователя, когда пользователь использует веб-браузер 40 для запроса приложения от веб-сервера 20. Например, веб-сервер 20 требует от пользователя его регистрационное имя и пароль, причем это требование отображается на веб-браузере 40. Пользователь сообщает (шаг 210) свои регистрационные данные веб-браузеру 40. После этого веб-браузер 40 передает (на шаге 220) регистрационное имя пользователя и его пароль веб-серверу 20 по защищенному глобальному коммуникационному каналу 30. В другом варианте регистрационными данными пользователя являются любой код или метод, который веб-сервер 20 готов принять для идентификации учетной записи пользователя на веб-сервере 20.

Веб-сервер 20 передает (шаг 230) регистрационные данные пользователя службе 60 выдачи разрешений. Служба 60 верифицирует (на шаге 240) регистрационные данные пользователя и определяет, имеет ли пользователь право на запрашиваемое приложение. В зависимости от объявленной политики по обеспечению безопасности для данного приложения служба 60 выдачи разрешений либо разрешает, либо запрещает пользователю доступ к приложению. Если служба 60 выдачи разрешений отказала в доступе, веб-браузер 40 отображает у клиента 10 сообщение об ошибке в формате HTML или в виде соответствующей веб-страницы. Если же служба 60 выдачи разрешений разрешает доступ к запрошенному приложению, она генерирует (шаг 245) разрешение сеанса и передает (на шаге 259) разрешение веб-серверу 20.

Как было описано ранее, разрешение содержит ИД сеанса и сеансовый ключ. ИД сеанса может быть использован один раз в течение определенного периода времени, т.е. он делает разрешение "одноразовым", не имеющим никакой ценности после его первого использования. Веб-сервер 20 записывает (шаг 253) разрешение в локальную память. В модифицированном варианте веб-сервер 20 ассоциирует регистрационные данные, сообщенные пользователем на шаге 210, и другую информацию, относящуюся к обеспечению безопасности и используемую для выдачи разрешения на сеанс (например, имя приложения), с сохраненным разрешением для последующего извлечения сервером 15 приложений.

Затем веб-сервер 20 передает (шаг 255) разрешение клиенту 10 через защищенный глобальный коммуникационный канал 30.

Веб-браузер 40 извлекает (шаг 260) из разрешения ИД сеанса и представляет его (шаг 265) серверу 15 приложений. Сервер 15 приложений проверяет ИД сеанса, чтобы удостовериться, что данный ИД сеанса не был уже использован тем же клиентом 10. В соответствии с одним из вариантов сервер 15 приложений осуществляет мониторинг каждого разрешения (т.е. хранит в локальной памяти соответствующий ИД сеанса), который передает на этот сервер клиент 10. В другом варианте проверку ИД сеанса для того, чтобы удостовериться, что данный ИД сеанса не был уже использован тем же клиентом 10, осуществляет служба 60 выдачи разрешений. Еще в одном варианте служба 60 выдачи разрешений осуществляет мониторинг разрешения, который она передает веб-серверу 20 для того, чтобы удостовериться, что каждый ИД сеанса передается в службу 60 выдачи разрешений только один раз.

После этого сервер 15 приложений использует ИД сеанса для того, чтобы определить сеансовый ключ, ассоциированный с этим ИД сеанса. Для этого сервер 15 приложений посылает ИД сеанса в службу 60 выдачи разрешений и запрашивает (шаг 270) у службы 60 выдачи разрешений веб-сервера 20 сеансовый ключ в ответ на ИД сеанса. Служба 60 выдачи разрешений обращается к локальной памяти и использует полученный ИД сеанса в качестве поискового предписания для обнаружения ассоциированной с ним информации о разрешении. После этого служба 60 выдачи разрешений возвращает (шаг 280) сеансовый ключ с ИД сеанса серверу 15 приложений.

Для того чтобы оптимизировать коммуникацию между сервером 15 приложений и веб-сервером 20, согласно альтернативному варианту изобретения веб-сервер 20 передает (на шаге 266, изображенном штриховой линией) серверу 15 приложений дополнительную информацию (например, имя запрашиваемого приложения, регистрационные данные пользователя), которая ранее (на шаге 255) была ассоциирована с разрешением.

Сервер 15 приложений извлекает (шаг 267, изображенный штриховой линией) дополнительную информацию, связанную с разрешением, и на основании этой информации дает разрешение на сеанс связи. Эта дополнительная информация, такая как пароль пользователя и/или имя запрошенного приложения, не была передана серверу 15 приложений клиентом 10 через незащищенный канал 25 коммуникации приложений, т.е. эта информация была защищена от потенциального перехвата. Согласно данному варианту сервер 15 приложений верифицирует дополнительную информацию (шаг 268, изображенный штриховой линией). Если дополнительная информация не верифицирована, сервер 15 приложений отказывает пользователю в доступе к запрошенному приложению (шаг 269, изображенный штриховой линией). Если дополнительная информация верифицирована, сервер 15 приложений разрешает доступ к запрошенному приложению и, как это было описано ранее, запрашивает (на шаге 270) сеансовый ключ у службы 60 выдачи разрешений.

В другом варианте служба 60 выдачи разрешений производит дополнительные проверки ИД сеанса. Например, служба 60 выдачи разрешений проводит проверки ИД сеанса с целью раннего обнаружения его повторного использования (т.е. проверки того, что ИД сеанса не передавался ранее в службу 60 выдачи разрешений) и/или атак класса DoS (Denial of Service), состоящих в перегрузке и последующем выводе из строя удаленного сервера посылкой большого количества нелегитимных пакетов данных. Еще в одном варианте веб-сервер 20 посылает первую и вторую часть разрешения на сервер 15 приложений до того, как сервер 15 приложений запросит их (шаг 270). В этом случае шаг 270 может быть исключен. Согласно данному варианту сервер 15 приложений сохраняет сеансовый ключ в своей локальной памяти и извлекает из нее этот сеансовый ключ после того, как клиент 10 представит серверу 15 приложений (на шаге 265) ИД сеанса.

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

В одном из вариантов канал 25 коммуникации приложений становится защищенным каналом с помощью протокола SSL. В этом варианте служба 60 выдачи разрешений заменяет сеансовый ключ в составе разрешения сертификатом сервера приложений. Клиент 10 использует сертификат сервера приложений для того, чтобы организовать коммуникацию с сервером 15 приложений. Сертификат сервера приложений передается клиенту 10 по глобальному коммуникационному каналу 30 в ответ на запрос разрешения.

В результате передачи сертификата сервера приложений клиенту 10 по защищенной линии (т.е. глобальному коммуникационному каналу 30) этот сертификат не должен быть подписан хорошо известным центром выдачи сертификатов (СА). Хотя клиент 10 не получил заранее сертификат или ключ СА, при использовании сертификата сервера приложений, включенного в разрешение, обеспечивается аутентифицированное безопасное соединение по каналу 25 коммуникации приложений.

Так, если клиент запрашивает какой-либо другой SSL-компонент (например, отдельный вариант или реализацию затребованного программного приложения), но не имеет сертификата в своей локальной памяти (т.е. в базе данных, на локальном диске, в постоянном или оперативном запоминающем устройстве), клиент 10 может использовать сертификат сервера приложений, переданный ему в составе разрешения для того, чтобы установить аутентифицированное безопасное соединение по каналу 25 коммуникации приложений. В частности, клиент 10 использует сертификат сервера приложений, полученный в составе разрешения, когда в его локальной памяти отсутствует базовый сертификат СА, ассоциированный с запрашиваемым SSL-компонентом (или когда клиент 10 располагает неполным перечнем сертификатов СА, в котором отсутствует сертификат СА для запрашиваемого SSL-компонента), причем клиент 10 не может получить доступ к базе данных СА веб-браузера 40. Кроме того, поскольку подписанный сертификат СА необходим для веб-сервера 20, но не требуется серверу 15 приложений (например, каждому серверу 15 приложений, который является членом серверной фермы), сокращаются затраты (включая накладные расходы), связанные с получением требуемого количества подписанных сертификатов СА для осуществления защищенной связи. В другом варианте сервер 15 приложений хранит секретный (приватный) ключ для дешифрования сообщений, которые зашифрованы соответствующим публичным ключом. Служба 60 выдачи разрешений затем посылает соответствующий публичный ключ сервера 15 приложений клиенту 10 для дешифрования сообщений.

В данном варианте ИД сеанса имеет дополнительную полезность, поскольку он гарантирует, что клиент 10 может получить доступ к запрошенному приложению, причем только однократный доступ, поскольку служба 60 выдачи разрешений (или веб-сервер 20) осуществляет мониторинг разрешения (т.е. ИД сеанса). Более того, если сервер 15 приложений и клиент 10 используют различные сеансовые ключи для шифрования и дешифрования коммуникаций через канал 25 коммуникации приложений, оператор перехвата не может модифицировать ИД сеанса, переданный клиентом 10 серверу 15 приложений. Действительно, ИД сеанса и криптографическая контрольная сумма в этом случае не соответствуют контрольной сумме, ожидаемой сервером 15 приложений (например, в рамках проверки целостности данных). Как следствие, клиент 10 и сервер 15 приложений могут обнаружить ситуацию использования различных сеансовых ключей сервером 15 приложений и клиентом 10, например, в случае атаки типа "вмешательство во взаимодействие" ("man-in-the-middle") для шифрования и дешифрования сообщений, передаваемых по каналу 25 коммуникации приложений.

В соответствии с еще одним вариантом сеансовый ключ, по существу, эквивалентен нулевому значению (т.е. разрешение содержит только одноразовый идентификатор или одноразовый идентификатор и постоянное значение в качестве сеансового ключа). Когда сеансовый ключ, по существу, эквивалентен нулевому значению, клиент 10 не передает регистрационные данные пользователя (например, пароль) на сервер 15 по незащищенному каналу 25 коммуникации приложений. Таким образом, поскольку разрешение выдается только на однократное использование и предоставляет доступ только к ранее верифицированному ресурсу (например, к ICA-клиенту 41), появляется возможность устранить внешний доступ к паролю при обеспечении индивидуального контроля за уровнем доступа к сеансу даже при нулевом или фиксированном значении сеансового ключа.

Далее, поскольку никакая информация не преконфигурируется в веб-браузер 40 или в клиент 10 для того, чтобы обеспечить дистанционное отображение запрошенного приложения (например, потому что клиенту не обязательно получать сертификат сервера или сертификат СА), способ по изобретению представляет собой решение с "нулевой инсталляцией" для обеспечения безопасного доступа к приложениям, предлагаемым на рабочих столах серверов глобальной сети. Кроме того, веб-браузер 40 может получать и разрешение, и ICA-клиента 41 от веб-сервера 20 по коммуникационному каналу 30. В этом варианте веб-сервер 20 передает, как это было описано выше, разрешение и документ в стандарте MIME, указывающий, что данные включают в себя "документ" для ICA-клиента 41 (в качестве приложения-помощи). Документ в стандарте MIME вызывает ICA-клиента 41, и веб-браузер 40 передает разрешение этому ICA-кпиенту 41. Тем самым обеспечивается возможность использования защищенности коммуникационного канала 30 для обеспечения безопасности канала 25 коммуникации приложений без предварительного инсталлирования ICA-клиента 41 в составе 10.

Из рассмотрения описанных выше вариантов осуществления изобретения для специалиста в данной области будет понятно, что могут быть реализованы и другие варианты изобретения. В связи с этим изобретение не должно быть ограничено конкретными вариантами его осуществления; объем его защиты должен определяться только прилагаемой формулой изобретения.

Изобретение относится к системе и способу формирования защищенного коммуникационного канала между клиентом и сервером приложений. Техническим результатом является повышение защищенности доступа к компьютерным приложениям. Согласно способу служба выдачи разрешений генерирует разрешение, содержащее идентификатор и сеансовый ключ. Коммуникационное устройство получает это разрешение от службы выдачи разрешений и передает его клиенту по защищенному коммуникационному каналу. Клиент передает идентификатор, входящий в состав разрешения, серверу приложений по каналу коммуникации приложений. Затем сервер приложений получает от службы выдачи разрешений копию сеансового ключа, входящего в состав разрешения. После этого сообщения, которыми обмениваются клиент и сервер приложений, шифруются с использованием сеансового ключа для того, чтобы сформировать защищенный коммуникационный канал на основе канала коммуникации приложений. Система реализует действия способа. 6 н. и 82 з.п. ф-лы, 2 ил.

1. Способ формирования защищенного коммуникационного канала между клиентом и сервером приложений, предусматривающий следующие операции:

(а) запрашивание клиентом у веб-сервера исполнения на сервере приложений приложения с передачей информации от указанного приложения, выполняемого на сервере приложений, клиенту,

(б) генерирование службой выдачи разрешений разрешения, содержащего идентификатор и сеансовый ключ,

(в) получение веб-сервером указанного разрешения от службы выдачи разрешений,

(г) передача веб-сервером указанного разрешения клиенту по защищенному коммуникационному каналу,

(д) передача клиентом идентификатора, входящего в состав указанного разрешения, серверу приложений,

(е) получение сервером приложений с использованием указанного идентификатора копии указанного сеансового ключа от службы выдачи разрешений,

(ж) формирование между клиентом и сервером приложений канала коммуникации приложений,

(з) исполнение сервером приложений приложения, указанного в запросе,

(и) передача сервером приложений информации от указанного приложения по каналу коммуникации приложений с использованием протокола удаленного отображения и

(к) шифрование с использованием указанного сеансового ключа указанной информации, передаваемой клиенту по каналу коммуникации приложений.

(а) запрашивание клиентом у веб-сервера исполнения на сервере приложений приложения с передачей информации от указанного приложения, выполняемого на сервере приложений,

(б) формирование защищенного глобального коммуникационного канала между веб-браузером, функционирующим в составе клиента, и веб-сервером,

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

(г) формирование канала коммутации приложений к серверу приложений,

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

(е) получение информации от приложения, идентифированного в указанном запросе, от сервера приложений по каналу коммуникации приложений с использованием протокола удаленного отображения и

(ж) дешифрование указанной информации с использованием указанного сеансового ключа.

(а) получение от веб-сервера запроса на исполнение в интересах клиента приложения и на передачу указанному клиенту информации от указанного приложения, выполняемого на указанном сервере приложений,

(б) получение идентификатора от указанного клиента,

(в) получение от сервера приложений копии сеансового ключа, ассоциированного с указанным идентификатором,

(г) формирование канала коммуникации приложений к клиенту,

(д) выполнение приложения, идентифицированного в указанном запросе,

(е) передача информации от указанного выполняемого приложения по каналу коммуникации приложений с использованием протокола удаленного отображения и

(ж) шифрование указанной информации с использованием сеансового ключа.

службу выдачи разрешений, генерирующую ассоциированное с клиентом разрешение, которое содержит идентификатор и сеансовый ключ,

веб-сервер, связанный со службой выдачи разрешений и выполненный с возможностью получения от клиента запроса на исполнение приложения на сервере приложений и от службы выдачи разрешений указанного разрешения и передачи разрешения клиенту по защищенному коммуникационному каналу, причем клиент выполнен с возможностью передачи идентификатора, содержащегося в разрешении, указанному серверу приложений, и сервер приложений, выполненный с возможностью получения, с использованием указанного идентификатора, копии сеансового ключа от службы выдачи разрешений, причем клиент и сервер приложений выполнены с возможностью формирования канала коммуникации приложений, при этом сервер приложений исполняет указанное приложение, идентифицированное в указанном запросе, и передает информацию от указанного выполняемого приложения по каналу коммуникации приложений с использованием протокола удаленного отображения,

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

веб-браузер, функционирующий в составе клиента и формирующий защищенный глобальный коммуникационный канал с веб-сервером,

причем веб-браузер выполнен с возможностью

передачи веб-серверу запроса на исполнение на сервере приложений приложения с передачей клиенту информации от указанного приложения, выполняемого на сервере приложений,

получения от веб-сервера разрешения, ассоциированного с клиентом и содержащего идентификатор и сеансовый ключ, и

передачи идентификатора, входящего в состав указанного разрешения, серверу приложений, и

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

службу выдачи разрешений, генерирующую ассоциированное с клиентом разрешение, которое содержит идентификатор и сеансовый ключ,

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

получения от клиента запроса на исполнение для клиента приложения на сервере приложений и на передачу клиенту информации от указанного приложения и

передачи разрешения клиенту по защищенному глобальному коммуникационному каналу, и

сервер приложений, выполненный с возможностью

получения идентификатора, входящего в состав указанного разрешения, получения копии сеансового ключа от веб-сервера,

формирования канала коммуникации приложений к клиенту,

выполнения указанного приложения,

передачи информации от приложения, идентифицированного в указанном запросе, клиенту по каналу коммуникации приложений с использованием протокола удаленного отображения,

шифрования указанной информации с использованием указанного сеансового ключа.