nicht angemeldet
Userdaten Verschlüsseln? MySQL
Hallo zusammen,
ich programmiere gerade einen WebShop (PHP) mit einem BackEnd(JAVA), die beide auf eine MySQL-DB zugreifen.
Nun geht es um den beliebten Datenschutz.
Ich will/darf die Userdaten nicht im Klartext speichern!
Das Passwort für den Login hinterlege ich mit md5() das ist klar.
Aber was wäre das sinnvollste für die Kundendaten (Name, Straße, Ort, usw)?
Diese müssen von mir ja auch mit einem Key entschlüsselt werden....
Ich dachte evtl an aes_encrypt direkt bei den Select/Updates per MySQL, da dies weder für Java noch PHP problematisch wird ;-)
Wäre dies aus Eurer Sicht sinnvoll? Oder gäbe es noch gute Alternativen?
Danke im Voraus!
-
Moin Moin!
ich programmiere gerade einen WebShop (PHP) mit einem BackEnd(JAVA), die beide auf eine MySQL-DB zugreifen.
Nun geht es um den beliebten Datenschutz.
Der fängt damit an, die Systeme abzusichern, und ist integraler Bestandteil der Planung einer neuen Software. Du hast also viel zu früh angefangen, Code zu schreiben.
Ich will/darf die Userdaten nicht im Klartext speichern!
Was meinst Du genau mit "Userdaten"?
Das Passwort für den Login hinterlege ich mit md5() das ist klar.
Schlechte Idee.
MD5 ist als geknackt anzusehen, erst recht ohne Salt. Nimm den härtesten Hash-Algorithmus, den Du bekommen kannst. SHA-512 wäre ein Anfang. Und auf jeden Fall gehört eine Zufallskomponente ("Salt") in die Hash-Funktion.
Aber was wäre das sinnvollste für die Kundendaten (Name, Straße, Ort, usw)?
Speichern im Klartext.
Die Anschrift ist laut unserem Datenschutz-Beauftragten ohnehin nicht sonderlich schutzwürdig.
Was meinst Du mit "usw"?
Diese müssen von mir ja auch mit einem Key entschlüsselt werden....
Eben. Das ist vollkommener Mumpitz, denn der Schlüssel und der Entschlüsselungsalgorithmus muß im Programm vorhanden sein. Ein Angreifer kann sich entweder den Schlüssel aus dem Programm herausfummeln oder stumpf das Programm so austricksen, dass es die Daten entschlüsselt rausrückt.
Also Klartext.
Ich dachte evtl an aes_encrypt direkt bei den Select/Updates per MySQL, da dies weder für Java noch PHP problematisch wird ;-)
Mumpitz. Damit verbrennst Du nur Rechenzeit.
Wäre dies aus Eurer Sicht sinnvoll? Oder gäbe es noch gute Alternativen?
Password + Salt durch eine Hash-Funktion jagen, Datenbank-Server, Backend-Server, Webserver und Backup-Server so gut es geht verrammeln, restliche Daten im Klartext speichern.
Zum Absichern der Server: Server baulich sichern (verschlossene Tür mit ausreichend Widerstand gegen Einbruchsversuche, keine Fenster, stabile Wände), keine nicht zwingend notwendigen Dienste (Services bzw. Daemons) laufen lassen, alle Software mit den minimal möglichen Rechten laufen lassen, Remote-Zugang gar nicht oder nur über eine verschlüsselte Verbindung, Zertifikate bzw. Public Key-Verfahren statt Login mit Passwort, ... -- zu dem Thema kann man kistenweise Bücher schreiben.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
MD5 ist als geknackt anzusehen, erst recht ohne Salt.
Das ist so nicht richtig - für MD5 gibt es immer noch keine praktikabel durchführbaren Pre-Image-Angriffe ...
Nimm den härtesten Hash-Algorithmus, den Du bekommen kannst. SHA-512 wäre ein Anfang.
... und auch wenn es diese gäbe, wären die für Passwörter idR. nicht relevant, da die Datenmenge hierbei signifikant abweicht. Ein Passwort ist keine zu signierende Nachricht und es ist so extrem unwahrscheinlich, dass es jemals (auch bei einem schlechten Hash-Algorimus) eine Kollision zweier kurzer Zeichenketten geben wird, dass dieser Fall zu vernachlässigen ist.. Jeglicher Hash-Algorithmus (egal wie stark er ist) ist gegen Wörterbuchangriffe anfällig - und genau darum gehts bei der Passwortsicherheit.
Und auf jeden Fall gehört eine Zufallskomponente ("Salt") in die Hash-Funktion.
Ja - und hierbei spielt es dann keine Rolle mehr, ob man nun MD5 oder SHA-256 oder gar 512 verwendet ist Wurst, eine Rainbow-Table ist schnell generiert. Ob die nun 2 TiB oder 8 hat ist bei den aktuellen Festplattenpreisen vernachlässigbar. Wichtig ist eben, dass man diese Tabelle unnütz macht und nur noch Brute-Forcen übrigbleibt - und auch dabei ist der Hash-Algorithmus wieder egal - und auch der verwendete Salt-Algorithmus. Sobald dieser bekannt ist, ist auch ein schlechtes Passwört nicht mehr sicher.
-
Tach,
MD5 ist als geknackt anzusehen, erst recht ohne Salt.
Das ist so nicht richtig - für MD5 gibt es immer noch keine praktikabel durchführbaren Pre-Image-Angriffe ...
ich halte den Hinweis md5 nicht mehr zu verwenden, trotzdem für sinnvoll: Es gibt Hash-Algorithmen, die im Moment als sicher zu betrachten sind und ich vermute md5 für alle Anwendungen zu "verdammen", prägt sich besser ein, als dass sich Leute merken müssen, welche Anwenungsfälle noch ok sind.
Nimm den härtesten Hash-Algorithmus, den Du bekommen kannst. SHA-512 wäre ein Anfang.
... und auch wenn es diese gäbe, wären die für Passwörter idR. nicht relevant, da die Datenmenge hierbei signifikant abweicht.
Wo spielt denn die Datenmenge eine Rolle? Ich vermute an den wenigsten Stellen, wird ein Paßwort beim Überprüfen in der Länge beschnitten bzw. überprüft, solange ich Kollisionen in einem ausreichend kleinen Bereich finde (ich schätze mal bei Webanwendungen im Megabytebereich), wird das noch akzeptiert werden.
mfg
Woodfighter
-
-
Hi,
Aber was wäre das sinnvollste für die Kundendaten (Name, Straße, Ort, usw)?
Speichern im Klartext.
Die Anschrift ist laut unserem Datenschutz-Beauftragten ohnehin nicht sonderlich schutzwürdig.
wieso lässt du ihn das nicht so machen, wie er es machen soll. Wenn er die Daten verschlüsselt speichern soll, dass soll er es halt so machen ;)
Ich finde die Idee aus der Datenschutzrechtler-Perspektive sehr gut. Das ist ganz im Sinne des §3a BDSG - auch wenn ein verstoß Verstoß dagegen keine direkten Folgen haben wird, sollte man sich schon daran halten.
Der Datenschutz-Beauftrage hat im Prinzip schon recht, dass die Anschrift nicht sonderlich schutzwürdig ist, da diese bei den meisten Leuten öffenltich zugänglich ist (Telefonbuch etc.) und man daher mit diesen Daten "mehr darf".
Wenn es aber Kundendaten sind, sind sie schutzwürdig PUNKT. Schon allein die Tatsache, dass eine Anschrift in der Kundentabelle gefunden wurde, stellt ein weiteres Datum dar - nämlich dass diese Person Kunde bei demundem Shop ist. Das kann sogar ein besonderes personenbezogenes Datum (und damit extrem schutzwürdig) sein - wenn der Shop z.B. ein Gay-Shop ist. Dann haben wir nämlich auch Angaben über die sexuelle Orientierung (Sexualleben - §3 Nr. 9 BDSG)
Natürlich sollte man diese Daten nicht so verschlüssel, dass man sie selbst nicht mehr entschlüsseln kann. 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. Aus Datenschutzsicht soll man vermeiden, überhaupt jemals in die Kundendatenbank einfach so reinzuschauen. Bei der Wartung/Fehlerbehebung ist das aber manchmal ünerlässlich. 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.
Klar, er kann alles entschlüsseln - aber dafür hat er hoffentlich keine Zeit.
Einem Angreifer wird das Leben so erschwert, er kann aber natürlich irgendwo den Entschlüsselungsalgorithmus finden. Deshalb sollte man sich auch an §9 BDSG sowie Anlage 1 des BDSG halten und vielleicht auch den BSI Grundschutz beachten und alles, was sonst noch so zur IT-Sicherheit gehört.
Alles in allem wird man dann ein Datenschutzgerechtes System haben, welches weder vor Angreifern von außen Angst haben muss, noch irgendwelche Daten zufällig intern preisgibt.
Gruß
Alex-
Natürlich sollte man diese Daten nicht so verschlüssel, dass man sie selbst nicht mehr entschlüsseln kann. Aber schon die klitzekleinste "Verschlüsselung" wie z.B. rückwärts anstatt vorwärts zu speichern ist ein Datenschutz-Gewinn.
security through obscurity ist also sicher? Hat das Georg Rau nicht auch neulich behauptet? :p
-
Hi,
security through obscurity ist also sicher? Hat das Georg Rau nicht auch neulich behauptet? :p
Dem ':p' nach zu urteilen, glaube ich, dass du schon verstanden hast, wie ich es gemeint habe ;)
-
security through obscurity ist also sicher? Hat das Georg Rau nicht auch neulich behauptet? :p
Dem ':p' nach zu urteilen, glaube ich, dass du schon verstanden hast, wie ich es gemeint habe ;)
Ja - es ging mir nur darum, den unterschied zwischen "Verschleierung" und "Verschlüsselung" klarzumachen.
Während hier eine Verschleierung der Daten (ob das nun AES ist oder einfach nur Rot 13) vermutlich völlig ausreichend ist (und es bei einem Angriff unerheblich ist, wie man es gemacht hat) um zu verhindern, dass jemand zufällig die Daten sieht, wenn er in die Datenbank schaut ist eine Verschlüsselung (zum tatsächlichen Schutz der Daten) bei der der Algorithmus und sämtliche Schlüssel im System bekannt sind absolut unsinnig.
-
-
-
Hi,
Das kann sogar ein besonderes personenbezogenes Datum (und damit extrem schutzwürdig) sein - wenn der Shop z.B. ein Gay-Shop ist. Dann haben wir nämlich auch Angaben über die sexuelle Orientierung (Sexualleben - §3 Nr. 9 BDSG)
Und jeder Kerl, der in der Drogerie Tampons kauft, *muss* natürlich einer sein, der eine Geschlechtsumwandlung hat machen lassen.
Oder halt, vielleicht kauft er auch nur für eine andere - weibliche - Person ein ...MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hallo,
Und jeder Kerl, der in der Drogerie Tampons kauft, *muss* natürlich einer sein, der eine Geschlechtsumwandlung hat machen lassen.
Oder halt, vielleicht kauft er auch nur für eine andere - weibliche - Person ein ...Ja klar. :P
Gibts dazu nicht irgendwo ne Statistik? Ich würd meine hand dafür ins Feuer legen, dass bei deinem Beispiel die Wahrscheinlichkeit gegen 0 geht, dass die Tampons für ihn als geschlechtsumgewandelte(r) sind. Bei meinem (Typ kauft was im Gay Shop) liegt die Wahrscheinlichkeit bestimmt über 80%.
Aber das ist auch völlig egal. Es geht beim Datenschutz nicht um den Durchschnittskunden oder sonstwas sondern um __jeden einzelnen__ Betroffenen. Beim einen kann irgendwas eine Falschinformation sein beim anderen ein besonderes personenbezogenes Datum. Will man sichergehen behandelt man eben alle Daten wie besondere personenbezogene.
Gruß
Alex
-
-
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
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
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-
Hi!
Alleine um diese Zufallsfunde geht es hier.
Was nützt es, Zufallsfunde zu erschweren, wenn man gezielt schauen kann? Wenn du sensible Daten hast und befürchten musst, dass Mitarbeiter oder Dienstleister diese nicht für sich behalten können, solltest du sie mit ein NDA (Non-disclosure agreement) zum Schweigen verpflichten. Das schließt auch nicht zufällige Funde ein. Gegen menschliche Schwächen helfen angemessene Vertragsstrafen, die zumindest zur Linderung des finanziellen Schadens herangezogen werden können.
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.
Oder sich eins ablachen, ob der dilettantischen Versuche.
[...] wenn es nicht überhaupt angebracht ist das ganze mit Testdaten oder zumindest mit pseudo- oder sogar anonymisierten Datensätzen zu machen.
Natürlich. Dumm nur, dass sich Fehler nicht nur auf das Testsystem beschränken oder stets auch dort nachvollziehbar sind.
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.
Dazu räumt das Gesetz garantiert keine Ausnahme ein.
Lo!
-
Moin Moin!
Was nützt es, Zufallsfunde zu erschweren, wenn man gezielt schauen kann? Wenn du sensible Daten hast und befürchten musst, dass Mitarbeiter oder Dienstleister diese nicht für sich behalten können, solltest du sie mit ein NDA (Non-disclosure agreement) zum Schweigen verpflichten. Das schließt auch nicht zufällige Funde ein. Gegen menschliche Schwächen helfen angemessene Vertragsstrafen, die zumindest zur Linderung des finanziellen Schadens herangezogen werden können.
Ich arbeite mit sensiblen Daten, seit Jahren, und meine diversen Arbeitgeber (aktueller und ehemalige) haben mich routinemäßig zur Verschwiegenheit auch über das Ende des jeweiligen Beschäftigungsverhältnisses hinaus verpflichtet.
Explizite Vertragsstrafen waren nie abgemacht, aber die normale Gesetzeslage sollte ausreichend abschreckend sein. Wenn ich bewußt sensible Daten meines aktuellen Arbeitgebers weitergeben würde, stünde ich wahrscheinlich am nächsten Tag ohne Job da, zur Abwechslung würde man mich dafür wahrscheinlich bis aufs letzte Hemd verklagen.
Wenn ich es drauf anlegen wollte, könnte ich meinem Arbeitgeber und einigen Leuten, die mit meinem Arbeitgeber zusammenarbeiten oder zusammengearbeitet haben, einen riesigen Schaden verpassen. Ich müßte nur gezielt nach einigen Datensätzen suchen und diese weitergeben.
Aber erstens widerspricht das meiner Vorstellung von Berufsehre, und zweitens wäre ich schön blöd, das zu machen. Es gibt bei meinem Arbeitgeber nur sehr wenige Leute, die die notwendigen Zugriffsrechte haben, d.h. ich würde extrem schnell verdächtigt. Und dann: Job weg, Kohle weg, und im blödsten Fall auch noch vorbestraft. Darauf kann ich gut verzichten.
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.
Oder sich eins ablachen, ob der dilettantischen Versuche.
Eben. Die Gleichung "verschlüsselt = sicher" geht nicht auf. Wenn ich ein grottenschlechtes System mit Verschlüsselung "sicher" machen will, ist das wie ein Pappkarton, der zusätzlich zum Paketband noch mit einem High-End-Vorhängeschloss "gesichert" ist. Niemand wird sich da die Mühe machen, dass Vorhängeschloss zu knacken, weil man mit wesentlich weniger Aufwand den Rest des Systems austricksen kann.
Sicherheit und Datenschutz fängt damit an, dass man die Systeme sichert. Ganz trivial: Server liegen innen im Haus, ohne eine Außenwand. Alarmanlage, Zugangsbeschränkungen, das ganze Theater. Darüber ein regelmäßig aktualisiertes Betriebssystem, auf das nur ein sehr kleiner Kreis von Leuten Zugriff hat, darüber Datenbank bzw. Applikation, wieder mit so wenig Rechten wie möglich. Und so weiter, und so weiter. Irgendwann ist man bei der Eingabevalidierung, und da ist man noch lange nicht fertig.
[...] wenn es nicht überhaupt angebracht ist das ganze mit Testdaten oder zumindest mit pseudo- oder sogar anonymisierten Datensätzen zu machen.
Natürlich. Dumm nur, dass sich Fehler nicht nur auf das Testsystem beschränken oder stets auch dort nachvollziehbar sind.
Das erstere ist richtig, das zweite sollte eigentlich nur extrem selten passieren. Denn idealerweise ist das Testsystem baugleich mit dem Produktivsystem und kann auch schnell auf dessen Datenstand gebracht werden. Virtuelle Maschinen sind da extrem hilfreich.
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.
Dazu räumt das Gesetz garantiert keine Ausnahme ein.
Muß auch nicht. Denn der Kunde hat dem Unternehmen das Recht gegeben, seine Daten zu verarbeiten. Dazu gehört auch, dass Admins und ggf. hausinterne Entwickler Einblick in die Daten bekommen, falls das für ihren Auftrag notwendig ist. Natürlich kann man dafür Sorgen, dass diese Einblicke automatisch und nicht manipulierbar dokumentiert werden.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hi,
Eben. Die Gleichung "verschlüsselt = sicher" geht nicht auf. Wenn ich ein grottenschlechtes System mit Verschlüsselung "sicher" machen will, ist das wie ein Pappkarton, der zusätzlich zum Paketband noch mit einem High-End-Vorhängeschloss "gesichert" ist. Niemand wird sich da die Mühe machen, dass Vorhängeschloss zu knacken, weil man mit wesentlich weniger Aufwand den Rest des Systems austricksen kann.
Solange du mir nicht unterstellst, dass ich sowas idiotisches vorgeschlagen habe, ist das OK...
Sicherheit und Datenschutz fängt damit an, dass man die Systeme sichert. Ganz trivial: Server liegen innen im Haus, ohne eine Außenwand. Alarmanlage, Zugangsbeschränkungen, das ganze Theater. Darüber ein regelmäßig aktualisiertes Betriebssystem, auf das nur ein sehr kleiner Kreis von Leuten Zugriff hat, darüber Datenbank bzw. Applikation, wieder mit so wenig Rechten wie möglich. Und so weiter, und so weiter. Irgendwann ist man bei der Eingabevalidierung, und da ist man noch lange nicht fertig.
Meine Rede (§9 BDSG, Anlage 1 BDSG, BSI Grundschutz etc.)
Dazu räumt das Gesetz garantiert keine Ausnahme ein.
Muß auch nicht. Denn der Kunde hat dem Unternehmen das Recht gegeben, seine Daten zu verarbeiten. Dazu gehört auch, dass Admins und ggf. hausinterne Entwickler Einblick in die Daten bekommen, falls das für ihren Auftrag notwendig ist. Natürlich kann man dafür Sorgen, dass diese Einblicke automatisch und nicht manipulierbar dokumentiert werden.
Das ist leider sehr falsch.
Mal eine kleine Einführung in das Datenschutzrecht:
Das Datenschutzrecht ist ein großes Verbot mit Erlaubnisvorbehalt. Man darf grundsätzlich absolut nichts machen was mit personenbezogenen Daten zu tun hat. Erlaubt ist das was im Gesetz erlaubt ist - mehr nicht.
Es wird von einigen Unternehmen schwachsinnigerweise (und nach einer mMn unzutreffenden Mindermeinung soweit ich weiß auch illegalerweise) praktiziert, vom Kunden z.B. bei einer Online-Bestellung eine Einwilligung einzuholen, dass das Unternehmen die Daten zur Versandabwicklung etc. verwenden darf. Das ist absolut nicht nötig und verwirrt den Kunden nur (sofern er überhaupt irgendwas dazu tatsächlich lesen sollte).
Also hat der Kunde dem Unternehmen nicht das Recht gegeben, die Daten zu nutzen. Das Unternehmen hat dieses Recht Kraft Gesetz (§ 28 Abs 1 S 1 Nr 1 BDSG) weil es _erforderlich_ ist um den Vertrag abzuwickeln.
Sobald es für diesen Vertrag nicht mehr _erforderlich_ (das heißt nicht dienlich/nutzlich/praktisch) ist, die Daten zu verwenden dürfen sie auch für nichts mehr verwendet werden.
Auch wenn der Kunde es doch mittels Einwilligung gemacht hätte würde diese in aller Regel solche Fälle nicht umfassen bzw. unwirksam sein. Es muss nämlich eine bewusste Einwilligung stattfinden - hierzu muss der Betroffene wissen worum es geht. Man muss es wenn dann also sehr ausführlich erklären und der Kunde könnte jederzeit widerrufen.
Es gibt aber auch noch § 28 I S 1 Nr 2 BDSG - hier kann eine Interessenabwägung stattfinden. Und genau da könnte das Unternehmen sich das Recht herholen die Daten dafür zu verwenden.
Gruß
Alex
-
-
Hallo,
ich bitte dich, doch mal genau das zu lesen was ich geschrieben habe und nichts gedanklich wegzulassen und vor allem nichts hinzuzuerfinden oder sonstwie zu verfälschen und dann denk nochmal drüber nach.
Du sagst ja grundsätzlich nichts falsches - aber es hört sich arg widersprüchlich zu dem an was ich gesagt habe...finde ich nicht so toll.
Was nützt es, Zufallsfunde zu erschweren, wenn man gezielt schauen kann? Wenn du sensible Daten hast und befürchten musst, dass Mitarbeiter oder Dienstleister diese nicht für sich behalten können, solltest du sie mit ein NDA (Non-disclosure agreement) zum Schweigen verpflichten. Das schließt auch nicht zufällige Funde ein. Gegen menschliche Schwächen helfen angemessene Vertragsstrafen, die zumindest zur Linderung des finanziellen Schadens herangezogen werden können.
Eine Verpflichtung auf das Datengeheimnis muss natürlich stattfinden - wer hat das bitte auch nur ansatzweise anders dargestellt?
Dienstleister müssen natürlich strengen Regelungen unterworfen werden.
Ohne sowas ist das komplette Vorhaben schon rechtswidrig.
Natürlich sind Vertragsstrafen eine gute Sache.
Oder sich eins ablachen, ob der dilettantischen Versuche.
DAS bezweifle ich sehr stark.
Alternative 1: Man versteht mich hier falsch und wendet nur eine leichte Verschlüsselung an und "etwas passiert" --> Die Behörden werden sicherlich nicht lachen sondern sauer werden und vielleicht auch mal zur Abwechslung ein Bußgeld verhängen.
Alternative 2: Man versteht mich richtig. Baut ein 100% datenschutzkonformes System (mit Verpflichtungen auf das Datengeheimnis, Zutritts- und Zugangssperen und so weiter) UND beherzigt meinen Vorschlag noch.
-->Die Behörden werden erfreut sein, dass es einer sehr ernst mit dem Datenschutz nimmt.[...] wenn es nicht überhaupt angebracht ist das ganze mit Testdaten oder zumindest mit pseudo- oder sogar anonymisierten Datensätzen zu machen.
Natürlich. Dumm nur, dass sich Fehler nicht nur auf das Testsystem beschränken oder stets auch dort nachvollziehbar sind.
Warum habe ich wohl geschrieben "wenn es nicht überhaupt angebracht ist ...". Eben, genau WEIL es nicht immer möglich ist. WENN es aber angebracht/möglich/auch Zielführend/etc. ist, die daten zu pseudonymisieren oder zu anonymisieren hat das auch zu geschehen!
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.
Dazu räumt das Gesetz garantiert keine Ausnahme ein.
Da scheinst du das Datenschutzrecht aber nicht sonderlich gut zu kennen.
-
Hi!
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.
Dazu räumt das Gesetz garantiert keine Ausnahme ein.
Da scheinst du das Datenschutzrecht aber nicht sonderlich gut zu kennen.Stimmt. Da du es aber besser zu kennnen scheinst, kannst du mir sicher die relevante Stelle zeigen. Bis dahin glaube ich nicht, dass man unter dem Vorwand der Problembehebung soweit auf den Datenschutz verzichten darf, dass der Kunde davon negativ betroffen wäre.
Lo!
-
Hallo,
Stimmt. Da du es aber besser zu kennnen scheinst, kannst du mir sicher die relevante Stelle zeigen. Bis dahin glaube ich nicht, dass man unter dem Vorwand der Problembehebung soweit auf den Datenschutz verzichten darf, dass der Kunde davon negativ betroffen wäre.
§ 28 Abs 1 S 1 Nr 2 BDSG, wobei für besondere personenbezogene Daten noch strengere Regeln gelten. Eine Pseudonymisierung (nichts anderes stellt eine einfache Verschlüsselung7Verscheleierung im Auge des Schlüsselinhabers dar) kann für die Interessenabwägung erforderlich sein.
§ 100 Abs 1 TKG ist auch ein gutes Beispiel. Da geht es um Störungen von Telekommunikationsanlagen - ist also eher eine Sonderfall-Sache.
Man muss natürlich beachten, dass insbesondere der § 28 BDSG keine Wunderwaffe ist. Die Interessenabwägung schlägt nicht immer zugunsten des Unternehmens aus. Sicherlich dann erst recht nicht, wenn es nur ein Vorwand ist oder wenn es aus Bequemlichkeit geschieht. Die gesetzlichen Möglichkeiten sind aber da, wenn man einen Fall hat in dem es wirklich zwingend erforderlich ist und der Kunde im EInzelfall damit leben können muss. Es geht ja auch nicht um das Auslesen ganzen Datenbanken - sondern um Einzelfälle.
Im TMG-Bereich (Telemediengesetz) ist das Ganze noch strenger. Ich habe da jetzt nicht zu lange nachgebohrt aber auf die Schnelle konnte ich da kein "Schlupfloch" finden.
Übrigens: So arg datenschützend ist das BDSG auch wieder nicht. Man schaue sich nur z.B. mal das Listenprivilig in § 28 Abs 3 an. Oder sogar im TMG-Bereich die Profilerstellung (auch wenn das Pseudonymisiert zu erfolgen hat und mit Widerspruchsmöglichkeit der Nutzer).
Gruß
Alex-
Hi!
Stimmt. Da du es aber besser zu kennnen scheinst, kannst du mir sicher die relevante Stelle zeigen. Bis dahin glaube ich nicht, dass man unter dem Vorwand der Problembehebung soweit auf den Datenschutz verzichten darf, dass der Kunde davon negativ betroffen wäre.
§ 28 Abs 1 S 1 Nr 2 BDSG, wobei für besondere personenbezogene Daten noch strengere Regeln gelten. Eine Pseudonymisierung (nichts anderes stellt eine einfache Verschlüsselung7Verscheleierung im Auge des Schlüsselinhabers dar) kann für die Interessenabwägung erforderlich sein.Da steht Geschäft (um die dortige Formulierung mal auf ein Wort zusammenzufassen) "mit dem Betroffenen". Wenn ich Fehler in meinem Programm suche ist der Kunde außen vor. Ich sehe das nicht als zutreffend an. Hast du dazu irgendwelche Entscheidungen, dass für Problemsuche in Daten(verarbeitung), die keinen konkreten Kunden betreffen, der Schutz der Daten aufgehoben werden kann?
Übrigens: So arg datenschützend ist das BDSG auch wieder nicht.
Ach, na dann ist es ja völlig in Ordnung, nur einen halbseidenen Schutz aufzubauen ...
Lo!
-
Hi,
Da steht Geschäft (um die dortige Formulierung mal auf ein Wort zusammenzufassen) "mit dem Betroffenen". Wenn ich Fehler in meinem Programm suche ist der Kunde außen vor. Ich sehe das nicht als zutreffend an. Hast du dazu irgendwelche Entscheidungen, dass für Problemsuche in Daten(verarbeitung), die keinen konkreten Kunden betreffen, der Schutz der Daten aufgehoben werden kann?
Ich lese da weder irgendetwas von einem Geschäft noch etwas von "mit dem Betroffenen" - vermutlich beziehst du dich auf Nummer 1 und nicht, wie ich es angegeben habe, Nummer 2.
Nach der Formulierung des § 28 Abs 1 S 1 sind die Nummern 1 - 3 völlig gleichwertige Alternativen. Diese Voraussetzungen müssen also _nicht_ kumulativ vorliegen. Das wird in der Literatur teilweise etwas anders gesehen - besonders krass in der arbeitsrechtlichen bevor es den § 32 gab. In Grenzen mag diese andere Sicht zutreffen - aber prinzipiell sind die Nummern 1-3 völlig unabhängig von einander anzuwenden.
Ich konnte leider auf die Schnelle keine Entscheidung oder ähnliches finden. Das wird denke ich mal sehr schwierig, weil sowas ja in der Regel überhaupt nicht auffällt - und wo kein Kläger da kein Richter. Allenfalls könnte man dazu in der Literatur etwas finden.
Generell zur Interessenabwägung:
Man kann jedes von der Rechtsordnung gebilligte Interesse verfolgen - egal ob wirtschaftlicher, ideeller oder rechtlicher Natur.Dann wird geschaut ob der Betroffene überhaupt ein schutzwürdiges Interesse an der Geheimhaltung seiner Daten hat.
Wenn ja muss eine Abwägung stattfinden. Da ist dann eben wichtig, was genau passiert. Da ist es dann natürlich besser für das Unternehmen, wenn lediglich eine Nutzung in Form von Anzeigen der Daten stattfindet und keine Verarbeitung oder gar Übermittlung.
Übrigens: So arg datenschützend ist das BDSG auch wieder nicht.
Ach, na dann ist es ja völlig in Ordnung, nur einen halbseidenen Schutz aufzubauen ...
Sage ich das? Wohl kaum, wenn ich sogar da befürworte was ich hier oben schon lang und breit erklärt habe.
Gruß
Alex-
Hi!
Da steht Geschäft (um die dortige Formulierung mal auf ein Wort zusammenzufassen) "mit dem Betroffenen". Wenn ich Fehler in meinem Programm suche ist der Kunde außen vor. Ich sehe das nicht als zutreffend an. Hast du dazu irgendwelche Entscheidungen, dass für Problemsuche in Daten(verarbeitung), die keinen konkreten Kunden betreffen, der Schutz der Daten aufgehoben werden kann?
Ich lese da weder irgendetwas von einem Geschäft noch etwas von "mit dem Betroffenen" - vermutlich beziehst du dich auf Nummer 1 und nicht, wie ich es angegeben habe, Nummer 2.
Dann bin ich mit der Nummerierung durcheinandergekommen. Für mich war "Abs 1" das Ding mit dem "(1)" und "S 1" das "1.". Das "Nr 2" hab ich ignoriert. Wenn es nun richtig ist, hat "S 1" also keine Kennzeichnung sondern ist alles von inklusive (1) bis exklusive dem Satz vor dem (2).
Aber vielleicht trifft das alles gar nicht auf den Fall zu. Unter der Voraussetzung, dass der Datennutzer sie rechtmäßig erhoben und aufbewahrt hat, gehört eine Fehlerbearbeitung in der Verarbeitungsanlage doch zur "Erfüllung eigener Geschäftszwecke". Wie werden denn dann die Daten anders genutzt, so dass dies irgendwelche Interessen des Dateninhabers derart betrifft, dass ein Schutz nicht mehr gegeben ist? Solange das alles intern abläuft und von den Daten nichts nach außen dringt, ist doch da gar nichts vorhanden, wo jemand in seinen Rechten zurückstecken müsste.
Vielleicht war ja einfach nur deine Formulierung unglücklich und du meintest gar keine Offenlegung der Daten gegenüber unberechtigten Dritten.
Lo!
-
Hallo,
Dann bin ich mit der Nummerierung durcheinandergekommen. Für mich war "Abs 1" das Ding mit dem "(1)" und "S 1" das "1.". Das "Nr 2" hab ich ignoriert. Wenn es nun richtig ist, hat "S 1" also keine Kennzeichnung sondern ist alles von inklusive (1) bis exklusive dem Satz vor dem (2).
S (als "Satz") nummeriert einfach die Sätze eines Absatzes durch, damit man sich besser darin zurechtfindet. Satz 1 geht hier am Anfang des Absatzes lost und endet nach Nummer 3. Abs 1 Satz 2 ist z.B. dann dieser: "Bei der Erhebung personenbezogener ...".
Aber vielleicht trifft das alles gar nicht auf den Fall zu. Unter der Voraussetzung, dass der Datennutzer sie rechtmäßig erhoben und aufbewahrt hat, gehört eine Fehlerbearbeitung in der Verarbeitungsanlage doch zur "Erfüllung eigener Geschäftszwecke". Wie werden denn dann die Daten anders genutzt, so dass dies irgendwelche Interessen des Dateninhabers derart betrifft, dass ein Schutz nicht mehr gegeben ist? Solange das alles intern abläuft und von den Daten nichts nach außen dringt, ist doch da gar nichts vorhanden, wo jemand in seinen Rechten zurückstecken müsste.
Vielleicht war ja einfach nur deine Formulierung unglücklich und du meintest gar keine Offenlegung der Daten gegenüber unberechtigten Dritten.
Um die "Erfüllung eigener Geschäftszwecke" geht es auf jeden fall - muss es im § 28 Abs 1 BDSG auch.
Es ist grundsätzlich alles verboten, was mit der Handhabung personenbezogener Daten zu tun hat. Also jeglicher Verwendungsschritt - auch die bloße Nutzung, die keine Verarbeitung darstellt - ist verboten.
Zu den Begriffen siehe hier.
Man muss also - z.B. im § 28 - einen Rechtfertigungsgrund finden. Auch wenn man die Daten nicht Dritten übermittelt oder sie veröffentlicht oder so sondern auch wenn man sie nur am Bildschirm aus der Datenbank ausgibt.Mir ging es wirklich nur im die interne Nutzung bzw. Verarbeitung der Daten. Dass Dritte (= nicht Auftragnehmer im Sinne des § 11) die Daten rechtmäßig bekommen dürfen im Rahmen einer Fehlerbehebung halte ich für äußerst schwierig wenn nicht gar unmöglich. (Wenn man mal von Einwilligungen der Betroffenen absieht)
Ich hoffe, jetzt ist es ein bisschen klarer.
-
-
-
-
-
-
-
-
-
-
-