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.
(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.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
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.