Chiffrement dans Microsoft SQL Server

Comme d’autres fournisseurs de SGBD, Microsoft utilise le protocole SSL pour la protection de ses clients. Cependant, peu de gens savent que, contrairement aux autres SGBD, MsSQL encapsule la poignée de main SSL dans TDS.

Ce procédé pourrait être fait délibérément pour réduire le nombre de menaces potentielles aux serveurs MS, car aujourd’hui, les fournisseurs utilisent le SSL dans une combinaison de couches simples du protocole comme une encapsulation complète. C’est plus simple et plus universel car l’activation ou désactivation du SSL n’affecte pas le protocole principal.

Le chiffrement dans MsSQL est effectué via deux modes : la protection du stade d’autorisation et la protection complète de la connexion. Dans les deux cas, le dialogue commence par un é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 dirige le premier paquet de poignée de main après l’avoir encapsulé dans TDS comme PRELOGIN. Tous les paquets SSL suivants sont encapsulés de la même manière dans TDS jusqu’à ce que la poignée de main soit complétée.

Cependant, le premier et tous les paquets d’application SSL 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 entre le client et le serveur n’est plus chiffré. Pendant le second mode, le chiffrement est mis en œuvre jusqu’à la fermeture de la session.

Il convient de noter que le serveur peut, en fait, fonctionner sans chiffrement, mais les clients officiels MSSQL ne fournissent pas cette option. Pourquoi est-ce important ? Le chiffrement dans le canal empêche par un moyen ou un autre la collecte passive de trafic et son analyse, c’est-à-dire le reniflement, ce qui représente l’une de nos fonctions principales.

En cas d’impossibilité de modifier le trafic, la fonctionnalité du renifleur est limitée. D’abord, cela se réfère aux 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échiffrer le trafic SSL, l’API OpenSSL de bas niveau doit être utilisée. Par conséquent, cela nous oblige à maintenir constamment à jour le renifleur SSL.

En même temps, le client doit installer une clé de serveur du côté du proxy (pare-feu). C’est un autre obstacle à la protection des données, car le client doit nous confier la protection du serveur ou ne pas utiliser le logiciel client officiel MsSQL (par exemple, Microsoft SQL Server Management Studio) en mode renifleur.

Quant aux 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 renifleur pour MsSQL Server est inclus dans le pare-feu. Nous avons fait tout notre possible pour que nos clients puissent l’utiliser facilement.

DataSunrise Database Security propose une solution de sécurité complète pour Microsoft SQL Server ou Azure SQL. DataSunrise inclut un pare-feu de base de données, une surveillance de l’activité des bases de données et audit, la découverte de données sensibles et 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 plus encore. Vous êtes invité à télécharger une version d’essai gratuite si vous souhaitez l’installer sur vos locaux. Si vous êtes un utilisateur de cloud et que vous exécutez votre base de données sur Amazon AWS ou Microsoft Azure, vous pouvez l’obtenir sur AWS market place ou Azure market place.