Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung
unter dem Förderkennzeichen 16OH21005 gefördert.
Die Verantwortung für den Inhalt dieser Veröffentlichung liegt
beim Autor/bei der Autorin.
In diesem Abschnitt wollen wir uns näher mit dem Thema Datenschutz und Datensicherheit auseinander setzen.
Zum Einen sind hier natürlich die gesetzlichen Regelungen und Bestimmungen wichtig. Zum Anderen ist es auch wichtig mit den technischen Möglichkeiten wie Authentifizierung und Autorisierung vertraut zu machen.
Ein weiterer wichtiger Aspekt ist auch die Nachvollziehbarkeit von Änderungen einer Datenbank. Hierzu ist es notwendig, sich mit den Protokollierungs- und Audit- Möglichkeiten der Datenbanksystem zu beschäftigen.
Zunächst wollen wir klären, was unter Datenschutz zu verstehen ist.
Im allgemeinen wird hier die Schutzwürdigkeit von personenbezogenen Daten verstanden. Hierunter fallen folgende Aspekte:
• Die Speicherung von personenbezogenen Daten
• Die Auswertung und Verarbeitung der personenbezogenen Daten
• Die Weitergabe und Nutzung von personenbezogenen Daten
Zunächst ist nun zu klären, was dies genau bedeutet.
Um einen Missbrauch der personenbezogenen Daten bzgl.
• Der Speicherung
• Der Auswertung und Verarbeitung
• Der Weitergabe und Nutzung
zu verhindern sind folgende Fragen zu klären:
1. Wer hat / darf überhaupt Zugriff auf die Daten haben?
2. Was sind die personenbezogenen Daten genau? Um welche Daten geht es also?
Um diese Fragen zu klären, schauen wir uns zunächst die gesetzlichen Regelungen und Bestimmungen an.
Die gesetzlichen Regelungen und Bestimmungen sind in dem
Bundesdatenschutz-Gesetzt (BSDG) festgelegt. Erstmalig wurde das Gesetzt 1990 verabschiedet.
Darüber hinaus gilt auch das europäische Gesetz EG 195196.
Auf der Webseite des Bundesministeriums der Justiz und Verbraucherschutz (link siehe unten) finden Sie die entsprechenden gesetzlichen Bestimmungen.
Als nächstes wollen wir nun klären, für wen die gesetzlichen Bestimmungen wichtig sind.
Siehe auch:
• http://www.gesetze-im-internet.de/bdsg_1990/index.html
Die gesetzlichen Regelungen sind zum einen wichtig für alle öffentlichen Einrichtungen und Behörden.
Die gesetzlichen Regelungen gelten aber auch für private Einrichtungen bzw.
Nicht-öffentlichen Einrichtungen wie zum Beispiel Firmen.
Also alle, die Umgang mit personenbezogenen Daten haben.
Im Fokus des Datenschutzes sind also die schutzwürdigen Belange.
Welche technischen Maßnahmen möglich sind, um diese schutzwürdigen Belange (Datenschutz) einzuhalten, fallen unter das Thema Datensicherheit.
Daher gilt es nun zu klären, was genau mit Datensicherheit im Kontext der Datenbanken gemeint ist bzw. was Datensicherheit mit Datenbanken zu tun hat.
Um zu klären, was Datenbanken mit Datensicherheit zu tun hat, schauen wir uns zunächst an, welche Art von Daten in der Datenbank abgelegt werden.
In vielen Datenbanken werden zum Beispiel folgende Arten von Daten gespeichert:
• Allgemeine Informationen über Personen, wie Adresse, Alter, E-Mail Adressen etc.
• Finanzdaten wie zum Beispiel Gehälter, Kontonummern, Kreditdaten etc.
• Gesundheitsdaten wie zum Beispiel Rezepte, Therapien, Krankheiten etc.
Dies sind nur einige wenige Beispiel, die zeigen, das in einer Datenbank sehr oft personenbezogene Daten abgelegt und auch verarbeitet werden.
Somit ist aus Sicht der Datensicherheit zu klären, welche Maßnahmen es gibt, um sich gegen einen unerlaubten Zugriff und einen Missbrauch der Daten, die in einer Datenbank gelegt sind, zu schützen.
Schauen wir uns daher nun die Maßnahmen genauer an.
Man kann die Maßnahmen in drei große Themenbereiche einteilen.
Physikalische Maßnahmen
Unter den physikalischen Maßnahmen fallen alle Regelungen, die den physikalischen Zugang und das Abhören von Daten verhindern sollen.
IT-Schutzmaßnahmen
Hierunter fallen alle allgemeine Maßnahmen, die unerlaubte Nutzung der Daten verhindern soll. Dazu gehören auch Maßnahmen, die festlegen, dass sich jeder, einer Identifikationskontrolle unterzieht. Auch Maßnahmen, die getroffen werden, um nachvollziehen zu können, wer, wann, welche Daten verwendet hat (Aufzeichnung).
Kryptographische Maßnahmen Hierunter fallen Maßnahmen wie:
• Verschlüsselung der Daten, damit Unbefugte die Daten nicht auswerten können
• Protokolle, um Daten sicher übertragen zu können
• Digitale Signaturen
• das Verhindern, dass Daten anonym verarbeitet werden können
• Aber auch Maßnahmen, die garantieren, dass Daten anonym verarbeitet werden können Somit stellt sich nun die Frage, welche Maßnahmen im Zusammenhang mit der
Datenbank wichtig sind. Dieser Frage wollen wir als nächstes nachgehen.
Aus Sicht der Datenbanken, sind die, in der Abbildung blau gekennzeichneten Punkte von Bedeutung.
Da sind zum einen die IT-Schutzmaßnahmen wie:
• Erlaubnis zur Nutzung Autorisierung
• Identifikationskontrolle Authentifizierung
• Aufzeichnungen Logging und Auditing
Darüber hinaus sind auch kryptographische Maßnahmen wichtig, um eine sichere Datenübertragung zu gewährleisten. Hierbei sind die Protokolle wichtig, um auf Datenbanken zugreifen zu können, die sich auf einem anderen Rechner innerhalb eines Netzwerkes befinden.
Welche Maßnahmen dies nun im einzelnen sind, wollen wir uns als nächstes ansehen.
Wie bei der vorherigen Abbildung bereits beschrieben, handelt es sich bei den IT-Schutzmaßnahmen im einzelnen um:
• Autorisierung .. Wer darf auf welche Daten innerhalb der Datenbank zugreifen
• Authentifizierung .. Ist die Person auch genau die Person , als die sie sich ausgibt
• Auditing .. Aufzeichnen, wer welche Änderungen in der Datenbank vorgenommen hat
Bei den kryptographischen Maßnahmen handelt es sich in der Praxis um Datenübertragungsprotokolle, um gesichert auf Datenbanken zugreifen zu können. Das Wichtigste dabei ist, dass die Daten nicht von Dritten mitgelesen werden können.
In der Praxis wird daher bei der Kommunikation mit einer Datenbank innerhalb eines Netzwerkes auf die Kommunikation via Secure Socket Layer (SSL) zurückgegriffen.
Als nächstes wollen wir uns mit den einzelnen Themenbereichen näher beschäftigen.
Die Authentifizierung bei den Datenbanken erfolgt in der Regel mittels User- Name und Password.
Hierzu bieten die Datenbanksysteme ein eigenes Authentifizierungsverfahren an.
Wie wir im Abschnitt SQL-DCL bereits gesehen haben, bietet SQL die
Möglichkeit einzelne User via CREATE USER anzulegen und auch wieder zu löschen.
Zusätzlich bieten Datenbanksysteme wie zum Beispiel Microsoft SQL-Server auch die Möglichkeit eines sogenannten Single-Sign-On (SSO) Verfahrens. Dies bedeutet, dass sich ein User nur einmal authentifizieren muss, und hat dann Zugang zu einer Menge von Anwendungen ( hier eben die Datenbank).
Siehe auch:
• Was ist SSO : http://searchsecurity.techtarget.com/definition/single-sign-on
Schauen wir uns zur Verdeutlichung einmal ein typisches Authentifizierungs- Szenario an.
Bei diesem Szenario gehen wir davon aus, dass ein Anwender sich auf einem System einloggt und dort einen SQL-Interpreter ( z.B. SQL Server sql_cmd) startet.
Schritt1:
Ein Anwender meldet sich an einem System an ( Login) mit dem Namen X und einem Password.
Schritt 2:
Der Anwender startet den SQL-Interpreter. Hierbei gibt er an, mit welcher Datenbank er sich verbinden möchte. Zusätzlich muss er auch angeben, mit welchem Benutzer er sich anmelden möchte. In unserem Beispiel ist der User- Name Y. Der User Name für das Anmelden bei dem Datenbanksystem ist also nicht der gleiche Name, mit dem sich der Anwender in das System eingeloggt hat.
Schritt 3:
Der SQL-Interpreter meldet sich bei dem Datenbanksystem an und übergibt den
Benutzernamen Y und das entsprechende Passwort.
Schritt 4:
Das Datenbanksystem überprüft nun, ob der Benutzer mit dem Namen Y auf das
Datenbanksystem zugreifen darf, und das Passwort auch korrekt ist. Ist dies der Fall, kann der Anwender nun SQL-Anweisungen via SQL-Interpreter an die Datenbank senden.
In dieser Abbildung sehen Sie ein weiteres Authentifizierungs-Szenario. Diesmal unter Verwendung von Single Sign ON (SSO).
Bei diesem Szenario gehen wir wieder davon aus, dass ein Anwender sich auf einem System einloggt und dort einen SQL-Interpreter ( z.B. SQL Server sql_cmd) startet.
Schritt1:
Ein Anwender meldet sich an einem System an ( Login) mit dem Namen X und einem Password.
Schritt 2:
Der Anwender startet den SQL-Interpreter. Hierbei gibt er an, mit welcher
Datenbank er sich verbinden möchte. Zusätzlich gibt er in einer speziellen Option an, dass er eine sogenannte „Trusted connection“ aufbauen möchte. Mit anderen Worten: Er möchte das SSO Verfahren nutzen.
Im Falle eines SQL-Servers, bedeutet dies, dass man die Option –E beim Aufruf des SQL-Interpreters sqlcmd( ehemals osql) angeben muss.
Schritt 3:
Der SQL-Interpreter meldet sich bei dem Datenbanksystem an und gibt zu erkennen, dass das SSO verfahren verwendet werden soll.
Schritt 4:
Das Datenbanksystem überprüft nun mittels eines Authentication Servers, ob der
Benutzer, der den SQL-Interpreter-Prozess gestartet hat, auch die entsprechende Erlaubnis hat, auf die Datenbank zugreifen zu dürfen.
Siehe auch:
• Verstehe SSO: https://msdn.microsoft.com/en-us/library/aa745042(v=bts.10).aspx
In dieser Abbildung sehen Sie ein weiteres Authentifizierungs-Szenario unter Verwendung von Single Sign ON (SSO).
Das Szenario ist diesmal etwas anders. Es wird davon ausgegangen, dass beim Starten eines System ein Dienst gestartet wird, welcher in JAVA geschrieben ist und die Schnittstelle JDBC verwendet und auf eine Datenbank Zugriff benötigt.
In diesem Fall muss in der entsprechenden URL zum Verbindungsaufbau via JDBC-Drivers, das entsprechende Authorisierungsverfahren angegeben werden.
Dies ist entweder
• Angabe von User und Password
• Angabe SSO-verwenden.
Der genaue Aufbau der URL muss bei den einzelnen DBMS Herstellern nachgeschlagen werden.
Siehe auch:
• JDBC Connection String Überblick: http://alvinalexander.com/java/jdbc- connection-string-mysql-postgresql-sqlserver
• Microsoft SQL Server JDBC URL : https://msdn.microsoft.com/de- de/library/ms378428(v=sql.110).aspx
• Microsoft JDBC Verbindungseigenschaften: https://msdn.microsoft.com/de- de/library/ms378988(v=sql.110).aspx
Nachdem wir uns einen Überblick verschafft haben, über die Maßnahmen bzgl.
Identifikation, wenden wir uns nun den Maßnahmen bzgl. der Zugriffsrechte zu.
Es geht also um die Möglichkeiten der Autorisierung.
Wie in dem Abschnitt SQL-DCL bereits beschrieben, bieten die
Datenbanksystem die Möglichkeit, den Zugriff auf die Daten einzuschränken.
Mit anderen Worten: Man kann Privilegien für einzelne Benutzer vergeben. Bei den Privilegien kann zum einen festgelegt werden, WER Zugriff hat ( linke Seite der Abbildung) und AUF_WAS darf zugegriffen werden (rechte Seite in der Abbildung).
Wie in der Abbildung ebenfalls ersichtlich ist, unterscheidet man zwischen:
• Zugriff auf Datenbank die Datenbank Objekte wie Tabellen, Stored Procedures etc.
• Operationen, die ausgeführt werden dürfen. Unter Operationen versteht man CREATE, READ, UPDATE, DELETE, EXECUTE Operationen.
Da in der Praxis sehr viele Benutzer auf eine Datenbank zugreifen können, sollen und es sich um sehr viele Daten-Objekte (i.a. Tabellen)n) handelt, wäre der Administrationsaufwand sehr hoch, wenn man für jeden einzelnen Benutzer die Rechte individuell verwalten wollte.
Um den Administrationsaufwand für das Verwalten der Privilegien in Grenzen zu halten, wurde in dem SQL-Standard SQL-99 das Konzept der Rollen eingeführt.
Diese Konzept erlaubt die Definition von Rollen.
Eine Rolle definiert einen Satz von Zugriffsrechten. Wobei Zugriffsrechte sein können:
• Tabellen anlegen, löschen etc.
• Views anlegen, löschen, ändern
• CRUD Operation auf Tabellen festlegen etc.
• Usw.
Somit kann man einem Benutzer oder einer Benutzergruppe eine Rolle zuweisen.
Dies bedeutet, dass dann diesem Benutzer bzw. alle Mitglieder der Gruppe die Rechte hat, die sich aus der Rolle ergeben.
Siehe auch:
• Microsoft SQL Server Roles verstehen:
http://www.databasejournal.com/features/mssql/article.php/1441261/Understanding- SQL-Server-Roles.htm
• ORACLE.
https://docs.oracle.com/cd/B19306_01/network.102/b14266/authoriz.htm#DBSEG5000
Eine weitere Sicherheitsmaßname ist das Auditing.
Hierbei geht es um den Nachweis, WER hat WANN auf WELCHE Daten zugegriffen.
Die Implementation ist dabei von Hersteller zu Hersteller unterschiedlich.
Die wichtigsten Unterscheidungsmerkmale sind dabei:
• Granularität der Daten
• Konfigurationsparameter
• Aufbau und Umfang der Auditdaten
Meist wird unterschieden zwischen:
• Server Audit
• Database Audit
Siehe auch:
• Microsoft SQL Server Auditing: https://msdn.microsoft.com/de-
https://docs.oracle.com/cd/B19306_01/network.102/b14266/cfgaudit.htm#BABCFIHB Was nun typischerweise bei den Auditdaten erfasst wird, schauen wir uns in der nächsten Abbildung etwas genauer an.
Diese Abbildung gibt Ihnen einen Überblick über die Informationen, die von den meisten Herstellern beim Einschalten des Audit-Dienstes protokolliert werden:
• Änderungen an Passwörtern
• Änderungen an der Audit-Konfiguration selbst
• SQL-DCL Anweisungen wie GRANT und REVOKE
• Änderungen am Datenbankschema selbst
Schauen wir uns nun abschließend zum Audit auf der nächsten Abbildung ein Beispiel vom Oracle an.
In dieser Abbildung sehen Sie Beispiele für Einträge in ein Oracle AUDIT File.
Quelle:
https://docs.oracle.com/cd/B19306_01/network.102/b14266/cfgaudit.htm#i10096 42
Ein Aspekt der Datensicherheit sind die Datenübertragungsprotokolle zwischen der Applikation und dem Datenbanksystem.
Die Herausforderungen hierbei stellt sich wie folgt dar.
In der Praxis kommen meist mehrstufige Software Architekturen zum Einsatz.
Hierbei werden die Datenbanksysteme auf einem eigenen Rechner installiert und betrieben. Dies bedeutet, dass eine Netzwerkverbindung benötigt wird, um die Daten zwischen den Anwendungen und dem Datenbanksystem austauschen zu können.
Die Risiken sind dabei:
• Das unerlaubte Kopieren von Daten
• Dass die Daten verfälscht werden können
• Daten zerstört / gelöscht werden können
• etc.
In dieser Abbildung ist eine Konfiguration dargestellt, bei der die Anwendungen und das Datenbankmanagementsystem (DBMS) auf demselben Rechner
installiert ist. Die Kommunikation findet daher rein lokal auf dem Rechner statt.
In vielen Fällen findet hierbei der Datenaustausch unverschlüsselt statt. In diesen Fällen muss jedoch sichergestellt werden, dass keine unerlaubte Software auf dem Rechner installiert werden kann, um einen Missbrauch auszuschließen.
In den meisten Fällen befinden sich jedoch die Anwendungen und das DBMS auf getrennten Rechnern. In diesen Fällen sind (wie bereits erwähnt) verschlüsselte Verbindungen via SSL notwendig.
Wie aus der Abbildung ersichtlich wird, ist hier ein spezielle Situation dargestellt.
Die Abbildung zeigt eine vereinfachtes Szenario, bei der eine Anwendung über das Internet auf einen Datenbank-Dienst zugreift.
In der Praxis handelt es sich bei den Apps um eine Browser Anwendung z.B. in JavaScript, die über eine Schnittstelle mit dem Backend ( hier ein Datenbank- Service ) Daten austauscht.
Hierbei sind folgende Sicherheitsaspekte (Angriffspunkte) zu beachten:
• Verschlüsselung aller Daten muss gegeben sein
• Ein Man-in-the-Middle Attack muss erkannt werden ( darf nicht möglich sein)
• SQL-Injection darf nicht möglich sein.
Was genau unter Man-in-the-Middle Attack und SQL-Injection zu verstehen ist, schauen wir uns als nächstes an.
Bei Man-in-the-Middle Attack handelt es sich (wie der Name schon ausdrückt) um ein Szenario, bei dem sich eine Dritte Instanz zwischen die Anwendung und Datenbanksystem „einklinkt“.
Gegenüber der Anwendung gibt diese Instanz vor das DBMS zu sein. Gegenüber dem DBMS gibt die Instanz vor das DBMS zu sein.
Um dies zu verhindern, werden beim Aufbau der Verbindung zwischen
Anwendung und DBMS sogenannte Zertifikate ausgetauscht, die den Nachweis erbringen, das der Kommunikationspartner wirklich der ist, für den er sich ausgibt.
Sie auch:
• Microsoft SQL Server: https://technet.microsoft.com/de- de/library/ms189067(v=sql.105).aspx
Unter SQL-Injection versteht man eine spezielle Form von Attacke. Bei dieser Form zielt der Angreifer darauf ab, dass z.B. in Web-Formularen die Eingaben des Anwenders als Teil eines SQL-Befehles unverändert eingetragen werden.
Ist dies der Fall, so kann der Hacker die Eingabe so gestallten, dass eine
„verfälschtes“ SQL-Anweisung entsteht, welche Schaden anrichten kann.
In diesem Fall spricht man davon, dass die SQL-Anweisung verfälscht wurde durch „Injection“.
Schauen wir uns hierzu als nächstes ein Beispiel an.
Siehe auch:
• Definition: http://searchsoftwarequality.techtarget.com/definition/SQL- injection
Die Abbildung zeigt zwei Möglichkeiten von SQL Injection.
In der linken Spalte der Tabelle steht die Original SQL-Anweisung wie sie ursprünglich gedacht wurde.
In der rechten Spalte der Tabelle sehen Sie jeweils die verfälschte SQL-
Anweisung. Die eingefügten SQL Fragmente (injected code) sind entsprechend farblich gegenzeichnet.
Die Grundlage für das Verfälschen von SQL-Anweisungen ist das Herausfinden, ob die Benutzereingaben wirklich unverändert in eine SQL-Anweisung
übernommen wird.
Hierbei gehen Hacker meist wie folgt vor:
1. Schritt : Eingaben so manipulieren, um einen Fehler zu erzeugen und prüfen wie das System auf Fehler reagiert
2. Schritt: Die Eingabe solange manipulieren, bis eine Fehlermeldung kommt, die auf einen Datenbankfehler hinweist.
3. Schritt. Die Eingabe nun so abändern, bis die Eingabe als gültiger Datenbankbefehl interpretiert wird.
Siehe auch:
• Beispiel: www.programmerinterview.com/index.php/database-sql/sql- injection-example
Zum Abschluss des Themas SQL-Injection ein Beispiel:
An der Benutzeroberfläche kann ein Anwender in ein Web-Formular einen Benutzer-Namen angeben.
Ein Hacker hat bereits herausgefunden, dass Eingaben nicht geprüft werden.
Wird diese Eingabe dann unverändert in einen SQL Befehl wie SELECT * from users where name = ´user_eingabe´
Übernommen, so funktioniert dies gut, solange die user_eingabeein Name eines Benutzer ist.
Bei einer SQL-Injection würde ein Hacker folgenden User-Namen verwenden:
Y´ ; drop table users
Wird nun diese Eingabe unverändert in die Datenbank-SELECT Anweisung übernommen, so ergibt sich folgende Anweisung:
SELECT * from users where name = ´Y´ ; drop table users
Es bleibt nun Ihnen überlassen sich zu überlegen, welche Konsequenzen /Ergebnis diese SQL-Anweisung mit sich bringen würde.
Um das Thema Datenschutz und Datensicherheit in Bezug auf Datenbank abzuschließen, finden Sie in dieser und in den nächsten Abbildungen eine Zusammenfassung der wichtigsten Punkte:
Aus Sicht der Anwendungsprogrammierung, sind folgende Punkte wichtig:
• Anwendung so gestallten, dass SQL-Injection ausgeschlossen ist
• Datenbankverbindungen mit unterschiedlichen Benutzerrechten verwenden
Aus Sicht der Datenbank-Administration sind folgende Punkte wichtig:
• Achte auf die Security-Einstellungen der Datenbank
• Erlaube nur SSL Verbindungen
• Achte immer darauf, dass die DBSM immer auf dem aktuellen Patch-Level ist
Quellen:
http://www.isaca.org/chapters1/Baton-
Rouge/newsandannouncements/Documents/Barnes%20ISACA%20Presentation.pdf
Hier sehen Sie DB-Admin Tipps für den Gebrauch von Passwörtern.
Hier sehen Sie DB-Admin Tipps für den Einsatz bzgl. Patches.
Hier sehen Sie DB-Admin Tipps bzgl. der Einstellung von Konfigurationsdaten.
Hier sehen Sie DB-Admin Tipps bzgl. Einstellung von User-Rechten.
Hier sehen Sie DB-Admin Tipps für den Gebrauch von Auditing
Hier sehen Sie DB-Admin Tipps für Umgang mit Datenbank-Backups.
Hier sehen Sie Tipps für die Anwendungsprogrammierung für den Gebrach von SSL-Verbindungen
Quellen:
SQL Server:
• https://msdn.microsoft.com/de-de/library/bb879949(v=sql.110).aspx Oracle:
• http://www.oracle.com/technetwork/topics/wp-oracle-jdbc-thin-ssl- 130128.pdf
• https://docs.oracle.com/cd/B19306_01/java.102/b14355/sslthin.htm#B ABHFBJD
MySQL:
• https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference- configuration-properties.html
