Aus Sicherheitsgründen sollte in Datenbanken die Anmeldung nur mit persönlichen Accounts erfolgen. Nur so kann sichergestellt werden, dass ein Benutzer eindeutig identifizierbar/authentifizierter ist. Gleichzeitig können auf diesem Weg Probleme mit diversen Security-Scanner-Tools beseitigt werden, die – egal ob zu Recht oder Unrecht – bei vielen Privilegien von Benutzer-Accounts Alarm schlagen.
Bei vielen Applikationen gibt es oft nur einen einzigen Datenbankbenutzer – den Applikations-Owner. Abgesehen davon, dass es gefährlich ist, wenn jeder Benutzer als Eigentümer der Applikationsobjekte arbeitet, weil der Benutzer damit potenziell zu viele Rechte hat, bedeutet dies aber auch, dass das Passwort dieses Benutzers zu vielen Personen bekannt sein muss. Eine Änderung des Passworts ist daher oft nicht ohne eine größere Betriebsunterbrechung der Applikation machbar.
Eine Lösungsmöglichkeit bietet Oracle mit Hilfe der "Proxy User Authentication". Damit kann der Benutzer-Login personalisiert werden, ohne gleichzeitig Probleme mit Zugriffsrechten oder Privilegien auszulösen. Dadurch, dass jeder Benutzer sein eigenes Login hat, ist zumindest auch das leidige Thema mit dem individuellen Ändern des Passworts entschärft.
Zusätzlich bietet dies die Möglichkeit, dass ein Benutzer verschiedene Aufgaben (z. B: Datenbank-Administrator und Applikationsverantwortlicher) wahrnehmen kann, ohne dass dem Benutzer-Account viele Privilegien zugeordnet werden müssen (was die Kopfschmerzen mit Security Tools deutlich reduziert). Dazu wird für jeden Benutzer in der Datenbank einen Named Account sowie eine Zuordnung benötigt, auf welche Datenban-Schematas er zugreifen darf.
Anwendungsbeispiel
Der Benutzer CHRIS soll in der Datenbank PDB1 sowohl Datenbank-Administrator als auch Applikationsverantwortlicher sein. Die Applikation verfügt lediglich über ein Schema "AppSchema1". Der Entwickler FRED darf nur im Applikationsschema arbeiten. Die Passwörter für die Accounts von SYSTEM (Datenbank-Administrationsaccount) als auch AppSchema1 soll den beiden Benutzern nicht bekannt sein.
Umsetzungsbeispiel
Vorbereitung (Benutzer AppSchema1 mit Berechtigungen anlegen):
sql
connect system/oracle@localhost/PDB1
CREATE USER AppSchema1 IDENTIFIED BY AppSchema1;
GRANT create session, create table TO AppSchema1;
ALTER USER AppSchema1 DEFAULT TABLESPACE users;
ALTER USER AppSchema1 QUOTA 10M ON users;
CREATE TABLE AppSchema1.Tab1 (x number);
INSERT INTO AppSchema1.Tab1 VALUES (4711);
COMMIT;
Benutzer Chris anlegen und Zugriff auf SYSTEM und AppSchema1 erlauben:
sql
CREATE USER chris IDENTIFIED BY chris;
GRANT create session TO chris;
ALTER USER system GRANT connect THROUGH chris;
ALTER USER AppSchema1 GRANT connect THROUGH chris;
Benutzer Chris anlegen und Zugriff auf AppSchema1 erlauben:
sql
CREATE USER fred IDENTIFIED BY fred;
GRANT create session TO fred;
ALTER USER AppSchema1 GRANT connect THROUGH fred;
Dem Benutzer Chris erlauben, dass dieser als Proxy-Benutzer auf die Schemas System und AppSchema1 zugreifen darf:
Anmeldungsbeispiel – Chris als AppSchema1:
sql
connect chris[AppSchema1]/chris@localhost/PDB1
show user;
USER is "APPSCHEMA1"
SELECT * FROM tab1;
X
----------
4711
SELECT * FROM proxy_users;
*
ERROR at line 1:
ORA-00942: table or view does not exist
Anmeldungsbeispiel – Chris als SYSTEM:
sql
connect chris[system]/chris@localhost/PDB1
show user;
USER is "SYSTEM"
SELECT * FROM proxy_users;
PROXY CLIENT AUT FLAGS
---------- ------------------ -----------------------------------------------
CHRIS SYSTEM NO PROXY MAY ACTIVATE ALL CLIENT ROLES
CHRIS APPSCHEMA1 NO PROXY MAY ACTIVATE ALL CLIENT ROLES
FRED APPSCHEMA1 NO PROXY MAY ACTIVATE ALL CLIENT ROLES
Das kann natürlich überwacht werden:
sql
SELECT distinct s.sid, s.serial#, s.username, s.osuser, sci.authentication_type
FROM v$session s,
v$session_connect_info sci
WHERE s.sid = sci.sid
AND s.serial# = sci.serial#
AND sci.authentication_type = 'PROXY';
SID SERIAL# USERNAME OSUSER AUTHENTICATION_TYPE
---------- ---------- ------------ ---------- --------------------------
754 47623 SYSTEM oracle PROXY
Möglicherweise muss in den Applikationen beim Zugriff auf den "SYS_CONTEXT" eine Anpassung erfolgen:
sql
SELECT sys_context('userenv','session_user') as session_user,
sys_context('userenv','session_schema') as session_schema,
sys_context('userenv','current_schema') as current_schema,
sys_context('userenv','proxy_user') as proxy_user
FROM dual;
SESSION_USER SESSION_SCHEMA CURRENT_SCHEMA PROXY_USER
------------------- ----------------------- ------------------------ ------------------
SYSTEM SYSTEM SYSTEM CHRIS
Je nachdem, welche Information benötigt wird.
So fern im Unified Audit Logons auditiert werden:
sql
SELECT dbusername, dbproxy_username
FROM unified_audit_trail
WHERE dbproxy_username is not null;
Vorteile:
- Im Unified Audit sieht man sowohl den Anmeldeuser Chris als auch das genutzte Schema.
- Die Passwörter der Applikationsuser müssen nicht mehr bekannt sein, da sich jeder Benutzer mit "seinem" User anmeldet.
Nachteile:
- Die personalisierten Benutzer müssen ausgerollt werden.
- Beim Zugriff auf "SYS_CONTEXT" müssen in der Applikation möglicherweise Anpassungen vorgenommen werden.
Natürlich bleibt immer noch das Problem, dass der jeweilige Applikations-Owner immer noch alle Rechte hat. Hier wäre der nächste Schritt, einen "App-Connect"-Benutzer zu erzeugen, der lediglich die benötigten Rechte auf die Objekte des Applikationsschemas hat. Die Proxy Authentication wird so erweitert, dass der Connect (außer für Entwickler) nicht mehr auf den Applikations-Owner erfolgt, sondern auf den App-Connect-Benutzer. Damit wären viele Sicherheitsthemen von gewachsenen Applikationen entschärft.
Christian Pfundtner
