Auditing für die Datenbank

Die Sicherheit der Datenbank soll durch die Nutzung von AUDITING-Optionen erhöht werden. Der Artikel zeigt einen Überblick über die bisher zur Verfügung stehenden Auditing-Möglichkeiten. Darüber hinaus werden auch die Neuigkeiten des Oracle 10g Release 2 in diesem Umfeld diskutiert.

Häufig ist es nicht nur wichtig zu wissen, wie eine Zugriffskontrolle auf firmensensitive Daten zu gestalten ist, sondern auch, wie eine sinnvolle Protokollierung von Zugriffen und Aktionen innerhalb der Datenbank erfolgt. Hierbei hilft das Auditing. Das klassische Auditing unterscheidet vier Formen:

• Mandatory Auditing
• SYS Auditing (Das sind alle Aktionen, die vom User SYS durchgeführt werden.)
• Standard Auditing
• Fine Grained Auditing (FGA)

Auf die beiden letztgenannten Formen, das Standard Auditing und das FineGrained Auditing (FGA), kann man einen besonderen, programmiertechnischen Einfluss nehmen.

Mandatory Auditing

Das Mandatory Auditing wird vom System automatisch ausgeführt. Es kann nicht vom Administrator unterdrückt werden. Unter Unix werden die Informationen per Default in das Verzeichnis $ORACLE_HOME/rdbms/audit geschrieben. Microsoft zeigt diese Information in seiner Ereignis-Anzeige an. Dabei werden sämtliche Startup- und Shutdown Aktionen bei Benutzern mit SYSDBA- oder SYSOPER-Privilegien mitprotokolliert.

Unter Unix kann ein anderes Verzeichnis als Aufbewahrungsort dieser Informationen genutzt werden, sobald der Datenbankparameter AUDIT_FILE_DEST verändert wird. Ebenso kann nun durch das Setzen von AUDIT_TRAIL=XML die Ausgabe als XML-Datei in das Betriebssystem erfolgen. Mit der neuen View V$XML_AUDIT_TRAIL können die DBAs diese Informationen mit einer Abfrage lesen.

SYS Auditing

Bei dieser Form des Auditing werden alle Aktionen des Users SYS und der Benutzer mit SYSDBA- und/oder SYSOPER-Privilegien mitprotokolliert. Die Aktivierung erfolgt durch das Setzen des statischen init.ora Parameters AUDIT_SYS_OPERATIONS. Die Speicherung erfolgt analog zu der beim Mandatory Auditing. Für diese Form ist das Setzen des Parameters AUDIT_TRAIL nicht erforderlich!

Bei diesen beiden Formen des Auditing besteht die Gefahr darin, dass geeignete Vorkehrungen für die Vermeidung des Plattenüberlaufs getroffen werden müssen.

Ebenfalls besteht die Möglichkeit, dass Benutzer mit entsprechenden DBA-Rechten auf Betriebssystemseite die gesammelten Informationen verändern oder löschen. Zur Behebung dieser Möglichkeit der Manipulation dient nun bei Unix-basierten Systemen die Nutzung der SYSLOG() Funktionalität als neues Feature.

Das Besondere daran ist, dass diese Information beliebig (z. B. auf einem Remote Server) in einer syslog.conf Datei abgelegt werden kann, ohne dass die DBAs eine Zugriffsmöglichkeit besitzen. Der Informationsfluss erfolgt hier über die Zuweisung zu einem Daemonprozess.

Standard Auditing

Das Einschalten des Standard Auditing erfolgt über den Parameter AUDIT_TRAIL.

Das Standard Auditing zielt dabei auf die Protokollierung von:

• Privilegien: Auditing von Systemprivilegien
• Schemaobjekte: SELECT, DML-Statement, GRANT, REVOKE auf Tabellen, Views, Sequenzen, Standalone Stored Procedures oder Functions und Packages
• Statements: DDL- oder DML-Statements

Für das Standard Auditing mittels Statements, Privilegien und Schemaobjekten kann eine Klausel über erfolgreiches Ausführen (WHENEVER SUCCESSFUL), nicht erfolgreiches Ausführen (WHENEVER NOT SUCCESSFUL) oder für beide Auditing Zustände (both) gesetzt werden. Hinzu kommt beim Statement Auditing noch die Option, ob das gleiche Statement innerhalb einer Session nur einmal (BY SESSION) oder jedesmal bei Ausführung in derselben Session (BY ACCESS) einen Audit-Eintrag erzeugen soll.

Es ist dabei zu beachten, dass das Auditing über die Privilegien dabei etwas detaillierter ist als ein Auditing über Schemaobjekte. Zum Beispiel wird beim Statement Auditing mit der TABLE Klausel auf CREATE TABLE, DROP TABLE und ALTER TABLE Bezug genommen. Beim Privileg Auditing (z. B. DROP TABLE) wird nur auf eines von diesen drei Privilegien abgezielt.

Die Speicherung der hiermit generierten Informationen kann entweder im Betriebssystem stattfinden oder innerhalb der Datenbank. Das Standard Auditing arbeitet bei der Speicherung der Informationen innerhalb der Datenbank mit der Tabelle SYS.AUD$ und die Abfrage der dort gespeicherten Informationen wird mit der View DBA_AUDIT_TRAIL durchgeführt.

Fine Grained Auditing (FGA)

Im Gegensatz dazu beruht das Fine Grained Auditing (FGA) auf der Protokollierung von Transaktionen, die auf einer Tabelle oder View ausgeführt werden und eine entsprechende Policy besitzen. Die Informationen für ein Auditing mit FGA werden aus der Tabelle SYS.FGA_LOG$ mittels der Data Dictionary View DBA_FGA_AUDIT_TRAIL gewonnen. Darüber hinaus kann ab Oracle 10g Release 2 nun auch die View DBA_COMMON_AUDIT_TRAIL genutzt werden, die Informationen aus dem Standard Auditing und aus dem FGA aufnimmt.

Das FGA kann im Gegensatz zum Standard Auditing ohne das Setzen der Oracle Datenbankparameter AUDIT_TRAIL und AUDIT_SYS_OPERATIONS initialisiert werden: Es ist besonders beim FGA zu beachten, dass es in früheren Releases nur dann funktionierte, wenn der Optimizer auf cost-based und nicht auf rule-based eingestellt war. Bei der rule-based Methode kann ein unnötiger Audit Event Trigger ausgelöst werden und die Audit-Informationen unnötig anwachsen lassen.

DBMS_FGA Package

Mit dem DBMS_FGA-Package können die FGA-Einträge sehr einfach verwaltet werden. Hierbei wird zuerst eine Audit Policy erstellt, mit der dann weiter gearbeitet werden kann. Diese Policy sammelt Audit-Informationen. Die mit Oracle 10g Release 2 eingeführte Neuerung der spaltenbasierten Beschränkung bei Tabellen und Views lässt das FGA für einzelne, sicherheitsrelevante Spalten zu. Hierdurch werden nun weniger Auditing-Informationen generiert als in den vorhergehenden Releases.

Auslösemechanismen

Für das Auslösen einer Policy reicht es aus, wenn die Audit-Bedingung auf NULL gesetzt wird bzw. ganz fehlt. Dadurch wird gewährleistet, dass auf jeden Fall ein Audit-Eintrag erzeugt wird, sobald die entsprechende Aktion (Statement-Typ) auf einer Spalte durchgeführt wird. Die Audit-Funktion wird immer als autonome Transaktion ausgeführt, die damit keinerlei Einfluss auf das eigentliche Statement hat. Das bedeutet, dass auch die eigentliche Policy immer einen Audit-Datensatz generiert. Auch das Protokollieren eines Merge-Kommandos ist damit möglich. Dazu müssen nur die entsprechenden Update und Insert Statements in einer Policy vorhanden sein. Für das Auditing wird dann hierbei nur ein Satz gebildet.

FGA und Trigger

Im Gegensatz zum Einsatz von Triggern ermöglicht das FGA, neben den DML- auch abgesetzte SELECT-Statements gegen die zugrunde liegende Tabelle oder View mitzuprotokollieren. Vorteile von FGAs gegenüber Triggern sind:

• Trigger lösen bei jedem DML-Statement aus. Das FGA veranlasst nur ein einmaliges Audit bei einer Policy.
• Durch die nur einmalige Auslösung kommt es zu einem Performancevorteil!
• Das FGA ist auch für SELECT-Statements möglich; bei Triggern sind SELECT-Statements nicht möglich.
• Trigger können keinen weiteren Instead-of-Trigger beobachten, der an demselben Objekt feuert. Das FGA beobachtet alle Policies einer Basistabelle.

FGA und Standard Auditing

Das FGA bietet folgende Vorteile gegenüber dem Standard Auditing:

• Es werden feiner granulierte Informationen generiert.
• Ausschluss unnützer oder sogar falscher Informationen.
• Das FGA ist jederzeit zu implementieren. Es ist kein Ändern von Datenbankparametern wie z. B. AUDIT_TRAIL nötig.
• Durch die innerhalb der Datenbank integrierte Funktionalität ist ein Umgehen des Auditings unmöglich.

Durch die feiner zu granulierende Informationsgenerierung wird es dem DBA durch das FGA erleichtert, auf Zugriffe von sensitiven Daten entsprechend zu reagieren. Er kann sich zum Beispiel sofort informieren lassen, wenn ein Zugriff erfolgt. Des Weiteren werden Informationen nicht unnötig gesammelt, sondern es kann ganz gzielt protokolliert werden, wie und von wem die sensitiven Informationen innerhalb der Datenbank genutzt werden.

Fazit

Die dargestellten Möglichkeiten helfen, die Zugriffe und Aktionen auf eine Datenbank und auf firmensensitive Daten gezielt zu protokollieren. Sie sind nicht zur Schaffung von „Datenfriedhöfen„ gedacht! Deshalb ist ein sehr sorgsamer Umgang mit diesen Funktionalitäten notwendig. Denn eine übertriebene Datensammlung geht immer mit einem Performanceverlust einher.

Klaus Günther (info@ordix.de).