ОБЕСПЕЧЕНИЕ СОГЛАСОВАННОГО ПРОХОДА БРАНДМАУЭРА, ИМЕЮЩЕГО ИНФОРМАЦИЮ О ПРИЛОЖЕНИИ Российский патент 2011 года по МПК G06F15/00 

Предпосылки и уровень техники

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

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

В одном примере брандмауэра клиентская компьютерная система может организовывать туннель через брандмауэр от сетевого уровня на клиентской компьютерной системе к соответствующему сетевому уровню на серверной компьютерной системе с использованием виртуальной частной сети ("VPN"), сервера удаленного доступа ("RAS") или другого родственного типа соединения с проходом через брандмауэр. Подобного рода туннельное соединение с проходом через брандмауэр, в общем случае, предусматривает, что клиент использует защищенный протокол передачи гипертекстовых файлов ("HTTPS"), который представляет собой механизм http, обеспечивающий обмен зашифрованной информацией с использованием механизмов шифрования протокола защищенных сокетов ("SSL") или защиты транспортного уровня ("TLS") для аутентификации на шлюзовом сервере. После того, как шлюзовой сервер разрешает проход через брандмауэр, клиентская компьютерная система может обращаться ко всем ресурсам “позади” брандмауэра, например с использованием одного или нескольких сокетов для взаимодействия с данным ресурсом.

Согласно другому решению с проходом через брандмауэр, например, предусматривающему соединение уровня приложений на клиенте с уровнем приложений на сервере, клиенту также может понадобиться вызывать протокольный процессор, связанный с нужным ему ресурсом. Протокольный процессор в этом случае, является, по существу, программным интерфейсом приложения ("API"), который также обычно пишется сторонним разработчиком в виде плагина (сменного модуля) (т.е. "плагина протокольного процессора") к стеку обмена RPC/HTTPS. Кроме того, для настройки на осуществление связи с ресурсом или прикладной программой определенного типа, плагин протокольного процессора также обычно призван включать в себя некоторые сетевые политики для использования данного ресурса (или "приложения"). Таким образом, после входа и прохождения всех необходимых уровней аутентификации, предписанных плагином протокольного процессора, клиентская компьютерная система может обмениваться информацией с запрашиваемым ресурсом на серверной компьютерной системе. Например, клиент может посылать события мыши и клавиатуры, которые затем пересылаются на соответствующий ресурс. Ресурс обрабатывает эти события и возвращает результаты обработки на клиент для локального отображения.

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

Другая проблема состоит в том, что весь Интернет-трафик направляется через серверную компьютерную систему, к которой подключена клиентская компьютерная система. Таким образом, если клиент подключен к корпоративному брандмауэру с использованием VPN и клиент запрашивает внешний новостной веб-сайт, новостной веб-сайт должен быть туннелирован через корпоративный брандмауэр прежде, чем направиться на клиентскую компьютерную систему. Еще одна проблема состоит в том, что VPN/RAS может осуществлять только проверку и фильтрацию пакетов, что обычно затруднительно на сложных протоколах или протоколах, предусматривающих потоковую проверку.

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

Таким образом, например, разработчик, реализующий соединения уровня приложений, может писать один плагин протокольного процессора, который использует протокол удаленного компьютера ("RDP"), который реализует один вид политики доступа с использованием шлюзового сервера; и, одновременно, писать другой плагин протокольного процессора, который использует протокол блока серверных сообщений ("SMB"), который реализует другие политики доступа на шлюзовом сервере. Кроме того, чтобы иметь потенциально уникальные политики доступа, каждый протокольный процессор также может иметь отдельные, уникальные скрипты, которые используются для других разнообразных инструментов администрирования и диагностики. Таким образом, зачастую может быть так, что разработчикам все время приходится с нуля создавать разные плагины, сетевые политики и соответствующие диагностические скрипты для каждого отдельного ресурса, представляющего интерес, который они хотят сделать доступным через брандмауэр.

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

Сущность изобретения

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

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

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

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

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

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

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

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

