SQL Server Management Studio 21/22 noch nicht einsetzen

[tts]Microsoft entwickelt das SQL Server Management Studio (SSMS) stetig weiter. Mit den Versionen 21 und 22 wurden einige Modernisierungen eingeführt, die auf den ersten Blick nach einem sinnvollen Fortschritt aussehen. In der Praxis zeigt sich jedoch: SSMS 21/22 ist derzeit für viele administrative Aufgaben noch nicht zuverlässig genug und sollte in produktiven Umgebungen mit Vorsicht betrachtet werden.

Besonders kritisch ist dabei ein Bereich, der in vielen Unternehmen zum täglichen Standard gehört: der SQL Server Agent.

Das Hauptproblem: Fehler beim Bearbeiten von SQL Server Agent Aufgaben

Ein zentrales Problem in SSMS 21/22 betrifft das Bearbeiten von SQL Server Agent Jobs. Gerade beim Öffnen, Bearbeiten oder Speichern von Aufgaben und deren Steps treten immer wieder Probleme auf. Dazu gehören unter anderem Fehlermeldungen beim Speichern, unvollständig geladene Eigenschaften oder fehlerhaft dargestellte Konfigurationen.

Das klingt zunächst nach einem typischen „kleinen UI-Bug“, kann aber schnell ernst werden. Denn SQL Server Agent Jobs sind in vielen Umgebungen das Rückgrat der Automatisierung. Sie steuern Backups, Wartungspläne, Datenimporte, Reporting-Prozesse oder Sicherheitsaufgaben. Wenn ein Tool hier nicht stabil arbeitet, steigt die Gefahr, dass Änderungen nicht korrekt übernommen werden oder Jobs unbeabsichtigt verändert werden.

Warum das im Alltag problematisch ist

SSMS ist nicht nur ein SQL-Editor, sondern das wichtigste Verwaltungswerkzeug für Datenbankadministratoren und IT-Betrieb. In produktiven Umgebungen müssen Änderungen schnell, sauber und nachvollziehbar durchführbar sein. Wenn grundlegende Funktionen wie die Job-Verwaltung nicht fehlerfrei funktionieren, führt das zu unnötigem Mehraufwand, längeren Wartungsfenstern und im schlimmsten Fall zu Ausfällen oder fehlerhaften Abläufen.

Gerade in Zeiten, in denen Datenbanken häufig ein kritischer Bestandteil der gesamten Infrastruktur sind, ist es schlicht keine gute Idee, mit einem instabilen Management-Tool zu arbeiten.

Empfehlung: SSMS 20.x bleibt aktuell die beste Wahl

Wer heute eine stabile und bewährte Umgebung benötigt, sollte weiterhin auf SSMS 20.x setzen. Diese Version bietet die nötige Zuverlässigkeit im täglichen Betrieb, insbesondere bei der Verwaltung von SQL Server Agent Aufgaben. Viele Administratoren nutzen SSMS 20.x weiterhin bewusst, weil es in der Praxis stabil läuft und keine bösen Überraschungen verursacht.

Kurz gesagt: Wer produktiv arbeiten will, fährt mit SSMS 20.x aktuell deutlich besser.

Englisch oder Deutsch? Beides möglich

Ein zusätzlicher Tipp: Die englische Version von SSMS wirkt in vielen Fällen etwas schlanker und ist oft angenehmer in der täglichen Nutzung, insbesondere wenn man Fehlermeldungen oder Workarounds recherchieren muss. Die meisten Microsoft-Dokumentationen und Community-Beiträge beziehen sich auf englische Menüs und Begriffe, wodurch die Fehlersuche deutlich schneller geht.

Die deutsche Version ist aber ebenfalls nutzbar und absolut in Ordnung, vor allem in Teams, die konsequent deutschsprachig arbeiten.

Fazit: SSMS 21/22 derzeit lieber nur zum Testen

SSMS 21 und 22 werden langfristig sicher die Zukunft sein. Aktuell gibt es aber noch zu viele Probleme in wichtigen Verwaltungsfunktionen, insbesondere rund um den SQL Server Agent. Wer auf Stabilität angewiesen ist, sollte deshalb vorerst auf SSMS 20.x setzen und SSMS 21/22 höchstens in Testumgebungen evaluieren.

Für produktive Systeme gilt damit momentan eine klare Empfehlung: SSMS 20.x verwenden und SSMS 21/22 erst dann einführen, wenn die bekannten Schwächen vollständig behoben sind.

IBM‑Db2‑Sicherheitslücken

IBM hat mehrere kritische #Sicherheitslücken im Datenbanksystem IBM Db2 veröffentlicht, die unter bestimmten Umständen lokale Angreifer in die Lage versetzen können, ihre Rechte auszuweiten – im schlimmsten Fall bis hin zu Root‑Rechten. Laut heise sind derzeit über 17 Schwachstellen bekannt, darunter zwei mit hoher Kritikalität, die es Angreifern mit Dateisystemzugriff ermöglichen, privilegierte Operationen auszuführen oder Root‑Zugriff zu erlangen. [heise.de]

Was genau ist betroffen?

Die Schwachstellen betreffen verschiedene Db2‑Versionen, inklusive älterer Releases, die nicht mehr im Support stehen und somit keine Sicherheitsupdates mehr erhalten. Für unterstützte Versionen wie Db2 11.5.9 stehen spezielle Patches (z. B. Special Build #66394) zur Verfügung. Diese beheben insbesondere Privilege‑Escalation‑Lücken sowie diverse Denial-of-Service‑Probleme, die durch manipulierte SQL‑Abfragen ausgelöst werden können.

Bin ich betroffen, wenn Db2 nur im internen LAN läuft?

Viele Unternehmen setzen Db2 ohne externe Erreichbarkeit und ausschließlich intern ein – zum Beispiel als Datenbank für d.3 / d.velop documents Version 8. Die gute Nachricht: Wenn der Db2‑Server nicht aus dem Internet erreichbar ist, sinkt das Risiko deutlich.

Allerdings gilt: Die kritischsten Lücken erfordern lokalen Zugriff auf den Server. Das bedeutet, dass ein Angreifer bereits im internen Netz oder auf dem System aktiv sein müsste, um die Schwachstellen auszunutzen. Das schützt zwar vor externen Angriffen, aber nicht vor:

• infizierten Arbeitsplätzen im LAN.
• kompromittierten Dienstkonten.
• internen Angreifern.
• Malware, die sich lateral im Netzwerk bewegt.

Kurz gesagt: Nicht aus dem Internet erreichbar bedeutet nicht automatisch sicher.

Was bedeutet das für d.3‑Systeme mit IBM Db2?

Ein wichtiger Punkt: d.velop hat angekündigt, die Unterstützung für IBM Db2 ab 2026 vollständig einzustellen. Bereits heute steht Db2 für Neuinstallationen nicht mehr zur Verfügung, und Bestandskunden erhalten nur noch bis Ende 2026 Support. Eine Migration auf Microsoft SQL‑Server wird ausdrücklich empfohlen. [Wichtige N….dok - GWS]

Damit ergibt sich ein doppelter Handlungsdruck:

1. Aktuelle Sicherheitslücken beheben
2. Frühzeitig die Migration auf SQL‑Server planen, da Db2 perspektivisch nicht mehr unterstützt wird

Wie hoch ist das Risiko für meine bestehende d.3‑Installation?

Bewertung für typische d.3‑Umgebungen im LAN:

Du bist wahrscheinlich betroffen, wenn:

• Du eine ungepatchte oder ältere Db2‑Version einsetzt.
• Dein d.3‑System weiterhin auf Db2 basiert (Version 8 ist häufig betroffen).
• Dienstkonten oder Anwendungen mit zu hohen Rechten laufen.
• es potenzielle interne Angriffswege gibt (z. B. über RDP, SMB, Schwachstellen in Drittsoftware).

Du bist weniger betroffen, wenn:

• Deine Db2‑Version gepatcht und im Support ist.
• Der Server gehärtet ist und nach Prinzip „Least Privilege“ betrieben wird.
• Das System vollständig isoliert ist.
• Du bereits auf Microsoft SQL‑Server migriert hast.

Klare Empfehlung

Kurzfristig

• Prüfen, welche Db2‑Version eingesetzt wird.
• Verfügbare Sicherheitsupdates umgehend installieren.
• Dienst‑ und Systemkonten prüfen und bereinigen.
• Serverhärtung durchführen (Firewall, AV, lokale Richtlinien).

Mittelfristig

• Migration von Db2 auf SQL‑Server planen, da der Hersteller‑Support endet
• Prüfen, welche d.3‑Komponenten bereits SQL‑Server voraussetzen

Langfristig

• Moderne Web‑Technologien (z. B. d.3 One) nutzen.
• Abhängigkeit von abgekündigten Technologien vermeiden.
• Sicherheitsrisiken reduzieren, die durch veraltete Datenbanksysteme entstehen.

Fazit

Auch wenn dein d.3‑System auf Basis von IBM Db2 nur intern im LAN betrieben wird, kann eine lokale Angriffsfläche bestehen bleiben – besonders, wenn ältere oder ungepatchte Versionen im Einsatz sind. Die aktuelle Entwicklung sowie das bevorstehende Supportende von Db2 bei d.velop machen klar: Eine Migration auf SQL‑Server ist nicht nur sicherer, sondern perspektivisch zwingend notwendig.