RU2439692C2 - Управляемое политиками делегирование учетных данных для единой регистрации в сети и защищенного доступа к сетевым ресурсам - Google Patents

Abstract

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

Description

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

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

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

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

Тем не менее, современные системы для делегирования учетных данных от клиента серверному приложению для доступа к возможностям серверного приложения не являются в достаточной степени защищенными, т.е. имеется недостаточная защита при делегировании/передаче учетных данных пользователя от клиента серверу, оставляя учетные данные пользователя уязвимыми для определенных форм атаки. В настоящее время, например, вызывающее приложение на стороне сервера или клиента иногда имеет доступ к учетным данным пользователя в формате открытого текста, и тем самым учетные данные пользователя в некоторой степени ненадежны. Помимо этого в настоящее время нет управляемого политиками способа контролировать и разграничивать делегирование учетных данных пользователя от сервера клиенту, который применяется к любому типу учетных данных пользователя, т.е. имя пользователя/пароль, PIN-код смарт-карты, одноразовые секретные коды (OTP) и т.д.

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

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

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

Другие признаки настоящего изобретения описываются ниже.

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

Далее описывается управляемое политиками делегирование учетных данных для единой регистрации в сети и защищенного доступа к ресурсам в сетевом окружении со ссылкой на прилагаемые чертежи, на которых:

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

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

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

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

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

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

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

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

Подробное описание изобретения

Обзор

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

Cred SSP согласно изобретению - это новый "поставщик услуг по обеспечению безопасности", иногда также упоминаемый как "поставщик услуг безопасности", который может быть доступен посредством существующей инфраструктуры интерфейса поставщика услуг по обеспечению безопасности (SSPI) операционной системы клиента. Cred SSP согласно изобретению дает возможность приложению делегировать учетные данные пользователя от клиента, к примеру, посредством программного обеспечения SSP на стороне клиента, в целевой сервер, к примеру, посредством программного обеспечения SSP на стороне сервера. В примерном неограничивающем варианте осуществления Cred SSP согласно изобретению может быть включен в Terminal Server. Тем не менее, Cred SSP согласно изобретению может быть использован посредством других приложений и может быть доступен любому внутреннему или стороннему приложению с помощью SSPI применимой операционной системы.

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

Microsoft Terminal Server (TS), например, является примером клиент-серверного продукта, который иногда требует от пользователя предоставлять учетные данные регистрации в сети на терминале/клиенте и делегировать эти учетные данные регистрации в сети на сервер, чтобы авторизовать обслуживание приложений и приемы работы "в стиле рабочего стола" продуктов операционной системы Microsoft Windows в терминале/клиенте. TS, в общем, может рассматриваться как включающий в себя три основные части: многопользовательский базовый сервер, протокол Remote Desktop Protocol (RDP), который позволяет отправлять интерфейс рабочего стола Windows в терминалы посредством сервера, и клиентское программное обеспечение, которое приводится в исполнение на каждом терминале. В одном неограничивающем варианте осуществления изобретения протоколы поставщика услуг по обеспечению безопасности учетных данных согласно изобретению могут быть реализованы в связи с программным обеспечением терминального сервера.

Дополнительный контекст

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

Дополнительный контекст и исходные данные для следующих терминов, в общем, известных специалистам в данной области техники, таким образом, предоставляются в данном документе: Kerberos, Windows NT Local Area Network (LAN) Manager (NTLM), простой и защищенный механизм согласования интерфейса прикладного программирования для служб безопасности (GSSAPI) (вкратце SPNEGO), локальный центр обеспечения безопасности (LSA), интерфейс поставщика услуг по обеспечению безопасности (SSPI) и протокол защищенных сокетов (SSL), а также примерная инфраструктура аутентификации в Windows.

Kerberos

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

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

Windows NT LAN Manager (NTLM)

Альтернатива Kerberos, NTLM - это протокол аутентификации, используемый в различных реализациях сетевых протоколов Microsoft, поддерживаемых посредством поставщика услуг по обеспечению безопасности NTLM (NTLMSSP). Первоначально используясь для аутентификации и согласования защищенной связи в режиме распределенного вычислительного окружения (DCE)/удаленного вызова процедур (RPC), NTLM также используется в качестве интегрированного механизма единой регистрации в сети.

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

Защищенный канал (Schannel)

Защищенный канал, также известный как Schannel, является поставщиком услуг по обеспечению безопасности (SSP), содержащим набор протоколов безопасности, которые обеспечивают аутентификацию идентификационных данных и улучшенную защиту связи за счет шифрования. Schannel главным образом используется для Интернет-приложений, которые требуют улучшенной безопасности для обмена данными по протоколу передачи гипертекста (HTTP). Серверная аутентификация, когда сервер предоставляет подтверждение своих учетных данных клиенту, требуется посредством протоколов безопасности Schannel. Таким образом, протоколы Schannel используют учетные данные Schannel, которые могут быть использованы для того, чтобы аутентифицировать серверы и, необязательно, клиенты. Клиентская аутентификация может быть запрошена сервером в любое время. Учетными данными Schannel являются сертификаты X.509. Информация открытых и закрытых ключей из сертификатов используется для того, чтобы аутентифицировать сервер и, необязательно, клиент. Эти ключи также используются для того, чтобы обеспечивать целостность сообщений, пока клиент и сервер обмениваются информацией, требуемой для того, чтобы формировать и обмениваться сеансовыми ключами. Schannel реализует протоколы SSL и TLS, подробнее описываемые ниже.

Простой и защищенный механизм согласования GSSAPI (SPNEGO)

SPNEGO - это стандартный псевдомеханизм интерфейса прикладного программирования для служб безопасности (GSSAPI) для равноправных узлов, чтобы определять то, какие механизмы GSSAPI совместно используются, выбирать один и затем устанавливать контекст безопасности с помощью совместно используемого механизма GSSAPI. Спецификацию SPNEGO можно найти в Рабочих предложениях Инженерной группы по развитию Интернета RFC 2478, озаглавленных "GSS-API Negotiation Mechanism", датированных декабрем 1998 года.

