Compliance und DSGVO #

Diese Seite ist für die Compliance-Verantwortlichen, Produktmanager und Systemadministratoren eines Hosters und für Support-Mitarbeitende, die eine Datenschutzanfrage eines Kunden erhalten. Sie beschreibt, was die Software bereitstellt: Datenschutz als Standard, Aufzeichnungen über Einwilligungen, Befehle für Auskunft und Löschung und Aufbewahrungseinstellungen, die im Repository zu finden sind. Sie sagt nicht, ob eine Website ein Gesetz einhält.

Warnung Diese Seite ist keine Rechtsberatung. Ob eine Website die Vorschriften einhält, hängt davon ab, was sie verarbeitet, für wen, und von Einstellungen und Dokumenten, die nur ihr Eigentümer bereitstellen kann. Der Hoster und jeder Kunde müssen ihren eigenen rechtlichen Rat einholen. Die eigene rechtliche Checkliste des Projekts sagt dasselbe: Fragen Sie zu Ihrem eigenen Fall einen Anwalt (E-Mail-Einstellungen: die rechtliche Checkliste).

Inhalt #

1. Rollen: wer was entscheidet
2. Datenschutz als Standard in den Logs
3. Das Prüfprotokoll und personenbezogene Daten
4. Einwilligung, Abmeldung und Unterdrückung bei Mails
5. Anfragen betroffener Personen
6. Sicherheit der Verarbeitung
7. Was bei Hoster und Kunde bleibt
8. Checkliste

Rollen: wer was entscheidet #

In einer typischen Hosting-Vereinbarung entscheidet der Kunde, warum und wie personenbezogene Daten auf seiner Website verarbeitet werden, und der Hoster betreibt die Infrastruktur im Auftrag des Kunden. Welche rechtliche Rolle jede Partei hat und welcher Vertrag zwischen ihnen nötig ist, klären die Parteien und ihre Berater. Für den Hoster ist die praktische Folge: Geben Sie dem Kunden die Fakten und die Werkzeuge unten, halten Sie Ihre eigenen betrieblichen Logs und Backups unter Kontrolle und unterstützen Sie Anfragen, wenn der Kunde darum bittet.

Datenschutz als Standard in den Logs #

MaskIP=disabled schreibt volle Adressen; Anfrage-Logs sagt, das nur für eine Website zu nutzen, die einen Grund und eine Rechtsgrundlage dafür hat. Die eigenen Zugriffslogs des Webservers (Apache, nginx, die des Panels) liegen außerhalb von Exponential und folgen den Einstellungen des Hosters.

Das Prüfprotokoll und personenbezogene Daten #

Aus 4.12 Datenschutz- und DSGVO-Aufgaben der Anleitung zum Audit, die ebenfalls sagt, dass sie keine Rechtsberatung ist:

• Datenminimierung als Standard: Adressen auf /24 (IPv6 /48) gekürzt, Sitzungen gehasht, User Agents auf Familie von Browser und Betriebssystem reduziert, E-Mail-Adressen und Anmeldeversuche unbekannter Benutzer gehasht; nie Passwörter, Tokens, Schlüssel zum Zurücksetzen, Geheimnisse oder POST-Inhalte; Lesezugriffe aus.
• Strenger: pro Feld full | truncate | hash | off in [AuditPrivacySettings] Field[], BeforeAfter=keys, kürzere Aufbewahrung; die Konfiguration für strengen Datenschutz.
• Pseudonymisierung: Der Index ersetzt personenbezogene Felder nach PseudonymiseAfterDays (90) durch ihre gehashte Form; die Dateien werden nicht umgeschrieben, weil das die Kette brechen würde.
• Auskunftsersuchen: exp:audit export --subject-user=<id> exportiert jeden Eintrag von oder über einen Benutzer; prüfen Sie ihn vor der Herausgabe, weil er auch die Handlungen anderer Personen an diesem Benutzer enthält.
• Löschung: Die Anleitung beschreibt, Audit-Einträge für ihre Aufbewahrungsfrist zu behalten und mit dieser Frist und der angewandten Pseudonymisierung zu antworten; einen zu löschen, würde die Kette brechen.

Einwilligung, Abmeldung und Unterdrückung bei Mails #

Seit 6.0.15 passiert jede Mail die Mail-Sperre (13.13):

• Notwendige Kategorien (security, orders, legal, admin) gehen immer hinaus.
• Optionale Kategorien gehen nur an Empfänger, die sie eingeschaltet haben, aus, bis die Person sie einschaltet, mit einer Fußzeile, einem Link zum Abmelden mit einem Klick und Headern List-Unsubscribe (RFC 8058).
• Einwilligungsprotokoll: jede Änderung an den Einstellungen einer Person mit Zeit, Quelle, gezeigtem Text, IP-Adresse und handelndem Benutzer; Double-Opt-in für Newsletter und Marketing.
• Unterdrückungsliste: Hard Bounces, Beschwerden, „alles stoppen“ und rechtliche Anfragen; gespeichert wird nur ein gesalzener Hash jeder Adresse.

