Was bedeutet “Kenntnis”?

Vorbemerkung: Zur Erläuterung der Begrifflichkeiten, die wir hier verwenden, möchte ich auf diesen Beitrag verweisen.

Problemstellung

Es ist wichtig zu verstehen, was “Kenntnis” der Daten im E-ID-Kontext bedeutet. Dies ist relevant in Bezug auf zwei Perspektiven:

  • Kenntnis des IdP
  • Kenntnis der Relying Party

Kenntnis des IdP wird von den Gegnern des BGEID behauptet, wie es die Diskussion der vergangenen Tage gezeigt hat (siehe die Kommentare zum Beitrag hier sowie das Resumé hier).

Das heisst: Es wird gesagt, der IdP könne (und werde) alles beobachten, was in der Schweiz in Online-Dingen geschieht. Mit Kenntnis gleichgestellt werden mitunter Begriffe wie Kontrolle, Wissen, Missbrauch, Einsicht oder Überwachung.

Die umgangssprachliche Formulierung hierfür lautet (z.B. im Artikel “Die Probleme mit der Schweizer E-Identität” im Online-Magazin Republik) wie folgt:

So erfährt es der Identitäts­provider, wenn Lena Fischer sich etwa bei Digitec einloggt, den Kaufvorgang abbricht, später bei Galaxus weitersurft und danach die Steuer­erklärung im Kanton St. Gallen ausfüllt

Adrienne Fichter, “Die Probleme mit der Schweizer E-Identität“, Republik (28.01.2021)

Warum dieser Beitrag? Ich habe ihn z.B. hier angekündigt.

Es geht darum, was Kenntnis heisst. Und das ist ein gar nicht so eindeutiger Begriff, anders als man meint. 

Christian Laux, “Um welche Daten geht es bei der E-ID?“, e-idblog.ch (04.02.2021)

Welche Daten fallen beim Einsatz der E-ID an?

Im Beitrag “Um welche Daten geht es bei der E-ID?” habe ich beschrieben, dass es beim BGEID um die folgenden Daten geht:

  • Personenidentifizierungsdaten
  • Nutzungsdaten
  • Nutzungsprofile

Man könnte noch die im Rahmen der gängigen Internetprotokolle anfallenden Angaben zum Gerät der Nutzerin nennen (Betriebssystem, Browserversion, etc.). Diese zählen wir zu den Nutzungsdaten.

Ausserdem kann man über Inhaltsdaten nachdenken. Solche fallen aber beim IdP nicht an, was allseits anerkannt ist (siehe den Beitrag “IdP sehen keine Inhaltsdaten“).

Unterschied Maschinensicht und Personensicht

Was bei der Analyse von Datenvorgängen oft ausgeblendet wird (so auch im Beitrag “Die Probleme mit der Schweizer E-Identität“): Dass man die Sicht der Personen, die ein System betreiben (hier verwende ich dafür den Begriff Personensicht oder Klartextsicht oder Klartextzugriff), nicht einfach so gleichsetzen darf mit der Datenlage auf einem System (Maschinensicht).

Warum diese Unterscheidung? Wer Maschinensicht mit Personensicht gleichsetzt, nimmt eine gedankliche Abkürzung. Dies verhindert eine klare und nachvollziehbare Diskussion.

Aber wir brauchen eine nachvollziehbare Diskussion. Wer eine solche mit diffusen Argumenten verhindert, untergräbt die Demokratie.

Beschreibung der Maschinensicht

Zunächst geht es um die Ebene der Datenhaltung, d.h. um die blosse Maschinensicht.

Ob es auch Personen gibt, die zusätzlich zur Maschinensicht (Datenebene) noch weitere Erkenntnisse bekommen (Klartextsicht oder Personensicht), behandeln wir später.

Es ist naheliegend, bei Beschreibung der Datenlage zu differenzieren nach Relying Party (zum Beispiel: einem Handelsregisteramt) und dem Identity Provider (IdP).

Datenhaltung bei der Relying Party (Maschinensicht):

  • Nutzungsdaten: Auf den Systemen des Handelsregisteramts entstehen Daten dazu, wer (die Nutzerin) wann und mit wem (dem Handelsregisteramt) interagiert.
  • Inhaltsdaten: Als Inhaltsdaten bezeichnen wir jene Angaben, die beschreiben, was die Nutzerin dem Handelsregisteramt mitteilt. Das Handelsregisteramt hat natürlich eigene Daten (Maschinensicht) darüber, warum die Nutzerin mit ihm interagiert hat (z.B. Gründung einer GmbH).
  • Nutzungsprofil: Wenn die Nutzerin mehr als einmal in wiedererkennbarer Weise beim Handelsregisteramt Meldungen macht, erhält das Handelsregisteramt natürlich so etwas wie eine Querschnittssicht auf die Aktivitäten der Nutzerin. Dass sie z.B. nicht nur Gesellschafterin der GmbH ist, sondern offenbar auch noch Verwaltungsrätin bei der X. AG, etc. Man kann diese Gesamtsicht bzw. Querschnittsbetrachtung als Nutzungsprofil bezeichnen. Das Handelsregister hat dazu eine Maschinensicht.

