Ein wichtiges Thema bei Datenbankanwendungen ist sicherlich, wie die Daten so geschützt werden können, dass Unberechtigte keine Kenntnis davon erlangen.
Ich möchte hier ein Beispiel aus meiner Praxis aufzeigen.
Mein Lieblings-Datenbank Managementsystem Advantage Database Server (ADS) kommt historisch aus dem Bereich der Xbase-Entwicklung (z.B. Clipper, DBase, FoxPro, Xbase++, Visual Objects) und ist dort nach wie vor stark vertreten. Das dort in der Regel verwendete Datenformat ist die unverschlüsselte DBF-Datei, welche direkt über das Dateisystem ansprechbar ist. Die Datenbanken können somit über einfachste Mittel kopiert werden.
Die DSGVO setzt Technische und Organisatorische Maßnahmen (TOMs) voraus, um personenbezogene und personenbeziehbare Daten zu schützen. Teil dieser TOMs ist die Zugangs- und die Zugriffskontrolle.
Welche Maßnahmen lassen sich also anwenden, um diesen Teil technisch zu unterstützen?
Dateien sollten nicht über das Dateisystem von jedem Benutzer kopiert werden können – und wenn sich das schon nicht realisieren lässt, so sollten die Dateien wenigstens verschlüsselt vorliegen.
Punkt 1 lässt sich durch den Einsatz eines Client/Server Systems erfüllen: Die Benutzer haben keinerlei Rechte mehr auf die Dateien bzw. Ordner, die Zugriffe werden über die Client/Server Schnittstelle erledigt. Im Fall des ADS bedeutet das: Umstellen auf den Servertyp „REMOTE“ und Entzug aller Dateirechte des Benutzers.
Damit hat man aber nur einen kleinen Teil erfüllt. Die Zugangskontrolle umfasst nämlich auch ein Login-System und ein Berechtigungskonzept mit voreingestellten Minimalrechten (Privacy by Design).
Hier kommt dann beim ADS das Data Dictionary ins Spiel. Wie man dies erstellt, ist in der Hilfe (und auch in meinen Büchern) ausführlich beschrieben. Ich beschränke mich hier auf die SQL-Schnittstelle.
Verbinden Sie den Data Architect in ein Verzeichnis mit dem Tabellentyp CDX (FoxPro) und erstellen dort eine einfache Kundentabelle. ACHTUNG: Ich habe nicht auf ein sauberes Datenbankdesign Wert gelegt!
CREATE TABLE Kunde( ID INTEGER, KNR CHAR(10), Name CHAR(30), Vorname CHAR(30), Strasse CHAR(30), PLZ CHAR(10), Ort CHAR(30), Telefon CHAR(30), Email CHAR(30), Geburtstag DATE, Religion CHAR(30), Bemerkung MEMO );
Diese Tabelle ist zunächst unverschlüsselt und von jedem Benutzer, der sich zum ADS verbindet und neben Pfad auch den Dateinamen kennt, ohne Probleme auslesbar. Damit es gleich etwas brisant wird, hat die Tabelle auch ein Feld „Religion“, speichert also auch besondere personenbezogene Daten.
Ein erster Schritt ist nun, diese Tabelle zu schützen. Dazu erstellen wir ein Data Dictionary.
CREATE DATABASE DSGVO PASSWORD 'geheim' ENCRYPT TRUE;
Wichtig: Es sollte der Standard-Benutzer „ADSSYS“ gleich mit einem individuellen Passwort geschützt werden sowie die Verschlüsselung des Data Dictionaries erfolgen. Die Verschlüsselung wirkt sich zunächst nur auf die Datenbank-Datei selbst aus, nicht auf die enthaltenen Daten.
Im nächsten Schritt erstellen Sie eine neue Verbindung im Data Architect, dieses Mal aber statt dem Verzeichnis direkt zum Data Dictionary. Alle weiteren Befehle werden über diese Verbindung erfolgen.
Jetzt gilt es, dieses Data Dictionary abzusichern:
EXECUTE PROCEDURE sp_ModifyDatabase('Log_In_Required', 'True');
EXECUTE PROCEDURE sp_ModifyDatabase('Verify_Access_Rights', 'True');
EXECUTE PROCEDURE sp_ModifyDatabase('Encrypt_Table_Password', 'auchgeheim');
EXECUTE PROCEDURE sp_ModifyDatabase('Encrypt_New_Table', 'True');
EXECUTE PROCEDURE sp_ModifyDatabase('Encrypt_Indexes', 'True');
EXECUTE PROCEDURE sp_ModifyDatabase('Encrypt_Communication', 'True');
EXECUTE PROCEDURE sp_ModifyDatabase('Enforce_Max_Failed_Logins', 'True');
Die einzelnen Absicherung betreffen: Ein zwingendes Login mit Rechteprüfung, ein Passwort für die Datenverschlüsselung sowie die automatische Verschlüsselung aller neu hinzugefügten/erstellten Tabellen und Indexdateien, einer Verschlüsselung der Kommunikation über das Netzwerk und der Vorbeugung gegen Brute-Force-Attacken durch Limitierung der Anzahl gescheiterter Anmeldungen.
Nun können wir die zuvor erstellte Tabelle dieser Datenbank hinzufügen.
EXECUTE PROCEDURE sp_AddTableToDatabase('Kunde','Kunde.dbf',2,1, '', '');
Da alle neuen Tabellen automatisch verschlüsselt werden, wirkt sich dies auch auf die Kunden-Tabelle aus. Wenn Sie versuchen, die Tabelle über die erste Verbindung zu öffnen, erfolgt schon die Abfrage nach dem Datenpasswort (in unserem Beispiel „auchgeheim“). Ein Öffnen über die Dictionary-Verbindung hat die implizite Entschlüsselung, es muss also nach dem Login nicht die Eingabe weiterer Passwörter erfolgen.
Nun können wir die ersten Benutzer anlegen.
EXECUTE PROCEDURE sp_CreateUser('Benutzer1','passwort','');
Wenn Sie sich nun von der Datenbank abmelden und mit diesem Benutzer wieder anmelden, sehen Sie, dass zunächst keine Berechtigungen auf Tabellen vorhanden sind (Privacy by Design).
Berechtigungen sollten allein aus praktischen Gründen nicht an Einzel-Benutzer vergeben werden. Es ist einfacher, Benutzergruppen bzw. Rollen anzulegen und die Berechtigungen darüber zu vergeben.
EXECUTE PROCEDURE sp_CreateGroup('Vertrieb', '');
EXECUTE PROCEDURE sp_AddUserToGroup('Benutzer1', 'Vertrieb');
GRANT SELECT, INSERT, UPDATE, DELETE ON Kunde TO Vertrieb;
Sie sehen: Mit nur wenigen Schritten erfüllt das Datenbank Managementsystem bereits wichtige Anforderungen der DSGVO. Auch wenn ich hier die Beispiele mit dem ADS zeige, sind die Schritte bei fast allen Client/Server Datenbank Managementsystemen ähnlich nachvollziehbar.
REFERENZ: DSGVO-Reihe