„Secure by Default” in Oracle 11g –
Die sichere Datenbank out-of-the-box?

Oracle hat viel unternommen, um die aktuelle Datenbank Version 11g sicherer zu gestalten. Sie liefert zahlreiche neue und verbesserte Security-Funktionen. Einen entscheidenden Anteil nimmt hierbei die neue Initiative „Secure by Default“ ein, die es dem Datenbankadministrator erleichtern soll, eine sicherere Datenbank out-of-the-box zu installieren. Mit der Initiative „Secure by Default“ starten wir eine neue Artikelreihe, in der wir unter anderem Maßnahmen für eine erhöhte Passwortsicherheit in 11g vorstellen und später auf Veränderungen im Security-Bereich eingehen, die Release 2 mit sich bringt.

Abb. 1: Abfrage im DBCA, ob die „Enhanced default security settings“ eingeschaltet werden sollen. Vergrößern ALTER ANY PROCEDURE CREATE ANY JOB DROP ANY TABLE ALTER ANY TABLE CREATE ANY LIBRARY DROP PROFILEE ALTER DATABASE CREATE ANY PROCEDURE DROP USER ALTER PROFILE CREATE ANY TABLE EXEMPT ACCESS POLICY AUDIT ROLE BY ACCESS CREATE EXTERNAL JOB GRANT ANY OBJECT PRIVILEGE ALTER SYSTEM CREATE PUBLIC DATABASE LINK GRANT ANY PRIVILEGE ALTER USER CREATE SESSION GRANT ANY ROLE ALTER SYSTEM CREATE USER AUDIT SYSTEM BY ACCESS DROP ANY PROCEDURE Abb. 2: Vordefinierte Einstellungen des Standard-Auditing unter Oracle 11g. SQL> select RESOURCE_NAME, LIMIT     from DBA_PROFILES    where PROFILE = 'DEFAULT'     and RESOURCE_TYPE = 'PASSWORD'; RESOURCE_NAME                    LIMIT -------------------------------- ------------------------- FAILED_LOGIN_ATTEMPTS             10 PASSWORD_LIFE_TIME                180 PASSWORD_REUSE_TIME UNLIMITED PASSWORD_REUSE_MAX UNLIMITED PASSWORD_VERIFY_FUNCTION NULL PASSWORD_LOCK_TIME                1 PASSWORD_GRACE_TIME               7 Abb. 3: Änderungen am Standard-Benutzerprofil beim Einschalten der „Enhanced Default Security Settings“. Abb. 4: Delayed Failed Login. Vergrößern BEGIN   DBMS_NETWORK_ACL_ADMIN.CREATE_ACL (     acl         => 'test_acl.xml',     description => 'Network permission for UTL_INADDR for user TEST_ACL',     principal   => 'TEST_ACL'     is_grant    => TRUE,     privilege   => 'resolve');     -- 'connect | resolve' END; / BEGIN   DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (     acl         => 'test_acl.xml',     host        => 'SLES10.ordix.de'); END; / commit; Abb. 5: ACL anlegen und einem Netzwerk Service zuweisen.

Überblick

Unter „Secure by Default“ versteht Oracle eine ganze Reihe von out-of-the-box-Maßnahmen, die die Oracle 11g Datenbank sicherer machen sollen als eine vergleichbare 10g-Installation. Diese Maßnahmen möchten wir Ihnen in diesem Artikel vorstellen:

• Standardmäßiges Auditing
• Änderungen am Standard-Benutzerprofil
• Verbesserte Überprüfung der Passwort-Komplexität
• Delayed Failed Logins
• Fine Grained Access Control (FGAC)bei Netzwerk-Callouts aus der Datenbank

Daneben spielen der verbesserte Passwortschutz und ein erweitertes Passwortmanagement eine zentrale Rolle unter den neuen Security-Funktionen, die Oracle 11g standardmäßig mit sich bringt. Dieses Thema wird jedoch erst Bestandteil des nächsten Artikels sein.

