Schnittstellen bzw. API sind beliebte Mittel, um Daten zwischen verschiedenen Systemen schnell und einfach auszutauschen. Insbesondere bei der Bewertung von komplexen IT-Systemen kann man auf die Information stoßen, dass eine oder mehrere API zu einer anderen Software verfügbar sind. In diesem Beitrag wird erläutert, was man datenschutzrechtlich zu beachten hat.
Der Inhalt im Überblick
Was ist eine Schnittstelle bzw. API?
Bei Schnittstellen wird – allgemein gesprochen – eine Verbindung zwischen zwei verschiedenen Systemen hergestellt. Die API ist ein Akronym für „application programming interface“, zu Deutsch: Schnittstelle zur Anwendungsprogrammierung. Hier geht es also nicht nur um die Verbindung irgendwelcher Systeme, sondern es soll konkret eine Software bzw. ein Anwendungsprogramm mit einem anderen System verbunden werden.
In einem älteren Fachbeitrag zum Thema Schnittstelle kann man die genauen Unterschiede gerne nochmal nachlesen.
So ist es beispielsweise denkbar, dass ein Zeiterfassungstool eine API zu einer HR-Datenbank bereitstellt. Die Stammdaten der Mitarbeitenden, wie Name, vereinbarte Arbeitszeit etc., werden dann nicht nochmal zusätzlich in dem Zeiterfassungstool angelegt, sondern das Zeiterfassungstool bezieht diese Informationen aus der HR-Datenbank. Dies hat den Vorteil, dass die Mitarbeiterstammdaten nur in der HR-Datenbank geändert werden müssen (und nicht zusätzlich in dem Zeiterfassungstool). Ein anderes Beispiel wären Portale für Wohnungssuchen, die eine Schnittstelle zur Schufa-Auskunft bereitstellen, mit denen Mieter per Mausklick den Vermieter die Abfrage bei der Schufa erlauben. Ein separates Anfragen bei der Schufa wird somit obsolet.
Was muss datenschutzrechtlich beachtet werden?
Die Vorschriften der DSGVO sind zu beachten, soweit die Schnittstellen dem Austausch von personenbezogenen Daten im Sinne von Art. 4 Ziffer 1 DSGVO dienen und der Anwendungsbereich der DSGVO eröffnet ist.
Die französische Aufsichtsbehörde CNIL hat auf 26 Seiten eine umfassende technische Empfehlung bei der Verwendung von API zum sicheren Datenaustausch veröffentlicht – zwar nur in französischer Sprache, aber es gibt ja zum Glück gute Übersetzungstools.
Erforderlichkeit einer API
Wie bei jeder Datenverarbeitung muss sich auch beim Einsatz einer Schnittstelle zum Datenaustausch die Frage gestellt werden, ob dieser Vorgang erforderlich ist. Dies kann bejaht werden, wenn einer oder mehrere der nachfolgenden Gründe vorliegt:
- Die Daten werden häufig aktualisiert und/oder ein regelmäßiger Zugriff auf die neuen Daten wird benötigt;
- ein Dritter benötigt zwar Zugriff auf die Daten, es ist aber nicht sinnvoll, dass dieser die Daten ebenfalls bei sich speichert (z. B. weil die Daten nur einmalig verwendet werden oder weil die kontinuierliche Verarbeitung dieser Daten keinen Historienverlauf bedarf);
- ein Dritter benötigt keinen Zugang zum gesamten Datensatz, sondern nur einen Zugang zu einer im Voraus nicht bestimmbaren Teilmenge;
- die Methoden, mit denen die Datensicherheit gewährleistet werden, können durch den Einsatz einer API aktualisiert werden (z. B. sichere Datenübertragung via API anstatt Fax oder unverschlüsselte E-Mail).
Die genannten Gründe sind nicht abschließend und daher nur beispielhaft zu verstehen.
Risiken durch den Einsatz von Schnittstellen
Auch wenn gute Gründe für den Einsatz einer Schnittstelle bestehen, dürfen die mit einer Schnittstelle verbundenen Risiken nicht außer Acht gelassen werden.
Durch den schnellen und einfachen Datenaustausch ist insbesondere der Verlust der Vertraulichkeit und damit der Verlust der Datenkontrolle für den Datenverantwortlichen sowie der betroffenen Person besonders wahrscheinlich. Dies kann entweder eintreten, weil beispielsweise ein Nutzer seinen Zugang zu einer Datenquelle ausnutzt oder gar einem Dritten Zugang einräumt. Oder ein Hacker eine API als Hintertürchen nutzt, um in das eigentlich anvisierte System einzudringen.
Wenn Daten leicht zugänglich sind, steigt auch immer die Gefahr, dass diese zweckentfremdet werden. Die DSGVO hat in Art. 5 Abs.1 lit. b DSGVO und Art. 6 Abs. 4 DSGVO einen engen Spielraum eingeräumt, wann personenbezogene Daten zu anderen Zwecken als den ursprünglichen weiterverwendet werden dürfen. Dies gilt auch zu beachten, wenn die Daten über eine Schnittstelle bezogen werden.
Trotz der Informationspflichten aus Art. 13 und 14 DSGVO werden betroffene Personen in Datenschutzhinweisen nicht immer umfänglich über den Einsatz von API informiert. Da hier auch oft eine Datenweitergabe an Dritte (z. B. andere IT-Dienstleister) erfolgen kann, geht dies mit einem Verlust an Transparenz einher.
Neben diesen aufgezeigten Risikoszenarien sind natürlich noch weitere denkbar.
Abhilfemaßnahmen: Privacy by design und by default
Wie bei allen Risiken gibt es eine Vielzahl an Möglichkeiten, wie man diesen begegnen kann und auf ein datenschutzrechtlich vertretbares Maß reduzieren kann. Letztlich geht es meist darum, die Schnittstellen von Anfang an so zu programmieren, dass die Grundsätze „privacy by design“ und „privacy by default“ aus Art. 25 DSGVO beachtet werden.
Allgemein lassen sich folgende risikominimierende Maßnahmen nennen:
- Minimierung der Daten, welche über die API ausgetauscht werden;
- bei Möglichkeit werden nur pseudonymisierte oder anonymisierte Daten übermittelt;
- die Möglichkeit des Zugriffs wird gezielt auf bestimmte Informationen beschränkt (z. B. durch granulare Abfrage);
- Zugriffe auf die Schnittstelle sind nachvollziehbar (z. B. durch Logging, Genehmigungsverfahren);
- Zugriffsrechte werden überwacht und geachtet (z. B. Rollenkonzept mit der Unterscheidung zwischen Lese- und Bearbeitenrechte);
- die allgemeinen technischen und organisatorischen Maßnahmen werden auch bei Schnittstellen (z. B. Verschlüsselung der Datenübertragung) angewandt.
Die CNIL erteilt in ihrer technischen Empfehlung noch weitere Handlungsempfehlungen in Abhängigkeit der Rolle zur Schnittstelle. Danach wird zwischen den Dateninhaber („détenteur de données“), den API-Manager („gestionnaire d’API“) und den Wiederverwender („réutilisateur“) unterschieden.
Der Dateninhaber kontrolliert die Daten technisch oder organisatorisch. Er kann mit der Rolle des API-Managers, der für die technische Komponente des Datenaustauschs via API zuständig ist, zusammenfallen, wenn er auch die Daten anbietet. Der Wiederverwender ist derjenige, der die Daten mittels API erhält und weiterverwendet. Auch diese Rolle kann letztlich mit dem Dateninhaber zusammenfallen. So empfiehlt die CNIL beispielsweise, dass der Dateninhaber eine genaue Dokumentation für den Weiterverwender bereithält, woher die Daten stammen, wie oft sie aktualisiert werden, welche Erhebungsmethode angewandt wird, ihre historische Tiefe usw.
Dem API-Manager wiederum wird aufgetragen, dass dieser bei der technischen Gestaltung der API die Zuverlässigkeit und Robustheit von Metadaten und anderer Informationen zur Systemsicherheit garantiert und dem Datenweiterverwender eine Testumgebung (sog. sandbox) zur Verfügung stellt. Dem Weiterverwender gibt die CNIL den Rat, (technische) Schlüssel zu Authentifizierungszwecken sicher (z. B. in einem digitalen Tresor) zu verwahren.
Erfüllung der Rechenschaftspflichten
Aus Art. 5 Abs. 2 DSGVO ergibt sich die Pflicht des Verantwortlichen, nachzuweisen, dass er die Einhaltung der Datenschutzgrundsätze nachweisen kann. Hieran ist auch beim Einsatz von Schnittstellen zu denken. Daher empfiehlt es sich, einerseits eine Übersicht in der Organisation (insbesondere IT-Abteilung) zu führen, aus der sich die im Unternehmen eingesetzten Schnittstellen ergeben. Hierbei kann auch zugleich die Erforderlichkeit jeder einzelnen Schnittstelle notiert werden. Falls hierbei eine nicht erforderliche Schnittstelle identifiziert wird, sollte diese nicht mehr eingesetzt werden. Hierdurch wird auch die Angriffsfläche für Hacker reduziert. Je nach Kritikalität der API kann entweder für jede gesondert oder aber auch allgemein für den Einsatz von API dokumentiert werden, welche technischen und organisatorischen Maßnahmen ergriffen werden.
Kurze Checkliste zur Überprüfung von API
Nachfolgend soll eine kleine Checkliste helfen, um die Gewährleistung von Datenschutz und Datensicherheit für einzelne Schnittstellen schnell zu überprüfen:
- Existiert eine ausreichende Dokumentation zu den Schnittstellen (ggf. sogar ein Datenmodell)?
- Ist die IT-Administration angemessen? Sind insbesondere die internen Verantwortlichkeiten festgelegt?
- Besteht ein angemessenes Nutzer- und Rechtemanagement unter Beachtung des Need-To-Know-Prinzips und des Least-Privilege-Prinzips?
- Existiert ein angemessenes Datensicherungs- und Löschkonzept?
- Existieren ggf. Prozesse zur Nutzervergabe und dem -entzug?
- Sind angemessene Maßnahmen zur sicheren Authentifizierung von Nutzern (z. B. MFA) etabliert?
- Wird der datenschutzrechtliche Grundsatz der Erforderlichkeit beachtet? Gibt es nachvollziehbare Gründe für den Einsatz der Schnittstelle?
- Wird der Grundsatz der Datensparsamkeit gewahrt, indem nur die benötigten Daten über die Schnittstelle übermittelt werden?
- Kann im Falle eines Datenschutzvorfalles anhand von Logfiles der Datenzugriff (wie Häufigkeit, Art und Weise der Zugriffe Volumen oder ihre historische Tiefe) nachvollzogen werden?
- Wie können Betroffenenrechte (insbesondere Recht auf Berichtigung, Widerspruch und Auskunft) gewahrt werden?
Auch diese Checkliste verdeutlicht wiederum, dass Schnittstellen letztlich nicht anders als Software zu behandeln sind.
Schnittstellen – von Datenschützern oft vernachlässigt
Das Thema Schnittstellen ist für Datenschutzberater meist sehr technisch und daher sehr abstrakt. Man findet hierzu auch kaum aussagekräftige Fachliteratur. Die Empfehlung der CNIL ist insoweit lesenswert, da es am Ende sogar nochmal hilfreiche Praxisbeispiele bietet. Da die DSGVO technisch-neutral ist, können die altbekannten Grundsätze wie eh und je angewandt werden. Es werden die typischen Fragen zur Datensicherheit und zur Beachtung der Datenschutzgrundsätze gestellt, wie man dies auch bei sonstigen IT-Anwendungen stellt. Man muss also keine Scheu davor haben, eine Schnittstelle datenschutzrechtlich zu bewerten.
Interessantes Thema, aber die Frage, ob API oder nicht, stellt sich aus technischer Sicht kaum. Was wäre denn die Alternative? Direkter Zugriff auf die Datenbank mit Connection String direkt in der App, so wie in den 90ern? Das wäre fatal.
Die API ist das erste, was entwickelt wird und werden muss, selbst wenn sie nur intern genutzt wird. Sie muss ein Sicherheitskonzept beinhalten, welches jedem Nutzer auf Basis seiner Authentifizierung exakt die Daten freigibt, die dieser benötigt. Ob ein Nutzer dann direkt über die API oder über die darüberliegende Benutzerschnittstelle (Webseite, App) zugreift, spielt keine Rolle.
Wenn ein Nutzer seine persönlichen Zugangsdaten (Kennwort, Session-Cookie, API-Key weitergibt), dann ist das so, als wenn ich jemandem meinen Haustürschlüssel in die Hand gebe: Wird etwas gestohlen wird, zahlt keine Versicherung. Respektive greift dann auch die DS-GVO nicht mehr, wenn ich meine Secrets weitergebe.
Vielen Dank für Ihren Kommentar, auf den wir gerne eingehen.
Zunächst sei klarzustellen, dass die technischen Vorteile einer API durch den Artikel nicht in Abrede gestellt werden sollten. Es sollte viel mehr erläutert werden, welche datenschutzrechtlichen Fragen beim Einsatz einer API zu beantworten sind. Dies auch vor dem Hintergrund, dass Datenschutzbeauftragte und -koordinatoren zu unserer Leserschaft gehören, für die ein solcher Blogbeitrag hilfreich sein kann.
Falls ein Mitarbeiter seine persönlichen Zugangsdaten an Dritte weitergibt, greifen die DSGVO Vorschriften dennoch. Es kann sich um eine meldepflichtigen Datenpanne nach Art. 33 DSGVO handeln, die sogar schadenersatzpflichtig sein kann. Der Arbeitgeber bleibt auch bei fehlerhaften Verhalten von Mitarbeitenden grundsätzlich Datenverantwortlicher und kann sich nur in wenigen Ausnahmefällen exkulpieren.