DSGVO Daten verschlüsseln

[KingofKning]

Tja, wenn Du den bösen Buben schon mal spezifizieren kannst, kannst Du ihn auch aussperren. Es gibt ja Produkte die jeden ODBC-Zugriff limitieren können.

Vielleicht hilfrt ein wenig nachdenken den günstigsten Weg zu finden bevor man sich zuviel Arbeit macht.

GG 4434

[BenderD]

Tja, wenn Du den bösen Buben schon mal spezifizieren kannst, kannst Du ihn auch aussperren. Es gibt ja Produkte die jeden ODBC-Zugriff limitieren können.

Vielleicht hilfrt ein wenig nachdenken den günstigsten Weg zu finden bevor man sich zuviel Arbeit macht.

GG 4434

... damit wirst Du in Bezug auf DSGVO keinen Blumentopf gewinnen, nicht mal einen Trostpreis.

D*B

[BenderD]

... falls ihr wenigstens einigermaßen aktuell seid (V7Rx), könnte FIELDPROC noch was hergeben, müsste aber vorab juristisch und technisch evaluiert werden.

D*B

[ILEMax]

Danke, schau ich mir an ...

@alle
Seid Ihr alle so 'Modern' das Euch das nicht betrifft?
Oder ignoriert Ihr diese Anforderung aus der DSGVO?
Oder sogar die ganze DSGVO?

der ILEMax

[Fuerchau]

https://www.security-insider.de/9-ds...arnt-a-673986/

Siehe vor allem auf Punkt 9
Wichtig ist hier insbesonders die Aussage:

"Ob eine Verschlüsselung zum Einsatz kommen soll oder nicht, hängt somit von dem zu ermittelnden Schutzbedarf der Daten, dem Risiko für die Betroffenen sowie weiteren Faktoren ab wie Stand der Technik, Implementierungskosten und Art, Umfang, Umstände und Zwecke der Verarbeitung. Verschlüsselung ist also kein Automatismus, sondern eine wichtige Maßnahmen bei entsprechendem Bedarf an Schutz für die Vertraulichkeit der Daten."

Wenn die Datenbank also keine Verschlüsselung hergibt, ist es auch nicht erforderlich. Man muss da halt andere Schutzmaßnahmen treffen.

Mit SQL kann man ab V7R2 oder R3 eine Anonymisierung / Maskierung von Daten vornehmen.
D.h., dass insbesonders bei SQL-/ODBC-Zugriffen sicherheitsrelevante Informationen verfälscht werden.
Zusätzlich konnte man ja vorher schon mit Berechtigungen und Views den Zugriff auf Daten beschränken.

Birgitta hatte dazu in der letzten Midrange einen Beitrag geschrieben (da wurde das Geburtsjahr einer Person z.B. durch 9999 ersetzt).
Wichtig dabei scheint wohl, dass erstmalig auch ein *ALLOBJ-User dann nicht mehr an alles drankommt.
Ob und wie dies auf RLA wirkt, kann ich nicht sagen, da SQL eigentlich erst hinter RLA beginnt.
Allerdings ist der RLA-Zugriff per ODBC (ja, das geht) oder Java-/Toolkit von außen eher selten.

Die Gefahr allerdings ist dabei, dass ich falsche Informationen lese und wenn es in der laufenden Verarbeitung passiert damit dann rechne und ggf. in andere Dateien fortschreibe.
Es ist also organisatorisch nicht ganz so einfach, wie uns die IBM das glauben macht.

[BenderD]

Danke, schau ich mir an ...

@alle
Seid Ihr alle so 'Modern' das Euch das nicht betrifft?
Oder ignoriert Ihr diese Anforderung aus der DSGVO?
Oder sogar die ganze DSGVO?

der ILEMax

... wie bisher auch: wir haben den sichersten Rechner der Welt, vertrauen auf unseren Menüschutz, in unseren Daten kennen wir uns selber kaum aus, unsere Programme sind so alt, dass sie keiner mehr versteht und außerdem stellen wir sowieso bald auf SAP um...

D*B

[holgerscherer]

... damit wirst Du in Bezug auf DSGVO keinen Blumentopf gewinnen, nicht mal einen Trostpreis.

Nachdenken hat man ja auch nicht beim Schreiben der DSGVO im Hinterkopf gehabt ;-)

-h

[AG1965_2]

... damit sind erst mal alle Schlüsselfelder und ähnliches draußen ...

Vorsicht: Wenn es sich um Begriffe handelt, mit denen eine Person eindeutig identifiziert werden kann UND man diesen Begriff nach außen gegeben hat (wie eben z.B. eine Kunden- oder Kontonummer), ist das auch ein personenbezogenes Datum!
https://www.datenschutzbeauftragter-...che-beispiele/

[BenderD]

Vorsicht: Wenn es sich um Begriffe handelt, mit denen eine Person eindeutig identifiziert werden kann UND man diesen Begriff nach außen gegeben hat (wie eben z.B. eine Kunden- oder Kontonummer), ist das auch ein personenbezogenes Datum!
https://www.datenschutzbeauftragter-...che-beispiele/

... überzeugt, ergänzt: wenn man es richtig macht!!

D*B

[Fuerchau]

"UND man diesen Begriff nach außen gegeben hat"

Welche Veranlassung habe ich diese Daten weiterzugeben?
Für mich steht immer noch der Technologieansatz im Vordergrund:
Wenn der Zugriff von dritten nicht ausgeschlossen werden kann, ist eine Verschlüsselung der Daten sicher sinnvoll.
Allerdings fängt dies beim Terminal ja bereits an.
Wenn ich den Blick von Dritten auf das Terminal nicht verhindern kann, so sind die Daten zu verschlüsseln, m.a.W., auf dem Bildschirm eigentlich bereits unleserlich zu machen.
Der sicherste Weg ist also, alle Personendaten zu löschen und die Verarbeitung einzustellen.

Wer hat sich sowas nur ausgedacht....

[holgerscherer]

Wer hat sich sowas nur ausgedacht....

die gleichen Typen, die zulassen, dass alle Daten von den Einwohnermeldeämtern an den Rundfunk-Gebührenservice weiter gegeben werden...

-h

[Fuerchau]

Muss eigentlich nun die Telefonauskunft auch verschlüsselt werden?