Security, Cloud Computing, IOS and real-time event streaming: 2014

26. September 2014

DOAG SIG Security 2014 in Hamburg: Enterprise User Security for DBAs #eus4dbas

Auf der SIG Security der DOAG habe ich über das Thema Enterprise User Security für DBAs referiert oder anders gesagt "Wie erfülle ich innerhalb einer Stunde Compliance- Anforderungen?".
Im Nachgang die Folien auf Slideshare:

15. September 2014

Bedrohung Verlust der Verfügbarkeit: In-Memory mal anders erklärt

Um es mal auf den Punkt zu bringen: Geniale Konzepte sollten auch weitererzählt werden. Mit der Oracle In-Memory Option hat Oracle gezeigt, wie man mit einem Patch-Release erhebliche Mehrwerte schaffen kann. Die Aktivierung dieser Option ist sehr einfach, also das Gegenteil von komplex!

27. August 2014

Oracle DB Security: Enterprise User Security für DBAs (EUS4DBAS)

Einführung

Die Idee mit diesem Post ist zu zeigen, wie sinnvolle Security in dem Betrieb von Datenbanken verwendet werden kann. Heute sind Unternehmen und Behörden sehr vielen Anforderungen ausgesetzt. Nicht nur die geschäftlichen Anforderungen, sondern vor allen Dingen die gesetzlichen Anforderungen gilt es, sinnvoll und effektiv umzusetzen. Es soll eine Nachhaltigkeit entstehen, die neue Anforderungen mehr oder weniger automatisch für die Zukunft abdeckt.

Betrachten wir nur das Bundesschutzgesetz (BDSG) und Datenschutzverordnungen der einzelnen Bundesländer (DSVO). Diese fordern im Umgang mit personenbezogenen Daten eine erhöhte Sensibilität. Gerade auch im Bereich der Administration bedeutet das, dass eine Zwecktrennung (Berechtigungen), regelmäßige Passwortänderungen und weiteres durchgeführt wird. Für eine ordnungsgemäße Datenverarbeitung nach aktuellem Stand der Technik ist es zwingend notwendig, dass die administrativen Tätigkeiten nachvollziehbar sind. Das LDSG und die DSVO stellen hierfür konkrete Anforderungen. Bei jeder administrativen Tätigkeit muss stets der Ausführende ermittelt werden können. Auch Oracle empfiehlt in seinem Security Guide die Nutzung personalisierter DBA Accounts in der Datenbank.

Dieser Post beschreibt ein Konzept, welches wir Enterprise User Security für DBAs (EUS4DBAS) nennen. Das Ziel ist genau die genannten gesetzlichen Anforderungen im Bereich der DBAs umzusetzen und gleichzeitig vorhandene Investitionen zu nutzen und dadurch erhebliche Aufwände im Betrieb einzusparen. Aber auch eine erhöhte Sicherheit zu implementieren, die klare Konzepte verfolgt (mehr Transparenz, mehr Kontrolle, mehr Nachvollziehbarkeit, Eindeutigkeit) und ganz wichtig Komplexität abbaut.

Abbildung 1: Enterprise User Security für DBAs

In der Regel haben viele Unternehmen bereits ein zentrales Benutzermanagement z.B. für Windows aufgebaut. Alle Mitarbeiter mit einem Windows Desktop Rechner werden i.d.R. im MS Active Directory verwaltet. Warum müssen noch zusätzliche Benutzerrepositories betrieben werden? Wie Sie wissen, kann jede Oracle Datenbank ihre eigenen Benutzer verwalten. Die Oracle Datenbank Enterprise Edition verfügt über die Funktion Enterprise User Security. Genau diese Funktion ermöglicht es bereits bestehende Benutzerrepositories für Oracle Datenbanken einzubinden und diese LDAP User in der Datenbank zu nutzen, ohne diese Benutzer noch einmal zusätzlich in der Datenbank anzulegen.

Warum dieses hervorragende Konzept „Enterprise User Security“ sinnvoll ist, beschreibt die Komplexitätsberechnung ComplexDBAMgmt für die kleine Benutzergruppe der DBAs. Würde man alle anderen Benutzergruppen hinzuberechnen, dann wäre die Komplexität wahrscheinlich so groß, so daß die Bedrohung „Verlust der Kontrolle“ gegeben ist. Betrachten Sie bitte nachfolgende Grafik (Abb. 2).

Abbildung 2: Berechnung Komplexität des Account Managements für DBAs

Sie sehen anhand der Berechnung, dass auch für eine kleine Benutzergruppe von 10 DBAs ein Aufwand entstehen kann, der so groß ist, das man wesentliche Maßnahmen für einen sicheren Datenbank-Betrieb vermeidet, wie

Regelmäßiges Ändern von Kennwörtern
Keine Zwecktrennung (der DBA macht einfach alles, Release Manager, Account Manager, etc.)
Keine personalisierten DBAs, alle DBAs arbeiten mit SYS und SYSTEM
und Sie kennen bestimmt noch viel mehr Maßnahmen, die nicht durchgeführt werden...

Also, warum vermeiden wir nicht die Komplexität? Stattdessen nutzen wir für die 10 DBAs das bestehende Benutzerrepository MS AD und gleichzeitig alle Policies, die diese Repository bereits eingestellt hat, wie Selfservices (PW-Reset), PW-Policies (starke Passwörter), starke Authentisierungsverfahren etc..

Das charmante an diesem Konzept ist: Sie investieren einen Aufwand von ca. 1 Stunde, um eine Umgebung zu implementieren, die Ihnen erhebliche Vorteile verschafft und für eine Nachhaltigkeit in der Zukunft sorgt.

Hinweis:
Ein Zeitaufwand von 1h Stunde ist für erfahrene Admins, die wissen was sie tun. Folgen Sie diesem Konzept dauert der erste Aufbau etwas länger. Sie müssen das Dokument lesen und verstehen und die einzelnen Schritte ausführen. Beim zweiten Mal wissen Sie was Sie tun müssen und dann geht es zügig voran.

Vorbereitende Schritte

Eine Umgebung die bestehende Benutzerrepositories mit einer Oracle Datenbank verwenden kann, sieht wie in Abb.3 beschrieben aus. Genau diese Umgebung bauen wir in diesem Konzept auf und beschreiben jeden einzelnen Schritt im Detail. Der Aufwand ohne Download-Zeit der Software Komponenten beträgt ca. 1 Stunde, wenn man alle Schritte kennt und den Aufbau bereits mehrmals durchgeführt hat.

Abbildung 3: Enterprise User Security Umgebung mit MS AD und Kerberos Authentisierung

Warum benötigt man Oracle Unified Directory und greift nicht direkt auf den MS AD Server aus der Datenbank heraus zu, fragen Sie sich bestimmt. Diese Frage ist berechtigt. Die Antwort ist: „Eine Oracle Datenbank kann im Bereich EUS nur mit einem Oracle LDAP wie OUD kommunizieren. Will man andere LDAP Dienste nutzen, so müssen diese über einen Oracle LDAP Dienst eingebunden werden.“

Achten Sie bitte darauf, dass die Kommunikation zwischen den Komponenten in Abb.3 funktioniert und nicht durch eine Firewall blockiert wird.

Vorbereitung und Informationen

Bevor wir mit der Umsetzung beginnen, benötigen wir folgende Informationen bzw. gehen davon aus, dass bestimmte Komponenten bereits existieren:

Die Komponenten Oracle Datenbank (11.2.0.4) und MS AD existieren bereits. Hostname, Port der Server benennen. Wie heissen, die DBA User Accounts (in der DB und im MS AD)?
Für den Aufbau des Oracle Unified Directories empfehlen wir die Nutzung einer eigener Maschine. Wir empfehlen den Aufbau mit Oracle Linux (64bit)
Version des MS AD?
Welches OS wird bei den DBA Workstations genutzt? Sind Oracle Clients installiert, welche Version?
Welche DB Versionen (auf dem DB Server) werden eingesetzt, die mit EUS arbeiten sollen?
Nutzen Sie Cloud Control für die Verwaltung der Datenbanken? Welche Version? Mit welchen Credentials arbeiten Sie aus Cloud Control heraus auf den Datenbanken?
Gibt es nur eine AD Root Domain (Z.B. oracle.com) oder gibt es auch child domains (de.oracle.com)? Wie lauten genau die Root und die Child Domains?
Gibt es zusätzliche MS AD Forests?
Der eine oder mehrere KDC (Key Distribution Center) Namen müssen bekannt sein. Wie heissen diese? (Beispiel: ad.de.oracle.com)
Existiert bereits eine krb5.ini/krb5.conf Datei (Kerberos Konfigurationsdatei), die für den Aufbau von EUS mit Kerberos verwendet werden kann?
Wie sieht ein typischer User im MS AD aus? Beispiel Distinguished Name: cn=carsten,cn=Users,dc=de,dc=oracle,dc=com . Vielleicht liegen die User auch in einer gesonderten Organisation Unit, Bsp. DBAs:
cn=carsten,cn=Users,ou=DBAS,dc=de,dc=oracle,dc=com
Kann der MS AD Server mit dem DB Server Dateien austauschen(Notwendig für den Keytab)?
Sind die DB Server (DNS Name) genau in der gleichen Root Domain? Wie ist die Namenskonvention (DNS Name) der DB Server? Wie lauten die DNS Namen von einem DB Server?
Beim Aufbau der Umgebung muss ein MS AD Admin vorort sein (wegen Keytab, User anlegen,...). KTPASS Tools müssen vorhanden sein. Benennen Sie einen MS AD User (Proxy User) mit lesenden Zugriff in das MS AD
NTP Server benennen? Alle Server müssen eine identische Zeit aufweisen

Download der Software Komponenten

Für den Aufbau der Umgebung mit Oracle Unified Directory benötigen wir nachfolgend aufgeführte Software-Komponenten, die im Vorfeld auf den dafür zur Verfügung gestellten Server heruntergeladen werden sollten.

Wir werden später den OUD-Server im Proxy-Mode aufbauen. In diesem Mode wird ein lesender Zugriff in MS AD realisiert. Eine redundante Datenhaltung wird somit vermieden.
Bereiten Sie Ihren Linux Server vor. Installieren Sie Oracle Linux 5 oder 6 (siehe Certification Matrix) und richten Sie einen Benutzer „oud“ ein, der der Gruppe „oud“ angehört.

Certification Matrix: Bitte Ihr Betriebssystem überprüfen:
http://www.oracle.com/technetwork/middleware/id-mgmt/identity-accessmgmt-certmatrix-1932870.xls
Installation Guide OUD 11gR2, vorbereitende Schritte: http://docs.oracle.com/cd/E49437_01/install.111220/e23737/before_you_install.htm#solBEFORE-YOU-INSTALL-OPENDS

Als user „oud“ einloggen und die Software downloaden.
Die Software legen wir im Verzeichnis: /home/oud/software ab. Für jedes Produkt ein eigenes Verzeichnis anlegen.
Als erstes laden wir die Software aus dem Internet.

Oracle Unified Directory 11.1.2.
Gehen Sie auf die Website: https://edelivery.oracle.com
und melden Sie sich an.
Folgen Sie den Hinweisen im Installation Guide:
also: Bitte Oracle Fusion Middleware unter LinuxX86-64 auswählen
Oracle Fusion Middleware Identity Management 11g R2 Media Pack anchecken und
continue clicken
Click Download für Oracle Unified Directory 11g 11.1.2.2.0
Der Download startet und wird im Server unter /home/oud/software/oud abgelegt.
Oracle Weblogic Server 10.3.6 (brauchen wir für Admin Oberfläche ODSM)
Gehen Sie auf die Download-Website (Weblogic 10.3.6):
download: Oracle WebLogic Server 11gR1 (10.3.6) + Coherence – (Achtung entsprechend der OS Version die richtige Version herunterladen. Ich nutze die 64-Bit Version, also vierte Spalte)
See als Files (+) aufklicken.
Package Installer: Generic (1TB)
Bitte darauf achten, ob Sie die 32bit oder 64bit Version benötigen.
Ablage nach /home/oud/software/weblogic
ADF Framwork downloaden (brauchen wir für Admin Oberfläche ODSM)
Bitte Version Application Development Runtime 11.1.1.7 unter „Application Development Runtime“ auswählen und downloaden: siehe ADF Download
Ablage nach /home/oud/software/adf
Download JRE oder JDK 6 oder 7, falls noch nicht auf dem Linux Server vorhanden
Java-Download
Ablage nach /home/oud/software
(optional) Apache Directory Studio herunterladen
Die Adminumgebung für den Oracle Unified Directory benötigt man nicht für den täglichen Gebrauch. Hierfür kann man stattdessen auf dem Server oder auf den Admin Desktop einen geeigneten LDAP-Browser nutzen. Wie z.B. das Directory Studio von Apache.
http://directory.apache.org/studio/downloads.html
Ablage nach /home/oud/software/ApacheDir
Aktueller Bundlepatch zum OUD herunterladen: Doc-ID: 1905631.1 (vom Juli 2014)
Über My Oracle Support (support.oracle.com) den richtigen Bundle Patch Number: 11.1.2.2.1 Patch:18662903 vom 15 Juli 2014 herunterladen
Ablage nach /home/oud/software/patch

EUS aufsetzen - Installation und Konfiguration

Ich werde in diesem Beitrag darstellen, wie einfach es ist, eine gesetzeskonforme Lösung für das Setup der DBAs in Oracle Datenbanken zu implementieren. Eine Lösung, die nicht nur gesetzeskonform ist, sondern auch erhebliche Aufwandsreduzierungen in der Verwaltung von personalisierten DBAs in allen ihren Oracle Datenbanken mit sich bringt.

Installation und Setup Oracle Unified Directory

Folgende Verzeichnisse werden wir auf dem Linux System nach der Installation vorfinden:

Oracle Middleware Home
Hierin werden wir Oracle Unified Directory (OUD), Oracle Weblogic Server sowie das Application Development Framework (ADF) installieren.
Verzeichnisname: /app/Middleware
Oracle Home
Hier werden produktspezifischen Files zum OUD installiert. Dieses Verzeichnis befindet sich innerhalb des Middleware-Home.
Verzeichnisname: /app/Middleware/Oracle_OUD1
Oracle Common Directory
Hier wird ADF abgelegt.
Verzeichnisname: /app/Middleware/oracle_common
Oracle Weblogic Domain Directory
Es wird eine Weblogic Domain abgelegt.
Verzeichnisname: /app/Middleware/user_projects

JAVA JDK 6 oder höher vorbereiten

Für die Installation benötigen wir für das OUD eine Java Version von mindestens Version 6. Falls das Java in der notwendigen Version nicht zur Verfügung steht, müssen Sie diese Version nachinstallieren. Öffnen Sie ein Terminalfenster auf dem OUD-Server:
Wechseln des Benutzers zu root und Java nachinstallieren (Download Java)
[oud ~]$ su -
[root ~]$ cd /home/oud/software
[root ~]$ rpm -ivh /home/oud/software/jdk-7u67-linux-x64.rpm

Java wird dann nach /usr/java installiert.

Linuxumgebung setzen

Bevor wir mit der Installation weiter machen, setzen wir die Linux-Umgebung für den oud Benutzer. Öffnen Sie ein Terminalfenster und editieren Sie die .bash_profile im Homeverzeichnis von OUD:
[oud ~]$ vi .bash_profile
JAVA_HOME=/usr/java/jdk1.7.0_67
INSTANCE_NAME=oud-proxy
OUD_HOME=/app/Middleware/Oracle_OUD1
PATH=.:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/oud/bin:$JAVA_HOME/bin:/app/Middleware/Oracle_OUD1/bin
export PATH JAVA_HOME INSTANCE_NAME OUD_HOME
[oud ~]$ source .bash_profile

Die Umgebung ist gesetzt. Testen Sie die Umgebung:
[oud ~]$ echo $INSTANCE_NAME

Oracle Unified Directory (OUD) installieren

Wir befinden uns immer noch auf dem OUD-Server und sind als „oud“ angemeldet. Nun installieren wir alle Komponenten, die wir für den OUD benötigen. Als Erstes installieren wir die OUD-Software, dann WebLogic Server, dann Oracle Directory Service Manager (ODSM) mit ADF und zum Schluß spielen wir noch den aktuellen OUD Bundle-Patch ein.
Nun packen wir die die OUD Software aus:
[oud ~]$ cd software/oud
[oud oud]$ unzip /home/oud/software/Oracle\ Unified\ Directory\ 11g\ 11.1.2.2.0_V43020-01.zip

Nun die OUD Software installieren, hierzu in das richtige Verzeichnis wechseln und den Installer ausführen;
[oud oud]$ cd /home/oud/software/oud/Disk1
[oud Disk1]$ ./runInstaller -jreLoc /usr/java/jdk1.7.0_67/
Der Installer startet, folgende Einstellung nehmen wir vor:
Software Updates (Support) Einstellungen: Wenn Sie möchten, ansonsten Skip Software Updates; OUD Base Location Home /app/Middleware, Oracle Home Directory Oracle_OUD1, alles andere lassen wir auf Default.

Abbildung 4: OUD-Installer, 7 einfache Schritte

Dieser Vorgang dauert wenige Minuten, dann ist die OUD Software installiert.

Oracle Weblogic Server (WLS) 10.3.6 (11g) installieren

Nun wird der Weblogic Server installiert. Dieser wird für den Betrieb des OUD-Admin-Tools „Oracle Directory Service Manager (ODSM)“ benötigt.
Weblogic Server installieren:
[oud ~]$ cd /home/oud/software/weblogic
[oud weblogic]$ /usr/java/jdk1.7.0_67/bin/java d-64 -jar wls1036_generic.jar