Ob und wie die hier eingeführten Maßnahmen wirklich zu einer out-of-the-box sichereren Datenbank führen und mit welchem Aufwand dies für den Datenbankadministrator zu erreichen ist, wird im Folgenden näher beleuchtet.

„Enhanced Default Security Settings” im DBCA 11g

Gleich zu Beginn des Arbeitens mit Oracle 11g R1 kommt der Anwender mit der neuen Initiative Secure by Default“ in Berührung. Denn schon der DBCA fragt sowohl beim Anlegen als auch beim nachträglichen Ändern der Datenbank, ob die „Enhanced default security settings“ eingeschaltet werden sollen:

Oracle empfiehlt, diese Frage mit dem ersten Auswahlpunkt zu beantworten (siehe Abbildung 1). Dies hat Anpassungen des Standard-Benutzerprofils sowie ein standardmäßiges Auditing bestimmter Operationen zur Folge, was in den folgenden zwei Absätzen näher erläutert wird.

Übrigens bietet Oracle mit 11g Release 2 diese Wahl nicht mehr an. Die „Enhanced Default Security Settings“ sind hier somit gesetzt und können im DBCA nicht mehr abgewählt werden.

Standardmäßiges Auditing

Über das Standard-Auditing lassen sich Aktionen von Benutzern in den drei Bereichen Objekte, Kommandos und Privilegien protokollieren.

Werden die „Enhanced Default Security Settings“ unter Oracle 11g eingeschaltet, so ändert sich der Default dieses Standard-Auditings folgendermaßen:

Der Parameter AUDIT_TRAIL steht dann auf DB, statt wie bisher auf NONE.

Viele Aktionen werden nun zwangsweise per Standard-Auditing (AUDIT...BY ACCESS) in die Audit-Tabelle SYS.AUD$ protokolliert. Hierzu zählen Aktionen, die unter Nutzung der in Abbildung 2 dargestellten Privilegien durchgeführt werden.

Was aus Gründen der Sicherheit eine gute Maßnahme darstellt, kann sich allerdings schnell zum Problem entwickeln, da es keinen Automatismus für das Löschen der Audit-Daten in der Audit-Tabelle (AUD$) gibt. Die Tabelle wird schnell zunehmend größer, was je nach Konfiguration bis zum Stillstand der Instanz führen kann. Die Tabelle sollte also in einen dedizierten Tablespace gelegt und die entstandenen Audit-Daten regelmäßig verarbeitet werden.

Zu diesem Zweck lohnt es sich, einen Blick auf das mit Patchset 11.1.0.7 eingeführte Paket DBMS_AUDIT_MGMT zu werfen; es bietet hilfreiche Prozeduren zur Administration (Verschieben, Bereinigen, etc.) der Audit-Tabellen.

Es empfiehlt sich außerdem, die obigen Audit-Einstellungen zu überprüfen und ggf. an die eigenen Bedürfnisse anzupassen; einige sind gewiss zu viel des Guten (z. B. CREATE SESSION...WHENEVER SUCCESSFUL), andere könnten sicherlich noch hinzugefügt werden.

Änderungen am Standard-Benutzerprofil

Durch das Einschalten der „Enhanced Default Security Settings“ werden nicht nur die Einstellungen für ein standardmäßiges Auditing aktiviert, sondern auch Änderungen am Standard-Benutzerprofil vorgenommen (siehe Abbildung 3).

Drei der Profileinstellungen, PASSWORD_LOCK_TIME, PASSWORD_GRACE_TIME und PASSWORD_LIFE_TIME, werden durch die automatische Anpassung nun restriktiver behandelt. So bedeutet die PASSWORD_LIFE_TIME von 180, dass sämtliche Benutzer nach 180 Tagen ihr Passwort ändern müssen!

Was aus Security-Sicht sicherlich der richtige Ansatz ist, führt jedoch bei auf die Datenbank zugreifenden Programmen (Skripte, Batch, Application Server, etc.), die ihre Kennwörter fest verdrahtet haben und diese nicht selbstständig ändern können, zum Absturz nach 180 Tagen!

