Userdaten Verschlüsseln? MySQL

[Alexander (HH)]

Moin Moin!

[...] Aber schon die klitzekleinste "Verschlüsselung" wie z.B. rückwärts anstatt vorwärts zu speichern ist ein Datenschutz-Gewinn.

Wieso? Weil der Angreifer zu doof ist das zu entschlüsseln? Nein! Weil man nicht beiläufig diese Daten im Klartext sehen können soll. [...]

Klar, er kann alles entschlüsseln - aber dafür hat er hoffentlich keine Zeit.

"Hoffentlich"?

Ich kann den Zeitaufwand deutlich senken, wenn die Aufgabe parallelisierbar ist. Das dürfte bei Kundendaten gegeben sein, ebenso bei Rainbow-Tables. Eine große Menge halbwegs schneller Rechner ist schnell beschafft, sei es legal über Cloud Services wie Amazon EC2 oder illegal über ein Botnet.

Wenn ich 1000 Rechner parallel nutzen kann, brauche ich grob überschlagen nur 1/1000 der Zeit, plus Aufwand für den Datentransport und das reine zerlegen der Daten in 1000 Arbeitspakete. Damit wird aus 3 Jahren sequenzieller Arbeit ein einziger Tag paralleler Arbeit.

Wenn ich mal kurz rechne: 1000 x 24 h/d x 0,095 USD/h = 2280,00 USD für 1000 On-Demand EC2 Small Instances auf Linux-Basis. Wenn ich Dir damit 100.000 EUR "Finderlohn" für die "Rückgabe" der Daten entlocken kann, ist das eine lohnende Investition.

Aus Datenschutzsicht soll man vermeiden, überhaupt jemals in die Kundendatenbank einfach so reinzuschauen.

Richtig.

Bei der Wartung/Fehlerbehebung ist das aber manchmal ünerlässlich.

Ebenfalls richtig.

Da ist es doch dann super, wenn die Daten einfach verschlüsselt sind. So sieht nämlich der Programmierer nicht, dass sein Nachbar sich Analdildos kauft oder sonstwas.

Ganz ernsthaft: Das ist Unfug. Wenn ich in einer Anwendung (egal ob mit oder ohne DB) einen Fehler suche, werde ich irgendwann an den Punkt kommen, an dem die verschlüsselten Daten entschlüsselt werden, damit man sie weiter verarbeiten kann. Und dort muß ich unter Umständen eine Debug-Ausgabe schreiben. Und dann läuft eben unter Umständen "Nachbar hat Dildo gekauft" durch das Debug-Log.

Das läßt sich aber schon durch eine normalisierte DB ziemlich gut vermeiden. Um bei Deinem Beispiel zu bleiben, sehe ich im Log eben nicht mehr "Nachbar hat Dildo gekauft", sondern "Rechnung 4711 enthält den Artikel 31415" und an einer ganz anderen Stelle "Rechnung 4711 geht an Kunde 42". Und dann muß ich immer noch wissen oder nachschlagen, dass Artikel 31415 der Dildo und Kunde 42 der vermeindlich biedere Nachbar ist. Letzeren Lookup kann man z.B. dadurch verhindern, dass die Datenbank nur ausgewählte Logins an die Kundentabellen heranläßt.

Den Rest kann man durch entsprechend organisierte Arbeitsabläufe und eingeschränkte Zugriffsrechte erschlagen:

Die Leute, die die Artikel in Kartons packen, sehen eine Packliste, auf der nur eine Kartonnummer und die zu packenden Artikel stehen. Keine Information über den Kunden.

Eine Station weiter kommt ein geschlossener Karton an, auf dem nur die Kartonnummer steht. Dort wird der zum Karton gehörende Adressaufkleber drauf gepappt. Die Klebenden wissen so zwar, dass der Nachbar Kunde ist, aber nicht, was er gekauft hat.

Bleibt die Rechnung. Die kann vollautomatisch gedruckt und in einen blickdichten Umschlag verpackt werden, niemand außer dem Innenleben der Druck-/Falz-/Kuvertiermaschine und dem Kunden bekommt die Rechnung zu Gesicht.

Die Buchhaltung / Mahn-Abteilung muß nur Rechnungsnummer, Endsumme und Kunde wissen, die Artikel müssen dort nicht angezeigt werden.

Und wenn wir noch weiter spinnen wollen: Um Probleme mit der Rechnung zu klären, könnte auf der Rechnung für den Kunden (und nur dort) ein Einmal-Passwort aufgedruckt werden, ohne dass niemand im Betrieb Details dieser einen Rechnung abrufen kann.

Alexander