Neue Vorsätze für das kommende Jahr 2014: Den Sicherheitszustand meiner Oracle Datenbank zu kennen!

Das neue Jahr steht bevor und damit neue Herausforderungen, neue gesetzliche Auflagen und andere wichtige betriebsbedingte Aufgaben.
Nehmen Sie sich die Zeit und prüfen Sie in diesem Zusammenhang den Sicherheitszustand Ihrer Oracle Datenbank. Wie das geht, finden Sie detailliert beschrieben im Buch "Oracle Security in der Praxis".

Oracle XML DB mit Benutzern aus dem Corporate Identity nutzen

Heute hat mir ein Kollege die Frage eines Kunden weitergeleitet:

Kann man die Microsoft Active Directory (MS AD) Benutzer verwenden, um sich an die Services der XML DB der Oracle Datenbank anzumelden?

Meine Antwort: Das sollte eigentlich mit der Enterprise User Security Funktionalität der Datenbank funktionieren.

Ausprobiert hatte ich das bis dato nicht, was ich dann gleich nachgeholt habe.

Enterprise User Security (EUS)

EUS ist eine Funktionalität innerhalb der Datenbank, die es erlaubt zentrale Benutzerverwaltungen auch für die Datenbank zu verwenden. In der Regel nutzen die meisten Unternehmen ein MS AD, aber auch LDAP Dienste anderer Hersteller können integriert werden.
Um diese zentralen Benutzerverwaltungen verwenden zu können, muss man die Datenbank gegen einen Oracle LDAP Dienst (wie Oracle Internet Directory, Oracle Unified Directory, Oracle Virtual oder Directory) registrieren und kann über den Oracle LDAP Dienst verschiedenste und bestehende LDAP Dienste wie MS AD, Novell eDir etc. einbinden. Wie das genau geht, ist in unterschiedlichen Quellen detailliert beschreiben. Ein neues Whitepaper von Oracle zu diesem Thema finden Sie hier (PDF).

Nutzt man das Oracle Internet Directory kann man z.B. den MS AD über Server Chaining oder die Directory Integration Plattform einbinden. Die Inhalte vom MS AD werden dann regelmäßig über ein anzulegendes Synchronization Profile synchronisiert.

Synchronization Profile für die Benutzer aus dem MS AD

Hat man das MS AD eingebunden, kann man nun die vorhandenen Benutzer für die Datenbank verwenden.

EUS mit MS AD User anwenden

Es wird ein neuer Benutzer im MS AD angelegt (oiduser1). Dieser Benutzer wird dann auch für die EUS mit der Datenbank verwendet.

AD User oiduser1 angelegt

Der neue AD User wird ins Oracle Internet Directory synchronisiert und kann dann mit der Oracle DB verwendet werden. Wenn der OID erfolgreich synchronisiert hat, ist der Benutzer sichtbar. Im nachfolgenden sehen Sie ein Screenshot des EM Database Control "EUS Configuration".

AD User im Enterprise Manager sichtbar

EUS ist korrekt aufgesetzt und somit kann man den AD Benutzer verwendet, um sich an der Datenbank anzumelden.

AD User meldet sich an die Datenbank an

EUS und somit AD User auch für die XML DB verwenden

Natürlich ist diese EUS Konfiguration völlig transparent für viele Anwendungen der Datenbank. So auch für die XML DB. XML DB ist in meiner Datenbank für HTTP freigeschaltet. Für das HTTP-Login in der Datenbank kann man nun auch MS AD Benutzer verwenden.

 

MS AD User Authentication für XML DB

Bitte beachten Sie auch ein ordentliches Access Control für Ihre XML DB zu konfigurieren.

Abschließend ist die Kundenfrage hiermit beantwortet. Geht nicht, gibt es nicht!

Mehr Sicherheit für Ihre Oracle Datenbank

Ein guter Artikel zur Datenbank Sicherheit auf blogs.oracle.com/securityDE/ heute gepostet.

Weitere Informationen in detaillierter Form im neuen Buch Oracle Security in der Praxis.

Rezension & Verlosung des neuen Buchs "Oracle Security in der Praxis"

Bis zum 15. Oktober verlose ich 5 Bücher "Oracle Security in der Praxis" für interessierte Leser, die bereit sind nach dem Lesen des Buches eine Rezension zu schreiben.
Idealerweise schreibt man eine Rezension bei Amazon.de oder auf den Seiten von Hanser.de.

Schreiben Sie einfach einen Kommentar zu diesem Blog-Beitrag und schon nehmen Sie an der Verlosung teil. Sie werden dann über Email informiert. Alternativ können Sie mir auch eine Email an "herr at carsten-muetzlitz.de" senden.

Vielen Dank.

Nachtrag zu meinem DOAG SIG Security Vortrag am 11.9.2013 in Berlin

Zu meinem Vortrag auf der gestrigen Veranstaltung  möchte ich zwei Ergänzungen nachliefern.

1. Setup Application Owner Setup

Im Vortrag stellte ich aus Sicht der Sicherheit ein richtiges und falsches Setup für Anwendungsowner vor. Ein Anwendungsowner ist dasjenige Schema, welches in der Datenbank die Datenbank-Objekte der Anwendung verwaltet.
Das nachfolgende Bild zeigt das richtige Setup auf.

Anwendungsowner Setup (Richtig)

Hierbei ist es wichtig, dass der Zugriff auf die Objekte im Anwednungsowner Setup über einen sogenannten Awendungsuser stattfindet. Dieser Anwendungsuser hat besondere Rechte, um damit auf den Objekten des Anwendungsowner operieren zu können (least privilege). Der Anwendungsowner ist gesperrt und dient lediglich als Speicher der Objekte. Ein Release Manager deployed neue Release in das Anwendungsowner Schema.
Der Vorteil dieses Setup ist eine Zwecktrennung und natürlich eine zugeschnittene Zugriffskontrolle für den Anwendungsuser, also die Umsetzung eines Least-Privilege Konzept.
In der Veranstaltung kam der Einwand, dass dieses theoretische Setup nicht praktikabel sei, da Anwendungshersteller zum Teil ein anderes Konzept verfolgen, welches ich als falsch betrachte. Diese Aussage ist natürlich richtig und eine Anpassung kann u.U. nicht trival sein, sowie zu einem Supportverlust führen.

Anwendungsowner Setup (falsch)

Wenn man bestehende (u.U. falsche) Anpassungen nicht ändern kann, sollte man zumindest das Risiko einschätzen und geeignete Maßnahmen einleiten, welche das Risiko eines falsches Konzeptes abmildern. Hat man z.B. ein Setup eines Anwendungsowner mit der die Anwendung direkt arbeitet, so kann es zu folgenden Risiken kommen:

1. Der Anwendungsowner hat sehr mächtige Privilegien wie ANY Grants. Diese mächtigen Privilegien können die Endbenutzer indirekt auf der Datenbanken ausführen, da die Anwendung die Verbindung zur Datenbank über den Anwendungsowner herstellt.
2. Die Anwendung autorisiert die Endbenutzer in der Anwendung und mildert so die mächtigen Privilegien in der Datenbank bereits in der Anwendung ab. D.h. aber auch, dass die Anwendung Sicherheit garantieren muss und z.B. SQLInjections nicht möglich sind. Das heisst aber auch weiter, dass man garantieren muss, dass nur die Anwendung (denn die autorisiert) mit dem Anwedungsowner-Schema arbeitet.
3. Zugriffe auf den Anwendungsowner werden auch dazu missbraucht direkt auf den Daten zu arbeiten z.B. für ein Reporting mittels Tools wie MS Excel, Toad, SQL Developer etc.. Hierbei können die mächtigen Privilegien missbraucht werden. Daher ist solch ein Zugriff zu unterbinden.
4. Es werden Datenintegrationen via DB Links aufgebaut, die direkt mit den Anwendungsowner arbeiten. Das führt u.U. wieder zum Missbrauch der mächtigen Privilegien.

Anwendungsarchitektur eines falsches Anwendungsowner Setups

