DSGVO

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Antworten
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

DSGVO

Beitrag von Koverhage »

Wenn es hier nicht hingehört bitte verschieben.
Ich möchte/muss Telefonnummern und Mail Adressen auf unserem Server speichern.
Die Daten sollten ja verschlüsselt werden (Achtung: kein SQL und kein ADS).
Was wäre die beste Methode dafür ?
Gruß
Klaus
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Ich würde das gute alte Crypt nehmen, in Verbindung mit einem möglichst langen Passwort, ggf. ergänzt um ein datensatzbezogenes "Salz" (also ein Add-On zum Passwort, das nur für diesen Eintrag gilt, so dass das Passwort je Datensatz anders ist). Das ist zwar nicht übermäßig sicher, aber man muss schon ein wenig Energie aufwenden, um das zu dechiffrieren. Ergänzend würde ich das Ergebnis in Hex umwandeln und so speichern.

Die Hashes, die man auch mit Xbase++ in sehr sicherer Form erzeugen kann, dienen nur der Ein-Weg-Verschlüsselung. Man kann also prüfen, ob eine Eingabe dem verschlüsselten Datum entspricht, aber aus dem verschlüsselten Datum nicht mehr das Original restaurieren. Weil es eigentlich kein verschlüsseltes Datum ist, sondern eben nur ein Hash - ein Wert, der u.a. aus dem Datum erzeugt wurde.
Herzlich,
Tom
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Ergänzung: Alaska hat das im April-Newsletter thematisiert und dafür drei Wege vorgeschlagen: RDP (App remote zur Verfügung stellen), die PGDDBE und Impersonation (einfach mal hier im Forum suchen, habe ich erklärt). Meiner Erinnerung nach kann man außerdem DBFs (aber nur FOX) AES-verschlüsseln, out of the box. Aber für einzelne Felder in einer Tabelle würde ich tatsächlich wie oben erläutert verfahren.
Herzlich,
Tom
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Koverhage »

Tom,
Danke an Crypt habe ich auch schon gedacht.
Schade das Xdot Crypt nicht kennt.
Gruß
Klaus
Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 483
Registriert: So, 28. Mär 2010 19:21
Danksagung erhalten: 11 Mal

Re: DSGVO

Beitrag von azzo »

Hallo Freunde,
eine Frage, die mich schon länger interessiert:
Gibt es eine Verpflichtung zur Verschlüsselung von Daten nach DSGVO.

LG
Otto
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Hallo, Klaus.

Du musst Xdot einfach nur mit den Tools (xbtbase1.lib/xbtbase2.lib) verlinken, als #pragma in der XDOT.PRG oder direkt in der XPJ, dann kann der auch Crypt(). Wenn die XbTools mit Deiner Anwendung verlinkt sind, kann DC_Dot() das auch, weil DC_Dot alle nichtstatischen Funktionen kennt, die Deine Anwendung auch kennt.

Hallo, Otto.

Nein, es gibt keine explizite Verpflichtung zur Verschlüsselung bzw. verschlüsselten Speicherung personenbezogener Daten. Der Dateninhaber (also Dein Softwarenutzer) muss nur technische und organisatorische Maßnahmen (TOMs) treffen oder treffen lassen, um diese Daten gegen Angriffe und Entwendung zu schützen, und dazu kann gehören, dass sie grundsätzlich verschlüsselt werden, aber es gibt auch andere Mechanismen, die den Zugang zu diesen Daten so erschweren, dass Datenlecks unwahrscheinlich(er) werden. Etwa die Absicherung der Infrastruktur, das vollständige Sperren der Datenbank für Zugriffe außerhalb der Anwendung, die wiederum so abgesichert ist, wie nur vorstellbar usw. usf. Verschlüsselung ist eines von vielen Mitteln, aber eine Verpflichtung besteht nicht. Sollte es aber zu einem Datenproblem kommen, kann es passieren, dass die Strukturen untersucht werden, und dass jemand feststellt, dass man die Daten aus Deiner Anwendung einfach so gut wie klarschriftlich mitgehen lassen kann, indem man eine DBF kopiert, die in einem für jedermann sichtbaren Verzeichnis auf dem Server liegt. Nicht die Wahl der Mittel ist vorgeschrieben, aber ihre Wirkung.
Herzlich,
Tom
Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 483
Registriert: So, 28. Mär 2010 19:21
Danksagung erhalten: 11 Mal

Re: DSGVO

Beitrag von azzo »

