Kryptografie erscheint in Datenschutzgesprächen oft als einzelnes Kästchen: verschlüsselt oder unverschlüsselt. Ein Softwarebefund ist selten so vollständig. Ein Scanner kann einen verdächtigen Speicherpfad oder eine unsichere Funktion finden. Er weiß damit noch nicht, welche Daten betroffen sind, wer darauf zugreifen kann, welche Schutzmaßnahmen außerhalb des untersuchten Codes existieren oder ob die Daten überhaupt gespeichert werden mussten.
Diese Lücke ist ein gutes Beispiel für PrivDev, meine Forschung zur Verbindung technischer Befunde mit Datenschutzbegriffen. Die umgesetzte erste Schicht ordnet Datentyp-Bezeichnungen eines Scanners einem gemeinsamen Vokabular zu. Eine spätere Forschungsfrage lautet, wie Befunde zu Software-Schwachstellen Entwicklern helfen können, ohne aus einem technischen Hinweis ein rechtliches Urteil zu machen. Bei Kryptografie wird deutlich, warum die Unterscheidung wichtig ist.
Ein Befund hat eine Grenze#
Angenommen, ein Scanner meldet, dass ein Wert im localStorage des Browsers landet, und findet auf dem untersuchten Pfad keine Verschlüsselung. Was lässt sich sicher sagen? Wir können den gemeldeten Codepfad benennen, gegebenenfalls die Herkunft des Werts und das Fehlen eines Verschlüsselungsaufrufs auf diesem Pfad. Daraus folgt weder, dass das gesamte System keinen Schutz besitzt, noch, dass Verschlüsselung den Entwurf angemessen machen würde.
Mehrere Fragen verändern die Bewertung. Ist der Wert personenbezogen oder ein Testwert? Ist er ein kurzlebiges Token, eine Kontaktadresse oder eine medizinische Notiz? Können Skripte der Seite darauf zugreifen? Wie lange bleibt er gespeichert? Greift auf dem Server ein anderer Schutz? Gegen welchen Angreifer soll das System geschützt werden? Je nach Antwort kann es sinnvoll sein, den Speicherort ganz zu vermeiden, die Daten zu begrenzen, Zugriffe anders zu steuern oder eine kryptografische Maßnahme zu verwenden.
Damit soll ein offensichtlicher Sicherheitsfehler nicht vertagt werden. Es geht darum, den Befund so genau zu formulieren, dass die zuständige Person handeln kann. „Auf dem untersuchten Codepfad keine Verschlüsselung sichtbar“ gibt einem Entwickler einen konkreten Ansatz. „Die Anwendung verstößt gegen die DSGVO und braucht Feldverschlüsselung“ behauptet Tatsachen, die der Scan womöglich nicht ermittelt hat.
Warum Datenschutz mehr als ein Sicherheitslabel braucht#
Sicherheitstaxonomien ordnen technische Schwachstellen. Datenschutz fragt zusätzlich nach Zweck, Notwendigkeit, Empfängern, Speicherdauer und Betroffenenrechten. Eine Schwachstelle wie Klartextspeicherung kann für Vertraulichkeit relevant sein. Ihre rechtliche Bewertung hängt jedoch von der Verarbeitung und ihren Umständen ab. Selbst wenn Verschlüsselung passt, sind die Details entscheidend: Was wird verschlüsselt? Wo liegen die Schlüssel? Wer kann entschlüsseln? Was geschieht nach der Entschlüsselung? Ein Label beantwortet das nicht.
Die DSGVO nennt in Artikel 32 Verschlüsselung als mögliche Maßnahme einer risikobezogenen Bewertung. Sie macht aus einer Scannerwarnung keine automatisch vorgeschriebene Implementierung. In den PrivDev-Notizen werden deshalb die beobachtete Schwachstelle, eine mögliche Maßnahme und ein Anlass zur rechtlichen Prüfung getrennt. Jede Verbindung dazwischen braucht eigene Belege und fachliche Kontrolle.
Eine Brücke, die auf eine Aussage verzichten kann#
Eine wichtige Lehre aus der ersten Mapping-Schicht des Projekts war eine Korrektur: Frühe Ergebnisse behaupteten bestimmte DSGVO-Bezüge schon aus Datentyp-Bezeichnungen und enthielten Kennungen, die im verwendeten Vokabular fehlten. Die Methode wurde überarbeitet, um Kategorien sauber zu trennen und bei schwachen Belegen auf eine Zuordnung zu verzichten. Für kryptografische Befunde sollte diese Disziplin erst recht gelten. Auch eine deterministische Regel kann eine falsche Annahme in eine formal saubere Ausgabe verwandeln.
Ein nützlicher Hinweis für Entwickler könnte vier Teile enthalten: die genaue Beobachtung des Scanners, den möglicherweise betroffenen Sicherheits- oder Datenschutzbegriff, die offenen Fragen und konkrete Prüfschritte. Er sollte auf den Code verweisen und Annahmen kenntlich machen. Dann kann eine Datenschutzfachperson den rechtlichen Kontext beurteilen, während ein Entwickler den technischen Pfad und vorhandene Schutzmaßnahmen prüft.
Das ist ein Vorschlag für die Darstellung späterer PrivDev-Forschung, keine bereits validierte Funktion eines fertigen Produkts. Layer 1 klassifiziert Datentyp-Bezeichnungen. Die Schritte von einer Schwachstelle zu einer Maßnahme oder rechtlichen Pflicht sind weiterhin Forschungsfragen. Ich möchte prüfen, ob ausdrücklich benannte Unsicherheit spätere Hinweise hilfreicher macht, statt nur vorsichtiger klingen zu lassen.
Das Kryptografie-Beispiel hält das Ziel greifbar: Ein Scanner zeigt, wo man nachsehen sollte. Ein Vokabular kann das Problem beschreiben. Über eine Schutzmaßnahme entscheidet man anhand des tatsächlichen Systems und mit klarer Verantwortung.