Conséquences pour la sécurité de la restauration d'une sauvegarde à partir d'une source inconnue?

Scénario : vous recevez une sauvegarde de base de données et vous êtes invité à la restaurer sur un serveur (qui héberge déjà d'autres bases de données), mais vous ne recevez aucune information utile sur le contenu de la sauvegarde ou sur la fiabilité de la source.

Question 1 : Quelles sont les implications potentielles de la restauration d'une sauvegarde qui pourrait bien être malveillante?

Question 2 : Que pouvez-vous faire pour protéger votre serveur / les données d'autres bases de données de l'impact de la restauration d'une sauvegarde potentiellement malveillante? RESTORE VERIFYONLYsemble être une bonne première étape. La réponse ultime est probablement «restaurer la base de données dans une machine virtuelle sandbox sans accès au monde extérieur», mais supposons que cette option est hors de propos. Que faut-il faire d'autre dans cette situation?

Une base de données peut contenir du code malveillant, éventuellement une procédure qui va changer un mot de passe pour la connexion "sa" ou supprimer chaque base de données. Cependant, la seule façon dont je peux voir que provoquer un problème est pour un individu de restaurer la base de données, puis d'exécuter manuellement tout code dans cette base de données. Il ne s'exécuterait pas de manière automatisée.

Aucun paramètre ne peut être appliqué dans une base de données pour que SQL Server exécute automatiquement un peu de code dans la base de données lors de sa restauration sur un serveur. Si c'était le cas, je m'attendrais à ce que Microsoft perde la certification Common Criteria pour le produit. C'est trop un bug pour m'avoir permis dans un SGBD.

Vous pouvez effectuer certaines étapes de prévention.

1. Assurez-vous que personne sauf un administrateur système n'a accès à la base de données restaurée.
2. Mettez la base de données en mode mono-utilisateur une fois la restauration terminée.
3. Vérifiez le code dans toutes les procédures et fonctions stockées et les déclencheurs dans cette base de données.
4. Effectuez une vérification dbcc pour vous assurer qu'il n'y a aucun problème d'intégrité.
5. Vérifiez les utilisateurs qui avaient accès à la base de données et supprimez-les tous.
6. Commencez à autoriser l'accès, très limité à des objets spécifiques vérifiés par vous.

Comme l'a dit Shawn, le code ne s'exécutera pas de lui-même à moins qu'une procédure stockée qui semble vbalid ait un exécutable d'un autre code malveillant. C'est la raison de vérifier le code à l'intérieur de chacun d'eux avant de le mettre en mode multi-utilisateur.

J'arrive ici, mais je peux penser à au moins un scénario dangereux: si vous restaurez une base de données qui a un fichier , ces fichiers sont maintenant sur votre réseau par défaut (et plus précisément, sur votre serveur SQL). Vous pouvez restaurer un virus.

Cela ne fera rien en soi, bien sûr - le virus ne devient pas soudainement sensible - mais si vos utilisateurs tentent ensuite d'accéder au fichier, ils pourraient être infectés. (Hé, j'ai dit que j'atteignais.) J'imagine un scénario où un pirate extérieur veut avoir des logiciels malveillants dans la porte, et il envoie ensuite un e-mail à Bob en comptabilité en disant: "Voici le fichier: \ sqlserver \ filetableshare \ myvirus.exe "- à ce stade, il est passé votre pare-feu sans détection, et nous sommes maintenant à vos outils antivirus et anti-malware internes.

RESTORE VERIFYONLY semble être une bonne première étape. La réponse ultime est probablement «restaurer la base de données dans une machine virtuelle sandbox sans accès au monde extérieur», mais supposons que cette option est hors de propos. Que faut-il faire d'autre dans cette situation?

La restauration vérifie uniquement l' intégrité de la base de données, elle ne vous dira pas si la sauvegarde inclut un code malveillant ou non. RESTORE VERIFYONLY n'essaie pas de vérifier la structure des données contenues dans les volumes de sauvegarde. Il est très différent que si la sauvegarde vient de l'intérieur de l'entreprise où vous travaillez peut être malveillante, mais si elle provient d'un tiers, vous devez être prudent, comme l'a souligné Shawn.

La documentation de Microsoft Online indique que

• Pour des raisons de sécurité, nous vous recommandons de ne pas attacher ou restaurer des bases de données à partir de sources inconnues ou non fiables. Ces bases de données peuvent contenir du code malveillant qui pourrait exécuter du code Transact-SQL involontaire ou provoquer des erreurs en modifiant le schéma ou la structure de la base de données physique. Avant d'utiliser une base de données provenant d'une source inconnue ou non fiable, exécutez DBCC CHECKDB sur la base de données sur un serveur non productif et examinez également le code, tel que les procédures stockées ou tout autre code défini par l'utilisateur, dans la base de données.

La question se concentre principalement sur une sauvegarde contenant des logiciels malveillants, mais il est également possible d'obtenir un comportement indésirable et potentiellement malveillant de l'opération de restauration elle-même.

J'ai accidentellement découvert par le passé qu'il est possible de planter SQL Server en essayant de restaurer un fichier de sauvegarde corrompu qui fait que SQL Server essaie de lire après la fin du fichier de sauvegarde et se bloque. Je ne sais pas quelles versions sont susceptibles ou exactement ce qui est nécessaire pour reproduire le problème. J'ai documenté quelques détails limités ici lorsque j'ai rencontré ce problème il y a quelques années.

Quel risque y a-t-il à restaurer une base de données inconnue à partir d'une source inconnue? Aucun.

Quel risque y a-t-il à laisser une application inconnue se connecter à l'aide d'un compte sysadmin pour se connecter à cette base de données et commencer à exécuter du code? BEAUCOUP! Si le compte d'application n'a que des droits dans la base de données et aucun accès au niveau du serveur, il ne peut rien faire en dehors de la base de données. Cela revient essentiellement à avoir une configuration de cadre de sécurité appropriée sur le serveur pour commencer.

On vous remet une sauvegarde de base de données et on vous dit de la restaurer sur un serveur (qui héberge déjà d'autres bases de données), mais vous ne recevez aucune information utile sur ce que contient la sauvegarde ou si la source doit être approuvée.

Agréable. Vous exigez une déclaration écrite signée de la personne qui vous dit de le faire, qui accepte l'entière responsabilité des conséquences. S'ils ne veulent pas le faire, vous devriez tester l'installation dans un bac à sable après avoir examiné le fichier de sauvegarde (si possible), et examiner soigneusement toutes les tables, procédures, etc. Si quelque chose sent drôle à un moment donné, ne le mettez pas sur le système de production. Même dans ce cas, vous devez indiquer clairement (à votre patron et à ses supérieurs) que vous n'avez jamais fait confiance à la sauvegarde et que vous ne le faites que sur ordre direct.

S'ils ne signent pas une telle déclaration, prévenez leur (s) supérieur (s) avant de faire quoi que ce soit. En tant que professionnel, il est de votre devoir de protéger votre système autant que possible, peu importe ce qu'un supérieur intelligent peut vous ordonner de faire. Vous pourriez être viré, mais vous pouvez garder la tête haute et savoir que vous avez fait la bonne chose.

Il n'y a pas beaucoup de dangers à proprement parler, à part certains de grande portée suggérés ici. Comme cela a été mentionné, il est difficile d'avoir des éléments auto-exécutables dans une sauvegarde de base de données elle-même. Il a besoin d'une sorte de mécanisme de déclenchement extérieur.

Obtenez un ancien ordinateur portable / bureau et une version d'évaluation de votre logiciel de base de données (SQLExpress) si la licence pose problème. Copiez le fichier de sauvegarde sur la machine, débranchez le réseau / sans fil et effectuez la restauration. Commencez ensuite à creuser. Prenez tout le temps dont vous avez besoin, car il y a de nombreux endroits où les choses peuvent se cacher, la plupart déjà couvertes par d'autres articles de ce fil.

Votre intégrité DBA et le bien-être de votre environnement de production sont plus importants que toute commande donnée par un supérieur.