Schatzkammer Datenbank

Vertrauen ist gut, Kontrolle zunehmend nötig: Monitoring von Datenbankaktivitäten und Konfigurationsänderungen

Das Ergebnis einer solchen Schwachstellenbewertung ist oftmals mit einer Zusammenstellung gezielter Handlungsempfehlungen verbunden und dient als erster Schritt zur Absicherung der Datenbank. Dazu zählt auch das Entfernen aller nicht benutzten Funktionen und Optionen des Datenbanksystems, die die Angriffsfläche unnötig vergrößern. Sobald eine abgesicherte Konfiguration erstellt wurde, sollte diese fortlaufend überprüft werden, um ungewollte Änderungen zu vermeiden. Dazu können Audit-Tools eingesetzt werden, die Momentaufnahmen („Snapshots“) der Konfigurationen (sowohl auf der Betriebssystem- als auch auf der Datenbankebene) vergleichen und eine Warnung ausgeben, sobald eine Änderung festgestellt wurde, die die Sicherheit der Datenbank beeinträchtigen könnte.

Neben der Absicherung der Konfiguration ist die Echtzeitüberwachung von (bestimmten) Datenbankaktivitäten ein wichtiges Mittel zur Gefahrenbegrenzung: Angriffsversuche und Datenverbrechen werden durch ein kontinuierliches Monitoring in Echtzeit erkannt und können ebenfalls verhindert werden („Data Loss Prevention“). In diesem Bereich haben sich in den letzten Jahren immer mehr Database-Activity-Monitoring-Lösungen auf dem Mark enwickelt, die eine nicht invasive Protokollierung der Datenbankaktivitäten erlauben [5].

Die Suchergebnisse der „Schatzsuche“ dienen als wichtiger Indikator dafür, auf welche Bereiche der Datenbank ein Fokus für die Überwachung gelegt werden muss, und können automatisch in das Regelwerk einer entsprechenden Database-Activity-Monitoring-Lösung übernommen werden. Die Monitoring-Lösungen lassen sich so konfigurieren, dass nur Änderungen von bestimmten Tabelleninhalten oder -strukturen berücksichtigt oder nur Aktionen eines bestimmten Nutzerkreises protokolliert werden. Eine solche Echtzeitüberwachung von Datenbankaktivitäten erkennt und meldet beispielsweise ungewöhnliche Zugriffsmuster, die auf eine SQL Injection, unberechtigte Änderungen an Finanzdaten, die Erhöhung von Privilegien eines Nutzers und Konfigurationsänderungen hindeuten.

Auch ist die Protokollierung privilegierter Benutzeraktivitäten eine Voraussetzung zur Erfüllung von Data-Governance-Vorschriften, wie z. B. des Sarbanes-Oxley Act (SOX), und Datenschutzverordnungen, wie z. B. der Payment Card Industry Data Security Standard (PCI -DSS). Diese Überwachung ist insbesondere deshalb wichtig, weil Angreifer sich häufig über solch privilegierte Benutzer unerlaubt Zugriff zur Datenbank verschaffen.

Das Monitoring von Datenbankaktivitäten ist auch ein Grundelement der bereits erwähnten Schwachstellenbewertung: So lassen sich traditionelle statische Bewertungen der Konfiguration um dynamische Bewertungen von „Verhaltensschwachstellen“ erweitern, um beispielsweise die gemeinsame Nutzung von Privilegien durch mehrere Benutzer oder eine übermäßig hohe Zahl fehlgeschlagener Datenbankanmeldungen sowie verdächtig viele Datenzugriffe in der Nacht zu erkennen. Schließlich ermöglichen einige Database-Activity-Monitoring-Technologien ebenso die Protokollierung von Nutzeraktivitäten auf der Anwendungsschicht, so dass ein Datenverbrechen nicht nur über eine direkte Verbindung zur Datenbank, sondern auch über mehrschichtige Architekturen wie SAP, PeopleSoft und die Oracle E-Business Suite erkannt wird. Technisch lassen sich die Database-Activity-Monitoring-Lösungen in der Regel durch eine nicht invasive Architektur charakterisieren – mit dem Vorteil, dass die protokollierten Datenserver nicht nennenswert belastet werden. Dazu werden leichtgewichtige Treiber auf Betriebssystemebene der Datenbankserver installiert, was keine Änderung an der Datenbank selbst oder den Anwendungen erforderlich macht.

Die Treiber überwachen den gesamten Netzwerkzugriff auf dem Datenserver sowie die Inter-Process-Communication- und Shared Memory-Bereiche, über die lokal auf die Datenbank zugegriffen wird. Mit diesem Ansatz wird eine 360-Grad-Rundumsicht über alle Aktivitäten auf der Datenbank realisiert. Die Informationen, die von den Treibern ermittelt werden, sind dabei sehr granular: So wird z. B. ermittelt, welcher Datenbanknutzer von welcher IP-Adresse oder Anwendung mit welchem SQL-Kommando auf welche Daten einer Datenbank zugreift. Ob diese gesammelten Informationen relevant sind und zwecks Auditing aufbewahrt werden, wird oftmals durch ein entsprechendes Regelwerk definiert. Das Regelwerk legt dabei fest, welche Protokollinformationen verworfen und welche gespeichert werden, beispielsweise nur die Zugriffe auf Produktionsdatenbanken von privilegierten Nutzer-Accounts. Viele Lösungen bringen auch vordefinierte Regelwerke für unterschiedliche Einsatzszenarien mit oder erlauben die automatische Regelerstellung auf Basis vorheriger Zugriffsanalysen.

Im Weiteren können die Regeln auch mit Aktionen hinterlegt werden, um z. B. in Echtzeit darüber informiert zu werden, wenn ein nicht autorisierter Client (IP-Adresse) versucht, auf schützenswerte Daten zuzugreifen, oder risikoindikative SQL-Fehlermeldungen im Produktivsystem vorkommen. Diese Informationen werden normalerweise zwecks weiterer Auswertung an eine speziell gehärtete Appliance geschickt, in der die Audit-Informationen aufbereitet werden und dem Reporting zur Verfügung stehen. Ein solch dediziertes Audit Repository in Form einer Appliance garantiert dabei eine sichere und nicht anfechtbare Verwaltung der Prüfprotokolle unter Berücksichtigung einer klaren Rollentrennung.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.