Logo Oracle Deutschland   DBA Community  -  Januar 2012
Oracle Audit Vault: Einfach installieren und testen
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Oracle Audit Vault, das Datawarehouse für Datenbank Audit Daten, ist inzwischen seit fast 5 Jahren verfügbar. Es handelt sich dabei nicht um ein Stück Basistechnologie wie eine Datenbank oder ein Betriebssystem, sondern um eine fertige Lösung für den Bereich Security & Compliance. Oracle Audit Vault ermöglicht es Unternehmen, Audit Daten aus Oracle, Microsoft SQL Server, Sybase ASE und IBM DB2 (LUW) Datenbanken zentral und geschützt vor Manipulationen zu speichern und datenbankübergreifend auszuwerten. Die Auswertung erfolgt entweder über vorgefertigte Berichte aus dem Lieferumfang von Audit Vault oder über eigene Berichte, die über beliebige SQL fähige Berichtsgeneratoren erstellt werden können. Ein eingebautes Jobsystem inklusive Attestierungsfunktion erlaubt die zeitgesteuerte automatische Ausführung dieser Berichte. Zusätzlich können Sicherheitsbeauftragte über Alerts zeitnah per Email oder sogenannte Trouble Tickets auf Verstöße gegen Compliance- und Sicherheitsvorschriften hingewiesen werden. Der Lieferumfang von Oracle Audit Vault umfasst neben einer Enterprise Edition der Oracle Datenbank (EE) die Datenbankoptionen Partitioning zur optimierten Speicherung der Daten, Oracle Advanced Security (ASO) zur Verschlüsselung der Datenübertragung zum Audit Vault Server und Oracle Database Vault (DV) zum Schutz der gespeicherten Daten vor Manipulationen zum Beispiel durch Datenbankadministratoren. Alle Komponenten sind in einem günstigen Lizenzpreis gebündelt (nähere Informationen dazu im letzten Abschnitt des Tipps).

Im Dezember 2011 wurde das neuste Release von Oracle Audit Vault mit der Versionsnummer 10.3 freigegeben. Während die Vorgängerversionen alle auf Datenbanken der Version 10.2 basierten, stellt nun die zur Zeit aktuellste Datenbankversion (11.2.0.3) das Repository zur Speicherung und Auswertung der Daten. Das neue Release bietet den Anlass für eine Anleitung zur einfachsten Installation und funktionalen Teststellung von Oracle Audit Vault. Alle dafür benötigten Software Komponenten sind über Downloads bei Oracle kostenlos verfügbar: Entweder zur freien Benutzung oder unter einer Lizenz zum Testen. Falls Sie also mitmachen möchten, stellen Sie lediglich einen X64-Rechner mit ausreichenden Ressourcen zur Verfügung (siehe unten), auf dem Sie die Software installieren, die in diesem Tipp verwendet wird. Wer sich vorher nochmals einen Überblick über das Thema Auditing verschaffen möchte, findet diesen zum Beispiel im Handbuch Oracle Database Security Guide oder in kompakterer Form in dem vor etwa einem Jahr erschienen Community Artikel zum Thema Auditing.

Dieser Artikel besteht aus folgenden Abschnitten, die über die Links in den nächsten Zeilen direkt erreicht werden können:

Übersicht über eine Audit Vault Lösung

