Novos drivers para SQL Server… O que você precisa saber

Recentemente, a Microsoft lançou dois novos drivers para o SQL Server, uma grande atualização:

Driver ODBC 18 para SQL Server
Driver OLEDB 19 para SQL Server

Essas são ótimas notícias! No entanto, há uma grande mudança de quebra que requer sua atenção. Especificamente, eles mudaram como as configurações padrão funcionam para a criptografia. Em todas as versões anteriores de drivers, o padrão era não exigir criptografia. Tínhamos as opções de forçar a criptografia do lado do servidor ou solicitá-la dentro da cadeia de conexão no lado do cliente. Obviamente, para o administrador do servidor, geralmente era mais desejável forçar a criptografia do servidor, de modo que não importaria se algum aplicativo antigo não o solicitasse, mas garantiria criptografar sua comunicação com o servidor.

Existem 2 palavras-chave de cadeia de conexão e uma configuração de servidor que influencia como o driver deve se comportar:

Dentro da string de conexão do lado do cliente:

Encrypt :indica se a comunicação deve ser criptografada.
TrustServerCertificate :indica se o cliente deve confiar apenas no certificado do servidor sem verificar a autenticidade do certificado.

Nas configurações do lado do servidor:

Force Encryption :exige que qualquer cliente que se conecte ao servidor criptografe a comunicação, independentemente da string de conexão do cliente.

A combinação das 3 propriedades influencia como a conexão será feita. Há um gráfico útil enumerando-os, que pode ser encontrado aqui.

No entanto, o cenário mais comum é que forçamos a criptografia do servidor e não especificamos mais nada na string de conexão. Aqui está a versão extraída de ambas as versões anteriores e o comportamento da nova versão:

Versão	Criptografar	Trust Server Certificado	Força do servidor Criptografia	Resultado
ODBC 17 e anterior OLEDB 18 e anterior	Não	Não	Sim	O certificado do servidor não foi verificado. Os dados enviados entre cliente e servidor são criptografados.
ODBC 18 OLEDB 19	Não	Não	Sim	O certificado do servidor foi verificado. Os dados enviados entre cliente e servidor são criptografados.

Acho que isso geralmente é uma coisa boa, especialmente com os bancos de dados SQL do Azure se tornando mais comuns, mas a alteração da verificação do certificado do SQL Server introduz uma alteração, especialmente para servidores que podem não ter certificados configurados. Por padrão, ele usará um certificado autoassinado, que não é tão seguro quanto um confiável. Para aqueles servidores onde as conexões são feitas pela internet, a precaução extra vale o esforço.

Aqui está uma comparação das cadeias de conexão ODBC para o Microsoft Access com alterações do SQL Server entre a versão anterior e a versão atual:

ODBC 17 vs. ODBC 18

17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ; Criptografar=sim;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;

Cadeias de conexão OLEDB 18 vs. OLEDB 19 para Microsoft Access com SQL Server

18:Provider= MSOLEDBSQL ;Data Source= ;Initial Catalog= ; Criptografar=sim;
19:Provider= MSOLEDBSQL19 ;Data Source= ;Initial Catalog=

Observe que nas versões anteriores, você precisava especificar o Encrypt=yes mas isso agora está implícito nas versões atuais.

Ok, mas eu tenho um servidor local, mas ele não está funcionando com os novos drivers?

Devido à alteração na configuração, agora você pode ver este erro:

Dependendo do cenário e dos requisitos, aqui estão as possíveis resoluções:

Instale e configure um certificado confiável no servidor.
Modifique a string de conexão do aplicativo para incluir TrustServerCertificate=Yes . USE COM CUIDADO
Modifique a string de conexão do aplicativo para incluir Encrypt=No e desative Force Encryption no servidor. NÃO RECOMENDADO
Não atualize drivers.

As etapas para resolver o problema são detalhadas nas seções correspondentes.

Resoluções

Instale e configure um certificado confiável no servidor

É muito importante notar que só porque você tem um servidor que tem um certificado SSL válido configurado e em uso ativo não significa que o SQL Server está usando o mesmo certificado. Além disso, verifica-se que o SQL Server Configuration Manager é horrível ao lidar com os certificados. Você pode descobrir que ele não listará nenhum certificado para você usar:

A versão curta é que o SQL Server Configuration Manager é excessivamente restritivo sobre quais certificados ele listará, o que pode ser bastante frustrante, especialmente porque esse é um problema de interface do usuário, não um verdadeiro requisito do próprio SQL Server. Felizmente, podemos contornar essa limitação boba da interface do usuário editando o registro diretamente. Isso corresponde à chave do registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib

Dentro dessa chave, há um valor Certificate que espera uma impressão digital do certificado.

Você pode colar manualmente a impressão digital do certificado SSL a ser usado, mas eu recomendaria usar um script para fazer isso, pois também precisamos garantir que a conta do servidor tenha permissão para acessar o certificado. Usei este artigo de blog como um guia para configurar o script do PowerShell para selecionar o certificado e carregá-lo na chave de registro do SQL Server e reiniciar o serviço. Dependendo de quem fornece seu certificado SSL e o fluxo de trabalho, você pode querer integrá-lo a algumas outras tarefas agendadas para que, quando o certificado SSL for renovado, a chave de registro e as permissões sejam atualizadas de acordo.

Se tudo estiver configurado corretamente, seu servidor poderá usar os novos drivers sem nenhuma modificação na string de conexão do aplicativo. Como uma verificação adicional, você pode verificar o log de erros do SQL Server e procurar uma linha como esta:

<timestamp>     spid11s     The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.

Se a impressão digital corresponder à que você deseja usar, você sabe que a carregou corretamente e, assim, a cadeia de confiança agora está estabelecida.

Modifique a string de conexão do aplicativo para incluir `TrustServerCertificate=Yes`

No entanto, se o seu servidor não estiver voltado para a Internet e for muito difícil configurar um certificado SSL, pode ser aceitável ativar o TrustServerCertificate . Isso requer uma alteração na string de conexão do seu aplicativo. Isso permite que o aplicativo permita a conexão com um servidor sem verificar o certificado do servidor. Se você puder controlar seu aplicativo com confiança para que ele não saia da sua rede, isso deve ser bom. Lembre-se de que, se alguém conseguir falsificar o nome ou o IP do servidor na rede, os aplicativos clientes estarão se conectando cegamente a esse computador. Por esse motivo, não podemos recomendar isso se houver internet envolvida na conexão. Nós realmente preferimos não correr o risco.

Modifique a string de conexão do aplicativo para incluir `Encrypt=No` e desative `Force Encryption` no servidor.

Essa é para quem gosta de aparecer na internet com um letreiro de neon gigante “STEAL MY DATA! SEQUEM-ME AGORA!” para todos os maus atores lá fora. Isso é erm, uma “opção”. A única coisa que posso dizer sobre essa opção é que é extremamente ruim. Tão ruim, que eu esqueci como fazer isso. Você está sozinho, amigo.

Não atualize drivers.

Uma alternativa um pouco melhor em comparação com a anterior é simplesmente não atualizar e ficar com os drivers ODBC 17 e OLEDB 18. No entanto, esta é, na melhor das hipóteses, uma medida paliativa. Essa resolução não requer alterações no aplicativo, mas isso apenas atrasa as alterações inevitáveis na melhor das hipóteses. Você pode aproveitar o tempo para explorar caminhos que o levarão à versão mais recente e protegerão seus dados adequadamente.

Espero que ajude!