2001-01-News-Hajdu-Row_Level_Security8i

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