фиг.1B - общая схема системы, показанной на фиг.1A, в которой клиентская компьютерная система осуществляет связь с указанным ресурсом, в соответствии с реализацией настоящего изобретения; и

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

Подробное описание

Реализации настоящего изобретения относятся к системам, способам и компьютерным программным продуктам, призванным обеспечивать стандартную платформу, на которой разработчики могут легко обеспечивать связь между клиентскими/серверными приложениями. В частности, одна реализация настоящего изобретения включает в себя защищенную инфраструктуру связи (обмена), способную эффективно и безопасно соединять удаленный клиент и любой серверный ресурс на уровне приложений стека связи через брандмауэр. Инфраструктура связи может стимулировать соединение с учетом различных пригодных политик доступа, которые не обязательно должны быть независимо разработаны разработчиком. Кроме того, инфраструктура связи может дополнительно включать в себя некоторые карантинные функции, которые можно использовать, чтобы гарантировать, что клиент не сможет подключиться к ресурсу без установки минимальной программной “заплатки”.

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

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

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

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

Существуют примеры конкретных типов API, которые можно использовать в соответствии с общими принципами изобретения. Функции этих API рассмотрены с общей ссылкой на следующие чертежи. Например, на фиг.1A схематически показана реализация настоящего изобретения, в которой клиентская компьютерная система 100 пытается осуществить связь с конкретным ресурсом (например, приложением или соответствующим компонентом), находящимся “позади” брандмауэра на шлюзовом сервере 150. Для осуществления этой связи клиент 100 и шлюзовой сервер 150 будут, в конце концов, использовать аналогично сконфигурированный плагин протокольного процессора (например, 115a-b), который содержит набор API (например, вышеупомянутых), которые могут осуществлять связь и/или работать в контексте инфраструктуры связи 107 (т.е. "встроенных" в инфраструктуру).

Как объяснено более подробно в нижеследующем описании изобретения и формуле изобретения, инфраструктура 107 связи представляет собой структуру данных, богатую особенностями (например, включающую в себя четыре вышеупомянутых API), которая включает в себя различные компоненты, модули обработки, инструменты, индексы и т.п. В общем случае инфраструктура 107 связи (обмена) построена и/или сконфигурирована так, чтобы разработчик мог легко конструировать плагин протокольного процессора (например, 115a-b, 117), который взаимодействует с инфраструктурой 107 связи, и использовать особенности и политики, обеспеченные в инфраструктуре 107 связи, без необходимости отдельно разрабатывать или прописывать эти особенности и политики.

В частности, на фиг.1A показано, что инфраструктура 107 связи содержит стек 113 связи, который используется для взаимодействия между физической границей в сети 135 и различными программными компонентами на шлюзовом сервере 150. В общем случае, шлюзовой сервер 150 может содержать любой терминальный сетевой сервер, например интернет-сервер, защищенный брандмауэром, для большой организации, через который проходит весь входящий и исходящий Интернет-трафик. Например, сотрудник организации, желающий подключиться из дома к ресурсу в офисе, будет подключен через шлюзовой сервер 150 прежде, чем получит доступ к ресурсу позади брандмауэра.

При этом инфраструктура 107 связи может включать в себя любое количество компонентов и модулей для взаимодействия с ресурсами позади брандмауэра, которые можно использовать для доступа к конкретному ресурсу. Например, на фиг.1A показано, что реализация стека 113 связи (обмена) на инфраструктуре 107 связи содержит уровень 105b защищенного протокола передачи гипертекстовых файлов ("HTTPS"), а также транспортный уровень 110b с возможностью встраивания. В одной реализации транспортный уровень 110b с возможностью встраивания (а также уровень 110a) представляет собой уровень 110b вызова удаленной процедуры ("RPC"), в связи с чем уровень 105a-b и уровень 110a-b можно совместно рассматривать как "HTTPS/RPC". При таком использовании уровень HTTPS 105b дешифрует или декодирует любое шифрование/кодирование SSL или TLS, тогда как транспортный уровень 110b с возможностью встраивания распаковывает любую упаковку (например, RPC), выполненную на соответствующем транспортном уровне 110a с возможностью встраивания на клиенте 100.

