Статья
04/01/2012

Сертификаты для безопасности диалога

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

Поиск сертификата для диалога

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

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

Чтобы выбрать сертификат, компонент Service Broker ищет сертификат, владельцем которого является пользователь, заданный в привязке, с последней датой истечения срока сертификата. Компонент Service Broker не рассматривает сертификаты, которые еще недействительны, срок действия которых истек или не обладающие отметкой о том, что они доступны для начала двустороннего диалога. Дополнительные сведения о сертификатах см. в разделе Инструкция CREATE CERTIFICATE (Transact-SQL).

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

Удаленная авторизация и безопасность двустороннего диалога

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

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

Шифруя заголовок закрытым ключом для локального пользователя, компонент Service Broker задает вопрос: «Доверяет ли удаленная база данных локальной базе данных?» Удаленная база данных может расшифровать заголовок, только если содержит соответствующий открытый ключ. При шифровании заголовка открытым ключом для пользователя в удаленной базе данных задается вопрос: «Доверяет ли локальная база данных удаленной базе данных?» Удаленная база данных может расшифровать заголовок, только если содержит соответствующий закрытый ключ. В целях безопасности и эффективности компонент Service Broker задает оба вопроса одновременно. Однако сообщение структурировано таким образом, что получатель, чтобы правильно ответить на сообщение, должен иметь возможность утвердительно ответить на оба вопроса.

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

Примечание
Устанавливайте сертификаты, полученные только из доверенных источников. Не распространяйте закрытые ключи.

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

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

В первое сообщение, оправляемое каждым из участников диалога, компонент Service Broker включает следующие заголовки:

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

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

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