Patchen oder Patchwork?
Du kennst das:
„Läuft doch.“
„Keine Zeit für Neustart.“
„Wir patchen im nächsten Quartal.“
Und dann steht der SQL Server mit offener Sicherheitslücke im Netz.
Kein Witz.
Kein Luxusproblem.
Ein ungepatchter SQL Server ist wie eine offene Tür bei Sturmflut.
Warum es kritisch ist
SQL Server läuft oft als Dienstkonto mit Sysadmin-Rechten.
Ein Exploit reicht – und der Angreifer hat Root-Zugriff auf alles:
- Datenbankinhalte
- Dateisystem
- Netzwerk
- ggf. sogar Active Directory
Angriffe über SQL Injection oder manipulierte DLLs sind kein Film.
Sie passieren.
Wenn Du nicht patchst, bist Du dran.
Wie Du den Patch-Stand prüfst
SQL Server verrät seine Version.
Und die Version sagt Dir, ob Du aktuell bist.
SELECT
SERVERPROPERTY('ProductVersion') AS Version,
SERVERPROPERTY('ProductLevel') AS Patchlevel,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('EngineEdition') AS Engine
Beispielausgabe:
| Version | Patchlevel | Edition | Engine |
|---|---|---|---|
| 15.0.4261 | CU23 | Standard Edition | 3 |
Dann auf https://sqlserverbuilds.blogspot.com nachsehen:
Was ist der letzte CU (Cumulative Update)?
Bist Du drunter: patchen.
Mein Patchmanagement-Ablauf
Ich arbeite mit klaren Regeln:
- Monatlicher Reminder (immer zum 5. Werktag)
Ich prüfe verfügbare CUs manuell oder per RSS. - Testsystem patchen
Virtuelle SQL-Kopie mit Produktivdaten (maskiert).
Patch wird dort getestet. - Review der SQL Server Logs
Nach dem Patch:- Dienste gestartet?
- Jobs laufen?
- Fehler in den Logs?
- Produktiv patchen nach Freigabe
Außerhalb der Geschäftszeiten.
Immer mit Backup vorab. - Rollback vorbereiten
Wenn’s knallt, will ich sofort zurück.
Backup. Snapshot. Downgrade-Skript. - Dokumentation aktualisieren
Patch-Level wird im IT-Wiki und Monitoring aktualisiert.
CU-Installation automatisieren (PowerShell)
Ich lasse mich benachrichtigen – aber patche nicht blind.
Invoke-WebRequest -Uri https://go.microsoft.com/fwlink/?linkid=866658 -OutFile "CUSetup.exe"
Start-Process -FilePath "CUSetup.exe" -ArgumentList "/quiet /IAcceptSQLServerLicenseTerms"
Wichtig: Vorher alle SQL-Dienste kontrolliert stoppen, wenn nötig.
Und Reboot einplanen.
Patchstatus für alle Instanzen prüfen
T-SQL mit Central Management Server oder über sp_MSforeachdb reicht nicht.
Ich nutze ein eigenes Reporting mit diesem Query:
SELECT
@@SERVERNAME AS ServerName,
SERVERPROPERTY('ProductVersion') AS Version,
SERVERPROPERTY('ProductUpdateLevel') AS CU,
SERVERPROPERTY('ProductBuild') AS Build,
SERVERPROPERTY('Edition') AS Edition
Zusätzlich ein SSIS-Paket, das die Werte in ein zentrales Monitoring schreibt.
Damit sehe ich auf einen Blick, wo es klemmt.
Was ist mit automatischen Updates?
SQL Server patcht sich nicht automatisch.
Selbst wenn Du WSUS nutzt, werden CUs oft nicht verteilt.
Du musst es planen.
Manuell.
Oder skripten.
Aber Du kommst nicht drum herum.
Typische Ausreden – und meine Antworten
„Wir haben keinen Testserver.“
Dann patch nachts. Mit Backup. Und Rauchmelder.
„Ich hab Angst, dass was kaputt geht.“
Dann solltest Du ein Testsystem einführen. Oder einen Notfallplan.
„Das hat doch bisher immer funktioniert.“
Ja. Bis zum ersten Incident mit 5-stelligem Schaden.
Patch oder stirb.
SQL Server ist sicher.
Wenn Du ihn pflegst.
Ohne aktuelle Patches ist er ein Risiko – für Dich, für Deine Firma, für alle Daten.
Ich patche regelmäßig.
Weil ich nachts ruhig schlafen will.
Keine Antworten