Kapitel 10: Transaktionen und Datenintegrität

–1–
Kapitel 10: Transaktionen und Datenintegrität
Ein DBMS hat die Korrektheit des Datenbankzustandes unter realen Benutzungsbedingungen zu wahren. Dazu gehören die folgenden Punkte:
• Datensicherheit (Recovery)
Schutz vor Verlust von Daten durch technische Fehler (z.B. Systemabsturz).
• Integrität (Integrity)
Schutz vor Verletzung der Korrektheit und Vollständigkeit von Daten durch berechtigte Benutzer.
• Synchronisation (Concurrency Control)
Schutz vor Fehlern durch sich gegenseitig störenden nebenläufigen Zugriff mehrerer Benutzer.
• Datenschutz (Security)
Schutz vor Zugriffen und Änderungen durch unberechtigte Benutzer.
Die Sicherstellung der Datensicherheit, Integrität (= Konsistenz) und Synchronisation wird durch das
Konzept der Transaktionen erreicht. Für den Datenschutz wird mit Zugriffsrechten gearbeitet.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–2–
10.1 Das Transaktionskonzept
Transaktionen (TAs) sind die Einheiten integritätserhaltender Zustandsänderungen einer Datenbank.
Transaktion
DBvorher
DBnachher
(konsistent)
DBtmp1
…
(konsistent)
DBtmpn
Transaktionen sind ein wesentliches Konzept für die Integritätserhaltung. Sie dienen zur Synchronisation (Concurrency Control) im Mehrbenutzerbetrieb. In Bezug auf die Datensicherheit (Recovery)
sind Transaktionen jedoch auch für Einbenutzersysteme wichtig.
Beispiel Bankwesen: Überweisung von Huber an Meier in Höhe von 200,00 DM
• Möglicher Bearbeitungsplan:
(1) Erniedrige Stand von “Huber” um 200,00
(2) Erhöhe Stand von “Meier” um 200,00
• Möglicher Ablauf:
Systemabsturz
Konto
Kunde
Meier
Huber
Stand
1.000,00
1.500,00
(1)
Konto
Kunde
Meier
Huber
Stand
1.000,00
1.300,00
(2)
Wichtig: Inkonsistenter Datenbankzustand darf nicht entstehen bzw. nicht dauerhaft bestehen bleiben.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–3–
Eigenschaften von Transaktionen
Eine grundlegende Charakterisierung von Transaktionen ist durch das ACID-Prinzip gegeben:
• Atomicity (Atomarität, “alles-oder-nichts”-Prinzip)
Der Effekt einer Transaktion kommt entweder ganz oder gar nicht zum Tragen.
• Consistency (Konsistenz, Integritätserhaltung)
Durch eine Transaktion wird ein konsistenter Datenbankzustand wieder in einen konsistenten
Datenbankzustand überführt.
• Isolation (Isoliertheit, logischer Einbenutzerbetrieb)
Innerhalb einer Transaktion nimmt ein Benutzer Änderungen durch andere Benutzer nicht wahr.
• Durability (Dauerhaftigkeit, Persistenz)
Der Effekt einer abgeschlossenen Transaktion bleibt dauerhaft in der Datenbank erhalten.
Eine weitere Forderung ist, daß eine Transaktion in endlicher Zeit bearbeitet werden kann.
Erweitertes Konzept: Designtransaktionen
Der Entwurf komplexer Systeme (CAD, Software, Multimedia-Präsentationen, …) kann nicht innerhalb weniger Sekunden oder Minuten durchgeführt werden, sondern zieht sich über Tage, Wochen
oder Monate hin. Dabei sollen aber durchaus auch “inkonsistente” Zwischenzustände der Datensicherung unterliegen. Ansätze hierfür sind Techniken zur Verwaltung “langer Transaktionen” und “geschachtelter Transaktionen”.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–4–
Steuerung von Transaktionen
• begin of transaction
Beginn der Befehlsfolge einer neuen Transaktion
SQL: Transaktionen werden stets implizit begonnen, es gibt kein begin work o.ä.
• end of transaction, commit
Bestätigung der Transaktion durch den Benutzer
– Die Änderungen seit Beginn der Transaktion werden endgültig bestätigt
– Der jetzt erreichte Zustand soll dauerhaft gespeichert werden
– Der Zustand wird durch den Benutzer für konsistent erklärt
SQL: commit work oder nur commit
• abort transaction
Abbruch der Transaktion durch das Programm bzw. den Benutzer (Rücksetzen, ABORT)
– Die Änderungen der Transaktion werden zurückgesetzt
– Der ursprüngliche Zustand vor der Transaktion wird wiederhergestellt.
SQL: rollback work oder nur rollback
Beispiel:
UPDATE Konto SET Stand = Stand – 200 WHERE Kunde = ‘Huber’;
UPDATE Konto SET Stand = Stand + 200 WHERE Kunde = ‘Meier’;
COMMIT;
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–5–
Ein COMMIT kann …
gelingen:
Der neue Zustand wird dauerhaft gespeichert, oder
scheitern:
Der ursprüngliche Zustand wie zu Beginn der Transaktion bleibt erhalten (bzw.
wird wiederhergestellt). Ein COMMIT kann scheitern, wenn die Verletzung von
Integritätsbedingungen erkannt wird.
Schematischer Ablauf
gelingt
Transaktion
DBvorher
(konsistent)
DBtmp1
…
commit
DBtmpn
rollback
DBnachher
mißlingt
(abort)
(konsistent)
Lange Transaktionen werden durch die folgenden Anweisungen unterstützt:
• Definition eines Sicherungspunktes, auf den sich eine (noch aktive) Transaktion zurücksetzen läßt. Die Änderungen dürfen allerdings noch nicht endgültig festgeschrieben werden, da
die Transaktion bis hin zur Bestätigung des COMMIT noch scheitern kann.
SQL: savepoint ⟨identifier⟩
• Zurücksetzen der aktiven Transaktion auf einen definierten Sicherungspunkt.
SQL: rollback to savepoint ⟨identifier⟩ oder nur rollback to ⟨identifier⟩
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–6–
10.2 Datensicherheit
Eine Aufgabe des DBMS besteht darin, die dauerhafte und konsistente Verfügbarkeit des Datenbestandes sicherzustellen. Ein wichtiger Aspekt ist die Berücksichtigung von Fehlern, die im laufenden Betrieb und auf den Datenträgern auftreten können.
Klassifikation von Fehlern
• Transaktionsfehler
Lokaler Fehler einer noch nicht abgeschlossenen Transaktion, z.B. aufgrund
– Fehler und Abbruch des Anwendungsprogrammes (z.B. Division durch Null, …)
– Verletzung von Integritätsbedingungen oder Zugriffsrechten
– expliziter Abbruch der Transaktion (rollback) durch den Benutzer
– Konflikte mit nebenläufigen Transaktionen.
• Systemfehler
Verlust von Hauptspeicherinformation z.B. wegen Stromausfall, Ausfall der CPU, Absturz des
Betriebssystems, etc. Die permanenten Speicher (Platten) sind nicht betroffen.
• Medienfehler
Verlust von permanenten Daten durch Zerstörung des Speichermediums, z.B. Plattencrash,
Brand, Wasserschaden, etc.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–7–
Techniken zur Wiederherstellung (Recovery)
Wichtigstes Ziel ist es, wieder einen konsistenten Datenbankzustand zu erreichen. Dabei soll soviel an
früherer Information wiederhergestellt werden wie möglich, nicht jedoch auf Kosten der Integrität.
Abhängig von der Art des aufgetretenen Fehlers gibt es verschiedene Wiederherstellungstechniken:
• Rücksetzen (bei Transaktionsfehler)
Der ursprüngliche Datenbankzustand wie zu Beginn der Transaktion wird wiederhergestellt; der
Anfangszustand jeder TA muß deshalb bis zum COMMIT verfügbar gehalten werden.
• Warmstart (bei Systemfehler)
Rücksetzen (UNDO) aller vor dem Fehler noch nicht abgeschlossenen Transaktionen.
• Kaltstart (bei Medienfehler)
Aufsetzen auf einem früheren, gesicherten Datenbankzustand (backup)
Nachführen (REDO) aller Transaktionen, die bereits committed waren
Rücksetzen (UNDO) aller Transaktionen, deren COMMIT noch ausstand
Technische Grundlagen
• Duplizierung (d.h. gezielte Redundanz) des Datenbankzustandes durch Backup-Techniken
(Bänder, Spiegelplatten, zusätzliches Rechenzentrum in anderer Stadt, …)
• Logfiles (logging): Mitprotokollierung der laufenden Aktionen, Beginn und Ende
(COMMIT, ABORT) von Transaktionen.
Logfiles entstehen sequentiell —> schnelles Schreiben möglich.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–8–
10.3 Integrität und Integritätsbedingungen (IB)
Für die Beispiele betrachten wir das folgende relationale Datenbankschema:
Kunde (KName, KAdr, Kto)
Auftrag (KName, Ware, Menge)
Lieferant (LName, LAdr, Ware, Preis)
Beispiele für Integritätsbedingungen:
(IB1) Kein Kundenname darf mehrfach in der Relation “Kunde” vorkommen.
(IB2) Jeder Kundenname in “Auftrag” muß auch in “Kunde” vorkommen.
(IB3) Kein Kunden-Kontostand darf unter -100 DM absinken.
(IB4) Das Konto von Weiß darf überhaupt nicht überzogen werden.
(IB5) Nur solche Waren dürfen bestellt werden, für die es mindestens einen Lieferanten gibt.
(IB6) Der Brotpreis darf nicht erhöht werden.
Man unterscheidet
• statische Integritätsbedingungen: Einschränkungen der möglichen Datenbankzustände
• dynamische Integritätsbedingungen: Einschränkungen der möglichen Zustandsübergänge
sowie
• modellinhärente Integritätsbedingungen: Durch das Datenmodell vorgegeben
• explizite Integritätsbedingungen: Durch den Benutzer formuliert
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
–9–
Inhärente Integritätsbedingungen des relationalen Modells:
• Typintegrität (Domains)
Werte müssen zum Typ passen (Spezialfall: Zulässigkeit von Nullwerten). Von den Systemen
werden verschiedene primitive Datentypen unterstützt (herstellerabhängig). Benutzerdefinierte Domains sind z.B. im SQL-Standard vorgesehen und werden zunehmend unterstützt.
• Schlüsselintegrität
Die Datenbank darf keine zwei Tupel mit gleichem Schlüssel enthalten.
• Referentielle Integrität (Fremdschlüsselintegrität)
Wenn Relation R einen Schlüssel von Relation S enthält, dann muß für jedes Tupel in R auch
ein entsprechendes Tupel in S vorkommen. Beispiel: IB2.
Explizite Integritätsbedingungen
Formulierung in der Anfragesprache bzw. unter möglichst geringer Erweiterung der Anfragesprache.
Beispiel: Integritätsbedingungen in relationaler Algebra
z.B. IB2:
πKName (Auftrag) ⊆ πKName (Kunde)
z.B. IB3:
σKto < –100 (Kunde) = ∅
Der Relationenkalkül eignet sich hervorragend, da sich allgemeine Aussagen gut formulieren lassen.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 10 –
Überwachung von Integritätsbedingungen
a) durch die Anwendungsprogramme
Nachteile:
– hoher Programmieraufwand
– fehleranfällig (z.B. Inkonsistenzen zwischen verschiedenen Programmen)
– nicht unter zentraler Kontrolle (DBA und DBS)
b) durch Integritätsmonitor als Komponente des DB-Systems.
Realisierung: DB-Trigger
Nachteil: Effizienzprobleme
Formale Beschreibung von Integritätsbedingungen durch das Tripel (Auslöser, Bedingung, Aktion),
engl. ECA-Rules (Event, Condition, Action):
• Auslöser: (Wann ist die Bedingung zu prüfen?)
– nach INSERT, DELETE, UPDATE oder
– bei Abschluß einer Transaktion
• Bedingung: (die eigentliche Bedingung)
• Aktion: (Was ist bei Verletzung der Bedingung zu tun?)
– Zurückweisen der Änderung
– Zurücksetzen der Transaktion
– Automatisches Auslösen von Folgeänderungen
– Externes Programm aufrufen (z.B. ausführliche Fehlermeldung ausgeben; Datenbankadministrator durch Mail benachrichtigen; …)
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 11 –
10.4 Synchronisation (Concurrency Control)
Nach dem ACID-Prinzip “Isolation” sollen Transaktionen im logischen Einbenutzerbetrieb ablaufen,
d.h. innerhalb einer Transaktion ist ein Benutzer von den Aktivitäten anderer Benutzer nicht betroffen.
Probleme bei unkontrollierter nebenläufiger Ausführung von Transaktionen
Ist die Isolierung der Transaktionen in einem Datenbanksystem nicht sichergestellt, können verschiedene Anomalien auftreten:
• Verlorengegangene Änderungen (Lost Updates)
• Zugriff auf “schmutzige” Daten (Dirty Read, Dirty Write)
• Nicht-reproduzierbares Lesen
• Phantomproblem
Diese Anomalien werden unter anderem am Beispiel der folgenden Flugdatenbank erläutert:
Passagiere FlugNr
LH745
LH745
LH745
BA932
BA932
Fluginfo FlugNr AnzPass
LH745
3
2
BA932
Platz
Name
3A
Müller
6D
Meier
5C
Huber
Schmidt 9F
5C
Huber
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 12 –
(1) Verlorengegangene Änderungen (Lost Update)
Änderungen einer Transaktion können durch Änderungen anderer Transaktionen überschrieben werden und dadurch verloren gehen.
• Beispiel:
Zwei Transaktionen T1 und T2 führen je eine Änderung auf demselben Objekt aus:
UPDATE Fluginfo SET AnzPass = AnzPass + 1 WHERE FlugNr = ‘BA932’;
• Möglicher Ablauf:
T1
A1.i
T2
Read Fluginfo[AnzPass] —> x1
A2.j
A2.j+1
A2.j+2
Read Fluginfo[AnzPass] —> x2
x2 := x2+1
Write x2 —> Fluginfo[AnzPass]
A1.i+1 x1 := x1+1
A1.i+2 Write x1 —> Fluginfo[AnzPass]
• Ergebnis:
Beide Transaktionen haben die Anzahl der Passagiere (für denselben Flug) jeweils um eins
erhöht. Obwohl zwei Erhöhungen stattgefunden haben, ist in der Datenbank nur die Erhöhung
von T1 wirksam. Die Änderung von T2 ist verlorengegangen.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 13 –
(2) Zugriff auf “schmutzige” Daten (Dirty Read, Dirty Write)
Als “schmutzige” Daten bezeichnet man Objekte, die von einer noch nicht abgeschlossenen Transaktion geändert wurden.
• Beispiel:
— T1 erhöht das Gehalt um 500 Euro, wird aber später abgebrochen.
— T2 erhöht das Gehalt um 5% und wird erfolgreich abgeschlossen.
• Möglicher Ablauf:
T1
A1.1
T2
UPDATE Personal
SET Gehalt = Gehalt + 500;
A2.1
UPDATE Personal
SET Gehalt = Gehalt * 1.05;
COMMIT;
ROLLBACK;
• Ergebnis:
— Der Abbruch der ändernden Transaktion T1 macht die geänderten Werte ungültig, sie werden
zurückgesetzt. Die Transaktion T2 hat jedoch die geänderten Werte gelesen (Dirty Read) und
weitere Änderungen darauf aufgesetzt (Dirty Write).
— Verstoß gegen ACID: Dieser Ablauf verursacht einen dauerhaften, fehlerhaften Datenbankzustand (Consistency), bzw. T2 muß nach COMMIT zurückgesetzt werden (Durability).
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 14 –
(3) Nicht-reproduzierbares Lesen
Eine Transaktion sieht während ihrer Ausführung unterschiedliche Werte desselben Objekts.
• Beispiel:
— T1: Gib die Fluginfo für alle Flüge und nochmal die Anzahl der Passagiere für BA932 aus.
— T2: Buche den Platz 3F auf dem Flug BA932 für Passagier Meier.
• Möglicher Ablauf:
T1
A1.1
T2
SELECT * FROM Fluginfo;
A2.1
A2.2
A2.3
A1.2
INSERT INTO Passagiere (*)
VALUES (‘BA932’, ‘Meier’, ‘3F’);
UPDATE Fluginfo
SET AnzPass = AnzPass + 1
WHERE FlugNr = ‘BA932’;
COMMIT;
SELECT AnzPass FROM Fluginfo
WHERE FlugNr = ‘BA932’;
• Ergebnis:
Die Anweisungen A1.1 und A1.2 liefern ein unterschiedliches Ergebnis für den Flug BA932,
obwohl die Transaktion T1 den Datenbankzustand nicht geändert hat.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 15 –
(4) Phantomproblem
Das Phantomproblem ist ein nicht-reproduzierbares Lesen in Verbindung mit Aggregatfunktionen.
• Beispiel:
— AnzPass werde jetzt durch COUNT(*) berechnet und nicht mehr in FlugInfo gespeichert.
— T1: Drucke die Passagierliste sowie die Fluginfo für den Flug LH745.
— T2: Buche den Platz 7D auf dem Flug LH745 für Phantomas.
• Möglicher Ablauf:
T1
A1.1
T2
SELECT * FROM Passagiere
WHERE FlugNr = ‘LH745’;
A2.1
A2.2
A1.2
INSERT INTO Passagiere
VALUES (‘LH745’, ‘Phantomas’, ‘7D’);
COMMIT;
SELECT AnzPass = COUNT(*) FROM
Passagiere WHERE FlugNr = ‘LH745’;
• Ergebnis:
Für die Transaktion T1 erscheint Phantomas noch nicht auf der Passagierliste, obwohl er in der
danach ausgegebenen Anzahl der Passagiere schon berücksichtigt ist.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 16 –
Serialisierbarkeit
Eine wichtiges Konzept, um die ACID-Eigenschaft ‘Isolation’ garantieren zu können, ist die Serialisierbarkeit von Transaktionen. Das bedeutet, die nebenläufige Bearbeitung von Transaktionen geschieht für den Benutzer transparent, d.h. als ob die Transaktionen (in einer beliebigen Reihenfolge)
hintereinander ausgeführt worden wären.
Begriffe
• Ein Schedule für eine Menge {T1, …, Tn} von Transaktionen ist eine Folge von Aktionen,
die durch Mischen der Aktionen der Tis entsteht, wobei die Reihenfolge innerhalb der jeweiligen Transaktion beibehalten wird.
• Ein serieller Schedule ist ein Schedule S von {T1, …, Tn}, in dem die Aktionen der einzelnen
Transaktionen nicht untereinander verzahnt sondern in Blöcken hintereinander ausgeführt
werden.
• Ein Schedule S von {T1, …, Tn} ist serialisierbar, wenn er dieselbe Wirkung hat wie ein beliebiger serieller Schedule von {T1, …, Tn}.
Die obigen Problemfälle stellen Beispiele für nicht-serialisierbare Schedules dar. Die zentrale Konsistenzbedingung für die Ablaufsteuerung nebenläufiger Transaktionen ist:
Nur serialisierbare Schedules dürfen zugelassen werden.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 17 –
Techniken zur Synchronisation
• Pessimistische Ablaufsteuerung (Sperrverfahren, Locking)
Durch Lese- und Schreibsperren wird verhindert, daß Änderungen sich auf nebenläufige Transaktionen auswirken können.
Nachteil: Schreibende, aber auch nur-lesende Transaktionen müssen ggf. warten, bis andere
schreibende (oder auch lesende) Transaktionen abgeschlossen sind.
Vorteil: In der Regel nur wenige Rücksetzungen aufgrund von Synchronisationsproblemen nötig.
—> Standardverfahren in kommerziellen DBMS
• Optimistische Ablaufsteuerung (Zeitstempelverfahren)
Transaktionen dürfen ungehindert bis zum COMMIT arbeiten. Bei COMMIT wird geprüft, ob
ein Konflikt aufgetreten ist (Validierung). Die Transaktion wird ggf. zurückgesetzt. Die Validierung wird anhand von Zeitstempeln durchgeführt (“Gab es seit Beginn der Transaktion ein Commit einer anderen Transaktion, das dieselben Daten betrifft?”).
—> nur geeignet, falls Konflikte zwischen Schreibern sehr selten auftreten.
Nur-lesende Transaktionen können sich gegenseitig nicht beeinflussen, da Synchronisationsprobleme
nur im Zusammenhang mit Schreiboperationen auftreten. Es gibt deshalb die Möglichkeit, Transaktionen als nur-lesend zu markieren, wodurch die Synchronisation vereinfacht und ein höherer Parallelitätsgrad ermöglicht wird:
SET TRANSACTION READ-ONLY
(kein INSERT, UPDATE, DELETE)
SET TRANSACTION READ-WRITE
(alle Zugriffe möglich)
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 18 –
10.5 Datenschutz
Begriff: Schutz der Daten vor Zugriffen und Manipulation durch unberechtigte Benutzer.
Allgemeine Maßnahmen
• Identifikation des Benutzers (etwa durch Paßwort oder sogar durch Personal)
• Schutz vor physischen Angriffen (Diebstahl von Magnetbändern, Anzapfen von Datenübertragungsleitungen, etc.)
• Betriebssystem muß Zugriff auf DB-Files durch fremde Programme verhindern.
• Datenverschlüsselung
DBS-spezifische Techniken
• Sichten (Views) als Schutzmechanismus (insbesondere “read-only” Sicht). Es ergeben sich
Probleme, wenn auch Änderungen erlaubt sein sollen.
• Verwaltung von Rechten entsprechend einem Sicherheitsmodell
– Discretionary Access Control
– Mandatory Access Control
Umsetzung:
• In relationalen Systemen können Rechte vom System über eine Systemtabelle verwaltet und
innerhalb des Systems weitergegeben werden.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 19 –
Das Sicherheitsmodell DAC
Für das Modell Discretionary Access Control (DAC) werden die folgenden Informationen verwaltet:
• Wer hat das Recht? (Sicherheitssubjekte)
—> Benutzeridentifikator für einzelne Benutzer oder Menge von Benutzern
• Auf welche Teile der Datenbank bezieht sich das Recht? (Sicherheitsobjekte)
—> beschrieben durch Anfragesprache oder Datendefinitionssprache
• Worin besteht das Recht (erlaubte Operationen)?
—> Zugriffsrechte für Lesen und für Ändern (Einfügen, Entfernen, Modifizieren)
• Darf das Recht weitergegeben werden?
Grundprinzipien:
—> Jeder Benutzer hat Rechte bzgl. der von ihm erzeugten Objekte.
—> Datenbankadministrator (DBA) hat alle Rechte.
Bewertung:
• Einfaches und sehr gebräuchliches Modell
• Erzeuger von Daten sind mit der Verantwortung für deren Sicherheit belastet.
• Abhängig von der Granularität der Objekte (Datenbank, Relationen, Tupel) kann die Verwaltung der Rechte sehr aufwendig werden.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04
– 20 –
Das Sicherheitsmodell MAC
Beim Modell Mandatory Access Control (MAC) werden Subjekte und Objekte mit einer Sicherheitseinstufung markiert (z.B. ‘streng geheim’, ‘geheim’, ‘vertraulich’, ‘unklassifiziert’):
• Vertrauenswürdigkeit (‘Clearance’) eines Subjektes s: clear(s)
• Sensitivität (‘Classification’) eines Objektes o: class(o)
Für die Zugriffskontrolle werden die folgenden Regeln verwendet:
• Ein Subjekt s darf ein Objekt o nur lesen, wenn das Objekt eine geringere Sicherheitseinstufung besitzt: class(o) ≤ clear(s)
• Beim Ändern muß ein Objekt o mindestens die Einstufung des schreibenden Subjektes s erhalten: clear(s) ≤ class(o)
Die zweite Regel kontrolliert den Informationsfluß, um den Mißbrauch durch autorisierte Benutzer zu
verhindern. Eine ‘streng geheime’ Information könnte sonst durch einen berechtigten Benutzer öffentlich zugänglich gemacht werden (Write-Down).
Bewertung
• Potentiell größere Sicherheit durch abgestufte Sicherheitsklassen
• Jedes Objekt wird einzeln eingestuft —> hoher Verwaltungsaufwand in der Datenbank.
• Benutzer mit unterschiedlicher Einstufung können nur schwer zusammenarbeiten, da von
höher eingestuften Benutzern veränderte Daten von niedriger eingestuften Kollegen nicht
mehr lesbar sind.
Universität München, Institut für Informatik
Skript Datenbanksysteme I WS 2003/04