|
Neuerungen in der Oracle Database 12c (Teil IX):Der sichere Weg:
|
Diese Umstellungen führen zu einer Vereinfachung im Umgang und bei der Erstellung eines neuen Konzeptes in allen Datenbankeditionen der Version 12c. Im folgenden Artikel werden diese Neuerungen und die Migration vorgestellt.
Ein Blick zurück
Bis einschließlich der Version Oracle 11g Release 2 gab es insgesamt vier verschiedene implementierte Auditing-Verfahren in der Datenbank:
- Mandatory Auditing
- Privileged Account Auditing (SYS- Auditing)
- Standard Auditing
- Fine Grained Auditing (FGA)
Diese Varianten wurden über Initialisierungsparameter, wie z. B. AUDIT_SYS_OPERATIONS oder AUDIT_TRAIL gesteuert. In Datenbanken, die in der Version 12c auf Unified Auditing umgestellt worden sind, haben diese Parameter keinen Effekt mehr.
Bei der Konfiguration erschwerten sehr viele Audit-Befehle die Übersichtlichkeit und Ausarbeitung eines wirkungsvollen Verfahrens. Wichtige Aktionen, wie die Anpassung der Audit-Konfiguration, RMAN und Data Pump waren zudem nicht in die Überwachung einbezogen.
Die Verteilung der Auditdaten auf unterschiedliche Speicherorte (ADUMP Directory und Datenbank) machte eine einheitliche Lösung der Datenkontrolle zudem schwierig. Auf Dateisystemebene besteht ein Berechtigungskonzept für die entsprechenden Verzeichnisse und parallel wird die Zugriffskontrolle auf die Audit Views in der Datenbank geregelt. Ein Analyst, der Auditing-Daten auswertet, benötigt demnach Zugriff auf beide Quellen.
Mixed Mode als Übergang zum Unified Auditing
Bei einer Migration auf Oracle 12c kommt es nicht zum Problem, dass das bestehende Auditing-Konzept nicht mehr wirksam ist. Unmittelbar nach dem Upgrade befindet sich die Datenbank in einem so genannten „Mixed Mode“. In diesem Zustand funktioniert das traditionelle Auditing (vor Oracle 12c) auch weiterhin. Die Audit-Einstellungen bleiben erhalten.
Nach der Migration sind die zwei neuen Policies ORA_SECURECONFIG und ORA_LOGON_FAILURES sofort aktiv. Die erste Policy überwacht wichtige CREATE-, ALTER-, DROP-Anweisungen und weitere Statements. Die zweite Policy protokolliert fehlerhafte Anmeldeversuche. Bei der Umstellung sollte daher beachtet werden, dass es zu einer redundanten Datenspeicherung kommen kann. Spezielle Unified-Auditing-Einstellungen, wie das RMAN Audit, funktionieren in diesem Modus noch nicht. Im Mixed Mode steht der Parameter Unified Auditing in der v$option auf FALSE (siehe Abbildung 1).
Unified Auditing
Das AUDSYS-Schema wurde in Oracle 12c neu implementiert. Dieser Datenbank-Account ist für eine Anmeldung gesperrt. Datensätze des Auditing, werden in diesem Schema in einer partitionierten Read-only-Tabelle geschrieben. Default-mäßig wird diese im Tablespace SYSAUX abgelegt.
Sollte die Datenbank nicht beschreibbar sein, werden die Events im Betriebssystem unter dem Verzeichnis $ORACLE_BASE/audit/$ORACLE_SID abgelegt. Die entstandenen Dateien können nachträglich in die Datenbank geladen werden.
Funktionsumfang
Das Auditing der Version 12c kann neben den Standardaktivitäten die Aktionen folgender Oracle-Komponenten erfassen:
- Real Application Security (Spalten XS_*)
- Recovery Manager (Spalten RMAN_*)
- Data Pump (Spalten DP_*)
- Database Vault (Spalten DV_*)
- Label Security (Spalten OLS_*)
- FGA (Spalten FGA_*)
- SQL*Loader Direct Path
Alle überwachten Aktivitäten sind in einer einzigen zentralen View ersichtlich. In der UNIFIED_AUDIT_TRAIL sind für alle Events dedizierte Spalten selektierbar. Die Spaltennamen sind mit dem jeweiligen Präfix der Auflistung identifizierbar. Diese zentrale Sicht löst die entsprechenden unzähligen Views wie SYS.AUD$, DBA_AUDIT_TRAIL, DBA_AUDIT_SESSION, DBA_FGA_AUDIT_TRAIL usw. ab.
Migration zu Unfied Auditing
Die Aktivierung des Unified Auditing funktioniert, wie in Abbildung 2 beschrieben, bei UNIX-Betriebssystemen über das Linken der Oracle Binaries [1]. Auf Windows muss eine DLL-Datei umbenannt werden. Die Datenbank muss bei dieser Aktion heruntergefahren sein. Der Parameter Unified Auditing (siehe Abbildung 1) steht nach der Aktualisierung jetzt auf TRUE. Die traditionelle Überwachung ist damit deaktiviert und deren Initialisierungsparameter
haben jetzt keinen Effekt mehr. Die alten Audit-Pfade sollten archiviert und bereinigt werden. Bei der Migration einer Multitenant-Datenbank werden CDB und alle angeschlossenen PDBs auf einmal umgestellt.
Die Verwaltung der Aktionen, die überwacht werden, erfolgt jetzt nur noch über die sogenannten Audit Policies, die in der Datenbank hinterlegt werden. Der Prozess der Umstellung auf das neue Verfahren kann genutzt werden, um das bestehende Konzept zu analysieren und zu modernisieren.
Unified Auditing Architektur
Auditing in einer Datenbank hat immer den Nachteil, dass es die Performance negativ beeinflusst. Mit der neuen Architektur wird dieser Nachteil minimiert. Einträge werden in einem bestimmten Format abgespeichert und die Daten können in der SGA zwischengespeichert werden. Wir unterscheiden daher zwei Schreibverfahren der Audit-
Einträge:
- Queued Write Mode (Default)
- Immediate Write Mode
Im Default-Verfahren, dem Queued Write Mode, werden die Audit-Einträge zunächst in der SGA abgelegt und periodisch auf Platte geschrieben. Der Parameter UNIFIED_AUDIT_SGA_QUEUE_SIZE definiert die Größe in der SGA für die Audit-Einträge. Diese werden dann periodisch oder manuell (siehe Abbildung 3) in die Audit-Basistabelle geschrieben.
Bei dem Queued Write Mode kann es bei einem inkonsistenten Herunterfahren der Datenbank zu einem Datenverlust kommen. Die Daten können sich zu diesem Zeitpunkt noch in der SGA befinden. Zur Absicherung bietet sich der Immediate Write Mode an. Die Datensätze werden nicht zwischengespeichert, sondern sofort in die entsprechende Tabelle geschrieben. Der eingeschaltete Write-Modus kann über die View DBA_AUDIT_MGMT_CONFIG_PARAMS selektiert werden und, wie in Abbildung 4 beschrieben, online geändert werden.
Konfiguration des Unified Auditing
Die Sammlung der Audit-Daten wird im Unified Auditing mit Policies realisiert. Diese Regeln können benutzerdefiniert sein oder es können bereits bestehende vordefinierte Standards (siehe Abbildung 5) verwendet werden. Policies sind Container, um Aktionen, Privilegien, Objekte und Rollen in der Datenbank zu überwachen. Die Ausführung dieser Policies kann mit Bedingungen oder Ausnahmen verknüpft werden, wie es z. B. in Abbildung 6 zu sehen ist. Hier werden alle Einfüge- und Abfrageoperationen für bestimmte Tabellen protokolliert, wenn die Anmeldung über „sqlplus“ erfolgt ist.
Die erstellten Regeln werden mit den Befehlen AUDIT und NOAUDIT aktiviert bzw. deaktiviert. Sind sie eingeschaltet, werden die entsprechenden Events im Audit Trail erfasst. Die zweite Policy (AUDIT_DP_POLICY) überwacht alle Data Pump Jobs des User obr. Hinterlegte Konfigurationen einer Policy lassen sich über die View AUDIT_UNIFIED_POLICIES abfragen.
Auswertung des Audit Trail
Alle aufgelaufenen Audit-Datensätze können in der zentralen View UNIFIED_AUDIT_TRAIL selektiert werden (siehe Abbildung 7). Im Vergleich zum Auditing vor der Version 12c, muss man sich hier keine Gedanken machen, welche View oder welche Dateien für die Analyse herangezogen werden müssen. Bestimmte RMAN-Operationen werden ohne eine bereits bestehende Policy im Audit-Pfad protokolliert (siehe Abbildung 8). Die entsprechenden Spalten der vereinheitlichten View können dabei herangezogen werden. Der Befehl DELETE ARCHIVELOG ALL; wird hingegen nicht aufgezeichnet.
Zugriffskontrolle auf Audit-Datensättze
Oracle hat mit der Einführung in die neue Version 12c viele Mechanismen eingebaut, bei der die Verantwortlichkeiten, je nach Zuständigkeit, verteilt werden können. Beim Auditing stellt der Datenbankadministrator nur den Tablespace für die Daten zur Verfügung und verschiebt die Basistabellen hinein. Die Verwaltung der Policies und die Analyse der Daten ist auf zwei neu geschaffene Rollen verteilt:
- AUDIT_ADMIN
- AUDIT_VIEWER
Die Admin-Rolle ist den Datenbankbenutzern vorbehalten, die sich um die Verwaltung, die Definition von Regeln und um das Housekeeping kümmern. Die Viewer-Rolle beinhaltet alle Rechte zur Auswertung der Audit-Daten. In der Praxis sollten diese zwei Rollen auf zwei verschiedene dedizierte Nutzer verteilt werden.
Housekeeping
Das Package DBMS_AUDIT_MGMT, welches mit der Version 11GR2 eingeführt worden ist, wurde um den Funktionsumfang des Unified Auditing erweitert. Zu den Funktionen des Paketes gehören unter anderem das manuelle Anstoßen des Schreibens im Queued Write Mode, das Verschieben der Audit-Tabellen und die Verwaltung alter Audit-Daten. Die Archivierung und Löschung alter Datensätze kann manuell aber auch in fest hinterlegten Datenbank-Jobs erfolgen.
Fazit
Das Auditing präsentiert sich ab der Version 12c bedeutend verbessert. Es erfüllt viele Anforderungen und vereinfacht die Realisierung. Im Hinblick auf die Performance wird durch den Queued Write Mode eine Steigerung erzielt. Die einfache Entwicklung und Umsetzung eines Konzeptes setzt hier neue Maßstäbe. Man braucht nicht mehr viele einzelne Audit Statements, sondern kann gruppiert einzelne Regeln in Policies bündeln. Hervorzuheben ist, dass mit der Migration das bestehende Konzept analysiert und neue Definitionen erstellt werden. Weiterhin ist die Analyse der Daten mit einer zentralen View bedeutend einfacher geworden. Vorbei ist das Zusammensuchen der Information aus verschiedenen Speicherorten. Das Oracle Audit ist in die richtigen Bahnen gelenkt worden und gerade im Punkt Benutzerfreundlichkeit in neue Dimensionen vorgedrungen.
Ole Breimann
()
Glossar
CDB
Die Container Database ist die zentrale Datenbank in einer Multitenant-
Architektur in der Oracle Version 12c. In diese können die Plugable-Datenbanken eingeklinkt werden können.
DLL-Dateien
Dynamic Link Library Windows Dateien werden über die Betriebssystemfunktionalität bereitgestellt.
FGA
Das Fine Grained Auditing ist eine Erweiterung des klassischen Auditing,
um nur zu protokollieren, wenn gewisse Inhalte betroffen sind.
PDB
Die Pluggable Database ist eine für Anwendungen genutzte Datenbank, die
unter Verwendung der Multitenant-Architektur betrieben wird.
Abbildungen:
SQL> SELECT * FROM v$option |
Abb. 1: Überprüfung des Auditing |
$ cd $ORACLE_HOME/rdbms/lib |
Abb. 2: Aktivierung des Auditing |
BEGIN |
Abb. 3: Manuelles Schreiben des SGA Audit-Bereiches auf Platte |
SQL> BEGIN |
Abb. 4: Write-Modus und Modifikation |
|
||||||||||||||||
Abb. 5: Übersicht der vordefinierten Rollen in 12.1.0.2 |
--Anlegen der AUDIT POLICY |
Abb. 6: Arbeiten mit Policies |
1 SELECT dbusername "User",action_name "Aktion",object_schema |
Abb. 7: Analyse der Audit-Daten |
rman_device_type, event_timestamp |
Abb. 8: Audit-Einträge von RMAN-Aktivitäten |