DORA gilt nicht für uns. Warum wir unseren SQL Server trotzdem härten sollten

Von /

Montagmorgen, IT-Runde. Die Frage kommt nebenbei: „Das Backup vom SQL Server läuft doch, oder?“ Alle nicken. Der Kollege, der den Server damals eingerichtet hat, ist längst nicht mehr im Haus. Ob sich das Backup zurückspielen lässt, hat seitdem niemand ausprobiert.

Viele SQL Server im Mittelstand sind nicht kaputt. Sie sind verwaist. Sie laufen, also fasst sie keiner an. Die Branchensoftware meldet sich als sa an, die halbe Domäne ist sysadmin, und die Version ist so alt wie das Firmenlogo. Wer seinen SQL Server härten will, braucht dafür kein neues Gesetz. Eine gute Vorlage gibt es trotzdem, und sie kommt aus der Finanzbranche: DORA.

Was DORA ist und warum Banken ihre IT jetzt beweisen müssen

DORA (Digital Operational Resilience Act) ist die EU-Verordnung 2022/2554. Sie verpflichtet Banken, Versicherungen und andere Finanzunternehmen seit dem 17. Januar 2025, ihre IT gegen Ausfälle und Angriffe abzusichern und das regelmäßig nachzuweisen. In Deutschland überwacht das die BaFin.

DORA ruht auf fünf Säulen:

  • IKT-Risikomanagement: Systeme kennen, Risiken bewerten, Schutzmaßnahmen festlegen.
  • Vorfallmeldung: Schwere IT-Vorfälle erkennen, einstufen und fristgerecht an die Aufsicht melden.
  • Resilienztests: Regelmäßig prüfen, ob die Schutzmaßnahmen tatsächlich wirken.
  • Drittanbieterrisiko: Dienstleister vertraglich in die Pflicht nehmen und überwachen.
  • Informationsaustausch: Wissen über Bedrohungen mit anderen teilen.

DORA erfindet keine neue IT-Sicherheit. DORA verlangt, dass man sie beweisen kann.

Genau dieser Unterschied zwischen „wir machen das“ und „wir können es belegen“ ist für den Mittelstand interessant.

Für wen DORA gilt und wie es trotzdem im Mittelstand ankommt

Der Maschinenbauer in Ostholstein fällt nicht unter DORA. Das Autohaus auch nicht, der Großhändler ebenso wenig. DORA gilt für Finanzunternehmen und reicht über sie hinaus nur an deren IT-Dienstleister weiter. Wer als Softwarehaus oder Rechenzentrum für eine Versicherung arbeitet, bekommt Prüfrechte, Sicherheitsvorgaben und Meldepflichten in den Vertrag geschrieben.

Die gleiche Mechanik kennt das NIS2-Gesetz. Unternehmen, die darunter fallen, müssen auch die Sicherheit ihrer Lieferkette im Blick haben. Zu den zehn Pflichtbereichen des Risikomanagements gehören unter anderem Backup-Management, Lieferkettensicherheit und Multifaktor-Authentifizierung. Pflichten wandern die Lieferkette hinunter. Meist als Fragebogen, manchmal als Vertragsklausel.

Sechs DORA-Prinzipien, mit denen du deinen SQL Server härten kannst

DORA nennt keine einzige SQL-Server-Einstellung. Übersetzt ins Datenbank-Handwerk bleiben aber sechs Fragen, die jede IT-Leitung beantworten können sollte.

1. Inventar: Welche SQL Server laufen überhaupt?

DORA verlangt ein vollständiges Verzeichnis der IT-Systeme. Im Mittelstand fehlt das fast immer für Datenbanken. SQL Server Express steckt in Branchensoftware, in der Zeiterfassung, auf dem Rechner in der Konstruktion. Niemand hat sie bewusst installiert, also patcht sie auch niemand.

Die Version zählt. Der Support für SQL Server 2016 endete am 14. Juli 2026, Extended Security Updates gibt es bis zum 17. Juli 2029. Diese Verlängerung ist teuer: Laut Brent Ozar kostet das erste Jahr 75 Prozent des ursprünglichen Lizenzpreises, das zweite 150 und das dritte 300 Prozent. SQL Server 2014 und älter sind ohnehin schon aus dem Support.

Der gefährlichste SQL Server im Haus ist der, von dem die IT-Leitung nichts weiß.

2. Zugriffe: Wer darf alles, und warum?

DORA fordert das Prinzip der geringsten Rechte und regelmäßige Überprüfung. Auf SQL Servern im Mittelstand sieht die Wirklichkeit anders aus. Anwendungen melden sich mit sa an. Eine Domänengruppe mit 40 Mitgliedern hat sysadmin-Rechte, weil es damals schnell gehen musste. SQL-Logins haben keine Kennwortrichtlinie.

sysadmin ist keine Berechtigung, sondern ein Generalschlüssel. Ein sinnvoller Rhythmus: einmal im Jahr die Liste aller privilegierten Konten mit den Fachabteilungen durchgehen und jeden Eintrag begründen lassen. Was keiner begründen kann, fliegt raus.

3. Backup mit Restore-Beweis

DORA verlangt nicht nur Backups, sondern getestete Wiederherstellung. Das ist der wichtigste Punkt für den Mittelstand. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung.

Zwei Zahlen gehören dazu, und die legt nicht die IT fest, sondern die Geschäftsführung. Wie viele Stunden Datenverlust sind verkraftbar (RPO)? Wie lange darf die Warenwirtschaft stehen (RTO)? Erst mit diesen Zahlen lässt sich ein Backup-Konzept prüfen. Dazu kommt eine Kopie, die ein Angreifer mit Domänen-Admin-Rechten nicht löschen kann. Ransomware sucht zuerst die Backups.

Der folgende PowerShell-Befehl aus dbatools spielt die letzten Backups einer Instanz auf einem Testserver zurück, prüft sie mit DBCC CHECKDB und legt das Ergebnis als Nachweis ab:

# Letzte Backups auf Testserver zurückspielen, mit DBCC CHECKDB prüfen, Ergebnis als Nachweis sichern
Test-DbaLastBackup -SqlInstance SQL01 -Destination SQLTEST01 |
    Select-Object SourceServer, Database, RestoreResult, DbccResult |
    Export-Csv -Path "\\fileserver\it-nachweise\restoretest_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation -Encoding UTF8

Der entscheidende Punkt ist die CSV-Datei am Ende. Sie macht aus einem Test einen Nachweis, den du der Geschäftsführung, dem Wirtschaftsprüfer oder dem Cyberversicherer vorlegen kannst.

4. Patchen und Angriffsfläche verkleinern

Jede Funktion, die aktiv ist, aber nicht gebraucht wird, ist eine offene Tür. Typische Kandidaten auf gewachsenen SQL Servern sind xp_cmdshell, CLR-Integration und OLE Automation. Oft hat sie eine Installationsanleitung vor zehn Jahren eingeschaltet, und keiner weiß mehr, warum.

Dazu gehören aktuelle Cumulative Updates, verschlüsselte Verbindungen und verschlüsselte Backups, sobald Sicherungen das Haus verlassen. Ein veralteter Patchstand ist selten eine technische Frage. Meist fehlt nur ein fester Termin.

5. Protokollieren und Vorfälle erkennen

DORA verlangt, schwere Vorfälle schnell zu erkennen und zu melden. Dafür muss man sie erst einmal sehen. SQL Server bringt mit SQL Server Audit alles Nötige mit: fehlgeschlagene Anmeldungen, Rechteänderungen, neue Logins. Die Protokolle gehören auf ein anderes System als den Server selbst. Sonst löscht der Angreifer seine Spuren gleich mit.

Wer Angriffe erst an der Lösegeldforderung erkennt, hat kein Monitoring. Genauso wichtig ist ein einseitiger Vorfallplan: Wer wird angerufen, wer entscheidet über das Abschalten, wer meldet an wen?

