3.1 Einführung:
Dieser Abschnitt gibt eine Einführung in die grundlegenden Sicherheitsaspekte einer Datenbank. Dabei wird unter anderem ein kurzer Überblick über die absichtliche Schädigung und Enthüllug von sensitiven Daten, Kategorien von Schutzmechanismen, sowie die Zugriffskontrolle in SQL behandelt.
Eine detailliertere Beschreibung, sowie Sicherheitsstrategien wird in einem der kommenden Vorträge „sichere Betriebssysteme, sichere Datenbanksysteme“ behandelt. Im folgenden werden die einzelnen Sicherheitskategorien und einige Sicherheitsstrategien („Policies“) kurz beschrieben:
Identifikation und Authentisierung:
Wie bereits ausführlichst in anderen Vorträgen und Ausarbeitungen erläutert, muss sich der Benutzer um sich Zugang zu einem Datenbanksystem zu schaffen, zunächst einmal identifizieren. Dies kann beispielsweise durch Eingabe des Benutzernamens erfolgen. Die Authentisierung überprüft daraufhin, ob es sich bei den Benutzern auch wirklich um die Person handelt, für die sie sich ausgibt. Normalerweise werden hierzu Paßwörter verwendet.
Autorisierung und Zugriffskontrolle:
Eine Autorisierung besteht aus Regeln, die die erlaubten Arten des Zugriffs auf Sicherheitsobjekte durch Sicherheitssubjekte definieren. Ein Sicherheitsobjekt ist eine passive Entität, die Informationen beinhaltet, wie z.B. ein Tupel oder ein Attribut. Ein Sicherheitssubjekt ist eine aktive Entität, die einen Informationsfluß bewirkt.
Sicherheitssubjekte können Benutzer, Gruppen, Datenbankprozesse bzw.
Anwendungsprogramme sein.
Die Autorisierung stellt sicher, dass alle direkten Zugriffe zu den System Objekten gemäss der Privilegien und deren Zugriffsrichtlinien erfolgen. Man unterscheidet hierbei zwischen
„Mandatory- “ und „Discretionary Access Control“ (kurz: MAC, DAC). Die
„Discretionary“ Zugriffsrichtlinien spezifizieren die Benutzerrechte auf unterschiedliche Systemressourcen und beinhalten ausserdem die Möglichkeit eines Benutzers, seine Rechte weiter zu geben. Man spricht von der „Mandatory“ Zugriffskontrolle, wenn Objekten des Systems sogenannte Sicherheitsmarken („security labels“) zugewiesen
werden, die einen Zugriff einschränken können. Letztere findet in Multi- Level Datenbanken Verwendung. Näheres dazu in Vortrag 9.
Zuverlässigkeit und Auditing:
Dienen dazu über alle Zugriffe einer Datenbank Buch zu führen, um deren physische Integrität zu wahren, und eine Analyse des Zugriffsprofils durchführen zu können.
Schäden können somit rechtzeitig erkannt und beseitigt werden.
Inferenz:
Bezeichnet das sich Erschliessen von Daten, aufgrund von öffentlicher Informationsverbreitung. Dieses Wissen über Daten muss nicht unbedingt aus einer Datenbank stammen. Die Inferenz Richtlinie legt somit fest, wie man klassifizierte Informationen vor der Enthüllung oder Verbreitung schützt, falls diese indirekt veröffentlicht werden.
Konsistenz:
Sie umfasst die betriebliche, semantische, und physische Integrität einer Datenbank und bestimmt, ob sich diese in einem gültigen bzw. korrekten Zustand befindet.
Die betriebliche Integrität gewährleistet die logische Konsistenz der Daten in einer Datenbank während der Ausführung verteilter Transaktionen. Die semantische Integrität beschreibt die logische Konsistenz von veränderten Daten, indem sie mit Hilfe von Kontrolldatenwerten die inhaltliche Vollständigkeit und Fehlerfreiheit sicherstellt. Die physische Integrität zielt darauf, die Datenbank immun oder reparierbar gegen physische Bedrohungen, z.B. Stromausfälle, zu machen.
Abbildung 8 : „Späßle“
Um seine Daten zu schützen, d.h. gegen unbefugten Zugriff abzusichern, müssen die Schwachstellen eines Systems bekannt sein und konsequent versucht werden, diese auszumerzen. Folgende Angriffspunkte sind vorstellbar:
Mißbrauch von Autorität:
Diebstahl, Veränderung oder Zerstörung von Daten oder Programmen.
Inferenz und Aggregation:
Inferenz siehe oben. Unter Aggregation versteht man, dass einzelne Daten öffentlich zugänglich und nicht sicherheitsrelevant sind. Eine Vielzahl von Daten zusammen genommen unter Umständen aber schon. Ein Beispiel für Inferenz ist der Informationsgewinn der Note eines Studenten, falls diese zusammen mit der Matrikelnummer veröffentlicht ist, und der Name des betroffenen Studenten beispielsweise zusammen mit seiner Matrikelnummer auf einer beliebigen Liste (z.B.:
Anwesenheitsliste, Matrikelnummer mit Unterschrift) erfaßt ist. Ein Angriffspunkt mittels Aggregation beschreibt beispielsweise den Informationsschluß über den statistischen
Alkoholgenuß einer einzelnen Person durch häufige Beobachtung des Trinkverhaltens die ser Person. Man bezeichnet dies als Aggregation, und nicht als Inferenz, da die Beobachtung eines einzelnen Zeitpunktes, an dem die Person Alkohol drinkt, nicht den Schluß zuläßt, daß ein Alkoholproblem vorliegt. Prost!
Maskierung:
Unautorisierter Zugriff auf Daten durch eine Person, die sich als ein autorisierter Benutzer ausgibt. Dabei erfolgt eine Umgehung der Zugriffskontrolle. Dies ist durch ausspionieren eines Passwortes möglich, oder die Ausnutzung von Sicherheitslücken im Betriebssystemcode oder in Anwendungsprogrammen.
Browsing:
Sicherheitsrelevante Informationen können zum Teil in Dateinamen oder Verzeichnisstrukturen enthalten sein. Dies bietet dem Angreifer weiterhin die Möglichkeit, seine Angriffe gezielt durchzuführen.
Trojanische Pferde & Versteckte Kanäle:
Wurden bereits in vergangenen Vorträgen erörtert.
3.2 Zugriffskontrolle in SQL
Im SQL-92 Standard existieren zwei Befehle zur Zugriffskontrolle. Einer um Rechte zu vergeben (grant), und einer um Rechte zu entziehen (revoke). Normen für Authe ntisierung und Protokollierung werden nicht aufgestellt. Diese erwähnten Befehle sind in das oben beschriebene DAC-Modell einzuordnen. Die Untestützung von MAC findet aber trotzdem Verwendung in kommerziellen Datenbanksystemen. Wir verweisen dazu auf den nachfolgenden Vortrag „Implementierungen“.
Beispiel (grant, revoke):
• grant select on employee to username;
• revoke select on employee from username cascade;
Die Verwaltung einer Datenbank ist dem DB- Administrator überlassen. Mit einer speziellen Systemkennung hat er Zugriff auf alle Daten und Funktionen der Datenbank.
Somit ist er auch verantwortlich für die Zugriffskontrolle bzw. Rechtevergabe. Da der DB- Administrator praktisch über alle Rechte einer Datenbank verfügt, kann ein Missbrauch seinerseits etwa über eine Protokollierung seiner Aktivitäten erfolgen, oder eine Überwachung durch eine gleichwertige oder höhere Instanz, sofern der Datenbankadministrator dem Systemadministrator bzgl. der Benutzerrechte untergestellt ist. Modelle hierzu wurden bereits in vorherigen Vorträgen erläutert.
Identifikation und Authentisierung:
Das Konzept der Identifikation und Authentisierung wurde bereits ausgiebig beschrieben.
Ein Benutzer identifiziert sich über einen Login und authentifiziert sich über sein Passwort.
Beispiel (Benutzer hinzufügen):
• create user username identified externally;
Autorisierung und Zugriffskontrolle:
Eine Autorisierung erfolgt mit dem grant-Kommando. Außer select existieren in SQL noch die Standardprivilegien delete, insert, update und references. Mit der Autorisierung über die Rechte insert, update und references ist es Möglich den Zugriff auf bestimmte Attribute einer Relation zu gewährleisen und/ oder einzuschränken. Das references-Privileg erlaubt Benutzern, Fremdschlüssel auf ein bestimmtes Attribut anzulegen. Somit kann ein Benutzer, aufgrund der referentiellen Integrität, daran gehindert werden, Datentupel aus einer Relation zu entfernen.
Sichten:
Mit Hilfe von Sichten ist man in der Lage, Daten vor nicht autorisierten Benutzern zu verschleiern. Dies geschieht, indem man auf eine Relation eine Sicht mit einer bestimmten Bedingung erzeugt. Man stelle sich beispielsweise eine Firma vor, in der nur Mitarbeiter einer Abteilung Zugriff auf öffentliche Daten von Mitarbeiter derselben Abteilung haben:
Beispiel:
• create view employee123 as select * from employee where department=123;
Weiterhin können aggregierte Sichten zur Informationsenthaltung nicht autorisierter Benutzer dienen, da sie keine exakten Datentupel, sondern statistische (aggregierte) Daten enthalten. Es ist aber hierbei auf den Informationsgehalt zu achten, da ansonsten wieder die Gefahr von Inferenz (siehe oben) besteht.
Auditing:
Der SQL-92 Standard beinhaltet keine Protokollierbefehle eines Datenbanksystems. In IBM-DB2 jedoch, wie auch in den meisten anderen DBS, wird der Befehl audit zur Protokollierung verwendet. Es können beispielsweise fehlgeschlagende Zugriffe protokolliert werden, um den eventuellen Angriff nachzuverfolgen.
Beispiel:
• db2audit configure scope objmaint, secmaint status failure (Protokollierung aller fehlgeschlagenen Operationen)
Nicht zu vernachlässigen ist der mit dem Auditing verbundene Zusatzaufwand für das Datenbanksystem. Deshalb sollte man sich genau überlegen, welche Protokolldaten überhaupt notwendig oder von Interesse sind.