Im Datenbankumfeld versteht man unter Auditieren das Aufzeichnen von Benutzeraktivitäten. Die Oracle-Datenbank kann das seit etwa 20 Jahren. Seit Oracle Version 6 konnte protokolliert werden, wer mit welchen Befehlen auf welche Objekte zugreift oder wer welche Systemprivilegien nutzt. Diese Möglichkeiten haben aber viele Jahre lang eher ein Schattendasein unter den Datenbankfeatures geführt. Das ist z.B. daran erkennbar, dass das Auditing standardmäßig immer ausgeschaltet war und erst nach der Änderung des (statischen) Konfigurationsparameters audit_trail und dem Neustart der Datenbank genutzt werden konnte. Inzwischen wird dem Auditing aber immer stärkere Aufmerksamkeit entgegengebracht - kein Wunder, denn Sicherheitsaspekte und Compliance-Anforderungen erzwingen ein immer umfangreicheres Monitoring der Benutzeraktivitäten. Sichtbar wird diese veränderte Einstellung dem Auditing gegenüber übrigens auch in der veränderten Standardeinstellung der neusten Datenbankversion, Oracle Database 11g: Hier ist das Auditing standardmäßig für alle Befehle aktiviert, die aus der Oracle-Perspektive sicherheitsrelevant sein könnten - z.B. für den Befehl CREATE USER.

Obwohl man also schon lange die unterschiedlichsten Aktivitäten auditieren konnte, mangelte es lange an Differenzierungsmöglichkeiten. Betrachtet man beispielsweise den Zugriff auf Tabellendaten, konnte man nur feststellen, wer und wann lesend oder ändernd auf eine Tabelle zugegriffen hat. Auch ob die Aktion erfolgreich war oder nicht, wurde notiert. Die genauen Statements konnte man jedoch mit Datenbankmitteln nicht reproduzieren. Genauso wenig konnte das Auditieren an bestimmte Bedingungen geknüpft werden. Beides ist inzwischen möglich.

Vorüberlegungen

Die tatsächliche Umsetzung des Auditing ist über viele Jahre bewährt und so sehr von Routine geprägt, dass die Herausforderung eigentlich vor allem in einer angemessenen Planung besteht. Die folgenden Abschnitte stellen die Rahmenbedingungen dar, die es dabei zu berücksichtigen gilt.

Aus zwei Gründen sollte man sich zunächst gut überlegen, was das Ziel des Auditing sein soll. Zum ersten kostet Auditieren Ressourcen. Auf einer ohnehin stark ausgelasteten Datenbank könnte ein unkontrolliertes Auditing zu einer nicht mehr akzeptablen Performance führen. Anzustreben ist, das selbstgesteckte Ziel mit möglichst minimalem Einsatz zu erreichen. Minimaler Einsatz kann an dieser Stelle heißen, dass z.B. nur die wichtigen Tabellen auditiert werden, dass nur ändernde Aktionen und keine lesenden oder dass nur erfolgreiche Aktionen erfasst werden.

Aber selbst wenn die Systemperformance keinerlei Problem darstellt, ist zum zweiten zu bedenken, dass die Auditing-Daten ausgewertet werden müssen. Je größer die Datenmenge, desto schwieriger und zeitaufwändiger ist eine aussagekräftige Auswertung. Auch um den sprichwörtlichen Wald vor lauter Bäumen nicht aus den Augen zu verlieren, sollte man sich also beim Auditing auf das Nötigste beschränken. Egal was möglich ist, in der Regel macht es keinen Sinn jede Aktion zu auditieren.

Hat man die Objekte und Aktionen identifiziert, die auditiert werden sollen, muss man sich als nächstes klar darüber werden, wie weit das Auditing gefasst werden soll: Müssen die exakten Statements erfasst werden, mit denen auf Daten zugegriffen wird? Sollen auch alle Aktivitäten auditiert werden, die als SYSDBA durchgeführt werden? Soll das Auditing nur dann erfolgen, wenn bestimmte Werte geändert werden oder bestimmte Rahmenbedingungen vorliegen?

Initialisierungsparameter: Wo und wie speichern?

Über den Initialisierungsparameter audit_trail wird zunächst das Wo und Wie der Speicherung der Audit-Daten festgelegt. Er ist - wie oben bereits erwähnt - in Datenbanken vor Oracle Database 11g standardmäßig nicht gesetzt. In 11g ist die Voreinstellung audit_trail=db. Das bedeutet, dass die Audit-Daten in der Datenbank gespeichert werden.

Die Speicherung in der Datenbank erfolgt in der Tabelle aud$. Die Tabelle ist Teil des Tablespace SYSTEM. Eine Auslagerung der Tabelle in ein anderes Tablespace wird zwar gelegentlich von Kunden nachgefragt, aber nur bedingt unterstützt: Nur Kunden, die das Produkt Audit Vault einsetzen, können aud$ zur Zeit in ein anderes Tablespace auslagern. Ob diese Möglichkeit mit der nächsten Datenbankversion (Oracle11g Release 2) wie geplant allen Kunden zur Verfügung gestellt wird, bleibt abzuwarten.

Wenn der zur Verfügung stehende Speicherplatz erschöpft ist (Tablespace SYSTEM ist voll), lässt die Datenbank keine weiteren Aktionen zu, die zu Auditing-Einträgen führen würden und natürlich auch keinerlei Aktionen, die zum Wachsen des Tablespace SYSTEM führen würden. Deshalb müssen die Daten in aud$ gelegentlich gelöscht werden. Je nach Anforderung müssen die Daten natürlich zuvor in irgendeiner Form gesichert werden, z.B. durch einen Export mit Data Pump. Als möglicher Nachteil der Speicherung der Audit-Daten in der Datenbank muss in diesem Zusammenhang auf den hier erkennbaren fehlenden Schutz vor Manipulationen durch einen kriminellen DBA hingewiesen werden.

Die Datenbank verhindert auch im Fall der Speicherung auf der Betriebssystemebene weitere Aktionen, wenn dort kein Speicherplatz mehr verfügbar ist. Aber der Schutz vor dem kriminellen DBA kann ein Grund dafür sein, Audit-Daten ausserhalb der Datenbank abzulegen. Setzt man den Parameter audit_trail=os werden die Daten in ASCII-Dateien unter betriebssystemspezifischen Standardverzeichnissen abgelegt oder - unter Windows - im Applications Event Viewer. Unter UNIX / Linux kann mit dem Initialisierungsparameter audit_file_dest auch ein alternatives Verzeichnis angegeben werden, in dem die Daten abgelegt werden. Das Verzeichnis bzw. die darin angelegten Dateien können dann durch die Vergabe entsprechender Schreib-Lese-Berechtigungen vor dem Zugriff durch den kriminellen DBA geschützt werden. Natürlich setzt das voraus, dass Datenbank- und Systemadministration nicht in einer Hand liegen.

Sieht man vom Einsatz des Produkts Oracle Audit Vault einmal ab, bietet die Möglichkeit des Speicherns auf der Betriebssystemebene unter UNIX / Linux mit dem zusätzlichen Parameter audit_syslog_level schließlich den stärksten Schutz vor dem kriminellen DBA: Die Audit-Daten werden dann in das syslog des Betriebssystems geschrieben. Das syslog kann sogar auf einem anderen Rechner liegen.

Die Ablage ausserhalb der Datenbank erhöht nicht nur den Schutz der Audit-Daten, sondern sie reduziert auch die Systembelastung durch das Auditing. Ein für manche Kunden attraktiver Nebeneffekt der Entscheidung, die Daten ausserhalb der Datenbank abzulegen, besteht in der dadurch gewonnenen Möglichkeit, die Daten im XML-Format zu speichern. Dazu wird der Parameter audit_trail=xml gesetzt. Auch in diesem Fall kann man mit dem bereits erwähnten Parameter audit_file_dest das Verzeichnis festlegen, unter dem die Audit-Daten abgelegt werden.

Initialisierungsparameter: Umfang der Einzelinformationen festlegen