Hallo Tom,
vielen Dank.
Interessant finde ich deinen Vorschlag mit dem 'datensatzbezogenen "Salz"'.

Mit freundlichem Gruß
Otto
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Koverhage »

Tom,
leider bringt Crypt mir ein falsches Ergebnis.
Laut Hilfe The function Crypt() encrypts or decrypts a string using the same password.

? crypt("12345678", "87654321")
? crypt("SÐz¦Îaþü", "87654321")

Als Ergebnis bekomme ich
SÐz¦Îaþü -> im Original (Dot Window) OEM, hier wohl Ansi, deshalb anders als im Dot
123P5678 -> müsste 12345678 sein
Gruß
Klaus
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Wenn Deine Anwendung auf OEM läuft, und Du rufst DC_Dot() auf, erfolgt eine Vor-Rückwärts-Konvertierung OEM-ANSI-OEM. Alles außerhalb des 7-Bit-Bereichs stimmt dann ggf. nicht mehr. Aber wenn Du das hier:

Code: Alles auswählen

FUNCTION Main()
LOCAL c := "12345678", cPW := "87654321", cTemp

cTemp := Crypt(c,cPW)
? Crypt(cTemp,cPW)
RETURN NIL
kompilierst und laufen lässt, zeigt es Dir "12345678" an. Wenn Du das Ergebnis von Crypt() speichern willst, dann wende ein StrToHex() auf das Ergebnis an - und umgekehrt, bevor Du diese Info wieder entschlüsseln willst.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DSGVO

Beitrag von ramses »

Koverhage hat geschrieben: Mi, 11. Aug 2021 8:46 Die Daten sollten ja verschlüsselt werden (Achtung: kein SQL und kein ADS).
Was wäre die beste Methode dafür ?
Ein verschlüsseltes Laufwerk!
Valar Morghulis

Gruss Carlo
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Koverhage »

Tom,
StrToHex hat den Nachteil das ich alle Feldgrößen verdoppeln müsste.
Das Ergebnis von Crypt bringt vermutlich Probleme in der DBF.
Gruß
Klaus
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: DSGVO

Beitrag von AUGE_OHR »

hi,
ramses hat geschrieben: Do, 12. Aug 2021 7:39 Ein verschlüsseltes Laufwerk!
wohl möglich mit TPM v2.0 und Bitlocker ... :badgrin:

ich halte mehr von eine Crypt-Controller wo der Code nicht von Microsoft kommt ...

---

"eigentlich" müsste man auch die Datenübertragung verschlüsseln.
die Ryzen "Pro" Modell sollen sogar "innerhalb" der CPU verschlüsselt arbeiten
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Hallo, Klaus.
StrToHex hat den Nachteil das ich alle Feldgrößen verdoppeln müsste.
Das Ergebnis von Crypt bringt vermutlich Probleme in der DBF.
Beides ist zutreffend. Aber es geht out-of-the-box - und wenn Du wirklich nur Telefonnummern und Mailadressen verschlüsseln willst, hält sich der Aufwand möglicherweise in Grenzen. Alternativ könntest Du mit AES herumspielen, oder mit Impersonation. Oder Du baust Dir einen eigenen, simplen Mechanismus (also eine Funktion "MyCrypt"), der im zulässigen Zeichenbereich Buchstaben und Ziffern verdreht, vertauscht oder in Abhängigkeit von irgendwas umpositioniert, aber auf eine Weise, die eben reversibel ist. Verschlüsseln heißt ja nicht, dass man irgendein anerkanntes Verfahren nutzen müsste - das hätte sogar den Nachteil, dass es ja bekannt wäre. Wenn Du was vollständig Propreitäres machst, das nicht auf den ersten bis vierten Blick zu durchschauen ist, hast Du die Sicherheitslatte schonmal etwas höher gelegt. Und Du kannst guten Gewissens behaupten, dass Du verschlüsselst.
Herzlich,
Tom
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Koverhage »

So werde ich es vermutlich realisieren.
Danke.
Gruß
Klaus
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Die "Caesar-Verschlüsselung" ist ein einfacher Algorithmus, den man schnell hinkriegt, und der so etwas macht. https://de.wikipedia.org/wiki/Caesar-Ve ... %BCsselung
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DSGVO

Beitrag von ramses »

AUGE_OHR hat geschrieben: Do, 12. Aug 2021 8:21
wohl möglich mit TPM v2.0 und Bitlocker ... :badgrin:

