Martins key.matiq-Blog
>> Zurück zum Artikelverzeichnis >>
Zero-Knowledge+ (4): Schutzniveaus
Geschrieben: 13.05.2022
Stichwörter: Sicherheit, Sicherheit mit Bedienbarkeit
In dem Artikel "Zero Knowledge+ (1): Der 'Cautiously Knowing Service'" habe ich eine differenzierte Herangehensweise für den Datenschutz in einer leistungsfähigen Software as a Service entwickelt. Dabei ist es wichtig, dass die Nutzer*in weiß (bzw. bei Bedarf leicht ermitteln kann), welchen Schutz ihre Daten genießen. Dies führt zur Definition von "Schutzniveaus".
Es geht hier hauptsächlich um Schutz vor Offenlegung
Wenn man von Datenschutz spricht, geht es im Allgemeinen nicht nur um den Schutz vor Offenlegung, sondern auch um den Schutz vor Datenverlust, vor missbräuchlichem Gebrauch von Daten oder vor Verfälschung von Daten.
Neben dem Schutz vor Offenlegung muss jede Software as a Service natürlich auch die weiteren Schutzaspekte immer beachten, aber sie stellen keine allzu große Herausforderung mehr dar, ist die Geheimhaltung erst einmal gesichert.
Deshalb schreibe ich im Folgenden explizit vor allem über den Schutz von Daten vor Offenlegung, aber mit den anderen Schutzaspekten auch im Hinterkopf.
Warum wir mehr als zwei Schutzniveaus brauchen
Meist wird in der Dokumentation von key.matiq von Kerngeheimnissen und Begleitdaten gesprochen. Kerngeheimnisse müssen vor allem vor Offenlegung geschützt werden, Begleitdaten vor allem vor Verlust. Doch wenn es darum geht, den Schutz möglichst gut zu entwickeln und auch den Benutzer*innen transparent darzulegen (weil diese ja auch in Einzelfällen darüber entscheiden können sollen, ob ihren ein besserer Schutz oder eine bessere Funktionalität wichtiger ist) muss man doch etwas differenzierter vorgehen.
Wir stellen dies z. B. bei dem Schutz vor Ausforschungsangriffen fest. Der Boxname oder die E-Mail-Adresse sind gewiss nicht "streng geheim", sollten aber potentiellen Angreifer*innen keineswegs leicht zugänglich gemacht werden. Sie sind aber auch nicht einfach "Begleitdaten".
Standardschutzniveaus
Zunächst macht es Sinn eine Reihe von Schutzniveaus zu definieren, die bei sicheren Web-Diensten zum Einsatz kommen können und für die meisten Daten angewendet werden können. Eine Skala von PL-0 bis PL-5 ("PL" steht für "protection level") erscheint angemessen:
- PL-0 ("Ungeschützte Daten"): Mit diesem (Pseudo-)Schutzniveau wird jeder nicht näher spezifizierte Schutz unterhalb von "PL-1" bezeichnet. Dieses Niveau ist nur angemessen, wenn die Daten bewusst öffentlich zur Verfügung gestellt werden sollen.
-
PL-1 ("Minimaler Schutz"):
Die Daten werden auf einem geschützten Server gehalten. Die Zahl der
Mitarbeiter*innen des Dienstes, die Zugang haben, ist begrenzt und
wohldefiniert. Der Zugang zu dem Server ist durch starke Verschlüsselung
geschützt. Der Server wird von einem zertifizierten Dienstleister betrieben,
oder er befindet sich im Besitz des CKS-Dienstleisters und sein
physikalischer Zugang ist geschützt.
Die schwächste Stelle ist hier der physikalische Zugang zum Server. (Denn wer die Server-Platte kopieren kann, hat den Zugang zu den Daten. Eine Anmeldung ist dafür nicht erforderlich.)
key.matiq benutzt dieses Schutzniveau für Benutzer*innendaten nicht. Dieses Schutzniveau ist jedoch hier beschrieben, da es vermutlich der häufigsten Implementierung von Internetdiensten entspricht, die überhaupt Kund*innendaten seriös schützen. -
PL-2 ("Beschränkung auf reguläre Server-User"):
Die Daten werden auf verschlüsselten Platten auf dem Server gehalten. Die
Schlüssel für diese Platten werden auf dem Server nur im flüchtigen
Speicher (RAM) gespeichert. D. h. beim Reboot müssen sie von außen neu
eingegeben werden. Auch außerhalb des Servers werden die Schlüssel bzw.
Passwörter von denen die Schlüssel abgeleitet werden, geschützt
gespeichert (starke Schutzkette1).
Die schwächste Stelle ist hier der Zugang zum Server über einen Mitarbeiter*innen-Account.
key.matiq benutzt dieses Schutzniveau unter dem Namen "PL-low" -
PL-3 ("Verschlüsselung mit Nutzer*innen-Passwort, serverseitig"):
Die Daten werden mit einem Schlüssel, der vom Kennwort der Kund*in
abgeleitet ist, verschlüsselt. Die Kund*in wird motiviert, ein Kennwort so
zu wählen, dass zusammen mit der Schlüsselstreckung eine starke Schutzkette
erzeugt wird. Die Ver- und Entschlüsselung findet serverseitig statt. Dabei
wird jedoch darauf geachtet, dass Klartexte von Daten und Schlüsseln immer
nur im flüchtigen Hauptspeicher des Servers verfügbar sind und (auch bei
Absturz des Serverprogramms) nie auf die Platte geraten.
Unabhängig davon wird auch der Schutz nach "PL-2" gewährleistet.
Die schwächste Stelle ist hier der Zugang zum Server über einen Mitarbeiter*innen-Account mit Rechten zur Änderung der Software.
key.matiq benutzt dieses Schutzniveau unter dem Namen "PL-medium" -
PL-4 ("Verschlüsselung mit Nutzer*innen-Passwort, clientseitig"):
Die Daten werden wie bei PL-3 mit einem Schlüssel, der vom Kennwort der
Kund*in abgeleitet ist, verschlüsselt. Die Ver- und Entschlüsselung findet
jedoch clientseitig statt, so dass der Server keinerlei Klartexte der Daten
bzw. für die Entschlüsselung der verschlüsselten Daten ausreichender
Schlüssel zur Kenntnis bekommt.
Unabhängig davon wird auch der Schutz nach "PL-2" gewährleistet.
Die schwächste Stelle ist hier der Zugang zum Client (z. B. durch eine Kolleg*in oder Mitbewohner*in der Kund*in). - Dieses Schutzniveau wird von key.matiq nicht benutzt. Es ist jedoch hier beschrieben, da es wohl der üblichen Beschreibung "clientseitige Verschlüsselung" oder "Zero-Knowledge-Server" am ehesten entspricht.
-
PL-5 ("Wie PL-4 aber mit serverseitigem Zusatzschutz"):
Die Daten werden wie bei PL-4 geschützt. Jedoch werden die Daten auf dem
Client zusätzlich geschützt, indem serverseitig die Sitzung jederzeit
unterbrochen oder abgebrochen werden kann.
Der Client löscht dann (aber auch bei Unterbrechung der Verbindung zum Server) bei sich sämtliche Klartexte der Daten. Er löscht auch Klartexte von Schlüsseln, soweit nötig, um eine Entschlüsselung von Daten zu verhindern.
Die Kund*in kann die Zeitspanne einstellen, nach der bei einer Kommunikationspause die Verbindung zwischen Client und Server als unterbrochen gilt.
Die schwächste Stelle ist hier die unbemerkte Veränderung der Software durch Unbefugte. Dieses Risiko wird zumindest durch den Einsatz einer Quellcode-Management-Software wie Git oder vergleichbare Maßnahmen minimiert. Das Restrisiko wird im Auge behalten und ihm wird durch unternehmenspezifische Maßnahmen (die nicht immer öffentlich erörtert werden können2) entgegegengewirkt.
key.matiq benutzt dieses Schutzniveau unter dem Namen "PL-high"
Angepasste generelle Schutzniveaus für andere CKS-Dienste
Wer einen Dienst als "Cautiously Knowing Service" bezeichnen möchte, kann durchaus die oben bezeichneten Standardschutzniveaus für sich modifizieren, sollte sich aber grundsätzlich an das Schema halten und muss die Abweichungen den Benutzer*innen des Dienstes gegenüber dokumentieren.
Spezialisierte Schutzniveaus
Generelle Schutzniveaus können zwar die Masse der Daten abdecken, aber in der Regel gibt es immer einige Daten, die bezogen auf den Schutz "zwischen den Ebenen" liegen. Um auch hier eine Systematik hineinzubekommen, sollten Schutzniveaus "PL-0+", "PL-1+" usw. dienst- und datentypbezogen definiert werden. "PL-1+" bedeutet: Das Schutzniveau "PL_1" ist garantiert, zusätzlich gibt jedoch weitere Schutzmechanismen, die dann für bestimmte Datenarten noch im Einzelnen spezifiziert werden.
Werden z. B. Abfragen auf prinzipiell ungeschützte Daten durch Captchas gebremst, so könnte man dies unter das Schutzniveau "PL-0+" fassen.
Z. B. kann bei key.matiq nicht komplett ausgeschlossen werden, dass eine Angreifer*in online herausbekommt, ob eine Box unter einem bestimmten Namen oder mit einer bestimmten E-Mail-Adresse existiert3, aber key.matiq kann dies durch Vorkehrungen4 gewaltig erschweren. Dieser Schutz ist also also unter "PL-0+" zu beschreiben.
CKS-Version
Das oben Gesagte ist bezüglich der allgemeinen Definition eines "Cautiously Knowing Service" gültig ab Version 0.4.
1) Als starke Schutzkette sehen wir an, wenn ausser dem Passwort, von dem alles abgeleitet wird, nur starke, zufällig gewählte Schlüssel und starke Verschlüsselungsalgorithmen verwendet werden. Auch das Passwort sollte einem starken Schlüssel entsprechen.
2) Weitere Maßnahmen sind meist nicht trivial und könnten daher evtl. durch Angriffsszenarien konterkariert werden, wenn man mal von Allgemeinplätzen wie "gute Mitarbeiter*innenwahl" absieht. D. h. hier läuft es auf Strategien hinaus, die nicht 100-prozentig sicher sein können, sondern "nur" das Risiko deutlich drücken können, was aber eben dann besser gelingen kann, wenn diese Maßnahmen nicht öffentlich diskutiert werden.
3) Diese Möglichkeit wertet den Schutz, der ansonsten bei PL-2 (bzw. PL-low) liegt, zunächst auf PL-0 ab. (Erst die folgenden Überlegungen ermöglichen, ihn schließlich, bei Beschreibung der zusätzlichen Schutzmaßnahmen auf PL-0+ aufzuwerten.)
4) Siehe "Zero Knowledge+ (3): Erkundungsangriffe".