Der Installer wird aufgerufen. Wir erstellen ein neues Middleware Home /app/Middleware. Wenn der Installer sagt, Verzeichnis ist nicht leer, wollen wir trotzdem mit Installation fortfahren. Entscheiden Sie selber, ob Sie Security Updates benötigen. Wir führen dann eine Custom-Installation durch und wählen nur Weblogic Server ohne Coherence. Am Ende der Installation auf Run Quickstart verzichten.

Abbildung 5: WLS-Installer, 10 einfache Schritte

Dieser Vorgang dauert ca. 10 Minuten.

Application Developerment Framework (ADF) und Oracle Directory Service Manager (ODSM) installieren

ADF ist notwendig für die Admin-Application (ODSM).
ADF unzippen und dann installieren. Bei der Installation sind keine expliziten Einstellungen notwendig. Wir installieren in das /app/Middleware Verzeichnis und nutzen oracle_common als Oracle Home:
[oud ~]$ cd /home/oud/software/adf
[oud adf]$ unzip ofm_appdev_generic_11.1.1.7.0_disk1_1of1.zip
[oud adf]$ cd Disk1
[oud adf]$ ./runInstaller -jreLoc /usr/java/jdk1.7.0_67/jre

Abbildung 6: ADF-Installer, 8 einfache Schritte

Auch diese Installation dauert wenige Minuten.

Nun können wir Oracle Directory Services Manager (ODSM) deployen. OUD, Weblogic und ADF müssen bereits installiert sein. Was wir ja eben getan haben.
Dazu rufen wir den Configuration Wizard des Weblogic Servers auf:
[oud ~]$ /app/Middleware/oracle_common/common/bin/config.sh

Wir erstellen eine neue Weblogic Domain "odsm". Wir wählen die zu installierende Komponente Oracle Directory Services Manager aus (Oracle JRF wird automatisch mitgewählt).
Hierzu tragen Sie als Domainnamen odsm ein. Wählen das Password für den Administrator weblogic. Wählen Sie bitte ein sicheres Passwort aus. In meinem Fall verwende ich "welcome1" (PS: Das ist übrigens kein sicheres Password). Achten Sie auch darauf, dass Sie mit dem richtigen JDK installieren. Wir nutzen immer das gleiche JDK. In meinem Fall JDK7.

Abbildung 7: WLS-Configuration Wizard für ODSM, 8 einfache Schritte

Auch dieser Vorgang dauerte wenige Minuten.

OUD Bundle Patch vom Juli 2014 einspielen

Alle OUD Komponenten sind installiert. Nun spielen wir den aktuellen Patch (bitte zum Zeitpunkt des Lesens nach aktuellen Patches schauen) ein.
[oud ~]$ cd software/patch
[oud patch]$ unzip p18662903_111220_Generic.zip
[oud patch]$ cd 18662903/OUD/

Lesen Sie nun die Readme.html mit einem Browser und informieren Sie sich über die notwendigen Schritte. Im Grunde wird beschrieben, wie der Patch eingespielt werden muss und was noch zu beachten ist: Also, der Patch wird eingespielt durch:
[oud OUD]$ /app/Middleware/Oracle_OUD1/OPatch/opatch apply

So, der Patch ist eingespielt und die OUD Software ist aktuell und kann konfiguriert werden.
Für einen ersten Test starten wir jetzt das Admin-Tool ODSM. Um einfach zu sehen, ob der Weblogic läuft.
Dazu fahren wir den Weblogic Server hoch. Öffnen Sie hierzu ein Terminal Fenster auf dem OUD-Server und starten den WLS:
[oud ~]$ /app/Middleware/user_projects/domains/odsm/bin/startWebLogic.sh

Beim Bootvorgang wird das Adminserver Verzeichnis angelegt:
/app/Middleware/user_projects/domains/odsm/servers/AdminServer
Im Bootvorgang wird der Adminuser abgefragt. Bitte geben Sie als User weblogic und als Password welcome1 (oder ihr eigenes Password) ein. Warten Sie nun bis die Meldung "Server started in RUNNING Mode" erscheint. Dann ist der Weblogic Server erfolgreich gestartet.
Damit der WLS automatisch startet (ohne Passwordeingabe) können Sie ein boot.properties File anlegen.
[oud ~]$ cd /app/Middleware/user_projects/domains/odsm/servers/AdminServer/
[oud AdminServer]$ mkdir security
[oud AdminServer]$ cd security
[oud security]$ vi boot.properties

Tragen Sie nun die richtigen Credentials für den Admin-User ein. Bei mir sind das:
username=weblogic
password=welcome1
Sobald der Server hochfährt, wird das Password automatisch in der boot.properties verschlüsselt und eine Eingabe ist dann nicht mehr notwendig.
Der WLS ist hochgefahren und ODSM kann aufgerufen werden. Öffnen Sie hierzu einen Browser und geben die URL http://<server>:7001/odsm ein. In meinem Fall
http://oud.de.oracle.com:7001/odsm
Es erscheint das Login-Fenster vom ODSM. Mehr wollten wir an dieser Stelle nicht sehen.

Abbildung 8: ODSM Login Browserfenster

WLS läuft und ODSM ist auch deployed.

Konfiguration des OUD als Proxy und Anbindung des MS AD

Nun starten wir die Konfiguration einer neuen OUD Instanz. Damit beim Anlegen dieser neuen Instanz der richtige Name verwendet wird (ansonsten asinst_1), haben wir bereits eine Umgebungsvariable angelegt. Bitte überprüfen Sie, ob die Variable gesetzt ist und „oud-proxy“ ausweist:
[oud ~]$ echo $INSTANCE_NAME

Wir wollen ein OUD-Proxy aufsetzen und somit vermeiden, dass die Daten aus dem MS AD redundant gespeichert werden. D.h. der Proxy greift auf den MS AD zu und liest die notwendigen Daten direkt aus dem MS AD. Hierfür benötigen wir einen Nutzer aus dem MS AD, der einen lesenden Zugriff auf die MS AD Daten besitzt. Er muss die Daten, also die DBAs, lesen können, die wir benötigen. Fragen Sie Ihren MS-AD-Admin welchen Nutzer er für Sie zur Verfügung stellen kann. In meinem Fall nutze ich den Administrator Benutzer, womit ich vollen Zugriff auf alle Daten im MS AD habe:
Host: ad.de.oracle.com Port: 389 (nicht verschlüsselt)
Username: administrator
Password: <password>
Im MS AD habe ich zwei DBA-Benutzer angelegt:

Suvad (DBA): suvad@de.oracle.com
Carsten (DBA): carsten@de.oracle.com

Beide Benutzer gehören der Gruppe DB-ADMINS an.

Abbildung 9: MS AD User, die als DBAs in der Datenbank arbeiten werden

Nun kreieren wir eine neue OUD Instanz „oud-proxy“.
Wir öffnen ein Terminalfenster und arbeiten immer noch als „oud“ User:
[oud ~]$ cd /app/Middleware/Oracle_OUD1

In diesem Verzeichnis findet man alle OUD Konfiguration Setup Tools. Wir wollen einen OUD-Proxy anlegen, der sich mit dem MS AD Server verbindet. Daher rufen wir das Proxy Tool auf:
[oud Oracle_OUD1]$ ./oud-proxy-setup

Da wir EUS aufsetzen, muss unbedingt secure access enabled werden. Wir wählen als Proxy unseren Server-Host oud.de.oracle.com aus. Die LDAP Ports sind 1389 und LDAPS 1636. Der AdminPort für den Zugriff des ODSM ist 4444. Root-User des OUD ist cn=Directory Manager und ich wähle das Password=oracle (wählen Sie hier ein sicheres Password). Fügen Sie den MS AD Server hinzu und setzen den Naming Context auf „dc=de,dc=oracle,dc=com“. Der Naming Context muß Ihrer Umgebung entsprechen. Am besten Sie schauen mit einem LDAP Browser in Ihrem MS AD und schauen wie die Root DN aussieht, diesen Kontext wählen Sie dann.
Laufzeitoptionen, d.h. spezielle Tuning Parameter, braucht man für einen OUD-Proxy nicht extra setzen. Die automatisch eingestellte Konfiguration ist bereits für einen Proxy-Einsatz bestmöglich eingestellt.

Abbildung 10: OUD-Proxy INstanz, wenige einfache Schritte

Der OUD-Proxy ist eingestellt. Wie Ihnen wahrscheinlich aufgefallen ist, haben wir zwar den MS AD Server benannt, aber noch keinen User, der durch OUD genutzt werden kann, um die entsprechenden User aus dem MS AD zu lesen.

OUD-Proxy Post-Installation Steps

Die Remote Credentials für den MS AD wird im Workflow Element des Proxies hinterlegt. Wir werden hier den Admin-User eintragen. Es empfiehlt sich aber für unseren Fall einen User einzutragen, der nur eine Leseberechtigung hat. Den User konfigurieren über die Kommandozeile. Theoretisch kann man auch den ODSM (das Admin-Tool) nutzen, ich finde die Kommandozeile aber einfacher.
Als erstes legen Sie bitte ein Password-File an, in dem wir das Password des OUD Admin (cn=Directory Manager) hinterlegen. Wenn wir mit der Konfiguration fertig sind, löschen Sie diese Datei bitte.
[oud ~]$ touch /tmp/password.txt
[oud ~]$ vi /tmp/password.txt
oracle

In dem dem File steht nur das password „oracle“, sonst nichts.
Nun richten wir den Remote User mit Zugriff auf MS AD ein. Das entsprechende Workflow-Element mit Zugriff auf MS AD heißt „proxy-we1“ (wird automatisch so gewählt). Der Administrator User hat im MS AD den entsprechenden Distinguish Name cn=administrator,cn=users,dc=de,dc=oracle,dc=com. Ihr User heißt wahrscheinlich anders. Mit dem „\“ am Ende jeder Zeile, sagen Sie dem Kommando, dass es noch nicht zu Ende ist und in der nachfolgenden Zeile weitere Eingaben erfolgen:
[oud ~]$ cd /app/Middleware/oud-proxy/OUD/bin/
[oud ~]$ dsconfig set-workflow-element-prop \
--element-name proxy-we1 \
--set remote-root-dn:cn=administrator,cn=users,dc=de,dc=oracle,dc=com \
--set remote-root-password:oracle \
--hostname oud.de.oracle.com \
--port 4444 \
--trustAll \
--bindDN cn=Directory\ Manager \
--bindPasswordFile /tmp/password.txt \
--no-prompt

Die Besonderheit von EUS ist auch, dass das Mapping der LDAP-Welt mit der DB-Welt im LDAP abgespeichert wird. Hierfür wird das sogenannte OracleContext verwendet. Dieses wollen wir im OUD abspeichern, da die MS AD Admins es nicht so gerne sehen, wenn fremde Veränderungen, die nicht von Microsoft stammen, eingespielt werden. Daher müssen wir dem OUD noch mitteilen, dass der OracleContent (angelegt durch das oud-proxy-setup) nicht im MS AD gesucht werden soll. Auch der Directory Manager befindet sich im OUD und nicht im MS AD. Folgendes Kommando führen wir hierzu aus (achten Sie bitte darauf Ihren eigenen Context zu setzen (dc=de,dc=oracle,dc=com anpassen)):
[oud ~]$ dsconfig set-workflow-element-prop \
--element-name proxy-we1 \
--add exclude-list:cn=Directory\ Manager \
--add exclude-list:cn=oraclecontext,dc=de,dc=oracle,dc=com \
--set remote-ldap-server-bind-dn:cn=administrator,cn=users,dc=de,dc=oracle,dc=com \
--set remote-ldap-server-bind-password:oracle \
--hostname oud.de.oracle.com \
--port 4444 \
--trustAll \
--bindDN cn=Directory\ Manager \
--bindPasswordFile /tmp/password.txt \
--no-prompt

Unser OUD weiss nun, wie er auf den MS AD zugreift, und dass das OracleContext nicht im MS AD gespeichert ist. Mit dem Einspielen des OracleContext durch das oud-proxy-setup wird ein LDIF-File eingespielt, der leider den falschen Naming-Context aufweist. Unser Naming-Context ist „dc=de,dc=oracle,dc=com“ (Fragen Sie Ihren MS AD ADMIN, welchen Wert Sie einstellen müssen). Im OUD wird aber derzeit noch „dc=example,dc=com“ verwendet. Auch die Speicherorte der Gruppen und User im MS AD müssen noch bekannt gegeben werden. Hierzu müssen wir eine LDIF Datei editieren und einige Einstellungen durch die richtigen Werte ersetzen. Die Änderungen werden wir mit dem „vi“ durchführen, das ist besonders einfach:
[oud ~]$ cd /app/Middleware/Oracle_OUD1/config/EUS/

Folgende Ersetzungen müssen wir vornehmen:

ou=people durch cn=users ersetzen
ou-groups durch cn=users ersetzen
dc=example,dc=com durch Ihren Kontext ersetzen, also bei mir ist das: dc=de,dc=oracle,dc=com ersetzen

[oud EUS]$ vi modifyRealm.ldif

Das Replace in "vi" ist sehr einfach. ESC Taste drücken und
:%s/pattern/replace Syntax eingeben und mit ENTER abschliessen, also in unserem Fall

:%s/ou=people/cn=Users (3 Ersetzungen)
:%s/ou=groups/cn=Users (3 Ersetzungen)
:%s/dc=example,dc=com/dc=de,dc=oracle,dc=com (14 Ersetzungen)

mit ESC und :wq speichern wir unsere Änderungen und kommen zurück zur Kommandozeile.
Nun müssen wir die Veränderungen in der modifyRealm.ldif im OUD einspielen. Hierfür gehen wir direkt über den LDAPPort 1389. Also nicht über den Admin-Port für ODSM.
[oud EUS]$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j /tmp/password.txt -v -f modifyRealm.ldif

Es sollten bei Anpassung des OracleContext keine Fehlermeldungen auftauchen.
Achtung:
In der Dokumentation http://docs.oracle.com/cd/E49437_01/admin.111220/e22648/eus.htm#CJABDBJJ hat sich leider ein Fehler eingeschlichen. Hier wird der Admin-Port des OUD angegeben. Richtig ist aber der LDAP Port.

Für die EUS Nutzung wollen wir auch Kerberos verwenden. Das hat drei wesentliche Vorteile:

Kerberos ist eine starke Authentisierung mittels Token
Man braucht den MS AD nicht zusätzlich für EUS zu erweitern (Schemaerweitereung durch ein weiteres Password-Attribute, sowie ein Password-Filter)
Und man realisiert für die DBAs ein SSO. Der DBA authentisiert normal über seinen Windows Desktop. Dabei wird der Kerberos Token (Ticket) erzeugt und mit diesem Token kann sich der DBA an seine Datenbanken anmelden ohne erneut Username/Password eingeben zu müssen.

Für die Kerberos Nutzung müssen wir noch zwei weitere Attribute im OracleContext ändern. Diese Attribute sind der Kerberos Name, den MS AD verwendet. Diesen Namen müssen wir auf den richtigen Eintrag im OracleContext mappen.
Für das erste Attribute legen wir eine neue ldif-Datei an und benennen das richtige Mapping für das Attribute orclCommonNichNameAttribute. Achten Sie bitte darauf, dass hier Ihr Context eingetragen wird (dc=de,dc=oracle,dc=com anpassen):
[oud EUS]$ vi NickNameAttribute.ldif
dn:cn=Common,cn=Products,cn=OracleContext,dc=de,dc=oracle,dc=com
changetype: modify
replace: orclCommonNicknameAttribute
orclCommonNicknameAttribute: userPrincipalName

mit ESC :wq speichern wir unsere Einträge
Wir machen die Änderng dem OUD bekannt:
[oud EUS]$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j /tmp/password.txt -v -f NickNameAttribute.ldif

Ein letztes Mapping müssen wir noch durchführen, damit nicht der Fehler "ORA-28293: No matched Kerberos Principal found in any user entry" entsteht. Oracle erwartet einen „krbPrincipalName“-Wert. Doch in meinem MS AD wird das Attribute „userPrincipalName“ verwendet. Dieses Mapping für Kerberos muss nun auch angepasst werden. Achten Sie bitte auch wieder darauf, dass hier Ihr Context eingetragen wird (dc=de,dc=oracle,dc=com anpassen):
[oud EUS]$ vi KerberosPrincipal.ldif
dn: cn=Common,cn=Products,cn=OracleContext,dc=de,dc=oracle,dc=com
changetype: modify
replace: orclCommonKrbPrincipalAttribute
orclCommonKrbPrincipalAttribute: userPrincipalName

mit ESC :wq speichern wir unsere Einträge
Nun ändern wir auch dieses Mapping im OUD mittels ldapmodify
[oud EUS]$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j /tmp/password.txt -v -f KerberosPrincipal.ldif

Hinweis lt. Dokumentation:
Wenn Sie kein Kerberos verwenden wollen, muss das NickNameAttribute auf sAMAccountName gemappt werden.
Siehe My Oracle Support Note:
OUD: Active Directy As External Directory Not Working For EUS (Doc ID 1570893.1)
Dann müssen aber wie gesagt noch ein paar weitere Änderungen am MS AD vorgenommen werden, wie Schemaerweiterung und Password-Filter Installation.
Näheres hierzu bitte in der Dokumentation verfolgen.
Ich hatte den WebLogic Server in der Zwischenzeit gestoppt, vielleicht taten Sie das auch.
Nun fahre ich den Weblogic Server mit der odsm Domain wieder hoch:
[oud EUS]$ cd /app/Middleware/user_projects/domains/odsm/bin/
[oud bin]$ startWebLogic.sh

Ich öffne ODSM und hinterlege meine Login Credentials:
http://oud.de.oracle.com:7001/odsm

Abbildung 11: OUD-Proxy Login für ODSM

Gehen Sie in den Datenbrowser , nun haben Sie Zugriff auf Ihre User und Groups in MS AD. Sie können hierfür auch jeden beliebigen LDAP Browser nutzen. Über das OUD-Proxy haben Sie nun Zugriff auf die MS AD User und Gruppen und zwar in der Berechtigung des MS AD User, den Sie für den OUD-Proxy eingestellt haben. Meine Konfiguration zeigt mir nachfolgendes Bild:

Abbildung 12: MS AD im Zugriff des OUD-Proxy (ODSM)

Der OUD-Proxy mit Zugriff auf MS AD und allen notwendigen Einstellungen, um ein EUS mit Kerberos für die Oracle Datenbank zu verwenden, ist fertig aufgesetzt. Der letzte Schritt ist die Password-txt zu löschen:
[oud EUS]$ rm /tmp/password.txt

Der Aufwand für die Installation und Konfiguration, wenn man alles richtig macht, beträgt weniger als eine Stunde. Die restlichen Minuten unseres Stunden-Budgets verbrauchen wir nun, um Kerberos aufzusetzen und die Datenbank an das LDAP anzubinden.

Kerberos für eine bestehende Oracle Datenbank einstellen

Nachfolgend finden Sie die Schritte für eine Kerberos Konfiguration einer bestehenden Oracle Datenbank der Version 11.2.0.4.
Hinweis Kerberos Konfiguration:
Eine detaillierte Beschreibung finden Sie in der Oracle Dokumentation

Einstellungen im MS AD

Wir müssen einen neuen Benutzer für das SPN (Service Principal Name) Mapping im MS AD erstellen. In meinem Fall nehme ich den Eintrag „carstentestdb“. Also einen eindeutigen Eintrag für die DB, die wir anbinden möchten.

Abbildung 13: MS AD SPN Mapping User anlegen

In der Hosts Datei tragen wir den DB-Server ein. Mit Hostname und IP-Adresse. Die Hosts Datei finden Sie unter c:\windows\systems32\drivers\etc\hosts.
XX.XXX.XXX.XXX db.de.oracle.com carstentestdb

Nun können wir die Keytab erzeugen. Gehen Sie zum MS AD Server und geben in der Kommandokonsole (cmd) folgendes Kommando ein.
ktpass -princ ORCL/db.de.oracle.com@DE.ORACLE.COM -mapuser carstentestdb +rndPass -crypto all -ptype KRB5_NT_PRINCIPAL -out c:\keytab.carstentestdb

Abbildung 14: Keytab auf dem MS AD Server erstellen

Im MS AD carstentestdb Eintrag überprüfen. In der Usermaske im Bereich Konto wird in dem Feld Benutzeranmeldename der richtige SPN (Service Principal Name) angezeigt.

Abbildung 15: SPN im MS AD überprüfen

Keytab zum DB Server kopieren. Ich kopiere die Keytab mittels WinSCP auf den DatenbankServer:
MS AD von c:\keytab.carstentestdb nach DBServer /etc/keytab.carstentestdb

Abbildung 16: Keytab auf den DB Server kopieren

Einstellungen für Kerberos auf dem DB Server

Wir geben den Hostname des MS AD in der Hosts-Datei (/etc/hosts) bekannt. Zusätzlich tragen wir für den DB Server noch den Alias-Namen „carstentestdb“ passend zum SPN Eintrag im MS AD ein.
xx.xxx.xxx.xxx ad.de.oracle.com ad
xx.xxx.xxx.xxx db.de.oracle.com db carstentestdb

Der nächste Schritt ist das Anpassen der Kerberos Konfigdateien im DB Server bzw. falls noch nicht vorhanden, eine neue Datei zu erstellen.
Öffnen Sie ein Terminalfenster auf dem DB Server und melden sich als root an. Die Konfiguration befindet sich im /etc Verzeichnis
[oud EUS]$ su -
[root ~]$ vi /etc/ krb5.conf
[libdefaults]
default_realm = DE.ORACLE.COM
clockskew = 3000
forwardable = true
default_tkt_enctypes = arcfour-hmac-md5
[realms]
DE.ORACLE.COM = {
kdc = ad.de.oracle.com
}
[domain_realm]
.de.oracle.com = DE.ORACLE.COM
de.oracle.com = DE.ORACLE.COM

Mit :wq speichern Sie Ihre Anpassungen. Wie gesagt, die Daten gehören zu meiner Umgebung und dienen hier nur als Beispiel. Bei anderen MS AD Umgebungen kann das anders aussehen.

Nun editieren wir die krb5.realms Datei. Diese befindet sicht auch im /etc Verzeichnis.
[root ~]$ vi /etc/krb5.realms
.de.oracle.com = DE.ORACLE.COM

Der DB Server muss nun auch mit dem MS AD für eine Kerberos Kommunikation bekannt gemacht werden. Hierfür muss die sqlnet.ora angepasst werden. Diese Anpassungen wird der „oracle“ User auf dem DB-Server durchführen:
[root ~]$ su – oracle
[oracle ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
SQLNET.AUTHENTICATION_SERVICES= (BEQ, KERBEROS5)
SQLNET.KERBEROS5_REALMS = /etc/krb5.realms
SQLNET.KERBEROS5_CONF=/etc/krb5.conf
SQLNET.KERBEROS5_KEYTAB=/etc/keytab.carstentestdb
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=ORCL
SQLNET.KERBEROS5_CONF_MIT=true
SQLNET.FALLBACK_AUTHENTICATION = TRUE

Nach dieser Änderungen startet man den DB Listener durch.
[oracle ~]$ lsnrctl stop
[oracle ~]$ lsnrctl start

Damit wir die Kerberos Authentisierung in der Datenbank testen können, wird ein Benutzer in der Datenbank als „externally“ anlegt. Wir erstellen einen User in der DB (krbuser@DE.ORACLE.COM) externally:
[oracle ~]$ sqlplus system/oracle@orcl
SQL > create user "SAHOVIC@DE.ORACLE.COM" identified externally as 'SAHOVIC@DE.ORACLE.COM';
SQL > grant CONNECT TO "SAHOVIC@DE.ORACLE.COM";

Nun testen wir Kerberos auf dem DB Server, der unter Linux läuft:
[oracle ~]$ okinit sahovic
Kerberos Utilities for Linux: Version 11.2.0.4.0 - Production on 21-AUG-2014 11:14:20
Copyright (c) 1996, 2013 Oracle. All rights reserved.
Password for sahovic@DE.ORACLE.COM: ........

[oracle ~]$ oklist
Kerberos Utilities for Linux: Version 11.2.0.4.0 - Production on 21-AUG-2014 11:14:24
Copyright (c) 1996, 2013 Oracle. All rights reserved.
Ticket cache: /tmp/krb5cc_501
Default principal: sahovic@DE.ORACLE.COM
Valid Starting Expires Principal
21-Aug-2014 11:14:17 21-Aug-2014 19:14:20 krbtgt/DE.ORACLE.COM@DE.ORACLE.COM

[oracle ~]$ sqlplus /@orcl
SQL >show user
USER is "SAHOVIC@DE.ORACLE.COM"

Somit ist Kerberos auf dem DB-Server konfiguriert und erfolgreich getestet. Natürlich kann man nun auch die Oracle Clients und u.U. auch die DB Links anpassen.

Einstellungen für EUS auf dem DB Server

OUD läuft und spricht mit MS AD, Kerberos als Authentisierungsverfahren läuft auch auf dem DB Server und spricht mit MS AD. Nun müssen wir noch EUS aktivieren. Nachfolgend führe ich die Quicksteps auf.

Hinweis:
Eine gute Beschreibung zum Aufsetzen EUS inkl. der DB finden Sie übrigens in der My Oracle Support Note: OUD-EUS configuration steps (Doc ID 1675625.1).
Als erster Konfigurationschritt rufen wir netca auf, um die ldap.ora zu generieren.

Wir wollen eine "Directory Usage Configuration" vornehmen. Den Directory Type belassen wir auf Oracle Internet Directory und setzen die Einstellungen von unserem OUD. OUD-Host und Port sowie Context: dc=de,dc=oracle,dc=com
[oracle ~]$ netca

Abbildung 17: netca zur Erstellung der ldap.ora

Der netca erstellt die Datei im Verzeichnis $ORACLE_HOME/network/admin/ldap.ora
[oracle ~]$ cat $ORACLE_HOME/network/admin/ldap.ora
# Generated by Oracle configuration tools.
DIRECTORY_SERVERS= (oudserver:1389:1636)
DEFAULT_ADMIN_CONTEXT = "dc=de,dc=oracle,dc=com"
DIRECTORY_SERVER_TYPE = OID

Nun muss noch die DB mit dem OUD-Server registriert werden. Dazu verwendet man den Database Configuration Assistent (dbca):
[oracle ~]$ dbca

Wir wählen „Configure DB Options“, wählen die richtige DB aus, und sagen „YES, register the Database“. Danach tragen Sie den OUD Admin ein, sowie geben ein Password für das Wallet an.
User DN: cn=Directory Manager
Password: Welcome1
Wallet Password (bitte ein gutes Password wählen): Welcome1
Keine weiteren Eingaben und die DB am Directory Service registrieren.
klkölks

Abbildung 18: dbca zum Registrieren der DB ans OUD

So die Infrastruktur steht. Nun müssen wir noch einiges in der DB vorbereiten und das Mapping zwischen DB und OUD vornehmen.
Als erstes die DB: Als „system“ legen wir ein globales Schema und eine globale DBA-Rolle in der DB an, die wir später mappen.
[oracle ~]$ sqlplus system/oracle@orcl
SQL > create user global_dba_schema identified globally;
SQL > create role global_dba_role identified globally;
SQL > grant dba to global_dba_role;

Der globale DBA Einstieg für personalisierte DBAs ist nun in der Datenbank eingerichtet. Hat aber noch keine Wirkung. Nun, müssen wir das Mapping mit dem LDAP vornehmen. Das machen wir im Enterprise Manager. Ich nutze das Datenbase Control auf dem DB Server : https://db.de.oracle.com:1158/em/console
Im Bereich Server klicken wir auf Enterprise User Security:
sdsds

Abbildung 19: EUS Konfiguration im Enterprise Manager

Im Enterprise Manager melden wir uns am OUD an:

Abbildung 20: Im Enterprise Manager beim OUD anmelden

„Manage Enterprise Domains" ausführen. „OracleDefaultDomain“ klicken und dann „Configure“ ausführen. Im Bereich User-Schema Mapping erstellen wir ein neues Mapping:
Den Nutzerbaum mappen wir auf das global_dba_schema. Also den Subtree cn=users,dc=de,dc=oracle,dc=com mit global_dba_schema.

Abbildung 21: Schema-Mapping im Enterprise Manager

Jetzt erstellen wir die Enterprise Role ENTERPRISE_DBA. Auf den Reiter „Enterprise Roles“ gehen und „create“ clicken. Wir tragen den Namen „Enterprise_DBA" ein.

Abbildung 22: Enterprise Role eintragen

Nun fügen wir der Enterprise Rolle eine DB Rolle hinzu. Klicken Sie auf „Add“ und melden sich dann als DBA (system/oracle) an. Wählen Sie die Rolle „GLOBAL_DBA_ROLE“.

Abbildung 23: Globale Role aus der DB mit der Enterprise Role im LDAP mappen

Nun müssen wir noch die Grantees, also die beiden DBAs suvad und carsten aus dem MS AD über den OUD hinzufügen. Beide erhalten mit der Zuordnung einen Zugriff oder besser eine Autorisierung als DBA für diese Datenbank. Klick auf „Grantee“ TAB und dann auf „ADD“. Wir fügen jeweils die beiden DBAs aus.

Abbildung 24: LDAP-User der globale Role zuordnen

Hinweis:
Eine Zuordnung einer MS AD Gruppe kann auch gewählt werden.
EUS mit Kerberos und Zugriff auf MS AD Nutzer ist fertig (ohne Desktop Clients). Das Aufsetzen des EUS im DB Server kann auch mittels Kommandotools leicht automatisiert werden: Copy ldap.ora, silent dbca Registrierung etc..

Zum Schluß testen wir EUS mit Kerberos auf dem DB Server. Zwei DBA User aus dem MS AD sind suvad@de.oracle.com und carsten@de.oracle.com und sollten in der DB als DBAs arbeiten können, ohne diese dort angelegt zu haben:
Als erstes TGT-Ticket holen
[oracle ~]$ okinit suvad
[oracle ~]$ oklist

Der User hat sich an Kerberos authentisiert und sein Token erhalten. Nun meldet er sich an die DB an (ohne Passwort, sondern mit dem Kerberos TGT) und die DB autorisiert über OUD (MS AD) den Benutzer und er kann als DBA arbeiten.
[oracle ~]$ sqlplus /@orcl
SQL > show user
USER is "GLOBAL_DBA_SCHEMA"
SQL> select * from session_roles;
DBA Rollen werden angezeigt.....
SQL> select sys_context('USERENV', 'ENTERPRISE_IDENTITY') from dual;
SYS_CONTEXT('USERENV','ENTERPRISE_IDENTITY')
-----------------------------------------------------------------------
cn=suvad,cn=Users,dc=de,dc=oracle,dc=com

Zusatzinformationen

Zeit

Achten Sie bitte darauf, dass alle Komponenten eine identische Zeit aufweisen. Entweder stellen Sie die Zeit manuell nach oder synchronisieren über einen oder mehrere NTP Server.

Kerberos Anpassungen für den Windows Client

Es empfiehlt sich einen passenden Oracle Client zum Datenbank Server zu installieren. Folgende Client sqlnet.ora muss angepasst werden:
SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5)
SQLNET.KERBEROS5_CONF = C:\WINDOWS\krb5.ini
SQLNET.KERBEROS5_CONF_MIT = true
SQLNET.KERBEROS5_CC_NAME = OSMSFT://
SQLNET.FALLBACK_AUTHENTICATION = TRUE

Für Windows 7 muss zusätzlich die Datei C:\Windows\System32\drivers\etc\services angepasst werden.
Die Einträge
kerberos           88/tcp    krb5 kerberos-sec      #Kerberos
kerberos           88/udp    krb5 kerberos-sec      #Kerberos
müssen durch die nachfolgenden Einträge ausgetauscht werden
kerberos           88/tcp    kerberos5 krb5 kerberos-sec      #Kerberos
kerberos           88/udp    kerberos5 krb5 kerberos-sec      #Kerberos

OUD HA Aufbau

Falls Sie den OUD Ausfallsicher machen müssen, folgen Sie bitte der My Oracle Support Note: „Enabling EUS with OUD-PROXY in HA mode for AD. (Doc ID 1609960.1)“

EUS User in der V$SESSION sichtbar machen

Siehe My Oracle Support Note: “How to Get The Name Of Enterprise User in V$SESSION? (Doc ID 1447631.1)”.

Schlusswort

So, wahrscheinlich haben Sie mehr als eine Stunde gebraucht. Aber da Sie jetzt die Key-Steps kennen und wissen, was zu tun ist, wird es beim zweiten Mal sicherlich nur 1 Stunde dauern.

13. Mai 2014

Oracle Net Services: Performance, Scalability, HA and Security Best Practices

Sehr gute Präsentation zu Net Services. Best Practices für die richtige Konfiguration von Oracle Net Service.
Sehr viele Security relevante Konfiguration wie z.B. der Logon Storm Handler.
Seht selber: Hier das PPT-Deck als PDF.

11. Februar 2014

Hands-on: Einführung in den Aufbau einer sicheren Oracle Datenbank

Im Dezember 2013 habe ich in Potsdam einen DB Security Hands-on Workshop durchgeführt. Ziel dieser Veranstaltung war es eine sichere Oracle Datenbank aufzubauen.

Aus den Ausführungen unserer DB Security Reviews für Kunden erfahren wir oft, dass untersuchte Datenbankumgebungen selten den notwendigen Schutzbedarf implementiert haben, den diese untersuchten DBs eigentlich erfordern.
Hinzu kommt, dass die Anforderungen an Datensicherheit und Datenschutz stetig steigen. Das deutsche Gesetz kennt insbesondere bei Sozial- und personenbezogenen Daten kein Pardon.

Der Oracle DB Security Hands-on Workshop zeigt an realen Beispielen, wie man Konzepte richtig aktiviert und welche Konzepte man implementieren muss. Es werden anhand der realen Beispiele Best Practices an Live-Datenbanken implementiert und mit den neuen Konzepte der DB 12c verlinkt.

Ich erstellte einen Lab-Guide mit dem sich Teilnehmer an einer Oracle 11.2.0.4 Datenbank ausprobieren konnten. Inhaltlich fokussierten wir uns in dem Workshop auf:
1. Wissen und AKVs
2. Mindestsicherheit
3. Zugriffskontrolle und Zwecktrennung
4. Erhöhte Komplexität
5. Verfügbarkeit
6. Audit und Überwachung
a) Spezielle Hands-on Übungen, um die Datenbank in den genannten 6
Bereichen sicherer zu machen
b) Wir behandeln 11g Datenbanken und verweisen aber auch auf neue
Funktionalitäten der 12c Datenbank
c) Ausblick besonderer DB 12c Security Lösungen

Beiliegend finden Sie nun den Lab-Guide, damit Sie mit dem Aufbau einer sicheren Oracle Datenbank beginnen können. Führen Sie die Labs aus und entwickeln Sie Ihr ganz eigenes Konzept zur Erhöhung der Datenbank Sicherheit.

Lab-Guide

Nachfolgend finden Sie Übungen, die die Sicherheit der Datenbank erhöhen. Die meisten der Labs adressieren eine Mindestsicherheit, die es zu aktivieren gilt.
Zusätzlich werden Lösungen aufgezeigt, die für einen erhöhten Schutzbedarf angewendet werden können und sollten.
Weitere Informationen:
Oracle Security in Depth Reference Architecture: http://www.oracle.com/technetwork/topics/entarch/oracle-wp-security-ref-arch-1918345.pdf

Setup der Umgebung

Importieren Sie als erstes das Database Image (wir nutzten eine DB 11.2.0.4, dieses Image haben Sie leider nicht zur Verfügung, daher müssen Sie ein eigenes Image aufbauen) in Ihre Vbox-Umgebung. Prüfen Sie bitte, wo genau die virtuellen Platten installiert werden. Falls Sie damit nicht einverstanden sind, ändern Sie den Pfad. Stimmen Sie dem Workshop-Lizenzsatz zu. Der Import-Vorgang dauert ca. 6 Minuten
Bevor Sie nun das importierte Image starten, konfigurieren wir einen Shared Folder:
1. Auf Ändern klicken und unter gemeiname Ordner ein lokales Verzeichnis mappen.
2. Wählen Sie Ihr lokales Verzeichnis aus und mappen diesen als gemeinsamen Ordner unter dem Namen Workshop mit vollen Zugriff
Nun können wir das Image starten. Die Linux Maschine fährt hoch.
Sobald das Loginfenster erscheint, melden wir uns als oracle/oracle an (root hat auch das Passwort oracle).
Akivieren Sie in dem Vbox-Menü >Geräte > gemeinsame Zwischenablage > bidirektional
Nun setzen wir als erstes den Shared Folder und kopieren dann das Zip-Archiv mit den Labs auf das Linux-Image. Öffnen Sie ein Terminalfenster und geben hierfür folgende Kommandofolge ein:

[oracle@localhost ~]$ su -
[oracle@localhost ~]$ mkdir /mnt/Workshop
[oracle@localhost ~]$ mount -t vboxsf Workshop /mnt/Workshop
[oracle@localhost ~]$ exit
[oracle@localhost ~]$ cd labs
[oracle@localhost ~]$ cp /mnt/Workshop/Hands-on_Labs.zip .
[oracle@localhost ~]$ unzip Hands-on_Labs.zip

Die vorbereiteten Scripte haben Sie nun nicht zur Verfügung, daher müssen Sie die Statements aus dem Blockeintrag kopieren.

Lab1: Mindestsicherheiteinstellen

In dieser Übung adressieren wir die Mindestsicherheit. Oracle liefert hier bereits Vorgaben. Zu nennende Quellen sind der Oracle Database Security Guide (in der entsprechenden Version) wie auch dokumentierte Projekte z.B. das Lockdown-Projekt.
In dieser Übung stellen Sie nun folgende Mindestsicherheit ein:
•    Netzwerkverschlüsselung
•    Init.ora Parameter, die die Sicherheit anheben
•    SQL*Net Konfiguration
Natürlich muss eine Mindestsicherheit immer den Anforderungen der Unternehmung folgen. Die hier dargestellten Vorgaben können als gute Grundlage genutzt werden, sollten aber den Anforderungen entsprechend angepasst werden.

Netzwerksicherheit einstellen

Als oracle Linux User ein Terminalfenster öffnen und den Listener sowie die Datenbank hochfahren:

[oracle@localhost ~]$ lsnrctl start
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> startup
SQL> exit;
TNSNames-Alias erstellen. Wir nutzen nicht den Network Configuration Manager (netca), sondern ändern manuell:
[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora
orcl =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.world)
    )
)

und Naming Service auf Local Naming einstellen (manuell):

[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)
ADR_BASE = /home/oracle/app/oracle

Wir erstellen nun ein Sample-Schema:

[oracle@localhost ~]$ sqlplus / as sysdba
SQL> create user scott identified by tiger default tablespace users;
SQL> grant connect, resource to scott;
SQL> exit;

Nun wollen wir testen, welche Daten aus dem Netzwerkverkehr mitlesen können. Dazu öffnen wir ein neues Terminalfenster und melden uns als root an. Root startet dann ein tcpdump und liest somit mit, was über das Netz gesendet wird:

[oracle@localhost ~]$ su -
Password:
[oracle@localhost ~]$ /usr/sbin/tcpdump -Xs 1518 -i lo port 1521

Im alten Terminalfenster melden wir uns als Scott an und ändern das Passwort. Dieses Passwort kann im Klartext mitgelesen werden:

[oracle@localhost ~]$ sqlplus scott/tiger@orcl
SQL> alter user scott identified by tiger;
SQL> Exit;
>>Tcpdump sollte nun das Kommando mitgelesen haben

Jetzt erzwingen wir eine Netzwerkverschlüsselung für die gesamte Oracle-Kommunikation über SQL*Net. Hierfür wird die sqlnet.ora angepasst:

[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)
ADR_BASE = /home/oracle/app/oracle
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA1)
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, 3DES168)

Übrigens der Parameter SQLNET.CRYPTO_SEED wird mittlerweile igoniert (seit 10g glaube ich). Der Seed wird automatisch erzeugt.
Starten Sie den Listener durch und führen ein paar SQL Abfragen ab, um zu prüfen, ob die Netzwerkverschlüsselung aktiv ist:

[oracle@localhost ~]$ lsnrctl
LSNRCTL > reload
LSNRCTL > services
LSNRCTL > status
LSNRCTL > exit;

[oracle@localhost ~]$ sqlplus scott/tiger@orcl
SQL> alter user scott identified by tiger;
SQL>exit;

Im root Terminalfenster (tcpdump) wird alles verschlüsselt. Sehen Sie das?
Nun prüfen wir den Network Service Banner, ob der Netzverkehr verschlüsselt wird (Achten Sie auf den Algorithmus AES256 und SHA1):

[oracle@localhost ~]$ sqlplus system/oracle@orcl
SQL> set lines 200
SQL> column username format a30
SQL> column network_service_banner format a120
SQL> select distinct substr(a.username,1,30) USERNAME,
                 b.network_service_banner
from v$session a,
      v$session_connect_info b
where a.sid=b.sid
and   a.serial#=b.serial#;
## Achten Sie auf den Algorithmus

Dokumentation: Doku: http://docs.oracle.com/cd/E11882_01/network.112/e10746/asoconfg.htm#ASOAG020
Oracle sagt im CPU Okt. 2013: Network encryption (native network encryption and SSL/TLS) and strong authentication services (Kerberos, PKI, and RADIUS) are no longer part of Oracle Advanced Security and are available in all licensed editions of all supported releases of the Oracle database. To remediate this security vulnerability, customers should configure network encryption in their clients and servers to protect sensitive data sent over untrusted networks. Refer to http://docs.oracle.com/cd/E11882_01/license.112/e47877/options.htm#CIHFDJDG - "Oracle Advanced Security section" of "Oracle Database Licensing Information 11g Release 2 (11.2)" for details of this licensing change.

Init.ora Parameter anpassen

In diesem Abschnitt betrachten wir nun die init.ora Parameter. Um die Sicherheit zu erhöhen, macht es Sinn bestimmte Parameter einzuschalten.

SQL> show parameter
NAME                                                       VALUE
O7_DICTIONARY_ACCESSIBILITY    FALSE        KORREKT
audit_sys_operations                                  FALSE        auf TRUE setzen
audit_trail               DB,EXTENDED    besser XML, lassen wir aber
                                                                   auf DB
control_files               ....ctl    besser mehrere verteilt auf
                               verschiedene Platten lassen
                                                                   wir aber so.
db_ultra_safe               OFF        wir setzen den Parameter
                                 auf DATA_ONLY, damit sind
                                                                   die nachfolgenden 3 Parameter auch gesetzt
**************************
Wird durch db_ultra_safe automatisch gesetzt
DB_BLOCK_CHECKING           FALSE        set to MEDIUM besser FULL,
                               wenn Performance OK.
DB_LOST_WRITE_PROTECT       NONE        set to TYPICAL
DB_BLOCK_CHECKSUM           TYPICAL    set to FULL
**************************
enable_ddl_logging                                     FALSE        set to TRUE
local_listener                   wird später registriert
open_links                                                   4        auf 0 setzen
open_links_per_instance                             4        auf 0 setzen
os_authent_prefix              ops$        auf RUL$ setzen, nie Default belassen
remote_login_passwordfile         EXCLUSIVE    brauchen wir das?
resource_limit                                              FALSE        auf TRUE setzen
sec_protocol_error_further_action      CONTINUE    auf DEPLAY oder DROP
sec_protocol_error_trace_action       TRACE        LOG oder ALERT
sec_return_server_release_banner               FALSE        TRUE setzen
smtp_out_server                        ACHTUNG anpassen
                                   Diesen Parameter passen wir in diesem LAB nicht an
sql92_security                FALSE        auf TRUE setzen

So, nun die init.ora Datei ändern:

[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> select value from v$parameter where name='spfile';
SQL> create pfile = '/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/mypfileorcl.ora' from spfile = '/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/spfileorcl.ora';
exit;

Mypfile editieren:

[oracle@localhost ~]$ vi $ORACLE_HOME/dbs/mypfileorcl.ora
orcl.__db_cache_size=230686720
orcl.__java_pool_size=4194304
orcl.__large_pool_size=8388608
orcl.__oracle_base='/home/oracle/app/oracle'#ORACLE_BASE set from environment
orcl.__pga_aggregate_target=222298112
orcl.__sga_target=369098752
orcl.__shared_io_pool_size=0
orcl.__shared_pool_size=117440512
orcl.__streams_pool_size=0
*.audit_file_dest='/home/oracle/app/oracle/admin/orcl/adump'
*.audit_trail='db_extended'
*.compatible='11.2.0.4.0'
*.control_files='/home/oracle/app/oracle/oradata/ORCL/controlfile/o1_mf_96kwtdsb_.ctl'
*.db_block_size=8192
*.db_create_file_dest='/home/oracle/app/oracle/oradata'
*.db_domain='world'
*.db_name='orcl'
*.diagnostic_dest='/home/oracle/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.memory_target=591396864
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.undo_tablespace='UNDOTBS1'

# Anpassungen fuer die Sicherheit
audit_sys_operations=TRUE
db_ultra_safe=DATA_ONLY
enable_ddl_logging=TRUE
open_links=0
open_links_per_instance=0
os_authent_prefix=RUL$
resource_limit=TRUE
sec_protocol_error_further_action=DELAY
sec_protocol_error_trace_action=LOG
sec_return_server_release_banner=TRUE
sql92_security=TRUE

Datenbank runterfahren, neues pfile aktivieren und prüfen:

[oracle@localhost ~]$ sqlplus / as sysdba
SQL> shutdown immediate
SQL> create spfile='/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/spfileorcl.ora' from pfile='/home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/mypfileorcl.ora';
SQL> startup
SQL> show parameter
SQL> exit;

Fertig. Prüfen Sie, ob Einstellungen aktiv sind.

Netzwerkkonfiguration (SQL*Net) anpassen

SQL*Net Konfiguration anpassen:

[oracle@localhost ~]$ lsnrctl stop

sqlnet.ora anpassen:

[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)
ADR_BASE = /home/oracle/app/oracle
# Encryption
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA1)
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, 3DES168)
#Irgendwelcher Input
SQLNET.CRYPTO_SEED="lökjlkjklafsdölkaqweürwüskldfäasdfäöaskdf)()(=)()="
# Security
SQLNET.INBOUND_CONNECT_TIMEOUT=7
SQLNET.OUTBOUND_CONNECT_TIMEOUT=10
SEC_USER_AUDIT_ACTION_BANNER=/home/oracle/app/auditwarning.txt
SEC_USER_UNAUTHORIZED_ACCESS_BANNER=/home/oracle/app/unauthwarning.txt
SQLNET.ALLOWED_LOGON_VERSION=12
SQLNET.EXPIRE_TIME=10
WALLET_OVERRIDE=TRUE