Eine Audit Vault Lösung besteht immer aus drei Komponenten:
System im Überblick
  1. Es gibt immer einen Audit Vault Server, der für die Speicherung und Auswertung der Audit Daten verantwortlich ist. Der Audit Vault Server wird über eine eigene Konsole verwaltet, den Audit Vault Administrator. Hier steht ein Dashboard zur schnellen Übersicht bereit, werden Berichte angestoßen und Alerts definiert, mit denen auf Unregelmäßigkeiten aufmerksam gemacht werden kann.

  2. Es gibt immer mindestens eine Datenbank, in der Audit Daten anfallen. Eine solche Datenbank wird auch als Quelldatenbank (source database) bezeichnet. Oracle Audit Vault unterstützt als Quelldatenbanken selbstverständlich Oracle, aber auch Microsoft SQL Server, Sybase ASE und IBM DB2 (LUW) Datenbanken. Was und wie auditiert wird, wird mit den üblichen Mitteln der betroffenen Quelldatenbank festgelegt. Im Fall einer Oracle Datenbank dienen dazu also zum einen die Initialisierungsparameter AUDIT_TRAIL und AUDIT_SYS_OPERATIONS sowie der Befehl AUDIT, zum anderen das Fine Grained Auditing. Die Implementierung des Auditing kann vollständig in der Quelldatenbank erfolgen, je nach Konfiguration aber auch zum größten Teil über den Audit Vault Server zentral gesteuert werden.

  3. Die Verbindung zwischen Quelldatenbanken und Audit Vault Server wird über Agenten hergestellt. Es gibt immer mindestens einen Agenten. Ein Agent steuert das Kopieren der Audit Daten aus der Quelldatenbank oder den Quelldatenbanken zum Audit Vault Server und kann für mehrere Quelldatenbanken auch auf unterschiedlichen Rechnern verantwortlich sein. Für das Kopieren verwendet ein Agent sogenannte Kollektoren. Es gibt spezielle Kollektoren für die Nicht-Oracle Datenbanken und drei unterschiedliche Kollektoren für Oracle Datenbanken.

    • Den Kollektor DBAUD für die Audit Daten, die in der Datenbank in den Tabellen SYS.AUD$, SYS.FGA_LOG$ und DVSYS.AUDIT_TRAIL$ gespeichert werden. Bei Verwendung dieses Kollektors kann der Agent auf dem Rechner des Audit Vault Servers, auf dem Rechner der Quelldatenbank oder einem beliebigen anderen Rechner installiert werden, solange dieser beliebige andere Rechner über Netzwerkverbindungen zum Audit Vault Server und zur Quelldatenbank verfügt.

    • Den Kollektor OSAUD für die Audit Daten, die in Betriebssystemdateien gespeichert werden. Bei Verwendung dieses Kollektors muss der Agent auf dem Quellsystem installiert sein.

    • Den Kollektor REDO zum Erfassen von Vorher- und Nachherwerten durch Auslesen der Redo Logs. Bei Verwendung dieses Kollektors kann der Agent auf dem Rechner des Audit Vault Servers, auf dem Rechner der Quelldatenbank oder einem beliebigen anderen Rechner installiert werden, solange dieser beliebige andere Rechner über Netzwerkverbindungen zum Audit Vault Server und zur Quelldatenbank verfügt.

    Um Manipulationen zu verhindern, erfolgt die Übertragung der Daten zum Audit Vault Server verschlüsselt und nahezu in Echtzeit.

Vorbereitung

Zur Zeit steht Oracle Audit Vault nur für x86-64 Linux zur Verfügung. Als Betriebssystem wird also eine der im Server Installation Guide aufgelisteten Distributionen benötigt. Die Oracle Variante steht kostenlos hier zum Herunterladen zur Verfügung. Das Betriebssystem kann entweder auf einem physisch vorhandenen Server installiert werden oder auf einem virtuellen Server. Soll ein virtueller Server verwendet werden, bietet sich als Virtualisierungssoftware zum Beispiel Oracle Virtual Box an (einschließlich extension pack!), das ebenfalls kostenlos hier zur Verfügung steht. Falls auf Oracle Virtual Box installiert wird, sollten mindestens 4 GB Arbeitsspeicher zur Verfügung stehen. Als Festplattenspeicherplatz genügen für diesen Tipp 30 GB, die Virtual Box erst bei Bedarf allokiert. Im Rahmen der Installation kann zusätzlich das Package oracle-validated-nnn.x86_64.rpm genutzt werden. Es ist Teil der Oracle Distributionen (für andere Distributionen kann es hier heruntergeladen werden) und vereinfacht besonders die Installation von Testdatenbanken, indem es zusätzliche für die Datenbankinstallation benötigte Packages installiert, Betriebssystemparameter anpasst, die Gruppen oinstall und dba einrichtet sowie einen Benutzer namens oracle anlegt. Im Übrigen wird das System so eingerichtet wie im Installation Guide beschrieben.