Применение SPNEGO можно найти, например, в расширении "HTTP Negotiate", которое является расширением аутентификации, которое первоначально реализовано в приложении обозревателя Internet Explorer и которое предоставило возможности единой регистрации в сети, известные как интегрированная аутентификация Windows. Согласуемые вспомогательные механизмы SPNEGO включают в себя NTLM и Kerberos, оба из которых могут использовать Active Directory.

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

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

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

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

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

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

Локальный центр обеспечения безопасности (LSA)

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

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

Интерфейс поставщика услуг по обеспечению безопасности (SSPI)

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

Учетными данными, используемыми для этого аутентифицированного соединения, могут быть: (1) учетные данные для существующей аутентифицированной линии связи между клиентской и серверной машинами (к примеру, существующего назначения диска), (2) учетные данные для пользовательской учетной записи клиента, если сервер распознает SID, ассоциативно связанный с этой учетной записью; это подразумевает, что клиент и сервер должны доверять одному домену и что пользовательская учетная запись принадлежит этому домену, (3) необработанные учетные данные (к примеру, имя и пароль) для локальной учетной записи на сервере, если они совпадают с именем и паролем пользователя клиента (в этом случае пользовательская учетная запись клиента и учетная запись, которую он использует на сервере, различаются), и (4) учетные данные (к примеру, имя и пароль), которые явно передаются пользователем. SSPI работает посредством запрашивания вызывающих приложений (клиентских и серверных процессов) передавать блоки данных туда и обратно до тех пор, пока базовый поставщик услуг безопасности не будет удовлетворен.

После загрузки динамически подключаемой библиотеки (DLL) системы безопасности и выбора пакета (другой термин для поставщика услуг безопасности, такого как NTLM, Kerberos и т.д.) клиент инициализирует локальный или клиентский SSPI и извлекает первый набор данных, чтобы отправить на сервер. Между тем, сервер инициализировал серверный SSPI, и после приема первого набора данных сервер предоставляет его в серверный SSPI, который обрабатывает первый набор данных, получая в результате второй набор данных. В ответ сервер выполняет проверку на соответствие результирующего второго набора данных, и если данные больше 0, сервер отправляет второй набор данных клиенту, который, в свою очередь, предоставляет их в клиентский SSPI. Далее клиентский SSPI либо запрашивает, чтобы третий набор данных был отправлен на сервер, либо сообщает приложению, что аутентификация завершена. Это продолжается до тех пор, пока клиентский и серверный SSPI не будут удовлетворены данными, принятыми друг от друга.

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

Протоколы защищенных сокетов (SSL) и безопасности транспортного уровня (TLS)

Протокол защищенных сокетов (SSL) и протокол безопасности транспортного уровня (TLS), его преемник, оба реализованные посредством Schannel, являются криптографическими протоколами, которые предоставляют защищенную связь по Интернету. Имеются незначительные различия между SSL 3.0 и TLS 1.0, но протокол остается практически таким же. Термин "SSL" иногда ссылается на оба протокола, если контекстом не внесены пояснения.

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

Примерная неограничивающая инфраструктура аутентификации в Windows

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

В одной реализации Windows поддерживает три основных SSP, описанных выше: Kerberos, оклик/отзыв NTLM и протоколы безопасности Schannel. Хотя Kerberos является способом аутентификации по умолчанию в Windows 2000, другие способы могут быть использованы посредством интерфейса поставщика услуг по обеспечению безопасности, или SSPI. Помимо этого, например, Windows может использовать следующие сетевые SSP для того, чтобы предоставлять услуги аутентификации с помощью цифровых сертификатов: распределенная аутентификация паролей (DPA) - протокол аутентификации по Интернету, расширяемый протокол аутентификации (EAP) - расширение к протоколу "точка-точка" (PPP) и основанным на открытом ключе протоколам, включая SSL, TLS и технологию закрытой связи.

Управляемое политиками делегирование учетных данных для единой регистрации в сети и защищенного доступа к сетевым ресурсам

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

Фиг.1 - это блок-схема, иллюстрирующая общее представление архитектуры Cred SSP согласно изобретению, которая предоставляет защищенное делегирование учетных данных от клиента серверу, без раскрытия учетных данных в формате открытого текста вызывающему приложению(ям). В одном варианте осуществления Cred SSP реализован как набор из двух пакетов: пакета CredSSP на стороне клиента (или приложений) Client-side_CredSSP и пакета CredSSP на стороне LSA LSA_CredSSP для устройства D, для клиентского вычислительного устройства или серверного вычислительного устройства.

Пакет на стороне клиента Client-side_CredSSP - это программное обеспечение поставщика услуг по обеспечению безопасности на стороне клиента, которое открыто для вызывающих приложений интерфейса I1 поставщика услуг по обеспечению безопасности на стороне клиента Client-side_CredSSP, предоставляет согласование Schannel и предоставляет функциональность пакета Schannel, а также обмен данными с пакетом на стороне LSA LSA_CredSSP через интерфейс I2 на стороне LSA CredSSP. В соответствии с изобретением обработка согласования и функциональности Schannel в пользовательском процессе способствует более быстрым операциям encryptMessage и decryptMessage в сравнении с производительностью посредством LSA.

В соответствии с изобретением LSA-пакет LSA_CredSSP предоставляет согласование SPNEGO, шифрование/расшифровку учетных данных и переадресацию учетных данных, а также выполняет проверку политик на соответствие политикам, заданным в вышеописанном наборе политик согласно изобретению.

Как упоминалось и как показано на фиг.2A и 2B в примерном неограничивающем варианте осуществления, изобретение реализовано в связи с клиентом 200 терминального сервера, делегирующим учетные данные терминальному серверу 250.

Как показано на фиг.2A, реализация клиента 200 терминального сервера взаимодействует с процессом 225 LSA-сервера посредством библиотеки 205 защищенной аутентификации, использующей локальный вызов 215 процедуры (LPC), который включает в себя передачу данных через границу 220 процесса. Функции 210 приводятся в исполнение в библиотеке 205 защищенной аутентификации и могут включать в себя функцию CredSSP Initialize Security Context (CredSSP.ISC), которая включает в себя функцию Secure Sockets Layer/Initialize Security Context (SSL.ISC) и функцию Secure Sockets Layer/Encrypt Message (SSL.EM). Функции 230 приводятся в исполнение в процессе 225 LSA-сервера и могут включать в себя функцию CredSSP Initialize Security Context (CredSSP.ISC), которая включает в себя функцию SPNEGO/Initialize Security Context (SPNEGO.ISC) и функцию SPNEGO/Encrypt Message (SPNEGO.EM).

