Segurança da caixa de diálogo do Service Broker

Aplica-se a:SQL ServerAzure SQL Managed Instance

A segurança de diálogo fornece criptografia, autenticação remota e autorização remota para uma conversa específica. Quando uma conversa usa segurança de diálogo, o Service Broker criptografa todas as mensagens enviadas fora de uma instância do SQL Server. As conversas do Service Broker usam a segurança de diálogo por padrão.

Noções básicas de segurança da caixa de diálogo

A segurança da caixa de diálogo do Service Broker permite que seu aplicativo use autenticação, autorização ou criptografia para uma conversa de diálogo individual (ou caixa de diálogo). Por padrão, todas as conversas de diálogo usam segurança de diálogo. Ao iniciar uma caixa de diálogo, você pode permitir explicitamente que uma caixa de diálogo prossiga sem segurança de diálogo incluindo a ENCRYPTION = OFF cláusula na BEGIN DIALOG CONVERSATION instrução. No entanto, se existir uma associação de serviço remoto para o serviço a que a conversação se destina, a caixa de diálogo utiliza segurança mesmo quando ENCRYPTION = OFF.

Para uma caixa de diálogo que usa segurança, o Service Broker criptografa todas as mensagens enviadas fora de uma instância do SQL Server. As mensagens que permanecem em uma instância do SQL Server nunca são criptografadas. Na segurança de diálogo, somente o banco de dados que hospeda o serviço inicial e o banco de dados que hospeda o serviço de destino precisam ter acesso aos certificados usados para segurança. Ou seja, uma instância que executa o encaminhamento de mensagens não é necessária para ter a capacidade de descriptografar as mensagens que a instância encaminha.

O Service Broker fornece dois tipos de segurança de diálogo, segurança total e segurança anônima. Para conversas que usam segurança de diálogo, o Service Broker fornece autorização remota para mapear o lado remoto da conversa para um usuário local.

As mensagens são criptografadas na rede quando a conversa usa segurança total ou segurança anônima. No entanto, os direitos efetivos no banco de dados de destino e a estratégia usada para a criptografia de mensagens diferem ligeiramente entre as duas abordagens.

Se a conversa usa segurança total ou segurança anônima, o corpo da mensagem é criptografado com uma chave de sessão simétrica que é gerada para a conversa específica. Somente as chaves são criptografadas com criptografia de chave privada usando o certificado fornecido para Segurança de Diálogo. O Service Broker também executa uma verificação de integridade de mensagens para ajudar a detetar corrupção ou adulteração de mensagens.

O SQL Server cria uma chave de sessão para uma conversa que usa segurança de diálogo. Para proteger a chave de sessão enquanto ela está armazenada no banco de dados, o Service Broker criptografa a chave de sessão com a chave mestra do banco de dados. Se uma chave mestra de banco de dados não estiver disponível, as transmission_status mensagens para a conversa permanecerão no com um erro até que uma chave mestra de banco de dados seja criada ou até que a conversa atinja o tempo limite. Portanto, ambos os bancos de dados que participam da conversa devem conter chaves mestras, mesmo quando os bancos de dados estão hospedados na mesma instância. Se o banco de dados inicial não contiver uma chave mestra, a caixa de diálogo falhará. Se o banco de dados de destino não contiver uma chave mestra, as mensagens permanecerão na fila de transmissão do banco de dados inicial. O último erro de transmissão dessas mensagens indica o motivo pelo qual as mensagens não podem ser entregues. Use o ENCRYPTION = OFF parâmetro para criar uma caixa de diálogo não criptografada ou use o seguinte comando para criar uma chave mestra de banco de dados:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>';

Por conveniência, o Service Broker permite que conversas seguras que permanecem em um único banco de dados prossigam, independentemente de o banco de dados conter uma chave mestra. Embora dois bancos de dados diferentes possam ser movidos para instâncias diferentes do SQL Server durante o tempo de vida de uma conversa, uma conversa dentro de um único banco de dados sempre permanece dentro desse banco de dados. Portanto, a conversa pode prosseguir.

Segurança total

A segurança total ajuda a proteger o serviço inicial contra o envio de mensagens para um banco de dados não confiável e ajuda a proteger o serviço de destino contra o recebimento de mensagens de um banco de dados não confiável. O Service Broker criptografa mensagens transmitidas pela rede quando a conversa usa segurança total.

A segurança total fornece identificação tanto para o serviço inicial quanto para o serviço de destino. A segurança total requer que o serviço inicial confie no serviço de destino e também requer que o serviço de destino confie no serviço inicial. Por exemplo, um serviço que encomenda peças de um fornecedor pode exigir que o aplicativo de pedidos confie no serviço do fornecedor e que o serviço do fornecedor confie no aplicativo de pedidos.

Os administradores de banco de dados estabelecem confiança trocando certificados que contêm chaves públicas. Para segurança total da caixa de diálogo, cada lado da conversa contém uma chave privada para um usuário local e uma chave pública para um usuário remoto. O banco de dados que hospeda o serviço inicial contém uma associação de serviço remoto. Essa associação de serviço remoto especifica o usuário local que possui o certificado que corresponde à chave privada no banco de dados remoto. Portanto, as operações em nome do serviço inicial são executadas como o usuário designado no banco de dados de destino.

O banco de dados de destino contém um usuário. Esse usuário possui um certificado que corresponde a uma chave privada que pertence ao usuário proprietário do serviço inicial. Portanto, as operações em nome do serviço de destino são executadas no banco de dados inicial como o usuário proprietário do serviço inicial.

Para diálogos que utilizam segurança completa, cada lado da conversa gera uma chave de sessão. A primeira mensagem em cada direção contém a chave de sessão, criptografada com uma chave de troca de chaves, conforme descrito em Certificados e Service Broker.

Segurança anónima

A segurança anónima ajuda a proteger o serviço inicial contra o envio de mensagens para uma base de dados não fidedigna. O Service Broker criptografa mensagens transmitidas pela rede quando a conversa usa segurança anônima.

A segurança anónima identifica o serviço de destino ao serviço originador, mas não identifica o serviço originador ao serviço de destino.

Por exemplo, um aplicativo que envia ordens de serviço pode precisar garantir que o destinatário da ordem de serviço seja o destino pretendido, mas o banco de dados de destino pode não precisar fornecer privilégios especiais para um serviço que envia ordens de serviço. Nesse caso, o banco de dados que contém o serviço inicial deve conter uma associação de serviço remoto para o serviço de destino.

Como o serviço de destino não pode verificar a identidade do serviço iniciador, as operações em nome do serviço inicial são executadas como um membro da função de banco de dados fixa pública no banco de dados de destino. O banco de dados de destino não recebe informações sobre o usuário que iniciou a conversa. O banco de dados de destino não precisa conter um certificado para o usuário que inicia a conversa.

Para diálogos que usam segurança anónima, ambos os lados da conversa utilizam a chave de sessão gerada pelo banco de dados originário. O banco de dados de destino não retorna uma chave de sessão para o banco de dados inicial.

Contextos de segurança para segurança de diálogo

A autorização remota do Service Broker controla o acesso remoto a um serviço individual. A autorização remota determina o contexto de segurança no qual as mensagens de entrada para uma instância do SQL Server são enviadas para um serviço.

O Service Broker sempre usa autorização remota para uma conversa segura que não ocorre inteiramente em uma instância do SQL Server. A segurança do diálogo configurada para a conversa determina o contexto de segurança que o Service Broker usa para a autorização remota.

O Service Broker não usa autorização remota quando a conversa permanece em uma instância do SQL Server, mesmo que a autorização remota esteja configurada. Para uma interação dentro de uma instância, os principais de segurança do SQL Server já estão disponíveis para o SQL Server, pelo que não é necessário usar autorização remota para determinar o contexto de segurança correto para as operações do Service Broker. No entanto, conforme descrito anteriormente neste tópico, o Service Broker cria uma chave de sessão para que a conversa possa prosseguir se um dos bancos de dados for movido para outra instância durante a conversa.

Para uma conversa que usa segurança anônima, a conexão é executada como um membro da função de banco de dados fixa pública no banco de dados de destino. Nesse caso, a função de banco de dados fixa pública deve ter permissão para enviar uma mensagem ao serviço. No entanto, a função não precisa de outras permissões no banco de dados.

Para uma conversa que usa segurança total, a conexão em cada lado da conversa atua com as permissões do usuário especificadas na associação de serviço remoto. Por exemplo, se uma associação de serviço remoto associar o nome InventoryService do serviço ao usuário InventoryServiceRemoteUser, o SQL Server usará o contexto de segurança para InventoryServiceRemoteUser colocar mensagens para o InventoryService aplicativo na fila para o serviço de destino.

Para maior segurança, o usuário que possui a chave privada para um serviço normalmente é um usuário diferente do usuário especificado para ativação. Um usuário que possui uma chave privada só precisa de permissão para adicionar uma mensagem à fila - ou seja, SEND permissão para o serviço que usa a fila. Por outro lado, o usuário especificado para ativação tem as permissões necessárias para realizar o trabalho solicitado e enviar uma resposta. No exemplo anterior, InventoryServiceRemoteUser não requer permissões para consultar a tabela de inventário ou enviar uma mensagem de retorno. O usuário só precisa de permissões para enviar uma mensagem para a fila que InventoryService usa. A ativação do procedimento guardado ocorre numa sessão diferente com as credenciais especificadas pela fila. Não é necessário compartilhar credenciais entre a sessão que enfileira a mensagem e a sessão que a processa.

Criar uma caixa de diálogo segura

Quando o Service Broker estabelece um diálogo entre duas bases de dados, o serviço iniciador deve estabelecer um contexto de utilizador na base de dados de destino para que possa colocar mensagens na fila de destino. Este contexto de utilizador determina se o serviço inicial tem permissão para abrir um diálogo com o destino.

A maneira mais flexível de fazer isso é criar um certificado e uma associação de serviço remoto. Para obter mais informações sobre como criar um certificado, consulte CREATE CERTIFICATE. Para obter mais informações sobre como criar uma ligação de serviço remoto, consulte CREATE REMOTE SERVICE BINDING.

Conteúdo relacionado

• Broker:Classe de evento de mensagem corrompida
• Classe de evento de login do agente de auditoria
• Ligações de serviço remoto
• Determinar o tipo de segurança da caixa de diálogo