Encriptacion en MSSQL Server

Al igual que otros proveedores de DBMS, Microsoft utiliza el protocolo SSL para la protección de sus clientes. Sin embargo, pocos son conscientes de que a diferencia de otros DBMS, MsSQL encapsula el apretón de manos SSL dentro de TDS.

El truco podría hacerse deliberadamente para reducir el número de amenazas potenciales a los servidores de MS, ya que hoy en día los proveedores utilizan SSL en una combinación de capa de protocolo simple como encapsulación completa. Es más fácil y más universal porque activar/desactivar SSL no afecta el protocolo principal.

El cifrado en MsSQL se efectúa a través de 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 cliente-servidor: el cliente envía su paquete PRELOGIN y recibe el mismo paquete del servidor. Luego, el cliente dirige el primer paquete de apretón de manos después de encapsularlo en TDS como PRELOGIN. Todos los siguientes paquetes SSL se encapsulan de la misma manera en TDS hasta que se completa el apretón de manos.

Sin embargo, el primer paquete de aplicación SSL y todos los subsecuentes se envían tal cual, sin estar encapsulados en TDS. El paquete encapsula la consulta de autorización LOGIN7. Aquí es donde los modos comienzan a diferir. El cifrado SSL del primer modo se completa y el tráfico siguiente 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.

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

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

Además, para descifrar el tráfico SSL se tiene que utilizar la API de bajo nivel de OpenSSL. A su vez, nos exige mantener el sniffer SSL constantemente actualizado.

Al mismo tiempo, el cliente necesita instalar una clave de servidor en el lado del proxy (cortafuegos). Es otro obstáculo para la protección de datos, ya que el cliente debe confiar la protección del servidor a nosotros o no usar 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 del lado del servidor de MsSQL. El Proveedor de Servicios Criptográficos de Windows permite hacerlo bajo condiciones normales.

Así, a pesar de las obvias restricciones del protocolo por parte de Microsoft, el sniffer para MsSQL Server está incluido en el cortafuegos. Hemos hecho todo lo posible para que sea fácil para nuestros clientes usarlo.

DataSunrise Database Security ofrece una solución completa de seguridad para Microsoft SQL Server o Azure SQL. DataSunrise incluye cortafuegos de bases de datos, monitoreo de actividad y auditoría, descubrimiento de datos sensibles y más. DataSunrise también es compatible con todas las demás bases de datos y almacenes de datos como Oracle, IBM DB2, IBM Netezza, MySQL, MariaDB, Greenplum, Amazon Aurora, Amazon Redshift, Microsoft SQL Server, Azure SQL, Teradata y más. Estás invitado a descargar una prueba gratuita si deseas instalarlo 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 obtenerlo desde AWS marketplace o Azure marketplace.