6. Prüfroutine statt Aufräumaktion

Der Kern von DORA sind regelmäßige, dokumentierte Tests. Das ist der Teil, den der Mittelstand am leichtesten übernehmen kann. Eine einmalige Aufräumaktion verfällt nach zwei Jahren wieder. Eine monatliche Prüfroutine mit abgelegten Ergebnissen und einem kurzen Quartalsgespräch mit der Geschäftsführung hält den Zustand.

Härtung ist kein Projekt. Härtung ist ein Termin im Kalender.

Welche Tools beim SQL Server Härten helfen

Aus meiner Praxis im norddeutschen Mittelstand zeigt sich: Für die ersten 80 Prozent brauchst du kein kostenpflichtiges Sicherheitsprodukt. Die folgenden Werkzeuge sind kostenlos und in der SQL-Server-Welt seit Jahren etabliert.

  • dbatools: Ein freies PowerShell-Modul mit mehreren hundert Befehlen für SQL-Server-Verwaltung. Für die sechs Prinzipien sind vor allem Find-DbaInstance (Inventar), Test-DbaBuild (Patchstand), Get-DbaServerRoleMember und Get-DbaLogin (Rechte), Test-DbaLastBackup und Get-DbaLastGoodCheckDb (Backups und Integrität) sowie Get-DbaSpConfigure (Angriffsfläche) nützlich.
  • dbachecks: Baut auf dbatools auf und prüft Instanzen gegen eine konfigurierbare Checkliste. Das Ergebnis ist ein wiederholbarer Prüfbericht statt einer Sammlung einzelner Skripte.
  • Ola Hallengren Maintenance Solution: Der Quasi-Standard für Backup-, Integritäts- und Indexjobs. dbatools installiert sie mit Install-DbaMaintenanceSolution.
  • sp_Blitz aus dem First Responder Kit: Eine Prozedur von Brent Ozar, die eine priorisierte Liste von Problemen ausgibt. Gut für den ersten Blick auf einen unbekannten Server.
  • CIS Benchmark für SQL Server: Kein Tool, sondern eine frei verfügbare Soll-Liste mit konkreten Einstellungen. Nützlich als Maßstab, gegen den die Prüfroutine läuft.
  • SQL Server Audit: Ist in SQL Server eingebaut und deckt die Protokollierung aus Prinzip fünf ab, ohne Zusatzsoftware.

Tools liefern Befunde, keine Entscheidungen. Ob die Branchensoftware ihre sysadmin-Rechte wirklich braucht, klärt kein PowerShell-Befehl, sondern ein Anruf beim Hersteller.

Welche Gesetze den Mittelstand trotzdem zur IT-Sicherheit verpflichten

