|
18c: Schema ohne Passwort
Warum muss eigentlich jedes Schema in einer Oracle Datenbank eine Authentifizierungsmethode haben? Es gibt doch auch Anwendungsfälle, bei denen es nur darauf ankommt Datenbank-Objekte abzulegen. Ein schlichter Objekt-Container würde dabei ausreichen, ohne dass die Möglichkeit besteht, sich direkt dagegen verbinden zu können.
Bisher musste bei der Erstellung eines Schemas zwingend eine Authentifizierungsmethode angegeben werden. Folgende Methoden stehen zur Verfügung:
- Authentifizierung durch das Betriebssystem (OS-Authentifizierung, Kerberos, PKI)
- CREATE USER benutzer IDENTIFIED EXTERNALLY;
- Authentifizierung durch die Datenbank (Passwort)
- CREATE USER benutzer IDENTIFIED BY ‘Geheim‘;
- Authentifizierung über ein Identitity Management System (Enterprise User Security)
- CREATE USER benutzer IDENTIFIED GLOBALLY;
Doch was ist, wenn ich keine Authentifizierung für dieses Schema haben möchte oder darf. Hierfür gab es bislang leider nur Workarounds. Einer dieser Workarounds ist die Verwendung eines sehr langen und kryptischen Passworts -Jm44!!j2h(7hsdtxl*psub+JTDl-, welches dann auch nach der Vergabe direkt wieder vergessen werden sollte. Eine andere Möglichkeit bestand darin, über die „CREATE USER HR IDENTIFIED BY VALUES“-Klausel, einen ungültigen HASH-Wert anzugeben. Diese Variante geht allerdings ab der Datenbank Version 12c nicht mehr, da hier der HASH-Wert überprüft wird. Wird es dennoch versucht, erhält man folgende Fehlermeldung – ORA-02153: invalid VALUES password string –. Auch das Sperren des Schemas ist keine zufriedenstellende Lösung, da ein gesperrtes Schema kein Proxy-Login mehr zulässt.
Zum Beispiel sollte auf ein Applikationsschema nicht direkt zugegriffen werden dürfen - weder durch einen Applikationsserver noch durch einen Entwickler oder Datenbank-Administrator. Für den Zugriff der Applikation auf die Applikationsobjekte ist es empfohlen, einen separaten technischen Applikationsbenutzer in der Datenbank anzulegen, der mittels Rollen und gegebenenfalls Synonymen, Zugriff auf das Applikationsschema erhält. Nur so ist eine Steuerung der Zugriffsrechte möglich. In diesem Fall ist es unerheblich, ob das Applikationsschema gesperrt, mit einem unbekannten Passwort geschützt oder gar kein Passwort besitzt. Bei der letzteren Variante, der ohne Passwort, ist wie oben erwähnt ein Proxy Login nicht möglich.
Für Entwickler und Datenbank-Administratoren bietet sich hingegen die Verwendung eines Proxy-Benutzers an. Der wesentliche Vorteil eines Proxy-Benutzers zeigt sich beim Versuch, Datenbankbenutzer zu personalisieren, obwohl sie letztendlich Shared-Schemas wie SYSTEM oder das Applikations-Schema verwenden. Neben dem vereinfachten Rollen-Management – die Rollen werden im Prinzip vererbt – , wird der reale Datenbankbenutzer im Auditing-Trail eingetragen. Und genau darauf zielt das neue 18c Datenbank Feature – Schema Only Accounts – ab.
Mit – Schema only Accounts – wird die Möglichkeit zur Verfügung gestellt, keine Authentifizierungsmethode angeben zu müssen. Mit der Klausel „NO AUTHENTICATION“ beim CREATE USER und ALTER USER Statement wird ein Schema Only Account erstellt.
- CREATE|ALTER USER benutzer NO AUTHENTICATION;
Das funktioniert fast mit jedem Datenbankbenutzer.
Ausnahme: Die Klausel -NO AUTHENTICATION- ist bei Datenbankbenutzern mit Administrations-Privilegien wie SYSDBA, SYSOPER, SYSBACKUP, SYSKM, SYSASM, SYSRAC, und SYSDG sowie natürlich bei der Verwendung von Datenbank-Links nicht zulässig.
Das folgende Beispiel zeigt das Feature für die Datenbank Administration mit dem User SYSTEM.
Aus Sicherheits- und Compliance- Gründen sollte der SYSTEM Benutzer nicht zur Administration verwendet werden. Der Hauptgrund dafür ist, dass entsprechende Aktivitäten keiner realen Person zugeordnet werden können und demzufolge nicht nachvollziehbar sind. Hier bietet sich das neue Feature sehr gut an.
Zunächst wird der SYSTEM Benutzer zum Schema Only Account geändert. Das heißt, der Benutzer System hat kein Passwort mehr und folglich kann sich niemand direkt mit ihm anmelden.
[nsibbing@nsibbing-lnx:[~]$ sqlplus sys@18c as sysdba SQL*Plus: Release 12.2.0.1.0 Production on Tue May 8 14:45:33 2018 Copyright (c) 1982, 2016, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production SQL> alter user system no authentication; User altered. SQL> connect system@18c Enter password: ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE.
Nun wird ein personalisierter Benutzer mit eigenem Passwort angelegt. Der neue Benutzer erhält maximal das „Create Session“ Privileg. Zudem wird es dem Benutzer erlaubt, den SYSTEM Benutzer als Proxy-Benutzer zu verwenden.
SQL> create user nsibbing identified by welcome1; User created. SQL> grant create session to nsibbing; Grant succeeded. SQL> alter user system grant connect through nsibbing; User altered.
Mehr ist im Prinzip nicht zu tun. Die Anmeldung als personalisierter DBA mit den Rechten des SYSTEM Benutzers erfolgt dann entsprechend eines Proxy-Logins.
SQL> connect nsibbing[system]@18c_cdb
Enter password:
Connected.
SQL> show user
USER is "SYSTEM"
SQL> select SYS_CONTEXT('USERENV','PROXY_USER') PROXY_USER, SYS_CONTEXT('USERENV','SESSION_USER') SESSION_USER from dual;
PROXY_USER SESSION_USER
-------------------- --------------------
NSIBBING SYSTEM
SQL>
Fazit
Schema only Accounts bieten eine geniale Möglichkeit, Datenbank-Benutzer auf einfache Weise zu personalisieren.
- Es werden hiermit gleich mehrere Themen adressiert:
- Benutzer mit -NO AUTHENTICATION- sind nicht mehr direkt nutzbar
- Kein Passwort mehr notwendig
- Kein Passwort-Profile mehr notwendig
- Jeder so personalisierte DBA oder Entwickler verwaltet sein eigenes Passwort
- Im Audit-Trail ist der reale Benutzer enthalten, trotz Verwendung des Shared Accounts
Lizenzhinweis
Dieses Feature steht in allen Editionen ab Oracle Datenbank 18c ohne zusätzliche Lizenzen zur Verfügung.
Weitere Informationen
Zurück zur Community-Seite