Segurança de transporte para espelhamento de banco de dados e grupos de disponibilidade AlwaysOn (SQL Server)

Artigo
06/25/2013

A segurança de transporte no SQL Server 2005 e versões posteriores envolve autenticação e, opcionalmente, criptografia de mensagens trocadas entre os bancos de dados. Para o espelhamento de banco de dados e Grupos de Disponibilidade AlwaysOn, a autenticação e a criptografia são configuradas no ponto de extremidade do espelhamento de banco de dados. Para uma introdução sobre pontos de extremidade de espelhamento de banco de dados, consulte O ponto de extremidade de espelhamento de banco de dados (SQL Server).

Neste tópico:

Autenticação
Criptografia de dados
Tarefas relacionadas

Autenticação

Autenticação é o processo de verificar se um usuário é quem o usuário diz ser. Conexões entre pontos de extremidade espelhamento de banco de dados requerem autenticação. Exigências de conexão de um parceiro ou testemunha, se existir, devem ser autenticadas.

O tipo de autenticação usado por uma instância do servidor para o espelhamento de banco de dados ou Grupos de Disponibilidade AlwaysOn é uma propriedade do ponto de extremidade do espelhamento de banco de dados. Dois tipos de segurança de transporte estão disponíveis para pontos de extremidade do espelhamento de banco de dados: Autenticação do Windows (SSPI) e autenticação baseada em certificado.

Autenticação do Windows

Sob autenticação do Windows, cada instância de servidor faz o logon para o outro lado usando as credenciais da conta de usuário do Windows sob o qual o processo está sendo executado. A Autenticação do Windows pode exigir configuração manual de contas de logon, como segue:

Se as instâncias do SQL Server forem executadas como serviços sob a mesma conta de domínio, nenhuma configuração adicional será necessária.
Se as instâncias do SQL Server forem executadas como serviços em diferentes contas de domínio (nos mesmos domínios ou em domínios confiáveis), o logon de cada conta deverá ser criado no master de cada uma das outras instâncias de servidor, e esse logon deverá receber permissões CONNECT no ponto de extremidade.
Se as instâncias do SQL Server forem executadas como conta de serviço de rede, o logon da conta de cada computador host (DomainName**\**ComputerName$) deverá ser criado no master de cada um dos outros servidores, e esse logon deverá receber permissões CONNECT no ponto de extremidade. Isso é porque uma instância de servidor em execução sob a conta de serviço de rede é autenticada usando a conta de domínio do computador host.

Observação
Para obter um exemplo da configuração de uma sessão de espelhamento de banco de dados usando Autenticação do Windows, consulte Exemplo: Configurando o espelhamento de banco de dados usando a Autenticação do Windows (Transact-SQL).

Certificados

Em algumas situações, como quando as instâncias de servidor não estão em domínios confiáveis ou quando o SQL Server estiver executando como um serviço local, a Autenticação do Windows é indisponível. Em tais casos, em vez de credenciais de usuário, são exigidos certificados para autenticar solicitações de conexão. O ponto de extremidade do espelhamento de cada instância de servidor deve ser configurado com seu próprio certificado localmente criado.

O método de criptografia é estabelecido quando o certificado é criado. Para obter mais informações, consulte Permitir que um ponto de extremidade de espelhamento de banco de dados use certificados para conexões de saída (Transact-SQL). Administre cuidadosamente os certificados que você usa.

Uma instância de servidor usa a chave privada de seu próprio certificado para estabelecer sua identidade ao configurar uma conexão. A instância de servidor que recebe a solicitação de conexão usa a chave pública do certificado do remetente para autenticar a identidade do remetente. Por exemplo, considere duas instâncias de servidor, Server_A e Server_B. Server_A usa sua chave privada para criptografar o cabeçalho da conexão antes de enviar uma solicitação de conexão a Server_B. Server_B usa a chave pública do certificado de Server_A para descriptografar o cabeçalho da conexão. Se o cabeçalho descriptografado estiver correto, Server_B saberá que o cabeçalho foi criptografado por Server_A, e a conexão é autenticada. Se o cabeçalho descriptografado estiver incorreto, Server_B saberá que a solicitação de conexão não é autêntica e recusará a conexão.

Criptografia de dados

Por padrão, um ponto de extremidade de espelhamento de banco de dados solicita a criptografia de dados enviados por conexões de espelhamento. Neste caso, os pontos de extremidade podem se conectar apenas a pontos de extremidade que também usam criptografia. A menos que você possa garantir que sua rede está segura, recomendamos que você solicite criptografia para suas conexões de espelhamento de banco de dados. Porém, você pode desabilitar a criptografia ou torná-la suportável, mas não obrigatória. Se a criptografia estiver desabilitada, nunca serão criptografados dados e os pontos de extremidade não poderão se conectar a um ponto de extremidade que solicita criptografia. Se a criptografia for suportada, só serão criptografados dados se o ponto de extremidade suportar ou solicitar criptografia.

Observação
Os pontos de extremidade de espelhamento criados por SQL Server Management Studio são criados com criptografia obrigatória ou desabilitada. Para alterar a configuração de criptografia para SUPPORTED, use a instrução ALTER ENDPOINT Transact-SQL. Para obter mais informações, consulte ALTER ENDPOINT (Transact-SQL).

Opcionalmente, você pode controlar os algoritmos de criptografia que podem ser usados por um ponto de extremidade, especificando um dos seguintes valores para a opção de ALGORITHM em uma instrução CREATE ENDPOINT ou instrução ALTER ENDPOINT:

RC4

Especifica que o ponto de extremidade deve usar o algoritmo RC4. Esse é o padrão.

Observação
O algoritmo RC4 é substituído. Esse recurso será removido em uma versão futura do Microsoft SQL Server. Não utilize esse recurso em desenvolvimentos novos e modifique, assim que possível, os aplicativos que atualmente o utilizam. É recomendável o uso do AES.

AES

Especifica que o ponto de extremidade deve usar o algoritmo AES.

AES RC4

Especifica que o dois pontos de extremidade negociarão por um algoritmo de criptografia com esse ponto de extremidade, dando preferência ao algoritmo AES.

RC4 AES

Especifica que o dois pontos de extremidade negociarão por um algoritmo de criptografia com esse ponto de extremidade, dando preferência ao algoritmo RC4.

Se os pontos de extremidade especificarem ambos os algoritmos, mas em ordens diferentes, vence o ponto de extremidade que aceita a conexão.

Observação
O algoritmo RC4 tem suporte somente para compatibilidade com versões anteriores. O novo material só pode ser criptografado por meio do algoritmo RC4 ou RC4_128 quando o banco de dados está no nível de compatibilidade 90 ou 100. (Não recomendável.) Use um algoritmo mais recente; por exemplo, um dos algoritmos AES. No SQL Server 2012, o material criptografado por meio do algoritmo RC4 ou RC4_128 pode ser descriptografado em qualquer nível de compatibilidade. Embora consideravelmente mais rápido que o AES, o RC4 é um algoritmo relativamente fraco, enquanto o AES é um algoritmo relativamente forte. Portanto, nós recomendamos que você use o algoritmo AES.

O algoritmo RC4 tem suporte somente para compatibilidade com versões anteriores. O novo material só pode ser criptografado por meio do algoritmo RC4 ou RC4_128 quando o banco de dados está no nível de compatibilidade 90 ou 100. (Não recomendável.) Use um algoritmo mais recente; por exemplo, um dos algoritmos AES. No SQL Server 2012, o material criptografado por meio do algoritmo RC4 ou RC4_128 pode ser descriptografado em qualquer nível de compatibilidade.

Embora consideravelmente mais rápido que o AES, o RC4 é um algoritmo relativamente fraco, enquanto o AES é um algoritmo relativamente forte. Portanto, nós recomendamos que você use o algoritmo AES.

Para obter informações sobre a sintaxe Transact-SQL para especificar criptografia, consulte CREATE ENDPOINT (Transact-SQL).