Zugriffskontrolle

Verschiedene Benutzer haben verschiedene Rechte bzgl. derselben Datenbank. Tabelle 14.1 zeigt eine Berechtigungsmatrix (wertunabhängig):

Benutzer	Ang-Nr	Gehalt	Leistung
A (Manager)	R	R	RW
B (Personalchef)	RW	RW	R
C (Lohnbüro)	R	R	--

Tabelle 14.1: Berechtigungsmatrix

Bei einer wertabhängigen Einschränkung wird der Zugriff von der aktuellen Ausprägung abhängig gemacht:

Zugriff (A, Gehalt):	R:	Gehalt	<	10.000
	W:	Gehalt	<	5.000

Dies ist natürlich kostspieliger, da erst nach Lesen der Daten entschieden werden kann, ob der Benutzer die Daten lesen darf. Ggf. werden dazu Tabellen benötigt, die für die eigentliche Anfrage nicht verlangt waren. Beispiel: Zugriff verboten auf Gehälter der Mitarbeiter an Projekt 007.

Eine Möglichkeit zur Realisierung von Zugriffskontrollen besteht durch die Verwendung von Sichten:

define view v(angnr, gehalt) as 
select angnr, gehalt from angest 
where gehalt < 3000

Eine andere Realisierung von Zugriffskontrollen besteht durch eine Abfragemodifikation.

• Beispiel:
  Die Abfrageeinschränkung

  
  deny (name, gehalt) where gehalt > 3000
  

  liefert zusammen mit der Benutzer-Query

  
  select gehalt from angest where name = 'Schmidt'
  

  die generierte Query

  
  select gehalt from angest
  where name = 'Schmidt' and not gehalt > 3000
  

In statistischen Datenbanken dürfen Durchschnittswerte und Summen geliefert werden, aber keine Aussagen zu einzelnen Tupeln. Dies ist sehr schwer einzuhalten, selbst wenn die Anzahl der referierten Datensätze groß ist.

• Beispiel:
  Es habe Manager X als einziger eine bestimmte Eigenschaft, z. B. habe er das höchste Gehalt. Dann läßt sich mit folgenden beiden Queries das Gehalt von Manager X errechnen, obwohl beide Queries alle bzw. fast alle Tupel umfassen:

  
  select sum (gehalt) from angest;
  select sum (gehalt) from angest 
  where gehalt < (select max(gehalt) from angest);
  

In SQL-92 können Zugriffsrechte dynamisch verteilt werden, d. h. der Eigentümer einer Relation kann anderen Benutzern Rechte erteilen und entziehen.

Die vereinfachte Syntax lautet:

grant { select | insert | delete | update | references | all } 
on <relation> to <user> [with grant option]

Hierbei bedeuten

select:	darf Tupel lesen
insert:	darf Tupel einfügen
delete:	darf Tupel löschen
update:	darf Tupel ändern
references:	darf Fremdschlüssel anlegen
all :	select + insert + delete + update + references
with grant option:	<user> darf die ihm erteilten Rechte weitergeben

• Beispiel:
  

  A:	grant read, insert on angest to B with grant option
  B:	grant read on angest to C with grant option
  B:	grant insert on angest to C

Das Recht, einen Fremdschlüssel anlegen zu dürfen, hat weitreichende Folgen: Zum einen kann das Entfernen von Tupeln in der referenzierten Tabelle verhindert werden. Zum anderen kann durch das probeweise Einfügen von Fremdschlüsseln getestet werden, ob die (ansonsten lesegeschützte) referenzierte Tabelle gewisse Schlüsselwerte aufweist:

create table Agententest(Kennung character(4) references Agenten);

Jeder Benutzer, der ein Recht vergeben hat, kann dieses mit einer Revoke-Anweisung wieder zurücknehmen:

revoke { select | insert | delete | update | references | all }
on <relation> from <user>

• Beispiel:
  B: revoke all on angest from C
  Es sollen dadurch dem Benutzer C alle Rechte entzogen werden, die er von B erhalten hat, aber nicht solche, die er von anderen Benutzern erhalten hat. Außerdem erlöschen die von C weitergegebenen Rechte.

Der Entzug eines Grant G soll sich so auswirken, als ob G niemals gegeben worden wäre!

• Beispiel:
  

  A:	grant read, insert, update	on angest to D
  B:	grant read, update	on angest to D with grant option
  D:	grant read, update	on angest to E
  A:	revoke insert, update	on angest from D

  Hierdurch verliert D sein insert-Recht, E verliert keine Rechte. Falls aber vorher A Rechte an B gab, z.B. durch

  A: grant all on angest to B with grant option

  dann müssten D und E ihr update-Recht verlieren.