Apps – DSGVO-Konformität und Checkliste für Datenschutzhinweise

Zusammenfassung

• Vor dem ersten Datenerhebungsschritt muss intern dokumentiert sein, welche personenbezogenen Daten zu welchem Zweck erhoben werden, wann sie gelöscht werden und welche Drittanbieter-Dienste eingebunden sind.
• Tracking-, Analyse- und Werbe-SDKs dürfen erst nach ausdrücklicher vorheriger Einwilligung der betroffenen Person aktiviert werden; Einwilligung und Widerruf sind serverseitig zu protokollieren.
• Jede App benötigt eigene, App-spezifische Datenschutzhinweise, die sowohl in der App als auch im App Store vor dem Download zugänglich sind – die allgemeinen Website-Datenschutzhinweise genügen nicht.
• Datensparsamkeit, restriktive Betriebssystem-Berechtigungen, verschlüsselte Datenübertragung und ein gestufter Informationsansatz (Layered Notices) sind die zentralen Bausteine der Compliance.

1. Entwicklungs- / Designphase

1.1 Allgemeines

Für sämtliche personenbezogenen Daten, die über die App erhoben und verarbeitet werden, muss intern dokumentiert sein:

1. Welche Art von Daten wird erhoben?
2. Zu welchem Zweck wird jede Datenart verwendet und wofür ist sie erforderlich?
3. Wann und wie wird jede Datenart gelöscht?
4. Ist es möglich, der betroffenen Person innerhalb von spätestens 30 Tagen Zugang zu (einer Kopie) ihrer Daten zu gewähren?
5. Welche Tools, SDKs oder Dienste von Drittanbietern werden eingesetzt?

1.2 Dateneingabeformulare

1. Dateneingabeformulare dürfen nur solche Informationen erheben, die für den konkreten Zweck zwingend erforderlich sind (ein Newsletter-Anmeldeformular benötigt z. B. weder Name noch Geburtsdatum).
2. Für die nutzende Person muss klar erkennbar sein, ob ein Feld optional oder verpflichtend ist.
3. Für die nutzende Person muss klar erkennbar sein, zu welchem Zweck die Information jedes Feldes verwendet wird. Im Zweifel sollte ein Tooltip über den Verwendungszweck informieren und/oder auf die Datenschutzhinweise verlinken (z. B. das Geburtsdatum wird zur Altersprüfung verwendet, da das Mindestalter zur Nutzung des Dienstes 16 Jahre beträgt).

1.3 Login / Registrierung

Bietet die App eine Registrierungs- und Account-Login-Funktion, ist Folgendes zu beachten:

1. Bei der Registrierung muss die nutzende Person darauf hingewiesen werden, dass sie die „Allgemeinen Geschäftsbedingungen" der App bzw. des Dienstes akzeptiert. Sie muss die AGB lesen und speichern können.
2. Auf der Registrierungsseite sollte ein Link zu den Datenschutzhinweisen enthalten sein. Wichtiger Hinweis: Die nutzende Person darf nicht aufgefordert werden, den Datenschutzhinweisen insgesamt zuzustimmen.
3. Soll die E-Mail-Adresse der nutzenden Person zu Marketingzwecken verwendet werden, erfordert dies grundsätzlich (von wenigen Ausnahmen abgesehen) eine zusätzliche vorherige ausdrückliche Einwilligung.
4. Die E-Mail-Adresse der nutzenden Person sollte über ein Double-Opt-in-Verfahren (individueller, per E-Mail versandter Link) validiert werden, um sicherzustellen, dass die nutzende Person Inhaberin der angegebenen E-Mail-Adresse ist.
5. Die nutzende Person muss ein Nutzerkonto löschen können. Bei Löschung des Kontos und/oder der App müssen die Nutzerdaten auf dem Gerät gelöscht werden (auch auf SD-Karten gespeicherte Nutzerdaten). Auch die auf dem Server des Unternehmens gespeicherten Daten müssen gelöscht werden, es sei denn, das Unternehmen ist zu einer längeren Aufbewahrung verpflichtet.

1.4 Datenschutzhinweise

1. Jede App muss eigene, spezifische Datenschutzhinweise haben (siehe unten). Eine Verlinkung auf die allgemeinen Datenschutzhinweise der Unternehmenswebsite genügt nicht.
2. Die Datenschutzhinweise müssen aus der App heraus erreichbar sein (z. B. über das Menü „Rechtliches" – „Datenschutzhinweise").
3. Im App Store muss ein Link zu den Datenschutzhinweisen platziert sein, damit die nutzende Person sie vor dem Herunterladen und Installieren der App lesen kann.

1.5 Tracking-, Analyse- und Werbe-SDKs (Software Development Kits)

1. Verwendet die App Drittanbieter-SDKs für Tracking, Analyse oder Marketing/Werbung (z. B. Adobe Analytics, Google Analytics, Crashlytics, Google Mobile Ads, AdMob oder Vergleichbares), darf solcher Code erst aktiviert werden, nachdem die nutzende Person ihre ausdrückliche vorherige Einwilligung erteilt hat. Vor oder ohne eine solche Einwilligung darf die App keinerlei Verbindung zu Drittanbieterdiensten oder -servern herstellen. Einwilligungstext, Einwilligungs-Banner und Einwilligungs-Protokollierung sind durch die Rechtsabteilung zu prüfen.
2. Die nutzende Person muss ihre Einwilligung jederzeit widerrufen können (z. B. über das Menü „Einstellungen" der App).
3. Einwilligung und Widerruf der Einwilligung müssen durch das Unternehmen (serverseitig) protokolliert werden.

1.6 Sonstige Drittanbieter-SDKs

Jedes weitere Drittanbieter-SDK, das eine Verbindung zu einem Drittanbieterdienst oder -server herstellt (z. B. zur Bereitstellung von Karten- oder Videofunktionen, Social-Media-Plugins, Zahlungsdienstleister), darf nur nach vorheriger Freigabe durch die Rechtsabteilung eingebunden werden.

1.7 Betriebssystem-Berechtigungen

1. Die App darf nur solche Berechtigungen (Kamera, Standort, Adressbuch/Kontakte, Mikrofon usw.) anfordern, die zur Bereitstellung des Dienstes der App erforderlich sind. Für die nutzende Person muss erkennbar sein, wann eine solche Berechtigung genutzt wird und zu welchem Zweck (z. B. „der Zugriff auf die Kamera wird genutzt, wenn die nutzende Person einen QR-Code scannen möchte").
2. Standortdaten sollten nur erhoben werden, wenn dies erforderlich ist, und nur für den erforderlichen Zeitraum (Intervall der Standorterhebung). Wo möglich sollten Standortdaten unscharf gemacht werden (statt des exakten Standorts wird z. B. nur die Postleitzahl/Region/das Land gespeichert). Historische Standortdaten dürfen nur gespeichert werden, soweit dies für den Dienst zwingend erforderlich ist. Die nutzende Person sollte darauf hingewiesen werden, wenn Standortdaten erhoben werden, und die Möglichkeit haben, dem zu widersprechen (Opt-out).

1.8 Weitere Anforderungen

1. Der Zugriff auf Gerätekennungen wie IMEI oder UDID, IMSI, MAC-Adresse, MSISDN oder Vergleichbares erfordert eine vorherige Freigabe durch die Rechtsabteilung.
2. Wird ein In-App-Browser verwendet, muss die nutzende Person auf die Datenschutzhinweise der im In-App-Browser angezeigten Website hingewiesen werden.
3. IP-Adressen sollten nur in gekürzter Form gespeichert werden, es sei denn, die Speicherung vollständiger IP-Adressen ist zwingend erforderlich. Werden vollständige IP-Adressen gespeichert, sollte die Speicherdauer klar definiert sein (z. B. 7 Tage).

1.9 Datensicherheit

(nicht abschließend, teilweise basierend auf Informationen der bayerischen Datenschutzaufsichtsbehörde)

1. Die Kommunikation (Datenübertragung) zwischen der App und dem Backend muss verschlüsselt sein.
2. Implementiert die App ein Nutzerkonto mit Passwort und Benutzernamen, sollten die folgenden Sicherheitsaspekte berücksichtigt werden (nicht zwingend):

• Verfügt der Dienst über eine ausreichende HTTPS-Verschlüsselung zum Schutz der personenbezogenen Daten?
• Erklärt der Dienst der nutzenden Person, wie ein starkes Passwort gewählt wird?
• Welche Mindestlänge wird für ein Passwort verlangt?
• Wird ein starkes Passwort durch den Dienst „erzwungen" oder kann auch ein schwaches Passwort verwendet werden?
• Wird der nutzenden Person die Stärke des gewählten Passworts angezeigt (z. B. Passwort-Qualitätsbalken)?
• Wird der nutzenden Person bei sensiblen Daten auch eine Mehr-Faktor-Authentifizierung angeboten (z. B. per SMS-Code oder Geräteidentifikation)?
• Erhält die nutzende Person eine E-Mail, um die im Konto hinterlegte E-Mail-Adresse erfolgreich zu bestätigen (ggf. mit URL-Token) und die Registrierung abzuschließen?
• Wird die nutzende Person darüber informiert, ob es fehlgeschlagene Logins gab und ob andere Geräte angemeldet sind (d. h. weitere Sitzungen aktiv sind)?
• Wird beim Ändern des Passworts das bestehende (alte) Passwort erneut abgefragt?
• Wird die nutzende Person über eine Passwortänderung per E-Mail informiert?
• Versendet die Passwort-vergessen-Funktion eine E-Mail mit einer temporär gültigen URL an die hinterlegte E-Mail-Adresse?
• Sind Daten im Ruhezustand (d. h. lokal auf dem Gerät gespeicherte Daten) ausreichend verschlüsselt/geschützt?
• Werden Zugangsdaten mit einem für die Passwortspeicherung geeigneten kryptografischen Verfahren transformiert (z. B. KeyChain für iOS, PBKDF2 bei Eigenimplementierung), bevor sie lokal gespeichert werden?
• Werden Passwörter bei der Eingabe in der App maskiert (ggf. zuschaltbar), um „Shoulder-Surfing" zu verhindern?
• Ist die Datenübertragung verschlüsselt (mit HTTPS)?
• Wird bei HTTPS Perfect Forward Secrecy verwendet?
• Wird verhindert, dass personenbezogene Daten über HTTP-GET-Parameter übertragen werden?
• Werden vertrauenswürdige SSL-Zertifikate verwendet und werden diese auch geprüft, um Man-in-the-Middle-Angriffe zu verhindern?
• Wird SSL-Pinning (feste „Verdrahtung" des SSL-Zertifikats in der App) verwendet?
• Werden Token-Werte anstelle von Kontodaten (z. B. Kundennummer) für eine Sitzungsreferenz zum Backend verwendet?
• Ist das Backend ausreichend gegen Angriffe auf Basis der OWASP Top 10 (2013) geschützt?
• Kann der Backend-Webserver über HTTP statt HTTPS erreicht werden (z. B. SSL-Stripping-Angriff)?
• Ist ein (JSON-)SSLStrip-Angriff möglich?

Kurz-Checkliste für die Nutzung von TLS:

• nur TLS 1.2 (kein SSL3, TLS 1.0, TLS 1.1 mehr)
• nur Cipher Suites, die Perfect Forward Secrecy unterstützen
• SSL-Pinning (Public-Key-Pinning empfohlen, ausnahmsweise auch CA-Pinning)
• Auswahl einer vertrauenswürdigen Zertifizierungsstelle
• Zertifikate mit 4096-Bit-RSA
• kein SHA-1 bei der Zertifikatssignierung (stattdessen mindestens SHA-256)
• keine veralteten kryptografischen Algorithmen (z. B. RC4, DES, …)
• keine Unterstützung von HTTP auf demselben Server (Gefahr von SSL-Stripping-Angriffen)
• aktuelles und systematisches Patch-Management der SSL-Komponenten (z. B. wegen Heartbleed, Poodle, CCS-Angriffen)
• TLS-Client-Zertifikate, um Man-in-the-Middle-Angriffe zu erschweren

2. Angaben in Datenschutzhinweisen (Datenschutzerklärungen)

Datenschutzhinweise für Apps müssen spezifisch für die jeweilige App gestaltet sein. Es genügt nicht, die allgemeinen Datenschutzhinweise der Unternehmenswebsite zu verwenden.

Die Datenschutzhinweise müssen aus der App heraus sowie von der Download-/Installationsseite im App Store aus zugänglich sein.

Datenschutzhinweise müssen insbesondere Folgendes enthalten:

1. Name und Kontaktdaten (Anschrift, E-Mail, Telefon) des für die Datenverarbeitung der App verantwortlichen Unternehmens (Verantwortlicher).
2. Kontaktdaten des Datenschutzbeauftragten dieses Unternehmens, sofern vorhanden (E-Mail-Adresse genügt).
3. Für jede Art personenbezogener Daten, die durch die App verarbeitet wird (z. B. Profildaten, Bestelldaten, Zahlungsdaten, Tracking-/Analysedaten):

• Beschreibung der Datenart
• Verwendungszweck (z. B. Abwicklung von Zahlungen)
• Rechtsgrundlage der Verarbeitung (gemäß Art. 6 DSGVO), z. B. Einwilligung, Vertragserfüllung oder Interessenabwägung (im letzteren Fall sind die von dem Unternehmen verfolgten Interessen anzugeben, z. B. „Verbesserung der App-Sicherheit durch Erkennung unbefugter Zugriffsversuche").
• Empfänger der Daten (Kategorie oder, wo möglich, Unternehmensnamen), einschließlich Drittanbieter-Dienstleistern, Hostern (z. B. AWS, Google, verbundene Unternehmen)
• Speicherdauer der Daten (oder die Kriterien zur Festlegung dieser Dauer)
• ob die Bereitstellung der Daten erforderlich ist, sowie mögliche Folgen einer Nichtbereitstellung dieser Daten

Datenschutzhinweise müssen außerdem folgende Informationen enthalten:

1. Falls Daten in Nicht-EU-Länder übermittelt werden: Name des Landes und welcher Datenexport-Mechanismus genutzt wird (z. B. EU-Standardvertragsklauseln).
2. Bestehen einer automatisierten Entscheidungsfindung, einschließlich Profiling, sofern vorhanden.
3. Informationen über die Rechte der betroffenen Personen (Recht auf Widerruf der Einwilligung, Beschwerde bei einer Aufsichtsbehörde, Auskunft sowie Berichtigung oder Löschung personenbezogener Daten, Einschränkung der Verarbeitung, Widerspruch gegen die Verarbeitung sowie das Recht auf Datenübertragbarkeit).
4. App-Berechtigungen: welche Berechtigungen erforderlich sind (unter jeder Betriebssystem-Plattform), wann Berechtigungen genutzt werden und zu welchem Zweck (z. B. „der Zugriff auf die Kamera wird genutzt, wenn die nutzende Person einen QR-Code scannen möchte").
5. Die Datenschutzhinweise müssen die folgenden Fragen beantworten (sofern einschlägig):

• Wie wird die E-Mail-Adresse verwendet?
• Wie kann ein Nutzerkonto gelöscht werden?
• Wie werden Push-Benachrichtigungen verwendet?
• Wie werden IP-Adressen verwendet?
• Wie werden Gerätekennungen verwendet?
• Werden Daten lokal auf dem Gerät oder remote auf einem Backend-/Drittanbieter-Server gespeichert?

Die Datenschutzhinweise müssen in präziser, transparenter, verständlicher und leicht zugänglicher Form in klarer und einfacher Sprache abgefasst sein.

Empfohlen wird ein gestufter Ansatz (Layered Notices): Relevante Informationen werden unmittelbar in der Benutzeroberfläche bzw. den Eingabeformularen bereitgestellt (z. B. enthält das Upload-Feld für das Profilbild einen Tooltip, der über den Verwendungszweck informiert und darüber, wer das Bild sehen kann). Detailliertere Informationen sind im Datenschutzhinweis-Dokument enthalten. Lange Datenschutzhinweise sollten eine Zusammenfassung der wichtigsten Aspekte enthalten, oder jeder Abschnitt wird zusammengefasst und die Details zu jedem Abschnitt werden über eine Schaltfläche bzw. einen Link „Mehr anzeigen" eingeblendet.