Die rechtliche Checkliste ordnet jede Anforderung von CAN-SPAM, DSGVO und ePrivacy, CCPA/CPRA und CASL dem Code und dem Test zu, der sie beweist, und listet auf, was der Website überlassen bleibt (Der Website überlassen):

1. die Postanschrift in der Fußzeile (mailpreferences.ini [FooterSettings] OrganisationAddress, nach einer Installation leer) und der Name des Absenders (OrganisationName);
2. eine Kategorie für jede kommerzielle Mail, die eigener Code versendet;
3. [GateSettings] SplitRecipients=enabled beibehalten;
4. DKIM-Signatur von List-Unsubscribe und List-Unsubscribe-Post durch den Mailserver;
5. ein Link zur Datenschutzerklärung im Registrierungsformular, wenn das Design einen möchte.

Punkt 4 ist oft Aufgabe des Hosters, weil der Hoster den Mailserver betreibt; siehe Mailzustellung und Einwilligung und Bounces bei Mails. Prüfen Sie den Zustand einer Website mit:

php bin/php/console exp:mail:status

Anfragen betroffener Personen #

Löschen Sie exportierte Dateien, wenn die Anfrage, die sie beantworten, erledigt ist; sie enthalten Adressen. Geben Sie mailpreferences/export und audit/read wenigen Personen.

Sicherheit der Verarbeitung #

Was die Software beiträgt, jeweils auf einer eigenen Seite beschrieben: bcrypt-Hashes von Passwörtern und Passwortregeln, zweistufige Anmeldung, verschlüsselte Tokens zum Abmelden, Schutz von Sitzungen, das Prüfprotokoll mit Hash-Ketten, Sicherheitsheader und eine Content Security Policy (Härtung für Hoster). Was der Hoster beiträgt: Abschottung zwischen Kunden, verschlüsselte Backups, Patches, Zugriffskontrolle für Mitarbeitende und Logs, die an Systeme mit eigenen Zugriffsregeln weitergeleitet werden (Trennung von Mandanten).

Was bei Hoster und Kunde bleibt #

• Verträge zwischen Hoster und Kunde und ihre Rollen nach dem Gesetz.
• Die Datenschutzerklärung, das Verzeichnis der Verarbeitungstätigkeiten und die dort genannten Aufbewahrungswerte; die Aufbewahrungseinstellungen der Software müssen dann passend gesetzt werden (Aufbewahrung von Logs und Daten).
• Backups: die Aufbewahrung personenbezogener Daten in Backups und der Umgang mit Löschung bei Daten, die auch in einem Backup liegen.
• Logs von Webserver, Mailserver und Panel außerhalb von Exponential.
• Dienste Dritter, die eine Website einbindet (Karten, Analyse, Schriften), die die Content Security Policy sichtbar macht, aber nicht bewertet.
• Newsletter-Statistiken: Die Erweiterung cjw_newsletter zählt Öffnungen und Klicks nur, wenn die Website es einschaltet (standardmäßig [TrackingSettings] Tracking=disabled), und pro Person nur mit Einwilligung; die Checkliste nennt, was die Website in ihrer Datenschutzerklärung angeben muss.

Checkliste #

• To do: Der Kunde weiß aus dieser Seite und den verlinkten Quellen, welche personenbezogenen Daten die Logs, das Prüfprotokoll und das Mail-System der Website behalten.
• To do: MaskIP bleibt eingeschaltet, es sei denn, der Kunde hat einen dokumentierten Grund.
• To do: Einstellungen zu Datenschutz und Aufbewahrung des Audits mit dem Kunden vereinbart; ein strengeres Profil angewandt, wo gewünscht.
• To do: Fußzeile der Mails ausgefüllt; exp:mail:status ohne Befund; DKIM-Signatur auf dem Mailserver des Hosters.
• To do: Ein dokumentierter Weg, Auskunfts- und Löschanfragen zu beantworten, einschließlich der anschließenden Löschung exportierter Dateien.
• To do: Aufbewahrung von Backups für personenbezogene Daten entschieden und aufgeschrieben.
• To do: Rechtliche Fragen an die eigenen Berater von Kunde und Hoster verwiesen.

Verwandte Seiten #

• Sicherheit für Hoster: Überblick
• Aufbewahrung von Logs und Daten
• E-Mail-Einstellungen: die rechtliche Checkliste
• E-Mail-Einstellungen: die Anleitung für Administratoren
• Audit: Datenschutz- und DSGVO-Aufgaben
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.