Die vier Schwachstellen, die Angreifer in Datenbankumgebungen am zuverlässigsten finden, sind seit Jahren dieselben: überprivilegierte Konten, gemeinsam genutzte Service-Accounts, Schlüssel und Passwörter ohne Rotation und eine Auditierung mit Lücken. Neu ist das Tempo, mit dem diese Lücken gefunden und ausgenutzt werden. KI-gestützte Angriffswerkzeuge scannen automatisiert nach Fehlkonfigurationen, erzeugen SQL-Injection-Varianten für die konkrete Anwendung und passen ihr Vorgehen an Firewall-Regeln und Rate-Limits an.

Dieser Beitrag richtet sich an DBAs und Database Security Engineers, also an alle, die Datenbanken täglich betreiben. Er beschreibt, was sich im Bedrohungsmodell geändert hat, welche Angriffstechniken Sie im Log wiedererkennen sollten und in welcher Reihenfolge Sie die typischen Schwachstellen schließen. Grundlage ist mein Whitepaper „Database Security in Regulated DACH Environments: Adapting to the Age of AI“, das die Bedrohungslage, die Architekturprinzipien und die regulatorischen Anforderungen für Deutschland, Österreich und die Schweiz im Detail beschreibt.

Was sich im Bedrohungsmodell geändert hat

Klassische Angriffe auf Datenbanken hinterließen erkennbare Muster. Ein Brute-Force-Versuch erzeugte tausende gleichartige Login-Fehler, eine SQL-Injection nutzte Payloads aus öffentlichen Listen, ein Scanner meldete sich mit einer Signatur, die jede Firewall kannte. Regelbasierte Erkennung hat gegen solche Angriffe über Jahre gut funktioniert.

KI-Modelle verändern Tempo, Variabilität und Anpassungsfähigkeit dieser Angriffe. Schwachstellenscans gegen relationale Datenbankplattformen laufen automatisiert und werten Systemkataloge, Fehlermeldungen und Netzwerkantworten aus. Payloads werden für die jeweilige Anwendung generiert. Angriffswerkzeuge reagieren auf Login-Policies, Firewall-Regeln und Rate-Limits und wechseln die Strategie, bevor ein Schwellenwert greift.

Das ist belegt und reproduzierbar. Microsoft und OpenAI haben im Februar 2024 dokumentiert, wie staatlich unterstützte Gruppen Sprachmodelle für Schwachstellenrecherche, Skripting und die Vorbereitung von Spear-Phishing-Kampagnen einsetzen. Wer eine Datenbank betreibt, plant heute mit einem Gegner, der schneller sucht, mehr Varianten probiert und aus jeder Abwehrreaktion lernt.

Vier Angriffstechniken, die Sie im Log wiedererkennen sollten

KI-optimierte SQL-Injection

SQL-Injection galt lange als Problem fehlender Eingabevalidierung. Heute durchsuchen KI-Werkzeuge Anwendungen automatisiert nach verwertbaren Stellen, erkennen Schwächen in ORM-generiertem SQL und in dynamischen SQL-Konstrukten und erzeugen Payloads, die auf die Struktur der Anwendung zugeschnitten sind. Diese Varianten umgehen signaturbasierte Filter, weil sie in keiner Signaturliste stehen.

Im Betrieb zeigt sich das als Abfragen mit ungewöhnlichen JOIN-Strukturen, auffälliger Länge oder Kommentar-Syntax aus Anwendungskonten, die sonst nur einfache Statements absetzen. Typisch sind auch Fehlermeldungen, die in kurzer Folge unterschiedliche Syntaxvarianten durchprobieren.

Credential-Angriffe mit Mustererkennung

GPU-beschleunigtes Passwort-Cracking berechnet Hashes gegen datenbankspezifische Authentifizierungsverfahren deutlich schneller als früher, und KI-Modelle erzeugen Passwortkandidaten, die klassische Wortlisten übertreffen. Beim Credential Stuffing gegen öffentlich erreichbare Datenbankendpunkte erkennen Modelle aus Telemetrie-Artefakten, welche Login-Muster gültig sind, und konzentrieren die Versuche darauf. In hybriden Umgebungen analysieren sie Token-Strukturen wie JWT und suchen nach Fehlkonfigurationen in Identitäts- und Zugriffssystemen.

Im Log erkennen Sie das an Login-Sequenzen, die unter jedem Rate-Limit bleiben, an Anmeldungen zu untypischen Zeiten oder von untypischen Standorten und an Service-Accounts, die sich plötzlich interaktiv anmelden.