Da in diesem Tipp davon ausgegangen wird, dass auf einem einzigen physischen bzw. virtuellen Server gearbeitet wird, und da zusätzlich mit mehreren unterschiedlichen Umgebungen gearbeitet wird, ist es überlegenswert, die Umgebungsvariablen nicht über die Standarddateien des Betriebssystems (zum Beispiel .login) einzurichten, sondern in einem Shell Script zu speichern, das bei Bedarf aufgerufen werden kann. Es könnte zum Beispiel für eine Instanz namens orcl orcl.sh heißen und für die Bash Shell folgendermassen aussehen:
export ORACLE_SID=orcl
export ORACLE_BASE=/oracle
export ORACLE_HOME=/oracle/product/dbhome
export LD_LIBRARY_PATH=/oracle/product/dbhome/lib 
export PATH=/oracle/product/dbhome/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/oracle/bin
# Prompt mit SID zur leichteren Identifikation unterschiedlicher Terminalfenster
export PS1='$ORACLE_SID $PWD> '
Es wird eine Oracle Datenbank installiert, die als Quelldatenbank dienen wird. Falls die dafür benötigte Software nicht bereits vorliegt, ist sie hier zum Herunterladen verfügbar. Bitte beachten Sie nochmals den Lizenzhinweis. Die Installation der Datenbank erfolgt mit dem Aufruf des Oracle Universal Installer (OUI) über ./runInstaller. Für die Zwecke dieses Tipps genügt eine Enterprise Edition Datenbank ohne Optionen, die als single instance erstellt wird. Wählt man im OUI unter Install Type Typical install aus, werden auch die Beispielschemata installiert, so dass Tabellen zur Verfügung stehen, für die das Auditing eingerichtet werden kann.

Nach der Datenbankinstallation wird als Benutzer SYSDBA das Auditing für den Test so eingerichtet, dass der komplette Text von SQL Statements einschließlich der Bindevariablen im Auditing erfasst wird (--1). Ausserdem sollen alle Aktionen des SYSDBA (--2) erfasst werden. Schließlich wird das Auditing für die Tabelle EMP des Benutzers SCOTT so eingerichtet, das alle Aktionen auf dieser Tabelle protokolliert werden (--3). Da die ALTER SYSTEM Befehle statische Initialisierungsparameter betreffen, wird abschliessend die Datenbank durchgestartet (--4).
ALTER SYSTEM SET audit_trail=db,extended SCOPE=spfile;   -- 1
ALTER SYSTEM SET audit_sys_operations=true SCOPE=spfile; -- 2
AUDIT ALL ON scott.emp;                                  -- 3
STARTUP FORCE                                            -- 4
Zum Abschluss der Vorbereitungen wird noch die Software für den Audit Vault Server und für den Audit Vault Agenten heruntergeladen. Beide Komponenten sind nach Akzeptieren der Lizenzbedingungen kostenlos hier zu finden. Damit stehen nun ein laufendes System mit einer Oracle Datenbank sowie die im weiteren Verlauf des Tipps benötigte Software zur Verfügung.

Installation des Audit Vault Servers

