• Artigo

Segurança de diálogo do Service Broker

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

A segurança de diálogo do Service Broker permite que seu aplicativo use autenticação, autorização ou criptografia para uma conversação (ou diálogo) individual. Por padrão, todas as conversações de diálogo usam segurança de diálogo. Quando você inicia um diálogo, pode permitir explicitamente que ele prossiga sem segurança de diálogo, incluindo a cláusula ENCRYPTION = OFF da instrução BEGIN DIALOG CONVERSATION. Contudo, se existir uma associação de serviço remoto para o serviço ao qual a conversação destinar, o diálogo usará a segurança, mesmo quando ENCRYPTION = OFF.

Para um diálogo que usa segurança, o Service Broker criptografa todas as mensagens enviadas para fora de uma instância do SQL Server. Nunca serão criptografadas mensagens que permaneçam dentro de uma instância do SQL Server. Na segurança de diálogo, apenas o banco de dados que hospeda o serviço iniciante e o banco de dados que hospeda o serviço de destino precisam ter acesso aos certificados usados para segurança. Isto é, não é necessário que uma instância que desempenhe encaminhamento de mensagens tenha a capacidade de descriptografar mensagens que a instância encaminha .

O Service Broker fornece dois tipos de segurança de diálogo, segurança completa e segurança anônima. Para conversações que usam a segurança de diálogo, o Service Broker fornece autenticação remota para mapear o lado remoto da conversação até o usuário local.

As mensagens são criptografadas na rede quando a conversação usa segurança completa 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 sutilmente entre as duas abordagens.

Quer a conversação use segurança completa quer segurança anônima, o corpo da mensagem é criptografado com uma chave de sessão simétrica gerada para a conversação específica. Somente as chaves são criptografadas usando o certificado fornecido para Segurança de Diálogo. O Service Broker também executa uma verificação de integridade da mensagem para ajudar a detectar danos ou violação da mensagem.

O SQL Server cria uma chave de sessão para uma conversação que usa segurança de diálogo. Para proteger a chave da sessão enquanto ela é arquivada 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 mensagens para as conversações permanecerão em transmission_status com um erro até que seja criada uma chave mestra de banco de dados ou até que o tempo limite da conversação se esgote. Portanto, ambos os bancos de dados que participam da conversação devem conter chaves mestras, mesmo quando os bancos de dados estão hospedados na mesma instância. Se o banco de dados iniciante não contiver uma chave mestra, o diálogo falhará. Se o banco de dados de destino não contiver uma chave mestra, as mensagens continuarão na fila de transmissão do banco de dados inicial. O último erro de transmissão dessas mensagens indicará a razão pela qual as mensagens não podem ser entregues. Use o parâmetro ENCRYPTION = OFF para criar um diálogo descriptografado ou use o seguinte comando para criar uma chave mestra de banco de dados:

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

Para conveniência, o Service Broker permitirá que conversações seguras que permaneçam dentro de um único banco de dados continuem, independentemente de o banco de dados conter uma chave mestra. Enquanto dois diferentes bancos de dados podem ser movidos para instâncias distintas do SQL Server durante o tempo de vida de uma conversação, a conversação em um único banco de dados sempre permanecerá dentro desse banco de dados. Portanto, a conversação poderá continuar.

Segurança completa

A segurança completa ajuda a evitar que o serviço iniciante envie mensagens a um banco de dados não confiável e ajuda a evitar que o serviço de destino receba mensagens de um banco de dados não confiável. O Service Broker criptografa mensagens transmitidas pela rede quando a conversação usa segurança completa.

A segurança completa fornece identificação tanto para o serviço iniciante quanto para o serviço de destino. A segurança completa requer que o serviço iniciante confie no serviço de destino e também requer que o serviço de destino confie no serviço iniciante. Por exemplo, um serviço que solicite peças de um fornecedor poderá exigir que o aplicativo de pedidos confie no serviço do fornecedor e o serviço do fornecedor confie no aplicativo de pedidos.

Administradores de bancos de dados estabelecem confiança trocando certificados que contenham chaves públicas. Para a segurança completa do diálogo, cada lado da conversação contém uma chave privada de um usuário local e uma chave pública de um usuário remoto. O banco de dados que hospeda o serviço iniciante 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 correspondente à chave privada no banco de dados remoto. Portanto, operações em nome do serviço iniciante serã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 à chave privada de propriedade do usuário que possui o serviço iniciante. Portanto, operações em nome do serviço de destino são executadas no banco de dados iniciante como o usuário que possui o serviço iniciante.

