Segurança de transporte para espelhamento de banco de dados e grupos de disponibilidade AlwaysOn (SQL Server)
A segurança de transporte envolve autenticação e, como opção, criptografia de mensagens trocadas entre os bancos de dados. Para espelhamento de banco de dados e Always On Grupos de Disponibilidade, a autenticação e a criptografia são configuradas no ponto de extremidade de espelhamento de banco de dados. Para obter uma introdução aos pontos de extremidade de espelhamento de banco de dados, confira O ponto de extremidade de espelhamento de banco de dados (SQL Server).
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 de servidor para espelhamento de banco de dados ou grupos de disponibilidade Always On é uma propriedade do ponto de extremidade de espelhamento de banco de dados. Dois tipos de segurança do transporte estão disponíveis para os ponto de extremidade de espelhamento de banco de dados: A Autenticação do Windows (a interface 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 mestre em 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 a conta de Serviço de Rede, o logon da conta de cada computador host (DomainName**\**ComputerName$) deverá ser criado no mestre em 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 de como configurar a sessão de espelhamento de banco de dados usando a Autenticação do Windows, confira 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 fica 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, confira 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 pelo 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 Transact-SQL ALTER ENDPOINT. Para obter mais informações, confira 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:
| Valor de ALGORITHM | Descrição |
|---|---|
| RC4 | Especifica que o ponto de extremidade deve usar o algoritmo RC4. Esse é o padrão. Observação: o algoritmo RC4 foi preterido. 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. Recomendamos usar 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. Em SQL Server 2012 e versões superiores, o material criptografado usando 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 do Transact-SQL para especificar criptografia, confira CREATE ENDPOINT (Transact-SQL).
Related Tasks
Para configurar a segurança de transporte para o ponto de extremidade do espelhamento de banco de dados
Consulte Também
Escolher um algoritmo de criptografia
ALTER ENDPOINT (Transact-SQL)
DROP ENDPOINT (Transact-SQL)
Central de segurança do Mecanismo de Banco de Dados do SQL Server e Banco de Dados SQL do Azure
Gerenciar metadados ao disponibilizar um banco de dados em outra instância do servidor (SQL Server)
O ponto de extremidade de espelhamento de banco de dados (SQL Server)
sys.database_mirroring_endpoints (Transact-SQL)
sys.dm_db_mirroring_connections (Transact-SQL)
Solução de problemas de configuração de espelhamento de banco de dados (SQL Server)
Solucionar problemas de configuração de grupos de disponibilidade AlwaysOn (SQL Server)excluído