Oracle DBMS: User und Database Security

(Last Updated On: 7. Juli 2015)

Authentication

Die häufigste Art, sich auf einem Oracle-System zu authentifizieren, ist die sogenannte local authentication. Hierbei werden die Zugangsdaten der Oracle DBMS-User im Oracle Data Dictionary gespeichert, also beispielsweise Passwörter, biometrische Daten o. Ä.

In größeren Unternehmen ist es jedoch gängig, sich an der Oracle datnebank über LDAP anzumelden. Hierbei können sich Benutzer über ihre Microsoft Active Directory- oder OpenLDAP-Accounts anmelden und dann über verschiedene Privilegien, die wir weiter unten kennenlernen werden, die Identität von Administratorkonten wie SYS annehmen.

Ein Datenbankparameter, den Sie wahrscheinlich niemals in Ihrer gesamten Oracle-Karriere aktivieren wollen, ist der Parameter REMOTE_OS_AUTHENT und OS_AUTHENT_PREFIX.

Die Passwörter einiger Nutzer sollten Sie sofort nach der Oracle-Installation ändern

  • SYSTEM (Intialpasswort MANAGER) und SYS (Initialpasswort CHANGE_ON_INSTALL).
  • Benutzer DBSANMP dient zur Überwachugn der Isntanz über das SNMP. Falls Sie kein SNMP einsetzen, können Sie den nutzer auch einfach sperren (siehe weiter unten)
  • Benutzer scott. Ein übungsuser, der zugriff auf eine Übungsdatenbank hat. In dieser übungsdatenbank könnten Angreifer beispielsweise Schrottdateien einfügen und somit den Speicherplatz vollschreiben. Scott ist bei neueren Oracle.Versionen jedoch standardmäßig gesperrt.

Benutzerverwaltung

Benutzer sperren

Benutzer können sie folgendermaßen sperren.

alter user <username> account lock

 

Privilegien

Bei Priviligen unterscheidet man zwischen

  • Systemprivilegien. Sien enthalten REchte auf alle bojetke eines bestimmten Typs udn generelle Rechte im System wie etwa Verbinden und Anmelden
  • objektprivilegien enthalten REchte auf bestimmte Objekte

Privilegien eignen sich zur Vergabe an einen konkreten, bestimmten User. in der Praxis jedoch vergibt amnd ie selben privilegien häufig an mehrere Nutzer, weshalb in der Praxis später Rolleng ebaut werden, die den jeweiligen nutzern dann einfach zugewiesen werden.

Einer der drei großen Pfeiler der IT-Security ist das Accounting. Es bedeutet, dass jederzeit nachvollziehbar sein muss, welche Person welche administrativen Tätigkeiten auf dem System ausgeführt hat.

dies können Sie aber nicht gewährleisten, wenn die Administration von SAP-Systemen mt den standardmäßig erstellten Administrationsusern arbeiten.

  • SYS – SYS ist sozusagen der Superuser, das Administratorkonto des Oracle DBMS. SYS ist dabei nicht nur der Superuser mit Administratorrechten, sondern auch der Besitzer des SYSTEM-TAblespace und anderer systemrelevanter Tablespaces, Tabellen und Views wie etwa dem Data Dictionary. Dadurch kann dieser User auch Änderungen am System selbst vornehmen.
  • SYSTEM – ein etwas weniger machtvoller Account. Der User System besitzt nicht wichtige Objekte wie das Data Dictionary und kann beispieslweise kein backup udn recovery oder datenbankupgrade durchführen.
  • SYSMAN

Für bestimmte Tätigkeiten brauchen Sei die Rechte des SYS Nutzers, weil Sie beispeislweise Datenbankparameter abändern müssen. Diese Rechte hat eben nur der SYS Nutzer, da nur der SYS-Nutzer Egientümer des SYSTEM-Tablespaces ist und daher nur dieser Nutzer die Datenbankparameter abändern kann. Wenn Sie sich jedoch direkt als SYS-Nutzer an der Datenbank anmelden, haben Sie wiederum das problem, dass Sie nicht nachvollziehen können, welche Person mit dem SYS-Nutzer gearbeitet und daher die Änderungen vollzogen hat.

