Ziel ist es grundsätzlich lesende und ändernde Zugriffe auf schützenwerte Daten auf Datenbankebene zu protokollieren, um die Gesamtmenge der Auditdaten auf das Wesentliche zu begrenzen und damit überhaupt ein effizientes Monitoring zu ermöglichen.
Lokalisierung von vorhandenen Datenbankinstanzen
Die Datenschutzinitiative sollte grundsätzlich damit beginnen, die vorhandenen Datebankinstanzen ausfindig zu machen, da nur das geschützt werden kann, was auch bekannt ist. Hierbei sollten nicht nur die Netzwerksegmente, sonderen auch die Datenbankinstanzen des Recovery & Deasaster-, Test- und Staging-Umfelds betrachtet werden. Dies ist in einem gesonderten Dokument zur jeweiligen Datenbank bzw. Applikation zu beschreiben.
Definition und Lokalisierung von schützenswerten Daten
Da nicht jede Datenbankinstanz für das Datenbank Activity Monitoring interessant ist, sollte in diesem Schritt pro Datenbank bzw. Applikation überprüft werden, ob überhaupt sensible und schützenwerte Daten in der Datenbank vorhanden sind erfasst werden. Dies ist in einem gesonderten Dokument zur jeweiligen Datenbank bzw. Applikation zu beschreiben.
Die Informationen zur Existenz von sensiblen Daten in der Datenbank zusammen mit Informationen zum Härtungsstatus der Datenbank aus den Datenbank-Scans lassen nun die Ableitung eines Risikos für die schützenswerten Datenbanken zu. Ein errechneter Risikowert auf einer Skala von 1 bis 10 bietet nun einen guten Überblick darüber, wo der größte Handlungsbedarf besteht.
Datenklassifizierung
Das Database Activity Monitoring ist erst effizient, wenn die Anzahl der “false positives” und “false negatives” sowie der Umfang der Auditdaten minimal sind. Zur Erzielung dieser Effizienz müssen in diesem Schritt die Speicherobjekte mit sensitiven Daten identifiziert und klassifiziert werden. Eine Klassifizierung der sensiblen und schützenswerten Daten kann z. B. in unterschiedliche Datentypen wie Personaldaten, Finanzdaten, Kreditkarten Informationen, User Credential etc. erfolgen.
Regeldefinition
Im Anschluß an die Datenklassifizierung sind zu den einzelnen Datenklassen entsprechende Regeln/Policies zu definieren, die bei einem Zugriff auf die Daten der zugrunde liegenden Datenklasse anschlagen. Solche Policies müssen klar und eindeutig formuliert und gleichzeitig flexibel gegenüber regelmäßigen Änderungen in den Systemen, Datenobjekten, Benutzerrollen, den Regularien und den strategischen Unternehmensrichtlinien und -zielen sein. Beispiele von möglichen Policies sollen nachfolgend beschrieben werden:
-
- Financial Data Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf Finanzdaten monitoren.
- Personal Data Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf Personaldaten monitoren.
- Schema Change Policy – Das Database Activity Monitoring System sollte jede Änderung von Datenbankchemata und Benutzerkonten monitoren.
- Large Data Set Policy – Das Database Activity Monitoring System sollte jeden Zugriff auf große Mengen von z.B. Kundendaten erkennen und monitoren.
- Failed Login Policy – Das Database Activity Monitoring System sollte alle fehlgeschlagenen Verbindungsversuchen zum Datenbankserver monitoren.
Das Database Activity Monitoring System muß hierzu in der Lage sein bei der Regeldefinition die relevanten Daten-banken, Tabellen, Objekte und Felder entsprechend zu konfigurieren. Z. B. sollte es möglich sein eine Regel auf einer definierten Datenbank für eine bestimmte Tabelle für eine bestimmt Aktion zu erstellen.
Datenerhebung
Abhängig von den definierten Regeln kommen u.a. nachfolgende Daten in Frage, die von einem Database Activity Monitoring System erhoben werden können:
-
- Anmeldeinformationen an den Datenbanken
- Aktivitäten auf der Datenbank mit welchen Privilegien
Implementierung der entsprechenden Regeln/Policies
Die konkrete Implementierung der entsprechenden Regeln/Policies ist vollständig abhängig von der Database Activity Monitoring Lösung und ist in einem gesonderten Dokument zur Lösung zu beschreiben.