Oracle Zugriffskontrolle:
Fine Grained Access Control (FGAC)

Der Artikel beschäftigt sich mit der Funktionalität der fein granulierten Zugriffskontrolle (FGAC) unter Oracle. Sie hilft dem Datenbankadministrator bei der Auswahl firmensensitiver Daten für einzelne Benutzer im Hinblick auf die Erhöhung der Sicherheit bei der Bearbeitung. Zunächst geben wir einen kurzen Überblick über die bisher zur Verfügung stehenden Möglichkeiten von Sicherheitsmechanismen. Danach stellen wir die fein granulierte Zugriffskontrolle und ihre neuen Einsatzmöglichkeiten ab Oracle 10g Release 2 vor.

Der Standardmechanismus der Zugriffskontrolle auf Tabellendaten wird über die Vergabe von Objektprivilegien (SELECT, INSERT, UPDATE, DELETE) an die einzelnen Benutzer oder über die Zuweisung von Benutzerrollen gesteuert. Damit ist nur eine statische Zugriffskontrolle auf die einzelne Tabelle oder die einzelne View gewährleistet.

Sobald der Benutzer das entsprechende Privileg besitzt, kann er auf sämtliche Datensätze dieser Tabelle zugreifen. Häufig ist es jedoch notwendig, dass der Benutzer nur auf die für ihn relevanten Daten zugreifen darf, z. B. beim Internet Banking.

Oftmals wird dies über die Bereitstellung von Views gelöst. Die Benutzer erhalten die Zu­griffs­rechte auf die Daten der Basistabellen nur über die Views. Die Nachteile dieser Lösung sind:

• fehlende Dynamik
• eine große Anzahl und Vielfalt von Views
• Administration über DDL-Kommandos

Fine Grained Access Control

Hier greift nun Fine Grained Access Control (FGAC): Über FGAC wird dem Benutzer sozusagen eine "Virtual Private Database" (VPD) zur Verfügung gestellt. Damit kann er nur noch die Datensätze sehen und manipulieren, auf die er entsprechend der definierten Sicherheitsrichtlinien ("Policys") zugreifen darf.

Der Zugriff auf die relevanten Daten wird in der Datenbank selbst gesteuert. Diese Funktion steht ab der Version 8i zur Verfügung. Dies bedeutete bisher, dass nur die einzelne Zeilenebene betrachtet wird. Seit dem Release Oracle 10g R2 ist nun die Möglichkeit der spaltenweisen Betrachtung hinzugekommen.

Abb. 1: Informationsgewinnung mittels Fine Grained Access Control (FGAC).

Vorgehensweise

Für eine spaltenweise Betrachtung ist es notwendig, eine so genannte Policy als Regelwerk an eine Basistabelle zu binden. Diese Policy beinhaltet wiederum eine Prädikatsfunktion, mit deren Hilfe gedanklich eine Erweiterung der WHERE-Klausel des entsprechenden DML- bzw. SELECT-Statements vor­genommen wird. Diese Prädikatsfunktion kann neuerdings über PL/SQL individuell an die einzelnen Anforderungen der spaltenweisen Betrachtung angepasst werden.

Policy

Die Policy wird mit Hilfe des Datenbank-Pack­ages DBMS_RLS erstellt. Zum Hinzufügen nutzt man die Prozedur ADD_POLICY. Die einzelnen Parameter beinhalten die Informationen in Abbildung 2. Hinzu kommen noch die Einzelprozeduren der Abbildung 3. Darüber hi­naus existieren auch Gruppenprozeduren, die dann auf bestimmte Policy-Gruppen wirken.

Dynamische Prädikatsfunktion

Die Policy-Funktion bezeichnet man auch als dynamische Prädikatsfunktion, weil sie erst in der Parse-Phase des eingegebenen SELECT oder DML-Statement implementiert wird und dann in der Ausführungsphase die relevanten Informationen liefert. Sie stellt eine WHERE-Klausel bereit, mit der die entsprechende Zugriffsregel definiert wird. Das Beispiel in Abbildung 4 gibt einen Überblick über die Erstellung der Prädikatsfunktion.