Um dieses Problem zu adressieren, gibt es das sysdba-Privileg. Sie können in einer Oracle-Instanz Single Sign on einrichten, so dass sich beispielsweise Windows Nutzer über Active Directory oder Linux Nutzer über LDAP an der Oracle Instanz anmelden können. Wenn Sie diesen nutzern oracle-intern die Rolle SYSDBA geben, dann ist es möglich, dass sich diese Nutzer anmelden und danach ein Kommando ausführen, welches dazu führt, dass Sie zum Nutzer SYS werden. Das kommando wird in den Logs der Oracle-Instanz aufgezeichnet udn somit kann im Nachhinein nachvollzogen werden, wer sich wann als User SYS angemeldet hat.

Als erstes müssen Sie einen neuen User erstellen

create user <name> identified by <passwort>

Eventuell wollt ihr für bestimmte Tablespaces eine quota erstellen, so dass der user einen tablespace beispielsweis enicht voll schreiben kann

SQL>CREATE USER <name> profile "defaulT" identified by "<passwort>" default tablespace "users" temporary tablespace "TEMP" quota 100 M on "users" account unlock
SQL>grant "connect" to "<username>"

Eine wichtige sicherheitseinstellung ist, dass der Stndardtablespace, auf den sich User einloggen, NICHT der SYSTEM-Tablespace ist.

Zu diesem User können wir außerdem ein Profil erstellen, welches bestimmte Beschränkungen setzt, beispielsweise wie viel CPU-Power pro SEssion der User bekommt, wann sein Passwort ausläuft, wie komplex sein Passwort sein muss und wei oft ein falsches Passwort eingegbeen werden kann, bevor der Account gesperrt wird.

CREATE PROFILE "<Profilname>" LIMIT CPU_PER_SESSION DEFAULT CPU_PER_CALL DEFUALT CONNECT_TIME DEFAULT IDLE_TIME DEFAULT SESSIONS_PER_USER 1 LOGICAL_READS_PER_SESSION DEFAULT LOGICAL_READS_PER_CALL DEFAULT PRIVATE_SGA DEFAULT GOMPOSITE LIMIT DEFUALT PASSWORD_LIFE_TIME 30 PASSWORD_GRACE_TIME 30 PASSWORD_REUSE_MAX UNLIMITED PASSWORD_REUSE_TIME DEFAULT PASSWORD_LOCK_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS 6 PASSWORD_VERIFY_FUNCTION DEFAULT

Dieses Priofil könnenw ri jetzt dem frisch erstellten User zuweisen.

ALTER USER "<username>" PROFILE "<profilname>"

initial könnt ihr auch jedem neuen User bereits beim erstellen ein Profil zuweisen

CREATE USER "<username>" PROFILE "<profilname>" IDENTIFIED BY "<passwort>" PASSWORD EXPIRE ACCOUNT UNLOCK GRANT "<privileg>" TO "<username>"

Wenn ihr eine Passwort-Komplexität erzwingen wollt, müsst ihr ein extra skript namens utlpwdmg.sql ausführen. Es befindet sich unter ORACLE_HOME\RDBMS\ADMIN\. Führt das Skript aus und von nun an funktioniert eine erzwungene password_complexity.

Nun stellt sich noch die Frage, welche privilegien doer rollen der Useraccount bekommen soll. Es gibt zwei spezielle Privieligen

  • SYSDBA. Nach seinem Login führt der user das kommando aus, um zum user SYS zu werden und dann auf der Datenbank alles zu tun,a lso Parameter ändern, updaten, backup und Recovery, Oracle isntanz starten und stoppen, Zugriff zu ALLEN Daten. Es wird geloggt, welcher User sich wann über seinen Useraccount zum user SYS gemacht hat, was den Anforderungen der IT-Security-Grundsäule Accounting gerecht wird.
  • SYSOPER. Nach seinem Login führt der user das Kommando aus, um zum User PUBLIC zu werden. Der user kann nur backupen, Oracle-Isntanz starten udn stoppen. Der User kann nicht updaten und hat keinen Zugriff auf Daten. Es wird geloggt, welcher User sich wann über seinen Useraccount zum user PUBLIC gemacht hat, was den Anforderungen der IT-Security-Grundsäule Accounting gerecht wird.

Wenn wir jetzt beispielsweise wollen, dass unser user das Privileg SYSDBA bekommt, geht das über

grant SYSDBA to "<username>";

Statt solcher „Userwechsel“-Privilegien können Sie auch SQL-Privilegien an einen User vergeben.

grant select on <objekt> to <username>;
grant create table on <objekt< to <username>;

Sie werden jedoch sehr schenll merken, dass das äußerst mühsam ist. Stattdessen sollten Sei solche Privilegien über Rollen regeln, die Sie dann dem einzelnen User zuweisen.

Es ist jedoch sehr schmerzhaft, Rollen über SQL zu erstellen. DAs sollten Sie wirklich über den Oralce Enterprise Manager machen, da Sie dann nicht sämtliche Privilegien auswendig wissenj müssen, die Sie eventuell in die Rolle packen wollen.

Hier für interessierte jedoch trotzdem der Weg zum Bau einer rolle über SQL

create role <rollenname>

Nun, da Sie die Rolle definiert haben, müssen Sei noch festlegen, welche Rechte in dieser rolle enthalten sein sollen. DAs geschieht etwa in folgendem Format, wenn sie festlegen wollen, welche Spalten eienr Tabelle die Rolle abfragen können soll:

grant select (<spalte1>, <spalte2>, <spalte3>) on <tabellennname> to <rollenname>

nachdem Sie die Berechtigungen für diese Rolle definiert haben, weisen Sie die Rolle noch verschiedenen Nutzern zu

grant <rollenname> to <username1>
grant <rollenname> to <username2>

Sioe können eine Rolle jedoch auch in eine andere Rolle verschachteln, so dass die eine Rolle in der anderen Rolle enthalten ist.

grant <rollenname1> to <rollenname2>
grant <rollenname2> to <username>

Sie könenn eien Rolle natürlich auch wieder von einem user entfernen

revoke <rollenname> from <username>

Wichtige privilegien sind beispielsweise

  • create session. Das Recht, sich an de rdatenbank anzumelden
  • create any table. Das recht, eine Tabelle anzulegen
  • drop any table … with admin option. Recht, tabellen oder Datensätze zu löschen und das Recht weiterzugeben
  • update (<spaltenname>) on <tabellenname>. Das Recht, die Werte von <spaltenname> in Datensäzen der Tabelle <tabellenname> zu ändern.

Oracle liefert bereits einige vordefinierte Rollen mit

  • CONNECT. Enthält das Recht, sich am System anzumelden
  • RESOOURCe. Enthlt REchte zum Anlegen von objekten und wird im Enterprise Manager genauer aufgeschlsüselt
  • DBA. ist das Recht, adminsitrativen Zugriff auf Datenbankobjekte auszuüben.

die Rollen des angemeldetne Benutzers können Sie sich folgendermaßen anzeigen lassen

select username, granted_role, admin_option from user_role_privs;

und die Default_Rollen folgendermaßen

select granted_role from user_role_privs where default_role= 'YES';

die aktiven Rollen füpr die aktuelle Sessions des Nutzers erhalten sie über

select * form session_roles;

Objektprivilegien des Nzutzers bekommen Sie über

select table_name, privilege, grantable from user_tab_privs

Jetzt noch ein kleiner Sonderfall. Nehmen wir einmal an, sie müssen an der Oracle-Instanz eine Wartung vornehmen, die es erfordert, dass die datenbank selbst nicht gemountet wird. Man würde die Instanz also im nomount-state starten lassen. Da das Passwrot für ihren User aber in der Datenbank gespeichert wird, können Sie in diesem Nomount-Stae standardmäßig nicht mit ihrem user an der Oracle-Instanz arbeiten, da Sie sich ohne gemountete Datenbank nicht anmelden können. Die Lösung kommt mit einem sogenannten Pw-File. Diese Datei speichert das Passwort in einer gehashten Binärdatei, das Passwort ist also nicht im Klartext lesbar. Das File befindet isch stnadardmäßig unter %ORACLE_HOME%\database oder %ORACLE_HOME%\dbs und heißt PWD<SID>.ora. Damit diese Atuhentifzierung funktioniert, muss der Parameter REMOTE_LOGIN_PASSWORDFILE gesetzt sein. Zur Erstellung der apsswortdatei wird dann das Tool ORAPWD genutzt. Der Oracle Database Configuration Assistnat führt das ORAPWD-Tool autoamtisch aus, wenn über den DBCA eine Datenbank erstellt wird.

Grundsätzlich ist die Möglichkeit des Logins über ein Passwortfile jedcoh ein mögliches sicherheitsleck, da es anderen nutzern erlaubt, sich über das netzwerk mit SYSDBA- oder SYSOPER-Rechten anzumelden.

alter database default_tablespace users;

Ein Privileg, auf welches Sie besonders Acht geben müssen, sit das PUBLIC-Privileg. Das Pjublic-privileg wird automatisch jedem user zugeteilt, der das Connect-Privileg hat, sich also auf dem System anmelden kann. Es gibt einige Releases der Oralce Database, bei welcher das PUBLIC-Privileg wiederum das EXECUTE-Recht beinhaltet, also das Recht, PL/SQL-Code auszuführen.

wir können schauen, auf wie welche PL/SQL-Pakete das Public-Privileg derzeit Zugriff erteilt, über

select table_name from dba_tab_privs where grantee = 'PUBLIC' and privilege = 'EXECUTE' and table_name like 'UTL%'

Es gibt in oracle ein paaar sehr sensitive PL/SQL Pakete, auf die Sie unbedingt Acht geben sollten

  • UTL_FILE – Zugriff auf Betriebssystem und Dateisystem
  • UTL_TCP – Öffne TCP Ports
  • UTL_SMTP – E-Mail-Versand
  • UTL_HTTP: Web browsen

sie können auf solche delikaten Pakete den zugriff für das Public-privileg widerrufen, indem Sie folgende Befehle ausführen

revoke execute on utl_file from public
revoke execute on utl_tcp from public
revoke execute on utl_smtp from public
revoke execute on utl_http from public

 Auditing

Um Auditing zu aktivieren müssen wir den Datenbankaprameter AUDIT_TRAIL setzen, also das Verzeichnis, in welcehs Audit-Informationen gespecihert werden sollen. Dieser Parameter kann nur bearbeitet werden, wenn die Instanz heruntergefahren ist.

Nachdem diese raprmeater gesetzt ist, können wri festlegen, was wir auditen wollen, etwa

audit select any table by access
audit select any table by session

Der Unterschied zwiscehn den beiden Optionen by access und by session ist, dass bei der by-access-Option jeder einzelne Zugriff auf Tabellen geloggt wird

Wenn der Parameter audit_trail auf DB gestzt ist, können Sie das Audit eines Benutzeraccounts einsehen über

select sql_text, priv_used, action_name from dba_audit_trail where username='<username>'

Auch wenn der Parameter audit_trail auf DB gesetzt ist, findet ihr unter Windows im Ereignis Log Einträge über Auditing-Events in Oracle.

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren...

Kommentar verfassen

This site uses Akismet to reduce spam. Learn how your comment data is processed.