Logo Oracle Deutschland   DBA Community  -  Februar 2011 (zuletzt ergänzt Juli 2011)
Least Privilege - Ein Anfang
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Für jede Datenbank muss ein adäquates Sicherheitskonzept existieren. Das gebietet nicht nur der 'gesunde Menschenverstand', sondern wird durch immer mehr Gesetze, Wirtschafts- und Unternehmensrichtlinien erzwungen. In diesem Zusammenhang werden auch Forderungen gestellt, die zwar nicht EDV spezifisch sind, aber auch in EDV Systemen umgesetzt werden müssen. Dazu gehören zum Beispiel die Prinzipien der Funktionstrennung und Aufgabenverteilung, der Kenntnis nur bei Bedarf (need to know) und auch die Einschränkung der Privilegien von Benutzern ausschließlich auf solche Rechte, die sie unbedingt benötigen, ihre dienstlichen Aufgaben zu erfüllen. Diese Einschränkung bezeichnet der Begriff least privilege.

Im Rahmen der Datenbank Community ist der Grundsatz des least privilege auch gelegentlich angesprochen worden - zum Beispiel im Rahmen der Beiträge zum Härten und zur Verwendung von Rollen. Die weitreichendsten grundsätzlichen Möglichkeiten der Umsetzung von least privilege bietet sicherlich der Einsatz der Datenbankoption Database Vault: Sie ermöglicht unter anderem, die Ausführung beliebiger Befehle an selbst zu definierende Bedingungen zu knüpfen. Muß oder kann man nicht gleich ganz so weit gehen, stellt sich im Alltag immer häufiger die Frage, wie least privilege für Datenbanken, die ja immer schützenswerte Daten enthalten, konkret durchgesetzt werden kann. In diesem Beitrag soll deshalb der Anfang gemacht werden für eine Art Liste, welche Privilegien und / oder Rollen unter Einhaltung des Prinzips des least privilege benötigt werden, um bestimmte Optionen, Features und Packages nutzen zu können. Dazu wird jeweils sehr knapp und ohne jeden Anspruch auf Vollständigkeit skizziert, wozu eine Option, ein Feature oder Package dient, um dann die Privilegien und / oder Rollen zu benennen, die zu ihrem Einsatz benötigt werden.

Vorab noch ein Hinweis: Dieser Artikel ist ganz offensichtlich unvollständig und weicht damit von den bisher vorliegenden Tipps der Community ab. Allerdings soll er in den nächsten Wochen und Monaten ständig ergänzt und überarbeitet werden - ausgehend von den Fragen, Wünschen und Informationen, die die Mitglieder der Community sowie Kolleginnen und Kollegen vorbringen. Manch einer hat gewarnt, dieses Thema anzugehen, von Sisyphusarbeit war die Rede. Dennoch: Ein paar Versuche, den Stein den Hang hinaufzurollen, dürfen es schon sein.


Data Pump

Data Pump ist seit Oracle10g der Nachfolger von Export und Import. Data Pump dient in erster Linie dazu, Daten aus einer Datenbank in eine andere Datenbanken zu transportieren.

Jeder Benutzer kann mit Data Pump seine eigenen Objekte exportieren und importieren. Dazu wird allerdings der Zugriff auf ein logisches Directory benötigt. Ein solches Directory kann ausschließlich ein Benutzer mit dem Privileg CREATE DIRECTORY anlegen. Die Rolle DBA verfügt über dieses Privileg und kann auch mit GRANT READ / WRITE / EXECUTE ON directoryname den benötigten Zugriff einrichten.

Ein exportierender Benutzer benötigt zudem die Berechtigung, in seinem default tablespace eine Tabelle anzulegen und ausreichend Speicherplatz (quota), um in diese Tabelle durch Data Pump Informationen zum Export protokollieren zu lassen.

Wer Objekte exportieren oder importieren will, die nicht zum eigenen Schema gehören, benötigt die Rollen datapump_export_full_database und / oder datapump_import_full_database.

Eine ausführlichere Beschreibung des Arbeitens mit Data Pump enthält dieser Community Beitrag.

Zurück zur Übersicht

DBMS_XPLAN

DBMS_XPLAN erlaubt die Analyse der Abarbeitung von SQL Befehlen zum Beispiel als Grundlage für eventuell erwünschte Performanceverbesserungen. Das Package gehört dem Benutzer SYS, wird aber mit den Privilegien des aufrufenden Benutzers ausgeführt.

Soll mit der Funktion DISPLAY aus dem Package die Ausgabe eines EXPLAIN Befehls angezeigt werden, genügt die Zugriffsberechtigung für die sogenannte plan table. Diese Tabelle kann mit dem Skript CATPLAN.SQL angelegt werden.

Die Funktion DISPLAY_CURSOR erfordert die Leseberechtigung für die Views V$SQL_PLAN, V$SESSION und V$SQL_PLAN_STATISTICS_ALL.

