Mehr Sicherheit in DB2 durch LBAC

In der ORDIX News Ausgabe 1/2007 gaben wir einen ersten Überblick über die zahlreichen Neuerungen der DB2 Version 9.1. Die weiteren Artikel dieser Reihe gehen nun mehr in die Tiefe einzelner neuer Funktionen, beschreiben technische Details und verdeutlichen den Umgang anhand kleinerer Beispiele. In diesem Artikel beginnen wir mit interessanten Einzelheiten über die Neuerung LBAC!

Was ist LBAC?

LBAC steht für "Label-Based Access Control" und ist in DB2 9.1 eine neue Funktion aus dem Bereich Sicherheit. Mit Hilfe dieser "kennzeichenbasierten Zugriffskontrolle" können für einzelne Zeilen und/oder Spalten einer Da­ten­banktabelle Lese- und Schreibrechte für ein­zelne Benutzer vergeben und gesteuert wer­den. Somit kann der Zugriff auf eine Tabelle erlaubt werden, bestimmte Bereiche dieser Tabelle bleiben allerdings für einzelne Benutzer im Verborgenen.

Beispiel I: Sicherheit auf Spaltenebene

Im ersten Beispiel nehmen wir an, dass eine Tabelle für Mitarbeiterdaten existiert. Eine Spalte dieser Tabelle beinhaltet das Gehalt. Mittels LBAC kann nun festgelegt werden, dass der Vorstand des Unternehmens auf die Spalte "Gehalt" Lese- und Schreibzugriff bekommt. Die Mitarbeiter der Verwaltung erhalten lediglich einen Lesezugriff und alle übrigen Mitarbeiter bekommen überhaupt keinen Zugriff auf die Spalte mit dem Gehalt.

Beispiel II: Sicherheit auf Zeilenebene

Im zweiten Beispiel gehen wir davon aus, dass eine Tabelle existiert, in der alle Tätigkeiten von verschiedenen Projekten erfasst werden.

Mittels LBAC wird nun festgelegt, dass ein Mitarbeiter Datensätze, die sich auf Projekte beziehen, an denen auch er tätig ist, lesend und schreibend zugreifen darf. Projektleitern wird erlaubt, die Datensätze von den Projekten einzusehen, für die sie die Leitungsposition übernehmen. Der Vorstand erhält Lesezugriff auf alle Datensätze der Tabelle, jedoch darf auch er keine Veränderungen vornehmen.

Funktionsweise

Die Zugriffssteuerung erfolgt über so genannte "Security Label" (Sicherheitskennzeichen), die sowohl Benutzern als auch Datensätzen einer Tabelle zugewiesen werden.

Möchte nun ein Benutzer auf einen Datensatz zugreifen, wird sein Sicherheitskennzeichen mit dem des Datensatzes verglichen. Nur bei einer Übereinstimmung erhält der Be­nut­zer Zugang zu den geforderten Tabellendaten.

Wenn die Sicherheitskennzeichen nicht übereinstimmen, sieht es für den Benutzer entweder so aus, als ob der Datensatz nicht existiert (LBAC auf Zeilenebene) oder aber er bekommt eine Fehlermeldung für unzureichen­de Berechtigung (LBAC auf Spaltenebene).

Bei der Vergabe des Sicherheitskennzeichens wird zusätzlich festgelegt, ob der Benutzer einen Vollzugriff auf die Daten erhält oder aber lediglich einen lesenden Zugriff.

Voraussetzungen

Sicherheitskennzeichen dürfen nicht von je­dem Benutzer zugewiesen werden, sondern können aus­schließlich durch einen Sicherheitsadministrator erfolgen. Bei diesem handelt es sich um einen Benutzer, der über die SECADM-Berechtigung verfügt, die ebenfalls mit der DB2 Version 9.1 neu eingeführt wurde (siehe ORDIX News Artikel "IBM DB2 UDB Version 9.1 – New Features (Teil I): Codename "Viper").

Benötigte LBAC-Komponenten

Sicherheitskennzeichen sind aber nur ein Bestandteil von LBAC. Daneben gibt es noch zwei weitere wichtige Bestandteile, so dass zum Einrichten von LBAC die folgenden Komponenten benötigt werden:

• Security Label Component
• Security Policy
• Security Label

Bei der Konfiguration von LBAC muss die obige Reihenfolge eingehalten werden.

Security Label Component

Die Komponente Security Label Component dient der Darstellung von Vertraulichkeitsstufen und -strukturen. Insgesamt gibt es folgende drei verschiedene Typen:

• ARRAY: dient der Speicherung verschiedener Vertraulichkeitsstufen. Je weiter vorne ein Element im Array eingeordnet ist, desto vertraulicher ist es.
• TREE: dient der Darstellung einer Hierarchie von Vertraulichkeitsstufen. Es gibt ein so genanntes ROOT-Element, dem weitere Elemente untergeordnet sind. Die untergeordneten Elemente können wiederum weitere Elemente aufnehmen.
• SET: definiert eine Menge von Vertraulichkeitsstufen. Dadurch kann hier nur die Über­prüfung durchgeführt werden, ob ein Element in der SET-Liste vorhanden ist. Es existieren keinerlei Hierarchien.

Die Syntax zur Erstellung einer Security Label Component" zeigt Abbildung 1.

CREATE SECURITY LABEL COMPONENT 
{ 
ARRAY[ <element>, <element>, ...] | 
TREE( <element> ROOT, <element> UNDER <element>, ...) | 
SET{ <element>, <element>, ...}
}

Für das Beispiel I ist es ausreichend, eine Security Label Component zu deklarieren, die vom Typ SET ist (siehe Abbildung 2).

create security label component slc_gehalt 
  set {'Vertraut'};

Abbildung 3 zeigt die Security Label Component für Beispiel II. Damit die Hierarchiestufen aus diesem Beispiel dargestellt werden können, wird die Security Label Component TREE verwendet, bei der an oberster Stelle der Vorstand steht. Danach folgen die Projektleiter, denen wiederum Projekte unterstellt sind. Besitzt ein Projekt keinen Projektleiter, ist es direkt dem Vorstand untergeordnet.

create security label component slc_projekte
  tree(
    'Vorstand'	    ROOT,
    'PL_Projekt_A'  UNDER 'Vorstand',
    'PL_Projekt_B'  UNDER 'Vorstand',
    'Projekt_A'     UNDER 'PL_Projekt_A',
    'Projekt_B'     UNDER 'PL_Projekt_B',
    'Projekt_C'     UNDER 'Vorstand’
  );

Security Policy

Die Security Policy dient der Aufnahme von Sicherheitskennzeichen und beschreibt die Richtlinien und Bedingungen für die eigentliche Zugriffskontrolle. Wichtigster Bestandteil einer Security Policy ist die gerade zuvor kennengelernte Security Label Component. Ohne diese Komponente kann eine Security Policy nicht erstellt werden, da hier die oben erwähnten Richtlinien durch die Vertraulichkeitsstufen festgelegt werden. Einzelne Sicherheitskennzeichen werden durch Zuordnung zu einer Security Policy in eine Vertraulichkeitsstufe eingeordnet.

Eine Security Policy kann verschiedenen Tabellen zugeordnet werden. Diese Zuordnung hat durch die SQL-Statements CREATE oder ALTER zu erfolgen. (Achtung, eine Tabelle kann immer nur eine Security Policy aufnehmen).

Die Syntax zur Erstellung einer Security Policy finden Sie in Abbildung 4. Bei der Erstellung gibt es zwei Optionen, die die Vergabe der Sicherheitskennzeichen regeln:

1. restrict not authorized write security label
   Das Einfügen oder Aktualisieren eines Datensatzes schlägt fehl, wenn der Benutzer nicht autorisiert ist, explizit ein Sicherheitskennzeichen für den Datensatz zu schreiben.
2. overwrite not authorized write security label
   Beim Einfügen oder Aktualisieren eines Datensatzes wird diesem automatisch das Sicherheitskennzeichen des Benutzers vergeben.

CREATE SECURITY POLICY 
  COMPONENTS <security label component>
  WITH DB2LBACRULES
  {
    restrict not authorized write security label
    | overwrite not authorized write security label
  };

Die Abbildungen 5 und 6 zeigen die Erstellung der Security Policy für die Beispiele I und II.

create security policy sp_gehalt
  components slc_gehalt
  with db2lbacrules
  restrict not authorized write security label;

create security policy sp_projekte
  components slc_projekte
  with db2lbacrules
  restrict not authorized write security label;

Security Label

Das Security Label ist die wichtigste Komponente von LBAC, da anhand eines Vergleiches dieser Kennzeichen entschieden wird, ob ein Benutzer einen Datensatz/Spaltenwert sehen darf oder nicht.

Als Basis für ein Sicherheitskennzeichen dient immer eine Security Policy. Bei der Namensgebung des Kennzeichens muss die Policy mit angeführt werden. Die Syntax entspricht dabei zum Beispiel dem select auf eine Tabelle eines anderen Schemas. Zuerst wird der Name der Policy verlangt, dann folgt ein Punkt ( . ) und anschließend der Name des Labels. Durch diese Vorgehensweise ist direkt festgelegt, welcher Security Policy ein Sicherheitskennzeichen zugeordnet ist.

Weiterhin wird beim Anlegen des Sicherheitskennzeichens die Angabe der Security Label Component verlangt. Jedes Kennzeichen kann immer nur eine Vertraulichkeitsstufe einer Security Label Component beinhalten.

Die Syntax zur Erstellung eines Sicherheitskennzeichens zeigt Abbildung 7.

CREATE SECURITY LABEL <security policy>.<name security label>
  COMPONENT <security label component> '<Vertrauensstufe>';

Die Abbildungen 8 und 9 zeigen die Erstellung der Sicherheitskennzeichen für die beiden Beispiele.

create security label sp_gehalt.sl_gehalt
  component slc_gehalt 'Vertraut';

create security label sp_projekte.projekt_a
  component slc_projekte 'Projekt_A';
 
create security label sp_projekte.projekt_b
  component slc_projekte 'Projekt_B';
 
create security label sp_projekte.projekt_c
  component slc_projekte 'Projekt_C';
 
create security label sp_projekte.pl_projekt_a
  component slc_projekte 'PL_Projekt_A';
 
create security label sp_projekte.pl_projekt_b
  component slc_projekte 'PL_Projekt_B';
 
create security label sp_projekte.vorstand
  component slc_projekte 'Vorstand';

LBAC-Aktivierung

Neben den Daten müssen natürlich auch die Benutzer mit einem entsprechenden Sicherheitskennzeichen ausgestattet werden. Die Zuweisung wird mit Hilfe des Grant-Kommandos vorgenommen.

Dabei kann nun auch festgelegt werden, ob der Benutzer Vollzugriff (for all access) oder nur Lesezugriff (for read access) auf die Daten erhält. Die Abbildungen 10 und 11 zeigen mögliche Grant-Kommandos für die beiden Beispiele.

grant security label sp_gehalt.sl_gehalt
  to user klose
  for all access;
 
grant security label sp_gehalt.sl_gehalt
  to user gruber
  for read access;

grant security label sp_projekte.projekt_a
  to user joschko for all access;
 
grant security label sp_projekte.vorstand
  to user klose for read access;
 
grant security label sp_projekte.pl_projekt_b
  to user gruber for read access;

Tabelle für LBAC anpassen

Erster Schritt, um eine Tabelle mit LBAC zu sichern, ist die Zuweisung einer Security Policy. Diese Zuweisung kann mit dem CREATE- oder mit dem ALTER TABLE-Befehl erfolgen. Im Weiteren muss man unterscheiden, ob die Tabelle auf Zeilen- oder auf Spaltenebene geschützt werden soll.

Wenn eine Tabelle auf Spaltenebene geschützt werden soll, so muss die zu schützende Spalte um die Klausel SECURED WITH und um den Namen des Sicherheitskennzeichens erweitert werden. Die Abbildung 12 zeigt, wie die Spalte "Gehalt" der Mitarbeitertabelle mit dem Kennzeichen "sl_gehalt" geschützt wird.

create table mitarbeiter (
  nr       int,
  name     varchar(25),
  adresse  varchar(25),
  gehalt   int SECURED WITH sl_gehalt
) 
security policy sp_gehalt;

Wenn eine Tabelle auf Zeilenebene geschützt werden soll, muss eine zusätzliche Spalte vom Datentyp DB2SECURITYLABEL angelegt werden. In dieser wird dann das Sicherheitskennzeichen des Datensatzes gespeichert, welches bei einer Abfrage mit dem Kennzeichen des Benutzers verglichen wird (siehe Abbildung 13).

create table projekttaetigkeiten
( 
  nr           DECIMAL(6) NOT NULL,
  projekt      DECIMAL(6) NOT NULL,
  mitarbeiter  DECIMAL(4) NOT NULL,
  datum        DATE,
  taetigkeit   VARCHAR(200),
  security     DB2SECURITYLABEL	
) 
security policy sp_projekte;

Beim Hinzufügen der zusätzlichen Spalte vom TYP DB2SECURITYLABEL wird für jeden Wert, der sich bereits in der Tabelle befindet, das Kennzeichen des Benutzers in dieser Spalte eingetragen.

Sicherheitskennzeichen zuweisen

Beim Insert wird jedem Datensatz ein entsprechendes Kennzeichen zugewiesen. Dieses ist abhängig vom Label des Benutzers, welcher den Datensatz einfügen möchte. Vorausgesetzt wird natürlich, dass der Benutzer im Besitz eines Sicherheitskennzeichens mit Schreibberechtigung für die Tabelle ist.

Explizit kann einem Datensatz in der Spalte vom Typ DB2SECURITYLABEL das Sicherheitskennzeichen auch durch die Funktion SECLABEL_BY_NAME() zugeordnet werden. Als Übergabeparameter werden die Security Policy und das Security Label verlangt:

SECLABEL_BY_NAME('sp_projekt', 'sl_projekt_a')

Bei einem select auf diese Spalte erhält man das jeweilige Sicherheitskennzeichen des Da­tensatzes, sofern man berechtigt ist, den Datensatz auch zu sehen.

Fazit

Hinter LBAC verbirgt sich mit Sicherheit eine sehr gute Methode, um bestimmte Daten vor unberechtigten Zugriffen zu schützen. Die Möglichkeit, Benutzern einzelne Datensätze einer Tabelle zu entziehen, ist alleine mit dem Vergeben (grant) bzw. Entziehen (revoke) von Rechten nicht zu realisieren.

Weiterhin kann man eventuell auch auf die Erstellung der ein- oder anderen View verzichten, indem man bereits zuvor Einschränkungen an Tabellen durch LBAC vornimmt.

Anfangs erscheint LBAC vielleicht ein bisschen kompliziert und unüberschaubar. Auch dieser Artikel und die darin enthaltenen Beispiele beschreiben lediglich einen kleinen Teil dieser neuen Funktion. Je intensiver man sich allerdings mit dem Thema auseinandersetzt und viele Funktionen einfach selbst ausprobiert, desto verständlicher und einfacher zu handhaben wird das Ganze.

Thorsten Schuhmacher (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen