Logo Oracle Deutschland   DBA Community  -  Januar 2015
Oracle Audit Vault and Database Firewall - Teil 1 (Audit Vault)
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co KG

Oracle bietet seit Mitte 2013 ein Produkt mit dem Namen Oracle Audit Vault and Database Firewall (AVDF) zum Kauf an. In der Namensgebung erhalten sich die beiden Produkte, durch deren Zusammenlegung AVDF entstanden ist: Das erste, Oracle Audit Vault (AV), ein Data Warehouse, in dem Audit Daten aus Datenbanken unterschiedlicher Hersteller abgelegt werden. Das zweite, Oracle Database Firewall (DBF), eine Firewall, die den Netzwerkverkehr zu Datenbanken unterschiedlicher Hersteller überwacht, protokolliert und unerwünschte oder durch SQL Injection manipulierte Zugriffe auf Datenbanken unterbindet. Bestandteil beider Produkte war jeweils ein eigenes umfangreiches Berichtswesen.

AV und DBF überschnitten sich vor allem im Bereich der Protokollierung und des Berichtswesens. Daher lag ein Zusammenlegen der Repositories für das Speichern der Protokolle und das Erzeugen von Berichten nahe. Zusätzlich wurde im Bereich der Steuerung der beiden Komponenten einiges verändert und aufeinander abgestimmt. Und schliesslich kam im Bereich Auditing das lang erwartete Software Development Kit (SDK) in den Lieferumfang. Mit diesem SDK können auch Produkte angebunden werden, für die Oracle keine eigene Anbindung (plugins) liefert.

Zwar änderte sich mit der Zusammenlegung der Produkte technisch einiges, aber auch hinsichtlich der Lizenzierung ergaben sich Änderungen. Gerade für kleinere und mittlere Installationen fallen nämlich deutlich geringere Lizenzkosten an: Das Repository ist kostenlos. Lediglich für jeden überwachten Server entstehen Lizenzgebühren und zwar für jeden angeschlossenen Server zur Zeit 4736 EURO / CPU - unabhängig von der Anzahl der darauf installierten und überwachten Systeme und unabhängig davon, ob eine Komponente des Produkts (AV oder DBF) oder beide Komponenten eingesetzt werden.

Dieser Tipp der DBA Community stellt vor Ein weiterer Tipp der Community wird in gleicher Weise die Komponente DBF vorstellen.

Installation
Die Hard- und Software Voraussetzungen für die Installation aller Komponenenten von AVDF sowie der daran anzubindenden Systeme sind im Installationshandbuch vollständig beschrieben. Deshalb wird an dieser Stelle nur kursorisch darauf eingegangen.

Die Installation von AV ist banal, denn das Produkt wird in Form eines ISO Image als Software Appliance geliefert. Das Konzept software appliance ist schon einmal in einem Community Artikel zu Oracle Key Vault vorgestellt worden: Die Kundin / der Kunde stellt einen X86-64bit Rechner hier mit mindestens 2GB RAM und 125GB Festplattenspeicherplatz zur ausschliesslichen Nutzung für AV zur Verfügung. Nach der Installation Auf diesem Rechner wird AV durch das Starten des ISO Image installiert. Der installierte Softwarestack besteht aus dem Betriebssystem Oracle Linux, einer Oracle Datenbank und einer graphischen Benutzeroberfläche, der Oracle Audit Vault Management Konsole. Die Bestandteile des Stacks werden hier nur der Vollständigkeit halber angeführt, ihre Nennung ist aber eigentlich überflüssig: Denn nach der Installation darf die Software in keiner Weise verändert, sondern nur in festgelegtem Ausmass konfiguriert werden.

Der Installationsprozess erwartet nur zwei Eingaben: Angaben zur IP Adresse (IP Adresse, Mask und sofern nötig Gateway) für den AV Server und ein Einmalpasswort, das als Passphrase bezeichnet wird und bestimmten Mindestanforderungen genügen muss. Es ermöglicht das erstmalige Einloggen in die AV Management Konsole. Zum Abschluss der Installation erscheint das Bild links.

