|
Least Privileges mit Oracle Privilege Analysis
Der Anforderung "The principle of least privilege" zu entsprechen, ist leichter gesagt als getan. Ziel ist es, nur die Rollen und Privilegien zu vergeben, welche für die fehlerfreie Ausführung der entsprechenden Funktionalität notwendig sind. Nicht mehr und nicht weniger. Die Realität sieht meist anders aus. Viele Datenbankbenutzer verfügen über wesentlich mehr Rollen und Privilegien als notwendig sind. Oft bedingt durch fortwährende Applikationsänderungen, bei denen meist nur das Datenmodell und die Applikationslogik verändert werden, aber nur selten das dahinterliegende Berechtigungskonzept. Es existieren auch Fälle, bei denen der Applikationsentwickler lieber den Weg des geringsten Widerstands geht und mit dem maximal höchsten Recht, welches für die Datenbank existiert, die Anwendung entwickelt. Die Vergabe der DBA-Rolle ist hier keine Seltenheit. Nach Beendigung der Entwicklung wird das Berechtigungskonzept meist nicht der Anwendung angepasst. Somit wird die Applikation mit zu vielen und zu mächtigen Rollen und Privilegien in Produktion genommen. Nachträglich die vergebenen Rollen und Privilegien zu reduzieren, traut sich niemand aus verständlichen Gründen. Die hieraus resultierenden Probleme entstehen erst, wenn eine Sicherheitsüberprüfung der Applikation beziehungsweise des Verfahrens ansteht. Denn jetzt wird nachgefragt.
Sind diese Rollen und Privilegien wirklich notwendig? Welche dieser Rollen und Privilegien können dem Benutzer entzogen werden?
In den meisten Fällen ist es schwer, wenn nicht sogar unmöglich, diese Fragen seriös zu beantworten. Bei einer Reduzierung der Berechtigungen, ohne eine genaue Erkenntnis darüber zu haben, welche Rechte und Privilegien für den fehlerfreien Betrieb der Applikation notwendig sind, führt zu einem erheblichen Risiko die Verfügbarkeit der Applikation zu verlieren. Doch die Anforderungen das Prinzip der geringsten Privilegien ( "the principle of least privilege") umzusetzen bleibt.
Oracle Privilege Analysis
Die Lösung dieses Problems liefert das Feature -Privilege Analysis- der Oracle Datenbank Enterprise Edition ab der Version 12.1 und die Oracle 18c XE. Die Datenbank selber weiß doch eigentlich am besten, welcher Datenbankbenutzer auf welche Objekte wie zugreift. Genau das macht Oracle Privilege Analysis. Privilege Analysis ermöglicht das Protokollieren der vom Benutzer wirklich verwendeten Privilegien beim Zugriff auf Datenbank-Objekte, unabhängig davon, welche Rollen und Privilegien ihm zugeordnet sind. Die Protokollierung erfolgt mittels eines sogenannten Capture-Prozesses, der über einen bestimmten Zeitabschnitt alle verwendeten Privilegien eines Datenbankbenutzers erfasst. Dieser Prozess wird durch das PL/ SQL-Package - DBMS_PRIVILEGE_CAPTURE – initialisiert. Die Aufzeichnung der verwendeten Privilegien durch den Privilege-Capture Prozess lässt sich auf Basis von Session-Kontextinformationen einschränken. So ist es möglich, nur bestimmte Applikationen oder Benutzer zu überprüfen. Nach Beendigung des Capture Prozesses lassen sich die Ergebnisse mittels der Tabellen DBA_USED_PRIVS, DBA_USED_OBJPRIVS, DBA_UNUSED_PRIVS und DBA_UNUSED_OBJPRIVS auswerten. Die hieraus resultierenden Ergebnisse ermöglichen das Erstellen neuer Rollen mit ausschließlich benötigten Privilegien, also Least Privileges.
Wie schnell dies umgesetzt werden kann, demonstriere ich hier anhand des folgenden Beispiels.
Beispiel
In diesem Beispiel verwende ich eine Applikation, bei dem der Entwickler den Weg des geringsten Widerstandes gegangen ist. Die Applikation verwendet einen technischen Datenbankbenutzer WEBLOGIC_SESSION, der sich an der Oracle Datenbank anmeldet. WEBLOGIC_SESSION besitzt die DBA Rolle, kann also nichts schief gehen.
SQL> SELECT granted_role FROM dba_role_privs WHERE grantee = 'WEBLOGIC_SESSION'; GRANTED_ROLE -------------------------------------------------------------------------------- CONNECT DBA SQL>
Die Applikationsobjekte selber befinden sich in einem - Schema Only Account - (siehe Tipp: Schema Only Account) einer 18c Datenbank.
SQL> SELECT username, authentication_type FROM dba_users WHERE username = 'DEMOAPPS'; USERNAME AUTHENTICATION_TYPE --------------- -------------------- DEMOAPPS NONE SQL>
Aufgrund der Tatsache, dass der technische Benutzer WEBLOGIC_SESSION mit der DBA Rolle arbeitet, gibt es natürlich keine Zugriffsschutzverletzungen und die Applikation arbeitet einwandfrei.
Damit wir nun das Prinzip der geringsten Privilegien-Vergabe für diese Applikation umsetzen können, ist es notwendig genau zu wissen, welche Objekte der Datenbankbenutzer WEBLOGIC_SESSION im Applikationsschema DEMOAPPS wie nutzt. Oder anders gesagt, welche Privilegien er aus der DBA Rolle wirklich nur nutzt.
Dazu setzen wir nun den Privilegien-Capture Prozess in der Datenbank auf. Der Datenbankbenutzer, der diesen Prozess aufsetzt, muss die Rolle CAPTURE_ADMIN besitzen. Ich verwende hierzu den SYSTEM Benutzer.
Der Capture Prozess wir mittels des PL/SQL Packages DBMS_PRIVILEGE_CAPTURE und der Prozedur CREATE_CAPTURE erstellt.
Als Eingabeparameter sind notwendig:
| Parameter | Beschreibung |
|---|---|
| NAME | Name des Capture-Prozesses |
| TYPE | Beschreibt, auf welcher Ebene das Capturing durchgeführt werden soll |
Folgende Werte sind für den Eingabeparameter TYP möglich:
| Werte | Beschreibung |
|---|---|
| DBMS_PRIVILEGE_CAPTURE.G_DATABASE | Alle verwendeten Privilegien der gesamten Datenbank werden erfasst. Mit Ausnahme von SYS Aktivitäten |
| DBMS_PRIVILEGE_CAPTURE.G_ROLE | Erfasst Privilegien von Benutzern, bei denen entsprechende Rollen aktiv sind. Zusätzliche Angaben der Rollen als Eingabeparameter notwendig. Zum Beispiel: ROLES => role_name_list('role1', 'role2') |
| DBMS_PRIVILEGE_CAPTURE.G_CONTEXT | Erfasst alle Privilegien von Sessions mit entsprechenden Kontextinformationen, wie zum Beispiel aus dem USERENV-Kontext. Dazu ist ein zusätzlicher Eingabeparameter notwendig. Zum Beispiel: CONDITION => 'SYS_CONTEXT(''USERENV'', ''IP_ADDRESS'')=''192.0.2.1'''; |
| DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT | Setzt sich aus den beiden letzten Types zusammen: Rollen plus Kontextinformationen |
Unter dem Link DBMS_PRIVILEGE_CAPTURE findet sich eine genaue Beschreibung des Packages.
In diesem Beispiel verwende ich den Type: DBMS_PRIVILEGE_CAPTURE.G_CONTEXT.
SQL> BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
name => 'COLLECT_USED_DEMOAPPS_PRIVS' ,
description => 'Ermittlung verwendeter Privilegien' ,
type => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT ,
condition => 'SYS_CONTEXT (''USERENV'',''CURRENT_SCHEMA'') = ''DEMOAPPS''' );
END;
/
PL/SQL procedure successfully completed.
Nachdem der Capture-Prozess erstellt wurde, muss er nur noch gestartet werden. Dies wird mittels der Prozedur ENABLE_CAPTURE aus dem DBMS_PRIVILEGE_CAPTURE durchgeführt. Dieser Prozess kann sofort gestartet werden, oder mittels des Datenbank Schedulers zeitversetzt.
SQL> BEGIN DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE('COLLECT_USED_DEMOAPPS_PRIVS'); END;
/
PL/SQL procedure successfully completed.
Nun werden alle Privilegien, die der Capture-Bedingung entsprechen, erfasst. Dies geschieht solange bis der Capture-Prozess wieder gestoppt wird. Dies wird mittels DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE durchgeführt. Das Stoppen des Capturings sollte erst dann erfolgen, wenn davon ausgegangen werden kann, dass alle Aktivitäten der Applikation einmal durchgeführt wurden.
SQL> BEGIN DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE('COLLECT_USED_DEMOAPPS_PRIVS'); END;
/
PL/SQL procedure successfully completed.
SQL>
Jetzt sind alle Privilegien erfasst und es kann der Bericht generiert werden. Dies wird wiederum mittels des DBMS_PRIVILEGE_CAPTURE Packages durchgeführt. In diesem Schritt werden die erfassten Informationen des Capture-Prozesses den DBA_USED_* und DBA_UNUSED_* Views zur Verfügung gestellt. Eine Beschreibung aller DBA_USED_* und DBA_UNUSED_* Views sind in der Oracle Dokumentation (Performing Privilege Analysis) zu finden.
SQL> BEGIN DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT('COLLECT_USED_DEMOAPPS_PRIVS'); END;
/
PL/SQL procedure successfully completed.
Die Abfrage der Views DBA_USED_PRIVS und DBA_UNUSED_PRIVS zeigt auf, welche Privilegien der Datenbankbenutzer WEBLOGIC_SESSION genutzt hat und welche nicht.
SQL> select count(*) from DBA_UNUSED_PRIVS WHERE USERNAME='WEBLOGIC_SESSION';
COUNT(*)
----------
33228
SQL> select count(*) from DBA_USED_PRIVS WHERE USERNAME='WEBLOGIC_SESSION';
COUNT(*)
----------
52
SQL>
Hier wird ziemlich schnell deutlich, dass der WEBLOGIC_SESSION Benutzer mächtig überprivilegiert ist. Klar, er verwendet ja auch die DBA Rolle.
Schauen wir uns mal an, welche dieser Privilegien der Benutzer WEBLOGIC_SESSION verwendet, um auf Objekte des Applikationsschemas DEMOAPPS zuzugreifen.
SQL> set linesize window col USERNAME format a18 col SYS_PRIV format a25 col OBJECT_OWNER format a10 col OBJECT_NAME format a30 SQL> SELECT DISTINCT SYS_PRIV,OBJECT_OWNER,OBJECT_NAME,USERNAME FROM DBA_USED_PRIVS WHERE OBJECT_OWNER='DEMOAPPS' AND CAPTURE='COLLECT_USED_DEMOAPPS_PRIVS'; SYS_PRIV OBJECT_OWN OBJECT_NAME USERNAME ------------------------- ---------- ------------------------------ ------------------ SELECT ANY TABLE DEMOAPPS DEMO_HR_ROLES WEBLOGIC_SESSION EXECUTE ANY PROCEDURE DEMOAPPS LOGGING_TAPI WEBLOGIC_SESSION UPDATE ANY TABLE DEMOAPPS DEMO_HR_EMPLOYEES WEBLOGIC_SESSION INSERT ANY TABLE DEMOAPPS DEMO_HR_EMPLOYEES WEBLOGIC_SESSION SELECT ANY SEQUENCE DEMOAPPS DEMO_HR_EMPLOYEES_SEQ WEBLOGIC_SESSION SELECT ANY TABLE DEMOAPPS DEMO_HR_USERS WEBLOGIC_SESSION SELECT ANY TABLE DEMOAPPS DEMO_HR_EMPLOYEES WEBLOGIC_SESSION 7 rows selected. SQL>
Im Ergebnis sehen wir die Zugriffe des WEBLOGIC_SESSION Benutzers auf Objekte im Applikationsschema DEMOAPPS und die dafür verwendeten Privilegien. Wie hier zu sehen ist, werden Systemprivilegien genutzt, sogenannte ANY Privilegien, da der Benutzer WEBLOGIC_SESSION die Privilegien aus der DBA Rolle verwendet hat. Damit wir jetzt eine neue Applikationsrolle erstellen können, die dem Least Privileges Ansatz entspricht, setzen wir einfach durch eine kleine Transformation via SQL die ANY-Privilegien in Objekt Privilegien um.
Zuerst erstelle ich eine neue Rolle - zum Beispiel HR_MINIMAL - und führe dann ein SQL Statement aus, welches mir die SQL-Befehle zum Granten der Objekt-Privilegien durch Abfrage der DBA_USED_PRIVS View erstellt. Das Ergebnis kann entweder in eine Datei geschrieben oder direkt via Copy and Paste im SQL*Plus ausgeführt werden.
SQL> CREATE ROLE HR_MINIMAL;
Role created.
SQL>
SQL> SELECT DISTINCT 'grant '||
CASE SYS_PRIV
WHEN 'SELECT ANY TABLE' THEN 'SELECT'
WHEN 'EXECUTE ANY PROCEDURE'THEN 'EXECUTE'
WHEN 'INSERT ANY TABLE' THEN 'INSERT'
WHEN 'UPDATE ANY TABLE' THEN 'UPDATE'
WHEN 'DELETE ANY TABLE' THEN 'DELETE'
WHEN 'SELECT ANY SEQUENCE' THEN 'SELECT'
END
||' on '||OBJECT_OWNER||'.'|| OBJECT_NAME||' to HR_MINIMAL;' PRIVS_TO_GRANT
FROM DBA_USED_PRIVS WHERE OBJECT_OWNER='DEMOAPPS' AND CAPTURE='COLLECT_USED_DEMOAPPS_PRIVS';
PRIVS_TO_GRANT
---------------------------------------------------------------------------------------------------------------------------
grant UPDATE on DEMOAPPS.DEMO_HR_EMPLOYEES to HR_MINIMAL;
grant SELECT on DEMOAPPS.DEMO_HR_EMPLOYEES_SEQ to HR_MINIMAL;
grant INSERT on DEMOAPPS.DEMO_HR_EMPLOYEES to HR_MINIMAL;
grant EXECUTE on DEMOAPPS.LOGGING_TAPI to HR_MINIMAL;
grant SELECT on DEMOAPPS.DEMO_HR_EMPLOYEES to HR_MINIMAL;
grant SELECT on DEMOAPPS.DEMO_HR_USERS to HR_MINIMAL;
grant SELECT on DEMOAPPS.DEMO_HR_ROLES to HR_MINIMAL;
7 rows selected.
Jetzt nur noch Copy and Paste der Ergebnisse im SQL*Plus.
SQL> grant UPDATE on DEMOAPPS.DEMO_HR_EMPLOYEES to HR_MINIMAL; grant SELECT on DEMOAPPS.DEMO_HR_EMPLOYEES_SEQ to HR_MINIMAL; grant INSERT on DEMOAPPS.DEMO_HR_EMPLOYEES to HR_MINIMAL; grant EXECUTE on DEMOAPPS.LOGGING_TAPI to HR_MINIMAL; grant SELECT on DEMOAPPS.DEMO_HR_EMPLOYEES to HR_MINIMAL; grant SELECT on DEMOAPPS.DEMO_HR_USERS to HR_MINIMAL; grant SELECT on DEMOAPPS.DEMO_HR_ROLES to HR_MINIMAL; Grant succeeded. SQL> Grant succeeded. SQL> Grant succeeded. SQL> Grant succeeded. SQL> Grant succeeded. SQL> Grant succeeded. SQL> Grant succeeded. SQL>
Zum Schluss muss noch dem Benutzer WEBLOGIC_SESSION die neue Rolle HR_MINIMAL zugewiesen und die DBA Rolle entzogen werden. Danach steht noch der Test der Applikation an und schon bin ich fertig.
SQL> revoke DBA from WEBLOGIC_SESSION; Revoke succeeded. SQL> grant HR_MINIMAL to WEBLOGIC_SESSION; Grant succeeded. SQL>
Da sich Applikationen stetig weiterentwickeln und verändern, sollte die Überprüfung mittels Privilege Analysis in regelmäßigen Abständen wiederholt werden - gegebenenfalls nach einem Applikations-Upgrade.
Privilege Analysis mit dem Oracle Enterprise Manager Cloud Control
Neben der Umsetzung mit dem PL/SQL Package, kann Privilege Analysis natürlich auch grafisch mit dem Oracle Enterprise Manager Cloud Control durchgeführt werden.
Fazit
Oracle Privilege Analysis war anfangs ein Feature von Oracle Database Vault. Aus diesem Grund wurde Privilege Analysis eher selten eingesetzt. Was wirklich schade war, denn es ist ein hervorragendes Feature, welches bei der Umsetzung von Datenschutzrichtlinien enorm hilfreich ist. Oracle gibt nun mit einer Lizenzänderung dieses Feature für alle Oracle Datenbanken in der Enterprise Editionen ab Version 12.1 -On Premises und Cloud- und in der Oracle 18c XE zur Nutzung frei. Dies ist wieder ein wichtiger und richtiger Schritt für die IT-Sicherheit.
Lizenzhinweis
Privilege Analysis steht als Feature der Oracle Database Enterprise Edition ab Version 12.1 und in der Oracle 18c XE zur freien Verfügung und ist nicht mehr Bestandteil von Database Vault. Licensing Information User Manual
Weitere Informationen
Zurück zur Community-Seite