Как показано на фиг.2B, реализация терминального сервера 250 взаимодействует с процессом 275 LSA-сервера посредством библиотеки 255 защищенной аутентификации, использующей локальный вызов 265 процедуры (LPC), который включает в себя пересечение границы 270 процесса. Функции 260 приводятся в исполнение в процессе 205 защищенной аутентификации и могут включать в себя функцию CredSSP Accept Security Context (CredSSP.ASC), которая включает в себя функцию Secure Sockets Layer/Accept Security Context (SSL.ASC) и функцию Secure Sockets Layer/Decrypt Message (SSL.DM). Функции 280 приводятся в исполнение в процессе 275 LSA-сервера и могут включать в себя функцию CredSSP Accept Security Context (CredSSP.ASC), которая включает в себя функцию SPNEGO/Accept Security Context (SPNEGO.ASC) и функцию SPNEGO/Decrypt Message (SPNEGO.DM).

Примерный неограничивающий протокол, используемый посредством Cred SSP согласно изобретению, примерно показан на блок-схеме последовательности операций способа по фиг.3. На этапе 300 начальное подтверждение связи SSL/TLS выполняется между клиентом и сервером. На этапе 305 осуществляется согласование SPNEGO, чтобы выбрать механизм аутентификации (к примеру, Kerberos, или NTLM, или другой подходящий механизм согласования, понимаемый посредством клиента и сервера). На этапах 310 и 315, используя согласованный механизм аутентификации, сервер аутентифицируется для клиента, а клиент аутентифицируется для сервера.

Если на этапе 320 надлежащая аутентификация достигнута между клиентом и сервером согласно этапам 310 и/или 315, то совместно используемый секрет (к примеру, совместно используемый ключ) устанавливается для всего остального трафика на этапе 330. Тем не менее, преимущественно, если на этапе 320 надлежащая аутентификация не установлена между клиентом и сервером, то сеанс не создается на этапе 325, и значительные вычислительные затраты и трафик исключаются. Ранее, к примеру, в прошлых реализациях терминального сервера аутентификация выполнялась с большими затратами, поскольку попытка выполнить аутентификацию начиналась после того, как создан сеанс. В отличие от этого, в соответствии с протоколом Cred SSP согласно изобретению, сеанс между клиентом и сервером не создается до тех пор, пока аутентификация клиента и сервера согласно выбранному механизму аутентификации SPNEGO не осуществлена.

Таким образом, предполагая на этапе 320, что соответствующая аутентификация выполнена с помощью выбранного механизма аутентификации, совместно используемый ключ устанавливается для всего последующего трафика между клиентом и сервером на этапе 330. Тем не менее, только то, что возник порог аутентификации, еще не означает, что сервер обязательно является доверенным посредством клиента. Таким образом, в этой точке, хотя сеанс создан между сервером и клиентом, клиент может считаться доверенным и недоверенным. Соответственно, используя групповую политику 335 по изобретению, LSA Cred SSP на клиентской машине выполняет проверку на соответствие политике на этапе 340, чтобы определить то, следует ли делегировать учетные данные пользователя. Если серверу не следует доверять, то на этапе 345 учетные данные не делегируются. Если взаимосвязь с сервером не является доверенной вследствие проверки на соответствие политике на этапе 340, то на этапе 350 открытый ключ сервера аутентифицируется, чтобы помочь исключить атаки "с человеком в середине", когда объект мошеннического программного обеспечения моделирует режим работы и открытый ключ сервера. Таким образом, если открытый ключ сервера не аутентифицирован на этапе 350, то учетные данные не делегируются согласно риску атаки "с человеком в середине" на этапе 355. На этапе 360 формат шифрования применяется к учетным данным, которые понимаются только посредством доверенной подсистемы LSA. На этапе 465 зашифрованные учетные данные делегируются от клиента серверу. Посредством понимания формата шифрования только посредством доверенной подсистемы LSA, преимущественно, вызывающие приложения на клиенте и сервере в LSA и Cred SSP согласно изобретению не имеют несанкционированного доступа к учетным данным в формате открытого текста.

Фиг.4 иллюстрирует более подробную реализацию протокола делегирования учетных данных по изобретению как примерную неограничивающую блок-схему последовательности операций способа. На этапе 400 подтверждение связи SSL/TLS выполняется между клиентом и сервером, и ключ шифрования SSL/TLS K_SSL/TLS устанавливается между клиентом и сервером. K_pub - это открытый ключ в сертификате сервера. Далее на этапе 410 по зашифрованному каналу SSL/TLS взаимная аутентификация клиента и сервера выполняется с помощью пакета SPNEGO. В зависимости от взаимосвязи доверия клиент/сервер пакет Kerberos или NTLM согласуется и используется. Следует отметить, что в случае если согласован NTLM, сервер подтверждает знание пароля клиенту, но другие серверы в этом домене имеют доступ к паролю. K_spnego - это либо субсеансовый ключ Kerberos, либо сеансовый ключ NTLM, совместно используемый обеими сторонами при завершении обмена SPNEGO.

На этапе 420 LSA Cred SSP на клиентской машине выполняет проверку на соответствие политике на основе имени участника-службы (SPN) сервера, информации аутентификации сервера (PKI/KRB в сравнении с NTLM) и настроек групповой политики, чтобы определять то, следует ли делегировать учетные данные пользователя серверу. Затем на этапе 430 проверяется, что K_SSL/TLS принадлежит целевому серверу, а не "человеку в середине", посредством выполнения следующего примерного обмена для аутентификации:

C->S: { { K_pub}K_spnego} K_SSL/TLS,

S -> C: { { K_pub + 1 }K_spnego } K_SSL/TLS.

Следует отметить, что K_SSL/TLS используется для того, чтобы шифровать всю клиент-серверную связь. Более того, этот этап аутентификации сервера может быть основан на Kerberos или NTLM, если нет основанного на PKI доверия. Защищенная привязка SSL/TLS-аутентифицированного канала к Kerberos-аутентификации, как описано, может выполняться поверх SSL/TLS. Говоря по-иному, изобретение может защищенно использовать основанные на Kerberos учетные данные, чтобы аутентифицировать SSL/TLS-согласованный главный/сеансовый ключ, что может быть особенно полезно, если нет доверия PKI между SSL/TLS-клиентом и SSL/TLS-сервером.

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

C->S: { { Password }K_spnego} K_SSL/TLS.

Как описано выше, например, на этапах 340 (и групповой политики 335) и 420 по фиг.3 и 4 соответственно, политики используются для того, чтобы контролировать и разграничивать делегирование учетных данных клиента в соответствии с изобретением, чтобы подавлять широкий диапазон атак. Как упоминалось, LSA-пакет согласно изобретению предоставляет SPNEGO-согласование, шифрование/расшифровку учетных данных и переадресацию учетных данных. LSA-пакет согласно изобретению также выполняет проверку политик на соответствие политикам, заданным в соответствии с изобретением. Назначение настроек групповой политики согласно изобретению заключается в том, чтобы обеспечить то, что учетные данные не делегируются неавторизованному серверу, к примеру машине под административным управлением мошенника или подчиняющейся злоумышленнику. Следует отметить, что хотя доверие может существовать для того, чтобы упрощать аутентификацию между клиентом и сервером, к примеру, на основе аутентификации PKI, Kerberos или NTLM, это доверие не означает, что целевой сервер является доверенным с помощью учетных данных пользователя. Таким образом, изобретение включает в себя опрос политики, чтобы обеспечить то, что целевой сервер может быть доверенным с помощью делегированных учетных данных.

Фиг.5 - это примерная неограничивающая блок-схема архитектуры Cred SSP согласно изобретению, которая предоставляет защищенное делегирование учетных данных от клиента серверу, без раскрытия учетных данных в формате открытого текста вызывающему приложению(ям). Аналогично фиг.1, Cred SSP реализуется как набор из двух пакетов на клиенте C и сервере S: пакет на клиентской стороне и пакет на стороне LSA. На клиенте C это преобразуется в CredSSP на клиентской стороне и CredSSP на стороне LSA. На сервере S это преобразуется в CredSSP' на клиентской стороне и CredSSP' на стороне LSA. Фиг.5 иллюстрирует, что в соответствии с изобретением учетные данные пользователя в формате открытого текста никогда не сохраняются или доступны вызывающему приложению CA клиента 500, запрашивающему ARS серверного приложения, ресурса или службы сервера 510. Пунктирная линия, сегментирующая часть доверенной подсистемы LSA, показывает, что только часть доверенной подсистемы LSA имеет доступ к учетным данным пользователя в формате открытого текста, т.е. возможность расшифровывать/шифровать. Помимо этого фиг.5 иллюстрирует, что CredSSP на стороне LSA на клиентской машине опрашивает групповые политики GP по изобретению, как подробнее описано ниже.

В этом смысле настройки групповых политик, показанные ниже в таблице III, задают то, какие серверы являются доверенными с помощью учетных данных пользователя, причем каждая настройка является списком имен участников-служб (SPN); в одном варианте осуществления разрешены подстановочные знаки. Специалисты в области техники строкового распознавания могут принимать во внимание, что "подстановочные" означают символы, такие как '*', которые могут означать любой символ или строку, разрешенную в алфавите SPN. Таким образом, согласно изобретению Cred SSP (клиентская сторона) делегирует учетные данные пользователя только в том случае, если сервер аутентифицирован для клиента, и SPN сервер проходит проверку на соответствие политике, к примеру, как задано посредством настроек групповой политики (GP), показанных в таблице III ниже.

Настройки политик для делегирования учетных данных пользователя, заданные ниже в таблице III, разработаны таким образом, чтобы подавлять множество атак, в том числе, но не только, атаки, перечисленные в таблице I:

Таблица I Типы атак, которые подавляют настройки политик
1	Троян или вредоносная программа может быть запущена на клиентской машине, к примеру, в режиме ограниченного пользовательского доступа (LUA), не администрирования.
2	Настройки GP по умолчанию в сравнении с другими значениями GP, которые могут конфигурироваться администратором (включая ненадлежащее использование подстановочных знаков).
3	Заражение службы доменных имен (DNS). Когда клиент преобразует имя хоста, он может обмениваться данными с мошенническим сервером.
4	Атаки типа "отказ в обслуживании" на центр распределения ключей (KDC) Kerberos.

Решение, сделанное в отношении того, какие из политик, заданных в соответствии с изобретением (заданных примерным неограничивающим образом в таблице III ниже), применяются к данной ситуации, зависит от протокола аутентификации, согласованного между клиентом и сервером, как описано выше в связи с фиг.3-5, и типа учетных данных. Фиг.6 показывает три примерных типа учетных данных, на которых может основываться политика в соответствии с изобретением, включая свежие учетные данные, учетные данные по умолчанию и сохраненные учетные данные. Свежие учетные данные - это учетные данные, которые вводятся в реальном времени посредством пользовательского интерфейса учетных данных, такого как CredUI 610. Сохраненные учетные данные - это учетные данные, которые введены ранее как свежие учетные данные и которые сохранены для дополнительного повторного использования посредством менеджера учетных данных, такого как CredMan 600, к примеру, на ограниченный период времени. Сохраненные учетные данные считаются более слабыми с точки зрения безопасности, чем свежие учетные данные. Еще менее защищенными являются учетные данные по умолчанию, которые, как явствует из имени, являются учетными данными, которые предназначены для использования посредством LSA 620 в отсутствие других инструкций использовать другие учетные данные. Например, учетные данные по умолчанию могут включать в себя учетные данные, введенные во время регистрации в сети. Учетные данные по умолчанию могут быть достаточными при определенных случаях, которые не требуют повышенной безопасности, такие как учетные данные определенных веб-узлов. Помимо этого, хотя и менее защищенные, учетные данные по умолчанию имеют преимущество немедленной доступности для LSA 620. Таким образом, имеется три типа учетных данных, которые могут быть использованы в связи с запросом посредством клиента терминального сервера TSC, как показано на фиг.6. Таблица II демонстрирует три типа учетных данных, рассмотренных в этом примерном неограничивающем варианте осуществления: свежие, сохраненные и по умолчанию.