Konfiguration
Erstes Einloggen in der Management Konsole Im nächsten Schritt müssen noch Benutzer und ihre Passwörter konfiguriert werden. Das geschieht in der gerade erwähnten Konsole, die über einen Browser unter der bei der Installation angegebenen URL erreichbar ist. Zum Einloggen wird, wie links erkennbar, das Einmalpasswort benötigt.


Konfiguration nach Abschluss der Installation Nach dem erstem Einloggen öffnet sich die Bildschirmseite, die auf der Abbildung links zu sehen ist. Es werden eingerichtet
  1. Ein Administrator, der keinen Zugriff auf die Audit Daten hat, jedoch für das Einrichten von AV, Backup und Recovery sowie der angeschlossenen Systeme verantwortlich ist. Dieser Administrator ist grundsätzlich ein sogenannten Superadministrator (superadmin). Ein superadmin kann weitere Benutzer als superadmin oder auch nur als admin einrichten. Während ein superadmin Zugriff auf alle eingerichteten Systeme hat, kann der Zugriff eines admin auf ausgewählte Systeme beschränkt werden. Die Webseite gibt für den ersten superadmin den Benutzernamen AVADMIN vor, empfehlenswert ist jedoch das Einrichten eines eigenen Benutzers mit eigenem Namen.
  2. Ein Auditor, der Zugriff auf die Audit Daten aller angeschlossenen Systeme hat und Berichte über alle Audit Daten erzeugen kann. Analog zum superadmin handelt es sich bei diesem zuerst eingerichteten Auditor um einen sogenannten superauditor. Ein superauditor kann weitere Auditoren als superauditor oder auditor einrichten. Letztere haben - ebenfalls analog zu den admins - nur Zugriff auf die Audit Daten ausgewählter Systeme. Auch für den ersten Superauditor, der nach der Installation eingerichtet wird, ist ein Benutzername vorgegeben (AVAUDITOR). Auch in diesem Fall ist es natürlich empfehlenswert, einen eigenen Benutzer mit eigenem Namen einzurichten.
  3. Das Passwort für den Benutzer root, der zum Beispiel bei Bedarf von der Rechnerkonsole aus den AV Rechner herunterfahren kann.
  4. Das Passwort für den Benutzer support, so dass man sich für bestimmte Aufgaben auch ohne root-Privilegien auf dem AV Rechner anmelden kann.
Für produktive Umgebungen sollte nun noch das DNS Setup sowie das Einrichten von NTP Servern erfolgen. Für die Zwecke dieses Tipps kann das jedoch vernachlässigt werden.

AV und Datenbank koordinieren
DA AV SELBST KEINERLEI AUDITING AUF IRGENDWELCHEN SYSTEMEN DURCHFÜHRT, STAMMEN ALLE DATEN IN AV AUS DEM NATIVEN AUDITING DER ANGEBUNDENEN SYSTEME. Das Zusammenspiel von AV und der zuliefernden Systeme muss also für jedes Produkt separat aufgesetzt werden. Dies geschieht jeweils in mehreren Schritten, die logisch aufeinander aufbauen. Die Schritte werden, sofern sie in AV zu vollziehen sind, für diesen Tipp vom Superadministrator AVADMIN ausgeführt. Host registrieren
  1. In AV wird zunächst der Server (host) registriert, von dem aus Audit Daten übermittelt werden. Im Menupunkt HOSTS werden dazu lediglich Rechnername und IP Adresse angegeben und gespeichert. Der Screenshot links zeigt das Ergebnis. Wichtig ist hier der Agent Activation Key in der fünften Spalte. Er wird im nächsten Schritt benötigt.

  2. Die Übermittlung der Audit Daten an AV besorgt ein Agent, der dazu auf dem registrierten Host installiert wird. Die Agent Software wird aus AV unter HOSTS und dem Unterpunkt AGENT auf der linken Seite (siehe vorangegangene Abbildung) in Form einer jar-Datei auf den Host heruntergeladen. Dort wird er durch einfaches Entpacken in ein beliebiges Verzeichnis - hier /home/oracle/agent/ - installiert.
    orcl /home/oracle/Desktop> java -jar agent.jar -d /home/oracle/agent
    Checking for updates...
    Agent is updating. This operation may take a few minutes. Please wait...
    Agent updated successfully.
    Agent installed successfully.
    If deploying hostmonitor please refer to product documentation for additional installation steps.
    Die Meldung bezüglich des hostmonitor kann für diesen Tipp ignoriert werden. Allerdings muss der Agent noch aus dem Verzeichnis bin des gerade angelegten Home_Verzeichnis_des_Agenten - hier also aus /home/oracle/agent/bin - gestartet werden. Zum erstmaligen Starten wird der Activation Key benötigt, der beim Registrieren des Host in AV erstellt wurde (siehe Text und Abbildung unter Punkt 1). Die Eingabe des Key erfolgt verdeckt.
    orcl /home/oracle/agent/bin> ./agentctl start -k
    Enter Activation Key:
    Agent started successfully.
    
    Agent Status Nicht nur die Meldung Agent started successfully zeigt an, dass die Aktion erfolgreich war, sondern auch die in der Abbildung links erkennbare Statusmeldung Running aus der Spalte AGENT STATUS des Menupunkts HOSTS in AV.
  3. Target registrieren
  4. Nun ist zu bedenken, dass auf einem Host mehrere und auch unterschiedliche Produkte Audit Daten produzieren können. Das bedeutet wiederum, dass es nicht ausreicht, nur jeden Host zu registrieren, sondern es muss auch jedes dort installierte und Audit Daten liefernde Produkt spezifiziert oder - wie es in AV heisst - registriert werden. Das Registrieren geschieht im Menupunkt TARGETS. Die Liste der unterstützten targets, die über sogenannte out-of-the box plugins angesprochen werden, listet das in der Einleitung bereits erwähnte Handbuch auf.

    Im Bild links erkennt man, wie eine Oracle Datenbank registriert wird. Die Eingaben sind weitgehend selbsterklärend. Erklärungsbedürftig ist lediglich die Angabe eines Benutzers und seines Passworts in der unteren Hälfte der Bildschirmseite: Da die Audit Daten aus der Datenbank kommen, wird ein Benutzer benötigt, der Zugriff auf diese Daten hat. Hier wird der Benutzer SYSTEM verwendet, allerdings sollte für Produktivumgebungen selbstverständlich ein anderer Benutzer verwendet werden. Dieser Benutzer muss bereits angelegt sein, sonst angelegt werden. Die nötigen Privilegien erlangt er, indem SYS das Skript oracle_user_setup.sql aus dem Verzeichnis $AGENT_HOME/av/plugins/com.oracle.av.plugin.oracle/config/ ausführt.
    SQL> show user
    USER is "SYS"
    SQL> @oracle_user_setup system setup
    Granting privileges to SYSTEM ... Done.
    Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning, Oracle Label Security and Oracle Database Vault options
    
    SYSTEM ist hier als Benutzername angegeben, der Parameter SETUP führt dazu, dass alle Audit Trails der betroffenen Datenbank ausgewertet werden können. Nicht auswertbar sind allerdings zum Beispiel die Vorher- / Nachherwerte aus den Redolog Dateien. Der Zugriff darauf ist separat einzurichten über den Parameter REDO. Alle verfügbaren Parameter und die damit verbundenen Möglichkeiten sind im Handbuch erläutert.

  5. Audit Trails registrieren
  6. Es bleibt ein einziger Schritt zum Abschluss der Vorbereitungen. Denn Oracle Datenbanken produzieren unterschiedliche Typen von Audit Daten: Daten, die in Tabellen wie AUD$ und FGA_LOG$ abgelegt sind oder andere, die in Betriebssystemdateien gespeichert werden. Konsequenterweise müssen also auch diese Typen für eine Oracle Datenbank in AV registriert werden. Dies geschieht im Menu TARGETS im Auswahlpunkt AUDIT TRAILS. Die Abbildung links zeigt das Ergebnis der gemachten Einträge.

    Es sind zwei Audit Trails eingerichtet und - wie an den grünen Pfeilen in der Spalte COLLECTION STATUS erkennbar ist - gestartet worden. Der erste Eintrag verweist auf ein Directory - konkret auf /home/oracle/app, in dem der Audit Trail des SYS Auditing für diese Datenbank gespeichert wird. Der zweite Eintrag verweist auf die Tabelle AUD$ des Benutzers SYS, weil der normale Audit Trail dieser Datenbank auf DB,EXTENDED gesetzt ist.
Test des Beispiels
In der Datenbank ist für die Tabelle EMP das Auditing so eingerichtet worden, dass alle Aktionen auf dieser Tabelle protokolliert werden. Nun wird getestet, ob die Audit Daten erfolgreich nach AV übertragen werden. Folgende Aktionen finden in der Datenbank statt:
SQL orcl> show user
USER is "SYS"
SQL orcl> SELECT * FROM scott.emp WHERE deptno = 13-3;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7782 CLARK      MANAGER         7839 09-JUN-81       2450                10
  7839 KING       PRESIDENT            17-NOV-81       5000                10
  7934 MILLER     CLERK           7782 23-JAN-82       1300                10

SQL orcl> connect scott/tiger
Connected.
SQL orcl> SELECT * FROM scott.emp WHERE deptno = 18-8;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7782 CLARK      MANAGER         7839 09-JUN-81       2450                10
  7839 KING       PRESIDENT            17-NOV-81       5000                10
  7934 MILLER     CLERK           7782 23-JAN-82       1300                10
  
Audit Trails registrieren
Loggt man sich als Auditor in AV ein, kann man unter einer ganzen Reihe vorgefertigter Berichte auswählen, die alle mit Oracle Application Express (APEX) erstellt wurden. Im Bild links ist der Bericht über alle Aktivitäten ausgewählt worden, ausserdem wurde das Abfrageergebnis auf die Zeilen beschränkt, in der die Zeichenfolge WHERE DEPTNO in der Spalte COMMAND TEXT enthalten ist. Da die Audit Daten annähernd in Echtzeit nach AV übertragen werden, sind die Aktionen, die kurz zuvor in der Datenbank durchgeführt wurden, bereits in dem Bericht sichtbar.

Weitere ausgewählte Features von AV
Dieser Tipp ist insgesamt schon recht lang geworden, deshalb hier noch einige wichtige Informationen zu AV nur in Kurzform.

Da es unsinnig wäre, erst nach Auswertung von Berichten auf Unzulässigkeiten reagieren zu können, verfügt AV über ein Alert-System, das bereits beim Einfügen von Audit Daten in AV überprüt, ob ein Alarm ausgelöst werden muss. Welche Möglichkeiten hier zur Verfügung stehen, beschreibt der Auditor' Guide.

Da für das Zusammenspiel von Oracle Datenbanken und AV ein privilegierter Benutzer eingerichtet wird (siehe oben), ist es zum Teil auch möglich, von AV aus das Auditing einer Datenbank zu konfigurieren. Dies geschieht über Policies. Die Vorgehensweise wird ebenfalls im Auditor's Guide beschrieben.

Das wichtigste an Audit Daten ist nicht die Sammlung, sondern die Auswertung dieser Daten. Wem dazu die vorgefertigten Berichte nicht ausreichen, der kann mit einem beliebigen Berichtsgenerator, der auf Oracle Datenbanken zugreifen kann, eigene Berichte erzeugen. Dazu ist die Tabellenstruktur, in der Daten in AV abgelegt werden, umfassend im Auditor's Guide beschrieben.

AV kann mit BIG-IP ASM und ArcSight SIEM integriert werden.

Zurück zum Anfang des Artikels

Zurück zur Community-Seite