Configurar o Mecanismo de Banco de Dados do SQL Server para criptografia de conexões

Aplica-se a: SQL Server (somente para Windows)

Você pode criptografar todas as conexões de entrada do 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 do SQL Server antes de executar etapas adicionais para criptografar dados no computador servidor ou nos computadores cliente.

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 do SQL Server ao usar um certificado de uma autoridade comercial pública. Para outros cenários, confira 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 do SQL Server, execute as seguintes etapas:

1. Instale o certificado no computador que está executando o SQL Server.
2. Configure o SQL Server para usar o certificado instalado.

Dependendo da versão do SQL Server Configuration Manager que 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. Confira Gerenciamento de Certificados (SQL Server Configuration Manager) para adicionar um certificado em uma instância do SQL Server, em uma configuração do cluster de failover ou em uma configuração do grupo de disponibilidade. O Configuration Manager simplifica muito o gerenciamento de certificados, cuidando da instalação do certificado e configurando o 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 uso do SQL Server, é necessário 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 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 as seguintes etapas para instalar e configurar o certificado no computador SQL Server:

1. No menu Iniciar, selecione Executare na caixa Abrir, digite MMC e selecione OK.
2. No console do MMC, no menu Arquivo, selecione Adicionar/Remover Snap-in.
3. Na caixa de diálogo Adicionar ou Remover Snap-ins, selecione Certificados e depois escolha Adicionar.
4. Na caixa de diálogo Snap-in dos certificados, selecione Conta do computador e depois escolha Avançar>Concluir.
5. Na caixa de diálogo Adicionar ou Remover Snap-ins, selecione OK.
6. No console do MMC, expanda Certificados (Computador Local)>Pessoal, clique com o botão direito do mouse em Certificados, aponte para Todas as Tarefas e selecione Importar.
7. Complete o Assistente para Importação de Certificados, a fim de adicionar um certificado ao computador.
8. No console do MMC, clique com o botão direito do mouse no certificado importado, aponte para Todas as Tarefas e selecione Gerenciar Chaves Privadas. Na caixa de diálogo Segurança, adicione a permissão de leitura para a conta de usuário usada pela conta de serviço do SQL Server.
9. No SQL Server Configuration Manager, expanda Configuração de Rede do SQL Server, clique com o botão direito do mouse em Protocolos para <instância do servidor> e selecione Propriedades.
10. Na caixa de diálogo Protocolos para <nome da instância> Propriedades, na guia Certificado, selecione o certificado desejado na lista suspensa da caixa Certificado e escolha OK.
11. Se você precisar que todas as conexões com o SQL Server sejam criptografadas, confira Etapa 2: definir as configurações de criptografia do SQL Server. Se você quiser habilitar apenas a criptografia para clientes específicos, reinicie o serviço SQL Server e confira Casos especiais para criptografar conexões com o SQL Server.

Procedimento extra para instâncias do 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 do servidor. Em um ambiente clusterizado, essa chave é definida como Null, embora o certificado correto exista no repositório. Para resolver esse problema, você deve executar estas etapas extras em cada um dos nós de cluster depois de instalar o certificado em cada nó:

1. Navegue até o repositório de certificados em que está armazenado o certificado de nome de domínio totalmente qualificado (FQDN). Na página de propriedades do certificado, acesse a guia Detalhes e copie o valor da impressão digital do certificado para uma janela do Bloco de Notas.

2. Remova os espaços entre os caracteres hexadecimais no valor da impressão digital no Bloco de Notas.

3. Inicie o 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\Certificate

4. Se o servidor virtual do SQL estiver atualmente nesse nó, faça o failover para outro nó do cluster e reinicie o nó em que ocorreu a alteração do Registro.

5. Repita este procedimento em todos os nós.

O certificado curinga não pode ser selecionado usando o SQL Server Configuration Manager. Para usar um certificado curinga, é necessário 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, no valor Certificado.

Ao criar conexões criptografadas para um indexador do Azure Search com o SQL Server em uma VM do Azure, confira Conexões do indexador com uma instância do SQL Server em uma máquina virtual do Azure.

Etapa 2: definir as configurações de criptografia do SQL Server

As seguintes etapas só serão necessárias se você quiser forçar as comunicações criptografadas para todos os clientes:

1. No SQL Server Configuration Manager, expanda Configuração de Rede do SQL Server, clique com o botão direito do mouse em Protocolos para <instância do servidor> e selecione Propriedades.
2. Na guia Sinalizadores, na caixa ForceEncryption, selecione Sim e OK para fechar a caixa de diálogo.
3. Reinicie o serviço SQL Server.

Mais informações

Criptografia de pacote de logon versus criptografia de pacote de dados

Em 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 (no lado do servidor ou do cliente), esses dois tipos de pacotes 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 atenda aos requisitos 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 presentes no repositório de certificados do 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 os pacotes de logon. Se não houver um certificado confiável instalado, o SQL Server gera um certificado autoassinado (certificado de fallback) durante a inicialização e usará ele para criptografar as credenciais. Esse certificado autoassinado ajuda a aumentar a segurança, mas não fornece proteção contra a falsificação de identidade pelo servidor. Se o certificado autoassinado for usado e o valor da opção ForceEncryption for definido como Yes, todos os dados transmitidos por uma rede entre o SQL Server e o aplicativo cliente são criptografados usando o certificado autoassinado.

Ao usar um certificado autoassinado, o SQL Server registra a seguinte mensagem no log de erros:

O certificado gerado automaticamente foi carregado com êxito para criptografia.

O SQL Server 2016 (13.x) e versões anteriores usam o algoritmo SHA1. No entanto, o SHA1 e muitos algoritmos mais antigos estão preteridos, começando com o SQL Server 2016 (13.x). Para obter mais informações, confira Recursos preteridos do Mecanismo de Banco de Dados no SQL Server 2016 (13.x).

Nesses ambientes, se você estiver usando o certificado autoassinado gerado automaticamente pelo SQL Server, seja apenas para o handshake de pré-logon ou para criptografar todas as comunicações servidor-cliente, o software de detecção de vulnerabilidades ou o software de segurança ou as políticas da empresa podem sinalizar esse uso como um problema de segurança. Você tem as seguintes opções para estes 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.
• Como agora você entende o motivo do sinalizador, pode ignorar a mensagem (não recomendado).
• Atualize para o SQL Server 2017 (14.x) ou uma versão posterior, que usa um algoritmo de hash mais forte (SHA256) para certificados autoassinados.

Script do PowerShell para criar certificados autoassinados para o SQL Server

O snippet de código a seguir pode ser usado para criar um certificado autoassinado em um computador que está executando o SQL Server. O certificado atende aos requisitos de criptografia para uma instância autônoma do SQL Server e é salvo no repositório de certificados do computador local (o PowerShell deve ser iniciado com permissões de administrador):

# Define parameters
$certificateParams = @{
    Type = "SSLServerAuthentication"
    Subject = "CN=$env:COMPUTERNAME"
    DnsName = @("{0}" -f [System.Net.Dns]::GetHostByName($env:computerName).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

Verifique 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;
GO

A coluna encrypt_option é um valor booliano 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 SQL Server com permissões

O serviço SQL Server detecta e usa o certificado automaticamente para criptografia se todas as seguintes condições são verdadeiras:

• O certificado tem um assunto que contém o FQDN do computador
• 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 que o certificado não esteja selecionado no SQL Server Configuration Manager.

Para substituir esse comportamento:

• 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