ich halte mehr von eine Crypt-Controller wo der Code nicht von Microsoft kommt ...
Nein, sicher nicht mit Bitlocker.
Besser ist z.B. PEFS
Runs on top of your file system. No messing around with complex configuration and additional storage devices.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Nun, es geht in Klaus' Fall darum, Daten zu schützen, an die die, vor denen sie geschützt werden sollen, sowieso rankommen, weil sie als DBFs irgendwo im Netz herumfliegen. Ein verschlüsselndes Dateisystem wie PEFS oder ähnliche Mechanismen setzen eine Ebene zu tief an. Ich würde eher zu Impersonation raten, das ist sehr elegant und auch nicht allzu kompliziert. Dann muss es zwar mindestens einen Account geben, der auf die Daten auch auf Dateiebene zugreifen kann, aber im täglichen Normalzugriff sind die Daten sicher.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DSGVO

Beitrag von ramses »

Hallo Tom

bei "Impersonation" liegen die Daten dummerweise doch im Klartext auf Festplatte und Sicherung ....
Bei der Verschlüsselung von Datenfelder hast du dann ein Problem mit den Index-Files.
Hier hilft dann z.B. PEFS welches alle Dateien eines Pfades Transparent verschlüsseln kann ohne änderung am Programmcode und auch die Datensicherung z.B. ein Datenset in der Cloud oder sonst wo perfekt schützt.
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Tom »

Hallo, Carlo.

Aber auf Telefonnummer oder Mailadresse legt man üblicherweise keinen Index, oder? Und, klar, bei Impersonation hast Du immer noch den Zugriff auf Administratorebene. Aber den hast Du bei einem SQL-Server ja auch. Und ein verschlüsseltes Dateisystem hilft Dir nicht, wenn die Nutzer - wie bei DBF-Datenbanken üblich - Vollzugriff auf die Datenverzeichnisse haben müssen. In diesem Fall wäre eine Dateisystem-Verschlüsselung in Verbindung mit Impersonation vermutlich die beste Wahl. Aber, wie gesagt - es geht hier um Telefonnummern und Mailadressen. Und wenn es nicht um hunderttausende von Kontakten geht, tut's da im Zweifelsfall auch ein Filter.
Herzlich,
Tom
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: DSGVO

Beitrag von Koverhage »

wie auch immer, ich muss die Datenfelder in der DBF verschlüsselt ablegen. Darauf erfolgt dann auch im Zweifel ein Index.

Es ist ja auch kein Problem.
Beispiel TelNr. die verschlüsselt in der DBF steht.
Der Suchbegriff wird vor dem Seek verschlüsselt und danach gesucht.
Im Quellcode kann ich nach

replace kd->telnr with Crypt(TelKlartext) suchen und einfach ädern
oder
m_TelNr := Decrypt(kd->telnr) // Die Funktion gibt es nicht. Ist nur zum besseren Verständnis.

Wenn ich die in der Anwendung im Klartext brauche, decodiere ich diese.
Was bei mir ein wenig mehr Aufwand ist: ich muss z.B. ein
dcbrowsecol field kd->telnr oder ein dcget kd->telnr entsprechend anpassen.
Gruß
Klaus
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: DSGVO

Beitrag von ramses »

Tom hat geschrieben: Do, 12. Aug 2021 14:27 Und ein verschlüsseltes Dateisystem hilft Dir nicht, wenn die Nutzer - wie bei DBF-Datenbanken üblich - Vollzugriff auf die Datenverzeichnisse haben müssen.
Da hast du recht. Daran habe ich gar nicht mehr gedacht!
Ich war in Gedanken beim Schutz der Daten gegenüber Aussenstehenden Dritten.
Die Betriebsangehörigen haben durch die vielen Listen/Export/Transferfunktionen sowieso Zugriff auf die Daten.
Da bringt es nicht viel z.B. die Telefonnummer in einer DBF zu Verschlüsseln und daneben bestehen die Umfangreichen Listen/Transferfunktionen.
Bei uns ist der gewollte Schutz der die Daten vor Diebstahl der Datenträger usw. durch Aussenstehende zu schützen

Bei den neueren Web-Apps sehen die User die Datenverzeichnisse gar nicht mehr, da ist es einfacher mit einem verschlüsselten Dateisystem zu arbeiten weil Softwaremässig gar kein Aufwand mehr anfällt und auch die PG Datenbanken automatisch voll verschlüsselt sind.
Valar Morghulis

Gruss Carlo
Antworten