Daten verschlüsseln

[z3ck3]

Hi,

ich überlege momentan ein Modul zu entwickeln mit dem man Mitgliedsdaten eines Vereins in einer Datenbank speichert und man diese auch über das Web verwaltet (https natürlich). Nun ist mir aber klar, das schon ein kleiner Fehler ausreicht, auf Seiten des Hosters, den Entwickelrn des Frameworks, oder eben auch bei mir, das die Daten in Flasche Hände geraten. Also ist meine Idee, das die Daten in der Datenbank verschlüsselt werden. Nur muss dann der Key ja irgendwo her kommen. Mir sind dazu drei Wege eingefallen:

1. Key liegt auf dem Server, die Daten werden vom Server entschlüsselt (potentiell ser unsicher)
2. Key wird vom Benutzer eingegeben, Daten werden vorm Server entschlüsselt (php)
3. Key wird vom Benutzer eingegeben, Daten werden vom Client entschlüsselt (js)

Klar ist das sich die Benutzer die Zugriff auf die Daten haben sollen sich entsprechend authentifizieren müssen. Der zusätzliche Key bei Lösung 2 und 3 wäre für alle User gleich. Wird einem User der Zugriff entzogen (z.b. bei Abwahl aus dem Vorstand etc.) dann müssten die Daten neu verschlüsselt und mit einem neuen Key versehen werden.

Gibt es noch andere Lösungswege als 2 und 3 die mir jetzt gerade nicht eingefallen sind?

[PatkIllA]

Was denn für Daten?
Wenn du alles in der Datenbank verschlüsselt wird verliert man auch sehr viele der Vorteile von Datenbanken.

Der vom user einzugebender Key wird praktisch nie direkt zum entschlüsseln verwendet. Üblicherweise wird damit quasi der eigentliche Schlüssel entschlüsselt und der dient dann zum Zugriff auf die Daten. Auf diese Weise muss man nur den Zugang zum Schlüssel neumachen, wenn man neuer Passwörter oder Zugriffsrechte vergibt oder entzieht.

Generell sollte man ohne sehr fundierte Kenntnisse eher Abstand nehmen sollte da groß selbst was zu implementieren. Auch beim Einsatz von sicheren Verfahren baut man sich da schnell einen Bock, der das ganze nutzlos macht.

[z3ck3]

klingt logisch den Schlüssel der auf dem Server liegt zu verschlüsseln. Das wäre ja quasi die Sicherheit aus Lösung zwei mit der einfachen Wartbarkeit aus Lösung eins.

Zu den Daten würden z.b. Name, eMail, geb. Datum, Ansprechpartner bei Minderjährigen und Adresse gehören. Datensätze die real sind und nicht an Dritte gelangen sollten.

Die Vorteile einer Datenbank würde man nicht direkt verlieren. Die Durchsuchbarkeit ginge ja nicht verloren (man muss halt nach vollen Namensteilen suchen statt nur nach h% z.b.) und wo sollte man sie sonst speichern außer auf der Festplatte eines Vorstandmitgliedes, der dafür sorgen muss das die Daten safe sind und wenn es mehere kopien gibt diese immer auf dem Laufenden stand gebracht werden müssen.


Es geht um einen Verein mit etwa 300+ Mitgliedern. Vorstand und Kassenwartin sollte Zugriff haben auf alle Daten. Außerdem schwebt mir vor das es auch Zugänge für bestimmte Mitglieder geben sollte, die das System als Mailverteiler für bestimmte Gruppen nutzen sollten. Da nur der Vorstand diese Aktionen auslösen kann weil er im Besitz des Schlüssels ist, würde er das natürlich moderieren. Momentan ist es so das man erst mit einem vom Vorstand reden muss, der dann die entsprechenden Mitglieder anschreibt über Outlook. Sehr Träge das ganze.


