SQL Was muss ich beim Design einer Datenbank beachten, um dem Recht auf Löschung durch Vernichtung btw. Entfernung der Daten zu entsprechen?

[Kristatos]

Ich würde sagen das Eintragen eines Anlage- und eines Löschdatums. So können ganz einfach nach Verstreichen der Speicherfristen diese automatisiert und regelmäßig entfernt werden.

 

[nutrix]

Und hier würde ich Antworten: Das sollte bereits im Datenschutzkonzept durch den Datenschutzverantwortlichen niedergeschrieben sein, und daran hat man sich zu orientieren

Denn wenn es nicht definiert ist durch das Datenschutzkonzept, na dann "Arbeitskreis" bilden haha

Kannst Du an der Stelle leider nicht so machen, weil Du ja der Techniker und IT-ler bist, der den Auftrag bekommt, daß so zu realisieren. 😉 Sprich, Verwaltung und Datenschutzkonzept ist hier nicht Deine Aufgabe.

Ergänzung (18. September 2023)

Oooooh. manche Prüfer in der mündlichen wollen keine Zweifel oder Gegenfragen.
:
Gab Punktabzug, obwohl ich ja mit Wissen über die Anzahl der Schnittstellen geglänzt hab.

Der Abzug blieb übrigens auch nach Beschwerde bei der IHK bestehen.

Ja, so auch meine Erfahrung. Die können überhaupt keine Leute leiden, die es besser wissen oder können, sie wollen nur ihren alten Mist bestätigt sehen.

Ergänzung (18. September 2023)

Ich würde sagen das Eintragen eines Anlage- und eines Löschdatums. So können ganz einfach nach Verstreichen der Speicherfristen diese automatisiert und regelmäßig entfernt werden.

Das ist eine sehr gute Antwort und würde ich so als Prüfer als ein Punkt von 3en sehen.

 

[xammu]

Vergesst nicht die Daten dann auch zeitnah aus den Backups zu löschen. Oder im Falle eines Restores auch sofort wieder.

 

[nutrix]

@nutrix jop. Es ist wirklich Privacy by Design, denn hier geht es ja um die technischen Aspekte sowie die dazugehörigen TOMs. Meine Vorschläge sind eine Kombi aus dem Löschkonzept sowie IT-Sicherheitsrichtlinie, Verantwortungs Matrix usw. Aber das geht schon mehr richtung ISMS 27001

Mag ja für richtige Anwendung im Beruf so richtig sein, aber das ist a) eine Prüfung b) die Prüfer, die meistens wenig Ahnung haben und c) es wird das Design angefragt. Design kümmert sich eben nicht um Gesetze und Prozesse. 😉

 

[chr1zZo]

@DeepComputer also ich denke es ist einiges zusammen zu kommen, und du hast noch paar Tage Zeit zum lernen und dich schlau zu machen.

Nächstes mal bissel früher Anfangen Und was ich echt klasse finde, sind hier die User im Forum, die sich so toll mit einbringen für das bestehen deiner Prüfung. Gute Ansätze, ich mag solche Themen und die Teilnahme daran

 

[nutrix]

Vergesst nicht die Daten dann auch zeitnah aus den Backups zu löschen. Oder im Falle eines Restores auch sofort wieder.

Wenn der TS meinem Hinweis folgt bzw. es richtig implementiert, ist das gar nicht mehr notwendig. Das wird heute sogar praktisch so - zumindest in meinen bekannten Projekten - so gelöst.

 

[TorenAltair]

@michi_z1981 Da bin ich mir immer treu geblieben. Ich muss für mich meine Antworten akzeptieren und mit dem Selbstverständnis (wenn ich falsch liege, dann liege ich falsch und akzeptiere das aber auch) beantworte ich auch Fragen, auch wenn es anderen Leuten nicht passen mag. Aber wenn man das argumentativ macht, hat man mMn nach schon gewonnen.

 

[michi_z1981]

hat man mMn nach schon gewonnen.

Ja , ich geb dir voll Recht.
Aber deswegen steht dann im Endeffekt die Sturheit eines einzelnen immer noch in meinem Abschluss.

 

[Rexaris]