Prompt Injection gegen Datenbank-Assistenten

KI-gestützte Query-Assistenten und Automatisierungswerkzeuge sind ein neuer Zugangsweg zur Datenbank. Wer die Eingaben an ein solches Modell manipuliert, kann Abfragen auslösen, die der Assistent im Namen eines berechtigten Nutzers ausführt. Dazu kommen Datenvergiftung über manipulierte Trainings- oder Kontextdaten und unkontrollierte Modellinteraktionen. Jeder Assistent mit Datenbankzugriff braucht ein eigenes technisches Konto mit minimalen Rechten, eine Protokollierung aller erzeugten Statements und eine Prüfung zwischen Modellantwort und Ausführung.

Adaptive Angriffswerkzeuge

Angriffswerkzeuge passen ihre Strategie an Firewall-Regeln, Login-Policies und Rate-Limits an. Ein gesperrter Port führt zum Wechsel auf einen anderen Pfad, ein Rate-Limit zu langsameren, verteilten Versuchen. Erkennung mit festen Schwellenwerten bleibt dabei still. Sichtbar werden diese Angriffe über Abweichungen vom Normalverhalten einer Instanz, also über eine Baseline, die Sie kennen müssen.

Die klassischen Fehler bleiben der Einstiegspunkt

Alle vier Techniken treffen auf dieselben Schwachstellen, die auch ohne KI seit Jahren ausgenutzt werden. Das Whitepaper nennt vier typische Fehler in Zugriffs- und Identitätsmodellen.

• Überprivilegierte Konten. Anwendungskonten mit db_owner oder sysadmin, weil es beim Deployment schneller ging. Ein kompromittiertes Konto dieser Art gibt dem Angreifer sofort alles.
• Gemeinsam genutzte Service-Accounts. Mehrere Anwendungen oder mehrere Personen teilen sich ein Konto. Im Audit-Trail fehlt dann die Zuordnung, wer eine Aktion ausgelöst hat, und eine Sperrung trifft alle Nutzer gleichzeitig.
• Fehlende Rotation. Passwörter, Zertifikate und Verschlüsselungsschlüssel, die seit Jahren unverändert sind. KI-gestützte Angriffe erkennen Muster in Zertifikatsketten und Rotationsintervallen und leiten daraus Angriffspfade ab.
• Unzureichende Auditierung. Logins, Rollenänderungen, Schemaänderungen, Datenzugriffe und Backup-Operationen werden nur teilweise protokolliert, und die Logs liegen auf demselben Server wie die Datenbank. Ein Angreifer, der die Instanz kontrolliert, kontrolliert auch die Spuren.

Dazu kommen unverschlüsselte Backups, schwache Authentifizierung, Insider-Zugriffe und fehlende Netzwerksegmentierung. Auditoren prüfen diese Punkte weiterhin als zentrale Kontrollpunkte, und KI-Werkzeuge nutzen sie automatisiert aus. Die Grundlagen der Härtung fasst Simple Talk in Database Security in 2026 zusammen.

Was Sie zuerst beheben sollten

Die ersten vier Schritte schließen die klassischen Lücken. Die Schritte fünf bis neun folgen den priorisierten Handlungsempfehlungen aus dem Whitepaper, übersetzt in Aufgaben für den Datenbankbetrieb.

1. Berechtigungen inventarisieren und zurückbauen. Listen Sie alle Logins mit sysadmin, db_owner, CONTROL SERVER und vergleichbaren Rechten. Für jedes Konto klären Sie, wer es nutzt, wofür und seit wann. Reduzieren Sie auf das Minimum und dokumentieren Sie die Entscheidung. Diese Liste ist gleichzeitig die Rezertifizierung, die DORA und NIS2 verlangen.
2. Service-Accounts trennen. Ein Konto pro Anwendung und pro Umgebung. Interaktive Anmeldung für Service-Accounts deaktivieren. Privilegierte Aktionen laufen über ein PAM-System oder einen Bastion Host mit vollständiger Protokollierung.
3. Rotation automatisieren. Passwörter, Zertifikate und Schlüssel bekommen ein Intervall und einen Prozess, der ohne manuelle Erinnerung läuft. Schlüssel liegen in einem HSM oder Key Vault, getrennt von den Daten. Backups, Transaktionslogs und temporäre Dateien sind ebenso verschlüsselt wie die Datenbankdateien. Jede Rotation hinterlässt einen Nachweis.
4. Audit-Trail vervollständigen und absichern. Logins, Rollenänderungen, Schemaänderungen, Zugriffe auf sensible Tabellen und Backup-Operationen werden vollständig erfasst. Logs werden an ein System außerhalb der Datenbankinstanz weitergeleitet, unveränderbar gespeichert und mit Integritätsprüfungen versehen. Zeitstempel sind über alle Systeme konsistent, und die Aufbewahrungsdauer ist als Richtlinie festgelegt.
5. Anomalieerkennung aktivieren. Sobald eine Baseline für normales Abfrage- und Login-Verhalten existiert, werden Abweichungen sichtbar: ungewöhnliche JOIN-Strukturen, Massenauslesen, Logins außerhalb des üblichen Musters. Die Alerts gehen an das SIEM, damit Datenbankereignisse mit Netzwerk- und Identitätsereignissen korreliert werden.
6. Adaptive Zugriffskontrolle einführen. MFA für alle interaktiven Zugriffe, zusätzliche MFA-Abfragen bei Risikoindikatoren, Just-in-Time-Zugriff für administrative Aufgaben. Berechtigungen werden bei ungewöhnlichem Verhalten automatisch herabgestuft.
7. Automatisierte Reaktionen vorbereiten. Kontosperrung, Isolation einer Instanz, forensischer Snapshot und Eskalation liegen als vorbereitete Playbooks vor und werden ausgelöst, bevor ein Mensch die Lage bewertet hat.
8. KI-Assistenten härten. Eigene Konten, minimale Rechte, Protokollierung aller erzeugten Statements, Prüfung manipulierter Eingaben.
9. Alles dokumentieren. Jede Konfiguration, jede Rotation, jeder Alert und jede Reaktion ist Evidenz für das nächste Audit. Eine Kontrolle ohne Dokumentation gilt für den Prüfer als nicht umgesetzt.

Woran Sie erkennen, dass es wirkt

Nach den ersten vier Schritten ist die Liste der Konten mit sysadmin-Rechten kurz und begründet, jeder Service-Account ist genau einer Anwendung zugeordnet, und jede Rotation hat einen Zeitstempel im Log. Nach Schritt fünf und sechs erzeugt ein Test-Login von einer unbekannten IP außerhalb der Geschäftszeiten einen Alert im SIEM und eine zusätzliche MFA-Abfrage. Diese Tests sind gleichzeitig die Nachweise, die ein Prüfer sehen will.

Wie Sie Berechtigungsänderungen, Konfigurationsabweichungen und Sicherheitsereignisse über die gesamte Datenbanklandschaft hinweg erfassen und für ein Audit aufbereiten, zeigt Redgate in der Übersicht zu Sicherheit und Compliance in Redgate Monitor.

Häufige Fragen

Reicht ein regelbasiertes IDS gegen KI-gestützte Angriffe?

Signaturen erkennen bekannte Payloads. KI-generierte Varianten und adaptive Angriffe haben keine bekannte Signatur und bleiben unter festen Schwellenwerten. Zusätzlich brauchen Sie eine Baseline des Normalverhaltens und Anomalieerkennung darauf.

Womit fange ich an, wenn ich nur einen Tag habe?

Mit der Berechtigungsinventur. Sie ist an einem Tag machbar, und die Liste der überprivilegierten Konten ist meist die größte einzelne Risikoreduktion.

Muss ich für Anomalieerkennung ein eigenes KI-Modell betreiben?

Nein. Monitoring-Anwendungen und Cloud-Plattformen bringen Baseline- und Anomaliefunktionen mit. Entscheidend ist, dass die Alerts im SIEM ankommen und dokumentiert werden.

Was gehört mindestens in den Audit-Trail?

Logins, Rollenänderungen, Schemaänderungen, Datenzugriffe und Backup-Operationen. Dazu kommen eine Aufbewahrungsrichtlinie, eine Integritätssicherung und die Weiterleitung an ein System außerhalb der Instanz, damit der Trail auch nach einer Kompromittierung der Instanz vollständig bleibt.

Weiterlesen

Das Whitepaper „Database Security in Regulated DACH Environments: Adapting to the Age of AI“ enthält die vollständige Bedrohungsanalyse, die Architekturprinzipien und die regulatorischen Anforderungen für Deutschland, Österreich und die Schweiz: Whitepaper herunterladen.

Wie Sie eine Architektur entwerfen, die diese Kontrollen trägt, beschreibe ich in „Zero Trust für Datenbanken: Eine Architektur, die KI-Angriffen und Audits standhält“. Warum das Thema in die Vorstandsvorlage gehört, steht in „DORA, NIS2, FINMA: Warum Datenbanksicherheit in DACH auf die Vorstandsagenda gehört“.