11.2
Auditing
273
Im Oracle Enterprise Manager finden Sie Unterstützung rund um das Thema
»Sicherheit« über die Menüpunkte »Administration«, »Sicherheit« und »Stan-
dardverzeichnis«.
Abb. 11.4: Die Startseite zum Thema Sicherheit im Enterprise Manager
Einige Prozeduren und Funktionen aus dem Systemkatalog sind auf den Benutzer
»PUBLIC« gegranted, d.h. jeder darf sie ausführen.
Warum sind Execute-Rechte, die nach PUBLIC gegranted sind, gefährlich? Sie bieten
eine Angriffsfläche über sogenannte PL/SQL-Injektionen. Da die Pakete mit dem
PUBLIC-Privileg von jedem ausgeführt werden können, der einen Account in der
Datenbank hat, sind sie besonders gefährlich. Weitere Informationen zum Thema
PL/SQL-Injektionen finden Sie in Kapitel 19, »Erweiterte Sicherheitsthemen«.
11.2 Auditing
Auditing ist ein wichtiger Teil des Sicherheitskonzepts. Auch wenn alle Datenban-
ken nach dem Sicherheitsstandard Ihres Unternehmens aufgesetzt sind und aktu-
ell Punkte der Policy erfüllt sind, ist nicht garantiert, dass es nicht trotzdem zu
Sicherheitsverletzungen kommt. Auditing liefert wichtige Informationen an das
Intrusion Detection System. Auditing ermöglicht eine nachträgliche Auswertung
COUNT(*)
----------
20000000
Kapitel 11
Sicherheit und Überwachung
274
von Sicherheitsproblemen oder -vorfällen. Darüber hinaus ermöglichen Audit-
Informationen das Erkennen von potentiellen Sicherheitsverletzungen. Angriffe
auf die Datenbank finden in der Regel über einen längeren Zeitraum statt. Die
Vorgehensweise vieler Hacker besteht aus einem schrittweisen Sammeln von
Informationen und dem Erlangen weiterer Rechte. Eine solche Attacke kann sich
über Wochen oder Monate hinziehen.
Aber auch für die Applikation selbst liefert Auditing unverzichtbare Informatio-
nen. Schließlich garantieren Sicherheits-Policies nur, dass die Datenbank als sol-
che sicher vor unberechtigten Zugriffen ist. Jede Applikation besitzt darüber
hinaus eine eigene Zugriffskontrolle, mit deren Hilfe die Rollen der einzelnen
Mitarbeiter umgesetzt werden. Leider trifft man immer noch auf Datenbankappli-
kationen, bei denen die Zugriffskontrolle durch die Applikation auf dem Client
oder Applicationserver vorgenommen wird. Die Zugriffskontrolle kann einfach
außer Kraft gesetzt werden, indem eine Verbindung zur Datenbank über eine
andere Applikation oder eines der zahlreichen Tools vorgenommen wird. Hier lie-
fert Auditing zumindest eine nachträgliche Kontrollmöglichkeit. Aber auch für die
User-Rezertifizierung spielt Auditing eine wichtige Rolle.
Oracle Auditing ist in das Datenbankbetriebssystem integriert, und es gibt keine
Möglichkeit, dies zu umgehen. Die Aktionen auf der Datenbank werden geloggt,
unabhängig davon wie der Zugriff erfolgt. Oracle Auditing unterscheidet die fol-
genden Arten:
Der Speicherort der Audit-Sätze wird als Audit Trail bezeichnet. Oracle bietet zwei
Möglichkeiten:
Database Audit Trail
File System Audit Trail
Auditing-Art Beschreibung
Session Auditing Aufzeichnung von Login-Versuchen
Statement Auditing Dient der Überwachung von ausgewählten Befehlen oder
Befehlstypen unabhängig von den Objekten, auf die sie ange-
wandt werden.
Object Auditing Basiert auf der Überwachung ausgewählter Datenbankobjekte
unabhängig von der verwendeten SQL-Anweisung oder den
benutzten Privilegien.
Privilege Auditing Es wird die Anwendung bestimmter Systemprivilegien aufge-
zeichnet. Diese Auditing-Art ist unabhängig vom Benutzer oder
den Objekten, auf die zugegriffen wird.
Fine Grained Auditing
(FGA)
Ermöglicht ein feinmaschiges Auditing bis auf Zeilen- und
Spaltenebene.
Tabelle 11.1: Die Arten des Oracle-Auditing
11.2
Auditing
275
Der Audit Trail wird durch den Init-Parameter »AUDIT_TRAIL« spezifiziert.
Wird der File System Audit Trail eingeschaltet, dann schreibt Oracle die Audit-
Sätze in das Verzeichnis, das durch den Parameter »AUDIT_FILE_DEST« spezi-
fiziert wird. Tabelle 11.2 beschreibt die möglichen Werte für den Parameter
»AUDIT_TRAIL«.
Unabhängig von den Einstellungen des Parameters »AUDIT_TRAIL« können
Aktivitäten überwacht werden, die mit der SYSDBA- und der SYSOPER-Rolle erfol-
gen. Dazu muss der Init-Parameter »AUDIT_SYS_OPERATIONS« auf »TRUE«
gesetzt werden. Diese Audit-Informationen werden ausschließlich in das Verzeich-
nis »AUDIT_FILE_DEST« geschrieben.
Bei Verwendung des Database Audit Trail werden die Audit-Informationen in der
Tabelle SYS.AUD$ (bzw. in der Tabelle SYS.FGA_LOG für Fine Grained Auditing)
gespeichert.
Parameterwert Bedeutung
DB Auditing ist eingeschaltet und zeigt auf den Database Audit Trail-
Die Sätze werden in die Tabelle SYS.AUD$ geschrieben.
DB_EXTENDED Entspricht dem Parameter »DB«. Zusätzlich werden die Spalten
SQLBIND und SQLTEXT gefüllt. Darin befinden sich die Binde-
Variablen und der SQL-Text.
OS Auditing ist eingeschaltet. Die Sätze werden in Dateien des Betriebs-
systems geschrieben. Ausnahme: Windows-Betriebssysteme.
NONE Auditing ist ausgeschaltet.
Tabelle 11.2: Die Werte für den Parameter »AUDIT_TRAIL«
Hinweis
Für Windows-Betriebssysteme gibt es keine Möglichkeit, den Audit Trail in das
Windows-Dateisystem zu schreiben. Der Initialisierungsparameter »AUDIT_FI-
LE_DEST« existiert auf dieser Plattform nicht. Alle Audit-Sätze werden in das
Event Log des Betriebssystems geschrieben.
Hinweis
Die Tabelle AUD$ befindet sich im Tablespace SYSTEM. Oracle empfiehlt, die
Tabelle nicht in einen anderen Tablespace zu verschieben. Sehen Sie genügend
Platz im Tablespace SYSTEM vor, um die Einträge für das Auditing aufnehmen
zu können. Standardmäßig existiert kein Housekeeping für AUD$. Sie müssen
das Archivieren öder Löschen älterer Einträge selbst organisieren.

Get Oracle 12c - Das umfassende Handbuch now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.