nicht angemeldet
Hi,
"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.
Das war eindeutig auf Fälle wie mein Beispiel (Programmierer sieht Dildokauf seines Nachbarn) beschränkt. Bei der Entschlüsselung ist es wurscht ob man da tatsächlich technisch "Zeit" braucht oder nicht. Der der das Recht hat die Tabelle überhaupt "ungeschützt" einzusehen muss nicht mit zeitraubenden Verschlüsselungs- oder Verschelierungstechniken von dem Inhalt abgehalten werden - er kann ihn ja so und so sehen. Andere Personen (auch Mitarbeiter etc.) müssen schon aufgrund des §9 BDSG etc. von der ganzen Tabelle ferngehalten werden.
Das "keine Zeit haben" war nur darauf bezogen, die einfache Entschlüsselung auch tatsächlich beim verrichten einer anderen Aufgabe vorzunehmen. Wenn ich beim Debugging in eine DB schauen muss dann habe ich Zeit, Daten die im Klartext dort stehen mal kurz zu überfliegen (nicht alle, ein paar). Ich habe aber keine Zeit jetzt auch noch extra die (einfache) Entschlüsselung zu machen nur weil ich neugierig bin. Wenn ich denn wirklich einen Datenschutzverstoß begehen will kann ich (sofern ich im Unternehmen der bin der dazu berechtigt ist) ja sowieso massenhaft alles entschlüsseln und mir fein säuberlich ausspucken lassen.
Alleine um diese Zufallsfunde geht es hier. Das ist ein klitzekleiner Teil in der Planung eines datenschutzorientierten Systems. Deine ganzen Ausführungen sind wahr und gut und alles - aber für mich gehört dieser Teil eben auch noch dazu wenn man wirklich sagen können will, dass man alles tut um ein sehr hohes Datenschutzniveau zu schaffen.
Ich behaupte auch nicht, dass es zwingend erforderlich ist sowas zu machen. Aber ich sage, dass es sicherlich nicht schadet. Es ist nicht zu aufwändig sowas bei der Programmierung des Systems zu berücksichtigen und es erhöht den Datenschutz um einen Tick. Wenn man dann echt mal mit den Datenschutzbehörden zu tun hat werden die sicherlich erfreut darüber sein. In Ausnahmefällen kann ich mir auch durchaus vorstellen, dass sowas als erforderlich angesehen wird. Oder zumindest als Ausreichend, wenn man z.B. nicht all deine Anregungen befolgt.
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.
Vielen Dank auch ;)
Mit solchen einfachen Maßnahmen kann ich diesen Zeitpunkt aber hinauszögern, wenn es nicht überhaupt angebracht ist das ganze mit Testdaten oder zumindest mit pseudo- oder sogar anonymisierten Datensätzen zu machen.
Wenn dann wirklich mal jemand diese Information sehen muss, weil das Problem anders nicht zu beheben ist, ist das im Prinzip völlig OK - hier müssen dann eben mal ausnahmsweise die Interessen des Kunden zurückstehen.
Gruß
Alex