New Feature 19c: Privilege Analysis

Was ist die „least privilege“ Best Practices?

Der Vollständigkeit halber eine kurze Erklärung der „least privilege“ Best Practices:

Im least-privilege Modell werden einem User nur genau die Rechte gegeben, die er braucht, um seine Funktion auszuführen und nicht mehr. Dies führt zu einer Reduzierung der Angriffsfläche für böswillige Attacken, wie auch für fahrlässiges Verhalten.

Was ist Privilege Analysis?

Privilege Analysis ist ein im Oracle Datenbank Kernel laufendes Programm, um verwendete Rechte für Datenbank-User und Applikationen zu ermitteln. Dabei wird über einen gewissen Zeitraum mitprotokolliert, welche Rechte genutzt werden, und das Ergebnis über Data Dictionary Views angezeigt.

Für diese Analyse wird die Rolle CAPTURE_ADMIN benötigt (und das CONNECT Recht).

Varianten der Privilege Analysis

Es gibt vier Varianten, wie Sie die Privilege Analysis vornehmen können.

Role-based

Die Role-based Analyse ist, wie es sich bei dem Namen erwarten lässt, eine Analyse, bei der anhand einer oder mehrerer Rollen die Rechte-Aufzeichnung aktiv wird.

Context-based

Bei der Context-based Analyse muss mit Hilfe der SYS_CONTEXT-Funktion ein Ausdruck geschrieben werden, der ein boolesches TRUE ergibt, damit die Aufzeichnung aktiv wird.

Role- and context-based

Eine einfache Kombination der zwei schon erklären Varianten. Diese müssen beide zutreffen, damit die Aufzeichnung aktiv wird.

Database-wide

Bei dieser Variante wird die Aufzeichnung für alle Datenbank-Benutzer (bis auf Ausnahmen, siehe Einschränkungen) aktiviert.

Einschränkungen

Die Privilege Analysis unterliegt ein paar Einschränkungen. Die gravierendste ist die Tatsache, dass dieses Feature nur in der Enterprise Edition verfügbar ist. Des Weiteren gibt es auch noch technische Einschränkungen:

• Es kann nur eine Analyse gleichzeitig laufen. Die Ausnahme bildet hier die Database-wide Analyse, diese kann in Kombination mit einer der drei anderen Varianten verwendet werden.
• Die Rechte des SYS Benutzers oder eines Benutzers, der sich als SYSDBA eingeloggt hat, können nicht aufgezeichnet werden.
• Wenn Objekte (Benutzer, Rollen, Tabellen, Views usw.) gelöscht werden, werden auch die entsprechenden Einträge in Views der Privilege Analysis gelöscht.

Multitenant Anmerkungen

Grundsätzlich ist Privilege Analysis Mulitenant fähig, aber es ist nicht möglich, eine „privilege analysis policy“ global über die ganze Multitenant Umgebung anzulegen. Jeder Container muss einzeln bearbeitet werden.

Allgemeiner Ablauf

Die Analyse der Rechte folgt immer dem gleichen Ablauf:

1. Definieren der „privilege analysis policy“.
   Hierbei wird festgelegt, was analysiert wird. Dabei wird sowohl die Art (z. B.: Role-based) wie auch die Bedingung (z. B.: Rollen) angeben.
2. Aktivieren der „privilege analysis policy“.
   Bei diesem Schritt startet die eigentliche Aufzeichnung; dabei sollte auch ein Name für den Durchlauf vergeben werden.
3. Warten
   Dies ist zugleich der am einfachsten durchzuführende wie auch der am schwierigsten zu definierende Schritt: Sie müssen nun die Aufzeichnung laufen lassen, bis alle Aktionen, die ein Benutzer bzw. eine Applikation für seine Funktion braucht, durchgelaufen sind, damit die Aufzeichnung vollständig ist. Eine zu kurze Aufzeichnungsdauer kann dazu führen, dass wichtige Rechte nicht benutzt werden und somit in den Ergebnissen fehlen.
4. Deaktivieren der Aufzeichnung.
   Mit diesem Schritt wird die Aufzeichnung deaktiviert und das Sammeln der Daten beendet.
