Privilege Analysis
Wenn Datenbank Accounts eingerichtet werden sollen, sollten diesem Account auch nur die wirklich benötigten Berechtiungen erteilt werden. Oftmals verlangt die Applikation aber nach sehr weitreichenden Berechtigungen. Wird mit DBA-Privilegien entwickelt, dann wird genau dieses Recht dann auch für die produktive Umgebung verlangt. Dem DBA gefällt das natürlich nicht. Der Entwickler oder Softwarehersteller wird sich nun aber schwer tun, die einzelnen benötigten Berechtigungen herauszuarbeiten. Hier kommt das Feature "Privilege Analysis" ins Spiel, das mit Oracle 12.1 eingeführt wurde. Dieses Feature war zu Beginn leider Teil der Option "Database Vault" und somit kaum nutzbar. Oracle hat nun mit der Version 18 die Lizenzbedinungen auch rückwirkend bis 12.1 geändert, das Feature ist jetzt Bestandteil der Enterprise Edition und erfordert keinerlei zusätzliche Optionen mehr.
Folgendes einfache Beispiel soll die Anwendung des Features verdeutlichen. Dreh- und Angelpunkt dabei ist das Package DBMS_PRIVILEGE_CAPTURE. Im Beispiel gibt es ein zentrales Schema namens "NEXUS" und einige weitere Datenbanknutzer, die auf dieses Schema zugrreifen sollen. Innerhalb der Applikation wurden Rollen erstellt, die alle nötigen Privilegien enthalten. Jedoch benötigten die Benutzer zusätzlich das "SELECT ANY TABLE" Privileg, da sonst Fehler auftraten. Dieses Recht galt es zu eliminieren.
Zuerst wird eine Regel erstellt, die definiert, welche Aktionen überwacht werden sollen. Da "like" für die Bedingung nicht verwendet werden kann, wurde ein "between"-Ausdruck verwendet, der das gleiche bewirkt.
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
name => 'COLLECT_NEXUS' ,
description => 'Ermittlung verwendeter Privilegien von Nexus' ,
type => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT ,
condition => 'SYS_CONTEXT (''USERENV'',''SESSION_USER'') between ''NEXUS'' and ''NEXUT'''
);
END;
/
Um nun tatsächlich Daten zu sammeln, muss diese Regel aktiviert werden.
BEGIN DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE('COLLECT_NEXUS'); END;
/
Nun kann der fragliche Teil der Applikation durchlaufen werden. Dabei wird die Datenbank alle genutzten Privilegien registrieren. Um die anfallende Datenmenge nicht zu groß werden zu lassen, wird das Sammeln im Anschluss direkt wieder deaktiviert.
BEGIN DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE('COLLECT_NEXUS'); END;
/
Nun kann mit Hilfe der View DBA_USED_PRIVS die Analyse beginnen.
SQL> SELECT DISTINCT USERNAME, SYS_PRIV, OBJ_PRV, OBJECT_OWNER,OBJECT_NAME,USERNAME FROM DBA_USED_PRIVS WHERE CAPTURE='COLLECT_NEXUS';
USERNAME SYS_PRIV OBJ_PRIV USER_PRIV OBJECT_OWNER OBJECT_NAME
----------- ---------------- ----------- ----------- --------------- ---------------
NEXUS13 CREATE PROCEDURE
NEXUS11 CREATE PROCEDURE
[...]
NEXUS11 CREATE TABLE
NEXUS13 CREATE VIEW
NEXUS11 CREATE VIEW
NEXUS11 SELECT ANY TABLE NEXUS KASSEKAT
NEXUS11 SELECT ANY TABLE NEXUS SPRACHEN
NEXUS13 SELECT SYS ALL_TAB_COLUMNS
NEXUS13 SELECT SYS ALL_CONSTRAINTS
NEXUS11 SELECT NEXUS BEREICHSZAHLEN
NEXUS13 SELECT SYS ALL_OBJECTS
NEXUS EXECUTE SYS DBMS_OUTPUT
NEXUS13 SELECT NEXUS KAPITEL
[...]
Offensichtlich benötigt die Applikation das "SELECT ANY TABLE" Privileg für den Zugriff auf zwei Tabellen im Hauptschema. Diese Berechtigungen hat der Nutzer bereits über eine Rolle erhalten, jedoch wirken diese Grants nicht, wenn die Tabellen innerhalb PL/SQL Code verwendet werden. Hierfür ist ein direkter Grant erforderlich.
Nachdem die Benutzer nun direkte Grants auf die beiden fraglichen Tabellen erhalten hatten, konnte der Grant des "SELECT ANY TABLE" zurückgenommen werden ohne die Funktion der Applikation zu beeinträchtigen.
Dieses Beispiel verdeutlicht gut die weit reichenden Anwendungsfälle dieses Features. Mit der Freigabe für die Enterprise Edition kann es nun auch in größerem Umfang zum Einsatz kommen. Einzig Standard Edition Nutzern bleibt diese Möglichkeit verwehrt.
Kommentare
Keine Kommentare