Die Funktion DISPLAY_AWR erfordert die Leseberechtigung für die Views DBA_HIST_SQL_PLAN, DBA_HIST_SQLTEXT und V$DATABASE.

Die Funktion DISPLAY_SQLSET erfordert die Leseberechtigung für die Views ALL_SQLSET_STATEMENTS und ALL_SQLSET_PLANS.

Die Funktion DISPLAY_SQL_PLAN_BASELINE erfordert die Leseberechtigung für die View DBA_SQL_PLAN_BASELINES.

Sämtliche Privilegien für die Verwendung von DBMS_XPLAN sind in der Rolle SELECT_CATALOG_ROLE enthalten. Im Sinne des least privilege ist von der Verwendung der Rolle abzuraten, denn sie enthält zusätzlich mehr als 2200 weitere Privilegien auf andere Objekte.

Eine ausführlichere Beschreibung des Arbeitens mit DBMS_XPLAN enthält dieser Community Beitrag.

Zurück zur Übersicht

Zugriffe auf das Data Dictionary

Der Initilisierungsparameter O7_DICTIONARY_ACCESSABILITY sollte auf dem Default FALSE stehen. Dadurch wird verhindert, dass Benutzer mit dem Privileg SELECT ANY TABLE Tabellen des Data Dictionary lesen können. Der Wert TRUE stellt den Zustand her, der in Version 7 der Datenbank Default war: Das SELECT ANY TABLE Privileg galt auch für die Tabellen des Data Dictionary.

Drei Rollen erlauben eine differenzierte Steuerung des Zugriffs auf Objekte des Data Dictionary:
  • SELECT_CATALOG_ROLE erlaubt den Zugriff auf Data Dictionary Views
  • DELETE_CATALOG_ROLE ermöglicht das Löschen in den Tabellen des Audit Trails und
  • EXECUTE_CATALOG_ROLE eröffnet den Zugriff auf Prozeduren und Packages des Data Dictionary.
Das Privileg SELECT ANY DICTIONARY erlaubt nicht nur den Zugriff auf Views des Data Dictionary, sondern den Zugriff auf ALLE Objekte des Benutzers SYS.

Zurück zur Übersicht

Enterprise Manager Database Control

Database Control ist das graphische Werkzeug zur Verwaltung einer lokalen Datenbank. Bei jeder Datenbankinstallation hat man die Wahl, das Database Control installieren zu lassen, oder der Installationsroutine mitzuteilen, dass stattdessen das systemübergreifende Werkzeug Enterprise Manager Grid Control zur Verwaltung der zu installierenden Datenbank verwendet wird.

Es wird die Rolle OEM_ADVISOR benötigt. Diese Rolle wird ebenfalls benötigt, um Advisory und Tuning Tasks (wie STS anlegen, löschen usw.) durchführen zu können. Will oder darf man wegen der Umsetzung des Prinzips des least privilege nicht das Privileg SYSDBA vergeben, wird für das Startup und Shutdown der Datenbank zusätzlich das Privileg SYSOPER benötigt.

Zurück zur Übersicht

Real Application Testing

Seit Oracle Database 11g besitzt die Datenbank ein Testing Werkzeug - die sogenannte Real Application Testing Option, die aus den beiden sich ergänzenden Komponenten SQL Performance Analyzer (SPA) und Database Replay (DB Replay) besteht. SPA wird dabei bei detaillierten SQL Statement Analysen eingesetzt, Database Replay hingegen testet die Performance des gesamten Datenbank Workloads.

Folgende Privilegien sind erforderlich:
  • EXECUTE für die Packages DBMS_WORKLOAD_CAPTURE und DBMS_WORKLOAD_REPLAY
  • CREATE ANY DIRECTORY
  • SELECT_CATALOG_ROLE
  • BECOME USER
  • ADMINISTER SQL TUNING SET
Zurück zur Übersicht

Real Time Monitoring (auch SQL Monitoring genannt)

Real Time Monitoring ist ein Feature des Tuning Packs. Das SQL Monitoring überwacht automatisch SQL Statements, wenn eine der folgenden Voraussetzungen erfüllt ist
  • Parallele Ausführung
  • Verbrauch von mehr als 5 Sekunden CPU bzw. I/O Zeit
  • Verwendung des MONITOR Hints
SELECT Privilegien auf folgende Views sind erforderlich
  • GV_$SQL_PLAN_MONITOR
  • GV_$SQL_PLAN
  • GV_$SQL_MONITOR
  • GV_$ACTIVE_SESSION_HISTORY
  • GV_$SQL
  • GV_$SESSION_LONGOPS
  • GV_$ASH_INFO
  • GV_$INSTANCE
  • GV_$DATABASE
  • GV_$TIMER
  • GV_$SQL_OPTIMIZER_ENV
  • GV_$SYS_OPTIMIZER_ENV
  • V_$SQL_PLAN_MONITOR
  • V_$SQL_PLAN
  • V_$SQL_MONITOR
  • V_$ACTIVE_SESSION_HISTORY
  • V_$SQL
  • V_$SESSION_LONGOPS
  • V_$ASH_INFO
  • V_$INSTANCE
  • V_$DATABASE
  • V_$TIMER
  • V_$SQL_OPTIMIZER_ENV
  • V_$SYS_OPTIMIZER_ENV
  • DBA_PROCEDURES
Sämtliche Privilegien für die Verwendung des Real Time Monitoring sind in der Rolle SELECT_CATALOG_ROLE enthalten. Im Sinne des least privilege ist von der Verwendung der Rolle abzuraten, denn sie enthält zusätzlich mehr als 2200 weitere Privilegien auf andere Objekte.

Eine ausführlichere Beschreibung des Arbeitens mit dem Real Time Monitoring enthält dieser Community Beitrag.

Zurück zur Übersicht

Resource Manager

Database Resource Manager ermöglicht die Verwaltung von Datenbank Ressourcen (zum Beispiel CPU) speziell die Verteilung auf verschiedene Applikationen und Benutzer.

Das Arbeiten mit dem Resource Manager erfordert das Privileg ADMINISTER RESOURCE MANAGER.

Eine ausführlichere Beschreibung des Arbeitens mit dem Resource Manager enthält dieser Community Beitrag.

Zurück zur Übersicht

SQL Plan Management

SQL Plan Management ist ein Feature der Enterprise Edition und verhindert Änderungen am SQL Ausführungsplan durch Speicherung und intelligente Weiterentwicklung des SQL Plans.

Folgende Privilegien sind erforderlich

  • ALTER SESSION
  • ADMINISTER SQL MANAGEMENT OBJECT
    • ,
Eine ausführlichere Beschreibung des Arbeitens mit dem SQL Plan Management enthält dieser Community Beitrag.

Zurück zur Übersicht

Text

Oracle Text ist in der Standardengine der Datenbank enthalten und ermöglicht linguistische Abfragen auf SQL Ebene.

Um Preferences-Einstellungen zu erzeugen, zu ändern und zu löschen oder spezielle Oracle Text PL/SQL Packages zu verwenden wird die Rolle CTXAPP benötigt. Falls folgende Packages im Rahmen der TEXT Entwicklung Verwendung finden, müssen zusätzlich EXECUTE Privilegien für diese Packages vergeben werden
  • CTXSYS.CTX_CLS
  • CCTXSYS.CTX_DOC
  • CCTXSYS.CTX_OUTPUT
  • CCTXSYS.CTX_QUERY
  • CCTXSYS.CTX_REPORT
  • CCTXSYS.THES
  • CCTXSYS.CTX_ULEXER
Eine ausführlichere Beschreibung des Arbeitens mit Text enthalten diese beiden Beiträge der APEX Community: Text 1 und Text 2.

Zurück zur Übersicht

Total Recall

Total Recall erfasst in der Datenbank sämtliche Zustände, die ein Datensatz einer Tabelle oder mehrerer Tabellen durch die Befehle UPDATE und DELETE erfährt. Die Datensätze können jederzeit gelesen werden, sie sind vor Veränderungen geschützt und können nach festzulegenden Zeiträumen automatisch gelöscht werden.

Das Anlegen, Ändern und Löschen eines sogenannten Archivs für die Speicherung der verschiedenen Zustände eines Datensatzes erfordert das Privileg FLASHBACK_ARCHIVE_ADMINISTER. Die Rolle DBA enthält dieses Privileg.

Damit die geänderten Sätze einer Tabelle archiviert werden, muss die Tabelle entweder mit der Klausel FLASHBACK ARCHIVE angelegt oder zu einem späteren Zeitpunkt mit dem Befehl ALTER TABLE ... FLASHBACK ARCHIVE modifiziert werden. Dazu wird das Privileg FLASHBACK ARCHIVE für ein existierendes Archiv benötigt.

Eine ausführlichere Beschreibung des Arbeitens mit Total Recall enthält dieser Community Beitrag.

Zurück zur Übersicht

Web Services

Native Web Services ermöglichen PL/SQL Packages, Prozeduren und Funktionen ohne zusätzliche Kodierung oder Installation als Web Service bereitzustellen.

Die Rolle XDB_WEBSERVICES ermöglicht die Nutzung von Web Services über HTTPS.

Mit der Rolle XDB_WEBSERVICE_OVER_HTTP wird die Nutzung über das Protokoll HTTP (nicht nur gesichert über HTTPS) ermöglicht.

Die Rolle XDB_WEBSERVICES_WITH_PUBLIC ermöglicht den Zugriff auf PUBLIC Objekte über Web Services.

Eine ausführlichere Beschreibung des Arbeitens mit Web Services enthalten diese beiden Beiträge der APEX Community: Web Services 1 und Web Services 2.

Zurück zur Übersicht


Zurück zur Community-Seite