Nuevos controladores para SQL Server... Lo que necesita saber

Recientemente, Microsoft lanzó dos nuevos controladores para SQL Server, una actualización importante:

Controlador ODBC 18 para SQL Server
Controlador OLEDB 19 para SQL Server

¡Esas son buenas noticias! Sin embargo, hay cambios importantes que requieren su atención. Específicamente, cambiaron cómo funciona la configuración predeterminada para el cifrado. En todas las versiones anteriores de los controladores, el valor predeterminado era no requerir cifrado. Teníamos las opciones de forzar el cifrado desde el lado del servidor o solicitarlo dentro de la cadena de conexión en el lado del cliente. Obviamente, para el administrador del servidor, por lo general, era más deseable forzar el cifrado desde el servidor, de modo que no importaría si alguna aplicación antigua no lo solicitaba, pero estaría garantizado para cifrar su comunicación con el servidor.

Hay 2 palabras clave de cadena de conexión y una configuración de servidor que influye en cómo debe comportarse el controlador:

Dentro de la cadena de conexión del lado del cliente:

• Encrypt :indica si la comunicación debe cifrarse.
• TrustServerCertificate :Indica si el cliente debe simplemente confiar en el certificado del servidor sin verificar la autenticidad del certificado.

Dentro de la configuración desde el lado del servidor:

• Force Encryption :exige que cualquier cliente que se conecte al servidor cifre la comunicación independientemente de la cadena de conexión del cliente.

La combinación de las 3 propiedades influye en cómo se realizará la conexión. Hay un gráfico útil que los enumera, que se puede encontrar aquí..

Sin embargo, el escenario más común es que forzamos el cifrado desde el servidor y no especificamos nada más en la cadena de conexión. Aquí está la versión extraída de las versiones anteriores y el comportamiento de la nueva versión:

Creo que, en general, esto es algo bueno, especialmente con las bases de datos de Azure SQL cada vez más comunes, pero el cambio de verificar el certificado de SQL Server introduce un cambio, especialmente para los servidores que pueden no tener certificados configurados. De forma predeterminada, utilizará un certificado autofirmado, que no es tan seguro como uno de confianza. Para aquellos servidores donde las conexiones se realizan a través de Internet, la precaución adicional vale la pena.

Aquí hay una comparación de las cadenas de conexión ODBC para Microsoft Access con los cambios de SQL Server entre la versión anterior y la versión actual:

ODBC 17 frente a ODBC 18

17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ; Cifrar=sí;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;

Cadenas de conexión OLEDB 18 frente a OLEDB 19 para Microsoft Access con SQL Server

18:Provider= MSOLEDBSQL ;Data Source= ;Initial Catalog= ; Cifrar=sí;
19:Provider= MSOLEDBSQL19 ;Data Source= ;Initial Catalog=

Tenga en cuenta que en versiones anteriores, tenía que especificar el Encrypt=yes pero esto ahora está implícito en las versiones actuales.

Vale, pero tengo un servidor local pero no funciona con los nuevos controladores.

Debido al cambio en la configuración, ahora puede ver este error:

Según el escenario y los requisitos, estas son posibles soluciones:

• Instalar y configurar un certificado de confianza en el servidor.
• Modifique la cadena de conexión de la aplicación para incluir TrustServerCertificate=Yes . UTILIZAR CON PRECAUCIÓN
• Modifique la cadena de conexión de la aplicación para incluir Encrypt=No y deshabilite Force Encryption en el servidor NO RECOMENDADO
• No actualice los controladores.

Los pasos para resolver el problema se detallan en las secciones correspondientes.

Resoluciones

Instalar y configurar un certificado de confianza en el servidor

Es muy importante tener en cuenta que el hecho de que tenga un servidor que tenga un certificado SSL válido configurado y en uso activo no significa que SQL Server esté usando el mismo certificado. Además, resulta que el Administrador de configuración de SQL Server es horrible al manejar los certificados. Es posible que descubras que no enumerará ningún certificado que puedas usar:

La versión corta es que el Administrador de configuración de SQL Server es excesivamente restrictivo en cuanto a los certificados que enumerará, lo que puede ser bastante frustrante, especialmente porque se trata de un problema de la interfaz de usuario, no un verdadero requisito del propio SQL Server. Afortunadamente, podemos eludir esta tonta limitación de la interfaz de usuario editando el registro directamente. Esto corresponde a la clave de registro:

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

Dentro de esa clave, hay un valor Certificate que espera una huella digital del certificado.

Puede pegar manualmente la huella digital del certificado SSL que se utilizará, pero recomendaría usar un script para hacerlo, ya que también debemos asegurarnos de que la cuenta del servidor tenga permiso para acceder al certificado. Usé este artículo de blog como guía para configurar el script de PowerShell para seleccionar el certificado y cargarlo en la clave de registro de SQL Server y reiniciar el servicio. Dependiendo de quién proporcione su certificado SSL y el flujo de trabajo, es posible que desee integrar esto en otras tareas programadas para que cuando se renueve el certificado SSL, la clave de registro y los permisos se actualicen en consecuencia.

Si todo está configurado correctamente, su servidor debería poder usar los nuevos controladores sin modificar la cadena de conexión de la aplicación. Como verificación adicional, puede consultar el registro de errores de su servidor SQL y buscar una línea como esta:

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

Si la huella digital coincide con la que desea usar, sabrá que la cargó correctamente y, por lo tanto, se ha establecido una cadena de confianza.

Modifique la cadena de conexión de la aplicación para incluir TrustServerCertificate=Yes

Sin embargo, si su servidor no está conectado a Internet y es demasiado doloroso configurar un certificado SSL, puede ser aceptable activar TrustServerCertificate . Esto requiere un cambio en la cadena de conexión de su aplicación. Esto permite que la aplicación permita conectarse a un servidor sin verificar el certificado del servidor. Si puede controlar con confianza su aplicación para que no salga de su red, esto debería estar bien. Tenga en cuenta que si alguien puede suplantar el nombre o la IP del servidor dentro de la red, las aplicaciones del cliente se conectarán ciegamente a esa computadora. Por esa razón, no podemos recomendar esto si hay Internet involucrado en la conexión. Realmente preferimos no correr el riesgo.

Modifique la cadena de conexión de la aplicación para incluir Encrypt=No y deshabilite Force Encryption en el servidor.

Esto es para aquellos a quienes les gusta navegar en Internet con un letrero de neón gigante “¡ROBA MIS DATOS! ¡SECUÉSTRAME AHORA!” a todos los malos actores que hay. Esto es erm, una "opción". Lo único que puedo decir sobre esta opción es que es extremadamente mala. Tan malo, que olvidé cómo hacer esto. Estás solo, amigo.

No actualice los controladores.

Una alternativa ligeramente mejor en comparación con la anterior es simplemente no actualizar y quedarse con los controladores ODBC 17 y OLEDB 18. Sin embargo, esto es, en el mejor de los casos, una medida provisional. Esta resolución no requiere cambios en la aplicación, pero esto solo retrasa los cambios inevitables en el mejor de los casos. Puede aprovechar el tiempo para explorar caminos que lo llevarán a la última versión y protegerán sus datos adecuadamente.

¡Espero que eso ayude!