Ich bin zwar kein Datenbank-Profi, aber für mich klingt das so, als sollte die DB so angelegt werden, dass die Personenbezogenen Daten alle in einer Tabelle gespeichert werden und nur über IDs mit anderen Tabellen verknüpft sind.
Dann kann man die Personenbezogenen Daten löschen ohne den Rest seiner Daten zu korrumpieren.

Bsp. Bestellungen. Da möchte ich für meine Bilanz nicht den ganzen Bestellvorgang löschen, sondern nur die damit verknüpften Kundendaten.

 

[nutrix]

Ich bin zwar kein Datenbank-Profi

Dann bewirb Dich mal schnell dafür, das ist genau die Lösung. Gerade wenn dann auch Logs länger über Jahre archiviert werden müssen, ist das die einzige ganzbare Lösung.

 

[DeepComputer]

Ja, wirklich vielen Dank an alle!

Also die Antworten (die ich mir jetzt rauspicke) wären:
1. PBD (Personen bezogene Daten) gesondert speichern.

als sollte die DB so angelegt werden, dass die Personenbezogenen Daten alle in einer Tabelle gespeichert werden und nur über IDs mit anderen Tabellen verknüpft sind.

2. Automatische Löschung nach einem gewissen Zeitraum, wenn nicht mehr benötigt.

Ich würde sagen das Eintragen eines Anlage- und eines Löschdatums. So können ganz einfach nach Verstreichen der Speicherfristen diese automatisiert und regelmäßig entfernt werden.

3. Löschung aus Back ups

Genauso mit den bisherigen Logs, die Daten enthalten, was mußt Du machen, damit diese, selbst nach dem Löschen nicht mehr den Benutzer enthalten? Hinweis, die Logs müssen weiter aufbewahrt werden.

nur bei den Logs bin ich mir noch unsicher - muss ich die anonymisieren?

 

[nutrix]

nur bei den Logs bin ich mir noch unsicher - muss ich die anonymisieren?

Ja, das wäre eine Lösung, oder das die Referenz entfällt, so daß Rückschlüsse auf die Person gezogen werden kann. Sprich, Du hast zu einer Bestellung eine ID, und wenn man die ID den Bezug (Referenz) nicht mehr zurückverfolgen oder wieder herstellen kann, gilt das als anonymisiert. Praktisch hängt man hier sogar noch eine Verschlüsselung der ID dran, und wirft den Schlüssel nach dem Löschen einfach weg.😉

Dieser Punkt ist auch wichtig:

Ergänzung (19. September 2023)

5. Die Löschung wurde protokolliert. Protokollierungskonzept.

Daher führe mal eher mehr als 3 Punkte an. Zuviel schreiben ist hier besser als zuwenig.

Also die Antworten (die ich mir jetzt rauspicke) wären:
1. PBD (Personen bezogene Daten) gesondert speichern.

Kann man so machen, aber hier würde ich als Prüfer Dich ganz gemein ausfragen und hinterfragen? Was bedeutet für Dich "gesondert speichern". Das ist technisch ganz schön kompliziert und aufwendig, wenn Du dann immer separate Dateien, oder sogar eine separaten Datenbank dafür verwenden würdest. Praktisch macht das keiner so.

Viel wichtiger ist das, was der Kollege oben geschrieben hat.

Ich bin zwar kein Datenbank-Profi, aber für mich klingt das so, als sollte die DB so angelegt werden, dass die Personenbezogenen Daten alle in einer Tabelle gespeichert werden und nur über IDs mit anderen Tabellen verknüpft sind.

Referenzen nennt man das. Eine vergebene Kundennummer ist eine solche Referenz. Geht der Bezug Kundennummer (hier vom Kollegen als ID bezeichnet) zur Person verloren, gilt das als anonyisiert bzw. gelöscht.

Man könnte sorum als technisches Design argumentieren:

1. In allen weiteren Daten (bzw. DB-Strukturen und Tabellen) personenbezogene Daten unbedingt vermeiden (eben auch Logs, Backups, Transaktionen...).
2. Personendaten streng trennen von Nutz- und Laufzeitdaten trennen. Achtung, das ist was anderes, was Du oben sagtest, mit Personendaten separat speichern, das ist, wie ich es Dir aufzeigte, unzureichend wie mißverständlich und kann unterschiedlich interpretiert werden.
3. In allen Daten nur mit Referenzen über IDs, Kundennummer etc. arbeiten (hier als Beispiel eine Bestellung verwenden).
4. Anlege- und Löschdatum vorsehen
5. Ebenso kaum erwähnt, Du mußt eine Löschroutine (als Programm wie Script oder per SQL) vorsehen, die auch alle vorhandenen personenbezogenen Daten korrekt findet und entfernt
6. Protokolle, Infos fürs Löschen vorsehen
7. Und ganz wichtig, was noch keiner hier so erwähnt hat, Prüf- wie Suchroutinen vorsehen, um die erfolgreiche Löschung zu bestätigen! In einem Audit muß man z.B. nachweisen können, daß die Person in dem DBS nicht mehr auffindbar ist bzw. keine Referenzen mehr erstellt werden können.

Daher gleich mal angewöhnen, auch wenn es nervt, möglichst extakt, widerspruchsfrei und klar das Design bennenen, weil das mußt Du später, wenn Du wirklich Konzepte dazu beruflich verfaßt, eh so exakt wie möglich formulieren. Ansonsten gibt es später Interpretations- wie Implementierungschaos. 😔

Als pragmatischer Ansatz arbeitet man hier auch mit Verschlüsselungen der personenbezogenen Daten bis hin zu den IDs, weils die Sache einfacher macht. Es ist aber als DB-Design so nicht explizit erforderlich, und wäre dann als Idee bzw. Punkt ein Sahnehäubchen. Je nach Prüfer wäre das ein Punkt oder nicht, der wieder interpretationswürdig wäre.

 

[Drexel]

Ich bin zwar kein Datenbank-Profi, aber für mich klingt das so, als sollte die DB so angelegt werden, dass die Personenbezogenen Daten alle in einer Tabelle gespeichert werden und nur über IDs mit anderen Tabellen verknüpft sind.
Dann kann man die Personenbezogenen Daten löschen ohne den Rest seiner Daten zu korrumpieren.

Bsp. Bestellungen. Da möchte ich für meine Bilanz nicht den ganzen Bestellvorgang löschen, sondern nur die damit verknüpften Kundendaten.

In der Realität sind gerade Bestellungen und Rechnungen aber Dokumente die lange aufbewahrt werden müssen und auch in der Datenbank unveränderbar sein sollen so lange. Deswegen werden die relevanten Daten zumindest in einigen ERP Systemen die ich kenne kopiert, damit sie sich nicht ändern, wenn sich die Referenz ändert.

 

[_killy_]

Bzgl. DSGVO Konformität:

1) Daten würde ich niemals aus einer DB physisch löschen
2) wenn Aufbewahrungsfrist verstrichen ist, dann werden die Daten anonymisiert
3) alle DSGVO relevanten Datenfelder würde ich separat auf mittels Flag versehen, dass man sehr einfach abgreifen kann, welche Dimensionen überhaupt DSGVO relevant sind und welche Dimensionen hiervon nicht betroffen sind

 

[ayngush]

Also die Fragestellung hat imho nichts direkt mit der EU-DSGVO zu tun und schon gar nichts mit Log-Dateien, Backups oder "physischen Daten" oder sonstigen Vorstößen in diese Richtung. Man muss da schon aufmerksam lesen: "Der Datenschutzbeauftragte des Unternehmens fordert ein Löschkonzept" ... "Der DSB" Das ist derjenige welche, der das Gesamtkonzept im Sinne der Anforderungen, die sich am Ende irgendwo auch aus der EU-DSGVO aber eben auch aus anderen Gesetzen und Vorgaben herleiten lassen konzeptioniert und die GF bei der Gestaltung und Umsetzung berät.

Löschkonzept ist dabei jedoch das Stichwort: Da es aber in der DSGVO bzw. BDSG-Neu nicht geregelt, wie ein Löschkonzept aufzubauen ist, nach dem wie (... was müssen sie beim Design beachten ...) jedoch gefragt wird, bietet es sich an nach anderen Standards ausschau zu halten. Und in der Tat gibt es mit der DIN 66398 genau dafür (Löschkonzept) einen Standard. Dieser Standard besagt, dass man beim Design (grob) folgendes berücksichtigen soll:

