Datenbanksicherheit 5 Methoden zum Sichern von SQL-Server-Datenbanken

Von Thomas LaRock |

Anbieter zum Thema

Es vergeht kaum ein Tag, an dem keine Informationen über einen neuen Cyberangriff oder eine Datensicherheitspanne die Runde machen. „YADB“ (Yet Another Data Breach) ist zum Hashtag und Schlagwort geworden.

Jede Datenbank ist anfällig für Sicherheitsvorfälle. Dabei ist keine Plattform stärker gefährdet als andere. Dieser Artikel konzentriert sich auf SQL-Server, doch die Informationen gelten für die verschiedensten Plattformen.
Jede Datenbank ist anfällig für Sicherheitsvorfälle. Dabei ist keine Plattform stärker gefährdet als andere. Dieser Artikel konzentriert sich auf SQL-Server, doch die Informationen gelten für die verschiedensten Plattformen.
(Bild: yurich84 - stock.adobe.com)

Die Gründe für Sicherheitsverletzungen und Datendiebstahl sind vielfältig. Mal hat jemand einen Laptop im Bus vergessen, mal ist eine öffentlich zugängliche Website nicht vor Angriffen durch Einschleusung von SQL-Befehlen geschützt. Doch wir sollten es den Hackern nicht zu leicht machen. Mit den folgenden Maßnahmen können wir unsere Daten und Datenbankserver besser schützen und das Risiko einer Datensicherheitsverletzung reduzieren.

Monitoring-Konfiguration

Der allererste Punkt auf jeder Sicherheitscheckliste besteht darin, das Monitoring zu konfigurieren. In der Vergangenheit war das Monitoring von Datenbankservern auf die Leistungsüberwachung beschränkt. Heutzutage braucht man mehr. Auch die Sicherheit muss überwacht werden. Das einfachste und am häufigsten genutzte Sicherheits-Monitoring besteht darin, fehlgeschlagene Anmeldeversuche im Blick zu behalten. Zudem sollte man Konfigurationsänderungen auf Datenbankebene, in Serverinstanzen und im Serverbetriebssystem überwachen. Die Konfiguration sollte die Überwachung von Kennwortänderungen, Änderungen der Serverrollen- und Datenbankrollenmitgliedschaft sowie Schemaänderungen umfassen.

Softwareinstallation

Bei der Installation von SQL-Server sollte man keine unnötigen Funktionen installieren. In anderen Worten: Installieren Sie Reporting Services nicht „für den Fall der Fälle“, weil es ja irgendwann mal jemand nutzen könnte. Jede Software und zusätzliche Komponente von SQL-Server, die man installieren, muss verwaltet und regelmäßig gepatcht werden. Das bedeutet: Jede auf dem Server installierte Software ist ein zusätzliches Sicherheitsrisiko. Außerdem muss nicht für jede Instanz SQL-Server Management Studio installiert sein. Es wird kaum je vorkommen, dass man selbst oder ein Entwickler per RDP auf einen Server zugreifen. Und selbst dann sollte man überlegen, stattdessen einen Jump Host zu nutzen.

Zugriffssteuerung

Der Zugriff auf den Datenbankserver sollte den Personen vorbehalten sein, die ihn wirklich benötigen, und auf die spezifischen Aktionen beschränkt werden, die sie für ihre Aufgaben benötigen. Idealerweise wird nur die Windows-Authentifizierung zusammen mit Active Directory (AD)-Gruppen verwendet. Dies beschränkt die Zahl der einzelnen, manuell erstellten Windows-Benutzeranmeldedaten. Ein weiterer Grund, das Erstellen von Windows-Benutzeranmeldedaten zu vermeiden, ist die Bereinigung: Wenn die entsprechenden Personen das Unternehmen verlassen, müssen die Anmeldedaten manuell entfernt werden. Wenn man AD-Gruppen nutzt, muss man nicht mehr vorhandene Benutzer nicht manuell entfernen.

Sicherheitsrelevante Aufgaben sollten von einem speziellen Sicherheitsteam übernommen werden, das für die Zuweisung von Windows-Benutzern zu AD-Gruppen verantwortlich ist. Der Datenbankadministrator ist anschließend dafür zuständig, Berechtigungen auf Datenbankebene für diese AD-Gruppenanmeldedaten zuzuweisen. Wenn die SQL-Authentifizierung erforderlich ist, deaktiviert man das „sa“-Konto oder benennt es um.

Schutz vor Einschleusung von SQL-Befehlen

Die Einschleusung von SQL-Befehlen ist eine häufige Form des Datendiebstahls, meist durch Webangriffe. Dabei ist es durchaus möglich, Angriffe durch Einschleusung von SQL-Befehlen zu erkennen und zu verhindern. Regelmäßige Penetrationstests mit Tools wie sqlmap können verdächtigen Code erkennen. Wenn der Webserver so konfiguriert ist, dass alle Anfragen protokolliert werden, können die Protokolle auf Hinweise auf eine Abfrage zur Einschleusung von SQL-Befehlen durchsucht werden. Eine Einschleusung von SQL-Befehlen kann man auch erkennen, wenn ein Angreifer Änderungen am Schema vorgenommen hat, beispielsweise durch das Entfernen einer Tabelle.

Die Einschleusung von SQL-Befehlen zu verhindern ist nicht schwer. Anstelle der Nutzung von dynamischem SQL sollte man gespeicherte Prozeduren oder vorbereitete Anweisungen verwenden und darauf achten, alle Eingaben zu bereinigen. Es sollte verhindert werden, dass Fehlermeldungen an einen Client zurückgegeben werden, da sie den Angreifern zusätzliche Informationen über das eigene System liefern könnten. Eine weitere bewährte Methode besteht darin, die EXECUTE AS-Funktion innerhalb von SQL-Server zu nutzen, um Anweisungen mit einem Konto mit niedrigeren Berechtigungen auszuführen.

Zuletzt: Die Verwendung erweiterter gespeicherter Prozeduren, die Angreifer mittels Einschleusung von SQL-Befehlen ausführen könnte, sollte man entfernen oder deaktivieren.

Backups sichern

Der letzte Schritt besteht im Sichern der Backups. Ohne ein gutes Backup wird die Wiederherstellung nach einem Sicherheitsvorfall schwierig. Für Backups gilt die 3-2-1-1-Regel: Drei Sicherheitskopien auf zwei verschiedenen Medientypen, von denen einer unveränderlich ist und der andere extern aufbewahrt wird. Der Wiederherstellungsprozess sollte häufig getestet werden. Ein Backup allein ist nutzlos, wenn es nicht wiederhergestellt werden kann. Die Datenbanksicherungen vorheriger Sicherungen sollte man nicht überschreiben. Sonst hat man kein funktionierendes Backup mehr, wenn die aktuelle Sicherung fehlschlägt. Diese Situation sollte unbedingt vermieden werden.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Außerdem sollte die Nutzung von Transparent Data Encryption (TDE) in Betracht gezogen werden: So werden nicht nur die Datenbankdateien, sondern auch die Datenbanksicherungen geschützt. Sicherungen können sowohl komprimieren als auch verschlüsselt werden, während TDE aktiviert ist. Dabei braucht man nicht zwangsläufig alle drei, aber man sollte überlegen, die Komprimierung auf die eine oder andere Weise mit der Verschlüsselung zu kombinieren.

Fazit

Daten sind das wertvollste Gut eines jeden Unternehmens. Jede Datenbank ist anfällig für Sicherheitsvorfälle. Dabei ist keine Plattform stärker gefährdet als andere. Dieser Artikel konzentriert sich auf SQL-Server, doch die Informationen gelten für die verschiedensten Plattformen. Die Sicherheit ist eine geteilte Verantwortung. Als Datenprofi sollte man dafür sorgen, den Datenbankserver zu sichern und das Risiko von Datenverlusten zu reduzieren.

Über den Autor: Thomas LaRock ist Head Geek bei SolarWinds.

(ID:48202186)