Proxy Authentication – ein Lösungsansatz für einige Sicherheitsthemen

updated on

Eines der größten Security Themen ist die Benutzeridentifizierung, speziell wenn es um den Bereich Datenbank Administration bzw. „gewachsene“ Applikationen geht.

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 Applikationsowner. Abgesehen davon, dass es gefährlich ist, wenn jeder Benutzer als Eigentümer der Applikationsobjekte arbeitet, weil der Benutzer damit potentiell 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 (zB: 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 Datenbank 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):

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:

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:

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:

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:

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:

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:

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.

Sofern im Unified Audit Logons auditiert werden:

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.

Nächste Schritte

Natürlich bleibt immer noch das Problem, dass der jeweilige Applikationsowner immer noch alle Rechte hat. Hier wäre der nächste Schritt, einen „App-Connect“ Benutzer zuerzeugen, 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 Applikationsowner erfolgt, sondern auf den App-Connect Benutzer. Damit wären viele Sicherheitsthemen von gewachsenen Applikationen entschärft.