Sicherheitsaspekte bei der Wiederherstellung eines Backups von einer unbekannten Quelle?

Szenario : Sie erhalten ein Datenbank-Backup und werden aufgefordert, es auf einem Server wiederherzustellen (auf dem bereits andere Datenbanken gehostet werden). Sie erhalten jedoch keine nützlichen Informationen darüber, was das Backup enthält oder ob die Quelle als vertrauenswürdig eingestuft werden soll.

Frage 1 : Welche potenziellen Auswirkungen hat die Wiederherstellung eines Backups, das möglicherweise böswillig ist?

Frage 2 : Was können Sie tun, um Ihren Server / die Daten in anderen Datenbanken vor den Auswirkungen der Wiederherstellung eines potenziell böswilligen Backups zu schützen? RESTORE VERIFYONLYDas scheint ein guter erster Schritt zu sein. Die ultimative Antwort ist wahrscheinlich "Wiederherstellung der Datenbank in einer Sandbox-VM ohne Zugriff auf die Außenwelt", aber nehmen wir an, dass diese Option vom Tisch ist. Was sollte in dieser Situation noch getan werden?

Eine Datenbank kann schädlichen Code enthalten, möglicherweise eine Prozedur, die ein Kennwort für die Anmeldung "sa" ändert oder jede Datenbank löscht. Die einzige Möglichkeit, die ein Problem hervorruft, besteht darin, dass eine Person die Datenbank wiederherstellt und anschließend den Code in dieser Datenbank manuell ausführt. Es würde nicht in automatisierter Weise ausgeführt.

Es gibt keine Einstellung, die in einer Datenbank angewendet werden kann, damit SQL Server beim Wiederherstellen auf einem Server automatisch Code in der Datenbank ausführt. Andernfalls würde Microsoft die Common Criteria-Zertifizierung für das Produkt verlieren. Das ist zu groß für einen Bug, der mir in einem DBMS erlaubt hat.

Es gibt einige Präventionsschritte, die Sie durchführen können.

1. Stellen Sie sicher, dass nur ein Systemadministrator Zugriff auf die wiederhergestellte Datenbank hat.
2. Versetzen Sie die Datenbank nach Abschluss der Wiederherstellung in den Einzelbenutzermodus.
3. Überprüfen Sie den Code in allen gespeicherten Prozeduren und Funktionen und Triggern in dieser Datenbank.
4. Führen Sie eine dbcc-Prüfung durch, um sicherzustellen, dass keine Integritätsprobleme vorliegen.
5. Überprüfen Sie die Benutzer, die früher Zugriff auf die Datenbank hatten, und entfernen Sie alle.
6. Beginnen Sie, den Zugriff zuzulassen, der auf bestimmte von Ihnen überprüfte Objekte beschränkt ist.

Wie Shawn sagte, wird der Code nur dann von selbst ausgeführt, wenn eine gespeicherte Prozedur, die vbalid zu sein scheint, einen anderen bösartigen Code ausführt. Dies ist der Grund, warum Sie den Code in jedem von ihnen überprüfen müssen, bevor Sie ihn in den Mehrbenutzermodus versetzen.

Ich erreiche hier, aber ich kann mir mindestens ein gefährliches Szenario vorstellen : Wenn Sie eine Datenbank mit einer Dateitabelle wiederherstellen , befinden sich diese Dateien jetzt standardmäßig in Ihrem Netzwerk (und insbesondere auf Ihrem SQL Server). Sie könnten einen Virus wiederherstellen.

Das alleine macht natürlich nichts - der Virus wird nicht plötzlich empfindlich - aber wenn Ihre Benutzer dann versuchen, auf die Datei zuzugreifen, könnten sie infiziert werden. Ich stelle mir ein Szenario vor, in dem ein externer Hacker Malware in die Tür bekommen möchte. Anschließend sendet er eine E-Mail an Bob in der Buchhaltung mit den Worten: "Hier ist die Datei: \ sqlserver \ filetableshare \ myvirus.exe "- zu diesem Zeitpunkt ist es ohne Erkennung an Ihren Firewalls vorbei gegangen, und wir sind nun bei Ihren internen Antiviren- und Antischadsoftware-Tools angelangt.

RESTORE VERIFYONLY scheint ein guter erster Schritt zu sein. Die ultimative Antwort ist wahrscheinlich "Wiederherstellung der Datenbank in einer Sandbox-VM ohne Zugriff auf die Außenwelt", aber nehmen wir an, dass diese Option vom Tisch ist. Was sollte in dieser Situation noch getan werden?

Bei der Wiederherstellung wird nur die Integrität der Datenbank überprüft. Es wird NICHT angezeigt , ob die Sicherung einen schädlichen Code enthält. Bei der Wiederherstellung wird nicht versucht, die Struktur der in den Sicherungsdatenträgern enthaltenen Daten zu überprüfen. Es ist höchst unwahrscheinlich, dass Backups, die von der Firma stammen, in der Sie arbeiten, böswillig sein können. Wenn sie jedoch von Dritten stammen, müssen Sie vorsichtig sein, wie Shawn betonte.

Microsoft Online-Dokumentation sagt das

• Aus Sicherheitsgründen empfehlen wir, keine Datenbanken aus unbekannten oder nicht vertrauenswürdigen Quellen anzuhängen oder wiederherzustellen. Solche Datenbanken können schädlichen Code enthalten, der unbeabsichtigten Transact-SQL-Code ausführen oder Fehler verursachen kann, indem das Schema oder die physische Datenbankstruktur geändert werden. Bevor Sie eine Datenbank aus einer unbekannten oder nicht vertrauenswürdigen Quelle verwenden, führen Sie DBCC CHECKDB für die Datenbank auf einem Nichtproduktionsserver aus und überprüfen Sie den Code in der Datenbank, z. B. gespeicherte Prozeduren oder anderen benutzerdefinierten Code.

Die Frage konzentriert sich hauptsächlich auf ein Backup, das Malware enthält. Es ist jedoch auch möglich, dass der Wiederherstellungsvorgang selbst unerwünschtes und potenziell böswilliges Verhalten hervorruft.

Ich habe in der Vergangenheit versehentlich festgestellt, dass es möglich ist, SQL Server zum Absturz zu bringen, indem versucht wird, eine beschädigte Sicherungsdatei wiederherzustellen, wodurch SQL Server versucht, nach dem Ende der Sicherungsdatei zu lesen, und abstürzt. Ich bin nicht sicher, welche Versionen anfällig sind oder was genau erforderlich ist, um das Problem zu reproduzieren. Ich habe hier einige begrenzte Details dokumentiert , als ich vor einigen Jahren auf dieses Problem gestoßen bin.

Welches Risiko besteht bei der Wiederherstellung einer unbekannten Datenbank aus einer unbekannten Quelle? Keiner.

Welches Risiko besteht darin, dass eine unbekannte Anwendung über ein Sysadmin-Konto eine Verbindung zu dieser Datenbank herstellt und Code ausführt? VIELE! Wenn das Anwendungskonto nur Rechte in der Datenbank und keinen Zugriff auf Serverebene hat, kann es außerhalb der Datenbank nichts wirklich tun. Dies hängt im Wesentlichen davon ab, ob auf dem Server ein ordnungsgemäßes Sicherheitsframework eingerichtet ist.

Sie erhalten ein Datenbank-Backup und werden aufgefordert, es auf einem Server wiederherzustellen (auf dem bereits andere Datenbanken gehostet werden). Sie erhalten jedoch keine nützlichen Informationen darüber, was das Backup enthält oder ob die Quelle als vertrauenswürdig eingestuft werden soll.

Nett. Sie fordern eine unterschriebene schriftliche Erklärung von demjenigen, der Sie dazu auffordert, dass er die volle Verantwortung für die Folgen übernimmt. Wenn sie dazu nicht bereit sind, sollten Sie die Installation in einer Sandbox testen, nachdem Sie die Sicherungsdatei überprüft haben (falls möglich), und alle Tabellen, Prozeduren usw. gründlich untersuchen das Produktionssystem. Selbst dann sollten Sie (Ihrem Chef und seinen Vorgesetzten) klar machen, dass Sie der Sicherung nie vertraut haben und dies nur auf direkten Befehl hin tun.

Wenn sie eine solche Erklärung nicht unterzeichnen, benachrichtigen Sie ihren Vorgesetzten, bevor Sie etwas unternehmen. Als Fachmann ist es Ihre Pflicht, Ihr System so gut wie möglich zu schützen, unabhängig davon, was Ihnen ein düsterer Vorgesetzter befiehlt. Sie könnten gefeuert werden, aber Sie können Ihren Kopf hoch halten und wissen, dass Sie das Richtige getan haben.

Es gibt nicht viele Gefahren, außer den hier vorgeschlagenen weitreichenden. Wie bereits erwähnt, ist es schwierig, automatisch auszuführende Elemente in einer Datenbanksicherung selbst zu haben. Es braucht eine Art äußeren Auslösemechanismus.

Besorgen Sie sich einen alten Laptop / Desktop und eine Evaluierungsversion Ihrer Datenbanksoftware (SQLExpress), wenn Lizenzierungsprobleme auftreten. Kopieren Sie die Sicherungsdatei auf den Computer, trennen Sie das Netzwerk / WLAN und führen Sie die Wiederherstellung durch. Dann anfangen zu graben. Nehmen Sie sich die Zeit, die Sie brauchen, denn es gibt viele Orte, an denen sich Dinge verstecken können, die meisten davon bereits von anderen Posts in diesem Thread abgedeckt.

Ihre DBA-Integrität und das Wohl Ihrer Produktionsumgebung sind wichtiger als jeder Auftrag, den ein Vorgesetzter erteilt.