DORA betrifft deinen Betrieb vermutlich nicht. Pflichtfrei ist der Mittelstand deshalb nicht. Diese Regelwerke fragen im Kern dasselbe, nur weniger freundlich (keine Rechtsberatung, bitte im Einzelfall prüfen lassen):

  • NIS2 (BSI-Gesetz): Das Umsetzungsgesetz betrifft rund 29.500 Unternehmen in 18 Sektoren. Es richtet sich grundsätzlich an Unternehmen ab 50 Beschäftigten oder mit mehr als 10 Millionen Euro Jahresumsatz und Bilanzsumme in den regulierten Sektoren. Dazu zählen auch Teile des verarbeitenden Gewerbes wie Fahrzeuge, Elektronik und Medizinprodukte sowie Lebensmittelproduktion und Chemie. Die Geschäftsleitung haftet nach § 38 BSIG persönlich für die Einhaltung. Erhebliche Vorfälle sind binnen 24 Stunden erstmals und binnen 72 Stunden ausführlicher zu melden.
  • DSGVO Artikel 32: Wer personenbezogene Daten verarbeitet, muss Sicherheit nach dem Stand der Technik gewährleisten. Artikel 32 verlangt ausdrücklich ein Verfahren zur regelmäßigen Überprüfung der Maßnahmen. Das ist die Prüfroutine aus Prinzip sechs, nur im Juristendeutsch. Datenpannen sind nach Artikel 33 in der Regel binnen 72 Stunden zu melden.
  • GoBD und § 147 AO: Buchhaltungsrelevante Daten müssen über die Aufbewahrungsfrist unverändert und für die Betriebsprüfung lesbar bleiben. Ein SQL Server ohne funktionierende Wiederherstellung ist deshalb auch ein steuerliches Risiko.
  • Haftung der Geschäftsführung: Nach § 43 GmbHG haftet der Geschäftsführer für die Sorgfalt eines ordentlichen Geschäftsmanns. § 1 StaRUG verlangt, bestandsgefährdende Entwicklungen früh zu erkennen. Ein wochenlanger Datenbankausfall kann genau das sein.
  • Cyber Resilience Act: Betrifft Hersteller vernetzter Produkte, also auch Maschinenbauer mit Steuerungssoftware. Seit dem 11. September 2026 gilt für sie die Meldepflicht für Schwachstellen und Vorfälle.
  • Verträge: Cyberversicherer fragen vor dem Abschluss nach Backups, Patchstand und Multifaktor-Anmeldung. Großkunden schicken Sicherheitsfragebögen, in der Automobilzulieferung oft verbunden mit TISAX. Diese Fragen kommen schneller als jede Aufsichtsbehörde.

Wo dieser Ansatz an Grenzen stößt

Die sechs Prinzipien härten die Datenbank, nicht das Unternehmen. Ein sauber konfigurierter SQL Server hilft wenig, wenn das Active Directory offen steht oder die Firewall alles durchlässt. Datenbank-Härtung ersetzt kein Informationssicherheits-Managementsystem, wie es NIS2-pflichtige Unternehmen brauchen.

Die zweite Grenze ist die Branchensoftware. Manche Hersteller verlangen sysadmin-Rechte oder zertifizieren nur alte SQL-Server-Versionen. Dann bleibt nur, das Risiko zu dokumentieren, den Server abzuschotten und mit dem Hersteller zu verhandeln. Die dritte Grenze: dbatools setzt PowerShell-Grundwissen voraus. Ohne jemanden, der die Befunde liest und handelt, erzeugt jede Prüfroutine nur schön formatierte Ablage.

Was das für die Geschäftsführung bedeutet

Für die Geschäftsführung heißt SQL Server härten vor allem: drei Entscheidungen treffen, die bisher niemand getroffen hat. Wie viel Datenverlust ist verkraftbar? Wie lange darf das System stehen? Wer prüft das regelmäßig und berichtet darüber? Die Technik dahinter ist überschaubar. Die erste Bestandsaufnahme mit den genannten Werkzeugen dauert meist Stunden, nicht Wochen. Ein Ausfall der Warenwirtschaft ohne funktionierendes Backup dauert dagegen so lange, bis jemand die Daten von Hand neu erfasst hat. Und eine nachweisbare Prüfroutine ist das beste Argument im Gespräch mit Versicherer, Wirtschaftsprüfer und Großkunden.

Wer seinen SQL Server einmal nach diesen sechs Prinzipien durchsehen lassen möchte, erreicht mich über sesoft.de/kostenloses-erstgespraech-sichern.

Quellen

Über den Autor

Sönke Schäfer ist Datenarchitekt und IT-Berater aus Sierksdorf in Ostholstein. Seit über 25 Jahren arbeitet er mit SQL Server und Microsoft Access im norddeutschen Mittelstand. Sein Schwerpunkt liegt auf gewachsenen Datenbank-Umgebungen ohne Dokumentation: Bestandsaufnahme, Härtung, Migration auf unterstützte Versionen und Prüfroutinen, die auch nach dem Projekt weiterlaufen.

Ähnliche Beiträge

Nach oben scrollen