Thema: privacy-engineering
-
Eine Anfrage einer betroffenen Person als Engineering-Prozess behandeln: Export und Löschung
Die Anfrage einer Person auf eine Kopie oder Löschung ihrer Daten wie einen Auftrag behandeln: geprüfte Aufnahme, ein Exporter pro Datenspeicher aus der Daten-Landkarte, der ein Manifest erzeugt, Auslieferung über einen befristeten authentifizierten Download, Löschung über die Pipeline, dokumentierte Ausnahmen mit Begründungscodes sowie ein Test mit einer synthetischen betroffenen Person in festem Rhythmus; welche Anfragen erfüllt werden müssen und bis wann, wird hier nicht behandelt.
-
Differential Privacy in einem Absatz, und wo sie nicht passt
Differential Privacy begrenzt, wie stark der Datensatz einer einzelnen Person die Ausgabeverteilung eines Abfragemechanismus verändern kann, indem kalibriertes Rauschen hinzugefügt und jede Antwort einem Budget belastet wird; sie passt zu wiederholten aggregierten Veröffentlichungen über grosse Populationen und passt nicht zu Datensätzen auf Einzelfallebene, kleinen Gruppen, exakten Operationen oder einmaligen internen Analysen.
-
Datenschutz-Prüfliste für ein Feature
Zehn Fragen, die eine prüfende Person beantwortet, bevor ein Feature live geht: Inventar neuer personenbezogener Daten, Minimierungsentscheidungen, Aufbewahrungsjob, Zugriff und Zugriffsprotokollierung, Abdeckung von Export und Löschung, Präferenzzwecke, Drittanbieter-Abläufe, ein kurzer LINDDUN-Durchgang, Testdaten und ein festgehaltenes Ergebnis; nur technische Eigenschaften, keine rechtliche Beurteilung.
-
Testdaten ohne personenbezogene Produktivdaten
Entwicklungs-, CI- und Staging-Umgebungen realistische Daten geben, indem man sie generiert: Spalten klassifizieren, geseedete Generatoren schreiben, die die Validatoren der Anwendung bestehen, Volumen mit generate_series erzeugen, aus der Produktion nur Verteilungen übernehmen, generierte Datensätze erkennbar markieren und den Abkürzungsweg «einfach Prod dumpen» entfernen.
-
Einwilligungs- und Präferenzdatensätze als Daten: was wann und über welche Oberfläche gewählt wurde
Die Entscheidungen einer Person als Append-only-Ereignisse modellieren (betroffene Person, Zweck, Entscheidung, Zeitpunkt, Quelle, Textversion) mit einer abgeleiteten Sicht auf den aktuellen Zustand, die jeder Konsument am Verwendungsort liest; ein Boolean in der Benutzerzeile kann nicht beantworten, was zum Zeitpunkt einer bestimmten Aktion vereinbart war oder welche Benutzer ein Banner-Fehler betraf.
-
Zugriffslogs für personenbezogene Daten: festhalten, wer welchen Datensatz gelesen hat
Ein Zugriffslog für personenbezogene Daten erfasst Lesezugriffe, nicht nur Schreibzugriffe: Akteur, betroffene Person, Objekt, Grund und Zeitpunkt, ausgelöst im Lesepfad der Anwendung und abgeglichen mit Statement-Logging auf Datenbankebene für Pfade, die daran vorbeiführen; es muss personenzentrierte Fragen beantworten wie: Wer hat sich im letzten Jahr den Datensatz dieser Person angesehen?
-
Wenn Lesezugriffe auf Tabellen mit Personendaten für das Team sichtbar gemacht werden, sinkt die Zahl breiter Abfragen auf diese Tabellen
Hypothese: Sobald jede Anweisung gegen Tabellen mit Personendaten protokolliert wird (PostgreSQLs log_statement legt fest, welche SQL-Anweisungen protokolliert werden) und das Protokoll dem Team in einer wöchentlichen Zusammenfassung gezeigt wird, sinkt der Anteil breiter Lesezugriffe (ohne Prädikat auf eine Personenkennung, oder mit einer Wildcard-Spaltenliste), während die Zahl der legitimen engen Lesezugriffe gleich bleibt; ein vorgeschlagener Vorher-Nachher-Test, ohne beanspruchtes Ergebnis.
-
Datenminimierung als Disziplin für Schema und Protokollierung
Nur die Personendaten speichern, die ein Feature benötigt, in der gröbsten Genauigkeit, die dem Zweck genügt, und Kennungen durch Allowlisting von Feldern aus Logs heraushalten; jede Spalte, jedes Logfeld und jeder abgeleitete Speicher, der Personendaten trägt, ist eine Designentscheidung mit einem Zweck, einer verantwortlichen Person und einem Ablaufdatum, kein Standardfall.
-
Eine Aufbewahrungsfrist als Löschjobs umsetzen
Eine Aufbewahrungsfrist ist erst real, wenn jede Datenklasse über einen Mechanismus verfügt, der pünktlich löscht: Partitions-Drops bei zeitpartitionierten Tabellen, Lifecycle-Regeln beim Objektspeicher, andernorts batchweise idempotente DELETE-Jobs, jeweils mit einer Metrik für den ältesten verbleibenden Datensatz und einem Alarm, wenn dieses Alter die Frist überschreitet.
-
How do teams verify that a deletion removed every copy of a person's data, and what did the verification find?
Open question: a deletion job reporting done is not the same as the data being gone (dead row versions before VACUUM, object versions, caches, indexes, analytics copies, backups, logs, third parties); which teams verify end to end, by which method, and which stores still held data after a completed deletion?
-
Pseudonymisation versus anonymisation as engineering techniques
Pseudonymisation swaps direct identifiers for tokens while keeping a way back (a key or a lookup table) and leaves one record per person; anonymisation aims to remove the association between records and people for everyone. Use keyed HMAC per purpose for pseudonyms, and treat a pseudonymised table as personal data with quasi-identifiers still in it.
-
Privacy threat modelling with LINDDUN in outline
Walk a data flow diagram element by element against the seven LINDDUN threat types (linking, identifying, non-repudiation, detecting, data disclosure, unawareness and unintervenability, non-compliance), record scenarios per element, and pick mitigations from a short menu; a one-session format modelled on a STRIDE session.
-
Deletion pipelines across services, derived stores and backups
Model deletion of one person's data as a job with a state per store in the data map: fan out an event, require each owning service to report done with counts, handle versioned object storage and derived stores explicitly, bound how long backups keep the data or destroy per-subject keys, and keep a suppression list so restores can re-delete.
Maschinenlesbar: JSON