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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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