Cifrado en Microsoft SQL Server

Como otros proveedores de DBMS, Microsoft utiliza el protocolo SSL para la protección de sus clientes. Sin embargo, pocos saben que, a diferencia de otros DBMS, MsSQL encapsula el intercambio de claves SSL dentro de TDS.

El truco puede haberse realizado deliberadamente para reducir el número de amenazas potenciales a los servidores de Microsoft, dado que hoy en día los proveedores utilizan SSL en una combinación de capa de protocolo simple en lugar de encapsulación completa. Es más fácil y universal, porque activar o desactivar SSL no afecta al protocolo principal.

El cifrado en MsSQL se efectúa mediante dos modos: protección en la etapa de autorización y protección completa de la conexión. En ambos casos, el diálogo comienza con el intercambio de configuraciones entre el cliente y el servidor: el cliente envía su paquete PRELOGIN y recibe el mismo paquete del servidor. Luego, el cliente envía el primer paquete de handshake después de haberlo encapsulado en TDS como PRELOGIN. Todos los siguientes paquetes SSL se encapsulan de la misma manera en TDS hasta que se completa el handshake.

Sin embargo, el primer paquete SSL de aplicación y todos los siguientes se envían tal como están, sin ser encapsulados en TDS. El paquete encapsula la consulta de autorización LOGIN7. Aquí es donde los modos comienzan a diferir. En el primer modo, el cifrado SSL se completa y el tráfico posterior entre el cliente y el servidor ya no está cifrado. Durante el segundo modo, el cifrado se implementa hasta el cierre de la sesión.

Cabe señalar que, de hecho, el servidor puede funcionar sin cifrado, pero los clientes oficiales de MSSQL no ofrecen esta opción. ¿Por qué es importante? El cifrado en el canal, de una forma u otra, previene la recopilación y el análisis pasivo del tráfico, es decir, el sniffing, que representa una de nuestras funciones principales.

En caso de que sea imposible modificar el tráfico, la funcionalidad del sniffer se limita. En primer lugar, se refiere a los cifrados basados en claves efímeras. Todos los cifrados basados en ECDHE y DHE entran en esta categoría, por ejemplo:

Además, para descifrar el tráfico SSL se debe utilizar la API de bajo nivel de OpenSSL. A su vez, esto nos obliga a mantener el sniffer SSL constantemente actualizado.

Al mismo tiempo, el cliente necesita instalar una llave del servidor en el lado del proxy (firewall). Es otro obstáculo para la protección de los datos, ya que el cliente debe confiar la protección del servidor a nosotros o no utilizar el software cliente oficial de MsSQL (por ejemplo, Microsoft SQL Server Management Studio) en modo sniffer.

En cuanto a las claves efímeras, pueden ser desactivadas en el lado del servidor de MsSQL. El Proveedor de Servicios Criptográficos de Windows permite hacerlo en condiciones normales.

Así, a pesar de las evidentes restricciones del protocolo por parte de Microsoft, el sniffer para MsSQL Server está incluido en el firewall. Hemos hecho todo lo posible para facilitar a nuestros clientes su uso.

DataSunrise Database Security ofrece una solución completa de seguridad para Microsoft SQL Server o Azure SQL. DataSunrise incluye firewall de base de datos, monitoreo y auditoría de la actividad en la base de datos, descubrimiento de datos sensibles y más. DataSunrise también es compatible con todas las demás bases de datos y almacenes de datos, tales como Oracle, IBM DB2, IBM Netezza, MySQL, MariaDB, Greenplum, Amazon Aurora, Amazon Redshift, Microsoft SQL Server, Azure SQL, Teradata y más. Puedes descargar una versión de prueba gratuita si deseas instalarla en tus instalaciones. En caso de que seas un usuario de la nube y ejecutes tu base de datos en Amazon AWS o Microsoft Azure puedes obtenerla en el AWS Marketplace o en el Azure Marketplace.