Die Unternehmen müssen immer mehr Regularien bezüglich Verarbeitung und Speicherung ihrer Unternehmensdaten erfüllen. Das können branchenspezifische, wie zum Beispiel Basel II und Basel III im Bankenbereich sein, aber auch branchenunabhängige wie die EU-Datenschutzgrundverordnung DGSVO. Gerade diese Verordnung ist für viele Bereiche der Datenverarbeitung in allen Unternehmen relevant. Die meisten Anwendungen persistieren ihre Daten in Datenbanken, daher ist die Überwachung der Datenbank Aktivitäten (Database Activity Monitoring) ein wichtiger Aspekt, um die Einhaltung der Verordnungen auch nachweisen zu können.
Die Datenbank Aktivitäten, die hierbei relevant sind, können wie folgt eingeteilt werden:
- An- und Abmeldevorgang (Login/Logout)
- Schreibender Zugriff auf Applikationsdaten
- Schreibender Zugriff auf Daten, die eine Veränderung der Applikationslogik bewirken
- Lesender Zugriff auf Applikationsdaten, die vertrauliche Informationen enthalten
- User- und Rollenverwaltung
- Rechteverwaltung
- Andere privilegierte Operationen, die z.B. Audit und Export
Ein gutes Rechtemanagement der Anwendung bietet einen hohen Schutz der Daten vor unberechtigtem Zugriff, aber es schützt nicht vor der missbräuchlichen Nutzung vorhandener Rechte. Zum Beispiel besitzt in der Regel ein Account mit DBA-Privilegien die Möglichkeiten auch Daten der Anwendung zu ändern, auch wenn er dieses nicht darf. Der Besitz eines Privilegs bedeutet nicht, dass man dieses Recht auch unbeschränkt nutzen darf. Entweder kann das Privileg dem Account nicht entzogen werden (z.B. dem SYS User bei Oracle Datenbanken), oder das Privileg darf nur unter bestimmten Bedingungen genutzt werden, welches in den Policies nicht ausreichend abgebildet werden kann.
Zusätzlich ist eine Protokollierung erforderlich, um auch nachweisen zu können, dass die Sicherheitseinstellungen nicht umgangen werden. Ein gutes Rechtemanagement kann nur den Aufwand der erforderlichen Protokollierung minimieren. Je nach Implementierung und das Vorhandensein anderer Schutzmechanismen kann aber die Protokollierung entsprechend mit Einschränkungen versehen und die anfallende Datenmenge deutlich reduziert werden. Zum Beispiel kann es ausreichend sein, nur fehlgeschlagene Anmeldevorgänge zu protokollieren. Oder aber die Protokollierung der Zugriffe auf die Applikationsdaten wird auf die Verbindungen beschränkt, die nicht von der Applikation selbst stammen. Diese Einschränkungen müssen immer zu den Gegebenheiten des Systems passen.
Database Activity Monitoring muss gezielt eingesetzt werden
Die meisten SQL-Operationen, die in einer Datenbank durchgeführt werden, können einer oder mehreren der oben genannten protokollrelevanten Tätigkeiten zugeordnet werden. Daher wird gerne mal pauschal die „Überwachung der Datenbank“ gefordert. Das ist natürlich unrealistisch. Bei den meisten Datenbanken würden Datenmengen und Lasten produziert werden, die weit über denen der eigentlichen Anwendung gehen.
Oft steht hinter der pauschalen Forderung der Protokollierung aller Datenbank Aktivitäten der Umstand, die Applikationslogik nicht genau zu kennen. Das ist vor allen Dingen bei gekauften Anwendungen der Fall. Aber nur eine feingranulare Unterteilung der Daten (auf Tabellen-Ebene) ermöglicht auch ein minimales Protokollieren. Je gröber die Unterteilung ist, je mehr wird unnötig protokolliert.
Bei dem Betrieb von Oracle Datenbanken, bei dem keine feine Unterteilung der Daten vorgenommen werden kann, hat sich folgende Vorgehensweise bewährt:
- Man führt eine möglichst klare Trennung zwischen Applikation und Datenbank-Plattform, beziehungsweise Applikationsnutzern und DBAs ein. Damit ist eine bessere Identifikation kritischer Operationen möglich. Es können einfachere Regeln definiert und die Protokollmenge begrenzt werden. So kann definiert werden, dass alle Zugriffe auf Objekte in Schemas, die nicht zur Datenbank-Plattform selbst gehören, als Teil der Applikation betrachtet werden. Nur Applikationsuser dürfen dann auf Objekte dieser Schemas zugreifen, DBAs aber nicht. Sollte trotzdem ein solcher Zugriff erfolgen, so wird dieser protokolliert.
- Ebenfalls sind alle DBA-Tätigkeiten, die nicht von einer vordefinierten Gruppe von DBAs ausgeführt werden, nicht zulässig. Verstöße gegen diese Regel werden ebenfalls protokolliert.
- Ein Enforcement dieser Zuständigkeitstrennung im Sinne der „Segregation of Duty“ (SoD) Regeln, wie sie zum Beispiel durch Terminierung der Session möglich ist, wird jedoch nicht empfohlen. Zum einen können immer wieder auch False-Positives auftreten, zum anderen können begründete Ausnahmen vorhanden sein. Ein Enforcement kann aber zu einem Fehlverhalten in der Datenverarbeitung führen. Dagegen kann mit der Protokollierung den Vorfällen nachgegangen und das Protokollereignis mit den Überprüfungsergebnissen ergänzt werden. Zum Beispiel kann hier einem Protokollierungsdatensatz eine vorhandene Ausnahmegenehmigung für ein Problemfixing beigefügt werden. Damit sind solche Ausnahmen ebenfalls regularienkonform dokumentiert.
Bei Three-Tier Applikationen kann in der Regel sehr zuverlässig bestimmt werden, ob eine Verbindung über die Applikation erfolgt ist, oder nicht. Folgende Kriterien werden hierbei herangezogen:
- Liste der Servernamen und, bzw. oder der IP-Adressen
- OS Username
- Programmname
- DB-Username
Wenn eine Protokollierung über die Applikation selbst erfolgt, sind nur noch die Aktivitäten außerhalb der Applikation zu betrachten. Alle Datenbank Aktivitäten durch die Applikation selbst können dann ausgeschlossen werden. Das ist in der Regel der weitaus größte Teil aller Datenbank Aktivitäten, der in diesem Fall nicht mehr protokolliert werden muss.
Audit einschalten und vergessen
Datenbank Systeme bieten in der Regel von Haus aus Protokollierungsmechanismen. Diese werden gerne genutzt um – oft nur vermeintlich – den Anforderungen aus den Regularien gerecht zu werden. Das Datenbank-System produziert dann Protokolldaten, entweder in Tabellen innerhalb der Datenbank oder extern in Form von Files oder Systemlog-Einträgen. Diese Daten werden vielleicht noch in Backups oder in ein Archivsystem weggeschrieben, aber eine sinnvolle Verarbeitung dieser Daten erfolgt nicht. Damit ist der Sicherheitsgewinn gering und entspricht auch nicht den Anforderungen aus den Regularien. Im Falle einer notwendigen Forensik müssen oft Unmengen an Daten wiederhergestellt und ausgewertet werden. Dabei sind weder die dafür notwendigen Ressourcen vorhanden, noch kann die Forensik innerhalb eines akzeptablen Zeitfensters realisiert werden.
Ein weiteres Problem sind die Restriktionen der Systeme, die nicht berücksichtigt werden. Oft werden nur Teile der notwendigen Informationen geschrieben, ohne dass man sich derer bewusst ist. Auch können verschiedene Ereignisse nicht miteinander verknüpft werden, was aber für eine gute Forensik elementar ist.
Betrachten wir es am Beispiel von Oracle Datenbanken. Heute wird in den meisten Oracle Datenbanken bereits die Aktivitäten des DBA-Accounts SYS vollumfänglich protokolliert (auditiert). Viele DBAs setzen zusätzlich einige Regeln, um weitere Datenbank Aktivitäten zu protokollieren. Aber eine ausreichende Zugriffskontrolle auf Applikationsdaten durch DBAs erfolgt in den seltensten Fällen. Der Grund liegt in der Unübersichtlichkeit der Regeln und vor allen Dingen auch in den Performance Einbußen begründet, wenn mehr als eine Basis-Protokollierung zum Einsatz kommt. Mit dem neuen Unified Auditing wurde zwar einiges verbessert, aber die grundsätzlichen Probleme wurden damit nicht gelöst.
Gerade die vollumfängliche Protokollierung des SYS Users stellt ein großes Problem dar. Es werden die Datenbank Aktivitäten vieler Prozesse protokolliert, die der internen Steuerung dienen, wie zum Beispiel bei der RAC Systemsteuerung, oder beim Backup. Im Ergebnis werden große Mengen an Audit-Daten geschrieben, die schnell die Speicherkapazität übersteigen können. Außerdem werden beim SYS User nur die rohen Statements gespeichert und nicht die ausgeführten SQL-Kommandos. Dieses erschwert zusätzlich die Auswertung ganz erheblich.
Nicht die Datenerhebung ist das Problem, sondern das Auswerten
Die Datenerhebung und das Housekeeping lassen sich zwar mit den bordeigenen Mitteln grundsätzlich realisieren, aber es gibt keine Möglichkeiten diese Daten mit denen anderer Datenbanken zusammenzuführen, zu aggregieren und auszuwerten. Aber nur so sind viele Auffälligkeiten bei den Datenbankzugriffen zu erkennen. Spätestens hier muss auf andere Tools zurückgegriffen werden.
Protokolldaten müssen, wenn sie für die Langzeitarchivierung ausgelagert wurden, gelegentlich für eine nachträgliche Analyse wieder eingelesen werden. Auch dieses bieten die On-Bord Systeme nicht.
Resümee
Die On-Bord Protokollmechanismen bieten zwar grundsätzlich Möglichkeiten die Datenbank Aktivitäten zu protokollieren, aber es bestehen Restriktionen und es fehlen Funktionen die Daten auch leicht auswerten zu können. Das ist aber erforderlich, um die notwendigen Nachweise der Compliance vorweisen zu können.
Folgende Funktionen müsste ein System besitzen, um die erhobenen Daten auch sinnvoll auswerten zu können:
- Erfassung der Aktivitäten
- Erkennen (Parsen) der Operationen
- Bewertung der Operationen gemäß einem Regelwerk
- Klassifizieren und Aggregieren der Daten
- Ggf. Ergänzung mit Daten anderer Quellen, z.B. mit Daten aus einer „Configuration Management Database“ (CMDB)
- Speicherung und Archivierung der Daten
- Einlesen älterer Archive für eine erneute Auswertung
- Ggf. Weiterleiten der Daten an ein nachgelagertes System, z.B. einem „Security Information and Event Management System“ (SIEM)
Neben diesen Forderungen für das Database Activity Monitoring muss das System auch die eigenen Zustandsänderungen (z.B. Ausfall von Komponenten), Änderung an den Systemeinstellungen und den hinterlegten Regeln protokollieren. Nur so kann sichergestellt werden, dass die Protokollierung auch regelkonform umgesetzt ist, beziehungsweise ob und in welchem Zeitraum welche Systeme aus der Überwachung herausgefallen sind.