Обеспечение согласованного прохода брандмауэра, имеющего информацию о приложении

Обеспечение согласованного прохода брандмауэра, имеющего информацию о приложении

Иллюстрации

Показать все

Реферат

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

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

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

В одном примере брандмауэра клиентская компьютерная система может организовывать туннель через брандмауэр от сетевого уровня на клиентской компьютерной системе к соответствующему сетевому уровню на серверной компьютерной системе с использованием виртуальной частной сети ("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 показа