Ein vollständiges Audit aller Lesezugriffe auf eine große Tabelle kann sehr viele Einträge erzeugen. Häufig ist die eigentliche Frage enger: Wer hat eine besonders schützenswerte Spalte – etwa Gehalt, Kontonummer oder Gesundheitsdaten – in einer Abfrage verwendet? Oracle Fine-Grained Auditing (FGA) kann eine Policy an genau solche Spalten binden und optional zusätzlich eine Zeilenbedingung prüfen.
DBMS_FGA schreiben ihre Audit Records in den UNIFIED_AUDIT_TRAIL. Das ermöglicht eine gemeinsame Auswertung, ändert aber nichts daran, dass Policy-Scope, Aufbewahrung und Zugriff auf Auditdaten kontrolliert werden müssen.Policy für eine sensible Spalte definieren
Das folgende Beispiel auditiert SELECT-Anweisungen, die in HR.EMPLOYEES auf die Spalte SALARY zugreifen. Die Policy wird mit DBMS_FGA.ADD_POLICY angelegt und standardmäßig aktiviert:
BEGIN
DBMS_FGA.ADD_POLICY(
object_schema => 'HR',
object_name => 'EMPLOYEES',
policy_name => 'AUDIT_SALARY_READ',
audit_column => 'SALARY',
statement_types => 'SELECT'
);
END;
/Mit audit_condition lässt sich die Policy zusätzlich auf Zeilen begrenzen, die eine fachliche Bedingung erfüllen. Über audit_column_opts bestimmen Sie, ob bereits der Zugriff auf eine der genannten Spalten (Standard ANY_COLUMNS) oder nur der Zugriff auf alle aufgeführten Spalten einen Eintrag auslöst. Für die konkrete Definition sollten Sie die verwendete Datenbankversion und die unterstützten Spalten prüfen; FGA ist beispielsweise nicht für Out-of-line-LOB-Spalten gedacht.
Einträge kontrollieren und interpretieren
Nach einem kontrollierten Testzugriff können Auditoren die Einträge im Unified Audit Trail prüfen. Für die Analyse sind neben Benutzer und Zeit auch Objekt, Aktion, Policy und – sofern verfügbar und freigegeben – SQL-Text hilfreich:
SELECT event_timestamp,
dbusername,
object_schema,
object_name,
action_name,
unified_audit_policies,
sql_text
FROM unified_audit_trail
WHERE object_schema = 'HR'
AND object_name = 'EMPLOYEES'
AND event_timestamp > SYSTIMESTAMP - INTERVAL '1' DAY
ORDER BY event_timestamp DESC;Ein Audit Record bedeutet nicht automatisch „eine Zeile gelesen“: Die Policy erfasst den Zugriff im Kontext der SQL-Anweisung und erzeugt nicht für jede passende Ergebniszeile einen separaten Datensatz. Nutzen Sie FGA daher für die Frage, welche Abfrage auf sensible Inhalte zielte, nicht als zeilenweise Änderungs- oder Zugriffshistorie.
Vor dem Produktivbetrieb
- Schutzbedarf und präzise Zielspalten mit Datenschutz, Fachbereich und Audit-Verantwortlichen festlegen.
- Mit erlaubten und nicht erlaubten Testabfragen kontrollieren, wann die Policy tatsächlich feuert.
- Auditvolumen unter realistischer Last beobachten; breite Bedingungen auf stark frequentierten Tabellen vermeiden.
- SQL-Text und Bind-Werte können sensible Inhalte enthalten: Zugriff, Weitergabe und Aufbewahrung des Trails entsprechend schützen.
- Auditdaten regelmäßig auswerten, archivieren und nach freigegebener Retention bereinigen.
Fazit
FGA hilft, Datenzugriffe granularer zu beobachten, als es ein pauschales Tabellen-Audit erlaubt. Der wirksame Einsatz hängt von sorgfältig gewählten Spalten und Bedingungen, einem getesteten Audit-Trail und einer klaren Retention ab. Für 26ai sollte das Team zudem die Integration in Unified Auditing und die Berechtigungen für Policy-Verwaltung und Auswertung berücksichtigen.
Weiterführend: Oracles Referenz zu DBMS_FGA, die Anleitung zu Value-Based Fine-Grained Auditing und zum Einrichten von Audit Policies.