Die bisherigen Parametereinstellungen führen zwar dazu, dass auditiert wird, aber es liefert nur recht vage Ergebnisse. Es kann z.B. festgestellt werden, dass eine Abfrage erfolgt ist, wer sie abgesetzt hat, ob sie erfolgreich war usw., aber wie genau diese Abfrage aussah, ist nicht festzustellen. Sinnvoll wäre in vielen Fällen sicherlich, das genaue Statement zu kennen. Dies wird möglich, wenn die Parameter db und xml in modifizierter Form verwendet werden, und zwar als db,extended oder xml, extended. Diese Varianten führen dazu, dass immer der gesamte SQL-Text sowie die Bind-Variablen erfasst werden. Es ist lediglich zu beachten, dass es bezüglich der Anzeige der Bind-Variablen Einschränkungen hinsichtlich der Datentypen gibt.

Liegt das exakte Statement vor, kann man z.B. im Fall von SELECTs unter Umständen sogar noch die genaue Ergebnismenge ermitteln, die dieses SELECT geliefert hat. Das wäre möglich, wenn in der Flash Recovery-Area (oder in Flashback Data Archives; vgl. den entsprechenden Community-Tipp) die Daten noch vorlägen und mit der AS-OF-TIMESTAMP-Klausel des SELECTs darauf zugegriffen werden kann.

Initialisierungsparameter: SYSDBA und SYSOPER auditieren

Egal wie die bisher genannten Parameter konfiguriert sind: Alle Aktionen, die ein Benutzer als SYSDBA oder SYSOPER ausführt, werden nicht erfasst. Dieses Problem lässt sich aber durch die Verwendung eines einzigen Initialisierungsparameter lösen. Der Parameter heißt audit_sys_operations und muss auf den Wert true gesetzt werden.

Dieses manchmal auch als SYS-Auditing bezeichnete Verfahren ist in Bezug auf den Parameter audit_trail erläuterungsbedürftig. Zunächst einmal funktioniert das SYS-Auditing, selbst wenn der Parameter audit_trail nicht gesetzt ist. Ausserdem werden die Ergebnisse des SYS-Auditing immer ausserhalb der Datenbank gespeichert - entweder in einem vorgegebenen Verzeichnis oder in dem Verzeichnis, das im Parameter audit_file_dest angegeben ist. Das soll natürlich dazu dienen, dem SYSDBA den Zugriff auf die Audit-Daten zu entziehen (s.o.). Und schließlich wird das SYS-Auditing im XML-Format geschrieben, sofern der Parameter audit_trail entweder auf xml oder xml,extended steht.

Abschließend sei noch darauf hingewiesen, dass das SYS-Auditing nicht weiter zu steuern ist. Es werden immer alle Statements protokolliert und zwar - komfortablerweise - mit vollständigem Text.

Auditieren

Nachdem der Initialisierungsparameter audit_trail gesetzt und aktiviert ist, wird mit dem Befehl AUDIT festgelegt, welche Aktionen konkret auditiert werden sollen. Was genau möglich ist, ist umfangreich im SQL-Handbuch beschrieben, deshalb an dieser Stelle nur einige Beispiele für die Syntax:

AUDIT ALL ON tabelle1
   -- alle Aktionen, die auf TABELLENNAME zugreifen
AUDIT table WHENEVER SUCCESSFUL
   -- alle Aktionen, die erfolgreich auf Tabellen zugreifen (DML und DDL)
AUDIT update table BY user1, user2
   -- alle UPDATEs der beiden Benutzer
AUDIT session
   -- alle CONNECTs und DISCONNECTs aller Benutzer
AUDIT alter system
   -- alle ALTER SYSTEM-Befehle aller Benutzer

DBA_AUDIT_TRAIL
   -- alle Einträge in aud$
DBA_OBJ_AUDIT_OPTS
   -- alle Auditing Optionen, die für Objekte aktiviert sind
DBA_PRIV_AUDIT_OPTS
   -- alle Systemprivilegien, die auditiert werden

DBMS_FGA.ADD_POLICY(
object_name     => 'tabellenname',         -- Name der Tabelle
policy_name     => 'community_policy',     -- Name der Policy
audit_condition => 'sensiblespalte > 100', -- Bedingung unter der auditiert wird
statement_types => 'select');              -- betroffener Befehl

Zurück zur Community-Seite