Configurar o Mecanismo de Banco de Dados do SQL Server para criptografar conexões
Aplica-se a:
SQL Server - somente Windows
Você pode criptografar todas as conexões de entrada para o SQL Server ou habilitar a criptografia para apenas um conjunto específico de clientes. Para qualquer um desses cenários, primeiro você precisa configurar o SQL Server para usar um certificado que atenda aos requisitos de Certificado para do SQL Server antes de executar etapas adicionais no computador servidor ou nos computadores cliente para criptografar dados.
Observação
Este artigo aplica-se ao SQL Server no Windows. Para configurar o SQL Server no Linux para criptografar conexões, consulte Especificar configurações de TLS.
Este artigo descreve como configurar o SQL Server para certificados (Etapa 1) e alterar as configurações de criptografia da instância do SQL Server (Etapa 2). Ambas as etapas são necessárias para criptografar todas as conexões de entrada para o SQL Server ao usar um certificado de uma autoridade comercial pública. Para outros cenários, consulte Casos especiais para criptografar conexões com o SQL Server.
Etapa 1: Configurar o SQL Server para usar certificados
Para configurar o SQL Server para usar os certificados descritos em Requisitos de certificado para o SQL Server, execute estas etapas:
- Instale o certificado no computador que está executando o SQL Server.
- Configure o SQL Server para usar o certificado instalado.
Dependendo da versão do SQL Server Configuration Manager à qual você tem acesso no computador do SQL Server, use um dos procedimentos a seguir para instalar e configurar a instância do SQL Server.
Computadores com o SQL Server Configuration Manager para SQL Server 2019 e versões posteriores
No SQL Server 2019 (15.x) e versões posteriores, o gerenciamento de certificados é integrado ao SQL Server Configuration Manager e pode ser usado com versões anteriores do SQL Server. Para adicionar um certificado em uma única instância do SQL Server, em uma configuração de cluster de failover ou em uma configuração de grupo de disponibilidade, consulte Gerenciamento de certificados (SQL Server Configuration Manager). O Configuration Manager simplifica muito o gerenciamento de certificados, cuidando da instalação do certificado e da configuração do SQL Server para usar o certificado instalado com apenas algumas etapas.
Os certificados são armazenados localmente para os usuários no computador. Para instalar um certificado para o SQL Server usar, você deve executar o SQL Server Configuration Manager com uma conta que tenha privilégios de administrador local.
Você pode instalar temporariamente uma edição Express do SQL Server 2019 (15.x) ou uma versão posterior para usar o SQL Server Configuration Manager, que dá suporte ao gerenciamento integrado de certificados.
Computadores com o SQL Server Configuration Manager para SQL Server 2017 e versões anteriores
Se você usar o SQL Server 2017 (14.x) ou uma versão anterior e o SQL Server Configuration Manager para SQL Server 2019 (15.x) não estiver disponível, siga estas etapas para instalar e configurar o certificado no computador do SQL Server:
- No menu Iniciar, selecione Executare, na caixa Abrir, digite MMC e selecione OK.
- No console do MMC, no menu Arquivo , selecione Adicionar/Remover Snap-in....
- Na caixa de diálogo Adicionar ou Remover Snap-ins, selecione Certificadose, em seguida, selecione Adicionar.
- Na caixa de diálogo Certificados snap-in, selecione conta de computadore, em seguida, selecione Seguinte>Concluir.
- Na caixa de diálogo Adicionar ou Remover Snap-ins, clique em OK.
- No console MMC, expanda Certificados (Computador Local)>Pessoal, clique com o botão direito do mouse Certificados, aponte para Todas as Tarefase selecione Importar.
- Conclua o Assistente para Importação de Certificados para adicionar um certificado ao computador.
- No MMC console, clique com o botão direito do mouse no certificado importado, aponte para Todas as Tarefase selecione Gerenciar Chaves Privadas. Na caixa de diálogo de segurança, adicione permissão de leitura para a conta de usuário usada pela conta de serviço do SQL Server.
- No SQL Server Configuration Manager, expanda de Configuração de Rede do SQL Server , clique com o botão direito do mouse Protocolos para <instância do servidor>e selecione Propriedades.
- Na caixa de diálogo Protocolos para <nome de instância> Propriedades, no separador Certificado, selecione o certificado desejado na lista suspensa para a caixa Certificado e, em seguida, selecione OK.
- Se você precisar que todas as conexões com o SQL Server sejam criptografadas, consulte Etapa 2: Definir configurações de criptografia no SQL Server. Se você quiser habilitar a criptografia apenas para clientes específicos, reinicie o serviço do SQL Server e consulte Casos especiais para criptografar conexões com o SQL Server.
Observação
Para instalar certificados na configuração do grupo de disponibilidade, repita o procedimento anterior em cada nó do grupo de disponibilidade, começando pelo nó primário.
Importante
A conta de serviço do SQL Server deve ter permissões de leitura no certificado usado para forçar a criptografia na instância do SQL Server. Para uma conta de serviço não privilegiada, as permissões de leitura devem ser adicionadas ao certificado. A falha ao fazer isso pode fazer com que a reinicialização do serviço SQL Server falhe.
Procedimento extra para instâncias de cluster de failover
O certificado usado pelo SQL Server para criptografar conexões é especificado na seguinte chave do Registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLServer\SuperSocketNetLib\Certificate
Essa chave contém uma propriedade do certificado conhecida como impressão digital, que identifica cada certificado no servidor. Em um ambiente clusterizado, essa chave é definida como Null mesmo que o certificado correto exista no armazenamento. Para resolver esse problema, você deve executar estas etapas adicionais em cada um dos nós do cluster depois de instalar o certificado em cada nó:
Navegue até o repositório de certificados onde o certificado FQDN (nome de domínio totalmente qualificado) está armazenado. Na página de propriedades do certificado, vá para o separador Detalhes e copie o valor da impressão digital do certificado para uma janela do Bloco de Notas .
Remova os espaços entre os caracteres hexadecimais no valor de impressão digital em Bloco de Notas.
Inicie Editor do Registro, navegue até a seguinte chave do Registro e cole o valor da Etapa 2:
HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\<instance>\MSSQLServer\SuperSocketNetLib\CertificateSe o servidor virtual SQL estiver atualmente nesse nó, execute um failover para outro nó no cluster e, depois, reinicie o nó onde ocorreu a alteração do registro.
Repita este procedimento em todos os nós.
Advertência
A edição incorreta do registo pode danificar gravemente o seu sistema. Antes de fazer alterações no Registro, recomendamos que você faça backup de todos os dados valiosos no computador.
Observação
O SQL Server 2008 R2 (10.50.x) e o SQL Server 2008 R2 (10.50.x) Native Client (SNAC) oferecem suporte a certificados curinga. Desde então, o SNAC foi preterido e substituído pelo Microsoft OLE DB Driver para SQL Server e Microsoft ODBC Driver para SQL Server. Outros clientes podem não suportar certificados wildcard.
O certificado wildcard não pode ser selecionado através do SQL Server Configuration Manager. Para usar um certificado curinga, você deve editar a chave do Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQLServer\SuperSocketNetLib e inserir a impressão digital do certificado, sem espaços, para o valor Certificate.
Observação
Para usar a criptografia com um cluster de failover, você deve instalar o certificado do servidor com o nome DNS totalmente qualificado do servidor virtual em todos os nós do cluster de failover. Você pode definir o valor da opção ForceEncryption na caixa de propriedades dos Protocolos para virtsql da Configuração de Rede do SQL Server como Sim.
Ao criar conexões criptografadas para um indexador do Azure Search para o SQL Server em uma máquina virtual do Azure, consulte conexões do indexador para uma instância do SQL Server em uma máquina virtual do Azure.
Etapa 2: Definir configurações de criptografia no SQL Server
As etapas a seguir só são necessárias se você quiser forçar comunicações criptografadas para todos os clientes:
- No SQL Server Configuration Manager, expanda Configuração de Rede do SQL Server, clique com o botão direito em Protocolos para a <instância do servidor>e selecione Propriedades.
- No separador Sinalizadores, na caixa ForceEncryption, selecione Sime, em seguida, selecione OK para fechar a caixa de diálogo.
- Reinicie o serviço SQL Server.
Observação
Alguns cenários de certificado podem exigir que você implemente etapas adicionais no computador cliente e no aplicativo cliente para garantir conexões criptografadas entre o cliente e o servidor. Para obter mais informações, consulte Casos especiais para criptografar conexões com o SQL Server.
Mais informações
Criptografia de pacotes de login versus criptografia de pacotes de dados
Em um alto nível, há dois tipos de pacotes no tráfego de rede entre um aplicativo cliente do SQL Server e o SQL Server: pacotes de credenciais (pacotes de logon) e pacotes de dados. Quando você configura a criptografia (do lado do servidor ou do lado do cliente), ambos os tipos de pacote são sempre criptografados. Mas, mesmo quando você não configura a criptografia, as credenciais (no pacote de logon) que são transmitidas quando um aplicativo cliente se conecta ao SQL Server são sempre criptografadas. O SQL Server usa um certificado que atende aos requisitos de certificado de uma autoridade de certificação confiável, se disponível. Esse certificado é configurado manualmente pelo administrador do sistema, usando um dos procedimentos discutidos anteriormente no artigo, ou presente no armazenamento de certificados no computador do SQL Server.
Certificados autoassinados gerados pelo SQL Server
O SQL Server usa um certificado de uma autoridade de certificação confiável, se disponível, para criptografar pacotes de logon. Se um certificado confiável não estiver instalado, o SQL Server gerará um certificado autoassinado (certificado de fallback) durante a inicialização e usará esse certificado autoassinado para criptografar as credenciais. Esse certificado autoassinado ajuda a aumentar a segurança, mas não protege contra falsificação de identidade pelo servidor. Se o certificado autoassinado for usado e o valor da opção ForceEncryption estiver definido como Sim, todos os dados transmitidos por uma rede entre o SQL Server e o aplicativo cliente serão criptografados usando o certificado autoassinado.
Quando você usa um certificado autoassinado, o SQL Server registra a seguinte mensagem no log de erros:
Um certificado autogerado foi carregado com êxito para criptografia.
O SQL Server 2016 (13.x) e versões anteriores usam o algoritmo SHA1. No entanto, o algoritmo SHA1 e muitos algoritmos mais antigos foram preteridos a partir do SQL Server 2016 (13.x). Para obter mais informações, consulte recursos preteridos do Mecanismo de Banco de Dados no SQL Server 2016 (13.x).
Nesses ambientes, se estiveres a utilizar o certificado autoassinado gerado automaticamente pelo SQL Server, apenas para o aperto de mão pré-login ou para criptografar todas as comunicações servidor-cliente, o teu software de deteção de vulnerabilidades, software de segurança ou políticas empresariais podem sinalizar este uso como um problema de segurança. Você tem as seguintes opções para esses cenários:
- Crie um novo certificado autoassinado ou um certificado de terceiros que use algoritmos de criptografia mais fortes e configure o SQL Server para usar esse novo certificado.
- Uma vez que agora você entende o motivo da bandeira, você pode ignorar a mensagem (não recomendado).
- Atualize para o SQL Server 2017 (14.x) ou uma versão posterior que use um algoritmo de hash mais forte (SHA256) para certificados autoassinados.
Script do PowerShell para criar certificado autoassinado para o SQL Server
O trecho de código a seguir pode ser usado para criar um certificado autoassinado em um computador que executa o SQL Server. O certificado atende aos requisitos de criptografia para uma instância autônoma do SQL Server e é salvo no armazenamento de certificados do computador local (o PowerShell deve ser iniciado como administrador):
# Define parameters
$certificateParams = @{
Type = "SSLServerAuthentication"
Subject = "CN=$env:COMPUTERNAME"
DnsName = @("$($env:COMPUTERNAME)", $([System.Net.Dns]::GetHostEntry('').HostName), 'localhost')
KeyAlgorithm = "RSA"
KeyLength = 2048
HashAlgorithm = "SHA256"
TextExtension = "2.5.29.37={text}1.3.6.1.5.5.7.3.1"
NotAfter = (Get-Date).AddMonths(36)
KeySpec = "KeyExchange"
Provider = "Microsoft RSA SChannel Cryptographic Provider"
CertStoreLocation = "cert:\LocalMachine\My"
}
# Call the cmdlet
New-SelfSignedCertificate @certificateParams
Verificar a criptografia de rede
Para verificar se a criptografia de rede está configurada e habilitada com êxito, execute a seguinte consulta Transact-SQL:
USE [master];
GO
SELECT DISTINCT (encrypt_option)
FROM sys.dm_exec_connections
WHERE net_transport <> 'Shared memory';
GO
A coluna encrypt_option é um valor booleano que indica se a criptografia está habilitada para essa conexão. Se o valor for TRUE, a conexão será criptografada com segurança. Se o valor for FALSE, a conexão não será criptografada.
Comportamento do certificado do SQL Server com permissões
O serviço SQL Server deteta e usa o certificado automaticamente para criptografia se todas as seguintes condições forem verdadeiras:
- O certificado tem um assunto que contém o FQDN da máquina
- O certificado é instalado no armazenamento de certificados do computador local
- A conta de serviço do SQL Server recebe acesso à chave privada do certificado
Esse uso acontece mesmo se o certificado não estiver selecionado no SQL Server Configuration Manager.
Para substituir esse comportamento, faça o seguinte:
Configurar outro certificado a ser usado no SQL Server Configuration Manager
ou
Remover as permissões da conta de serviço do SQL Server para o certificado indesejado