Um dies zu verhindern, empfiehlt es sich, vor Ablauf der 180 Tage ein spezielles Profil anzulegen, in dem PASSWORD_LIFE_TIME auf UNLIMITED gesetzt wird, und das Profil nur den Benutzern zuzuteilen, deren Passwort aus genannten Gründen nie ablaufen soll.

„Enhanced Default Security Settings“ ein-/ausschalten

Die „Enhanced Default Security Settings“ werden über die Ausführung des Skriptes $ORACLE_HOME/rdbms/admin/secconf.sql eingeschaltet. Dieses Skript wird automatisch bei neu unter 11g erstellten Datenbanken – unabhängig davon, ob sie per Skript (!) oder DBCA erstellt wurden – ausgeführt.

Lediglich der Gang über den DBCA ermöglicht es, diese Einstellungen über den entsprechenden Bildschirm (siehe Abbildung 1) einzeln oder in Gesamtheit auszuschalten. Hierfür ruft der DBCA die beiden Skripte undoaud.sql und undopwd.sql im Verzeichnis $ORACLE_HOME/rdbms/admin auf, um die Änderungen am Standard Auditing und Profil nach dem Anlegen der Datenbank wieder rückgängig zu machen.

Bei auf 11g migrierten Datenbanken werden die „Enhanced Default Security Settings“ grundsätzlich nicht eingeschaltet.

„Secure by Default“ – Verbesserte Passwort-Verifizierungsfunktion

Oracle liefert mit dem erweiterten Passwort-Management, das bereits in Oracle 8i eingeführt wurde, folgendes Skript aus: $ORACLE_HOME/rdbms/admin/utlpwdmg.sql
Über die Ausführung dieses Skriptes wird in der Datenbank eine PL/SQL-Funktion angelegt, die neu eingegebene oder geänderte Benutzerkennwörter auf ausreichende Komplexität überprüft.

In der Oracle Version 11g wurde das Skript utlpwdmg.sql um die zusätzliche Funktion VERIFY_FUNCTION_11G erweitert, in der die Anforderungen an die Komplexität des Passwortes signifikant erhöht wurden:

• Minimale Passwortlänge von 8 Stellen (bisher: 4 Stellen)
• Passwort ungleich Username(1-100) (neu)
• Passwort ungleich Username rückwärts geschrieben (neu)
• Passwort ungleich Datenbankname, Datenbankname(1-100) (neu)
• „Einfache“ Passwörter werden geprüft (z. B. welcome1, database1, user1234, etc.)
• Passwort ungleich oracle(1-100) (neu)
• Passwort muss mindestens 1 Buchstabe und mindestens 1 Zahl beinhalten (bisher: 1 Buchstabe, 1 Zahl und 1 Sonderzeichen)

Da die neue Verifizierungsfunktion auch in 11g standardmäßig nicht eingerichtet ist, muss das Skript utlpwdmg.sql weiterhin explizit ausgeführt werden.

Die Ausführung des Skriptes hat neben der Anlage der neuen Funktion aber auch Änderungen am Standard Benutzerprofil zur Folge: Der Profil-Parameter PASSWORD_VERIFY_FUNCTION wird auf VERIFY_FUNCTION_11G geändert. Darüber hinaus werden die auf die Ressource PASSWORD bezogenen Parameter gemäß den „Enhanced Default Security“-Einstellungen neu gesetzt.

„Secure by Default“ – Verzögertes Login bei falscher Passworteingabe

Der Versuch, sich mehrfach mit falschem Kennwort an einen existierenden Benutzer in der Datenbank anzumelden, löst ab Oracle 11g eine verzögerte Bearbeitung weiterer Login-Versuche an diesen Benutzer aus. Diese Maßnahme, mit deren Hilfe Brute-Force-Attacken erschwert werden sollen, gehört mit zum Standard in 11g und wird nach 3 Fehlversuchen mit einer maximalen Verzögerungszeit von jeweils 10 Sekunden wirksam.