Kann man das falsche Setup nicht verhindern oder anpassen, muss man sich dem Risiko 1) bewußt sein und Maßnahmen für das Risiko 2) erzwingen, wie z.B. nur die Anwendung darf auf das Schema zugreifen und der Zugriff wird auf Ausführung kritischer Aktivitäten überwacht.
Für die Risiken 3) und 4) agiert man meistens aus eigener Motivation und sollte hier unbedingt, dass richtige Setup umsetzen, also auf die Least Privilege achten und eine richtige Zwecktrennung durchführen.

2. Wann muss gepatched werden?

Oracle liefert vierteljährlich sogenante Security Patch Updates (SPU) oder Critical Patch Updates (CPU). Eine Übersicht der letztes Updates finden Sie hier.
Nun höre ich oft, dass man Patching einmal oder zweimal im Jahr durchführt. Diese Strategie halte ich für falsch. Die richtige Strategie ist eine interne Entscheidungsgrundlage zu definieren, die aussagt, wann gepatched werden muss. Hierfür muss auch das Buyin der Fachabteilung eingeholt werden, die dann diese Entscheidung mitträgt.
Die Risikomatrix zu einem CPU oder SPU kann hier die notwendige Grundlage schaffen. Es werden die Komponenten dargestellt, die eine Schwachstelle aufweisen und mit einem Risikofaktor versehen. Der Faktor 10 stellt das höchste Sicherheitsrisiko dar. Somit könnte man z.B. folgede Entscheidungsgrundlage formulieren:
"Wenn in unseren Datenbanken mit hohem Schutzbedarf eine genutzte Komponente mit einer Schwachstelle betroffen ist, die einen Risikofaktor > 6.5 hat und zu erheblichen Bedrohungen für das Business führen kann, dann muss gepatched werden. Wenn diese Situation eintritt, muss der entsprechende Patch/CPU innerhalb von einer definierten Zeit (z.B. 2 Monate) deployed werden."
Während meiner Präsentation kam der Einwand, dass diese Strategie nicht praktikabel sei, wenn Kunden tausende von Datenbanken betreiben. Der Aufwand des Patchens wäre zu umfangreich.
Diesen Einwand kann ich verstehen, hat aber nichts mit meiner Strategievorlage zu tun. Der Einwand beschreibt das "WIE". Also wie patche ich u.U. tausende von Datenbankinstances sehr effizient, wenn die interne Entscheidung sagt: "Lt. gegebenen Risiko müssen wir patchen".
Nun könnte man den Einwand auch so verstehen, dass der Einwandgeber sagen wollte: "Ja, eigentlich richtige Strategie, aber wegen der Masse der Datenbanken kann man nicht auch das Risiko betrachten und andauernd patchen."
Die Menge der Datenbanken sollte nicht dazu führen, dass man sich das Risiko nicht bewusst macht. Es ist keine trivale Aufgabe tausende von Datenbanken regelmäßig zu patchen, trotzdem befreit die Menge der Datenbanken sich nicht vor der Entscheidung "wann gepatched werden muss". Natürlich müssen hier die internen Gegebenheiten eingearbeitet werden. Fakt ist, ein nicht-patchen führt automatisch zu einem erhöhten Risiko.
Nachdem man die Entscheidungsgrundlage geschaffen hat, muss man sich über das "WIE" Gedanken machen. Also wie kann der Patch effizient in den betroffenen und schutzbedürftigen Datenbanken deployed werden.
Oracle hat in seinem Datenbank-Administrationsbaukasten Enterprise Manager geeignete Lösungen, um ein Patching zu vereinfachen. Das nachfolgende Bild stellt einen typischen Prozess dar:

Patching Prozess mit Oracle Enterprise Manager Hilfsmitteln

Das Buch zur Oracle DB Security in der Praxis

Erscheint im Oktober und kann bereits bei Amazon.de vorbestellt werden,

Dieses Buch ist einzigartig:

• Eine vollständig dokumentierte Vorgehensweise die Sicherheit der DB zu überprüfen
• Vollgestopft mit Best Practices, Tools und vielen Erkenntnissen
• Ab Okt. 2013 im Handel erhältlich

Die Oracle Database 12c Multitenant Architektur

Eine schöne Übersicht der neuen 12c DB Architektur finden man hier: Multitenant Architektur

DB Security 12c Serie 2: PL/SQL Invoker Rights

Es gibt zwei Arten von Aufrufen für PL/SQL Funktionen:

• Definer’s Right (AUTHID = DEFINER)
  Zur Compilezeit werden die Berechtigungen geprüft
• Invoker’s Right (AUTHID = CURRENT_USER)
  Zur Laufzeit werden die Berechtigungen geprüft

Der wesentliche Unterschied ist, dass eine PL/SQL Funktion mit AUTHID=CURRENT_USER die Berechtigungen des Aufrufenden nutzt. Somit könnte man z.B. eine PL/SQL Funktion implementieren, die eine Aktion ausführt, für die der Entwickler keine Berechtigungen zum Zeitpunkt der Erstellung besitzt. D.h. weiter ein Entwickler kann über PL/SQL für kurze Zeit (nämlich während der Ausführung der Funktion) Berechtigungen von Benutzer ausnutzen, wie z.B. die Berechtigungen eines DBAs.

PL/SQL Beispiel: Entwickler hat nicht das CREATE USER Recht

create or replace procedure check_syntax authid current_user is
begin
execute immediate 'GRANT DBA TO ENTW1';
end;
/

PL/SQL mit AUTHID=CURRENT_USER:

Haben Sie schon einmal in Ihrer Datenbank geprüft, welches PL/SQL Funktionen und Prozeduren mit Invoker Rechten ausgeführt werden? Kennen Sie den Source-Code dieser PL/SQL-Logiken? Ja, dann sollten Sie alles unter Kontrolle haben, oder? Nein, Sie kennen nicht den Zustand, dann prüfen Sie doch einfach mal, was in Ihrer Oracle-Datenbank an PL/SQL mit Invoker Rechten existiert:

SQL Beispiel für 12c: Ermittlung der Invoker PL/SQL Logiken

select a.owner, 
       a.object_type,
       a.authid,
       b.name as CONTAINER,
       count(*)
 from cdb_PROCEDURES a,
      v$containers b
 where a.con_id =b.con_id
 group by a.owner, a.object_type, a.authid, b.name
 order by 1,2,3;

SQL Beispiel für 11g: Ermittlung der Invoker PL/SQL Logiken

select a.owner, 
       a.object_type,
       a.authid,
       count(*)
 from DBA_PROCEDURES a
 group by a.owner, a.object_type, a.authid
 order by 1,2,3;

Führen Sie doch einfach dieses Select-Statement für die entsprechende DB-Version aus. Sind Sie überrascht?

Mit der DB 12c wurde das Konzept "Invoker Rechte"angepasst

In 11g hatte der Owner - also der Ersteller - der PL/SQL-Logik die Kontrolle, zu entscheiden wie die Logik ausgeführt wird. Mit 12c wurde nun eine sinnvolle und neue Restriktion eingeführt.

Oracle prüft nun zusätzlich die Privilegien des Owners der Procedure, wenn ein Benutzer ein Invoker Right’s Procedure ausführt. D.h. der Owner muss das INHERIT PRIVILEGES Object Privileg oder INHERIT ANY PRVILEGES besitzen. Ist das nicht der Fall ist, dann wirft die Datenbank einen Fehler.
Somit kann jeder Ausführende selber entscheiden, ob seine Berechtigung zur Ausführung einer PL/SQL Logik missbraucht werden kann. 

Oracle Empfehlung für den Einsatz von INVOKER Rights in PL/SQL und Views:

1. Immer dann wenn eine PL/SQL Procedure in einem hoch privilegierten Schema erstellt und von anderen genutzt werden soll (z.B. in einem DBA Schema). Wenn weniger privilegierte User diese Procedure aufrufen, dann können diese Benutzer zur Zeit der Ausführung mehr in der Datenbank tun, als sie tatsächlich dürfen.
   Darum empfiehlt sich eine Invoker's Rights Procedure, denn dann läuft die PL/SQL Logik mit den Rechten des Aufrufers also des Invokers..
2. Immer dann wenn das PL/SQL kein SQL enthält und verfügbar für viele andere Nutzer sein muss, wie das Package DBMS_OUTPUT.

Coole URL: World biggest Data Breaches

Diese Visualierung der weltgrössten Datenverluste ist einfach zu schön und muss gezeigt werden:
Check it out:
World biggest data breaches

DB 12c Security Serie 1: Die Resource Rolle

Mit der Serie der Neuerungen in der 12c Datenbank bezogen auf Security möchte ich nicht mit den großen Veränderungen beginnen.
Natürlich gibt es bahnbrechende Erneuerungen wie die Mandantenfähigkeit (Multitenant), das vervollständigte Information Lifecycle Management (ILM) Konzept, neue Funktionen zur Steigerung der Verfügbarkeit wie Global Data Services, Application Continuity oder Active Dataguard Far Syn und auch neue Konzepte für die Datensicherheit wie Redaction, die Privilege Analysis, die durchgängige implementierte Zwecktrennung und das unified Auditing.
Ich beginne mit den kleinen Veränderungen und Neuerungen, die die bekannte und sehr gute Sicherheit der Oracle Datenbank weiter abrunden.
Ich empfehle schon seit langer Zeit die Nutzung eigener definierter Rollen für die Anwendungen, die in der Datenbank betrieben werden. Der Hintergrund dieser Empfehlung ist sehr einfach:

Oft sehe ich das Rollen wie CONNECT und RESOURCE als Standardrollen vergeben werden, ohne zu prüfen, ob die Berechtigungen in diesen Rollen wirklich dem "least privilege" folgen, also wirklich notwendig sind. Das führte dazu, dass Datenbankbenutzer in älteren Datenbank Versionen z.B. über die Rolle CONNECT ein "ALTER SESSION" Privileg bekamen. Mit diesem Privilge konnten Sessions gedumped werden . Oder ermöglichte die Zuordnung der Rolle RESOURCE einem Datenbankbenutzer ein UNLIMITED TABLESPACE QUOTA, so dass die Datenbankbenutzer mit der RESOURCE Rolle jeden Tablespace unlimiert beschreiben konnten.

Bereits in der Datenbank Version 10.2 wurden die Privilegien der CONNECT Rolle auf "CREATE SESSION" reduziert.
Mit der aktuellen 12c (12.1) Version hat sich Oracle wieder entschieden, auch die Privilegien diesmal der RESOURCE Rolle zu beschneiden. Es wurde das Privileg "UNLIMITED QUOTA" entfernt. Somit sind ausschließlich folgende Privilegien in der RESOURCE Rolle zu finden:

SQL> select * from role_sys_privs where role ='RESOURCE' order by privilege;
                                ADMIN
ROLE       PRIVILEGE            OPTION COMMON
---------- -------------------- ------ ------
RESOURCE   CREATE CLUSTER          NO     YES
RESOURCE   CREATE INDEXTYPE        NO     YES
RESOURCE   CREATE OPERATOR        NO     YES
RESOURCE   CREATE PROCEDURE        NO     YES
RESOURCE   CREATE SEQUENCE        NO     YES
RESOURCE   CREATE TABLE            NO     YES
RESOURCE   CREATE TRIGGER          NO     YES
RESOURCE   CREATE TYPE              NO     YES

Was bedeutet das?

Mit der Datenbank Version 12c müssen die DBAs und Anwendungsowner QUOTA auf Tablespaces kontrolliert vergeben. Eine Zuordnung der Rolle RESOURCE reicht nicht mehr aus, und wurde sowieso entgegen von Sicherheitsbedenken von mir noch nie empfohlen. Also, bei einer Migration auf 12c bedenken, dass falls RESOURCE genutzt wurde, ein QUOTA Management aufgesetzt werden muss. Darüber hinaus sollte man auch gleich die Gelegenheit prüfen, wenn RESOURCE verwendet wurde, ob die darin verwendeten Privilegien wirklich zur Erfüllung der Aufgabe des Datenbankbenutzer benötigt werden. Es empfiehlt sich immer eigene Rollen entsprechend der notwendigen Privilegien zu erstellen. Eine Nutzung von Standardrollen für Nicht-Admins in der Datenbank sollte vermieden werden. Diese Weisheit erhöht die Kontrolle für das Berechtigungskonzept, denn eine eigene Erstellung bedingt es genau über die notwendigen Privilegien nachzudenken.