Datenmanagement 60 5 Datenschutz und Datensicherheit 5.1 Datenschutz Wer wird hier geschützt? Personen Ein anderer Begriff für Datenschutz ist Zugriffskontrolle. Datenschutz soll sicherstellen, dass alle Informationen in einer Datenbank nur von den berechtigten Benutzern in der jeweils für sie zulässigen Form gelesen bzw. geändert und nur auf den vorgesehenen Wegen transportiert und weiterverarbeitet werden. D. h. Ziel ist die Einhaltung der gesetzlichen Datenschutzbestimmungen anwendungsspezifischen Geheimhaltungsvorschriften. Im Bereich Datenschutz sind folgende Begriffe von Bedeutung: Identifikation: Darunter versteht man die Anmeldung eines Benutzers beim System unter Angabe einer Benutzererkennung. Authentisierung: Dies bezeichnet den Prüfvorgang durch das System, mit dem sichergestellt werden soll, dass ein Benutzer, der sich mit einer bestimmten Kennung anmeldet, auch tatsächlich der zur Führung dieser Kennung Berechtigte ist. Autorisierung: Damit bezeichnet man den Akt der Vergabe von Zugriffsrechten (oder allgemeiner: Nutzungsrechten) an einen Benutzer. Der autorisierende Benutzer muss selbstverständlich die Rechte, die er weitergibt, ebenso besitzen wie das Recht zu ihrer Weitergabe. 5.2 Datensicherheit Wer wird geschützt? Daten Der Bereich Datensicherheit lässt sich weiter in die drei Teilbereiche Datensicherung, Synchronisation und Integrität gliedern.
Datenmanagement 61 5.2.1 Datensicherung Überspielen der Daten auf einen anderen (externen) Datenträger am Ende einer Sitzung (z.b. Tag); d. h. die Daten werden zusätzlich an einem anderen Ort gehalten. Schutz der Datenbank vor Verlust von Daten durch technische und menschliche Fehler. Z. B. kann ein Log-File geführt werden, das alle Veränderungen der Datenbank protokolliert. Tritt tatsächlich ein technischer oder anderer Fehler auf, so dient das Log-File dazu, den Zustand bis möglichst kurz vor dem Systemabsturz zu rekonstruieren. D.h. der Verlust von schon abgeschlossenen, aber noch nicht gesicherten Vorgängen soll möglichst gering gehalten werden. 5.2.2 Synchronisation Die Synchronisation soll Fehler durch sich gegenseitig störende Zugriffe mehrerer Benutzer auf ein Datenobjekt verhindern. Beispiel: Umbuchung bei einer Bank z.b. von einem Konto A bei einer Bank zu einem anderen Konto B derselben Bank. Es stellt sich die Frage, welche Schritte während des Umbuchungsprozesses eine Transaktion darstellen. Lese Konto A in a1 a1 := a1-100 Schreibe a1 in Konto A Lese Konto B in b1 b1 := b1 + 100 Schreibe b1 in Konto B Was ist eine Transaktion? 1. Jeder kleinste Teilschritt ist eine Transaktion: Diese Definition ist nicht sinnvoll, da sich die Datenbank nach den Teilschritten in einem inkonsistenten Zustand befinden kann, was vermieden werden sollte. 2. Der gesamte Umbuchungsvorgang ist eine Transaktion. Erfolgt jetzt während der Umbuchung ein Systemabsturz, so kann die Datenbank in ihren ursprünglichen, konsistenten Zustand zurückgeführt werden. Eine Transaktion ist die Überführung einer Datenbank von einem in einen anderen konsistenten Zustand.
Datenmanagement 62 Eine Transaktion ist eine vom Benutzer definierte Folge von Aktionen, also eine "elementare Arbeitseinheit" mit folgenden Eigenschaften (ACID): 1. Atomicity (Unteilbarkeit einer Transaktion -> eine Transaktion wird entweder ganz oder gar nicht wirksam; Verantwortung: DBMS) 2. Consistency (vor Beginn und nach Abschluss der Transaktion befindet sich die Datenbank in einem konsistenten Zustand; die Verantwortung für die Konsistenzerhaltung liegt beim Benutzer) 3. Isolation (Die Effekte einer Transaktion werden für andere Transaktionen erst nach erfolgreicher Beendigung der Transaktion sichtbar; andernfalls können die anderen Transaktionen inkonsistente Zwischenzustände sehen; Verantwortung: DBMS) 4. Durability (nach erfolgreicher Ausführung einer Transaktion müssen die Wirkungen dieser Transaktion erhalten bleiben. Es ist dann keine automatische Rücksetzung mehr möglich; Verantwortung: DBMS) 5. endliche Ausführungszeit (jede Transaktion besteht aus endlich vielen Aktionen; d.h. eine Transaktion sollte keine Endlosschleife enthalten. Verantwortung: Benutzer. Für die technische Kontrolle der Ausführungszeit ist jedoch das DBMS verantwortlich.) Festlegung: Ein Datenbanksystem kann daher auch als Transaktionssystem bezeichnet werden. Problem: synchrone (parallele) Verarbeitung mehrerer Transaktionen Schwierigkeiten treten auf, wenn mehrere Transaktionen auf denselben Datensatz zugreifen. Beispiel 1 (Lost Update): Objekt: A; Beide Transaktionen wollen a um 10 erhöhen, a habe einen Wert von 20.
Datenmanagement 63 read a1<-a a1 = 20 read a2<-a a2 = 20 a1 := a1+10 a1 = 30 write a1->a A = 30 a2 := a2+10 a2 = 30 write a2->a A = 30 Auswertung: a hat jetzt den Wert 30. Bei einzelnen Betrachtungen der Transaktionen hat es den Anschein, als wären sie korrekt durchgeführt worden. Bei Betrachtung beider Transaktionen ergibt sich ein Fehler (a hätte 40 betragen müssen, die Auswirkung einer Transaktion ging verloren), der nicht genau lokalisiert werden kann und nur schwer für den einzelnen Benutzer, der nur seine Transaktion isoliert sieht, zu erkennen ist. Dies wird Lost Update genannt. Ein Problem des Lost Update ist, dass er nicht zu einem inkonsistenten Zustand der Datenbank führen muss und daher bei Überprüfung der Konsistenzbedingungen der Datenbank nicht unbedingt entdeckt wird. Er sollte deshalb von vornherein durch geeignete Mechanismen vermieden werden. Beispiel 2 (inkonsistente Sicht): Integritätsbedingung: A + B = 0 Ziel: Umbuchung von 1,-- read a1<-a a1 = 0 a1 := a1 1 a1 = -1 write a1->a A = -1 read b1<-b b1 = 0 b1 := b1 + 1 b1 = 1 write b1->b B = 1 read a2<-a a2 = -1 read b2<-b b2 = 1 Wird die Transaktion 2 zum Zeitpunkt ausgeführt, d.h. während die Transaktion 1 noch läuft, so erhält sie eine inkonsistente Sicht auf die Werte A und B. Die Transaktion 2 hat eine inkonsistente Sicht.
Datenmanagement 64 Weitere Anomalien, die bei beliebiger paralleler Abarbeitung von Transaktionen entstehen können, sind: Nichtwiederholbares Lesen Verwendet eine Transaktion ein Objekt aus der Datenbank mehrfach, ohne dass eine interne Kopie gehalten wird, so ist ein mehrfaches Lesen dieses Objekts aus der Datenbank notwendig. Arbeitet eine andere Transaktion parallel auf diesem Objekt, so können bei mehrfachem Lesen unterschiedliche Werte berücksichtigt werden. Lesen ungesicherter Werte: Der Wert eines Objekts, das in die Datenbank geschrieben wurde, ist solange ungesichert, bis die schreibende Transaktion beendet wird, da der Wert im Fall eines Rollbacks ungültig werden kann. Wird ein ungesicherter Wert von einer anderen Transaktion gelesen, so kann die Integrität der Datenbank verloren gehen. Phantome: Liest eine Transaktion eine Liste von Objekten mehrfach und schreibt eine andere Transaktion zwischen zwei Lesevorgängen weitere Objekte in diese Liste, so spricht man von Phantomen. Objekte tauchen aus der Sicht der ersten Transaktion aus dem Nichts auf. Beispiel: Ein Benutzer eröffnet eine Transaktion t1 und liest alle Angestelltensätze, um herauszufinden, wie viele Angestellte in Berlin wohnen. Danach beschließt er, dieselben Daten noch einmal zu durchsuchen, um festzustellen, welche Angestellten in Berlin-Mitte wohnen. Nach dem ersten Suchvorgang könnte eine Transaktion t2 einen Angestellten einfügen, der in Berlin-Mitte wohnt. Der Benutzer sieht diesen Angestellten im ersten Durchgang nicht, wohl aber im zweiten. Damit ist für den Benutzer der Grundsatz verletzt, dass er ungestört von allen anderen Benutzern mit der Datenbank arbeiten können muss. Es werden Kriterien benötigt, deren Einhaltung garantiert, dass die synchrone Verarbeitung von Transaktionen nicht zu Fehlern in der Datenbank führt.
Datenmanagement 65 Serialisierbarkeit Eine Menge von Ausführungen von Transaktionen führt immer zu einem konsistenten Zustand der Datenbank, wenn alle Transaktionen "der Reihe nach" (seriell) abgearbeitet werden. Die Reihenfolge der Transaktionen ist dabei egal. Würde das Datenmanagement nur jeweils die Ausführung einer Transaktion gleichzeitig zulassen, so wäre damit die Konsistenz der Datenbank gewährleistet. Diese Einschränkung durch das DBMS führt jedoch zu einer geringen Effizienz des Datenbanksystems, da auch Transaktionen, die überhaupt nicht auf gemeinsame Teile der Datenbank zugreifen, nicht parallel ausgeführt werden dürfen. Das DBMS soll einen möglichst hohen Grad an paralleler Abarbeitung von Transaktionen zulassen, ohne dass Fehler in der Datenbank auftreten. Dies ist immer dann der Fall, wenn die Wirkung der parallel ausgeführten Transaktionen der Wirkung irgendeiner seriellen Ausführung der gleichen Transaktionen entspricht. Das System paralleler Transaktionen heißt dann serialisierbar. Definition: Ein paralleles System von Transaktionen ist dann korrekt synchronisiert, wenn es serialisierbar ist, d.h. wenn es mindestens eine (gedachte) serielle Ausführung derselben Transaktionen gibt, die 1. denselben Datenbankzustand und 2. dieselben Ausgabedaten der Transaktionen liefert. Wie kann Serialisierbarkeit erreicht werden? Zur Gewährleistung der Serialisierbarkeit eines Systems paralleler Transaktionen werden Synchronisationsverfahren angewendet. Man unterscheidet zwei Arten solcher Verfahren: 1. Verifizierende Verfahren: Zu bestimmten Zeitpunkten wird getestet, ob die Serialisierbarkeit noch gegeben ist. Liegt eine Verletzung der Serialisierbarkeit vor, so wird eine geeignete Transaktion zurückgesetzt und neu gestartet. 2. Präventive Verfahren: Es wird verhindert, dass nicht-serialisierbare Folgen von Transaktionsausführungen überhaupt entstehen. In diese Kategorie fallen alle bislang praktisch angewandten Verfahren, insbesondere die Sperrverfahren.
Datenmanagement 66 Sperrverfahren Die Synchronisation eines Systems paralleler Transaktionen kann geschehen, indem jede Transaktion die Objekte in der Datenbank sperrt, die für ihre Abarbeitung benötigt werden. Möchte eine Transaktion ein Objekt nur lesen, so kann sie eine sog. Lesesperre (RLOCK) für das entsprechende Objekt anfordern. Auf einem Objekt dürfen gleichzeitig beliebig viele Lesesperren gesetzt sein. Soll das Objekt auch verändert werden, so ist eine exklusive Sperre (oder auch Schreibsperre (WLOCK)) anzufordern. Alternativ kann eine Lesesperre in eine Schreibsperre umgewandelt werden, sofern keine weitere Lesesperre auf diesem Objekt gesetzt ist. Bei der Anforderung von Sperren sind bestimmte Protokolle zu beachten, da durch den Gebrauch von Sperren alleine keine Serialisierbarkeit garantiert wird: Beispiel: read a1<-a a1 = 1 a1 = a1 + 1 a1 = 2 write a1->a A = 2 read b1<-b b1 = 1 b1 = a1 b1 = 2 write b1->b B = 2 read b2<-b b2 = 2 b2 = b2 + 2 b2 = 4 write b2->b B = 4 read a2<-a a2 = 2 a2 = b2 a2 = 4 write a2->a A = 4 Haben A und B vor der Ausführung von t1 und t2 beide den Wert 1, so führt sowohl die Hintereinanderausführung t1->t2 als auch die Hintereinanderausführung t2->t1 zu dem Endwert 4 für A und B. Eine parallele Ausführung von t1 und t2 ist somit nur dann korrekt, wenn sie ebenfalls zu dem Wert 4 für die Objekte A und B führt: wlock A wlock B read a1<-a a1 = 1 read b2<-b b1 = 1 a1 = a1 + 1 a1 = 2 b2 = b2 + 2 b2 = 3 write a1->a A = 2 write b2->b B = 3 unlock A unlock B wlock B wlock A read b1<-b b1 = 3 read a2<-a a2 = 2 b1 = a1 b1 = 2 a2 = b2 a2 = 3
Datenmanagement 67 write b1->b B = 2 write a2->a A = 3 unlock B unlock A Die Datenbank hat nach dieser parallelen Ausführung den Wert 3 für A und den Wert 2 für B. Es gibt keinen äquivalenten seriellen Ablauf von t1 und t2, obwohl Sperren verwendet wurden. Das Zwei-Phasen-Protokoll Das Zwei-Phasen-Protokoll ist ein Sperrprotokoll, das Serialisierbarkeit garantiert. Das Protokoll fordert, dass die Anforderung und die Freigabe von Sperren durch eine Transaktion in zwei getrennten Phasen erfolgt. Nachdem eine Transaktion eine Sperre freigegeben hat, darf sie keine weiteren Sperren mehr anfordern. Vorheriges Beispiel mit Zwei-Phasen-Protokoll: rlock A rlock B read a1<-a a1 = 1 read b2<-b b1 = 1 a1 = a1 + 1 a1 = 2 b2 = b2 + 2 b2 = 3 wlock A wlock B write a1->a A = 2 write b2->b B = 3 Rlock B: Muss warten, da B gesperrt rlock A: Muss warten, da A gesperrt DEADLOCK t1 und t2 befinden sich in einem Deadlock, da beide Transaktionen auf die Freigabe einer Sperre warten, die durch die jeweils andere Transaktion gehalten wird. Die Deadlock-Situation wird durch das DBMS erkannt und aufgehoben, indem eine der beiden Transaktionen (z.b. t2) zurückgesetzt wird. rollback: Wird zurückgesetzt. B ist frei und wird wieder auf den Wert 1 gesetzt. B = 1 read b1<-b (rlock B durch blieb bestehen) b1 = 1 Siehe Hinweis b1 = a1 b1 = 2 Wlock B rlock B: Neustart von t2; t2 muss auf Freigabe von B warten Write b1->b B = 2 unlock B: B ist frei; t2 kann weiterarbeiten.
Datenmanagement 68 unlock A: t1 ist fertig. read b2<-b b2 = 2 b2 = b2 + 2 b2 = 4 wlock B write b2->b B = 4 rlock A read a2<-a a2 = 2 a2 = b2 a2 = 4 wlock A write a2->a A = 4 unlock A unlock B A und B haben beide den Wert 4. Der parallele Ablauf von t1 und t2 ist somit serialisierbar. Würde an dieser Stelle die Transaktion t2 mit einem rlock B erneut gestartet werden, dann käme es zu einem späteren Zeitpunkt zu einem erneuten Deadlock. Dieser müsste dann ebenfalls durch rollback aufgelöst werden. Daher wurde in diesem Beispiel der Neustart von t2 verzögert. Es gibt zwei besondere Formen des Zwei-Phasen-Protokolls: Beim Preclaiming müssen zu Beginn einer Transaktion vor der eigentlichen Verarbeitung alle gewünschten Sperren angefordert werden. Dies hat den Vorteil, dass jede Transaktion, die in die Verarbeitungsphase kommt, Sperren für alle zur Verarbeitung notwendigen Objekte besitzt. Die Transaktion kann somit nicht mehr an einem Deadlock beteiligt sein. Tritt der Deadlock bereits vor der Verarbeitung beim Anfordern der Sperren auf, so ist das Zurücksetzen der Transaktion problemlos möglich, da sie noch keine Objekte in der Datenbank verändert hat. Preclaiming ist nur dann möglich, wenn schon vor Beginn der Verarbeitung alle an der Verarbeitung beteiligten Objekte bekannt sind. Weiterhin schränkt Preclaiming die mögliche Parallelität bei der Abarbeitung von Transaktionen ein, da Sperren länger als notwendig gesetzt sind. Beim Sperren bis EOT (End of Transaction) werden alle Sperren bis zum Ende einer Transaktion gehalten. Dies hat den Vorteil, dass keine andere Transaktion Werte gelesen haben kann, wenn eine Transaktion zurückgesetzt werden muss. Durch Sperren bis EOT wird der mögliche Parallelitätsgrad bei der Ausführung von Transaktionen eingeschränkt, da Sperren länger als notwendig gehalten werden. Ein Deadlock kann durch Sperren bis EOT nicht verhindert werden.