Обеспечение безопасности диалогов компонента Service Broker
Механизм обеспечения безопасности диалогов позволяет защитить конкретный диалог за счет шифрования, удаленной проверки подлинности и удаленной авторизации. Если используется обеспечение безопасности диалога, компонент Service Broker шифрует все сообщения, отправляемые за пределы экземпляра SQL Server. Диалоги компонента Service Broker используют по умолчанию обеспечение безопасности диалога.
Основы обеспечения безопасности диалогов
Механизм обеспечения безопасности диалогов компонента Service Broker позволяет приложению использовать в конкретном диалоге проверку подлинности, авторизацию или шифрование. По умолчанию эта функция активирована для всех диалогов. Начиная диалог, можно явно разрешить продолжение диалога без обеспечения его безопасности, указав в инструкции BEGIN DIALOG CONVERSATION предложение ENCRYPTION = OFF. Тем не менее, при существовании привязки удаленной службы, с которой начат диалог, безопасность диалога обеспечивается даже в случае наличия предложения ENCRYPTION = OFF.
Если используется обеспечение безопасности диалога, компонент Service Broker шифрует все сообщения, отправляемые за пределы экземпляра SQL Server. Сообщения, не покидающие экземпляр SQL Server, никогда не шифруются. При обеспечении безопасности диалога доступ к соответствующим сертификатам нужен только базам данных, являющимся узлами службы-инициатора и целевой службы. Это означает, что экземпляр, выполняющий пересылку сообщений, вполне может не поддерживать возможность дешифрования пересылаемых сообщений.
Компонент Service Broker поддерживает два типа обеспечения безопасности диалога: полное и анонимное. Если используется обеспечение безопасности диалога, компонент Service Broker выполняет удаленную авторизацию для сопоставления удаленной стороны диалога с локальным пользователем.
Передаваемые по сети сообщения шифруются при обоих типах обеспечения безопасности диалога. Однако права в целевой базе данных и стратегии шифрования сообщений при двух этих подходах незначительно различаются.
И при полном, и при анонимном обеспечении безопасности диалога текст сообщения шифруется с использованием симметричного ключа сеанса, создаваемого для указанного диалога. С применением закрытого ключа и сертификата, предоставленных механизму обеспечения безопасности диалога, шифруются только эти ключи. Компонент Service Broker также выполняет проверку целостности сообщений, чтобы обнаружить повреждение или фальсификацию сообщения.
SQL Server создает для диалога, использующего обеспечение безопасности, ключ сеанса. Чтобы защитить ключ сеанса во время его хранения в базе данных, компонент Service Broker шифрует его с применением главного ключа базы данных. Если главный ключ базы данных недоступен, сообщения в диалоге остаются в transmission_status с ошибкой, до тех пор пока этот ключ не будет создан или не истечет время ожидания диалога. Таким образом, обе базы данных, принимающие участие в диалоге, должны содержать главные ключи, даже если эти базы данных относятся к одному экземпляру SQL Server. Если инициирующая база данных не содержит главный ключ, диалог будет прерван. Если главного ключа нет в целевой базе данных, сообщения остаются в очереди передаваемых сообщений базы данных, инициировавшей диалог. Причина, по которой эти сообщения не могут быть доставлены, будет отражена в последней ошибке передачи. В этом случае воспользуйтесь параметром ENCRYPTION = OFF для создания незашифрованного диалога или создайте главный ключ базы данных с помощью следующей команды.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'
Для удобства работы компонент Service Broker поддерживает продолжение выполнения защищенных диалогов, не выходящих за пределы одной базы данных, независимо от того, есть ли в ней главный ключ. Во время диалога две разных базы данных можно переместить на другие экземпляры SQL Server, однако диалог, ограниченный одной базой данных, всегда остается в ее логических пределах. Это делает возможным его продолжение.
Полное обеспечение безопасности
Механизм полного обеспечения безопасности помогает предотвратить отправление сообщений ненадежной базе данных инициирующей службой и получение сообщений от ненадежной базы данных целевой службой. При полном обеспечении безопасности диалога компонент Service Broker шифрует переданные по сети сообщения.
Механизм полного обеспечения безопасности диалога выполняет идентификацию и службы-инициатора, и целевой службы. Этот механизм требует, чтобы служба-инициатор доверяла целевой службе и наоборот. Например, служба заказа компонентов у поставщика может требовать, чтобы приложение заказа компонентов доверяло службе поставщика, а служба поставщика доверяла приложению заказа компонентов.
Администраторы баз данных формируют доверие между службами путем обмена сертификатами, содержащими открытые ключи. При полном обеспечении безопасности диалога каждая сторона диалога имеет закрытый ключ локального пользователя и открытый ключ удаленного пользователя. База данных, являющаяся узлом службы-инициатора, содержит привязку удаленной службы. Привязка удаленной службы определяет локального пользователя, который владеет сертификатом, соответствующим закрытому ключу в удаленной базе данных. Таким образом, операции от имени службы, инициировавшей диалог, выполняются в целевой базе данных в контексте соответствующего пользователя.
В целевой базе данных содержатся данные пользователя. Этот пользователь владеет сертификатом, соответствующим закрытому ключу, который принадлежит владельцу службы-инициатора. Таким образом, операции от имени целевой службы выполняются в базе данных службы-инициатора в контексте владельца службы-инициатора.
При полном обеспечении безопасности диалога каждая его сторона создает ключ сеанса. Первое сообщение, отправляемое в каждом направлении, содержит ключ сеанса, зашифрованный с использованием ключа обмена ключами; более подробно это описано в разделе Сертификаты и компонент Service Broker.
Анонимное обеспечение безопасности
Механизм анонимного обеспечения безопасности диалога помогает предотвращать отправление сообщений ненадежной базе данных инициирующей службой. При анонимном обеспечении безопасности диалога компонент Service Broker шифрует переданные по сети сообщения.
Механизм анонимного обеспечения безопасности диалога идентифицирует целевую службу для службы-инициатора, но не идентифицирует службу-инициатор для целевой службы.
Примером может служить сценарий, в котором приложение, отправляющее данные о рабочих заданиях, должно гарантировать доставку этих данных правильному адресату, в то время как целевая база данных может не предоставлять службе-инициатору никаких специальных привилегий. В этом случае база данных, обслуживающая службу-инициатор, может содержать привязку удаленной службы к целевой службе.
Так как целевая служба не может проверить идентификационные данные службы-инициатора, операции от имени последней выполняются в целевой базе данных в контексте фиксированной роли public. Целевая база данных не получает никаких данных о пользователе, инициировавшем диалог, и в целевой базе данных вполне может отсутствовать сертификат этого пользователя.
При анонимном обеспечении безопасности диалога обе его стороны используют ключ сеанса, созданный базой данных службы-инициатора. Целевая база данных не возвращает ключ сеанса базе данных службы-инициатора.
Контексты обеспечения безопасности диалогов
Удаленная авторизация компонента Service Broker контролирует удаленный доступ к отдельной службе. Этот механизм определяет контекст безопасности, в котором сообщения, принимаемые экземпляром SQL Server, отправляются службе.
Компонент Service Broker всегда выполняет удаленную авторизацию для защищенных диалогов, которые не выполняются полностью в одном экземпляре SQL Server. Контекст безопасности, используемый компонентом Service Broker для удаленной авторизации, определяется типом обеспечения безопасности диалога.
Если диалог ограничен экземпляром SQL Server, компонент Service Broker не выполняет удаленную авторизацию даже в том случае, если механизм удаленной авторизации сконфигурирован. В ограниченном экземпляром диалоге участники безопасности SQL Server уже доступны экземпляру SQL Server, поэтому нет никакой необходимости выполнять удаленную авторизацию с целью определения правильного контекста безопасности для операций компонента Service Broker. Тем не менее, как было сказано выше в данном разделе, компонент Service Broker создает ключ сеанса, чтобы диалог можно было продолжить в случае, если в ходе диалога одна из баз данных будет перемещена в другой экземпляр.
При анонимном обеспечении безопасности диалога соединение работает в целевой базе данных в контексте фиксированной роли public. В этом случае предопределенная роль базы данных public должна иметь разрешение на отправление сообщений службе. Другие разрешения, связанные с базой данных, этой роли не нужны.
При полном обеспечении безопасности диалога соединение работает на каждой стороне диалога с разрешениями пользователя, указанного в привязке удаленной службы. Например, если привязка с удаленной службой связывает имя службы InventoryService с пользователем InventoryServiceRemoteUser, экземпляр SQL Server помещает сообщения, адресованные приложению InventoryService, в очередь в контексте безопасности пользователя InventoryServiceRemoteUser.
Пользователь, владеющий закрытым ключом службы, обычно отличается от пользователя, для которого будет выполнена активация, это повышает надежность защиты. Пользователю, владеющему закрытым ключом, нужно разрешение только на добавление сообщений в очередь, то есть разрешение SEND, соответствующее службе, которая использует очередь. В отличие от этого варианта, пользователь, для которого будет выполнена активация, имеет разрешения, которые необходимы для выполнения запрошенной работы и отправления ответа. В предыдущем примере пользователь InventoryServiceRemoteUser не нуждается в разрешении на выполнение запросов таблицы материально-технических запасов (inventory) или на отправление ответного сообщения. Ему нужно лишь разрешение на помещение сообщений в очередь, которую использует служба InventoryService. Активация хранимой процедуры выполняется в другом сеансе с учетными данными очереди. Разделять какие-либо учетные данные между сеансом, помещающим сообщение в очередь, и сеансом, обрабатывающим сообщение, не требуется.
Создание безопасного диалога
Когда компонент Service Broker устанавливает диалог между двумя базами данных, инициирующая служба должна установить пользовательский контекст в целевой базе данных, чтобы можно было направлять сообщения в целевую очередь. Пользовательский контекст определяет, имеет ли инициирующая служба разрешение на начало диалога с целевой базой данных.
Легче всего это осуществить, создав сертификат и привязку удаленной службы. Дополнительные сведения о создании сертификата см. в разделе Инструкция CREATE CERTIFICATE (Transact-SQL). Дополнительные сведения о создании привязки удаленной службы см. в разделе CREATE REMOTE SERVICE BINDING (Transact-SQL).
Альтернативой созданию сертификата и привязки удаленной службы является использование безопасности SQL Server для установки надежной связи между двумя базами данных. Владелец инициирующей службы выполняет олицетворение пользователя в целевой службе. Для этого может потребоваться установка свойства базы данных TRUSTWORTHY в инициирующей базе данных в значение ON и предоставление разрешения AUTHENTICATE пользователю в целевой базе данных. Дополнительные сведения см. в разделе Расширение олицетворения базы данных с помощью инструкции EXECUTE AS.
.gif "Примечание") Примечание |
|---|
Если контекст безопасности установлен неправильно, отправляемые в диалог сообщения будут оставаться в очереди sys.transmission_queue в инициирующей службе со следующим сообщением об ошибке в столбце transmission_status: Серверу-участнику «%.*ls» не удается получить доступ к базе данных «%.*ls» под текущим контекстом безопасности. |
См. также