Titel Row Level Security in Oracle8i Autor Karol Hajdu, Trivadis GmbH Mit der Version Oracle 8.1.5 wurden in die Datenbank neue Mechanismen eingebaut, welche die effiziente Implementierung der Zugriffssteuerung mit Granularität auf Row Ebenen erlauben. Dieser Artikel erläutert die Eigenschaften, Grenzen und möglichen Probleme beim Einsatz dieser Mechanismen. Der Hauptteil des Artikels ist den Policies gewidmet. Der Artikel beschreibt auch die Art, wie die Policies bei ihrer Arbeit durch die anderen Mechanismen wie Session Kontexte unterstützt werden. Die Oracle Dokumentation behandelt das Thema Policies und ihre Anwendung relativ bescheiden. Ziel dieses Artikels ist, die Konzepte und Zusammenhänge zu erläutern, die aufgrund mangelhafter Dokumentation meistens nur durch Testversuche zu erwerben sind. Problemstellung bei der Row Level Security: Von einer Tabelle sollen bestimmte Rows nur unter bestimmten Bedingungen sichtbar sein. Lösungsmöglichkeiten bis Oracle 8.1: Verkapseln der Bedingungen in eine WHERE Klausel einer View Verkapseln der Bedingungen in eine PL/SQL Prozedur Delegierung der Aufgabe vom Server auf andere Komponenten im System, z.B. Front-End-Tool Jede dieser Lösungen ist mit einigen Nachteilen (Funktionalität, Performance) verbunden. Mögliche Lösung ab Oracle 8.1: Die geschützte Tabelle wird mit einer PL/SQL Funktion verknüpft, die die Definition für Berechnung der Zugriffsberechtigungen verkapselt. Die Verknüpfung der Tabelle, der PL/SQL Funktion und der Operation wird im Data Dictionary gespeichert und Policy genannt. Die Prüfung der Zugriffsrechte, die via Policies geregelt werden, geschieht in der Datenbank völlig transparent. Rows, für die ungenügende Rechte berechnet wurden, werden durch das Prädikat in der WHERE Klausel aus dem Resultset gefiltert. Page 1 of 15 Beispiel : Anforderung : Zugriff auf die Tabelle SCOTT.EMP ist für alle Benutzer nur während Geschäftszeit erlaubt. Lösung : - Anlegen einer PL/SQL Funktion GetWorkHoursPredicate, die folgende WHERE Klauseln in Form eines Text-Strings generiert: - " 1 = 1": zwischen 8:00 und 17:00 - " 0 = 1": sonstige Systemzeit - Anlegen einer Verknüpfung zwischen der Tabelle SCOTT.EMP und GetWorkHoursPredicate, dazu wird ein Aufruf des DBMS_RLS Packages benötigt: DBMS_RLS.ADD_POLICY ( object_schema object_name policy_name function_schema policy_function statement_type update_check ); => => => => => => => 'SCOTT', 'EMP' , 'SAMPLE_POLICY', 'SECOWNER', upper('GetWorkHoursPredicate'), 'SELECT,INSERT,UPDATE,DELETE', TRUE Effekt : - In einer Session eines beliebigen Benutzers um 7:00 Benutzer Interaktion in SQL*Plus Verarbeitung Interne Oracle - In einer Session eines beliebigem Benutzer um 9:00 Abbildung 1 Die fett gedruckten Prädikate in der WHERE Klausel wurden von DBMS selbst angehängt. Der Text der Prädikate wurde durch Aufruf der Funktion GetWorkHoursPredicate erstellt. Page 2 of 15 Eigenschaften der Policies : Mit Policies können sowohl Tabellen als auch Views geschützt werden. Die Definition des Schutzes wird in der PL/SQL Funktion (Policy Function) definiert. Der Schutz kann sowohl gegenüber unerlaubtem Lesezugriff (SELECT), als auch gegenüber unerlaubten Modifikationen (INSERT, UPDATE, DELETE) definiert werden. Die Definition des Schutzes muss nicht für alle Operationen auf einer Tabelle gleich sein. Pro geschützte Quelle (Tabelle oder View) und Operation können mehrere Policies definiert werden. Die Prädikate der einzelnen Policies werden in der WHERE Klausel mit AND verknüpft. Die Abbildung 1. zeigt die Verhältnisse in der DB, wo die Policy aus unserem Beispiel registriert ist. Abbildung 1 DBA_POLICIES EMP Geschützes Schema: SCOTT Get WorkHours Predicate Policies Schema: SECOWNER SAMPLE_POLICY * * S: * I: * U: * D: ** ** Data Dictionary Owner: SYS Die Policy enthält einen Verweis auf das geschützte Objekt, einen Verweis auf die PL/SQL Funktion, sowie auch Flags, für welche Operation sie appliziert werden soll. Die Trennung des Policies Schemas von dem geschützten Schema ist nicht zwingend notwendig. Oracle erlaubt und unterstützt auch (wie wir später sehen werden) solche Trennungen. Page 3 of 15 Wozu sind Policies gedacht? Eine Definition zu ermöglichen, wie die DB-Instanz die Attribute des Benutzers mit dem Tabelleninhalt (Rows) vergleichen soll, um die Zugriffsrechte des Benutzers gegenüber dem Tabelleninhalt festzustellen. Mit dem Tabelleninhalt ist bei Änderungsoperationen der Inhalt vor der Operation gemeint. Policies können zusätzlich auch zur der Prüfung benutzt werden, dass der Benutzer nach der betätigten Änderungsoperation seine Rechte gegenüber der veränderten Rows nicht "verliert" (die Rows sind für ihn weiterhin sichtbar). Solche Policies werden mit dem sogenannten UPDATE_CHECK Flag gekennzeichnet. Beispiel : Anforderung : Lesezugriff auf die Tabelle SCOTT.EMP ist für alle Benutzer erlaubt. Jeder Angestellte kann nur sich selbst sehen. Die Managers können zusätzlich ihre Untergeordneten sehen und deren die Attribute modifizieren. Bei der Policy für UPDATE ist die Frage über die Einstellung des UPDATE_CHECK Flags von grosser Bedeutung. Filtering der Rows aufgrund der Applizierung der Policy verursacht, dass jeder Manager seine eigene Sicht auf den Inhalt der Tabelle EMP bekommt. Bei der Änderung des Fremdschlüssels in der Row mit SCOTT, der eine Zuordnung zum Manager JONES hat, kann Herr JONES dies so ändern, dass die Row mit SCOTT aus seiner Sicht auf die EMP Tabelle verschwindet und bei einem anderen Manager (KING) auftaucht. Session of User JONES, manager of SCOTT SQL> UPDATE emp 2> SET mgr = 7839 3> WHERE ename = 'SCOTT' ; EMP’ EMP 'SCOTT' ... ... Session of User KING, empno= 7839 EMP’ Abbildung 2 zeigt diese Situation. Abbildung 2 Um dies zu vermeiden, wird das UPDATE_CHECK Flag bei der Policy auf TRUE gesetzt (leider ist dies nicht der Default Wert). Es verursacht, dass nach der Page 4 of 15 UPDATE Operation (von Herrn JONES beantragt) zusätzlich geprüft wird, dass die Row mit SCOTT immer noch in der Sicht des Herrn JONES ist. Im negativen Fall wird die Operation mit ORA-28115: policy with check option violation abgebrochen. Wozu sind Policies nicht gedacht? um die Anzahl der Columns in einem Query Result zu verkleinern oder zu vergrössern um die Werte der Rowsattribute in einem Query Result zu maskieren (mit NULL) oder anders transformieren (DECODE) Wo agieren die Policies? Die Policies agieren in allen Sessions ausgenommen der Sessions des SYS Benutzers und der Benutzer, die als SYSDBA angemeldet sind. Wann agieren die Policies? unmittelbar vor dem Ausführen eines SELECT oder DML Befehls bei Direct Path Operationen (export/import/load) : sie forcieren die Benutzung von Conventional Path Wie agieren die Policies bei SELECT oder DML Befehlen? Beobachten wir folgendes Scenario, dass gegen die DB in Abbildung 1. ausgeführt wird. Session of User ADAMS, SID: 4711 SQL> SELECT * FROM EMP, DEPT 2> WHERE EMP.deptno = DEPT.deptno ; 1. Benutzer ADAMS startet in einer Session ein SELECT Befehl 2. Im Library Cache wird nach der geparsten Representation des Befehls gesucht. Bei Misserfolg wird eine neue SQL Area angelegt. Page 5 of 15 Library Cache SQL Area: 13 DEPT EMP 3. Oracle benutzt die Information aus der SQL Area (13), um einen neuen Cursor zu öffnen. Der neue Cursor muss mit der Aufrufer-Session assoziiert werden. Bei Erstellung dieser Assoziation prüft Oracle, ob einige von den Datenquellen durch irgendeine Policy geschützt sind. Jede durch Policy geschützte Quelle (Tabelle/View) wird mit einer transienten View ersetzt. Child of SQL Area 13 (context heap) EMP’ DBA_POLICIES DEPT EMP WHERE <<Security_Predicate>> Get WorkHours Predicate Policies Schema: SECOWNER Page 6 of 15 SAMPLE_POLICY * * S: * I: * U: * D: ** ** Der entparste Quelltext der transienten View könnte etwa wie folgt aussehen : VIEW EMP' AS SELECT * FROM EMP WHERE <<Security_Predicate>> Der Zeitpunkt, wann das Ersetzen der Quelle EMP mit transienter View EMP' stattfindet, hat wesentliche Konsequenzen auf die Performance und Transparenz des mit Policies implementierten Zugriffsteuerungssystems. Oracle hat sich hier bei der Wahl viel Mühe gegeben und hat sich für den geeignetsten Zeitpunkt entschieden. Die durchaus sehr günstigen Konsequenzen dieser Entscheidung werden später beschrieben. Jetzt geht's weiter mit der Frage, wie wird das <<Security_Predicate>> erstellt. 4. Oracle ruft die PL/SQL Funktion aus der Definition der Policy auf, um das Security Prädikat zu erstellen. Der Aufruf passiert in einer autonomen Session des Owners der Policy Funktion, die extra für diesen Zweck erstellt wurde. Session of SECOWNER, SID: 5211 Child of SQL Area 13 (context heap) DEPT EMP’ EMP WHERE 1=0 Execution Plan ... Fetching ... Page 7 of 15 begin :Security_Predicate:= GetWorkHoursPredicate(...) ; end ; / 1=0 Das Anlegen der SECOWNER Session ist mit wenig Overhead verbunden (vermutlich als eine light-weight Session implementiert). Sehr günstig ist auch die Tatsache, dass der Execution Plan erst nach dem Eingliedern des Policy Prädikats erstellt wird. Agieren der Policies: richtige Stelle und richtiger Zeitpunkt Anhand des vorgestellten Scenarios kann man Konsequenzen in folgenden Bereichen sehen: 1. Funktionalität Schritt 3. im Scenario zeigt, dass wirklich jede Referenz auf geschützte Tabellen durch die Policy geprüft wird (d.h. mit der transienten View ausgetauscht wird): Sowohl bei direkter Benutzung im SQL Befehl, als auch bei indirekter Benutzung, z.B. via Definition einer View oder eines PL/SQL Blocks, und auch bei Befehlen, die export/import/load Utilities generieren. Da bei allen DML Befehlen – nicht nur bei SELECT - die Assozierung des Cursors mit der Aufrufer-Session stattfindet, können auch diese auf gleiche Weise geschützt werden. Die Art der Operation (UPDATE, DELETE oder INSERT) wird einfach aus der geparsten Repräsentation übernommen. jegliche Zugriffe innerhalb der Policy Funktion unterstehen gegebenenfalls auch der gleichen oder anderen Policies (von Oracle werden sogar Zyklen erkannt: ORA-28108: circular row level security policies detected) 2. Information Hiding (Kapselung) Es ist möglich, die Informationen über die Zugriffsrechte zum Inhalt völlig getrennt von Inhalt selbst abzulegen (Policy Funktion muss nicht im gleichem Schema sein wie die geschützten Tabellen). Die Ableitung von Berechtigungen kann sowohl in der Policy Funktion als auch im Policy Prädikat definiert werden. Die Zugriffe innerhalb dieser Konstrukte verlangen in beiden Fällen keine Vergabe der Grants auf das Schema, wo die Daten über die Zugriffsrechte gespeichert sind. (Die Policy Prädikate werden nicht während dem Parsing angehängt, sondern erst später) Page 8 of 15 Da die Policy Funktion immer in einer autonomen Session läuft, kann sie weder durch die Transaktionswelt der geprüften Session, noch durch die Einstellungen der Package Variablen parametrisiert werden. Die Policy Funktion kann auch keinen direkten Einfluss in dieser Hinsicht auf die geprüfte Session haben. 3. Performance Durch das Policy Prädikat wird der Aufbau des Execution Plans beeinflusst, weil der Aufbau erst nach dem Anhängen des Policy Prädikats stattfindet. Durch die Policy Prädikate wird die Library Cache nicht belastet, weil Prädikate erst nach dem Parsing angehängt werden. Ein Prädikat Caching findet bei Applikationen statt, welche die Wiederverwendung von Cursorn erlauben (wie z.B. PL/SQL oder PRO*C mit Compiler Option release_cursor, aber nicht SQL*Plus): Bei gleichen SQL Befehlen innerhalb einer Session können somit die Aufrufe von Policy Funktionen erspart werden. Wodurch sind die Policy Funktionen parametrisierbar? Auch wenn die Policy Funktion immer eine fest vorgeschriebene Signatur haben muss und in einer autonomen Session läuft, so können dennoch folgende Daten als implizite Parameter benutzt werden : „Status Attribute“ der Instance, wie z.B. SYSDATE Ausgewählte Attribute der geprüften Session: nur die, welche dem Session Context gehören. Die Werte der Package Variablen, der benutzerspezifischen Data-Dictionary Views (wie z.B. SESSION_ROLES) oder der Pseudospalte USER können nicht benutzt werden. Inhalt der erreichbaren DB Objekte. Hier findet die gewöhnliche Prüfung der Zugriffsrechte auf Objektebene statt (in Bezug zum Owner der Policy Funktion) und die Lesekonsistenz zu der geprüften Session wird gesichert (Policy Session sieht nur die bestätigten Änderungen der geprüften Session). Was ist ein Session Context ? Ab Oracle8.1.5 ist es möglich, einer beliebigen Session eine Menge von Schlüssel-Wert Paare zuzuordnen. Anwendung und Umgang mit dieser Menge ist den Environment Variablen in der OS-shell sehr ähnlich. Beim Anlegen der Session wird die Menge initialisiert und kann später durch privilegierte PL/SQL Packages modifiziert oder erweitert werden. Die Policy Funktion kann bei der Ableitung der Zugriffsrechte die Werte aus den Schlüsseln des Session Contextes der geprüften Session benutzen, wie z.B. den Namen des Benutzers (Schlüssel 'SESSION_USER' ) oder seine IP Adresse Page 9 of 15 (Schlüssel 'IP_ADDRESS'). Die beiden Beispielschlüssel sind aus der standardmässig initialisierten Menge (weitere sind in der in der Oracle's SQLReference, unter Stichwort SYS_CONTEXT dokumentiert). Die Policy Funktion kann aber auch die Schlüssel aus einer selbst definierten Kontext-Erweiterung benutzen. Systemdesign mit Policies – worauf ist zu achten? 1. Umfang bei mengenartigen Änderungsoperationen muss immer klar sein Der Benutzer muss sich immer bewusst sein, welche Daten er durch eine Operation modifizieren will. Oracle erlaubt, pro Tabelle unterschiedliche Policies für unterschiedliche Zugriffsoperation anzulegen. In einem Zugriffsteuerungsystem darf es aber nie vorkommen, dass der Benutzer den Inhalt modifizieren kann, über dessen Existenz er sich nicht bewusst ist, d.h. den er nicht mit SELECT Operation lesen kann. Da dies von Oracle selbst nicht sichergestellt wird (z.B. bei UPDATE Operation werden nur UPDATE Policies involviert), muss unsere Zugriffsteuerung selbst dafür sorgen, dass ein beliebiges Prädikat für UPDATE und DELETE pro Row immer das entsprechende Prädikat für SELECT enthält. Einfachste Lösung: Man legt über die Tabelle eine (Basis-) Policy für alle Operationen an, und zusätzlich noch eine andere Policy nur für höher privilegierte Operationen. 2. Filtering anhand ungenügend Zugriffsrechte ist nicht immer das gewünschte Verhalten Das Policy Prädikat ist dazu gedacht, den Tabelleninhalt mit ungenügenden Zugriffsrechten auszufiltern. Beim Lesen der Daten ist diese Semantik das meist gewünschte Verhalten. Bei Änderungsoperationen aber nur in sehr seltenen Fällen! Meistens möchte man informiert werden, dass die Operation aufgrund mangelnder Berechtigungen fehlgeschlagen hat. Bei mengenartigen Operationen sogar auch mit der Auflistung der Elemente, welche die Probleme verursacht haben. Um eine Oracle Exception zu generieren, müssen wir einen PL/SQL Block aufrufen, der mit Inhalt der einzelnen Row parametrisiert ist. Die Policy Funktion können wir dazu nicht benutzen, da sie nicht mit einzelnen Rows parametrisierbar ist. Wir brauchen also eine SQL Funktion in das Policy Prädikat zu platzieren. Da Änderungsoperationen meistens relativ hoch selektive Beschränkungen auch ohne das Policy Prädikat haben, können wir mit den Performance Nachteilen relativ gut leben. 3. Zugriffsteuerung ist ein benutzerabhängiger Teil der Anwendungslogik Bei Systemen, wo die Anwendungslogik auch in dem Oracle Server residiert, stellt sich die Frage, wo die mit Policies implementierte Zugriffsteuerung Page 10 of 15 agieren soll: Gleich über den Tabellen? Unmittelbar unter dem API des Applikationsservers? Um die Trennung der Zugriffslogik von der allgemein gültigen Logik zu erzielen, empfehlen wir, die Zugriffslogik möglichst hoch (in der Abstraktionsrichtung) zu platzieren, am besten gleich unter dem API. Die günstige Architektur zeigt die Abbildung 8. Abbildung 8 4. Verwendung von DBMS_RLS.REFRESH_POLICY ist verdächtig Mit DBMS_RLS.REFRESH_POLICY besteht die Möglichkeit, die Neuberechnung der gecachten Policy Prädikate zu forcieren. Braucht man überhaupt so etwas zu machen? In den meisten Fällen ist die Menge der Zugriffsberechtigungen von der Funktion und den Aufgaben der Person innerhalb einer Unternehmenseinheit abgeleitet. Abgesehen von einigen Spezialfällen, gibt es gute Gründe dafür, Page 11 of 15 dass die Änderungen in dieser Menge nur mit Anlegen einer neuen Session synchronisiert werden: - es ist meistens gewünscht, dass die Benutzersicht auf die Daten (aufgrund Berechtigungen) während einer Sitzung konstant bleibt - Anlegen der Session kommt meistens häufiger vor, als eine Änderung in den Berechtigungen Ein typisches Beispiel eines Spezialfalls ist die Autorisierung in einer workfloworientierten Anwendung, wo die Berechtigungen zum Produkt aufgrund dessen Zustand abgeleitet werden. Eine Verwendung von DBMS_RLS.REFRESH_POLICY erweckt unserer Meinung nach den Verdacht, dass man die Policies entweder für andere Zwecke als Autorisierung benutzt, oder dass die Autorisierung nicht auf einer konsequenten Autentizierung basiert. Entwicklung der Policies – worauf ist zu achten? 1. Error-stack des Aufrufs der Policy Funktion ist nach dem Abschluss nicht verfügbar Der Error-stack von dem Aufruf der Policy Funktion, falls er nicht leer war, wird in die Alert.log Datei geschrieben. Die geprüfte Session erhält aus dem Policy Error-Stack nur einen einzigen Eintrag mit ORA-28112 : failed to execute policy function. Dies verhindert also die feinere Behandlung des Fehlers durch die Applikation (Policy Session hat konsequenterweise einen sehr limitierten Einfluss auf die geprüfte Session). 2. DML Befehle innerhalb der Policy Funktion werden nicht unterstützt Jeder Versuch, ein DML Befehl innerhalb der Policy Funktion durchzuführen, mag er auch innerhalb einer autonomen Transaktion stattfinden, endet mit einem Fehler (ORA-28112). 3. Manche Beziehungen imr Data Dictionary bezüglich Policies werden nicht auf referentielle Integrität geprüft Der Data Dictionary von Oracle8.1.5 und 8.1.6 erlaubt, dass nach einem DROP FUNCTION PolicyFunction oder DROP USER SecOwner einige Policies in der Datenbank immer noch aktiv sind, obwohl für sie keine Policy Funktion existiert. Konsequenz : bis zur Behebung des Problems sind die durch fehlerhafte Policies geschützten Daten nicht verfügbar (ORA-28100: policy function schema string is invalid oder ORA-28104 policy function or package is invalid). Ein einfacher DDL-Event Trigger beim SYS kann das Auftreten solcher Situationen vermeiden: CREATE OR REPLACE TRIGGER d_policies_ri BEFORE DROP ON DATABASE Page 12 of 15 WHEN ( sys.dictionary_obj_type = 'USER' OR sys.dictionary_obj_type = 'PACKAGE' OR sys.dictionary_obj_type = 'FUNCTION' ) DECLARE l_cnt NUMBER ; BEGIN SELECT count(*) INTO l_cnt FROM DBA_POLICIES p WHERE p.enable = 'YES' AND ( ( sys.dictionary_obj_type = 'USER' AND sys.dictionary_obj_name = p.PF_OWNER ) OR ( sys.dictionary_obj_type = 'PACKAGE' AND sys.dictionary_obj_owner = p.PF_OWNER AND sys.dictionary_obj_name = p.PACKAGE ) OR ( sys.dictionary_obj_type = 'FUNCTION' AND sys.dictionary_obj_owner = p.PF_OWNER AND sys.dictionary_obj_name = p.FUNCTION) ) ; IF l_cnt > 0 THEN raise_application_error(-20001, 'Policy Dependency exists : USER/PACKAGE/FUNCTION still used in an enabled policy.') ; END IF ; END ; / 4. Für das Aufruf Tracking der Policy Funktionen gibt es seitens Oracle keine Unterstützung Oracle liefert kein Tracking Tool, mit dem man die Aufrufe der Policy Funktionen verfolgen kann. Dies wäre aber gerade beim Entwickeln der Policies sehr wünschenswert. Ein kleines Utility von Trivadis, das man von unserer Web-Site downloaden kann, kann Ihnen das Aufruf Tracking wesentlich erleichtern. DBA Aufgaben mit Policies – worauf ist zu achten ? 1. Policies werden auch bei Export/Import/Load Operationen appliziert Beim Applizieren der Policy werden entsprechende Warnungen produziert. Die Applikation der Policies kann man nur vermeiden, wenn man das Utility als SYS oder als SYSDBA aufruft. Sogar beim Benutzer SYSTEM, oder bei EXTERNALLY identifizierten Benutzern, die sich in der DBA Gruppe des Betriebsystems befinden, werden die Policies appliziert, solange die die Session nicht als SYSDBA angelegt wird. Hier die Beispiele, wie man sich in diesen Fällen als SYSDBA einlogt : imp 'SYSTEM/MANAGER AS SYSDBA'.... . exp '/ AS SYSDBA' ...... 2. Beim Export und Import der Tabellendefinition werden auch Policies einbezogen Beim Export oder Import einbezogene Policies referenzieren auch die Policy Funktion, welche aber nicht mit der Tabellendefinition übertragen wird. Es ist auch richtig so, denn der Export/Import hat keine Kenntnisse über das mit Page 13 of 15 Policy Funktionen entwickelte Subsystem der Zugriffssteuerung. Es muss dem Administrator überlassen werden, in wie weit die Zugriffslogik in der DB fähig sein soll, die exportierten Daten zu schützen, bzw. in wie weit die importierte Policy die bereits in der DB vorhandenen Daten schützen soll. Dadruchkann es passieren, dass aufgrund invalider Policies die geschützten Daten nicht verfügbar sind (auch für die autorisierten Benutzer), eine Freigabe der geschützten Daten nach einem unvollständigen Import wird jedoch auch vermieden. 3. Pro Datenbank sollte es nur einen Benutzer mit Verwaltungsrechten für die Policies geben Anlegen oder Löschen einer Policy entspricht in der Welt der höheren Granularität dem Entnehmen oder der Vergabe der Rechte zu den DBObjekten. Das Delegationsprinzip (nur der Besitzer der Rechte kann die Rechte an andere weiter vergeben) kann man bei der Granularität auf Row aus mehreren Gründen nicht benutzen: - die Rechte können nicht immer auf einzelne Row bezogen sein (Performance, Administration) - der Vergeber der Rechte darf in manchen Fällen die Rechte auf den Rows selbst nicht besitzen Oracle ermöglicht in der Version 8.1.5 und 8.1.6, ausgewählte Benutzer zur Administration der Policies über beliebige DB-Objekte zu berechtigen (mit EXECUTE Privilege auf DBMS_RLS). Diese Benutzer brauchen keinen Rechte auf die DB-Objekte zu haben, auf denen sie die Policies administrieren. Eine neue Art vom Objekt Privilege 'RLS_PROTECT' wäre seitens Oracle eine elegante Lösung dieses Problems. Wir sind aber überzeugt, dass man durchaus befriedigend mit nur einem DB-Account für Verwaltung der Policies leben kann und benutzen dafür folgende Argumentation: - die Zugriffslogik und die Daten über die Zugriffsrechte selbst können auch ausserhalb dieses Accounts gespeichert werden (Massnahme gegen nicht autorisierte Änderung der Zugriffsrechte) - dieses Account braucht keine Rechte auf die DB-Objekte zu haben, auf welchen er die Policies verwaltet (Massnahme gegen nicht autorisierten Zugriff) - die Vorteile von der zentralisierten Verwaltung der Policies, welche ja anwendungsunabhängig und transparent agieren Zusammenfassung: Page 14 of 15 Oracle ist es mit Policies gelungen, schon im dem ersten Release (8.1.5) ein gutes und konsistentes Konzept vorzustellen, das auf transparente und performante Weise implementiert ist. Die Policies können einen mächtigen Beitrag bei der Implementierung eines Row Level Security Systems leisten. Da sie vor allem die Entwicklung und Integration der Zugriffslogik entlasten, ermöglichen sie, dass man sich beim Design weniger mit technischen Problemen beschäftigen muss, zugunsten der Semantik. Da sie transparent und allgemeingültig agieren, stellt sie die Frage über richtige Semantik viel deutlicher. Da sie sehr tief in die Datenbank integriert sind, leisten sie auch im DBA Bereich beim Schutz der Daten einen Beitrag. Die hohe Transparenz birgt auch Risiken. Die Konsequenzen des Agieren von Policies müssen an alle klar kommuniziert werden: an Entwickler, an DBAs und auch an Endbenutzer. Dies ist fast nur dann möglich, wenn die Menge der Regeln klein ist und die Regeln selbst einfach sind. Mit freundlicher Empfehlung :-) "Policies – enjoy it, but keep it simple!" Karol Hajdu Trivadis GmbH Max-Lang-Str. 56 D-70771 Leinfelden-Echterdingen Tel.: +49-711-90 36 32-30 Fax : +49-711-90 36 32-59 [email protected] www.trivadis.com Page 15 of 15