Es ist NICHT möglich, eine beliebige Datenbank zu installieren und durch Konfiguration zu einem Audit Vault Server umzufunktionieren. Vielmehr MUSS die Audit Vault Server Datenbank von dem eigens dafür vorgesehenen Installationsmedium in ein eigenes ORACLE_HOME installiert werden. Die Umgebungsvariablen dafür sind analog zum obigen Beispiel etwa folgendermassen zu setzen:
export ORACLE_SID=av
export ORACLE_BASE=/oracle
export ORACLE_HOME=/oracle/product/11.2.0/avhome
export LD_LIBRARY_PATH=/oracle/product/11.2.0/avhome/lib 
export PATH=/oracle/product/11.2.0/avhome/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/oracle/bin
export PS1='$ORACLE_SID $PWD> '
Auch diese Variablen werden in einem Shell Skript zum Beispiel unter dem Namen av.sh gespeichert. Nach Aufrufen des Skripts wird der Audit Vault Server ebenfalls mit ./runInstaller über den OUI der heruntergeladenen Software installiert.

Die Installation beginnt wie gewohnt mit Abfragen zu Security Updates und Installations Optionen. Für das Testsystem benötigt man keine Updates, und es soll sowohl die Software installiert als auch der Audit Vault konfiguriert werden. Als Installationstyp gibt man in Schritt 3 Basic Installation an. (Die Option Advanced Installation erlaubt zum Beispiel die Installation als Real Application Cluster (RAC)). Man gelangt zur Bildschirmmaske mit dem Schritt 4. Zwei Eingaben sind erläuterungsbedürftig.
Installation Schritt 4
Als Name des Administrators ist avadmin angegeben. Nur die hier angegebene Person kann die Strukturen des Audit Vault verwalten, zum Beispiel Agenten einrichten. Dabei hat die Person NICHT das Recht, die Berichte des Audit Vault zu starten oder anderweitig auf die im Audit Vault Server gespeicherten Daten zuzugreifen. Zugriff auf diese Daten hat nur die Person avauditor, die im Bild als Audit Vault Auditor angegeben wurde. Dies dient dem Prinzip der Funktionstrennung und Aufgabenverteilung, und dieses Prinzip ist auch in weiteren Punkten für Audit Vault durchgesetzt. Denn es gibt zwar nach wie vor den Benutzer SYSDBA und dieser startet zum Beispiel auch die Audit Vault Server Datenbank, allerdings hat er weder die Möglichkeit, die Strukturen des Audit Vault Servers zu manipulieren, noch hat er Zugriff auf die gesammelten Audit Daten. Beides wird durch die Datenbankoption Database Vault vor jedem Zugriff durch SYSDBA geschützt. Auch das Anlegen zusätzlicher Benutzer, etwa weiterer Auditoren, oder das Ändern von Benutzerpasswörtern muss mit einem Database Vault spezifischen Benutzer angelegt werden, der standardmäßig so heisst wie der Audit Vault Administrator - allerdings mit dem Zusatz DVA und in diesem Fall also avadmindva. Wer mit der Option Database Vault vertraut ist, erkennt vielleicht, dass es sich dabei um den Benutzer mit der Rolle Database Vault Account Manager handeln muss. Die Database Vault typischen Benutzer können im Übrigen auch im Rahmen einer Advanced Installation selbst konfiguriert werden.