1. Datenarten identifizieren und definieren
2. Löschregeln aus Startzeitpunkt und Löschfrist erstellen
3. Löschklassen bilden, die Datenarten Standardlöschregeln zuordnet.

Edit: Und darüber hinaus natürlich so Sachen wie Verantwortliche benennen usw. Das hat aber mit Datenbankdesign nichts mehr zu tun.

Viel Spaß beim pauken, das ist ein ätzend trockenes Thema, welches in der Praxis (meiner Erfahrung nach) auch völlig anders gehandhabt wird, als es in Prüfungen abgefragt wird. Genau wegen solchen "Gesamtunfug" jault die Wirtschaft bei uns momentan auch wegen Überregulierung herum.

Grüße

 

[Drexel]

Deine 3 Punkte haben für mich aber wenig mit dem Design der Datenbank zu tun, wonach aber explizit gefragt wird. Für mich ist die Frage relativ unsinnig, nach dem Design der Applikation oder der Prozesse zu fragen wäre deutlich sinniger.

 

[ayngush]

Es ist explizit nicht nach dem technischen Datenbankdesign gefragt, sondern danach, welche drei Punkte man im Bezug auf ein Löschkonzept bei dem Design einer Datenbank berücksichtigen muss. Und das sind eben die Drei punkte: Datenkategorien definieren, Löschregeln definieren, Löschklassen bilden

 

[nutrix]

Nope, Du hast die Anforderung nicht richtig gelesen:
https://www.computerbase.de/forum/t...r-daten-zu-entsprechen.2160863/#post-28617962
Du beantwortest den ersten Satz.

"Der Datenschutzbeauftragte Ihres Unternehmens verlangt bei jeder neuen Anwendung im Unternehmen ein Löschkonzept.

Der ist aber nicht gefragt, sondern der 2. Satz.

Was müssen Sie beim Design einer Datenbank beachten, um dem Recht auf Löschung durch Vernichtung btw. Entfernung der Daten zu entsprechen? Geben Sie drei Punkte an."

@DeepComputer
Habt Ihr etwa genau die DIN 66398 im Unterricht durchgenommen?

Nur mal so, ich mache das schon sehr lange mit allerhand Konzepten, und ich habe von dieser DIN Norm und deren Begrifflichkeiten so noch nirgendwo was gehört. Wir haben in allen Datenbankmodell mit solchen Begriffen wie Datenarten, Datenkategorien und Löschklassen nirgends so gearbeitet oder laut DSGVO bzw. Datenschutzrichtlinien so mit diesem Begriffen umgesetzt. Theorie und Praxis wiedermal. Gut, wenn man das so in der Ausbildung gelernt hat (und da mußte dann bestimmt irgendwo das mal im Unterricht oder in den Unterlagen erwähnt worden sein), dann muß man das wohl oder übel so auswendig lernen.

Gerade hier merkt man immer wieder die Schwächen solcher Normen
https://www.din-66398.de/inhalt/detailsinhalte/inhalte_begriffe.html#loeschregel

"Datenart" im Verhältnis zur "Datenkategorie"​

Die DIN 66398 entstand vor der Verabschiedung der DSGVO. Der Begriff der Datenkategorie wurde damals im Datenschutz noch nicht verwendet. Nachdem die DSGVO in Kraft getreten war, wurde in Projekten diskutiert, ob der Begriff der Datenart zur Datenkategorie gewechselt weren soll. Wir haben davon jedoch in den meisten Fällen Abstand genommen. In Projekten zeigt sich, dass die Unterscheidung der beiden Begriffe hilfreich für Diskussionen ist.

Das ist so typisches Behördengeschwätz, was sich dann wieder vielfach in den Konzepten und Begriffen widerspricht oder veraltet ist.

Schon alleine der Begriff Datenart wird hier vollkommen anders verwendet:
https://www.din-66398.de/inhalt/detailsinhalte/inhalte_begriffe.html#datenart

Datenart​