Aber der Tip mit dem Schlüssel der den Schlüssen entschlüsselt hast du mir schon sehr geholfen. Verschlüsselungsalgorythmen werden ja vom Framework bereits bereitgestellt.

[RattuS]

Wo genau liegt dein Problem? Sind Datenbank- und Applikationsserver bei dir denn überhaupt getrennt?

[z3ck3]

Nein. Aber wenn die Daten plain in der Datenbank stehen reicht eine Lücke aus um an die Daten zu kommen. Und wenn die Daten dort verschlüsselt sind, aber der Key plain auf dem Server liegt, dann könnte man auch diesen auslesen. Wenn jemand Zugriff aufs Dateisystem bekommt ist eh Hopfen und Malz verloren (Mysql Daten stehen dort ja klar zu lesen).

Also war meine Idee, einfach weil es personenbezogene reale Daten sind, diese zusätzlich abzusichern, das auch im Falle eines nicht authorisierten Zugriffs die Daten nicht so einfach ausgelesen werden können. Und in dem Fall dann die Mühe für die etwa 300-400 Datensätze zu groß wäre. Die Eingabe eines zusätzlichen Keys, zur Entschlüsselung der Daten war einfach der logische Schritt.

Außerdem wird das auf einem Shared Hosting laufen und da kann auch schon mal scheiße passieren durch "Nachbarn" und/oder Hoster.

Btw. DB-/Appserver sind in Shared Hosting oft auch von einander getrennt (was u.a. bei Mittwald zu Performanceeinbußen führt meiner Meinung nach, aber wayne ;) )

[Gast]

Wenn man dich, der offensichtlich nahezu keinen Plan hat, mit der Umsetzung beauftragt, können die Mitgliedsdaten des Vereins gar nicht so wichtig sein, wie du tust.

Tipp: Sucht euch eine professionelle Person.

[Marscel]

Verschlüsseln tut man nur empfindliche Sachen, in den allermeisten Fällen beschränkt sich das auf ein Passwort - wovon dann i.d.R. nur ein gesalteter Hash vorliegt.

Andere empfindliche Sachen wie z.B. Zahlungs- oder Kreditkartendaten, da gibts dann deutlich strengere Auflagen, an die man sich halten sollte (bis hin zu physischen Zugangssperren).

Was auch immer du dir da selbst einfallen lässt, wenn du nicht gerade die Sicherheitsexpertise hast, wird das eventuell gar nichts bringen sondern nur die Performance deiner Anwendung nach unten ziehen.

Deswegen setz dein Augenmerk auf folgendes:
* mach deine Web?-Anwendung gegen gängige Angriffsvektoren sicher
* nutz immer eine gesicherte Kommunikation zwischen dir als Admin und dem Server, SSH Key-Pair-Verfahren authentifiziert den Client und macht die Kommunikation privat
* alle Dienste kriegen nur die Rechte, die sie zum Betrieb benötigen
* HTTPS
* Updates bei Bekanntwerden von Lücken

Wenn du dann immer noch Zweifel hast, kannst du dir jemanden zum Auditing holen, aber das kostet natürlich auch einiges.

Wenn der Hoster fahrlässig versagt, kannst du diesen belangen, wenn du nachweisen kannst, dass du alle Zugänge nach Stand der Technik gesichert hast. AGB des Hosters, ggf. dessen Datenschutzerklärung und BDSG Anlage zu §9 (http://www.gesetze-im-internet.de/bdsg_1990/anlage_79.html) sollte man sich natürlich zu Gemüte führen.

[Bösewicht]

du koppelst die zu verschlüsselnden daten einfach mit dem passwort hash wert des users...
wen der user jetzt aber sein passwort ändert dann kann er die daten nicht mehr abfragen...
Also baust du eine Funktion ein die beim Passwort ändern ein Chronjob(der auch ausgeführt wird wen browser beim ändern abstürzt) und dieses script ändert den hash des pass von dir dann in jeden Eintrag der verschlüsselt ist...

Suchst du sowas in der art?