Para diálogos que usam segurança completa, cada lado da conversação gera uma chave de sessão. A primeira mensagem em cada direção contém uma 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 evitar que o serviço iniciante envie mensagens a um banco de dados não confiável. O Service Broker criptografa mensagens transmitidas pela rede quando a conversação usa segurança anônima.

A segurança anônima identifica o serviço de destino para o serviço iniciante, mas não identifica o serviço iniciante para o serviço de destino.

Por exemplo, um aplicativo que envia ordens de serviço pode ter de garantir que o destinatário da ordem de serviço seja o destino pretendido, porém o banco de dados de destino pode não precisar fornecer nenhum privilégio especial para um serviço que envia ordens de serviço. Nesse caso, o banco de dados que contém o serviço iniciante 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 iniciante, as operações em nome do serviço iniciante 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 nenhuma informação sobre o usuário que iniciou a conversação. O banco de dados de destino não precisa conter um certificado para o usuário que inicia a conversação.

Para diálogo que usam segurança anônima, ambos os lados da conversação usam a chave de sessão gerada pelo banco de dados iniciante. O banco de dados de destino não retorna uma chave de sessão ao banco de dados iniciante.

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 dentro do qual as novas mensagens para uma instância do SQL Server são enviadas a um serviço.

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

O Service Broker não usa autorização remota quando a conversação permanece dentro de uma instância do SQL Server, mesmo se a autorização remota for configurada. Para uma conversação dentro de uma instância, as entidades de segurança do SQL Server já estarão disponíveis no SQL Server, não havendo, pois, necessidade de usar autorização remota para determinar o contexto de segurança correto para as operações do Service Broker. Porém, conforme descrito no início deste tópico, o Service Broker cria uma chave de sessão de modo que a conversação possa continuar, caso um dos bancos de dados seja movido para outra instância durante uma conversação.

Para uma conversação que usa segurança anônima, a conexão é executada como 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 deverá ter permissão para enviar uma mensagem ao serviço. Porém, a função não necessita de nenhuma outra permissão no banco de dados.

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

Para melhor segurança, o usuário que possui a chave privada de um serviço é geralmente um usuário diferente daquele especificado para a ativação. Um usuário que possui uma chave privada só necessita de permissão para adicionar uma mensagem à fila – isto é, permissão SEND para o serviço que usa a fila. Ao contrário, o usuário que é especificado para a ativação tem as permissões exigidas para realizar a tarefa solicitada e enviar uma resposta. No exemplo precedente, InventoryServiceRemoteUser não requer permissões para examinar a tabela de inventário ou enviar uma mensagem de retorno. O usuário só precisa de permissões para enviar uma mensagem à fila que o InventoryService usa. A ativação de procedimento armazenado ocorre em uma sessão diferente com as credenciais que a fila especifica. Nenhuma credencial precisa ser compartilhada entre a sessão que enfileira a mensagem e a sessão que processa a mensagem.

Criando um diálogo seguro

Quando o Service Broker estabelece um diálogo entre dois bancos de dados, o serviço iniciante deverá estabelecer um contexto de usuário no banco de dados de destino para colocar mensagens na fila de destino. Esse contexto de usuário determina se o serviço iniciante tem permissão para abrir um diálogo no destino.

O modo mais flexível de fazer isto é criar uma associação de serviço remoto e certificado. Para obter mais informações sobre a criação de certificados, consulte CREATE CERTIFICATE (Transact-SQL). Para obter mais informações sobre como criar uma associação de serviço remoto consulte, CREATE REMOTE SERVICE BINDING (Transact-SQL).

Uma alternativa para criar uma associação de serviço remoto e certificado é usar a segurança de SQL Server para estabelecer uma relação confiável entre os dois bancos de dados. O proprietário do serviço iniciante representa um usuário no serviço de destino. Isso poderá exigir a definição da propriedade de banco de dados TRUSTWORTHY no banco de dados iniciante como ON e a concessão de permissão autenticada a um usuário no banco de dados de destino. Para obter mais informações, consulte Estendendo representação de banco de dados com EXECUTE AS.

ObservaçãoObservação

Se o contexto de segurança não for definido corretamente, as mensagens enviadas no diálogo permanecerão na sys.transmission_queue do serviço iniciante com a seguinte mensagem de erro na coluna transmission_status: O principal do servidor '%.*ls' não pode acessar o banco de dados '%.*ls' no contexto de segurança atual.