Die Installation und Konfiguration benötigt einige Minuten und wird mit dem abschliessenden Hinweis auf die URLs beendet, unter denen die Datenbankkonsole des Enterprise Manager (https://rechnername:5500/em) und der Audit Vault Administrator Konsole (https://rechnername:5500/av) zu erreichen sind. Zu beachten ist bei einem Neustart, dass BEIDE Konsolen gleichzeitig mit dem folgenden Befehl von der Kommandozeile aus gestartet werden müssen:
avctl start_av
Zwischenschritt: Da mit der Installation des Audit Vault Server nun die zweite Datenbank auf dem Testsystem läuft, sollte der Listener angepasst werden. Um aus beiden Umgebungen einen Listener starten zu können, werden die Inhalte der vom OUI angelegten Konfigurationsdateien zusammengefasst und in beiden Umgebungen identisch abgelegt. Es ist in diesem Zusammenhang lediglich wichtig, dass die Portnummer für den Listener aus der Umgebung der Audit Vault Server Installation verwendet wird, da dieser standardmäßig während der Installation zum Beispiel in die Konfiguration der Audit Vault Konsole einfließt. Die Datei listener.ora liegt standardmäßig unter $ORACLE_HOME/network/admin und könnte folgendermassen aussehen:
SID_LIST_LISTENER = (SID_LIST = 
              (SID_DESC = (GLOBAL_DBNAME = orcl.de.oracle.com)(ORACLE_HOME = /oracle/product/dbhome)
                 (SID_NAME = orcl))
              (SID_DESC = (GLOBAL_DBNAME = av.de.oracle.com)(ORACLE_HOME = /oracle/product/11.2.0/avhome)
                 (SID_NAME = av)))
LISTENER =(DESCRIPTION_LIST =
    (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = oel57.de.oracle.com)(PORT = 1522))))
ADR_BASE_LISTENER = /oracle
WALLET_LOCATION =
 (SOURCE = (METHOD = FILE)
           (METHOD_DATA = (DIRECTORY = /oracle/product/11.2.0/avhome/network/admin/avwallet)))
SSL_CLIENT_AUTHENTICATION = FALSE

Installation eines Audit Vault Agenten

Es mag auf den ersten Blick merkwürdig erscheinen, aber die Installation des Agenten beginnt mit einem Schritt im Audit Vault Server. Doch bei näherem Hinsehen lässt sich das erklären: Daten können in eine Datenbank nur durch vorhandene Benutzer eingefügt werden. Nur über einen solchen Benutzer kann der Agent also arbeiten. Gleichzeitig muss der Agent einen Namen erhalten, damit der Audit Vault Server eine Zuordnung zwischen dem Benutzer und dem Agenten herstellen kann. Beides wird mit einem einzigen Befehl des Audit Vault Configuration Assistant (avca) in der Umgebung des Audit Vault Servers von der Kommandozeile aus erreicht.
avca add_agent ľagentname communityagent -agenthost hostname.domain 
Enter agent user name: benutzer         -- wird bei der Eingabe nicht angezeigt
Enter agent user password: benutzerpwd  -- wird bei der Eingabe nicht angezeigt
Re-enter agent user password: benutzerpwd
Es folgt die Meldung, dass der Agent erfolgreich angelegt wurde. Man kann nun die Gelegenheit nutzen, die Audit Vault Administrationskonsole erstmals aufzurufen und sich darin vom Erfolg der Aktion zu überzeugen. Dazu loggt man sich als AVADMIN (s.o.) mit der Rolle AV_ADMIN ein, wählt den Reiter Management und anschließend in der Menuzeile Agent aus. Man sieht etwa folgendes Bild:

Anlegen des Agenten

Nun wird der Agent selbst installiert. Auch er wird in ein eigenes ORACLE_HOME installiert. Wieder kann man sich eines Shell Skripts bedienen, das die Umgebungsvariablen setzt. Es könnte agent.sh heissen und folgendermassen aussehen:
unset ORACLE_SID
export ORACLE_BASE=/oracle
export ORACLE_HOME=/oracle/product/agent
export LD_LIBRARY_PATH=/oracle/product/agent/lib
export PATH=/oracle/product/agent/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/oracle/bin
export PS1='AGENT $PWD> ' 
Das Löschen der Umgebungsvariable ORACLE_SID ist wichtig. Ist die Variable gesetzt, kann das zu einem Scheitern der Installation führen!

Installation eines Agenten Es folgt der Aufruf des OUI aus dem Installationsmedium für den Audit Vault Agenten in der Umgebung des Agenten. Im Einstiegsbildschirm ist als erstes der Agentenname einzutragen. Beim Aufruf des OUI ist hier avagent eingeblendet, aber natürlich ist das nicht der Name, der oben festgelegt wurde. Der richtige Name muss also communityagent heissen. Es bleiben noch der oben festgelegte Benutzername (benutzer) und das dazugehörige Passwort (benutzerpwd) sowie der Connect String zum Audit Vault Server anzugeben, wo dieser Benutzer und der Agent ja bereits bekannt sind.

Nach Anklicken von NEXT geht es dann ohne weitere Angaben zügig zur Installation, die in wenigen Minuten abgeschlossen ist.

Für diesen Tipp muss der Agent nach einem eventuellen Herunterfahren des Servers bzw. der virtuellen Maschine aus der Umgebung des Agenten mit folgendem Befehl neu gestartet werden:
avctl start_agent


Einrichten der Kollektoren

Es sollen nur zwei der drei für Oracle Datenbanken zur Verfügung stehenden Kollektoren installiert werden: Der DBAUD Kollektor, der für die in der Datenbank gespeicherten Audit Daten zuständig ist - oben wurde der Parameter AUDIT_TRAIL auf db,extended gesetzt - und der OSAUD Kollektor, der für die Daten zuständig ist, die im Rahmen des Auditing des SYSDBA immer in Betriebssystemdateien gesammelt werden. Der Redo Kollektor, der für Vorher- und Nachherwerte verantwortlich ist, wird nicht installiert, weil etwas mehr Vorbereitung erforderlich wäre und das den Rahmen dieses ohnehin schon umfangreichen Tipps endgültig sprengen würde.

So wie der Agent zum Einfügen der Audit Daten in den Audit Vault Server dort einen Benutzeraccount (benutzer) benötigt (s.o.), ist er bzw. sein Kollektor auch in der Quelldatenbank auf einen Benutzer angewiesen, der zum Beispiel den Zugriff auf die Tabelle AUD$ und die Audit Einstellungen der Quelldatenbank ermöglicht. Dieser Benutzer kann zum Beispiel quellbenutzer heissen. Zur Ausstattung dieses Benutzers mit den benötigten Privilegien, stellt Oracle das Skript zarsspriv.sql zur Verfügung, das sowohl in der Umgebung des Agenten als auch in der des Audit Vault Server unter $ORACLE_HOME/av/scripts/streams/source abgelegt ist. Es wird auf der Quelldatenbank nach Anlegen des Benutzers durch SYSDBA ausgeführt.

Installation eines Agenten
Wie man sieht, wird zunächst der Name des angelegten Benutzers abgefragt, dann erfolgt die Angabe, ob dieser Benutzer die Privilegien für die beiden anzulegenden Kollektoren (SETUP) oder für alle Kollektoren (REDO_COLL) erhalten soll.
Quelldatenbank im Audit Vautl Server einrichten
Nun werden in der Umgebung des Audit Vault Servers mit der Utility avorcldb dem Audit Vault Server die Informationen über die Quelldatenbank bekannt gemacht


Kollektoren hinzufügen
und dann die Kollektoren hinzugefügt. Falls bereits ein gleichnamiger Kollektor für diese Datenbank existiert oder jemals existiert hat (!), erhält man eine Fehlermeldung. Man installiert dann einen funktional identischen Kollektor mit einem anderen Namen (Details im Handbuch).
Agent für die Kollektoren einrichten
Noch zwei kleinere Schritte bleiben zu tun, bevor das Gesamtsystem getestet werden kann: Der Agent muss in die Lage versetzt werden, die Kollektoren zu betreiben. Dazu werden über den Aufruf von avorcldb aus der Umgebung des Agenten Einträge in einem Wallet und der Datei tnsnames.ora der Quelldatenbank gemacht.

Da nun alle Komponenten über die notwendigen Informationen zur Zusammenarbeit verfügen, können die Kollektoren jetzt gestartet werden. Das geht von der Kommandozeile aus zum Beispiel mit dem Befehl
avctl start_collector -collname DBAUD_Collector -srcname testdb
Kollektor starten
oder auch aus dem Audit Vault Administrator heraus. Loggt man sich dort mit der Rolle AV_ADMIN ein und geht über den Reiter Management in den Menüpunkt Collectors sieht man nach dem Starten des Kollektors DB_AUD das Bild links.

Natürlich muss auch noch der Kollektor OS_AUD gestartet werden.

Funktionales Testen des Systems

Audit Daten erzeugen Zum Testen führt man nun als Benutzer SCOTT und SYSDBA einige Aktionen auf der Tabelle EMP aus.
Audit Server Beispielbericht
Die Ergebnisse lässt man sich nach dem Einloggen als Auditor über einen Bericht im Audit Vault Administrator anzeigen, zum Beispiel im Reiter Audit Reports im Bereich Default Reports unter Access Reports den Bericht Activity Overview. Es handelt sich um Application Express Berichte, die angepasst, gespeichert und als PDF ausgegeben werden können. Im Beispiel ist zusätzlich die Spalte SQL Text ausgewählt worden, und es sind zwei Bedingungen formuliert worden, die im oberen Teil des Bildschirms eingeblendet sind.

Wer mag, kann natürlich weitere Tests durchführen, zum Beispiel mit dem Fine Grained Auditing (FGA), oder das System erweitern, indem man mit dem Package DBMS_AUDIT_MGMT die Audit Daten auf der Quelldatenbank nach Übertragen auf den Audit Vault Server löscht bzw. die Dateigröße der Dateien mit Audit Daten auf maximal 2 GB begrenzt (das Arbeiten mit dem Kollektor OSAUD erfordert diese Eingrenzung zwingend). Wie man dabei vorgeht, erklärt ein Tipp aus dem November 2011.

Lizenzierung einer Audit Vault Lösung

Die Lizenzierung erfolgt separat für den Audit Vault Server und die Agenten.

Weil es sich bei Oracle Audit Vault um eine Lösung handelt, werden nicht die einzelnen Komponenten - Enterprise Edition Datenbank, Option Advanced Security, Option Database Vault, Option Partitionierung - lizenziert, sondern es gibt nur einen Gesamtpreis, der die Grundlage für die ausschließlich CPU basierende Lizenzierung liefert. Zur Zeit beträgt im Oracle Store der Listenpreis pro CPU 57.500,00 U.S. Dollar. Wenn man diesen Preis vergleicht mit dem Preis, der durch die Addition der einzelnen Listenpreise der Komponenten entsteht (93.500,00 U.S. Dollar), wird deutlich, dass Oracle Audit Vault eine ausgesprochen preisgünstige Lösung darstellt.

Auch Agenten werden ausschließlich pro CPU lizenziert - und zwar nach den CPUs des Rechners oder der Rechner auf dem / denen eine Quelldatenbank oder mehrere Quelldatenbanken laufen. Die Anzahl der Datenbanken auf einem Datenbankserver ist unerheblich. Der Listenpreis pro Agent beträgt zur Zeit im Oracle Store 3.500,00 U.S. Dollar pro CPU.

Da es sich bei Oracle Audit Vault nicht um ein Datenbank Produkt handelt, sondern um eine Lösung, enthält übrigens das Handbuch Oracle Database Licensing Information keine Informationen zu dieser Lösung.

Weiterführende Informationen

Nicht alles Wissenswerte über Oracle Audit Vault kann auf diesem begrenzten Raum dargestellt werden. Wer nach der Lektüre des Tipps oder nach dem Durcharbeiten dieser kompakten Teststellung meint, dass Audit Vault eine gute Ergänzung zur eigenen Sicherheitsarchitektur sein könnte, der findet hier mehr Informationen:

Audit Vault Handbücher

Audit Vault Webseite


Zurück zur Community-Seite