5. Generieren der „privilege Anaysis“ Ergebnisse und deren Auswertung.
6. Optional: Löschen der „privilege analysis policy“.

Damit werden auch alle aufgezeichneten Daten gelöscht.

Beispiel

Im Folgenden ein Beispiel, um die praktisch nötigen Schritte zu verdeutlichen.

In diesem Beispiel wurden zwei Benutzer angelegt. Dem Benutzer „PA_User“ wurden alle nötigen Rechte zugewiesen, damit er die Privilege Analysis durchführen kann; dem zweiten User „WHYNOTDBA“ wurde die DBA-Rolle zugewiesen. Nun soll ermittelt werden, welche Rechte vom „WHYNOTDBA“ Benutzer benötigt werden. Die Funktion des User besteht lediglich darin, vordefinierte SQL-Skripte nach Bedarf auszuführen.

1. Definition der „privilege analysis policy“

SQL> conn pa_user/pa_user
Connected.
SQL> BEGIN
  2   DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
  3    name           => 'WHYNOTDBA Analysis',
  4    description    => 'Analysieren der Rechte vom User WHYNOTDBA',
  5    type           => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT,
  6    condition      => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'')=''WHYNOTDBA''');
  7  END;
  8  /

PL/SQL procedure successfully completed.
SQL>

Mit dem CREATE_CAPUTRE Aufruf des Packages DBMS_PRIVILEGE_CAPTURE wird Name, Beschreibung, Type und, wenn erforderlich, die Bedingung des Typus definiert. In diesem Fall eine Context-based Analyse mit dem Namen „WHYNOTDBA Analysis“ und der Bedingung „SYS_CONTEXT('USERENV', 'SESSION_USER')='WHYNOTDBA'“.

Ein Beispiel für einen Aufruf mit Role-Based würde wie folgend aussehen:

BEGIN
 DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
  name           => 'DBA Role Analysis',
  description    => 'Analysieren der Rechte von der Rolle DBA',
  type           => DBMS_PRIVILEGE_CAPTURE.G_ROLE,
  roles          => 'dba');
END;
/

Wenn der Type auf G_ROLE gesetzt ist, entfällt der Übergabeparameter condition;  stattdessen muss roles gesetzt sein. Mehrere Rollen müssen über ein VARRAY Namens „role_name_list“ angegeben werden (Dabei können bis zu 10 Rollen angegeben werden).

…
roles => role_name_list('dba','ressource'));
…

Die restlichen Schritte der Analyse sind identisch.

2. Aktivieren der „privilege analysis policy“

SQL> BEGIN
  2    DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE (
  3     name       => 'WHYNOTDBA Analysis',
  4     run_name   => 'WHYNOTDBA_Analysis_run_1');
  5  END;
  6  /
SQL>

PL/SQL procedure successfully completed.

Durch ENABLE_CAPTURE wird die eigentliche Aufzeichnung gestartet. Es müssen der Name der „privilege analysis policy“ und ein Name für diesen Durchgang vergeben werden.

Um zu überprüfen, ob gerade eine Analyse aktiv ist, kann die View DBA_PRIV_CAPTURES abgefragt werden:

SQL> set linesize 300
SQL> col name for a50
SQL> col run_name for a50
SQL> col enabled for a10
SQL> select name, run_name, enabled from DBA_PRIV_CAPTURES where enabled='Y';

NAME                RUN_NAME                  ENABLED   
------------------- ------------------------- -----------
WHYNOTDBA Analysis  WHYNOTDBA_ANALYSIS_RUN_1  Y

3. Warten

In diesem Fall ist Warten nicht direkt nötig, da es die einfache Möglichkeit gibt, alle SQL-Skripte nacheinander auszuführen.

C:\oracle\mqs\sql>sqlplus whynotdba/XXX

SQL*Plus: Release 19.0.0.0.0 - Production on Mon Dec 9 13:06:40 2019
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
Version 19.3.0.0.0

SQL>@@sqlscript01.sql
…
SQL>@@sqlscript50.sql
SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
Version 19.3.0.0.0

3. Deaktivierung der Aufzeichnung

SQL> EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE ('WHYNOTDBA Analysis');

Unter Angabe des „privilege analysis policy“ Namen wird über die Funktion DISABLE_CAPTURE diese deaktiviert.

4. Generieren des „privilege Anaysis“ Reports.

Zuerst müssen mit dem GENERATE_RESULT Aufruf die Ergebnisse vorbereitet werden, bevor diese in den entsprechenden Data Dictionary Views zu sehen sind.

SQL> BEGIN
  2    DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT (
  3      name      => 'WHYNOTDBA Analysis',
  4      run_name  => 'WHYNOTDBA_Analysis_run_1');
  5  END;
  6  /

PL/SQL procedure successfully completed.

4.1. Auswertung der Ergebnisse

SQL> col username format a10
SQL> col sys_priv format a16
SQL> col object_owner format a13
SQL> col object_name format a30
SQL> col run_name format a27
SQL> set linesize 300
SQL> set pagesize 1000
SQL> SELECT distinct SYS_PRIV, OBJ_PRIV, USER_PRIV, OBJECT_OWNER, OBJECT_NAME, OBJECT_TYPE, RUN_NAME FROM DBA_USED_PRIVS WHERE USERNAME = 'WHYNOTDBA';
SYS_PRIV  OBJ_PRIV  USER_PRIV  OBJECT_OWNER  OBJECT_NAME                    OBJECT_TYPE  RUN_NAME
--------- --------- ---------- ------------- ------------------------------ ------------ -------------------------
          SELECT               SYS           DBA_ROLE_PRIVS                 VIEW         WHYNOTDBA_ANALYSIS_RUN_1
…
          SELECT               SYS           DBA_INDEXES                    VIEW         WHYNOTDBA_ANALYSIS_RUN_1

50 rows selected.
SQL>

Da alle Rechte aufgezeichnet werden, wann immer sie genutzt werden, ist es ratsam, mit distinct zu arbeiten, da je nach Länge der Aufzeichnung natürlich viele Rechte vielfach aufgezeichnet werden. In unserem Beispiel ergibt sich dadurch eine Liste von 50 Objekt-Rechten.

Mit einem kleinen Select lässt sich daraus auch schnell ein kleines Skript erstellen, um dem Benutzer die entsprechenden Rechte zu geben.

SQL> set linesize 300
SQL> set pagesize 1000
SQL> SELECT distinct 'GRANT '||OBJ_PRIV||' ON '||OBJECT_OWNER||'.'||OBJECT_NAME||' TO '||USERNAME||';' FROM DBA_USED_PRIVS WHERE USERNAME = 'WHYNOTDBA';

'GRANT'||OBJ_PRIV||'ON'||OBJECT_OWNER||'.'||OBJECT_NAME||'TO'||USERNAME||';'
----------------------------------------------------------------------------------------------------------------------------------------------------------
GRANT SELECT ON SYS.V_$FLASH_RECOVERY_AREA_USAGE TO WHYNOTDBA;
…
GRANT SELECT ON SYS.DBA_JOBS TO WHYNOTDBA;

50 rows selected.
SQL>

Zusätzlich muss dem User das CONNECT Recht zugeordnet werden, damit dieser sich anmelden kann.

Natürlich dürfen Sie nicht vergessen, ihm die DBA-Rollen zu entziehen.

Danach sollten Sie natürlich verstärkt auf Fehler bezüglich Rechten achten. In diesem Beispiel wurden einfach alle Skripte nochmal mit den reduzierten Rechten ausgeführt und dabei auf entsprechende Fehler geachtet.

5. Löschen der „privilege analysis policy“

SQL> EXEC DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE ('WHYNOTDBA Analysis');

Mit dem Aufruf von DROP_CAPTURE mit dem Übergabeparameter des Namens der „privilege analysis policy“ werden sowohl die Policy wie auch alle dazugehörigen Daten gelöscht.

Fazit

Mit der Privilege Analysis, die in 19c neu hinzugekommen ist, ist es relativ einfach, wenn auch unter Umständen noch zeitaufwendig, die benötigten Rechte eines Datenbank-Benutzer zu analysieren. Leider ist hierfür die Enterprise Edition notwendig.