Überwachung der Datenbankaktivität: Was zu beachten ist und wie man es macht
Oct 20, 2026
Die Überwachung der Datenbankaktivität existiert, weil native Audit-Tools in SQL Server, Oracle, MySQL und PostgreSQL sensible Lesevorgänge, Vorher-Nachher-Werte und Manipulationen durch privilegierte Konten, die genau überwacht werden sollten, nicht erfassen. Sie zeichnet unabhängig auf, wer sich verbunden hat, was sich geändert hat und ob jemand die Spur selbst verändert hat. Beschränken Sie die Erfassung auf regulierte Tabellen, leiten Sie Aufzeichnungen an ein SIEM weiter und passen Sie Warnungen an eine Basislinie normaler Aktivitäten an.
Datenbanken enthalten Kunden-, Zahlungs- und Gesundheitsdaten, die für Regulierungsbehörden, Angreifer und Prüfer am wichtigsten sind. Die nativen Audit-Funktionen in SQL Server, Oracle, MySQL und PostgreSQL erfassen Objekt- und Berechtigungsänderungen, bieten jedoch wenig Einblick darüber, wer sensible Zeilen gelesen hat.
Der Netwrix Bericht zur Daten- und Identity-Sicherheit 2026 ergab, dass 75 % der sensiblen Datenlecks mit kompromittierten Identitäten oder falsch konfigurierten Berechtigungen beginnen. Die native Prüfung bietet die geringste Sichtbarkeit dort, wo diese Identitäten die größte Macht haben: privilegierte Konten, die den Prüfpfad selbst bearbeiten können.
Die Überwachung der Datenbankaktivitäten erstellt ein unabhängiges Protokoll von Zugriffen, Änderungen und administrativen Aktionen, sodass Sicherheitsteams Vorfälle untersuchen, Compliance nachweisen und Missbrauch erkennen können, bevor ein kompromittiertes Konto oder eine stille Konfigurationsänderung zu einem meldepflichtigen Verstoß wird.
Was ist Datenbankaktivitätsüberwachung?
Database Activity Monitoring (DAM) ist eine Sicherheitsdisziplin, die Benutzer- und Administratoraktivitäten innerhalb einer Datenbank unabhängig vom Datenbank-Engine erfasst, speichert und analysiert. Auf Anfrage beantwortet sie, wer sich verbunden hat, was gelesen oder geändert wurde und ob jemand die Audit-Konfiguration verändert hat.
DAM steht neben der Leistungsüberwachung, dient jedoch einem anderen Zweck. Performance-Tools überwachen CPU, I/O und Abfragelatenz, um den Motor gesund zu halten. DAM erfasst stattdessen die SQL-Anweisung, Benutzeridentität, Client-IP-Adresse und Zeitstempel, sodass Sie Aktivitäten einer benannten Person oder einem Dienst zuordnen können.
Ein DAM-Tool sammelt diese Informationen über einen network tap, einen Host-Agenten oder die eigene Audit-Funktion der Datenbank und leitet sie dann an ein Repository außerhalb der Datenbank weiter, damit der Datensatz einen kompromittierten Administrator-Account überlebt.
Warum die Überwachung der Datenbankaktivitäten wichtig ist
Für einen Datenbankadministrator (DBA) oder Sicherheitsanalysten ist der schwierige Teil bei jedem Vorfall oder Audit, nachzuweisen, wer was berührt hat. Ohne eine unabhängige Datenbankspur rekonstruieren Teams diesen Nachweis manuell aus Teilprotokollen, meist unter Zeitdruck.
Sensiblen Daten konzentrieren sich in der Datenbankschicht
Kundendaten, Karteninhaberdaten und protected health information (PHI) befinden sich in Datenbanktabellen. Alle regulierten Daten durchlaufen irgendwann eine Datenbank. Wenn der Datenbankzugriff nicht überwacht wird, verlieren die sensibelsten Vermögenswerte der Umgebung ihre nächstgelegene Verantwortungsebene, und jede nachgelagerte Kontrolle hängt von einer Spur ab, die nie erfasst wurde.
Native Datenbankprotokolle können eine Untersuchung nicht unterstützen
Die Standard-Trace von SQL Server erfasst Objekt- und Berechtigungsänderungen, aber keine SELECT-Aktivitäten, und speichert nur 100 MB Verlauf. Schlimmer noch, Microsoft warnt, dass Sysadmins die Audit-Trail selbst manipulieren können, weshalb NIST SP 800-53 AU-9(2) verlangt, Audit-Datensätze auf einem separaten System zu speichern.
Compliance-Rahmenwerke erfordern eine Datenbank-Audit-Trail
Jeder große Rahmen behandelt Datenbankaktivitäten als Beweismittel. PCI DSS v4.0.1 Anforderung 10 schreibt 12 Monate protokollierten Zugriff auf Karteninhaberdaten und die Integrität der Prüfprotokolle vor. HIPAA's 45 CFR 164.312(b) verlangt Mechanismen, die Aktivitäten in ePHI-Systemen aufzeichnen und prüfen.
In seinem Inspektionsbericht 2023 zu Ernst & Young Incorporated (PCAOB-Veröffentlichung Nr. 104-2024-113) beanstandete der PCAOB das Unternehmen, weil es nicht bewertet hatte, wie die Kontrollverantwortlichen des Kunden direkte Änderungen an der Datenbank hinter seinem Buchhaltungssystem überprüften, bei einer Prüfung der internen Kontrolle über die Finanzberichterstattung gemäß SOX.
Die DSGVO Artikel 5(2) verlangt von Verantwortlichen, die Einhaltung der Grundsätze der Verordnung nachzuweisen, einschließlich der Offenlegung, wer auf personenbezogene Daten zugegriffen hat.
Kompromittierte Konten und Missbrauch durch Insider treten zuerst in der Datenbank zutage
Ein gültiger Login wirkt für jedes System legitim, außer für das, das aufzeichnet, was getan wurde. Deshalb lösen Anmeldeinformationen-Diebstahl und Insider-Missbrauch selten Perimeter-Kontrollen aus. Der 2026 Data Breach Investigations Report von Verizon zeigte, dass Anmeldeinformationen-Missbrauch in 39 % der Sicherheitsverletzungen irgendwann in der Angriffskette vorkam, und kontinuierliche Datenbanküberwachung ist oft der früheste Ort, um die seitliche Bewegung zu erkennen, die darauf folgt.
Netwrix Auditor zeichnet Vorher-Nachher-Werte für Zugriffs- und Änderungsereignisse in hybriden Microsoft-Umgebungen auf. Fordern Sie eine Demo an.
Datenbankaktivitäten, die Sie überwachen müssen
Die untenstehenden Kategorien haben genug Sicherheits- oder Compliance-Gewicht, um eigene Erkennungsregeln zu rechtfertigen. Zusammen erfassen sie, wer eingedrungen ist, was gelesen oder geändert wurde und ob jemand die Aufzeichnung manipuliert hat: die Fragen, mit denen jede Untersuchung beginnt.
Authentifizierungs- und Verbindungsereignisse
Anmeldeprotokolle sind der erste Ort, an dem gestohlene Anmeldeinformationen sichtbar werden. Fehlgeschlagene Anmeldungen zeigen Passwortraten oder credential stuffing, während erfolgreiche Anmeldungen von ungewöhnlichen Quellen darauf hinweisen, dass Anmeldeinformationen an Orten verwendet werden, an denen sie nicht sein sollten.
Privilegierte und Dienstkonto-Anmeldungen verdienen besondere Aufmerksamkeit, da ein Dienstkonto, das plötzlich von einem neuen Arbeitsplatz statt von seiner üblichen Anwendungsschicht verbindet, fast immer einer Untersuchung wert ist. Oracle aktiviert standardmäßig eine predefined failed-logon policy in neuen Datenbanken, obwohl bei aktualisierten diese oft manuell eingeschaltet werden muss.
Lesen sensibler Daten und Massenexporte
Direkte Sichtbarkeit darüber, wer regulierte Tabellen abgefragt hat, trennt das Wissen, dass eine Offenlegung stattgefunden hat, vom Nachweis, was entnommen wurde. Der erstmalige Zugriff auf eine Tabelle, die ein Benutzer noch nie berührt hat, und die Massenextraktion mit Tools wie bcp oder expdp sind die Leseverhalten, die am meisten beobachtet werden sollten, dasselbe Verhalten, das data loss prevention-Kontrollen am Endpunkt überwachen.
Schema- und Konfigurationsänderungen
Schema- und Konfigurationsänderungen können Daten zerstören oder die Überwachung, die alles andere erfassen soll, blind machen. CREATE, ALTER, und DROP Anweisungen gegen Tabellen und gespeicherte Prozeduren benötigen eigene Warnungen, und Änderungen an der Audit-Konfiguration selbst verdienen die schnellste Reaktion. Microsoft liefert xp_cmdshell standardmäßig in SQL Server deaktiviert, da das Aktivieren einem Angreifer eine Kommandozeile ermöglicht.
Neue oder eskalierte Berechtigungen
Eine einzelne Privilegienvergabe kann ein eingeschränktes Konto in eines verwandeln, das alles lesen kann oder die Prüfspur vollständig deaktiviert. Änderungen der Rollenmitgliedschaft, neue Anmeldungen und jede Hinzufügung zur sysadmin-Rolle in SQL Server oder einer gleichwertigen DBA-Rolle in Oracle sind nicht verhandelbare Warnungen, das gleiche privilege escalation Muster, das auf Identitätsebene überwacht wird. Das Prinzip der geringsten Privilegien ist die Basiskontrolle. Die ORA_ACCOUNT_MGMT-Richtlinie von Oracle deckt dies ab, ist jedoch standardmäßig deaktiviert.
Datenänderungen an sensiblen Tabellen
Wenn sich ein Gehalt oder Kontostand ohne Autorisierung ändert, ist die erste Frage, wie der Wert vor der Änderung war. Native Audit-Protokolle erfassen nur den Anweisungstext, nicht die Zeilenwerte, daher muss ein separates Verfahren den Vorher-Nachher-Inhalt sichern, wie z. B. SQL Servers Change Data Capture, MySQLs binäres Zeilenbild-Logging oder PostgreSQL triggers. Warnungen bei Massen- oder außerhalb der Arbeitszeiten erfolgten Änderungen an regulierten Tabellen entsprechen MITRE T1565, Data Manipulation.
Aktivität, die das normale Muster durchbricht
Basisregeln erfassen Aktivitäten, die isoliert betrachtet gewöhnlich wirken, aber für das ausführende Konto ungewöhnlich sind, wie ein Benutzer, der plötzlich innerhalb von fünf Minuten 10 Tabellen abfragt, oder ein bekanntes Anwendungskonto, das sich von einer neuen IP-Adresse verbindet.
Dies ist die einzige Kategorie, die auf SIEM-Analysen statt auf nativer Audit-Konfiguration basiert, derselbe verhaltensbasierte Ansatz, den identity threat detection auf Kontoebene verwendet.
Wie man die Überwachung der Datenbankaktivitäten implementiert
Bearbeiten Sie die fünf Schritte der Reihe nach, da jeder vom vorherigen abhängt. Was Sie in Schritt 1 festlegen, bestimmt die passende Erfassungsmethode in Schritt 2 und so weiter.
Sie gehen auch von einem kleinen Team aus, das nicht jedes Ereignis manuell überprüfen kann, daher basieren mehrere der folgenden Schritte auf gestuften Rollouts und automatisierten Baselines statt auf manueller Prüfung.
1. Definieren Sie den Umfang dessen, was überwacht wird
Beginnen Sie damit, zu inventarisieren, welche Datenbanken regulierte oder geschäftssensible Daten enthalten, wie Gehaltsabrechnungen, Karteninhaber, Gesundheitsdaten oder geistiges Eigentum, und ordnen Sie sie nach regulatorischem Treiber. Dieses Inventar ist nur relevant, wenn Sie wissen, welche Tabellen sensible Felder enthalten, also führen Sie zuerst data classification durch; überspringen Sie es, und eine Gehaltsabrechnungsprüfung hat nichts, worauf sie sich stützen kann.
Die Einsätze sind hoch: Die Umfrage hinter dem Netwrix 2026 Data and Identity Security Report ergab, dass 57 % der Organisationen kein kontinuierliches Inventar sensibler Daten führen, sodass die meisten Teams diesen Schritt blind beginnen.
Sobald Sie sensible Datenbanken kartiert haben, erweitern Sie dasselbe Inventar auf die privileged, gemeinsamen und Service-Konten, die darauf zugreifen, und verpflichten Sie sich, jede privileged Sitzung vollständig zu überwachen, auch wenn die Protokollierung regulärer Benutzer selektiv bleibt.
CIS Safeguard 8.5 legt die Mindestanforderung für dieses Engagement fest. Erfassen Sie mindestens Benutzername, Zeitstempel sowie Quell- und Zieladressen für jedes Asset mit sensiblen Daten.
2. Wählen Sie eine Erfassungsmethode, die zu Ihrer Umgebung passt
Passive Netzwerkerfassung über einen SPAN-Port ist der Ausgangspunkt, wenn Sie keine Last auf dem Server haben möchten. Dieser Last-freie Kompromiss kostet jedoch die Sichtbarkeit von Forward-Secret Transport Layer Security (TLS), lokalen Verbindungen und cloudverwalteten Datenbanken.
Wenn das Blockieren einer Anweisung wichtiger ist als deren Anzeige, ist ein Inline-Proxy besser geeignet, da er TLS selbst beendet, obwohl diese Kontrolle Latenz hinzufügt und den Proxy zu einer Verfügbarkeitsabhängigkeit macht.
Wenn lokale Verbindungen danach noch abgedeckt werden müssen und das Team die CPU-Kosten sowie die Revalidierungsarbeit bei jedem Kernel- oder Datenbank-Upgrade tolerieren kann, schließt ein Host-Agent diese Lücke. Teams, die Datenbank als Dienst (DBaaS) betreiben oder Einblick in gespeicherte Prozeduren und Verschlüsselung benötigen, erreichen dies stattdessen durch die Kombination von nativer Prüfung mit agentenloser Sammlung.
Oracle berichtet von einer mittleren einstelligen CPU-Auslastung für natives Auditing bei bis zu 360.000 Audit-Datensätzen pro Stunde. Agentenlose Sammlung erhöht die Last zusätzlich, daher sollte die Kombination vor dem Einsatz getestet werden.
In der Praxis kombinieren die meisten Teams ohnehin Methoden, da die AVDF-Dokumentation von Oracle empfiehlt, Netzwerküberwachung mit Datenbankprüfung zu koppeln, damit sich beide gegenseitig blinde Flecken abdecken.
3. Legen Sie Richtlinien und Alarmgrenzen fest, die ein kleines Team bearbeiten kann
Schalten Sie Regeln stufenweise ein, nicht alle auf einmal, da das Aktivieren aller Regeln am ersten Tag ein kleines Team mit Fehlalarmen überflutet. Beginnen Sie diesen gestuften Rollout mit Audit-Manipulation und Sysadmin-Berechtigungen, die aus den oben genannten sechs Aktivitätskategorien abgeleitet sind, da diese beiden die geringste Toleranz für verpasste Warnungen haben.
NIST SP 800-94 warnt, dass ein frisch eingesetztes System typischerweise zu viele Fehlalarme erzeugt, bevor seine Regeln vollständig an die Umgebung angepasst sind. Deshalb ist der gestufte Ansatz hier so wichtig.
Regeln für Volumen und Zugriffsmuster erfordern eine andere Behandlung. Führen Sie sie als Anomalien aus, abgestimmt auf mindestens eine Woche Basisdaten, im gleichen Größenordnungsbereich wie Microsoft Sentinel für seine eigene Anomalie-Regel für betroffene Zeilen, die über 14 Tage trainiert wird.
Erwarten Sie, dass diese Schwellenwerte lokal in Ihrer Umgebung bleiben und keiner universellen Zahl folgen, da für ein Team eine Anomalie 100 Zeilen sind, für ein anderes 500.000, und nur Ihre eigene Basislinie zeigt, welches welche ist.
4. Zentralisieren Sie Datenbankereignisse und korrelieren Sie diese mit dem Identitätskontext
Zentralisieren Sie zuerst die Protokollsammlung, wie CIS Safeguard 8.9 es verlangt, und verwenden Sie ein Tool, das große Ereignisdatenmengen auf eine Menge filtert, die ein Mensch überprüfen kann, wie es NIST SP 800-61 Rev. 3 empfiehlt. Sobald diese Pipeline existiert, korrelieren Sie jedes Ereignis mit dem dahinterstehenden Konto, da ein zentrales Protokoll ohne Identitätskontext Sie immer noch rohe SQL-Anweisungen statt Namen lesen lässt.
In Microsoft Sentinel läuft diese Korrelation über bestimmte Tabellen. Leiten Sie Azure SQL-Auditereignisse an die Tabelle SQLSecurityAuditEvents (oder AzureDiagnostics in älteren Setups), SQL Server Windows-Ereignisse an SecurityEvent und Defender-Warnungen an SecurityAlert; Verwenden Sie dann die Tabelle IdentityInfo, um die Person hinter jedem Konto zuzuordnen.
Splunk- und IBM QRadar-Nutzer können dasselbe Muster mit ihren eigenen Identitätsabfragen verwenden; der Nutzen besteht darin, aus „jemand führte ein großes SELECT aus“ „ein vor zwei Stunden zum sysadmin hinzugefügtes Auftragnehmerkonto führte ein großes SELECT aus“ zu machen.
5. Testen, optimieren und die Überwachungspipeline warten
Testen Sie die gesamte Pipeline mit repräsentativer Aktivität, bevor Sie ihr in der Produktion vertrauen. Fügen Sie eine Testanmeldung zu einer Serverrolle hinzu, ändern Sie eine Auditspezifikation und führen Sie einen Export von 600 Zeilen durch, dann bestätigen Sie, dass jede Warnung mit der richtigen Identität ankommt. Eine Pipeline, die das Ereignis protokolliert, aber den Identitätskontext verliert, ist nur halb gebaut.
Erstellen Sie Baselines neu, wann immer sich Anwendungen ändern, und überprüfen Sie regelmäßig die Audit-Richtlinien selbst, da Oracle's AVDF documentation warnt, dass ein DBA diese ändern oder löschen kann. Rufen Sie die Einstellungen planmäßig ab und überprüfen Sie sie; CIS Safeguard 8.1 fordert diese Überprüfung mindestens jährlich.
Die Aufbewahrung erfordert dieselbe Disziplin. Stellen Sie sie auf das strengste geltende Mandat ein, mit der 12-monatigen Mindestdauer von PCI DSS als Grundlage, und behalten Sie auch die Diagnostikeinstellung, die eine Azure SQL-Pipeline speist, auf Ihrer Überwachungsliste, da deren Löschung die Sammlung still stoppen kann.
Wie Netwrix Ihnen hilft, die Datenbankaktivität zu überwachen
Der Großteil der oben genannten Arbeit, vom Festlegen des Umfangs bis zur Korrelation des Identitätskontexts, gilt unabhängig von den verwendeten Tools. Netwrix Auditor übernimmt die Erfassung, Benachrichtigungen sowie Vorher-Nachher-Details für SQL Server und Oracle, und Netwrix Access Analyzer ergänzt die Berechtigungs- und sensiblen Datenebene.
Verfolgung von Anmeldungen und privilegiertem Zugriff
Netwrix Auditor SQL Server monitoring zeichnet erfolgreiche und fehlgeschlagene Anmeldungen auf und verfolgt DBA-Aktivitäten, einschließlich privilegierter Aktionen und Änderungen der Serverrollen. Seine Oracle Database monitoring Software verfolgt erfolgreiche und fehlgeschlagene Anmeldungen und überwacht SQL-Anweisungen und Berechtigungen. Für beide Quellen können Sie Warnungen konfigurieren, um einem Analysten eine E-Mail zu senden oder ein von Ihnen definiertes Skript als Reaktionsaktion.
Auditor-Berichte dienen auch als Nachweis für die Einhaltung von Vorschriften. First National Bank and Trust of Beloit nutzt Netwrix Auditor als Hauptlösung für die OCC-Compliance und benötigt jetzt eine Stunde statt einer Woche zur Vorbereitung auf Audits. Bank of the South verwendet es, um geschäftskritische Daten zu schützen und PCI DSS sowie GLBA einzuhalten, und spart so mindestens 40 Stunden pro Jahr bei der Auditvorbereitung.
Erfassung von Vorher- und Nachherwerten bei Datenänderungen
Netwrix Auditor for SQL Server läuft standardmäßig im triggerlosen Modus, liest alle fünf Minuten das Trace-Log ohne zusätzliche Belastung und meldet, wer was wann geändert hat. Der triggerbasierte Modus fügt Vorher-Nachher-Werte für INSERT, UPDATE und DELETE hinzu, die die native Prüfung nicht bieten kann, allerdings auf Kosten einer höheren Belastung bei Servern mit hohem Transaktionsaufkommen.
Aktivitäten mit sensiblen Daten verbinden
Netwrix Auditor wendet sensiblen Datenkontext auf Tabellenebene im triggerlosen Modus an, unter Verwendung der von Ihnen konfigurierten Tabellen und Richtlinien, sodass Berichte Aktivitäten gegen regulierte Tabellen kennzeichnen können. Für tiefere Entdeckung und Berechtigungsanalyse in SQL Server und Oracle, Netwrix Access Analyzer kartiert effektive Berechtigungen und zeigt überbelichtete Daten auf, über das hinaus, was Auditor allein abdeckt.
Bereitstellung mit minimalen Auswirkungen auf die Produktion
Netwrix Auditor sammelt remote, sodass nur der triggerbasierte Modus direkt die überwachten Tabellen berührt. Die Oracle-Sammlung läuft alle zehn Minuten über den Oracle Instant Client auf dem Auditor-Server, und das Auslesen der SQL Server-Traces erfolgt alle fünf Minuten. Add-ons leiten Aktivitätsdaten an Splunk, IBM QRadar und ArcSight weiter für Teams, die bereits auf ein SIEM zentralisieren.
Setzen Sie die Überwachung der Datenbankaktivitäten in die Praxis um
Beginnen Sie mit der Instanz, die Ihre strengsten Daten enthält, legen Sie eine Basislinie fest und erweitern Sie erst, wenn der erste Alarm Satz umsetzbare Ergebnisse liefert.
Bei cloudverwalteten Workloads hängt die Abdeckung von der Datenquelle und dem Bereitstellungsmodell ab. Netwrix Access Analyzer erkennt sensible Daten und analysiert Berechtigungen in SQL Server, Azure SQL, Amazon RDS für SQL Server und Oracle.
Fordern Sie eine Demo an und sehen Sie, wie Netwrix Ihnen hilft, Datenbankaktivitäten zu überwachen, die Prüfprotokolle zu zentralisieren und Missbrauch zu erkennen, bevor es zu einer Sicherheitsverletzung kommt.
Häufig gestellte Fragen zur Überwachung der Datenbankaktivität
Teilen auf
Erfahren Sie mehr
Über den Autor