Таблица II Типы учетных данных
Свежие учетные данные	Учетные данные пользователя, собранные посредством пользовательского интерфейса, такого как CredUI, и переданные непосредственно в SSPI (к примеру, переданные в вызов AcquireCredentialsHandle).
Учетные данные по умолчанию	Учетные данные, которые первоначально предоставлены посредством пользователя, когда пользователь первый раз зарегистрировался в системе (доступны для SSP).
Сохраненные учетные данные	Учетные данные для конкретного целевого сервера, которые пользователь выбрал сохранить в менеджере учетных данных (к примеру, CredMan).

Как упоминалось выше, таблица III включает в себя примерный неограничивающий набор настроек групповой политики (GP) для контролирования/разграничения делегирования учетных данных пользователя посредством клиента серверу в соответствии с изобретением. Специалисты в области техники работы вычислительных сетей могут принимать во внимание, что Termsrv/* означает набор SPN, где служба - это Termsrv, а машиной-хостом, указанной после прямого слеша "/", может быть любой целевой сервер, совпадающий с подстановочным знаком *.

Таблица III Настройки групповой политики для контролирования/разграничения делегирования учетных данных пользователя
#	Настройка GP (список SPN)	Значение по умолчанию	Комментарии
1	AllowDefCredentials Значение: Пароль может быть передан перечисленным целям при аутентификации с помощью учетных данных по умолчанию.	NULL	Настройка по умолчанию: По умолчанию, делегирование учетных данных по умолчанию (введенных, когда пользователь первый раз регистрировался в системе) не разрешено на любой машине. Это означает, что вредоносные программы, запущенные на машине клиента (в режиме LUA mode), не смогут делегировать учетные данные по умолчанию посредством вызова в Cred SSP (вне зависимости от всех остальных фактов, т.е. схемы аутентификации), поскольку проверка на соответствие политике завершится отказом.
2	AllowSavedCredentials Значение: Пароль может быть передан перечисленным целям при аутентификации с помощью сохраненных учетных данных.	Termsrv/*	Настройка по умолчанию: Значение по умолчанию разрешает делегирование сохраненных учетных данных пользователя терминальной службе, запущенной на любой машине. Следует отметить, что это применимо к серверам, на которых пользователь ранее входил в систему и выбрал сохранить свои учетные данные в CredMan (Имя целевого сервера сохраняется вместе с учетными данными пользователя в CredMan).
3	AllowFreshCredentials Значение: Пароль может быть передан перечисленным целям при аутентификации с помощью свежих учетных данных.	Termsrv/*	Посредством сравнения с вышеуказанными настройками, в случае с AllowFreshCredentials отсутствует возможность у вредоносных программ, выполняющих скрытую регистрацию в системе (без первоначального запрашивания пользователя, при условии, что настройки политики AllowSavedCredentials и AllowDefCredentials не активированы).
4	DenyDefCredentials Значение: Пароль не может быть передан перечисленным целям при аутентификации с помощью учетных данных по умолчанию.	NULL	Эта настройка используется для того, чтобы дополнительно разграничить, каким серверам учетные данные по умолчанию пользователя могут делегироваться, и сама по себе не предоставляет возможности для того, чтобы воспользоваться. Однако администратор все еще должен проявлять осторожность при проектировании политики для учетных данных по умолчанию через комбинирование настроек DenyDefCredentials и AllowDefCredentials. Если AllowDefCredentials покрывает большой набор серверов, список исключений, выраженный через DenyDefCredentials, может не полностью покрывать все недоверенные серверы в данном окружении. Это может стать частичным несоответствием со временем, когда подключатся новые серверы. Дополнительно, вредоносная программа с административными привилегиями может удалить недоверенные серверы из списка DenyDefCredentials. Однако вредоносная программа с административными привилегиями является состоянием "игра окончена", поскольку есть ряд способов получить пароль пользователя в этом случае.
5	DenySavedCredentials Значение: Пароль не может быть передан перечисленным целям при аутентификации с помощью сохраненных учетных данных.	NULL	Эта настройка используется для того, чтобы дополнительно разграничить, каким серверам сохраненные учетные данные пользователя могут делегироваться, и сама по себе не предоставляет возможности для того, чтобы воспользоваться.
6	DenyFreshCredentials Значение: Пароль не может быть передан перечисленным целям при аутентификации с помощью свежих учетных данных.	NULL	Эта настройка используется для того, чтобы дополнительно разграничить, каким серверам свежие учетные данные пользователя могут делегироваться, и сама по себе не предоставляет возможности для того, чтобы воспользоваться.
7	AllowDefCredentialsWhenNTLMOnly Значение: Если единственным пакетом аутентификации является NTLM, и пользователь аутентифицируется с учетными данными по умолчанию, разрешает паролю быть переданным перечисленным целевым объектам.	NULL	По умолчанию эта настройка отключена, поскольку Kerberos и доверие на основе PKI предлагает более строгую методологию аутентификации, чем NTLM.
8	AllowSavedCredentialsWhenNTLMOnly Значение: Если единственным пакетом аутентификации является NTLM, и пользователь аутентифицируется с сохраненными учетными данными, разрешает паролю быть переданным перечисленным целевым объектам.	Termsrv/* (непри-соединенный), NULL (присое-диненный)	Чтобы справиться с внутренней слабостью протокола NTLM, делегирование учетных данных пользователя разрешено по умолчанию только для неприсоединенных к домену машин (в этом случае гарантированно серверная аутентификация выполняется посредством целевой автономной машины). По умолчанию, для случая присоединения к домену NTLM, сам по себе, не разрешен (серверная аутентификация основана на Kerberos или PKI).
9	AllowFreshCredentialsWhenNTLMOnly Значение: Если единственным пакетом аутентификации является NTLM, и пользователь аутентифицируется со свежими учетными данными, разрешает паролю быть переданным перечисленным целевым объектам.	Termsrv/*

Обобщая, решение Cred SSP согласно изобретению предоставляет более защищенное решение, чем ранее, посредством предоставления набора политик, которые могут быть использованы для того, чтобы контролировать и разграничивать делегирование учетных данных пользователя от клиента серверу. Как иллюстрирует примерный неограничивающий набор политик по таблице III, политики разрабатываются таким образом, чтобы реагировать на широкий диапазон атак, включая вредоносные программы, запущенные на машине клиента. Дополнительно, Cred SSP согласно изобретению включает в себя "защищенную по умолчанию" политику, которая является специальной конфигурацией через настройки политики, которая позволяет клиентской машине, по умолчанию, подавлять широкий диапазон атак. Более того, набор политик согласно изобретению применим к защите любого типа учетных данных пользователя, включая, но не только, имя пользователя/пароль, PIN-код смарт-карты, одноразовые секретные коды (OTP) и т.д. Cred SSP согласно изобретению предоставляет дополнительную защиту учетных данных пользователя, поскольку вызывающему приложению (Cred SSP API) на стороне сервера или клиента никогда не предоставляется доступ к учетным данным пользователя в формате открытого текста, потому что только доверенная подсистема LSA имеет доступ к учетным данным в формате открытого текста.

Примерные сетевые и распределенные окружения

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

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

Фиг.7A предоставляет схематичное представление примерного сетевого или распределенного вычислительного окружения. Распределенное вычислительное окружение содержит вычислительные объекты 10a, 10b и т.д. и вычислительные объекты или устройства 110a, 110b, 110c и т.д. Эти объекты могут содержать программы, способы, хранилища данных, программируемую логику и т.д. Объекты могут содержать части одинаковых или различных устройств, таких как PDA, аудио/видеоустройства, MP3-проигрыватели, персональные компьютеры и т.д. Каждый объект может обмениваться данными с другим объектом посредством сети 14 связи. Эта сеть может содержать другие вычислительные объекты и вычислительные устройства, которые предоставляют услуги системе по фиг.7A, и может представлять несколько соединенных сетей. В соответствии с аспектом изобретения каждый объект 10a, 10b и т.д. или 110a, 110b, 110c и т.д. может содержать приложение, которое может использовать API или другой объект, программное обеспечение, микропрограммное обеспечение и/или аппаратное обеспечение, подходящее для использования с системами и способами делегирования учетных данных от клиента серверу согласно изобретению.

Следует также принимать во внимание, что объект, такой как 110c, может размещаться на другом вычислительном устройстве 10a, 10b и т.д. или 110a, 110b и т.д. Таким образом, хотя изображенное физическое окружение может показывать подключенные устройства как компьютеры, эта иллюстрация является просто примерной, и альтернативно может быть изображено или описано физическое окружение, содержащее различные цифровые устройства, например PDA, телевизионные приемники, MP3-проигрыватели и т.д., программные объекты, такие как интерфейсы, COM-объекты и т.п.

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

В домашних сетевых окружениях предусмотрено, по меньшей мере, четыре различные по своей сути сетевые транспортные среды, каждая из которых может поддерживать уникальный протокол, к примеру сеть электроснабжения, среда передачи данных (беспроводная и проводная), среда передачи речи (к примеру, телефон) и мультимедийная среда. Большинство домашних управляющих устройств, таких как переключатели освещения и приборы, могут использовать сети электроснабжения для возможностей подключения. Услуги передачи данных могут поступать в дома по широкополосным каналам (к примеру, DSL-модем или кабельный модем) и быть доступными внутри дома с помощью возможностей беспроводного (к примеру, HomeRF или 802.11B) или проводного (к примеру, Home PNA, кабельная система категории 5, Ethernet, даже сеть электроснабжения) подключения. Речевой трафик может поступать в дома как проводной (к примеру, кабельная система категории 3) или беспроводной (к примеру, сотовые телефоны) и может распространяться в доме с помощью кабельной разводки категории 3. Мультимедийная среда, или другие графические данные, может поступать в дома через спутник либо через кабель и типично распространяется в домах с помощью коаксиального кабеля. IEEE 1394 и DVI также являются цифровыми межкомпонентными соединениями для кластеров мультимедийных устройств. Все эти и другие сетевые окружения могут появляться или уже появились, поскольку стандарты протоколов могут взаимодействовать между собой, чтобы формировать сеть, к примеру сеть интранет, которая может быть подключена к внешнему миру посредством глобальной вычислительной сети, такой как Интернет. Вкратце, имеется множество различных по своей сути источников для хранения и передачи данных, и, следовательно, по мере развития вычислительным устройствам потребуются способы совместного использования данных, таких как доступные или используемые данные, присущие программным объектам, к примеру, в ходе делегирования учетных данных от клиента серверу в соответствии с настоящим изобретением.

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

Таким образом, сетевая инфраструктура предоставляет множество сетевых топологий, таких как клиент/сервер, равноправная или гибридная архитектура. "Клиент" - это член класса или группы, который использует службы другого класса или группы, к которой он не относится. Таким образом, в вычислительных системах клиентом является процесс, т.е., упрощая, набор инструкций или задач, который запрашивает службу, предоставляемую другой программой. Клиентский процесс использует запрошенную службу без необходимости "знать" какие-либо подробности о работе другой программы или самой службы. В клиент/серверной архитектуре, в частности в сетевой системе, клиентом обычно является компьютер, который осуществляет доступ к общим сетевым ресурсам, предоставляемым другим компьютером, к примеру сервером. В иллюстрации на фиг.7A, в качестве примера, компьютеры 110a, 110b и т.д. могут считаться клиентами, а компьютеры 10a, 10b и т.д. могут считаться серверами, при этом серверы 10a, 10b и т.д. содержат данные, которые затем тиражируются на клиентских компьютерах 110a, 110b и т.д., хотя любой компьютер может считаться клиентом, сервером или и тем, и другим, в зависимости от обстоятельств. Любые из этих вычислительных устройств могут обрабатывать данные или запрашивать службы либо задачи, которые могут включать в себя делегирование учетных данных от клиента серверу согласно изобретению.

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

Клиенты и серверы обмениваются данными друг с другом, используя функциональность, предоставляемую уровнем протоколов. Например, протокол передачи гипертекста (HTTP) является стандартным протоколом, который используется в связи с всемирной паутиной (WWW) или "веб-сетью". Типично сетевой адрес компьютера, такой как адрес Интернет-протокола (IP), или другая ссылка, такая как унифицированный указатель информационного ресурса (URL), может быть использована, чтобы идентифицировать серверные или клиентские компьютеры друг для друга. Сетевой адрес может упоминаться как URL-адрес. Обмен данными может предоставляться по среде связи, к примеру клиенты и серверы могут быть соединены друг с другом посредством подключений по TCP/IP для высокоскоростной связи.

Таким образом, фиг.7A иллюстрирует примерное сетевое или распределенное окружение с серверами, обменивающимися данными с клиентскими компьютерами посредством сети/шины, в котором может быть использовано настоящее изобретение. Более подробно, ряд серверов 10a, 10b и т.д. соединяются по сети/шине 14 связи, которой может быть LAN, WAN, сеть интранет, Интернет и т.д., с рядом клиентов или удаленных вычислительных устройств 110a, 110b, 110c, 110d, 110e и т.д., таких как портативный компьютер, карманный компьютер, тонкий клиент, подключенный к сети прибор или другое устройство, такое как VCR, TV, микроволновая печь, осветительный прибор, нагревательный прибор и т.п., в соответствии с настоящим изобретением. Таким образом, предполагается, что настоящее изобретение может применяться к любому вычислительному устройству, при соединении с которым желательно делегировать учетные данные пользователей серверу.

В сетевом окружении, в котором сетью/шиной 14 связи является Интернет, например, серверы 10a, 10b и т.д. могут быть веб-серверами, с которыми клиенты 110a, 110b, 110c, 110d, 110e и т.д. обмениваются данными через любой из ряда известных протоколов, например HTTP. Серверы 10a, 10b и т.д. также могут выступать в качестве клиентов 110a, 110b, 110c, 110d, 110e и т.д. в соответствии с характеристикой распределенного вычислительного окружения.

Как упоминалось, связь может быть проводная, или беспроводная, или комбинация вышеозначенного, как требуется. Клиентские устройства 110a, 110b, 110c, 110d, 110e и т.д. могут обмениваться или не обмениваться данными по сети/шине 14 связи и могут иметь независимую связь, ассоциативно связанную с ними. Например, в случае TV или VCR может иметься или отсутствовать сетевой аспект в их управлении. Каждый клиентский компьютер 110a, 110b, 110c, 110d, 110e и т.д. и серверный компьютер 10a, 10b и т.д. может быть оснащен различными прикладными программными модулями или объектами 135a, 135b, 135c и т.д., а также подключениями или доступом к различным типам элементов или объектов хранения, в которых файлы или потоки данных могут быть сохранены или на которые части файлов или потоков данных могут быть загружены, переданы или перемещены. Любые из этих одного или более компьютеров 10a, 10b, 110a, 110b и т.д. могут отвечать за хранение и обновление базы 20 данных или другого элемента хранения, такого как база данных или память 20 для хранения данных, обработанных или сохраненных согласно изобретению. Таким образом, настоящее изобретение может быть использовано в вычислительном сетевом окружении, имеющем клиентские компьютеры 110a, 110b и т.д., которые могут осуществлять доступ и взаимодействовать с вычислительной сетью/шиной 14, и серверные компьютеры 10a, 10b и т.д., которые могут взаимодействовать с клиентскими компьютерами 110a, 110b и т.д. и другими аналогичными устройствами и базами 20 данных.

Примерное вычислительное устройство

Как упоминалось, изобретение применяется к любому устройству, на котором может быть желательным защитить первичное приложение от вмешательства со стороны вторичных приложений устройства. Поэтому необходимо понимать, что карманные, портативные и другие вычислительные устройства и вычислительные объекты любого типа рассматриваются для использования в связи с настоящим изобретением, т.е. в любом месте, где устройство может захотеть делегировать учетные данные серверу (к примеру, GSM-сеть через портативное устройство, такое как мобильный телефон). Соответственно, удаленный компьютер общего назначения, описанный ниже на фиг.7B, является всего одним примером, и настоящее изобретение может быть реализовано с помощью любого клиента, имеющего поддержку взаимодействия по сети/шине. Таким образом, настоящее изобретение может быть реализовано в окружении сетевых размещаемых служб, в которых содержится немного или минимум клиентских ресурсов, к примеру, в сетевом окружении, в котором клиентское устройство выступает просто как интерфейс для сети/шины, такой как объект, находящийся в приборе.

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

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

Со ссылкой на фиг.7B, примерное удаленное устройство для реализации изобретения включает в себя вычислительное устройство общего назначения в виде компьютера 110a. Компоненты компьютера 110a могут включать в себя, но не только, блок 120a обработки, системную память 130a и системную шину 121a, которая соединяет различные компоненты системы, включая системную память, с блоком 120a обработки. Системная шина 121a может быть любой из нескольких типов шинных структур, включающих в себя шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из множества шинных архитектур.

Компьютер 110а типично включает в себя множество машиночитаемых носителей. Машиночитаемыми носителями могут быть любые доступные носители, к которым можно осуществлять доступ посредством компьютера 110a. В качестве примеров, но не ограничения, машиночитаемые носители могут содержать компьютерные носители хранения и среду связи. Компьютерные носители хранения включают в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией хранения информации, такой как машиночитаемые инструкции, структуры данных, программные модули или другие данные. Компьютерные носители хранения включают в себя (но не только) память по технологии RAM, ROM, EEPROM, флэш-память или другой технологии памяти, CD-ROM, универсальные цифровые диски (DVD) или другие оптические диски, магнитные кассеты, магнитные ленты, магнитные диски или другие магнитные устройства хранения либо любой другой носитель, который может быть использован для того, чтобы хранить нужную информацию и к которому может осуществлять доступ компьютер 110a. Среда связи типично содержит машиночитаемые инструкции, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущая волна или другой механизм распространения, и включает в себя любой носитель для доставки информации.

Системная память 130a может включать в себя компьютерные носители хранения в виде энергозависимой и/или энергонезависимой памяти, такие как постоянное запоминающее устройство (ROM) и оперативное запоминающее устройство (RAM). Базовая система ввода-вывода (BIOS), содержащая базовые подпрограммы, которые помогают передавать информацию между элементами в компьютере 110a, к примеру, в ходе загрузки, может быть сохранена в памяти 130a. Память 130a также типично содержит данные и/или программные модули, которые немедленно доступны и/или являются выполняемыми в данный момент блоком 120a обработки. В качестве примера, но не ограничения, память 130a также может включать в себя операционную систему, прикладные программы, другие программные модули и программные данные.

Компьютер 110a также может включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители хранения. Например, компьютер 110a может включать в себя накопитель на жестких дисках, который считывает или записывает на несъемные энергонезависимые магнитные носители, накопитель на магнитных дисках, который считывает с или записывает на съемный энергонезависимый магнитный диск, и/или накопитель на оптических дисках, который считывает с или записывает на съемный энергонезависимый оптический диск, такой как CD-ROM или другой оптический носитель. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители хранения, которые могут быть использованы в примерном операционном окружении, включают в себя, но не только, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, цифровую видеоленту, твердотельное RAM, твердотельное ROM и т.п. Накопитель на жестких дисках типично подключен к системной шине 121a через интерфейс несъемной памяти, такой как интерфейс, а накопитель на магнитных дисках и накопитель на оптических дисках типично подключены к системной шине 121a через интерфейс съемной памяти, такой как интерфейс.

Пользователь может вводить команды и информацию в компьютер 110a посредством устройств ввода, например клавиатуры и указательного устройства, обычно называемого мышью, шарового манипулятора или сенсорной панели. Другие устройства ввода могут включать в себя микрофон, джойстик, игровой планшет, спутниковую антенну, сканер и т.п. Эти и другие устройства ввода часто подключены к блоку 120a обработки через пользовательский ввод 140a и ассоциативно связанный интерфейс, который подключен к системной шине 121a, но может быть подключен через другой интерфейс и шинные структуры, такие как параллельный порт, игровой порт или универсальная последовательная шина (USB). Графическая подсистема также может быть подключена к системной шине 121a. Монитор или другой тип дисплейного устройства также подключен к системной шине 121a через такой интерфейс, как интерфейс 150a вывода, который, в свою очередь, может обмениваться данными с видеопамятью. Помимо монитора, компьютеры также могут включать в себя другие периферийные устройства вывода, например динамики и принтер, которые могут быть подключены через интерфейс 150a вывода.

Компьютер 110a может работать в сетевом или распределенном окружении, использующем логические соединения с одним или более удаленных компьютеров, таких как удаленный компьютер 170a, который, в свою очередь, может иметь возможности, такие как мультимедийные возможности, отличные от устройства 110a. Удаленным компьютером 170a может быть персональный компьютер, сервер, маршрутизатор, сетевой PC, одноранговое устройство или другой общий сетевой узел либо другое удаленное устройство потребления или передачи мультимедиа и может включать в себя любые или все элементы, описанные выше относительно компьютера 110a. Логические соединения, показанные на фиг.7B, включают в себя сеть 171a, такую как локальная сеть или глобальная сеть, но также могут включать в себя другие сети/шины. Такие сетевые окружения широко распространены в домах, офисах, корпоративных вычислительных сетях, сетях интранет и в Интернете.

При использовании в сетевом окружении LAN, компьютер 110a подключен к LAN 171a посредством сетевого интерфейса или адаптера. При использовании в сетевом окружении WAN, компьютер 110a типично включает сетевой компонент (сетевую карту, модем и т.д.) или другое средство для установления связи по WAN, такой как Интернет. Средство подключения к сети, которое может быть внутренним или внешним, может подключаться к системной шине 121a по пользовательскому интерфейсу 140a ввода или с использованием другого подходящего механизма. В сетевом окружении программные модули, показанные относительно компьютера 110a, или их части могут быть сохранены на удаленном запоминающем устройстве. Следует принимать во внимание, что показанные и описанные сетевые соединения являются типичными, и другие средства установления линии связи между компьютерами могут быть использованы.

Примерные распределенные вычислительные инфраструктуры или архитектуры

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

Например, платформа управляемого кода MICROSOFT®, т.е. .NET, включает в себя серверы, блочно-наращиваемые услуги, такие как веб-ориентированное хранение данных и загружаемое программное обеспечение устройств. Вообще говоря, платформа .NET предоставляет (1) возможность всему диапазону вычислительных устройств работать совместно и иметь пользовательскую информацию автоматически обновляемой и синхронизируемой на всех из них, (2) расширенные интерактивные возможности для веб-страниц с поддержкой все большего применения XML вместо HTML, (3) онлайновые услуги, которые содержат персонифицированный доступ и доставку продуктов и услуг пользователю из центрального отправного пункта для управления различными приложениями, таких как, к примеру, электронная почта, или программного обеспечения, такого как Office .NET, (4) централизованное хранение данных, которое повышает эффективность и простоту доступа к информации, а также синхронизации информации между пользователями и устройствами, (5) возможность интегрировать различные среды связи, такие как электронная почта, факсы и телефоны, (6) для разработчиков, возможность создавать многократно используемые модули, тем самым повышая производительность и снижая число ошибок программирования, и (7) также множество других признаков межплатформенной и межъязыковой интеграции.

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

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

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

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

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

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

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

Claims (19)

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

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

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

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

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

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

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

8. Способ по п.7, в котором выполнение проверки политики выполняется посредством локального центра обеспечения безопасности (LSA), а доверенная подсистема является доверенной подсистемой LSA.

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

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

11. Способ по п.1, в котором начальное подтверждение связи - это подтверждение связи согласно протоколу защищенных сокетов (SSL) или безопасности транспортного уровня (TLS).

12. Способ по п.1, в котором при упомянутом согласовании выполняют согласование с помощью простого и защищенного механизма согласования интерфейса (GSSAPI) прикладного программирования для служб безопасности (SPNEGO).

13. Способ по п.1, в котором выбранный пакет аутентификации - это любое из Kerberos или NT Local Area Network (LAN) Manager (NTLM).

14. Способ по п.1, в котором упомянутым совместно используемым секретом является совместно используемый сеансовый ключ.

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

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

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

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

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

Images