Unter einer Datenart versteht die DIN 66398 eine Gruppe von Datenobjekten, die zu einem einheitlichen Zweck verarbeitet wird. Hintergrund ist, dass mit der Erfüllung des Zwecks die Erforderlichkeit der personenbezogenen Daten nicht mehr gegeben ist. Die Daten sind dann zu löschen. Wenn der Zweck einheitlich ist, folgt daraus eine gemeinsame Löschregel.

Die wichtigsten Kriterien für die Bildung der Datenarten in einer Organisation sind:

• die fachlichen Zwecke in den Geschäftsprozessen
• die Rechtsgrundlagen für die Verarbeitung
• die Betroffenen

Die Informatik verwendet Datenart=Datentyp
https://de.wikipedia.org/wiki/Datentyp

Und schon ist die Verwirrung komplett. Und dann haben wir einen Datensatz bzw. eine Tabelle wie Bestellung, wo eine Kundennummer einem Artikel zugeordnet ist. Wenn die Kundennummer nicht mehr zuordbar ist, gibt es keine personenbezogenen Daten in dieser Tabelle mehr. Laut der oberen Vorschrift ist diese "Datenart" aber zu löschen, sprich auch die Bestellung selbst. Die wird aber mit Aufbewahrungsfristen versehen, weil ein Händler sehr wohl belegen muß, wieviel er wann verkauft hat (Stichwort Vorsteuer, MwST und Co.), und Steuer auf Gewinne uvm. Da braucht man schon wieder Juristen, die sich mit diesen DIN Normen rumschlagen müssen, um das mit der DSGVO und dem Datenschutz überhaupt unter einen Hut zu bekommen.

 

[ayngush]

Deswegen lässt man seine "Hausaufgaben" (Prüfungsvorbereitung ist auch eine Eigenleistung) auch nicht vom Internet beantworten und lernt aus seinen Mitschriften, Skripten und sonstigen Lernmaterialien, die im Unterricht verwendet und emfpohlen worden sind

Ich weiß ja auch nicht, was die da gelernt haben, ich weiß ja nicht mal um was für eine Abschlussprüfung es geht. Ich leite aus der Fragestellung ab, dass es nicht um technische Details geht, sondern um organisatorische bzw. rechtliche Details. Halt vom Anforderungsmanagement her betrachtet die sogenannten Rahmenparameter. (Was gilt es aufgrund von Vorgaben Dritter bei dem Design einer Datenbank zu beachten)

Dabei kann ich mich natürlich auch irren aber mehr Informationen liegen mir nicht vor.

Es wird übrigens auch unterschiedlich von Datei von Datenbanken zwischen "Juristen" und "Informatikern" und "Entwicklern" gesprochen. Für ein Entwickler ist eine Datenbank so etwas wie der MS SQL Server, für einen Juristen ist das eine Ansammlung von in Beziehung stehenden Daten. Dabei kann eine "juristische" Datenbank auch auf einen Blätterwald gedruckt sein... Und dann bezeichnet man das Ganze manchmal auch einfach willkürlich als "Datei". Oftmals machen das gerne Politiker und Medien, die darüber berichten.

 

[DeepComputer]

Habt Ihr etwa genau die DIN 66398 im Unterricht durchgenommen?

Hallo @nutrix,

Also erstens - die Prüfung ist schon vorbei. Ich werde sie mit Sicherheit bestehen.
Zweitens wollte ich schon früher anmerken, dass das Abgefragte irgendwo mit dem Gelernten korrelieren sollte. Da wir nichts über Löschkonzepte gelernt haben, wird es auch nicht abgefragt werden.
@ayngush lag schon richtig mit seinen 3 Punkten, auch wenn wir diese auch nicht im Detail durchgenommen haben.
Die richtigen Antworten waren:
PBD irgendwie gesondert speichern.
Automatisch löschen, wenn der Zweck wegfällt.
Backups und logs auch löschen/anonymisieren.

Es sollen ja nur ganz allgemeine Konzepte genannt werden, weil es in der Realität ja dann sowieso vom konkreten Fall und Kontext abhängt.

Also streitet euch nicht darüber, wie die Frage zu interpretieren sei - so eine hohe Bedeutung hat sie auch nicht

//sorry für den "sterilen Ton", bin grad ziemlich genervt von der Institution/Prüfung. Nächste Woche habe ich noch praktische und mündliche und danach ist es endlich vorbei.