Конечно, в стек 113 связи может быть включено любое количество дополнительных или альтернативных уровней, причем стек связи может входить в состав или коррелировать с традиционной 7-уровневой моделью взаимодействия открытых систем ("OSI"). Например, хотя в этой реализации уровень HTTPS/транспортный уровень с возможностью встраивания 105b/110b для простоты показан в виде минимального набора уровней, аспекты изобретения этим не ограничиваются. В других реализациях, например, разработчик может обходиться без HTTPS и использовать другой механизм подключения на основании решения SSL и/или протокола управления передачей ("TCP"), которое также предусматривает соединение уровней приложений клиента и шлюза через защищенное соединение. Поэтому HTTPS/встраиваемый транспорт, в частности набор HTTPS/RPC, является единственно возможным способом обеспечения элементов решения с проходом брандмауэра.

Заметим, что одно преимущество HTTPS и транспортного уровня с возможностью встраивания, например, RPC состоит в том, что некоторые протоколы, например RPC, обратно совместимы с более ранними версиями HTTP (например, HTTP версии 1.0). Таким образом, разработчик, использующий набор HTTPS/RPC, может обнаружить, что этот элемент решения с проходом брандмауэра можно легче применять на более старых серверах или на серверах, которые ограничивают типы трафика более общим типом трафика HTTP.

