Hallo,
aus gegebenem Anlass (https://forum.fhem.de/index.php/topic,85801.msg783735.html#msg783735 (https://forum.fhem.de/index.php/topic,85801.msg783735.html#msg783735)) rege ich alle Entwickler dazu an, dass kein Modul vertrauliche URLs, E-Mail-Adressen oder Kennwörter ins Log schreibt und auch nicht in der fhem.cfg speichert. Die Gefahr, dass ein Anwender versehentlich diese Informationen veröffentlicht, ist gegeben - ich schätze, dass eine Handvoll Fälle im Jahr zu hektischen Bereinigungsfunktionen im Forum führen. Aufgrund der E-Mail-Funktion des Forums sind die Auswirkungen auch weitläufig.
Dies ist ein Punkt für Development Guidelines.
Viele Grüße
Boris
Hallo Boris,
danke für die Anregung. Unterstütze ich. Auch würde ich eine einheitliche Ablage / Verschlüsselung von Daten, die im weitesten Sinne der DSGVO unterliegen, unterstützen. Hierzu sollten Standardfunktionen bereitgestellt werden.
Module, die nicht dieser neuen Konvention folgen, sollten dann zunächst erst einmal nach Contrib verschoben werden.
Grüße Jörg
Gesendet von iPad mit Tapatalk
Habe gerade eines meiner Module entsprechend geändert. Bin auch dafür sowas nicht als logging mit aus zu geben.
ZitatAuch würde ich eine einheitliche Ablage / Verschlüsselung von Daten, die im weitesten Sinne der DSGVO unterliegen, unterstützen.
Es gibt die Funktionen getKeyValue / setKeyValue, die Daten in dem etwas vesteckt gelegenen FHEM/FhemUtils/uniqueID ablegen, unveschluesselt.
Ich habe bisher gedacht, dass DSVGO im Normalfall (d.h. Nutzung fuer die eigene Wohnung/Haus/etc) FHEM nicht betrifft.
Und wenn es FHEM betrifft: wie genau muessen die Passwoerter geschuetzt werden?
Zitat
Ich habe bisher gedacht, dass DSVGO im Normalfall (d.h. Nutzung fuer die eigene Wohnung/Haus/etc) FHEM nicht betrifft.
Und wenn es FHEM betrifft: wie genau muessen die Passwoerter geschuetzt werden?
ui, ui - da gibt's noch Informationsbedarf.
Die DS-GVO gilt natürlich überall, aber nicht für alles :)
Insofern stimmt es aber das die DS-GVO nichts damit zu tun hat was der Anwender mit seinen Daten macht. Die DS-GVO regelt wie ein Anbieter (privat, Verein, Geschäftlich) Daten von anderen behandeln. Was "müsste" man mit dem Passwort machen ? Alles(!) was notwendig ist um die Vertraulichkeit, Integrität und Verfügbarkeit der Information zu garantieren - in Bezug auf Mißbrauch, Naturgewalten, Unfälle/äußere Einflüsse und Versehen sowie Schusslichkeit legitimer Anwender. :) "Due Care ... "
Nun, grundsätzlich gilt die DSGVO auch für das Forum. Somit dürfen, ohne Zustimmung des Betroffenen, keine Personen bezogenen oder beziehbare Daten veröffentlicht werden.
Zu Fragen ist: Ich poste versehentlich solche Daten. Mein Post wird per Benachrichtigung an x User versendet. Ich lösche meinen Beitrag. Nun müssten alle Empfänger dies auch tun.
Ist ein schönes Spielfeld für Juristen und Abmahner. Von daher schon mal Risiko minimieren und Logs und fhem.cfg frei halten.
Fände ich gut.
Grüße Jörg
Gesendet von iPad mit Tapatalk
1. ja, die DS-GVO gilt auch für das Forum.
2. nein, das Beispiel so wie Du es schreibst ist falsch und unterliegt _nicht_ der DS-GVO. (Die Daten werden _nicht_ vom Betreiber des Forum erhoben. Transferschutz)
3. immer richtig: Risikoanalyse führt zu controls. Den user auf diese Art vor sich selbst zu schützen ist umsichtiges Handeln und gut ! (Ist aber eben _kein_ DS-GVO Fall. Da gibt es ganz andere Baustellen)
Und wie soll ein Modul Passwörter speichern, die zB für den Zugriff auf ein Device benötigt werden? Es ist dem Anwender wohl kaum zumutbar, nach jedem Start von FHEM Passwörter manuell einzugeben (zB per Set Befehl).
Auch das verschlüsselte Abspeichern bringt nichts. Schließlich kann sich jeder die notwendige Entschlüsselungsfunktion im Quellcode des entsprechenden Moduls anschauen.
Bleibt eigentlich nur die Bereitstellung einer zentralen Passworddatei, die per Private Key SSL verschlüsselt wird. Zugriff gibt es dann nur für die lokale FHEM Instanz mit dem richtigen Schlüssel.
Zitat von: rudolfkoenig am 20 März 2018, 10:06:04
Es gibt die Funktionen getKeyValue / setKeyValue, die Daten in dem etwas vesteckt gelegenen FHEM/FhemUtils/uniqueID ablegen, unveschluesselt.
Ich habe bisher gedacht, dass DSVGO im Normalfall (d.h. Nutzung fuer die eigene Wohnung/Haus/etc) FHEM nicht betrifft.
Und wenn es FHEM betrifft: wie genau muessen die Passwoerter geschuetzt werden?
Steht hier.
Davon ab geht es eigentlich in erster Linie um das Loggen
ZitatBleibt eigentlich nur die Bereitstellung einer zentralen Passworddatei, die per Private Key SSL verschlüsselt wird. Zugriff gibt es dann nur für die lokale FHEM Instanz mit dem richtigen Schlüssel.
Ich verstehe noch nicht, welches Problem dieses Verfahren loest. Wenn ich den Schluessel klauen kann, dann kann ich die Daten aus der zentralen Passwortdatei auch entwenden. Und wenn ich den Schluessel nicht entwenden kann, dann kann ich vermutlich auch die unverschluesselten Daten nicht klauen. Die Frage ist nur theoretisch, ich gehe immer noch davon aus, dass DSVGO die FHEM-Installationen nicht betrifft.
Korrekt
Mein Beitrag bezog sich auf die Anregung von Boris, Passwörter nicht zu loggen und auch nicht in der fhem.cfg zu speichern. Letzteres dürfte eben schwierig zu realisieren sein, ohne den Benutzer extrem zu gängeln.
natürlich hilft auch eine verschlüsselte Passwortdatei nicht, wenn der Schlüssel entwendet wird. Man könnte jedoch guten Gewissens die fhem.cfg im Forum posten, da man dann in der Datei auf Passwörter verzichten könnte.
Lieber Zap,
Bitte lesen noch Mal was Rudi geschrieben und ich 2 Beiträge drüber Zitiert habe.
Passwörter müssen nicht in die cfg. Beispiel FRITZBOX Modul.
Zitat von: zap am 21 März 2018, 07:37:17
Mein Beitrag bezog sich auf die Anregung von Boris, Passwörter nicht zu loggen und auch nicht in der fhem.cfg zu speichern. Letzteres dürfte eben schwierig zu realisieren sein, ohne den Benutzer extrem zu gängeln.
Ich glaube, es liegt ein Missverständnis vor. Die Passwörter nicht in der fhem.cfg zu speichern, bedeutet nicht, dass der Benutzer sie jedesmal eingeben muss, wenn FHEM gestartet wird. Wie mehrmals hier geschrieben, stellt FHEM Mechanismen bereit, die Passwörter in anderen Dateien zu speichern. Die Gefahr, dass ein Anwender seine Konfiguration postet ohne die Passwörter darin unkenntlich zu machen, sollten wir ausschließen.
Um die Frage der sicheren Aufbewahrung ging es mir nicht. Das ist ein viel dickeres Brett.
Viele Grüße
Boris
Danke Dir Boris für Dein mehr Text. Mein kurzer Hinweis ging wohl verloren.
"configdb info" nutzt ab sofort die privacy als default. Das bedeutet, wer in der Ausgabe dieses Befehls auch seinen Datenbankuser und das zugehörige Passwort finden möchte, muss die privacy explizit abschalten. Bisher war das Verhalten genau umgekehrt: die privacy musste eingeschaltet werden.
Zitat von: Dr. Boris Neubert am 21 März 2018, 08:12:58
Um die Frage der sicheren Aufbewahrung ging es mir nicht. Das ist ein viel dickeres Brett.
Viele Grüße
Boris
Das stimmt. Die sichere Aufbewahrung ist viel kritischer. Wenn ich es richtig verstanden habe, könnte ich ein Modul schreiben, das vordergründig irgendwas sinnvolles macht und im Hintergrund zB die Dateien mit den unverschlüsselten Passwörtern irgendwo hin schickt. Ist das so?