Editieren Sie die auditwarning.txt und unauthwarning.txt nach belieben. Diese Banner können Sie verwenden, um bestimmte Warnungen zu der Datenbank auszusprechen (Beispiele liegen bei).
Kopieren Sie die Dateien aus lab1 /home/oracle/labs/lab1/*warning.txt in das Verzeichnis /home/oracle/app

[oracle@localhost ~]$ cp /home/oracle/labs/lab1/*warning.txt /home/oracle/app
[oracle@localhost ~]$ ll /home/oracle/app/*.txt

listener.ora anpassen (wir stellen um auf Port 1522):

[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/listener.ora
LISTENER =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1522))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1522))
    )
    (DESCRIPTION =
      (ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
    )
)
SID_LIST_LISTENER=
(SID_LIST=
    (SID_DESC=
      (GLOBAL_DBNAME=orcl.world)
      (ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/dbhome_2)
      (SID_NAME=orcl)
     )
   )
ADR_BASE_LISTENER = /home/oracle/app/oracle
# Security
ADMIN_RESTRICTIONS_LISTENER=ON
INBOUND_CONNECT_TIMEOUT_LISTENER=5
SECURE_REGISTER_LISTENER = (IPC)
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=OFF
LOGGING_LISTENER = OFF
WALLET_LOCATION =
(SOURCE =
   (METHOD = FILE)
    (METHOD_DATA =
     (DIRECTORY = /home/oracle/app/oracle/oradata/ORCL/wallet)
    )
)

Ändern Sie den Port in der tnsnames.ora auf 1522:

[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora
orcl =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl.world)
    )
)

Listener wieder starten und in der DB registrieren:

[oracle@localhost ~]$ lsnrctl start
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> alter system set local_listener = '(DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=REGISTER)))' scope = BOTH;
SQL> shutdown immediate
SQL> startup
SQL> exit;

Fertig. Prüfen Sie die Zusatznachrichten und Einstellungen ob diese aktiv sind.
Weitere Informationen:
Using Class of Secure Transport (COST) to Restrict Instance Registration (Doc ID 1453883.1)

Lab 2: Eine Mindestauditierung aktivieren

In der Übung 1 haben wir bereits das Auditing in der Datenbank aktiviert. Es werden nun alle SYS Aktivitäten auditiert, sowie 2 weitere wichtige Aktivitäten, die in der Datenbank überwacht werden sollten.

SYS Auditing

Der init.ora Parameter AUDIT_SYS_OPERATIONS trägt in unserer Datenbank den Wert TRUE. Diesen Parameter haben wir in LAB1 bereits verändert. Mit dieser Einstellung werden alle Aktivitäten protokolliert, die unter einem SYSDBA oder SYSOPER in der Datenbank arbeiten. Die Protokolle werden im Betriebssystem abgelegt bzw. unter Windows in den Event Viewer Log.
In unserer Datenbank werden die Aktivitäten in $ORACLE_BASE/admin/$ORACLE_SID/adump abgelegt. Falls Sie einen anderen Pfad haben wollen, muss der init.ora Parameter AUDIT_FILE_DEST angepasst werden.
Damit Sie sehen was alles protokolliert wird, führen Sie bitte folgende Schritte aus:
1. Öffnen Sie ein Terminal (Fenster1) und melden sich als SYSDBA an

[oracle@localhost ~]$ sqlplus / as sysdba
SQL> show parameter audit

2. Öffnen Sie ein weiteres Terminal (Fenster2) und wechseln in den Audit-Bereich auf dem Filesystem und öffnen die letzte Audit-Datei mit „tail“:

[oracle@localhost ~]$ cd /home/oracle/app/oracle/admin/orcl/adump/
[oracle@localhost ~]$ ls -ltr
Wir öffnen die letzte angezeigte Datei
[oracle@localhost ~]$ tail -f „letzte angezeigte .aud Datei“

3. Gehen Sie zurück ins Terminal (Fenter1) und führen einige Kommandos als SYSDBA aus:

SQL> alter system switch logfile;
SQL> select name, spare4 from sys.user$ order by 1;

4. Schauen in das Terminal (Fenster2), dort sollten Sie alle ausgeführten Kommandos sehen:
...

Wed Nov 27 16:10:28 2013 +01:00
LENGTH : '181'
ACTION :[27] 'alter system switch logfile'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/2'
STATUS:[1] '0'
DBID:[10] '1357437676'

Wed Nov 27 16:11:39 2013 +01:00
LENGTH : '188'
ACTION :[34] 'select name, spare4 from sys.user$'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/2'
STATUS:[1] '0'
DBID:[10] '1357437676'

PS: Status:[1] 0 heißt, dass das Kommando korrekt ausgeführt wurde und keine Fehler auftraten. Probieren Sie einfach ein fehlerhaften Kommando aus.
Typischerweise würde man für die Sammlung der Aktivitäten einen zentralen Protokollserver aufbauen. Hierfür kann man verschiedene Lösungen aufbauen, wie einen zentralen Syslog Dienst oder Oracle Audit Vault und weitere Lösungen.
Beachten Sie bitte, dass deutsche Gesetze (BDSG) und Datenschutzrichtlinien (DSV) eine Protokollierung der Administratoren fordern.
Weitere Informationen:
Siehe My Oracle Support: Audit SYS User Operations (How to Audit SYSDBA) (Doc ID 174340.1),
Online Documentation: http://docs.oracle.com/cd/E11882_01/network.112/e16543/auditing.htm#DBSEG0611

Mindesteinstellung der Überwachung von Systemprivilegien

Gesetze wie das Bundesdatenschutzgesetz fordern eine Protokollierung, daher sollte diese geforderte Protokollierung auch aktiv sein. Ein Audit in der Datenbank erzeugt einen gewissen Overhead.
Siehe http://www.oracle.com/technetwork/database/audit-vault/learnmore/twp-security-auditperformance-166655.pdf
Im Security Guide der Oracle Datenbank findet man einen Vorschlag, welche Privilegien als minimal Anforderung überwacht werden sollten.
Weitere Informationen:
Oracle Security Guide, Guidelines für Auditing: http://docs.oracle.com/cd/E11882_01/network.112/e16543/guidelines.htm#DBSEG90008
Die dort beschriebenen Vorgaben, werden wir jetzt umsetzen und erweitern diese mit der Überwachung von der Anlage PUBLIC SYNONYME, da Public Synonyme gerne für Root-Kits genutzt werden:
1. Öffnen Sie ein Terminal und melden sich als SYSDBA an:

[oracle@localhost ~]$ sqlplus / as sysdba

2. Führen Sie Ihre Audit Policy der Systemprivilegien aus (siehe auch lab2/ audit_policy_systemprivs.sql):

SQL> AUDIT ALTER ANY PROCEDURE BY ACCESS ;
SQL> AUDIT ALTER ANY TABLE BY ACCESS ;
SQL> AUDIT ALTER DATABASE BY ACCESS ;
SQL> AUDIT ALTER SYSTEM BY ACCESS ;
SQL> AUDIT CREATE ANY EDITION BY ACCESS ;
SQL> AUDIT CREATE ANY JOB BY ACCESS ;
SQL> AUDIT CREATE ANY LIBRARY BY ACCESS ;
SQL> AUDIT CREATE ANY PROCEDURE BY ACCESS ;
SQL> AUDIT CREATE ANY TABLE BY ACCESS ;
SQL> AUDIT CREATE EXTERNAL JOB BY ACCESS ;
SQL> AUDIT CREATE PUBLIC SYNONYM BY ACCESS ;
SQL> AUDIT DROP ANY EDITION BY ACCESS ;
SQL> AUDIT DROP ANY PROCEDURE BY ACCESS ;
SQL> AUDIT DROP ANY TABLE BY ACCESS ;
SQL> AUDIT ALTER PROFILE BY ACCESS ;
SQL> AUDIT ALTER USER BY ACCESS ;
SQL> AUDIT AUDIT SYSTEM BY ACCESS ;
SQL> AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS ;
SQL> AUDIT CREATE SESSION BY ACCESS ;
SQL> AUDIT CREATE USER BY ACCESS ;
SQL> AUDIT DROP PROFILE BY ACCESS ;
SQL> AUDIT DROP USER BY ACCESS ;
SQL> AUDIT EXEMPT ACCESS POLICY BY ACCESS ;
SQL> AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS ;
SQL> AUDIT GRANT ANY PRIVILEGE BY ACCESS ;
SQL> AUDIT GRANT ANY ROLE BY ACCESS ;
SQL> AUDIT ROLE BY ACCESS ;
SQL> AUDIT DATABASE LINK BY ACCESS ;
SQL> AUDIT DIRECTORY BY ACCESS ;
SQL> AUDIT PROFILE BY ACCESS ;
SQL> AUDIT PUBLIC SYNONYM BY ACCESS ;
SQL> AUDIT SYSTEM AUDIT BY ACCESS ;
SQL> AUDIT SYSTEM GRANT BY ACCESS ;

3. Überprüfen Sie Ihre Policy in der Datenbank und führen dafür folgendes Kommando aus:

SQL> set lines 120
SQL> select user_name,
       proxy_name,
       privilege,
       case
        when        privilege = 'ALTER ANY PROCEDURE' OR
                    privilege = 'ALTER ANY TABLE'     OR
                    privilege = 'ALTER DATABASE'      OR
                    privilege = 'ALTER SYSTEM'        OR
                    privilege = 'CREATE ANY EDITION' OR
                    privilege = 'CREATE ANY JOB'      OR
                    privilege = 'CREATE ANY LIBRARY' OR
                    privilege = 'CREATE ANY PROCEDURE'OR
                    privilege = 'CREATE ANY TABLE'    OR
                    privilege = 'CREATE EXTERNAL JOB' OR
                    privilege = 'CREATE PUBLIC SYNONYM' OR
                    privilege = 'DROP ANY EDITION'    OR
                    privilege = 'DROP ANY PROCEDURE' OR
                    privilege = 'DROP ANY TABLE'      OR
                    privilege = 'ALTER PROFILE'       OR
                    privilege = 'ALTER USER'          OR
                    privilege = 'AUDIT SYSTEM'        OR
                    privilege = 'CREATE PUBLIC DATABASE LINK' OR
                    privilege = 'CREATE SESSION'      OR
                    privilege = 'CREATE USER'         OR
                    privilege = 'DROP PROFILE'        OR
                    privilege = 'DROP USER'           OR
                    privilege = 'EXEMPT ACCESS POLICY'OR
                    privilege = 'GRANT ANY OBJECT PRIVILEGE' OR
                    privilege = 'GRANT ANY PRIVILEGE' OR
                    privilege = 'GRANT ANY ROLE'      OR
                    privilege = 'ROLE'                     then 'ORA-Recommend'
        else 'Customer'
      end ORA_REC
from dba_priv_audit_opts order by 3;

Ihre Audit Policy ist hiermit aktiv. Nun können Sie diese testen:

SQL> connect system/oracle
SQL> create user peter identified by pan;
SQL> column username format a15
SQL> column obj_name format a15
SQL> column action_name format a30
SQL> select username, obj_name, action_name
from dba_audit_trail where action_name like 'CREATE USER'
order by timestamp;

Probieren Sie selber weitere Aktionen aus. Vielleicht im SQL Developer dort ist die Ergebnismenge übersichtlicher.

Entfernte DB Link Zugriffe erkennen

Der Zugriff von DB Links in die Datenbank ist ein Risiko. In der Regel werden die kompletten Credentials in der entfernten Datenbank gespeichert und über diese DB Links dürfen dann alle berechtigten DB Benutzer auf die entfernte Datenbank zu greifen. Wenn es sich um einen Public DB Link handelt, dann dürfen alle DB Benutzer zu greifen.
Wie kann man nun in der Datenbank sehen, welche überwachten Systemprivilegien von entfernten Benutzern über einen Datenbank Link ausgeführt wurden?
Hierfür müssen wir einen Datenbank Link anlegen und diesen Database Link nutzen und dann schauen wir in die DBA_AUDIT_TRAIL und prüfen, ob ein DB Link genutzt wurde.
1. Als erstes legen wir ein neues Table-Objekt im Benutzer SCOTT an und befüllen es:

[oracle@localhost ~]$ sqlplus /nolog
SQL> conn scott/tiger@orcl
SQL> create table criticaldata (nr number, citData varchar2(100));
SQL> insert into criticaldata values (1, 'Patent zur Herstellung von Coca Cola');
SQL> insert into criticaldata values (2,'Geodata fuer naechste Erdoelbohrung');
SQL> commit;

2. Nun legen wir als SYSTEM einen neuen Benutzer und geben diesem Benutzer das Recht sich anzumelden und ein Recht Database Links anzulegen:

SQL> conn system/oracle@orcl
SQL> create user dblinkusr identified by oracle;
SQL> grant create session, create database link to dblinkusr;

3. Nun legen wir den DB Link an und schauen auf das neue Objekt von SCOTT:

SQL> conn dblinkusr/oracle@orcl
SQL> create database link scott_link connect to scott identified by tiger using 'orcl';

4. Bevor wir den Datenbank Link nutzen können, müssen wir den init.ora Parameter OPEN_LINKS auf 1 setzen, ansonsten würde folgende Fehlermeldung angezeigt werden; ORA-02020: too many database links in use

SQL> conn / as sysdba
SQL> alter system set OPEN_LINKS=1 scope=SPFILE;
SQL> shutdown immediate
SQL> startup
SQL> show parameter open_links

5. Datenbank Link nutzen, d.h. der benutzer schaut über den Link in die Objekte, ohne eine direkte Berechtigung Daten aus diesem Objekt zu lesen;

SQL> conn dblinkusr/oracle@orcl
SQL> select * from criticaldata@scott_link;

6. Nun schauen wir in der DBA_AUDIT_TRAIL nach und schauen mal, wie man sieht ob ein enterfernter DB Link etwas in unserer Datenbank ausführte:

SQL> conn system/oracle@orcl
SQL> select username, obj_name, action_name, comment_text
from dba_audit_trail
where comment_text like '%DBLINK_INFO%'
order by timestamp desc;

Alternativ nutzen Sie den SQL Developer

Mindesteinstellung der Überwachung von Objektprivilegien

Zu jeder Mindestsicherheit gehört die Überwachung von wichtigen SYS-Objekten. Hierzu zählen die Tables SYS.USER$, SYS.LINK$ und SYS.USER_HISTORY$
Zusätzlich überwachen wir den Zugriff auf unser wichtiges Objekt SCOTT.CRITICALDATA.
1. Audit für die wichtigen SYS-Objekte einstellen:

[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> AUDIT SELECT,update,delete,insert ON SYS.LINK$ BY SESSION;
SQL> AUDIT SELECT,update,delete,insert ON SYS.USER_HISTORY$ BY SESSION;

2. Normalerweise sollte man die SYS.USER$ Table auch überwachen, die wird aber für einen WARM-Start benötigt (in 11g DBs). Somit sollte an dieser Stelle der Zugriff auf diese Tabelle eingeschränkt sein. Seit 12c kann man die SYS.USER$ überwachen:

    /*12c audit policy's definition */
    CREATE AUDIT POLICY pol1 ACTIONS select ON sys.user$;
    /* Enabled audit policy for ALL users */
    AUDIT POLICY pol1;

3. Audit für die Scott Tabelle

SQL>AUDIT SELECT,update,delete,insert ON SCOTT.CRITICALDATA BY SESSION;

4. Zusätzlich können Sie gerne eigene Objekte überwachen
5. Mit diesem Select können Sie alle Objekt-Privilegien (ausser PUBLIC) ansehen, am besten SQL Developer benutzen:

SQL> select a.owner,
       a.grantor,
       a.grantee,
       CASE
        WHEN (SELECT 'X' from dba_users
              where username = a.grantee) IS NOT NULL THEN 'USER'
        WHEN (SELECT 'X' from dba_roles
              where role = a.grantee) IS NOT NULL THEN 'ROLE'
       END AS GRANTEE_TYP,
       a.table_name,
       max(decode(privilege,'SELECT','X')) "SELECT",
       max(decode(privilege,'INSERT','X')) "INSERT",
       max(decode(privilege,'UPDATE','X')) "UPDATE",
       max(decode(privilege,'DELETE','X')) "DELETE",
       max(decode(privilege,'ALTER','X')) "ALTER",
       max(decode(privilege,'REFERENCES','X')) "REFERENCES",
       max(decode(privilege,'INDEX','X')) "INDEX",
       max(decode(privilege,'EXECUTE','X')) "EXECUTE"
from dba_tab_privs a
where a.grantee != 'PUBLIC'
group by a.owner, a.grantor, a.grantee, a.table_name
order by a.grantee,a.owner,a.table_name;

Netzwerk überwachen

Wenn Sie wollen, dass die unerwarteten Fehler im SQL*Net Verkehr mitprotokolliert werden,schalten Sie nachfolgenden Schalter an.
1. Network auf unerwartete Fehler überwachen

[oracle@localhost ~]$ sqlplus / as sysdba
SQL> AUDIT NETWORK;

Fine grained Auditing (FGA)

FGA nutzt man, wenn man eine Auditierung detaillieren möchte wie z.B. eine Überwachung des Zugriffs auf nur eine Spalte oder man auditiert nur dann, wenn eine bestimmte Bedingung zutrifft und nicht zutrifft.
Weitere Informationen:
Auditing Specific Activities with Fine-Grained Auditing: http://docs.oracle.com/cd/E11882_01/network.112/e16543/auditing.htm#DBSEG525
How to Avoid Common Flaws and Errors Using Fine Grained Auditing (Doc ID 199419.1)
SCRIPT: How To Apply the Same Fine Grained Audit Policy To All Tables In A Schema. (Doc ID 469007.1)
SCRIPT: How To Implement The Equivalent Of BY SESSION Auditing Using FGA on Objects? (Doc ID 1269970.1)
Wir legen jetzt einen simplen Case an, der nur protokolliert, wenn mit einem bestimmten Tool auf unsere wichtige Tabelle im Scott Schema zugegriffen wird.
1. Als Erstes wird ein FGA Admin angelegt, der alle notwendigen Rechte besitzt:

[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> CREATE USER FGA_ADMIN IDENTIFIED BY oracle;
SQL> GRANT CREATE SESSION TO fga_admin;
SQL> GRANT EXECUTE ON DBMS_FGA TO fga_admin;
SQL> GRANT CREATE PROCEDURE TO fga_admin;
SQL> GRANT SELECT on sys.v_$session TO fga_admin;

2. Als FGA_ADMIN anmelden und notwendige Policies und Funktionen anlegen:
Als erstes eine Funktion die das verwendete Tool beim Login prüft:

SQL> conn fga_admin/oracle@orcl
SQL> create or replace function getProgram return varchar is
         l_program varchar2 (500) := NULL;
        begin
         select Program into l_program from v$session
          where SID = sys_context('USERENV','SID');
         return l_program;
        exception when others then
         return NULL;
        end;
/
SQL> grant execute on fga_admin.getProgram to PUBLIC;

Nun können wir die Policy anlegen und protokollieren, wenn SQL Developer benutzt wird und auf die Spalte CITDATA zugegriffen wird:

SQL> BEGIN   -- erst droppen, falls schon vorhanden
      DBMS_FGA.DROP_POLICY(
      object_schema      => 'SCOTT',
      object_name        => 'CRITICALDATA',
      policy_name        => 'CRITICALDATA_POLICY');
     END;
/

BEGIN
DBMS_FGA.ADD_POLICY(
   object_schema      => 'SCOTT',
   object_name        => 'CRITICALDATA',
   policy_name        => 'CRITICALDATA_POLICY',
   enable             => TRUE,
   audit_condition    =>
       'fga_admin.GetProgram=''SQL Developer''',
   audit_column       => 'citdata',
   statement_types    => 'SELECT,INSERT,DELETE,UPDATE',
   audit_trail        => DBMS_FGA.DB+DBMS_FGA.EXTENDED);
END;
/
Überprüfen Sie bitte, ob die Policy existiert:
SQL> conn / as sysdba
SQL> SELECT POLICY_NAME FROM DBA_AUDIT_POLICIES;

3. Nun wechseln Sie in den SQL Developer als User Scott und selektieren die Tabelle (auf dem Desktop auf das SQL Developer Icon doppelklicken):

SQL Developer> Connection für scott/tiger@orcl Port: 1522 sdid=orcl anlegen (oben links auf das grüne PLUS klicken)
SQL Developer> select * from criticaldata;

4. Melden Sie sich als DBA an und Sie prüfen ob der Zugriff protokolliert wurde:

SQL> conn / as sysdba
SQL> select * from DBA_COMMON_AUDIT_TRAIL where AUDIT_TYPE='Fine Grained Audit' order by extended_timestamp desc;

Im Audit Type wird FGA gekennzeichnet. Prüfen Sie die Aussagen.
Im Verzeichnis LAB2 finden Sie einen SQL-Script fga_anlegen.sql zur Anlage der FGA Policy.

Audit Daten säubern

Bei der Überwachung mittels Audit entstehen Daten, die in bestimmten Abständen zu säubern sind. Definieren Sie sich Ihren eigenen Plan, wann die Daten veraltet und überprüft sind.
Oracle Support hat in seiner Knowledge Base einen Script vorbereitet, der eine Retention Time von einer Woche vorsieht.
SCRIPT: Basic example to manage AUD$ table in 11.2 with dbms_audit_mgmt (Doc ID 1362997.1)
Diese Übung werden wir nicht durchführen.

Audit Policy generieren

Das nachfolgende Script generiert, die eingestellte Audit Policy (Systemprivilegien) in der Datenbank.
SCRIPT: Generate AUDIT and NOAUDIT Statements for Current Audit Settings (Doc ID 287436.1).
Diese Übung werden wir nicht durchführen.

Audit in der Datenbank härten

Es gibt verschiedene Möglichkeiten ein Audit zu härten. Oracle hat hier in seiner Knowledgebase Informationen zur Verfügung gestellt. Fragen Sie hierzu Ihren Oracle Sales Consultant.
Natürlich können Sie auch Audit Vault nutzen, dann werden die Auditdaten in einem zentralen und revisionssicheren Audit Warehouse verwaltet. Darüber hinaus werden die Daten in den Zieldatenbanken zentral und automatisiert gesäubert, Policies zentral provisioniert und einiges mehr.

Lab 3: Schutz der Daten durch Verschlüsselung

Für verschiedenene Schutzmaßnahmen, die eine Verschlüsselung fordern, kennen wir verschiedenen Business Cases:
1.    Die Daten verlassen die Datenbank z.B. über einen Export-Dump oder Backup
2.    Schutz vor Nicht-Datenbankbenutzern wie ROOT, Storage-Admins, Hoster etc.
3.    Physikalischer Datendiebstahl (Rechnerdiebstahl)

Data Encryption mit DataPump:

Es ist keine Installation und keine Konfiguration notwendig. Die einzige Voraussetzung ist das Vorhandensein eines DIRECTORY-Objektes. Zusätzlich muss der Benutzer berechtigt sein, in das Directory zu schreiben.
1. Prüfen Sie, ob Directories vorhanden sind und wer Zugriff hat:

[oracle@localhost ~]$ sqlplus system/oracle@orcl
SQL> select a.owner,
       a.table_name as DIRNAME,
       b.directory_path,
       a.grantor,
       a.grantee,
       CASE
        WHEN (SELECT 'X' from dba_users where username = a.grantee)
             IS NOT NULL THEN 'USER'
        WHEN (SELECT 'X' from dba_roles where role = a.grantee)
             IS NOT NULL THEN 'ROLE'
       END AS GRANTEE_TYP,
       a.privilege,
       a.grantable,
       a.hierarchy
from dba_tab_privs a,
       dba_directories b
where a.table_name = b.directory_name
order by a.table_name, a.grantee, a.privilege;

2. Wir wollen nun als SCOTT die Objekte exportieren und müssen SCOTT ein WRITE Recht auf DATA_PUMP_DIR geben:

SQL> grant write, read ON DIRECTORY DATA_PUMP_DIR to SCOTT;

3. Daten als USER SCOTT exportieren. Einmal mit Passwort, d.h. die Daten werden verschlüsselt. Das angegebene Passwort braucht man auch für den späteren Import.
Als Linux oracle User im Terminal nachfolgende Kommandos ausführen:

[oracle@localhost ~]$ expdp scott/tiger TABLES=scott.criticaldata DIRECTORY=DATA_PUMP_DIR FILE=scott.dmp ENCRYPTION_PASSWORD=welcome1
[oracle@localhost ~]$ ll /home/oracle/app/oracle/admin/orcl/dpdump/

4. Rufen Sie den „vi“ mit dem Export-Dump auf und versuchen Sie sinnvolle Werte abzuleiten:

[oracle@localhost ~]$ vi /home/oracle/app/oracle/admin/orcl/dpdump/scott.dmp

5. Ein Import würde nachfolgend funktionen (führen wir aber nicht aus):

[oracle@localhost ~]$ impdp scott/tiger TABLES=scott.criticaldata DIRECTORY= DATA_PUMP_DIR FILE=scott.dmp ENCRYPTION_PASSWORD=welcome1

Anstelle des Passwords können auch Wallets verwendet werden.
OPTIONAL: Wiederholen Sie die Schritte 3 und 4 ohne den ENCRYPTION_PASSWORD-Parameter und durchsuchen Sie den Export Dump nach "Coca Cola".

Data Encryption mit Tablespace Verschlüsselung

Nun verschlüsseln wir einen Tablespace und schieben in diesen neuen Tablespace unsere wichtige Tabelle CRITICALDATA aus dem SCOTT Schema.
1. Wallet Location muss in der sqlnet.ora definiert sein.
Editieren der $ORACLE_HOME/network/admin/sqlnet.ora und hinzufügen, des neuen Parameters:

[oracle@localhost ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
ENCRYPTION_WALLET_LOCATION =
(SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
    (DIRECTORY =
     /home/oracle/app/oracle/oradata/ORCL/wallet)))

2. Wallet Verzeichnis anlegen (zu den Datenfiles):

[oracle@localhost ~]$ mkdir $ORACLE_BASE/oradata/ORCL/wallet

3. Listener durchstarten

[oracle@localhost ~]$ lsnrctl
LSNRCTL> reload
LSNRCTL> exit

4. Wallet mit Master Key erstellen. Passwort dient dem Schutz des Wallets:

[oracle@localhost ~] sqlplus / as sysdba
SQL> alter system set encryption key identified by "welcome1";

5. Wallet öffnen, falls es noch nicht bereits geöffnet ist (ist schon geöffnet).

SQL> alter system set encryption wallet open identified by "welcome1";

6. Nun können wir einen verschlüsselten Tablespace erstellen:

SQL> create tablespace enc256_ts datafile
'/home/oracle/app/oracle/oradata/ORCL/datafile/enc256_ts.dbf'
size 10M autoextend on next 1M encryption
using 'AES256' default storage (encrypt);

7. Wir betrachten uns nun, ob der Tablespace wirklich verschlüsselt ist:

SQL> select tablespace_name,encrypted from dba_tablespaces;

8. Nun können wir das SCOTT Objekt in diesen verschlüsselten Bereich verschieben. Die Daten sind dann transparent verschlüsselt:

SQL> alter table scott.criticaldata move tablespace enc256_ts;
SQL> select owner, table_name, tablespace_name from dba_tables
where owner='SCOTT' and table_name='CRITICALDATA';

9. Optional: Mit dem Parameter close schließt man das Wallet und dadurch kann keiner mehr (auch die berechtigten User nicht mehr) auf die verschlüsselten Daten (im Tablespace) zugreifen.

SQL> alter system set encryption wallet close identified by "welcome1";

10. Optional: Wenn man AutoOpen Wallet erstellen/nutzen will:

[oracle@localhost ~]$ orapki wallet create –wallet /home/oracle/app/oracle/oradata/ORCL/wallet/ewallet.p12 -auto_login

oder mit Hilfe vom Oracle Wallet Manager
Weitere Informationen:
TDE Best Practices: http://www.oracle.com/technetwork/database/security/twp-transparent-data-encryption-bes-130696.pdf

Lab 4: Zwecktrennung – Segregation of Duties (SoD)

Die Zwecktrennung wird z.B. auch in den Gesetzen gefordert z.B. in der Anlage zum §9 Bundesdatenschutzgesetz

“...8. zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten getrennt verarbeitet werden können...“.

Nicht der Gesetze sondern auch der eigenen Sicherheit und Kontrolle wegen, empfiehlt sich eine sinnvolle Zwecktrennung in der Datenbank. Das schafft eine klare Übersicht und bessere Kontrolle. Abweichungen der Zwecktrennung wären sofort sichtbar.
Unsere Erfahrung zeigt, dass eine unkontrollierte Mentalität in der Datenbank, wo jeder alles machen darf, dazu führt, dass durchaus gute Konzepte gar nicht oder nur halb umgesetzt werden. Das ist natürlich für die Sicherheit in der Datenbank nicht mehr kontrollierbar.
Eine saubere Zwecktrennung in der Datenbank sollte immer folgende Punkte berücksichtigen:

Eine saubere Trennung der Aufgaben in der Datenbank ist zu implementieren.
Idealerweise bekommt jeder Mitarbeiter eine AKV (Aufgaben, Kompetenzen und Verantworlichkeiten) Matrix vorgelegt, diese sollte in der DB erzwungen werden.
Die Datenbank 12c bietet eine voreingestellt Zwecktrennung out-of-the-box. Es werden verschiedene SYS User, Audit User und andere Rollen deployed, damit die Zwecktrennung bereits von Anfang an auf ein Mindestmaß eingestellt ist.
Überlegen Sie, welche Systeme und Rollen in der Unternehmung man für die Zwecktrennung bereits verwenden könnte.
Beispiel: MS AD Admin. Für die Benutzerverwaltung in der DB wird ein bestehendes System mittels EUS (Enterprise User Security) genutzt. Rund um das System wie z.B. MS Active Directory bestehen Rollen, die auch für die Datenbank genutzt werden.
Zur Zwecktrennung gehört auch das Setup von Anwendungsowner und Anwendungsusern
Machen Sie die Zwecktrennung in Ihrer Datenbank auch sichtbar. Das macht man sehr einfach mittels Profilen. Zusätzlich kann man sich eine Syntax auch für Benutzernamen ausdenken. Schalten Sie Banner, die darauf hinweisen, dass hier protokolliert wird (haben wir ja bereits schon gemacht)!

Datenbank Profile

Ordnen Sie jeder Benutzergruppe das passende Profile zu, um diese Benutzergruppe eindeutig zu identifizieren und im Profile die passenden Paramter für diese Benutzergruppe zu setzen.
In unserem Beispiel, werden wir zwei Profile anlegen. Ein Profil für die Admins und eines für alle anderen Benutzer. Standardmäßig existiert immer ein Default-Profile. Dieses Profil bleibt erhalten und wird für alle nicht-Admins weitergenutzt.
1. Als erstes installieren wir die Verfiy_Function, diese können Sie gerne nach Ihren Vorstellungen anpassen. Wir empfehlen auch für 11g Umgebungen, die Verify_Function, die mit 12c mitgeliefert wird, zu verwenden (machen wir hier nicht).

[oracle@localhost ~]$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/utlpwdmg.sql

Schauen Sie sich auch gerne den Inhalt des SQL-Scriptes an.

2. Nun legen wir ein Profile für die Admins an:

SQL> CREATE PROFILE PRFL_ADMINS LIMIT
   FAILED_LOGIN_ATTEMPTS 5
   PASSWORD_LIFE_TIME 60
   PASSWORD_REUSE_TIME 60
   PASSWORD_REUSE_MAX 5
   PASSWORD_VERIFY_FUNCTION verify_function
   PASSWORD_LOCK_TIME 2
   PASSWORD_GRACE_TIME 10
   SESSIONS_PER_USER 1
   COMPOSITE_LIMIT 5000000
   CONNECT_TIME 30
   IDLE_TIME 30
   CPU_PER_CALL UNLIMITED
   CPU_PER_SESSION UNLIMITED
   LOGICAL_READS_PER_CALL     UNLIMITED
   LOGICAL_READS_PER_SESSION UNLIMITED
   PRIVATE_SGA                UNLIMITED;

3. Nun prüfen wir welche DBAs in der Datenbank existieren (SYS und SYSTEM):

SQL> set lines 200
SQL> select rp.grantee ,
(select 'YES' from dba_users where username=rp.grantee) IS_USER,
(select 'YES' from dba_roles where role=rp.grantee) IS_ROLE,
CASE
WHEN (select 'YES' from dba_roles where role=rp.grantee) = 'YES'
THEN (select count(*) from dba_role_privs a
where a.granted_role=rp.grantee
and a.grantee in (select username from dba_users)
)
END AMOUNT_GRANTED_USERS,
rp.granted_role,
rp.admin_option,
rp.default_role
from dba_role_privs rp
where rp.granted_role='DBA';

4. Die dargestellten DBAs (SYS und SYSTEM) bekommen nun das neue Profile zugeordnet:

SQL> ALTER USER SYS PROFILE PRFL_ADMINS;
SQL> ALTER USER SYSTEM PROFILE PRFL_ADMINS;

5. Überprüfen Sie, welche Benutzer welche Profile aufweisen:

SQL> select username,
account_status,
profile
from dba_users order by 1;

6. So bringen Sie Ordnung in Ihre Datenbank und kennzeichnen die verschiedenen Benutzergruppen.
7. Das Default Profile sollte jetzt entsprechend Ihren Anforderungen angepasst werden. (Lassen wir hier aber aus).
Da der init.ora Parameter RESOURCE_LIMIT auf TRUE steht, werden die Kernel-Parameter in den Profilen aktiv genutzt.

Wer ist für das Account Management zuständig?

Prüfen Sie bitte selber, wer alles in der Datenbank für das Account Management zuständig ist. Das macht man am besten mit nachfolgendem SELECT:

[oracle@localhost ~]$ sqlplus /nolog
SQL> conn system/oracle@orcl
SQL> select grantee
     , count(granted_role) "Roles w/AdmOption"
     from dba_role_privs
    where grantee in (select username from dba_users)
      and admin_option ='YES'
    group by grantee
    order by 2 desc,1;

Das aufgezeigte Statement zeigt an, wer Rollen angelegt hat. Ist diese Verteilung auf verschiedene DB-Benutzer gewollt? Schaffen Sie in Ihrer Datenbank eindeutige Rollen, die für die entsprechenden Aufgaben z.B. eben für das Accountmanagement ausgestattet werden. Dann haben auch nur diese Rollen die Berechtigung, die man für das Account Management braucht, wie CREATE|ALTER...USER, CREATE ROLE...

Umgang mit SYS und SYSTEM – personalisierte DBAs

Die Empfehlung lautet wie folgt:
SYS nur in Notfällen verwenden z.B. für Patches, SYSTEM wird gesperrt und jeder DBA erhält eine eigene Kennung. Idealerweise nutzt man für die personalisierten DBAs eine Kerberos Authentisierung, um den Passwortwechsel über MS AD zu nutzen und eine automatische Passwort-Synchronisation zu haben. Somit existiert eine einheitliche und bestehende Passwort-Policy (über das MS AD oder einen anderen unternehmensweiten LDAP Dienst). Für einen professionellen Betrieb mit wenig Aufwand empfiehlt es sich auch für Admins Enterprise User Security mit Kerberos aufzusetzen.
In unserem Beispiel setzen wir nun die Empfehlung um und legen einen personalisierten DBA an.
1. SYSTEM wird gesperrt:

[oracle@localhost ~]$ sqlplus /nolog
SQL> conn / as sysdba
SQL> alter user SYSTEM account lock;

2. Nun legen wir einen personalierten DBA an (Achtung wir haben nun die PASSWORD-Policy angelegt, also > 8 Zeichen ):

SQL> CREATE USER <IhrName> identified by MeinOracle1
temporary tablespace temp default tablespace SYSAUX;
SQL> GRANT DBA to <IhrName>
SQL> alter user <IhrName> profile PRFL_ADMINS;

Admins sind zu personalisieren. So fordert es z.B. die Datenschutzverordnung.

Umgang mit dem Password-File

In der Regel findet man für die Datenbank folgenden Umgang mit dem Password-File:
1. Der Init.ora Parameter REMOTE_LOGIN_PASSWORDFILE wird auf den Wert EXCLUSIVE getzt werden. Das bedeutet, dass das Password File nur für eine DB genutzt werden kann.
2. Im Password-File befindet ein SYSDBA (SYS):

[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> select * from V$PWFILE_USERS;

Diese Einstellung bedeutet nun, dass sich ein SYSDBA remote an die Datenbank anmelden kann. Er wird dann über das Password-File authentisiert, auch wenn die Datenbank nicht verfügbar ist.
Ist es das was Sie wollen? Remote zu administrieren?
Wenn nein, sollten Sie das Password-File on-Demand anlegen, d.h. nur wenn Sie eine Remote-Administration vornehmen wollen bzw. müssen. Für alle anderen Fälle existiert die Passwort-Datei nicht. In unserem Fall brauchen wir keine Remote-Administration und löschen das Password-File einfach:
1. Password-Datei löschen:

$ cd $ORACLE_HOME/dbs
$ rm orapworcl

2. Nun kann man sich trotzdem über die Console an die Datenbank anmelden, da der „oracle“ user der OS-<dba> Gruppe angehört:

[oracle@localhost ~]$ sqlplus / as sysdba

3. Braucht man nun doch ein Password-File legt man es einfach an:

[oracle@localhost ~]$ orapwd FILE=orapworcl ENTRIES=1
Enter password for SYS: (hier bitte oracle eingeben)
[oracle@localhost ~]$ sqlplus / as sysdba
SQL> select * from V$PWFILE_USERS;

4. Der User SYS wird automatisch eingetragen.

Apps-Owner und Apps-User Setup

Auch eine Zwecktrennung für das Anwendungssetup in der Datenbank ist ein wichtiges Thema. Hierbei ist das Least Privilege – Prinzip anzuwenden.
1. Der Apps-Owner verwaltet die Objekte und hat keine hochprivilegierten Privilegien. Außerdem wird der Owner gesperrt. Wir geben dem Appsowner 1MB Quota auf den Tablespace USERS:

[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> create user appsowner identified by Ooracle9923911 temporary tablespace temp default tablespace users account lock;
SQL> alter user appsowner quota 1M on users;

2. Das Deployment wird von einem Release Manager durchgeführt. Bei uns ist das heute der personalisierte DBA:

SQL> conn <IhrName>/MeinOracle1@orcl
SQL> create table appsowner.anwendung (nr number, text varchar2(100));

3. Der Apps-User wird angelegt und bekommt alle Privilegien, die er benötigt. Das Account Management übernimmt auch der personalisierte DBA:

SQL> conn <IhrName>/MeinOracle1
SQL> create user appsuser identified by MeinOracle1 temporary tablespace temp default tablespace users;
SQL> grant create session to appsuser;
SQL> grant select, insert, delete, update on appsowner.anwendung to appsuser;

4. Der Apps-User kann sich nun anmelden und auf den Objekten des Apps-Owners operieren:

SQL> conn appsuser/MeinOracle1@orcl
SQL> insert into appsowner.anwendung values (1,'Zeile1');
SQL> insert into appsowner.anwendung values (2,'Zeile2');
SQL> insert into appsowner.anwendung values (3,'Zeile3');
SQL> commit;
SQL> select * from appsowner.anwendung;

So würde ein richtiges Apps-Owner und Apps-User Konzept/Setup aussehen. Natürlich sehr vereinfacht. Im Idealfall hat man mehrere Apps-User für unterschiedliche Aufgaben mit unterschiedlichen Berechtigungen. Die Berechtigungen werden natürlich in Rollen zusammengefasst.

Lab 5: Datenschutz auf Zeilenebene

In diesem Bereich stellt Oracle verschiedene Mechanismen zur Verfügung. Wir betrachten hier insbesondere

Row Level Security(RLS) oder Virtual Private Database (VPD)
Data Redaction, also das Redigieren von Informationen
Data Masking, die Pseudonymisierung von Daten bevor diese ausgetauscht werden, z.B. Produktionsdaten für das Development (behandelt wir hier nicht)

Virtual Private Database (VPD)

VPD schränkt den Zugriff auf Daten zur Laufzeit sein, in dem durch geeignete Policies Bedingungen zur Laufzeit ausgeführt werden. Hierfür führen wir folgendes Beispiel (lab5/VPD_Demo.sql)aus:
1. Als SYS legen wir die User für das VPD Beispiel an
Melden Sie sich als <IhrName> an und erstellen Sie die notwendigen Benutzer. Einen Apps-Owner und zwei Endbenutzer:

[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> CREATE USER orasec IDENTIFIED BY MeinOracle1
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session, create table TO orasec;
SQL> alter user orasec quota 1M on users;
SQL> CREATE USER orasec1 IDENTIFIED BY MeinOracle1
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session TO orasec1;
SQL> CREATE USER orasec2 IDENTIFIED BY MeinOracle1
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session TO orasec2;

2. Als Apps-Owner orasec die Objekte erstellen

SQL> CONNECT orasec/MeinOracle1@orcl
SQL> CREATE TABLE VPD_CUSTOMERS (
          "CUSTOMER_ID"      NUMBER(6) NOT NULL,
"CUST_FIRST_NAME" VARCHAR2(20) NOT NULL,
"CUST_LAST_NAME"   VARCHAR2(20) NOT NULL,
"CUST_EMAIL"       VARCHAR2(30),
CONSTRAINT "CUSTOMERS_PK" PRIMARY KEY("CUSTOMER_ID")
USING INDEX);
SQL> CREATE TABLE VPD_ORDERS (
"ORDER_ID"       NUMBER(12) NOT NULL,
"ORDER_DATE"     TIMESTAMP(6) WITH LOCAL TIME ZONE NOT NULL,
"CUSTOMER_ID"    NUMBER(6) NOT NULL,
"ORDER_STATUS"   NUMBER(2),
"ORDER_TOTAL"    NUMBER(8, 2),
"REP_ID"      NUMBER(6) NOT NULL,
CONSTRAINT "ORDERS_CUSTOMER_ID_FK" FOREIGN KEY("CUSTOMER_ID")
REFERENCES "VPD_CUSTOMERS"("CUSTOMER_ID"),
CONSTRAINT "ORDER_PK" PRIMARY KEY("ORDER_ID") USING INDEX)
LOGGING ;
SQL> CREATE TABLE VPD_ITEMS (
"ORDER_ID" NUMBER(12) NOT NULL,
"LINE_ITEM_ID" NUMBER(3) NOT NULL,
"PRODUCT_ID" NUMBER(6) NOT NULL,
"UNIT_PRICE" NUMBER(8, 2),
"QUANTITY" NUMBER(8),
CONSTRAINT "ORDER_ITEMS_ORDER_ID_FK" FOREIGN KEY("ORDER_ID")
REFERENCES "VPD_ORDERS"("ORDER_ID") ON DELETE CASCADE NOVALIDATE,
CONSTRAINT "ORDER_ITEMS_PK" PRIMARY KEY("ORDER_ID", "LINE_ITEM_ID") USING INDEX)
LOGGING ;

3. Erstelle die Tabelle für das Mapping. Die Salesreps werden in der Order Tabelle gemappt:

SQL> CREATE TABLE VPD_REPS
(id          NUMBER(6)    NOT NULL,
ouser       VARCHAR2(30) NOT NULL,
first_name VARCHAR2(50) NOT NULL,
last_name   VARCHAR2(50) NOT NULL);

4. Fülle die Tabellen mit Daten:

SQL> INSERT INTO vpd_reps VALUES (0,'ORASEC','Schema','Owner');
SQL> INSERT INTO vpd_reps VALUES (1,'ORASEC1','John','Hansen');
SQL> INSERT INTO vpd_reps VALUES (2,'ORASEC2','David','Tolosana');
SQL> Insert into VPD_CUSTOMERS (CUSTOMER_ID,CUST_FIRST_NAME,CUST_LAST_NAME,CUST_EMAIL) values (1,'Peter','Pan','peter.pan@disney.com');
SQL> Insert into VPD_CUSTOMERS (CUSTOMER_ID,CUST_FIRST_NAME,CUST_LAST_NAME,CUST_EMAIL) values (2,'Donald','Duck','donald.duck@disney.com');
SQL> Insert into VPD_CUSTOMERS (CUSTOMER_ID,CUST_FIRST_NAME,CUST_LAST_NAME,CUST_EMAIL) values (3,'Dagobert','Duck','dagobert.duck@disney.com');
SQL> Insert into VPD_ORDERS (ORDER_ID,ORDER_DATE,CUSTOMER_ID,ORDER_STATUS,ORDER_TOTAL,REP_ID) values (1,to_timestamp('29-NOV-13 01.14.28.926000000 PM','DD-MON-RR HH.MI.SSXFF AM'),1,1,100,1);
SQL> Insert into VPD_ORDERS (ORDER_ID,ORDER_DATE,CUSTOMER_ID,ORDER_STATUS,ORDER_TOTAL,REP_ID) values (2,to_timestamp('29-NOV-13 01.14.56.275000000 PM','DD-MON-RR HH.MI.SSXFF AM'),2,1,200,2);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (1,1,1,50,1);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (1,2,2,10,5);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (2,1,1,50,2);
SQL> Insert into VPD_ITEMS (ORDER_ID,LINE_ITEM_ID,PRODUCT_ID,UNIT_PRICE,QUANTITY) values (2,2,3,10,10);
SQL> Commit;

5. Erstellen Sie die Zugriffsrechte an die Endbenutzer. Normalerweise würden wir Rollen anlegen:

SQL> GRANT SELECT ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT INSERT ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT UPDATE ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT DELETE ON VPD_CUSTOMERS TO orasec1, orasec2;
SQL> GRANT SELECT ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT INSERT ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT UPDATE ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT DELETE ON VPD_ORDERS TO orasec1, orasec2;
SQL> GRANT SELECT ON VPD_ITEMS TO orasec1, orasec2;
SQL> GRANT INSERT ON VPD_ITEMS TO orasec1, orasec2;
SQL> GRANT UPDATE ON VPD_ITEMS TO orasec1, orasec2;
SQL> GRANT DELETE ON VPD_ITEMS TO orasec1, orasec2;

6. So, das Daten-Modell steht. Erteilen Sie nun ORASEC Privilegien für das Anlegen der späteren VPD Policies :

SQL> CONNECT / as sysdba
SQL> GRANT create any context, create public synonym, create procedure TO orasec;
SQL> GRANT EXECUTE ON SYS.DBMS_RLS TO orasec;

7. ORASEC erstellt den Context, der später beim Login gefüllt wird, darüber wird der Endbenutzer identifiziert und in der VPD Policy eindeutig zugeordnet:

SQL> CONNECT orasec/MeinOracle1@orcl
SQL> CREATE CONTEXT orasec USING orasec.Context_Package;
SQL> CREATE OR REPLACE PACKAGE Context_Package AS
          PROCEDURE Set_Context;
          END;
/
SQL> CREATE OR REPLACE PACKAGE BODY Context_Package IS
   PROCEDURE Set_Context IS
    v_ouser VARCHAR2(30);
    v_id     NUMBER;
BEGIN
    DBMS_Session.Set_Context('ORASEC','SETUP','TRUE');
    v_ouser := SYS_CONTEXT('USERENV','SESSION_USER');
    BEGIN
      SELECT id INTO   v_id
        FROM   vpd_reps
       WHERE ouser = v_ouser;
      DBMS_Session.Set_Context('ORASEC','REP_ID', v_id);
    EXCEPTION
      WHEN NO_DATA_FOUND THEN
        DBMS_Session.Set_Context('ORASEC', 'REP_ID', 0);
    END;
    DBMS_Session.Set_Context('ORASEC','SETUP','FALSE');
END Set_Context;
END Context_Package;
/
SQL> GRANT EXECUTE ON orasec.Context_Package TO PUBLIC;
SQL> CREATE PUBLIC SYNONYM Context_Package FOR orasec.Context_Package;

8. Der SYS erstellt den Logon-Trigger in dem der Context dem Benutzer zugewiesen wird.

SQL> CONNECT <IhrName>/MeinOracle1@orcl
SQL> CREATE OR REPLACE TRIGGER orasec.Set_Security_Context
AFTER LOGON ON DATABASE
BEGIN
orasec.Context_Package.Set_Context;
END;
/

9. Der Anwendungsowner legt nun die VPD Policy an. Die Policy ermittelt über den Context den aktuellen Benutzer und garantiert, dass nur die Kundendaten gelesen und verändert werden können, die dieser Benutzer betreuit. D.h. die Table VPD_ORDERS wird immer mit der REP_ID auf den aktuellen Benutzer eingeschränkt

SQL> CONNECT orasec/MeinOracle1@orcl
SQL> CREATE OR REPLACE PACKAGE Security_Package AS
FUNCTION User_Data_Security(Owner VARCHAR2, Objname VARCHAR2)
    RETURN VARCHAR2;
END Security_Package;
/
SQL> CREATE OR REPLACE PACKAGE BODY Security_Package IS
FUNCTION User_Data_Security(Owner VARCHAR2, Objname VARCHAR2)
RETURN VARCHAR2 IS
    Predicate VARCHAR2(2000);
BEGIN
    Predicate := '1=2';
    IF (SYS_CONTEXT('USERENV','SESSION_USER') = 'ORASEC') THEN
      Predicate := NULL;
    ELSE
      Predicate := 'REP_ID = SYS_CONTEXT(''ORASEC'', ''REP_ID'')';
    END IF;
    RETURN Predicate;
END User_Data_Security;
END Security_Package;
/
SQL> GRANT EXECUTE ON orasec.Security_Package TO PUBLIC;
SQL> CREATE PUBLIC SYNONYM Security_Package FOR orasec.Security_Package;
SQL> BEGIN
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_SELECT_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'SELECT');
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_INSERT_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'INSERT');
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_UPDATE_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'UPDATE');
DBMS_Rls.Add_Policy('orasec', 'VPD_ORDERS', 'VPD_ORDERS_DELETE_POLICY', 'orasec', 'SECURITY_PACKAGE.USER_DATA_SECURITY', 'DELETE');
END;
/

10. VPD ist fertig konfiguriert. Der Anwendungsowner sieht alle Daten, die Endbenutzer sehen nun nur die Daten der betreuten Kunden. Testen Sie selber:

SQL> connect orasec/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> connect orasec1/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;
SQL> connect orasec2/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;

11. Was passiert nun, wenn wir einen neuen Benutzer anlegen, sieht der überhaupt etwas, wenn keine Zuordnung besteht. Testen Sie selber:

SQL> CONNECT <IhrName>/MeinOracle1@orcl
SQL> CREATE USER orauser IDENTIFIED BY MeinOracle1
DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
SQL> GRANT create session TO orauser;
SQL> CONNECT orasec/MeinOracle1@orcl
SQL> GRANT SELECT ON VPD_CUSTOMERS TO orauser;
SQL> GRANT SELECT ON VPD_ORDERS TO orauser;
SQL> GRANT SELECT ON VPD_ITEMS TO orauser;
SQL> CONNECT orauser/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;

12. Ja, tatsächlich der Benutzer hat zwar eine SELECT-Berechtigung kann aber keine Daten sehen, da er selber kein Salesrep ist. Nun, wie kann man die VPD Policy aushebeln?

SQL> CONNECT <IhrName>/MeinOracle1@orcl
SQL> GRANT EXEMPT ACCESS POLICY to orauser;
SQL> CONNECT orasec/MeinOracle1@orcl
SQL> select count(*) from orasec.vpd_orders;
SQL> select * from orasec.vpd_orders;

13. Also immer schön aufpassen, wer welche Privilegien bekommt. Achten Sie darauf, dass die Privilegien ordentlich verteilt werden. Am besten immer einen Extra-Account definieren, der Policies anlegt. Zusätzlich die Vergabe von wichtigen Privilegien überwachen.

Data Redaction

Data Redaction ist eine neue Funktion in der Datenbank Versionen 12c bzw. 11.2.0.4, die lizenztechnisch zu der Advanced Security Option gehört. Diese Funktion erlaubt eine Maskierung von Daten auf Datenbankebene und zeigt diese Maskierung dann durchgehend an, egal wie auf die Daten zugegriffen wird und wer zugreift. Data Redaction ist besonders wertvoll in der Nutzung mit Anwendungen. Sobald eine Data Redaction Policy deployed ist, werden die entsprechenden Daten geschützt und geschützt an die Anwendung weitergegeben.
Für die Anwendung einer Data Redaction Policy ist folgendes Szenario gegeben:
Der Anwendungsowner und Sicherheitsbeauftragte „orasec“ hat die Richtlinie ergeben, dass alle Kreditkarten-Daten in den Bestellungen nur für die Sales Reps sichtbar sind. (siehe lab5/REDACTION.sql)
1. Der SYS erteilt dem orasec User die Berechtigung Data Redaction anzuwenden:

[oracle@localhost ~]$ sqlplus / as sysdba
SQL> grant execute on DBMS_REDACT to orasec;

2. Nun ändern wir die Order Table und fügen eine Spalte für die Kreditkarten ein:

SQL> connect orasec/MeinOracle1@orcl
SQL> alter table vpd_orders add creditcard varchar2(12);
SQL> update vpd_orders set creditcard='990457 4556';
SQL> commit;

3. Nun legt der OraSec Benutzer die Redaction Policy an. Sie besagt, dass nur die Sales Reps die Kreditkarten Ihrer Kunden sehen, sonst keiner. Redigiert wird FULL, aber mit der PARTIAL Funktion, die dann aber die komplette Syntax mit „* Sternchen“ versieht

SQL> BEGIN
DBMS_REDACT.ADD_POLICY(
   object_schema   => 'orasec',
   object_name     => 'VPD_ORDERS',
   column_name     => 'CREDITCARD',
   policy_name     => 'CREDITCARD_DBA',
   function_type   => DBMS_REDACT.PARTIAL, --DBMS_REDACT.FULL,
   function_parameters => 'VVVVVVFVVVV,VVVVVV-VVVV,*,1,10',
   expression      =>
       'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') NOT IN
                    (''ORASEC1'',''ORASEC2'')'
);
END;
/

4. Nun wird getestet:

SQL> connect orasec/MeinOracle1@orcl
SQL> select customer_id, creditcard from vpd_orders;
SQL> connect orasec1/MeinOracle1@orcl
SQL> select customer_id, creditcard from orasec.vpd_orders;
SQL> connect orasec2/MeinOracle1@orcl
SQL> select customer_id, creditcard from orasec.vpd_orders;
SQL> connect / as sysdba
SQL> select customer_id, creditcard from orasec.vpd_orders;

Sehen Sie als SYS die Kreditdaten? Wenn ja, warum ist das wohl so?
Der SYS hat natürlich die Rolle DATAPUMP_EXP_FULL_DATABASE und diese beinhaltet die Berechtigung EXEMPT REDACTION POLICY, daher kann SYS die Daten im Orginal sehen. Achten Sie in Ihrem Konzept, wer was tun darf und trennen Sie die Aufgaben ordentlich, dann verlieren Sie nie oder selten die Kontrolle.

Lab 6: Zugriffskontrolle

Kommen wir zu der letzten Übung an diesem Tag. Die Zugriffskontrolle ist ein sehr wichtiger Baustein einer Oracle Datenbank. Hierüber steuert man, wer was in der Datenbank tun darf. Tatsächlich zeigt die Realität sehr komplexe Zugriffskonzepte, die viele tausende Grants benötigen und nur noch schwer zu kontrollieren sind. Darüber hinaus werden nicht nur komplexe Konzepte implementiert, sondern auch viele Fehler eingebaut. Es entstehen Redundanzen und teilweise auch Konzeptaushebelungen.
Darum ein Appell an dieser Stelle: Halten Sie Ihr Zugriffskonzept so einfach wie möglich. Einige grundlegende Regeln sind nachfolgend aufgeführt:

Nur Oracle Standard-Accounts haben Oracle Standard-Rollen
Alle anwendungsbezogenen Accounts erhalten speziell dafür angelegte Rollen. Diese Rollen wurden bewußt angelegt und der Inhalt der Berechtigungen in den Rollen ist bekannt.
Rollen wie CONNECT und RESOURCE werden nicht vergeben.
Nur die Admins erhalten eine Standardrolle wie DBA
Achten Sie darauf, dass man Privilegien nicht doppelt vergibt. Es reicht z.B. dem DBA die Rolle DBA zu gehen. CONNECT und RESOURCE braucht er nicht, da er mit der Rolle DBA alle Privilegien aus CONNECT und RESOURCE bereits besitzt.
Achten Sie darauf ausschließlich Rollen zu verwenden und nicht dem Account direkte Grants zuzuweisen (sofern das geht, mit 12c sollte das keine Probleme machen. In unseren Übungen haben wir der Einfachheit wegen direkte Grants verwendet).
Und ganz wichtig kennen Sie das Zugriffskonzept Ihrer Datenbank

Zugriffskontrolle transparent machen

Als Erstes schauen wir uns die eingestellte Zugriffskontrolle an. Dafür haben wir einige SELECT Statements vorbereitet:
1. Alle DBAs in der Datenbank