Datenhaltung beim IdP (Maschinensicht):

  • Nutzungsdaten: Auch der IdP hat auf seinen Systemen eigene Daten, die beschreiben, dass die Nutzerin zu einem bestimmten Zeitpunkt mit dem Handelsregisteramt interagiert hat.
  • Inhaltsdaten: Anders als das Handelsregisteramt hat der IdP auf seinen Systemen keine eigenen Daten darüber, worüber die Nutzerin sich mit dem Handelsregister austauscht.
  • Nutzungsprofil: Der IdP erhält bei mehrfachem Einsatz der E-ID durch die Nutzerin auch eine Datenreihe, die man als Nutzungsprofil bezeichnen kann. Einzelne Datenpunkte werden dabei allerdings nur für maximale 6 Monate (je nach Use Case für einen kürzeren Zeitraum) gespeichert. Wer die E-ID weniger oft als einmal halbjährlich einsetzt, der kann das Entstehen von Nutzungsprofilen beim IdP also verhindern. Die beim IdP anfallenden Datenpunkte sind inhaltlich enger als jene bei der Relying Party. Der IdP erhält nur Daten dazu, wer (die Nutzerin) wann mit wem (dem Handelsregisteramt) interagiert hat. Inhaltsdaten erhält der IdP wie erwähnt nicht und kann solche Angaben somit auch nicht in das Nutzungsprofil speichern.

Wie sieht die Personensicht auf Daten aus?

Ob es über die Maschinensicht (Datenebene) hinaus noch eine Klartextsicht jener Personen gibt, welche die betreffenden IT-Systeme verwalten (d.h. Personal des Handelsregisteramts für dessen Systeme, einerseits, und Personal des IdP andererseits, für dessen Systeme), ist im Folgenden zu beschreiben, wiederum getrennt für die Relying Party und den IdP:

Klartextsicht (Personensicht):

  • Bei der Relying Party: Eine solche Klartextsicht erfolgt nur dann, wenn die Relying Party keine Prozesse eingerichtet hat, um die Einsichtnahme durch Personen zu verhindern. Nach dem revidierten DSG, das direkt auf die E-ID anwendbar ist, muss die Relying Party Vorgaben von Privacy by Design etc. einhalten und Klartextsichten nur jenen erlauben, die zur Erfüllung ihrer Arbeit zwingend darauf angewiesen sind (Need-to-Know-Grundsatz). Wenn die Relying Party eine Amtsstelle ist, braucht sie in der Regel eine gesetzliche Grundlage.
  • Beim IdP: Auch der IdP untersteht dem revidierten DSG. Auch der IdP muss somit Grundsätze von Privacy by Design einhalten (Art. 7 Abs. 1 revDSG). Was besonders ist: Der IdP darf keine Mutmassungen anstellen über die Interaktionen der Nutzerin bei der Relying Party. Das wäre eine Bearbeitung von Personenidentifizierungsdaten. Solche Beobachtungen oder Mutmassungen sind verboten (Art. 9 Abs. 1 BGEID). Ein IdP, der solche Beobachtungen anstellen würde, würde seine Anerkennung verlieren.

Selbstverständlich beschreibt dies erst die gesetzliche Sicht auf die Zusammenhänge. Anknüpfend geht es dann um die Frage, wie IdPs kontrolliert werden.

Was die E-ID-Gegner zu Recht vortragen

Es wird zu Recht gesagt, dass jeder, der ein technisches System (Maschinensicht) kontrolliert, am Ende auch die Daten auf dem System ansehen kann (Personensicht).

Was die E-ID-Gegner aber unterstellen

Der Umstand allein, dass auf einem System Daten gehalten werden (Maschinensicht auf dem Code Layer), bedeutet noch nicht, dass diese Daten auch inhaltlich von einem Menschen gelesen werden (Personensicht auf dem Content Layer).

Dies kann zwar sein, ist aber kein Automatismus. Es handelt sich um ein Risiko.

Risikobewertung nötig

Risiken muss man abwenden. In der IT spricht man von “Mitigieren”. Das ist eine recht schwierige Wortwahl. Sie will sagen: Man muss das Risiko und seine Wirkung (“Impact”) abmildern.

In der Informationstechnologie besteht Konsens darüber, dass man Risiken mit anerkannten technischen und organisatorischen Massnahmen abmildern muss – und zwar für solange, bis Eintretenswahrscheinlichkeit und Auswirkungen genügend reduziert wurden. Genügend meint, dass das Risiko nach Vollzug der Massnahmen als annehmbar erscheint. Eine Welt ganz ohne Risiko gibt es nicht. Das ist ebenfalls anerkannt.

Was auch anerkannt ist: Dass es nicht nur “das eine” Lösungsdesign gibt. Aber es kann sein, dass ein weniger vorteilhaftes Lösungsdesign mehr Massnahmen (sprich: mehr “Mitigation”) benötigt, bis man von einem annehmbaren Risiko sprechen kann.

Risiken müssen konsequent bewertet und kontrolliert werden. Das DSG wie auch das BGEID sehen entsprechende Mechanismen vor.

Direttissima

Nochmals: Die E-ID-Gegner unterstellen einen Automatismus. Damit ersparen sie sich die Aufgabe einer nüchternen Risikobeurteilung.

Das ist ein Abkürzung im Gedanken. Über eine solche Direttissima habe ich hier geschrieben: Gefühle in der IT.

Das könnte Dich auch interessieren...

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert