Microsoft SQL Server absichern: Datenbank-Sicherheitslücken schließen

Die US-Cybersicherheitsbehörde CISA warnt derzeit vor aktiv ausgenutzten Sicherheitslücken in mehreren weit verbreiteten Plattformen – darunter Red Hat, Gitea und Microsoft SQL Server. Für viele KMU klingt das zunächst nach einem Problem großer Rechenzentren. Tatsächlich läuft aber in einem erheblichen Teil ostdeutscher Mittelständler mindestens ein SQL-Server-Instanz im Hintergrund – für die Warenwirtschaft, die Buchhaltungssoftware oder ein selbst entwickeltes Kundenportal. Und genau diese Instanzen sind oft seit Jahren nicht mehr angefasst worden.

Warum Microsoft SQL Server ein attraktives Angriffsziel ist

Ein Datenbank-Server ist für Angreifer besonders lohnend, weil er selten isoliert betrieben wird. Er speichert in der Regel genau die Daten, die für ein Unternehmen am wertvollsten sind: Kundendaten, Bestellhistorien, Finanzbuchungen, mitunter auch Zugangsdaten anderer Systeme. Wer Zugriff auf den SQL Server bekommt, hat oft direkten Zugriff auf den Kern des Geschäftsbetriebs – ganz ohne den Umweg über einzelne Arbeitsplatzrechner.

Gleichzeitig geraten SQL-Server-Instanzen in vielen KMU zwischen die Zuständigkeiten. Die Anwendung, die auf der Datenbank aufsetzt, wird vom Softwarehersteller gepflegt. Der Server selbst gehört formal zur IT-Abteilung oder zum externen Dienstleister. In der Praxis kümmert sich dann mitunter niemand konsequent um Patches, Konfiguration und Zugriffsrechte der Datenbank-Engine – solange die Anwendung läuft, wird nicht angefasst.

Typische Schwachstellen in der Praxis

• Veraltete SQL-Server-Versionen: Ältere, nicht mehr unterstützte Versionen erhalten keine Sicherheitsupdates mehr, laufen aber häufig weiter, weil eine Migration als Risiko für die Fachanwendung gilt.
• Offener Port 1433 ohne Einschränkung: Der Standard-Port des SQL Servers ist teils direkt aus dem Internet erreichbar, etwa für Fernzugriffe von Software-Anbietern, ohne dass der Zugriff auf bestimmte IP-Bereiche beschränkt wurde.
• Schwache oder gemeinsam genutzte SA-Konten: Das integrierte Administrator-Konto “sa” wird mit einfachen oder unternehmensweit bekannten Passwörtern betrieben, teils sogar über mehrere Systeme hinweg identisch.
• Übermäßige Rechte für Anwendungs-Accounts: Der Datenbank-Benutzer der Fachanwendung besitzt oft weit mehr Rechte als notwendig, etwa vollen Administratorzugriff statt nur Lese- und Schreibrechte auf die tatsächlich benötigten Tabellen.
• Aktivierte, aber ungenutzte Funktionen: Features wie xp_cmdshell, mit denen sich vom SQL Server aus Betriebssystembefehle ausführen lassen, bleiben aktiviert, obwohl sie nie gebraucht werden – ein beliebter Hebel für Angreifer, um von der Datenbank aus auf das gesamte System zuzugreifen.

Was KMU konkret tun können

1. Bestandsaufnahme aller Datenbank-Server

Der erste Schritt ist oft der aufschlussreichste: eine vollständige Liste aller im Unternehmen laufenden SQL-Server-Instanzen, inklusive Version, Patch-Stand und Verantwortlichkeit. In der Praxis taucht dabei regelmäßig mindestens ein vergessener Server auf, der ursprünglich für ein Testsystem oder eine mittlerweile abgelöste Software eingerichtet wurde.

2. Patch-Management konsequent umsetzen

Microsoft veröffentlicht regelmäßig Sicherheitsupdates für den SQL Server. Diese sollten – nach Test in einer Staging-Umgebung – zeitnah eingespielt werden, statt Monate oder Jahre liegen zu bleiben. Für unterstützte Versionen ist das in der Regel unkritisch; wer noch mit End-of-Life-Versionen arbeitet, sollte eine Migration priorisieren, statt auf ungepatchte Sicherheitslücken zu vertrauen.

3. Netzwerkzugriff auf das Nötigste beschränken

Ein SQL Server sollte niemals direkt aus dem Internet erreichbar sein. Der Zugriff auf Port 1433 gehört in ein internes Netzwerksegment, abgesichert durch eine Firewall wie OPNsense, und für Fernzugriffe – etwa von Software-Dienstleistern – ausschließlich über eine gesicherte VPN-Verbindung statt über eine offene Port-Weiterleitung.

4. Rechte konsequent nach dem Least-Privilege-Prinzip vergeben

Anwendungs-Accounts sollten exakt die Rechte erhalten, die sie für ihre Funktion benötigen – nicht mehr. Das integrierte “sa”-Konto sollte, wo möglich, deaktiviert oder zumindest mit einem starken, einzigartigen Passwort und Multi-Faktor-Absicherung auf der Zugriffsebene versehen werden.

5. Unnötige Funktionen deaktivieren

Features wie xp_cmdshell, verlinkte Server oder ungenutzte Netzwerkprotokolle sollten deaktiviert werden, wenn sie nicht aktiv gebraucht werden. Jede aktivierte, aber ungenutzte Funktion vergrößert die Angriffsfläche ohne Mehrwert.

6. Protokollierung und Monitoring einrichten

Fehlgeschlagene Anmeldeversuche, ungewöhnliche Abfragen oder Zugriffe außerhalb der Geschäftszeiten sollten protokolliert und im Idealfall überwacht werden. Ohne Logging bleibt ein Angriff auf die Datenbank oft monatelang unentdeckt.

Praxis: Schritt-für-Schritt-Absicherung

1. Inventar erstellen: Alle SQL-Server-Instanzen im Unternehmen erfassen, inklusive Version und Verantwortlichkeit.
2. Patch-Stand prüfen: Für jede Instanz den aktuellen Support-Status und offene Sicherheitsupdates ermitteln.
3. Netzwerksegmentierung umsetzen: Datenbank-Server hinter die Firewall in ein separates Netzwerksegment legen, keine direkte Internet-Erreichbarkeit zulassen.
4. Zugriffsrechte bereinigen: Konten und Berechtigungen auf das tatsächlich benötigte Minimum reduzieren, das sa-Konto absichern oder deaktivieren.
5. Unnötige Features abschalten: xp_cmdshell und ähnliche Funktionen deaktivieren, sofern nicht zwingend erforderlich.
6. Monitoring aufbauen: Anmeldeversuche und kritische Abfragen protokollieren und regelmäßig auswerten.

Rexoma unterstützt KMU in Dresden bei der Datenbanksicherheit

Sie wissen nicht genau, welche SQL-Server-Instanzen in Ihrem Unternehmen laufen oder auf welchem Patch-Stand sie sich befinden? Rexoma unterstützt KMU in Dresden, Sachsen und im gesamten ostdeutschen Raum bei der Absicherung von Datenbank-Servern – von der Bestandsaufnahme über Netzwerksegmentierung bis zum laufenden Patch-Management.

Häufige Fragen zu SQL-Server-Sicherheit

Ist die kostenlose Express-Edition von SQL Server genauso betroffen? Ja. Die Sicherheitslücken betreffen die Datenbank-Engine unabhängig von der Lizenz-Edition. Auch kostenlose Express-Installationen, die häufig für kleinere Fachanwendungen genutzt werden, benötigen dieselben Patches und dieselbe Härtung.

Reicht eine Firewall vor dem Server als Schutz aus? Eine Firewall ist eine wichtige Basis, ersetzt aber keine Härtung der Datenbank selbst. Interne Bedrohungen, kompromittierte Anwendungs-Accounts oder seitliche Bewegung nach einem erfolgreichen Angriff auf ein anderes System lassen sich damit allein nicht verhindern.

Wie oft sollte der Patch-Stand geprüft werden? Sicherheitsupdates für SQL Server sollten mindestens monatlich geprüft und zeitnah nach Veröffentlichung eingespielt werden, kritische Lücken idealerweise innerhalb weniger Tage nach Test in einer Staging-Umgebung.

Was tun, wenn die Fachanwendung eine veraltete SQL-Server-Version voraussetzt? In solchen Fällen sollte mit dem Softwarehersteller geklärt werden, ob eine neuere Version unterstützt wird. Ist das nicht möglich, sollte die Instanz zusätzlich durch strikte Netzwerksegmentierung und minimale Zugriffsrechte abgesichert werden, um das Restrisiko zu begrenzen.

Betrifft das Thema auch MySQL oder MariaDB? Die grundlegenden Prinzipien – Patch-Management, Netzwerksegmentierung, Least-Privilege-Rechte, Deaktivierung ungenutzter Funktionen – gelten für alle relationalen Datenbanksysteme, auch wenn sich die konkreten Konfigurationsschritte unterscheiden.