[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL> col GRANTEE format a30
SQL> col IS_USER format a4 heading is|User
SQL> col IS_ROLE format a4 heading is|Role
SQL> col AMOUNT_GRANTED_USERS heading AMOUNT|GRANTED|USERS
SQL> col granted_role format a7 heading granted|Role
SQL> col ADMIN_OPTION format a5 heading ADMIN|Option
SQL> col DEFAULT_ROLE format a6 heading DEFAULT|Role
SQL>select rp.grantee ,
       (select 'YES' from dba_users where username=rp.grantee) IS_USER,
       (select 'YES' from dba_roles where role=rp.grantee) IS_ROLE,
       CASE
         WHEN (select 'YES' from dba_roles where role=rp.grantee) = 'YES'
         THEN (select count(*) from dba_role_privs a
                where a.granted_role=rp.grantee
                  and a.grantee in (select username from dba_users)
              )
       END AMOUNT_GRANTED_USERS,
       rp.granted_role,
       rp.admin_option,
       rp.default_role
from dba_role_privs rp
where rp.granted_role='DBA'
/

Es sollten drei DBAs existieren und SYSTEM ist gelocked. Prüfen Sie das nochmal.
2. Wer hat Zugriff auf SYS-Objekte wie sys.user$:

SQL> col "GRANTEE" format a25
SQL> col IS_USER format a4 heading is|User
SQL> col IS_ROLE format a4 heading is|Role
SQL> col AMOUNT_GRANTED_USERS heading AMOUNT|GRANTED|USERS
SQL> col "SYS-OBJECT" format a25
SQL> SELECT DISTINCT a.GRANTEE ,
       (select 'YES' from dba_users where username=a.grantee) IS_USER,
       (select 'YES' from dba_roles where role=a.grantee) IS_ROLE,
       CASE
         WHEN (select 'YES' from dba_roles where role=a.grantee) = 'YES'
         THEN (select count(*) from dba_role_privs b
                where b.granted_role=a.grantee
                  and b.grantee in (select username from dba_users)
              )
       END AMOUNT_GRANTED_USERS,
       'SYS.'||table_name "SYS-OBJECT"
FROM DBA_TAB_PRIVS a
WHERE a.OWNER LIKE 'SYS'
AND a.TABLE_NAME LIKE '%$'
order by 1;

Was fällt Ihnen auf? XDB und APEX haben Zugriff auf SYS:USER$ und können somit alle Hashwerte der Passwörter auslesen. Ist das ok?
3. Wer hat welche System-Privilegien in der Datenbank?

SQL> set lines 200
SQL> col grantee format a30
SQL> col grantee_typ format a7 heading Grantee|Typ
SQL> col privilege format a40
SQL> select a.GRANTEE,
       CASE
       WHEN (SELECT 'X' from dba_users where username = a.grantee) IS NOT NULL
          THEN 'USER'
       WHEN (SELECT 'X' from dba_roles where role = a.grantee) IS NOT NULL
         THEN 'ROLE'
       END AS GRANTEE_TYP,
       a.PRIVILEGE,
       a.ADMIN_OPTION
from dba_sys_privs a
where a.grantee not in ('DBA','SYS')
order by 1,2,3;

Fällt Ihnen etwas auf? Es existieren hauptlich Standard Vergaben an Oracle Standard Account. Einige Accounts und Rollen sind sehr mächtig und weisen sogenannte ANY Privilegien wie SELECT ANY TABLE auf. Diese hoch privilegierten Rollen wie EXP_FULL_DATABASE gilt es zu schützen.
4. Schauen wir gleich, ob diese Rolle geschützt ist:

SQL> col name format a30
SQL> col PROTECTED_ROLE format a15   heading Protected|Role
SQL> select name,
       decode(password, null, 'NO',
                       'EXTERNAL', 'EXTERNAL',
                       'GLOBAL', 'GLOBAL',
                       'APPLICATION','APPLICATION',
                       'PASSWORD') PROTECTED_ROLE
from sys.user$
where type# = 0 and password is not null
order by 1;

Es gibt nur eine globale Standardrolle. Die Rolle, mit der man die komplette Datenbank exportieren kann, ist leider nicht geschützt.
Tipp: Eine gute Variante die Zugriffsberechtigung zu analysieren ist die Privilege Analyse, die Oracle mit der 12c Datenbank eingeführt hat.

Secure Application Roles

In dieser Übung wollen wir nun den Schutz einer wichtigen Rolle simulieren. Dafür legen wir eine eigene Rolle HR_ADMIN an.
Zu allererst legen wir eine Policy in Form von PL/SQL an:
1. Prozedur erstellen, die für bestimmte Personen und zu einer bestimmten Uhrzeit die Nutzung der HR_ADMIN Rolle erlaubt:

[oracle@localhost ~]$ sqlplus / as sysdba
SQL> CREATE OR REPLACE PROCEDURE SYS.ROLE_CHECK
           AUTHID CURRENT_USER
AS
BEGIN
IF (SYS_CONTEXT ('userenv','session_user')='ORASEC1')
    AND (TO_CHAR (SYSDATE, 'HH24') BETWEEN 8 AND 20)
THEN
     EXECUTE IMMEDIATE 'SET ROLE HR_ADMIN';
END IF;
END;
/

Die Policy sagt aus, dass ORASEC1 zwischen 8 und 20 Uhr diese Berechtigung nutzen darf.
2. Nun legen wir die secure Application Role an und weisen dieser Rolle Berechtigungen zu.

SQL> create role HR_ADMIN identified using sys.ROLE_CHECK;
SQL> grant select on sys.user$ to HR_ADMIN;
SQL> grant HR_ADMIN to orasec1;
SQL> grant execute on SYS.ROLE_CHECK to orasec1;

3. Nun probieren wir dieses Konstrukt aus:

SQL> conn orasec1/MeinOracle1
SQL> execute sys.ROLE_CHECK;
SQL> select * from sys.user$;

Die Rollenzuweisung hat funktioniert. Das Setzen der Rolle kann man geschickter machen, für die Übung reicht dieses Prinzip jedoch.

4. Nun verändern die Policy und schränken den Zugriff auf 19-20 Uhr ein.

SQL> connect / as sysdba
SQL> CREATE OR REPLACE PROCEDURE SYS.ROLE_CHECK
           AUTHID CURRENT_USER
AS
BEGIN
IF (SYS_CONTEXT ('userenv','session_user')='ORASEC1')
    AND (TO_CHAR (SYSDATE, 'HH24') BETWEEN 19 AND 20)
THEN
     EXECUTE IMMEDIATE 'SET ROLE HR_ADMIN';
END IF;
END;
/

5. Nun probieren wir dieses Konstrukt aus:

SQL> conn orasec1/MeinOracle1
SQL> execute sys.ROLE_CHECK;
SQL> select * from sys.user$;

Der Zugriff wurde verweigert.

Endbenutzer in der Datenbank sichtbar machen

Anwendungen sind meist in einer Dreischichten Architektur aufgebaut. D.h. die Anwendung wird über einen Client aufgerufen, der eine Anwendung auf dem Application Server ausführt und diese Anwendung meldet sich mit einem sogenannten Shared Account an die Datenbank an. In der Datenbank erkennt man leider nicht den Endbenutzer (der, der sich an der Anwendung angemeldet hat), sondern man sieht nur, dass der Application Server also die Anwendung angemeldet ist.
Diese Art der Konfiguration ist heute nicht mehr ausreichend. Endbenutzer sollten in der Datenbank sichtbar gemacht werden. Die Konfiguration ist sehr einfach. D.h eine technische Begründung warum Endbenutzer in der Datenbank nicht sichtbar, gilt heute nicht mehr.
Die Frage ist natürlich, warum sollen Endbenutzer sichtbar gemacht werden? Weill nur dann zusätzlichen Schutzmöglichkeiten aktiviert werden können. Kennt man den Endbenutzer, kann man zusätzliche Autorisierungsregeln definieren, die in der Anwendung nicht vorgegeben sind (empfiehlt sich gerade, wenn die Anwendung hochprivilegierte Benutzer wie DBAs benutzt), oder man kennt alle Benutzer, die sich lange Zeit nicht anmeldeten und kann diese de-aktivieren.
Wir haben zwei Beispiele mitgebracht, die den Endbenutzer in der Datenbank sichtbar machen. Einmal mittels einer JDBC-Verbindung (Java-Code) und das andere Beispiel nutzt sogenannte Proxy-Benutzer.
Eine weitere Möglichkeit ist das Setzen von CONTEXTS, wie im VPD Beispiel. Diese Möglichkeit werden wir in diesem Abschnitt nicht behandeln.

Endbenutzer im Java-Code vorbereiten

In diesem Beispiel werden wir zwei Codebeispiele durchspielen. Als erstes machen wir eine normale JDBC Connection auf und gucken, was wir in der DB sehen. Im zweiten Codebeispiel setzen wir den Client-Identifier und schauen nach, was wir in der DB sehen.
OracleJDBC.java:

// einfachen Java-Beispiel
import java.sql.*;
import java.util.*;
 
public class OracleJDBC {
  public static void main(String[] argv) {
   System.out.println("-------- Oracle JDBC Connection Testing ------");
   try {
    Class.forName("oracle.jdbc.driver.OracleDriver");
   } catch (ClassNotFoundException e) {
    System.out.println("Where is your Oracle JDBC Driver?");
   e.printStackTrace();
   return;
  }
  System.out.println("Oracle JDBC Driver Registered!");
  Connection connection = null;
  Statement stmt = null;
  try {
   connection = DriverManager.getConnection(
     "jdbc:oracle:thin:@localhost:1522:orcl", "scott", "tiger");
   } catch (SQLException e) {
   System.out.println("Connection Failed! Check output console");
   e.printStackTrace();
   return;
  }
  if (connection != null) {
   System.out.println("You made it, take control your database now!");
      try{
        stmt = connection.createStatement();
     System.out.println("SELECT USER FROM DUAL");
        ResultSet rs = stmt.executeQuery("SELECT USER FROM DUAL");
        while(rs.next()){
          String username = rs.getString("user");
          //Display values
          System.out.println("Username: " + username);
       }
       try{
        System.out.println("> Continue with ENTER...");
          System.in.read(); // => This line is just to stop until you press enter. 
       }catch(Exception e){
         e.printStackTrace();
      }
     }catch(SQLException se){
       se.printStackTrace();
     }
    System.out.println("\n============="); 
  } else {
   System.out.println("Failed to make connection!");
  }
 }
}

OracleJDBCEndbenutzer.java:

// einfachen Java-Beispiel
import java.sql.*;
import java.util.*;
import oracle.jdbc.OracleConnection;

 
public class OracleJDBCEndbenutzer {
  public static void main(String[] argv) {
   System.out.println("-------- Oracle JDBC Connection Testing ------");
   try {
    Class.forName("oracle.jdbc.driver.OracleDriver");
   } catch (ClassNotFoundException e) {
    System.out.println("Where is your Oracle JDBC Driver?");
   e.printStackTrace();
   return;
  }
  System.out.println("Oracle JDBC Driver Registered!");
  Connection connection = null;
  Statement stmt = null;
  try {
        String URL = "jdbc:oracle:thin:@localhost:1522:orcl";
        Properties info = new Properties();
        info.put("user","scott");
        info.put("password","tiger");
        info.put("v$session.program","Test-JDBC");
        info.put("v$session.osuser","oracle");
     connection = DriverManager.getConnection(URL, info);
   } catch (SQLException e) {
   System.out.println("Connection Failed! Check output console");
   e.printStackTrace();
   return;
  }
  if (connection != null) {
   System.out.println("You made it, take control your database now!");
      String[] metrics = new String[OracleConnection.END_TO_END_STATE_INDEX_MAX];
     //client Identifier setzen
     metrics[OracleConnection.END_TO_END_CLIENTID_INDEX] = "carsten Muetzlitz, wohnhaft in Potsdam";
     try{
       ((OracleConnection)connection).setEndToEndMetrics(metrics,(short)0);
     }catch(Exception oe){
       oe.printStackTrace();
     }
     try{
      stmt = connection.createStatement();
   System.out.println("SELECT USER FROM DUAL");
      ResultSet rs = stmt.executeQuery("SELECT USER FROM DUAL");
      while(rs.next()){
       String username = rs.getString("user");
      //Display values
      System.out.println("Username: " + username);
     }
     try{
      System.out.println("> Continue with ENTER...");
      System.in.read(); // => This line is just to stop until you press enter. 
     }catch(Exception e){
       e.printStackTrace();
     }
    }catch(SQLException se){
      se.printStackTrace();
    }
    System.out.println("\n============="); 
  } else {
   System.out.println("Failed to make connection!");
  }
 }
}

1. Den beiliegenden Javacode kompilieren:
hierzu den $ORACLE_HOME/jdbc/lib/ojdbc6.jar in Ihr Beispiel Directory (/home/oracle/labs/lab6) kopieren und den Java Code (OracleJDBC.java) kompelieren. Es entsteht unsere Java-Class

[oracle@localhost ~]$ cd /home/oracle/labs/lab6
[oracle@localhost ~]$ cp $ORACLE_HOME/jdbc/lib/ojdbc6.jar .
[oracle@localhost ~]$ javac OracleJDBC.java

2. Das Java Program ausführen:

[oracle@localhost ~]$ java -cp /home/oracle/labs/lab6/ojdbc6.jar:/home/oracle/labs/lab6 OracleJDBC

Das Programm bleibt stehen. Bitte öffnen Sie nun ein zweites Terminal und melden sich als sysdba in der Datenbank an:

[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl
SQL>

Jetzt können Sie die Sessions in der DB prüfen
Zurück in das andere Terminal folgendes Statement prüfen:

SQL> set lines 200
SQL> select username, program, client_identifier from v$session where username='SCOTT';

Im anderen Terminal bitte das Java Programm mit ENTER schliessen.

3. Wie Sie sehen, sieht man nur den angemeldeten User und den Programm Namen.
4. So nun wollen wir den Benutzer sichtbar machen.
Hierzu kompilieren Sie bitte den beigefügten OracleJDBCEndbenutzer.java Code:

[oracle@localhost ~]$ javac -classpath $ORACLE_HOME/jdbc/lib/ojdbc6.jar OracleJDBCEndbenutzer.java

Als nächsten Schritt führen wir das Java-Programm aus:

[oracle@localhost ~]$ java -cp /home/oracle/labs/lab6/ojdbc6.jar:/home/oracle/labs/lab6 OracleJDBCEndbenutzer

und führen das SQL Statement im SQL*Plus Fenster erneut aus

SQL> r

5. Wie Sie sehen, sehen wir nun den Endbenutzer und den richtigen Programmnamen.

Die Aussage ist:
Jede Java-Anwendung kann den Endbenutzer in der DB sichtbar machen. Mit 10g konnte man den Client-Identifier mit setClientIdentifier setzen, heute nutzt man die Oracle JDBC Extension mit OracleConnection.END_TO_END_CLIENTID_INDEX und setzt den aktuell angemeldeten Endbenutzer.
Siehe auch Method setClientIdentifier() Not Found In Interface oracle.jdbc.OracleConnection for JDBC 10g (Doc ID 369236.1)
Teilweise sind viele Anwendungen bereits so vorbereitet, dass man ohne Programmieraufwand den aktuell angemeldeten Benutzer bis zur Datenbank durchreichen kann. Z.B. die Oracle Lösungen Business Intelligence, eBusiness Suite und viele andere Lösungen, die auf einem Application Server ablaufen.

Endbenutzer meldet sich über einen Proxy User an

Nun will ich die sogenannten Proxyuser einführen. Oracle nennt dieses Konzept Lightweight Session Proxy Authentication. Um dieses Beispiel in der Praxis anzuwenden, führen wir folgende Schritte durch:
1. SQL*Plus aufrufen und als sysdba anmelden

[oracle@localhost ~]$ sqlplus <IhrName>/MeinOracle1@orcl

2. Jetzt erstellen wir in der Datenbank einen Anwendungsuser „App-User“ und den Enbenutzer „Joe“:

SQL> create user appuser identified by MeinOracle2;
SQL> create user joe identified by MeinOracle1;

3. Wir geben nur dem Endbenutzer entsprechende Berechtigung:
Er soll sich an die Datenbank anmelden können und darf die Tabelle scott.criticaldata lesen:

SQL> GRANT CREATE SESSION to joe;
SQL> GRANT SELECT on scott.criticaldata to joe;

4. Nun erlauben wir dem Apps-User sich über Joe an die Datenbank anzumelden

SQL> alter user joe grant connect through appuser;

5. Wir melden uns über den Appsuser an die Datenbank an (PW vom Appsuser) und schauen, was uns die DB sagt:

SQL> conn appuser[joe]/MeinOracle2@orcl
SQL> select * from scott.criticaldata;
SQL> select sys_context('userenv','current_user') from dual;
SQL> select sys_context('userenv','proxy_user') from dual;

Weitere Informationen:
http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/proxy/index.html
oder
Proxy Users and Auditing Proxy Users (Doc ID 782078.1)

Gut zu wissen - abschließendes Statement

Die Übungen, die wir hier durchspielten, sind kein vollständiges Ergebnis für Ihre Datenbanksicherheit, sondern nur ein Anfang. Oracle liefert vielfältige Informationen in der Online-Dokumentation, in der Knowledge Base vom Oracle Support sowie in einigen Whitepapern. Nutzen Sie diesen Anfang, um nun Ihre Datenbanksicherheit zu erhöhen und damit unsere Daten besser schützen.
Eine konsolidierte Zusammenfassung, wie die Sicherheit einer Datenbank überprüft werden kann, und aus der Überprüfung, die richtigen Maßnahmen für einen erhöhten Schutz abzuleiten, finden Sie z.B. sehr gut dokumentiert in dem neuen Buch „Oracle Security in der Praxis“, welches seit dem 1.Okt. 2013 im Buchhandel erhältlich ist.

Sichere Oracle Datenbanken aufbauen