Inconvénients du chiffrement d'objet SQL Server 2005+?

Question

Pour une base de données livrée avec un produit déployé à distance, existe-t-il des inconvénients à chiffrer tous les objets de code (procs, fonctions, vues) via la clause WITH ENCRYPTION dans MS SQL Server 2005 et 2008?

Les avantages sont dissuasifs pour les changements «sur mesure» sur le terrain qui répondent à un besoin tout en en créant beaucoup plus. L'objectif n'est pas de protéger l'IP ou les données, mais de prévenir les changements de code non autorisés lorsque les droits de modifier les objets ne peuvent pas être gérés (la sécurité est hors des mains des développeurs, mais la responsabilité de résoudre les problèmes).

Quels nouveaux problèmes pourraient être causés par cette approche?

Answer 1

Microsoft a créé cette fonctionnalité spécifiquement à cette fin. Le seul inconvénient que je peux voir est que la protection est faible; il peut être contourné par des scripts disponibles publiquement et SQL Profiler peut être utilisé pour afficher le texte en clair des procédures décryptées. Mais il devrait encore agir comme un moyen de dissuasion efficace.

Answer 2

Nous avons implémenté le cryptage dans un produit d'entreprise que nous avons déployé sur plus de 200 sites pour les raisons que vous avez indiquées et pour dissuader l'ingénierie inverse.

Dans notre cas, c'était plus de problèmes que cela valait la peine. Nos clients n'ont jamais vraiment changé quoi que ce soit et il nous a été difficile de déboguer les problèmes sur le terrain. Profiler ne vous donne pas les détails nécessaires lorsque tout est chiffré. Nous aurions souvent à charger une version non chiffrée de nos SPROCs etc. pour déboguer des problèmes.

De plus, il est plus difficile de varier votre schéma en fonction de la version que vous attendez. La plupart des outils de différenciation ne peuvent pas différencier les objets chiffrés.

Answer 3

Vous êtes sur le mauvais chemin. WITH ENCRYPTION est une option obsolète des SQL 2000 jours. Les moyens de contourner sont bien connus et peuvent être découverts par quiconque avec minimal google search skills. La bonne façon est d'utiliser code signing. Le meilleur moyen est de créer un certificat, de signer les procédures, puis de supprimer la clé privée. De cette façon, personne, pas même vous, ne peut changer de code par la suite sans détruire les signatures. Cela n'empêche personne de modifier les procédures, mais une fois modifiées, elles détruisent le sceau de signature et la falsification est évidente. Vous pouvez aller plus loin et vous assurer que les procédures en elles-mêmes n'ont aucune autorité pour exécuter leur but (ie ne peut pas lire les tables auxquelles accéder) mais que l'autorité dérive de leurs signatures (le certificat utilisé pour les signer est accordé les droits nécessaires). De cette façon, s'ils altèrent le code, non seulement ils détruisent le sceau, mais ils provoquent également l'arrêt du système. Expliquer les conséquences de ces actions est généralement assez dissuasif.

Answer 4

Il existe de nombreux outils permettant de décrypter des procédures stockées dans SQL Server. Il existe un outil disponible dans le commerce, appelé SQL Shield, qui modifie le mécanisme de cryptage et rend beaucoup plus difficile la détection et la modification du code source. Cependant, je dois dire que les procédures de cryptage rendent la maintenance plus difficile: comparer, faire des diffs, etc.