CREATE OR REPLACE FUNCTION meier.mitarbeiter_sec 
  (schema IN varchar2, tab IN varchar2)
RETURN VARCHAR2 AS
BEGIN
  RETURN 'MITARBEITERNAME='''|| 
    sys_context('userenv', 'session_user') ||'''';
END mitarbeiter_sec;
/
 
SELECT mitarbeitername, gehalt, abteilungsnr 
  FROM mitarbeiter
  WHERE MITARBEITERNAME = (sys_context('userenv', 'session_user') ;

Abbildung 5 zeigt die Erstellung einer Policy mit Prädikatsfunktion.

EXECUTE DBMS_RLS.ADD_POLICY (
  object_schema =>   ' MEIER ',
  object_name =>     'MITARBEITER', 
  policy_name =>     'MA_POLICY',
  function_schema => 'MEIER', 
  policy_function => 'MITARBEITER_SEC',
  statement_types => 'SELECT'
  ); 
 
select mitarbeiternr, mitarbeitername, gehalt 
  from MEIER.mitarbeiter;

Spaltenbasierte Beschränkung bzw. Spaltenmaskierung

Die mit Release 2 eingeführte Modifikation der spaltenbasierten Beschränkung beruht auf der Möglichkeit, die einzelnen, sicherheitsrelevanten Spalten zu bezeichnen. Damit werden nur die Datensätze der markierten sicherheitsrelevanten Spalten angezeigt, für die eine Zugriffsberechtigung besteht. Somit sind nur diejenigen Spaltenwerte zu sehen, auf die der aktuelle Benutzer zugreifen darf. Die übrigen Werte der sicherheitsrelevanten Spalten werden mit NULL-Werten angezeigt. Abbildung 6 zeigt einen entsprechenden Aufruf und die zugehörige Ausgabe.

EXECUTE DBMS_RLS.ADD_POLICY (
  object_schema =>         ' MEIER ', 
  object_name =>           'MITARBEITER', 
  policy_name =>           'MA_POLICY',
  function_schema =>       'MEIER', 
  policy_function =>       'MITARBEITER_SEC',
  statement_types =>       'SELECT',  
  sec_relevant_cols =>     'GEHALT', 
  sec_relevant_cols_opt =>  DBMS_RLS.ALL_ROWS
  );
 
select mitarbeiternr,mitarbeitername,gehalt from MEIER.mitarbeiter;
 
Ausgabe:
MITARBEITERNR	MITARBEITERNAME	  GEHALT 
1               Dr. Klose
11              Schroeder
155             MEIER             20000 

Kontextsensitiver Policy Typ

Ebenso kann man nun eine Policy im session­bezogenen Kontext erstellen. Die Prädikats­funktion wird dabei bezogen auf existieren­de Kontextwerte zusammengestellt [z. B. SYS_CONTEXT ('USERENV', 'SESSION_USER')].

Dabei wird die Prädikatsfunktion nach dem Parsen des SQL-Statements entsprechend des gesetzten Kontextes benutzt. Dies ist dann sinnvoll, wenn mit mehr als einem Benutzer oder verschiedenen Benutzergruppen gearbeitet wird.

Dazu wird zuerst der entsprechende Kontext definiert. Der zugrunde liegende Kontext, in dem der Benutzer arbeitet, sollte durch einen Logon-Trigger definiert sein. Der Kontext selbst stellt dabei ein über die gesamte Session gültiges Attribut/Wertepaar dar. Dies gilt ab Oracle 10g Release 2 mit der Funktionalität SYS_CONTEXT auch bei einer parallelen Abfrage.

Bei der kontextsensitiven Erstellung einer Policy braucht man die Prädikatsfunktion nicht erneut anzupassen (siehe Abbildung 7). Das kommt dem Ziel der Steigerung der Performance entgegen.

CREATE CONTEXT mitarbeiter_ctx USING ora00.mitctx;
CREATE OR REPLACE PACKAGE ora00.mitctx AS
  PROCEDURE set_mitarbeiternr_prc;
END;
/
CREATE OR REPLACE PACKAGE BODY ora00.mitctx IS
  PROCEDURE Set_mitarbeiternr_prc IS mit_name VARCHAR2(200);
BEGIN
  SELECT mitarbeitername INTO mit_name FROM ora00.mitarbeiter
    WHERE mitarbeitername = SYS_CONTEXT('USERENV','SESSION_USER');
  DBMS_SESSION.SET_CONTEXT ('MITARBEITER_CTX', 'MA_NO', mit_name);
END SET_MITARBEITERNR_PRC;
END;
/
BEGIN
  mitctx.set_mitarbeiternr_prc;
END;
/
CREATE OR REPLACE PACKAGE ora00.mitctx AS 
  PROCEDURE set_mitarbeiternr_prc;
END;
/

Im Anschluss wird, wie schon in den vorhergehenden Releases, eine Prädikatsfunktion erstellt, die nun den neu erstellten Kontext benutzt (siehe Abbildung 8). Vorteilhaft ist, dass diese nun nicht neu angepasst werden muss, sondern immer für die durch den Kontext betroffenen Benutzer Gültigkeit besitzt.

CREATE OR REPLACE PACKAGE ora00.mit_security AS
FUNCTION mitarbeiter_sec (schema IN VARCHAR2, tab IN VARCHAR2)
RETURN VARCHAR2;
END;
/
CREATE OR REPLACE PACKAGE BODY ora00.mit_security AS
FUNCTION mitarbeiter_sec (schema IN VARCHAR2, tab IN VARCHAR2)
RETURN VARCHAR2 IS v_mit VARCHAR2(200);
BEGIN
  v_mit := 'mitarbeitername = SYS_CONTEXT(''MITARBEITER_CTX'',''MA_NO'')';
  RETURN v_mit;
END mitarbeiter_sec;
END mit_security;
/

Im letzten Schritt (Abbildung 9), erstellen wir nun die Policy, die die Prädikatsfunktion benutzt. Als Ergebnis dieser kontextbasierenden Prädikatsfunktion ergibt sich bei dem User ORA00, dass bei einem SELECT-Zugriff nur seine relevanten Daten aus der Tabelle Mitarbeiter an­gezeigt werden (siehe Abbildung 10).

BEGIN
DBMS_RLS.ADD_POLICY (object_schema => 'ORA00', 
  object_name =>     'MITARBEITER', 
  policy_name =>     'MIT_POLICY', 
  function_schema => 'ORA00', 
  policy_function => 'MIT_SECURITY.MITARBEITER_SEC', 
  statement_types => 'SELECT');  
  --, sec_relevant_cols => 'GEHALT',
sec_relevant_cols_opt=>DBMS_RLS.ALL_ROWS)
END;
/

select mitarbeitername, gehalt from mitarbeiter;

MITARBEITERNAME   GEHALT
ORA00             10000

Fazit

Fine Grained Access Control bietet gegenüber den herkömmlichen Verfahren die folgenden Vorteile:

• Weniger Administrationsaufwand für die Da­tenbankadministratoren durch weniger Views
• Ausschluss überflüssiger Informationen (Information Overload/Zeitmanagement) für den einzelnen Benutzer
• Das FGAC kann jederzeit ohne weitere Lizenzkosten implementiert werden.
• Durch die innerhalb der Datenbank integrierte Funktionalität ist ein programmierbares Umgehen von Sicherheitsrichtlinien unmöglich.
• Das FGAC erweitert die Möglichkeiten der Zugriffskontrolle durch zeilen- und spaltenbasierte Datenselektion.

Diese nun feiner zu granulierende Informationsgewinnung ermöglicht dem Datenbankadministrator, dass er den Entscheidern keine überflüssigen Informationen mehr zur Verfügung stellt, die diese gar nicht haben sollen oder wollen. Das Fine Grained Access Control definiert nun eindeutig, von wem welche sensitiven Informationen innerhalb der Datenbank genutzt werden dürfen und welche nicht.

Klaus Günther (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen