Chiffrement dans Microsoft SQL Server

Comme les autres fournisseurs de SGBD, Microsoft utilise le protocole SSL pour protéger ses clients. Cependant, peu de personnes savent que contrairement à d’autres SGBD, MsSQL encapsule la poignée de main SSL dans TDS.

Ce procédé a peut-être été réalisé volontairement pour réduire le nombre de menaces potentielles sur les serveurs MS, alors qu’aujourd’hui, les fournisseurs utilisent le SSL dans une simple combinaison de couche de protocole sous forme d’encapsulation complète. C’est plus simple et plus universel, car l’activation ou la désactivation du SSL n’affecte pas le protocole principal.

Le chiffrement dans MsSQL s’effectue via deux modes : la protection pendant la phase d’autorisation et la protection de l’ensemble de la connexion. Dans les deux cas, le dialogue commence par l’échange de paramètres entre le client et le serveur : le client envoie son paquet PRELOGIN et reçoit le même paquet du serveur. Ensuite, le client envoie le premier paquet de la poignée de main, après l’avoir encapsulé dans TDS sous forme de PRELOGIN. Tous les paquets SSL suivants sont encapsulés de la même manière dans TDS jusqu’à ce que la négociation soit terminée.

Cependant, le premier paquet d’application SSL ainsi que tous les paquets suivants sont envoyés tels quels, sans être encapsulés dans TDS. Le paquet encapsule la requête d’autorisation LOGIN7. C’est ici que les modes commencent à différer. Le chiffrement SSL du premier mode est terminé et le trafic subséquent entre le client et le serveur n’est plus chiffré. Dans le deuxième mode, le chiffrement est appliqué jusqu’à la fermeture de la session.

Il est à noter que le serveur, en réalité, peut fonctionner sans chiffrement, mais les clients officiels de MSSQL ne proposent pas cette option. Pourquoi cela est-il important ? Le chiffrement du canal, d’une manière ou d’une autre, empêche la collecte passive et l’analyse du trafic, c’est-à-dire le sniffing, qui constitue l’une de nos fonctions principales.

Dans le cas où il est impossible de modifier le trafic, la fonctionnalité du sniffer est limitée. Tout d’abord, cela concerne les chiffres basés sur des clés éphémères. Tous les chiffres basés sur ECDHE et DHE relèvent de cette catégorie, par exemple :

De plus, pour décrypter le trafic SSL, il est nécessaire d’utiliser l’API OpenSSL de bas niveau. Celle-ci, à son tour, nous oblige à maintenir constamment le sniffer SSL à jour.

Par ailleurs, le client doit installer une clé de serveur du côté du proxy (pare-feu). Cela représente un obstacle supplémentaire à la protection des données, car le client doit nous confier la protection du serveur ou ne pas utiliser le logiciel client officiel de MsSQL (par exemple, Microsoft SQL Server Management Studio) en mode sniffer.

En ce qui concerne les clés éphémères, elles peuvent être désactivées du côté serveur de MsSQL. Le fournisseur de services cryptographiques de Windows permet de le faire dans des conditions normales.

Ainsi, malgré les restrictions évidentes du protocole de la part de Microsoft, le sniffer pour MsSQL Server est intégré dans le pare-feu. Nous avons fait tout notre possible pour en faciliter l’utilisation par nos clients.

DataSunrise Database Security offre une solution de sécurité complète pour Microsoft SQL Server ou Azure SQL. DataSunrise inclut un pare-feu pour bases de données, une surveillance des activités et un audit, la détection des données sensibles et bien plus encore. DataSunrise prend également en charge toutes les autres bases de données et entrepôts de données tels que Oracle, IBM DB2, IBM Netezza, MySQL, MariaDB, Greenplum, Amazon Aurora, Amazon Redshift, Microsoft SQL Server, Azure SQL, Teradata et bien d’autres. Vous êtes invités à télécharger une version d’essai gratuite si vous souhaitez l’installer sur vos locaux. Dans le cas où vous seriez un utilisateur cloud et que votre base de données fonctionne sur Amazon AWS ou Microsoft Azure, vous pouvez l’obtenir via AWS Marketplace ou Azure Marketplace.