Discussion :

[smuller]

Bonjour,

Pour répondre à un point d'audit, mon responsable me demande de faire le nécessaire pour chiffrer les connexions entre des clients applicatifs et leur base de données.

Je reste vraiment perplexe face à cette demande de l'auditeur car la base données ne contient aucunes données sensibles et les connexions client/serveur sont sur un LAN privé et maitrisé. Mais au-delà de ces considérations ce qui m'embête surtout, c'est que Microsoft informe que l'activation du chiffrement ralentit les performances sans donner d'ordre de grandeur.

Est-ce que l'un d'entre vous aurait un retour d'expérience sur cette problématique : mise ne place du chiffrement pour qui, pour répondre à quoi et quid des performances ? Si vous avez de la littérature à partager sur le sujet, je suis également preneur ;).

Merci par avance
Stéphane

[StringBuilder]

Le risque est certainement avant tout un problème de sniffing possible des login/pass

=> Si un user se conncete avec son mot de passe habituel sur SQL Server, alors une connexion non sécurisée à SQL Server peut permettre de trouver son mot de passe Windows ou d'accès à d'autres outils sensibles.

[smuller]

Même pas, j'ai effectivement oublié de préciser que l'authentification est du type "Windows Authentication" avec des groupes AD etc...

[StringBuilder]

Dans ce cas, effectivement, seuls les échanges de données sont non sécuriés... La mise ne place d'encryption ne me semble pas non plus vraiment critiques...

[DotNetMatt]

Pour les perfs SSL en général c'est négligeable, le principal impact étant le handshake qui doit être fait à la connexion. Après tout dépend des caractéristiques de ton environnement et de ce qui est fait sur la base... Le plus simple pour te faire une idée c'est de faire un test avec le même jeu de données, et de comparer avec et sans SSL pour un nombre de transactions X en Y minutes (throughput), le temps mis par l'application pour exécuter l'action, sa consommation de CPU, de mémoire, de bande passante, et les I/O disque...

Si tu considères l'impact trop important, une possibilité est de garder les connexions ouvertes plus longtemps ce qui aura pour effet de réduire le nombre de handshakes... Ceci peut avoir des impacts sur les applicatifs qui utilisent la base donc à voir si c'est une bonne solution ou non... A mon avis c'est une mauvaise idée de faire ca.

Sinon attention le fait d'utiliser la Windows Authentication ne met pas forcément à l'abri ! Il a été démontré un certain nombre de vulnérabilités liées à NTLM lors de la DEFCON 2013 il me semble. Il faut passer à Kerberos, malheureusement NTLM est encore activé par défaut dans un grand nombre de logiciels, et le passage à Kerberos n'est pas toujours facile...

[SQLpro]

...Microsoft informe que l'activation du chiffrement ralentit les performances ....

Pour le chiffrement des données oui ! Pour le chiffrement des connexions, c'est à peine mesurable !

A +

[mikedavem]

Le risque est certainement avant tout un problème de sniffing possible des login/pass

Il faut savoir que depuis SQL Server 2005 les phases d'authentification avec SQL Server (login de type SQL) sont toujours nativement chiffrées.

Pour les perfs SSL en général c'est négligeable, le principal impact étant le handshake qui doit être fait à la connexion

Ceci n'est pas tout à fait juste. Le handshake se fait au départ pour pouvoir établir ou non une connexion entre le client et le serveur. Une fois réussie, le travail de chiffrement est toujours là. En effet, la mise en place d'un canal sécurisé SSL entre SQL Server et le client concerne l'ensemble des paquets qui transitent entre les 2 protagonistes (heureusement d'ailleurs). Il y a effectivement un certain coût à la mise en place d'une telle fonctionnalité et cela varie avec les caractéristiques de ton architecture et ton workload principalement. La bonne démarche à mon sens est de comparer avant et après activation du chiffrement. Je commencerai par regarder 2 métriques significatives ici que sont le nombre de batchs et transactions / sec + utilisation CPU par SQL Server. Ne pas oublier que cela a aussi un impact côté client et de regarder également de ce côté.

Maintenant d'après ce que tu nous dis, si la criticité des données n'est pas importante, tu peux toujours challenger l'auditeur pour savoir pourquoi il préconise une telle solution. Il a bien du justifier cela dans son rapport je suppose.

++