Безопасность диалогового окна Service Broker

Область применения: SQL Server Управляемый экземпляр SQL Azure

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

Основы безопасности диалогов

Защита диалогов Service Broker позволяет вашему приложению использовать проверку подлинности, авторизацию или шифрование для отдельной беседы (диалога). По умолчанию все диалоговые беседы используют безопасность диалогов. При запуске диалогового окна можно явно разрешить диалогу продолжать работу без безопасности диалогов, включив ENCRYPTION = OFF предложение инструкции BEGIN DIALOG CONVERSATION . Однако если для службы существует привязка удаленной службы, предназначенная для беседы, диалоговое окно использует безопасность даже в том случае ENCRYPTION = OFF.

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

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

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

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

SQL Server создает сеансовый ключ для беседы, в которой используется защита диалога. Чтобы защитить ключ сеанса во время его хранения в базе данных, Service Broker шифрует ключ сеанса с главным ключом для базы данных. Если главный ключ базы данных недоступен, сообщения для беседы остаются в transmission_status ошибке до тех пор, пока не будет создан главный ключ базы данных или пока не истекает время ожидания беседы. Поэтому обе базы данных, участвующие в беседе, должны содержать главные ключи, даже если базы данных размещаются в одном экземпляре. Если инициируемая база данных не содержит мастер-ключ, диалог окончен ошибкой. Если целевая база данных не содержит главный ключ, сообщения остаются в очереди передачи инициируемой базы данных. Последняя ошибка передачи для этих сообщений указывает причину, по которой сообщения не могут быть доставлены. Чтобы создать незашифрованное диалоговое окно, используйте 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 использует для удаленной авторизации.

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

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

Для беседы, использующего полную безопасность, подключение на каждой стороне беседы действует с разрешениями пользователя, указанного в привязке удаленной службы. Например, если привязка удаленной службы связывает имя InventoryService службы с пользователем InventoryServiceRemoteUser, SQL Server использует контекст безопасности для InventoryServiceRemoteUser отправки сообщений приложения InventoryService в очередь для конечной службы.

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

Создание безопасного диалогового окна

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

Самый гибкий способ сделать это — создать сертификат и привязку удаленной службы. Дополнительные сведения о создании сертификата см. в разделе CREATE CERTIFICATE. Дополнительные сведения о создании привязки удаленной службы см. в статье CREATE REMOTE SERVICE BINDING.

Связанный контент

• Класс событий Broker:Corrupted Message
• Класс событий Audit Broker Login
• Связи удаленного сервиса
• Определение типа безопасности диалогового окна