В любом случае на фиг.1A также показано, что сквозной интерфейс приложения ("сквозной API") 160 располагается в верхней части связки HTTPS/встраиваемого транспорта стека 113. Сквозной API 160 может содержать любое количество компонентов и модулей (например, один или несколько вышеупомянутых "базовых API", "конфигурационных API", "API политик" и/или "API состояния и контроля среды выполнения") для создания надлежащего соединения между клиентом 100 и соответствующим плагином протокольного процессора и для гарантированной реализации надлежащих сетевых политик в соединении. Например, сквозной API 160 включает в себя компонент 170 политик доступа (например, "API политик") и компонент 175 инструментов администрирования ((например, "конфигурационный API" и/или "API состояния и контроля среды выполнения"), которые можно рассматривать как ряд функций, которые более подробно описаны ниже. Однако в более общем случае сквозной API 160 может действовать как прокладка между связками HTTPS/встраиваемого транспорта в стеке связи 113 и одним или несколькими плагинами протокольного процессора, которые используются для связи с конкретным ресурсом.

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

Однако разработчику нужно также обеспечить соответствующий плагин протокольного процессора для клиента, чтобы клиент мог осуществлять связь с запрашиваемым ресурсом. Таким образом, например, на фиг.1A также показано, что клиент 100 имеет стек 103 связи (обмена), который также включает в себя уровень HTTPS 105a и транспортный уровень 110a с возможностью встраивания. В общем случае транспортный уровень 110a с возможностью встраивания используется для упаковки всех исходящих сообщений (например, 130) в соответствии с надлежащим протоколом (например, протоколом RPC при использовании уровня RPC), тогда как уровень HTTPS 105a используется для шифрования или кодирования исходящих сообщений, например посредством шифрования или кодирования SSL или TLS. Плагин 115а протокольного процессора располагается в верхней части связки HTTPS/встраиваемого транспорта клиента.

В общем случае плагин 115а протокольного процессора содержит любые интерфейсы (например, "базовый API" и/или "конфигурационный API"), ресурсы или компоненты, необходимые для создания туннеля подключения и соответствующего канала (внутри туннеля) с нужным ресурсом на шлюзовом сервере 150. Соответственно, плагин 115а протокольного процессора, по меньшей мере, комплементарен с плагином 115b протокольного процессора. Например, на фиг.1A показано, что плагин 115а протокольного процессора относится к определенному типу (т.е. "типу A"), соответствующему типу ресурса (т.е. ресурса 120a), который клиент 100 использует локально, и таким образом способен осуществлять связь с комплементарным плагином протокольного процессора, использующим те же вызовы, кодирование и т.д.

Таким образом, на фиг.1A дополнительно показано, что стек 103 связи включает в себя ресурс 120a (например, прикладную программу, компонент или даже другой API). Например, клиент открывает приложение базы данных в локальной компьютерной системе, которое синхронизировано с рабочей версией базы данных, находящейся позади брандмауэра на шлюзовом сервере 150. Хотя ресурс 120a в ряде случаев может представлять собой полную версию приложения, ресурс 120a также может быть просто программным компонентом приложения, который позволяет определенным образом отображать данные, передаваемые в потоковом режиме со шлюзового сервера 150. Поэтому компоненты, например ресурс 120a, обеспечивают в этом случае минимальный набор ресурсов, которые позволяют клиенту 100 напрямую подключаться к ресурсу на шлюзовом сервере 150.

Например, на фиг.1A показано, что клиент 100 запрашивает 130 соединение с ресурсом 120b, используя ресурс 120a. Для этого клиент 100 инициирует стек связи 103, имеющий соответствующий плагин протокольного процессора (т.е. 115a), который относится к надлежащему типу (т.е. "типу A") для нужного ресурса (т.е. ресурса 120a). Затем клиент 100 отправляет сообщение 130 запроса подключения на шлюзовой сервер 150 через стек 103 связи. В частности, плагин 115а протокольного процессора снабжает исходящее сообщение 130 информацией аутентификации (содержащей, например, имя пользователя и пароль, идентификацию клиента, цифровые подписи), конкретным вызовом ресурса 120b и любой информацией сетевых политик, которая может потребоваться на сквозном API 160. Затем плагин 115а протокольного процессора отправляет сообщение 130, подлежащее упаковке на транспортном уровне 110a с возможностью встраивания, шифрованию на уровне HTTPS 105 (т.е. через TLS или SSL), с последующей отправкой по сети 135.

Затем инфраструктура 107 связи принимает сообщение 130 и осуществляет функции первоначальной распаковки и дешифрования. Например, уровень HTTPS 105b дешифрует любое кодирование SSL или TLS, и транспортный уровень 110b с возможностью встраивания распаковывает сообщение из любого соответствующего кодирования (например, кодирования RPC). Затем сквозной API 160 может проверить информацию аутентификации в сообщении 130 и определить, авторизован ли клиент 100 на запрашиваемое подключение на основании весьма дифференцированных политик доступа. В одной реализации, в частности, дифференцирование политик доступа основано на разделении политик доступа на по меньшей мере два независимых набора: политику доступа к сети для определения, авторизован ли клиент создавать сетевое соединение с сервером 150 в первую очередь; и политику доступа к ресурсам для определения, авторизован ли клиент иметь канал подключения с запрашиваемым ресурсом помимо того, что ему разрешено создавать туннель подключения. Такая авторизация политики доступа (к сети или ресурсу) может быть конфигурирована в зависимости от любых параметров, которые желает рассматривать администратор сети и/или приложения/ресурса, например от аутентификации посредством традиционных имен пользователя и паролей, идентификации "здоровья клиента" и т.п. (например, карантинная особенность, более подробно рассмотренная ниже).

Некоторые примеры правил, составляющих политику доступа к сети, включают в себя ограничения в отношении того, входит ли пользователь на клиенте 100 в авторизованную группу, связанную с запрашиваемым ресурсом. Набор политик доступа к сети также можно сконфигурировать на ограничение подключения к некоторым серверам только группой в отделе маркетинга, ограничение количества общих туннелей подключения к серверу некоторым максимальным количеством, ограничение доступа к определенному серверу (временем суток, определенными пользователями и т.д.) позади брандмауэра, или даже ограничение доступа только конкретными портами на данном сервере. Другие политики доступа к сети можно сконфигурировать на требование, чтобы клиент предъявил "интеллектуальную карту" до подключения к серверу 150.

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

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

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

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

В альтернативных реализациях инфраструктура 107 связи просто отключает любые особенности, которые не поддерживаются клиентом 100, благодаря чему клиент не пытается установить связь в некоторый момент с такими неподдерживаемыми особенностями. Например, разработчик ресурса 120b может иметь обеспеченные ряд особенностей или обновлений особенности для этого ресурса, к которому клиент 100 (или клиенты, принадлежащие классу пользователей, указанному политикой доступа к ресурсам) не должен осуществлять доступ (или использовать его), пока клиент 100 также имеет минимальный набор соответствующих ресурсов, особенностей или обновлений особенности. Эти ресурсы, особенности и/или соответствующие обновления особенности могут быть функциональными, но также могут быть связаны с системой безопасности, из-за чего может быть важно, чтобы разработчик их применял. Соответственно, в одной реализации инфраструктура 107 связи может просто поместить запрашиваемое подключение в карантин, пока такие согласования особенностей с клиентом 100 не будут удостоверены или аутентифицированы.

Затем клиент 100 обрабатывает сообщение 140, например, обнаруживая, какие особенности клиент 100 выполняет или способен выполнять, и подготавливает ответ. Например, на фиг.1B показано, что клиент 100 в ответ посылает сообщение 145, указывающее любые подобные идентифицированные поддерживаемые особенности. Затем сквозной API 160 может сравнить ответ 145 с информацией в компоненте 170 политик доступа для определения, пригодны ли эти поддерживаемые клиентом особенности для сетевого соединения или для установления канала к запрашиваемому ресурсу, или нужны ли другие особенности (или другие версии тех же особенностей). В одной реализации, если нужны другие особенности (т.е. клиент 100 недостаточно обновлен или не имеет определенных необходимых особенностей) для подключения к шлюзовому серверу 150, то сквозной API 160 может просто разорвать соединение, может послать сообщение об ошибке или может послать сообщение, указывающее место в сети, где клиент 100 может загрузить особенность. В других реализациях, например вышеупомянутых, инфраструктура 107 связи просто отключает те особенности шлюзового сервера 150, которые клиент 100 также не поддерживает.

Если сообщение 145 указывает надлежащий набор особенностей (когда такие особенности могут понадобиться), и клиент 100 авторизован на доступ к запрашиваемому ресурсу на стороне сервера, то сквозной API 160 может начать передавать соединение на соответствующий плагин протокольного процессора для ресурса. Например, сквозной API 160 может сначала посмотреть на "тип" запрашиваемого ресурса для определения, требует ли ресурс 120b особого плагина протокольного процессора, или является ли ресурс 120b частью более широкого класса ресурсов. В частности, на фиг.1B показано, что плагин протокольного процессора 115b связан, по меньшей мере, с ресурсами 120b и 123, а плагин 117 протокольного процессора, который является процессором "типа B", связан, по меньшей мере, с ресурсами 125 и 127. В общем случае этот этап определения соответствующего плагина протокольного процессора можно осуществлять путем просмотра системного реестра, в котором каждый плагин протокольного процессора прописывается при установке.

В любом случае, на фиг.1B показано, что сквозной API 160 идентифицирует плагин 115b протокольного процессора, который является процессором "типа A" и связан с запрашиваемым ресурсом 120b. Затем сквозной API 160 осуществляет передачу управления каналом между клиентом 100 и плагином 115b протокольного процессора. Поэтому плагин 115a протокольного процессора на клиенте 100 и плагин 115b протокольного процессора на шлюзовом сервере 150 теперь соединены на соответствующих уровнях приложений стеков 103 и 113, соответственно, и, таким образом, могут обмениваться данными (например, 155) по каналу соединения. В частности, инфраструктура 107 связи допускает один или несколько каналов в туннеле для подключения к конкретному ресурсу с использованием соответствующих плагинов протокольного процессора клиента и шлюзового сервера, а не сетевого соединения, обрабатываемого сетевыми уровнями соответствующих стеков связи.

Управление этими каналами через туннель подключения может позволять клиенту 100 идентифицировать любые дополнительные ресурсы, к которым можно осуществить доступ, а также создавать дополнительные каналы с первоначально запрашиваемым ресурсом (т.е. ресурсом 120b). Например, клиент 100 может создать несколько каналов в туннеле подключения с одним и тем же ресурсом посредством инфраструктуры 107 связи, а также запросить у сквозного API 160 обеспечение дополнительных каналов (а также других туннелей и соответствующих одного или нескольких других каналов) к другим ресурсам, связанным с тем же плагином протокольного процессора, который связан с ресурсом 120b, например ресурсу 123. В некоторых реализациях клиент 100 также может просить инфраструктуру 107 связи идентифицировать другой плагин протокольного процессора (например, 117), пригодный для связи с другим ресурсом (например, 125). В любом случае управление соединением осуществляется, по меньшей мере отчасти, посредством компонента 170 политик доступа и/или компонента 175 инструментов администрирования (или "компонента 175 инструментов").

В общем случае компонент 175 инструментов может содержать любое количество интерфейсов (например, один или несколько из "базового API", "конфигурационного API", "API политик" и/или "API состояния и контроля среды выполнения"). Компонент 175 инструментов администрирования также может содержать любые скрипты (сценарии), таблицы данных и соответствующие функции, доступ к которым может осуществлять, например, администратор шлюзового сервера 150. Например, администратор сети, желающий повлиять на сетевую политику для определенного плагина протокольного процессора или проанализировать количества соединений через инфраструктуру 107 связи, может открыть пользовательский интерфейс (не показан), обеспеченный компонентом 175 инструментов.

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

Разработчик плагина протокольного процессора также может обращаться к этим инструментам в компоненте 175. В частности, разработчик может прописать в плагине протокольного процессора возможность доступа и задать различные сетевые политики по умолчанию для использования с плагином протокольного процессора. Например, разработчик плагина протокольного процессора может сконструировать плагин протокольного процессора для взаимодействия с другим интерфейсом в инструментах 175 администрирования и задать минимальный ресурс или требования к особенностям. Соответственно, на фиг.1A-1B показан ряд компонентов, инструментов и схем, которые можно использовать в контексте инфраструктуры 107 связи и которые способны обеспечивать избирательный, безопасный и измеримый доступ к ресурсам в настройке брандмауэра.

Реализации настоящего изобретения также можно описать применительно к способам, содержащим один или несколько этапов для достижения конкретного результата. Например, на фиг.2 показана блок-схема этапов способов со стороны клиента 100 и шлюзового сервера 150 для создания подключения (например, канала) к конкретному ресурсу через брандмауэр. Этапы, показанные на фиг.2, описаны ниже со ссылками на фиг.1A-1B.

В частности, на фиг.2 показано, что способ со стороны клиента 100 содержит этап 200, на котором посылают запрос подключения на шлюзовой сервер. Этап 200 включает в себя этап, на котором посылают запрос соединения на шлюзовой сервер, в котором запрос идентифицирует серверный ресурс для соединения с соответствующим клиентским ресурсом. Например, клиент 100 конкретизирует стек 103 связи плагином 115а протокольного процессора для доступа к ресурсу 120b. Затем клиент 100 подготавливает и отправляет сообщение 130, которое включает в себя информацию аутентификации, а также запрос доступа к ресурсу 120b, и отправляет сообщение 130 на шлюзовой сервер 150.

Кроме того, на фиг.2 показано, что способ со стороны шлюзового сервера 150 содержит этап 210, на котором принимают клиентский запрос ресурса. Этап 210 включает в себя этап, на котором принимают клиентский запрос на клиентское соединение, в котором клиентский запрос идентифицирует ресурс, к которому клиент хотел бы подключиться. Например, шлюзовой сервер 150 принимает сообщение 130. Затем шлюзовой сервер 150 декодирует сообщение 130 на уровне HTTPS 105b, распаковывает упаковку любого другого протокола на транспортном уровне с возможностью встраивания 110b и оценивает любую содержащуюся в нем информацию аутентификации. Если информация аутентификации неверна, например, конфликтует с политикой доступа к сети, шлюзовой сервер 150 может просто отменить соединение. Альтернативно, если информация аутентификации верна, например, удовлетворяет минимальному стандарту (например, надлежащему имени пользователя и паролю) подключения через брандмауэр, шлюзовой сервер 150 может подвергнуть соединение карантину, пока определенный набор особенностей - также в соответствии с политикой доступа к сети или ресурсам - не будет идентифицирован из клиента 100.

Таким образом, например, на фиг.2 также показано, что способ со стороны шлюзового сервера 150 содержит этап 220, на котором подвергают соединение карантину. Этап 220 включает в себя этап, на котором подвергают карантину соединение с клиентом для определения, установлен ли на клиенте минимальный набор из одной или нескольких особенностей. Например, на фиг.1A показано, что, приняв сообщение 130, инфраструктура 107 связи отправляет одно или несколько ответных сообщений 140. Вместо того, чтобы с необходимостью устанавливать соединения в этот момент, ответное сообщение 140 запрашивает дополнительную информацию для идентификации поддерживаемых особенностей на клиенте 100, например, версии плагина 115а протокольного процессора, особенностей соединения, которые клиент 100 и сервер 150 взаимно поддерживают, или любых других компонентов 120a ресурса (или соответствующих особенностей, обновлений особенности и т.д.), которые, в конце концов, можно использовать при соединении.

Соответственно, на фиг.2 показано, что способ со стороны клиента 100 содержит этап 230, на котором принимают запрос для минимального набора особенностей. Этап 230 включает в себя этап, на котором принимают от шлюзового сервера запрос на минимальный набор из одной или нескольких особенностей, поддерживаемых клиентом для ресурса. Например, клиент 100 принимает сообщение 140 на стеке 103 связи и обрабатывает сообщение 140 на плагине 115а протокольного процессора, например, путем выполнения любых скриптов или проверки любой информации системного реестра на предмет запрашиваемых особенностей, включая любые другие ресурсы или ресурсные особенности, запрашиваемые сервером 150. В частности, плагин 115а протокольного процессора идентифицирует свою собственную информацию особенностей, или информацию особенностей для ресурса 120a, или информацию особенностей для другого программного компонента или ресурса (не показан) на клиенте 100.

Кроме того, на фиг.2 показано, что способ со стороны клиента 100 содержит этап 240, на котором посылают ответ особенностей на шлюзовой сервер. Этап 240 включает в себя этап, на котором посылают ответ поддерживаемых особенностей на шлюзовой сервер, причем ответ поддерживаемых особенностей указывает особенности, поддерживаемые клиентом. Например, на фиг.1B показано, что клиент 100 отправляет ответное сообщение 145, которое указывает набор из одной или нескольких особенностей, которые поддерживаются клиентом 100, например присутствие запрашиваемой версии программного обеспечения.

На фиг.2 также показано, что способ со стороны шлюзового сервера 150 содержит этап 250, на котором идентифицируют соответствующий плагин протокольного процессора. Этап 250 включает в себя этап, на котором идентифицируют плагин протокольного процессора на основании типа ресурса для идентифицированного ресурса. Например, сквозной API 160 идентифицирует, что плагин 115b протокольного процессора является плагином "типа A", и является тем же типом, который выявлен для протокольного процесса 115a на клиенте 100, и связан с запрашиваемым ресурсом 120b на шлюзовом сервере 150.

На фиг.2 дополнительно показано, что способ со стороны шлюзового сервера 150 содержит этап 260, на котором перенаправляют подключение на плагин протокольного процессора. Этап 260 включает в себя этап, на котором перенаправляют соединение с клиентом на идентифицированный плагин протокольного процессора. Например, согласно фиг.1B, после того, как сквозной API 160 идентифицирует, что плагин 115b протокольного процессора пригоден и что информация, предоставленная клиентом 100, соответствует конкретной политике доступа к ресурсам, сквозной API 160 передает управление запрашиваемым подключением плагину 115b протокольного процессора. В общем случае этот процесс может предусматривать установление туннеля - и одного или нескольких каналов в туннеле - между протокольным процессором 115a на клиенте 100 и плагином протокольного процессора 115b на шлюзовом сервере 150. Затем плагин 115а протокольного процессора на клиенте 100 и плагин 115b протокольного процессора на шлюзовом сервере могут напрямую осуществлять связь на уровне приложений сетевых стеков 103 и 113 через этот туннель и соответствующие один или несколько каналов.

Таким образом, на фиг.2 также показано, что способ со стороны клиента 100 содержит этап 270, на котором подключаются к плагину протокольного процессора на шлюзовом сервере. Этап 270 включает в себя этап, на котором подключаются к уровню приложений стека связи на шлюзовом сервере, в результате чего клиентский ресурс передает данные посредством плагина протокольного процессора, связанного с серверным ресурсом. Например, теперь, когда плагины 115а-b протокольного процессора сообщаются непосредственно через брандмауэр и поскольку соединение передается в соответствии с сетевой политикой, только клиент 100 получает через брандмауэр доступ, достаточный для связи с ресурсом 120b. Таким образом, клиент 100 не имеет свободного доступа ко всем ресурсам позади брандмауэра. Тем не менее, как описано выше, клиент 100 может иметь возможность инициировать дополнительные каналы или соединения с одним и тем же ресурсом, с разными экземплярами ресурса или с другими ресурсами, которые клиенту 100 разрешено идентифицировать через инфраструктуру 107 связи.

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

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

Варианты осуществления настоящего изобретения могут содержать компьютер специального назначения или общего назначения, включающий в себя различное компьютерное оборудование, которое более подробно рассмотрено ниже. В частности, варианты осуществления в рамках настоящего изобретения также включают в себя компьютерно-считываемые носители для переноса или хранения компьютерно-выполняемых команд или структур данных. Такие компьютерно-считываемые носители могут представлять собой любые доступные носители, к которым может осуществлять доступ компьютер общего назначения или специального назначения. В порядке примера, но не ограничения, такие компьютерно-считываемые носители могут содержать ОЗУ, ПЗУ, ЭСППЗУ, CD-ROM или другой носитель в виде оптического диска, носитель в виде магнитного диска или другие магнитные запоминающие устройства, или любой другой носитель, который можно использовать для переноса или хранения нужного средства программного кода в форме компьютерно-выполняемых команд или структур данных, и к которому может осуществлять доступ компьютер общего назначения или специального назначения.

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

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

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

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

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

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

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

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

5. Способ по п.4, дополнительно содержащий этап, на котором передают управление другим каналом к идентифицированному плагину протокольного процессора с клиентом, делающим другой запрос на соединение.

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

7. Способ по п.6, в котором политика доступа содержит политику доступа к сети для определения, авторизован ли клиент на соединение с сервером, и политику доступа к ресурсам для определения, авторизован ли клиент создавать канал с запрашиваемым ресурсом посредством соединения с сервером.

8. Способ по п.6, в котором настройка политик доступа содержит указание, ограничивающее доступ клиента к ресурсу в течение суток, и в котором другой запрос на соединение не соответствует времени суток.

9. Способ по п.6, в котором настройка политик доступа содержит указание, ограничивающее доступ клиента к ресурсу конкретным портом сервера ресурсов позади брандмауэра, причем другой запрос на соединение запрашивает соединение с ресурсом на этом конкретном порте сервера ресурсов.

10. Способ по п.6, в котором настройка политик доступа является политикой доступа к сети, которая ограничивает количество туннелей соединения через брандмауэр на шлюзовом сервере, в результате чего другой запрос на соединение требует создания нового туннеля соединения сверх установленного предела.

11. Способ по п.6, в котором настройка политик доступа требует, чтобы клиент делал клиентский запрос с помощью интеллектуальной карты, при этом другой запрос на соединение указывает, что клиент не имеет интеллектуальной карты.

12. Способ по п.6, в котором настройка политик доступа ограничивает доступ к одному и тому же ресурсу для разрешенного класса пользователей, при этом другой запрос на соединение исходит от другого пользователя, который не является членом этого разрешенного класса пользователей.

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

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

15. Инфраструктура связи по п.14, в которой сетевые политики содержат политики доступа к сети для определения, авторизован ли клиент на соединение с шлюзовым сервером, и политику доступа к ресурсу для определения, авторизован ли клиент создавать канал с запрашиваемым ресурсом посредством установленного соединения.

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

17. Инфраструктура связи по п.14, в которой соединения между клиентами и ресурсами осуществляются на уровне приложений стека связи.