Die verzögerte Login-Bearbeitung greift auch dann, wenn zudem versucht wird, die Verbindung von einer anderen IP-Adresse oder Host aus aufzunehmen.

FAILED_LOGIN_ATTEMPTS vs. SEC_MAX_FAILED_LOGIN_ATTEMPTS

Die soeben beschriebene Verzögerung bei fehlerhaften Anmeldeversuchen setzt sich bis zur Sperrung des betroffenen Accounts in der Datenbank fort. Die Anzahl der hier möglichen Versuche ist auch in 11g weiterhin durch die Angabe FAILED_LOGIN_ATTEMPTS im Passwortprofil des Benutzers begrenzt (siehe Abbildung 4).

Im Gegensatz dazu bezieht sich der in Oracle 11g eingeführte Initialisierungsparameter SEC_MAX_FAILED_LOGIN_ATTEMPTS nicht auf einen bestehenden Account in der Datenbank, sondern auf jeglichen fehlerhaften Anmeldeversuch mit unbekanntem Benutzer und Passwort. Bleiben 10 dieser wahlfreien Angriffsversuche (= Intruders) ohne Erfolg, wird die Verbindung abgebrochen; eine Funktionalität, die allerdings nur im Kontext einer OCI-Applikation zum Tragen kommt.

Access Control Listen (ACLs) – Kontrolle der Netzwerkzugriffe aus der Datenbank

In der Oracle Datenbank existieren bereits seit längerer Zeit eine Reihe von PL/SQLPackages, mit deren Hilfe Informationen aus der Datenbank heraus an beliebige, im Netzwerk erreichbare Server geschickt werden können. Zu diesen „Netzwerk“-Paketen zählen:

• UTL_TCP
• UTL_SMTP
• UTL_MAIL
• UTL_HTTP
• UTL_INADDR

Diese Pakete sind bis Oracle 10g durch das EXECUTE-Privileg, das standardmäßig an PUBLIC(!) vergeben ist, zur Ausführung freigegeben. Diese uneingeschränkte und allgemeingültige Zugriffsmöglichkeit auf das gesamte Netzwerk erscheint praktisch, stellt aber ein erhebliches Sicherheitsrisiko dar.

Dem begegnet Oracle 11g mit einem neu eingeführten Sicherheitskonzept: Netzwerkzugriffe, die durch PL/SQL-Pakete erfolgen, müssen vom DBA sowohl für die einzelnen Ziele als auch für die einzelnen Benutzer bzw. Rollen separat freigegeben werden.

Diese Freigabe erfolgt über so genannte Access Control Listen (ACLs). Programmtechnisch werden die ACLs mit dem neuen Package DBMS_NETWORK_ACL_ADMIN erzeugt und verwaltet (siehe Abbildung 5).

Aber Achtung: ACLs werden als XMLDokumente unter Verwendung der XML DBKomponente abgelegt. Damit ein Arbeiten mit diesen „Netzwerk“-Paketen also auch weiterhin funktioniert, muss die XML DB in der 11g Datenbank installiert sein.

Fazit

Festzuhalten bleibt, dass es mit der neuen Oracle Initiative „Secure by Default“ wirklich leichter wird, eine sicherere Datenbank outof- the-box zu installieren. Die Maßnahmen sind aus Security-Sicht sinnvoll und holen mit einigen wichtigen Industriestandards in punkto Sicherheit auf.

Es bleiben jedoch Aufwände für den Administrator bestehen. Sie liegen hauptsächlich in der Berücksichtigung der Auswirkungen sowie der Anpassung an die eigenen Bedürfnisse dieser out-of-the-box-Maßnahmen. Nur das Zusammenspiel der von Oracle gelieferten Default-Sicherheitsmaßnahmen mit den manuellen Konfi gurationen des DBA führen zu einer wirklich sicheren Datenbank.

Im nächsten Artikel stellen wir Ihnen u. a. die Änderungen im Bereich des Passwortmanagements vor.

Kathleen Hock (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen