Das katholische Südwest-Datenschutzaufsicht hat 240 Webseiten von katholischen Schulen automatisiert geprüft. Das KDSZ Frankfurt hat dabei festgestellt, dass auf vielen Webseiten die gleichen Probleme bestehen – und angesichts der geschilderten Probleme bei Schul-Webseiten liegt es nahe, dass auch andere Webseiten ähnliche Probleme haben.

Der Blick in den vierseitigen Ergebnisbericht der Prüfung lohnt daher für alle, die eine Webseite betreiben – die festgestellten Probleme und die Abhilfe sind nicht nur im Geltungsbereich des KDG relevant.

Rechtsgrundlagen für Datenverarbeitungen auf und durch Webseiten

Nur in Ausnahmefällen soll man nach Ansicht des KDSZ Frankfurt (der ich mich anschließe) auf eine Einwilligung zurückgreifen. Sollten doch Einwilligungen eingeholt werden – etwa bei Cookies, wo Einwilligungen alternativlos sind –, muss sichergestellt werden, dass erst nach der Einwilligung mit der entsprechenden Verarbeitung begonnen wird.

Relevant ist dieser Hinweis auch bei Einbettungen etwa von Videos oder Kartendienstleistern: »Insbesondere sollten externe Komponenten, die nicht benötigt werden, falls eine betroffene Person keine Einwilligung erteilen möchte, erst dann von externen Servern geladen werden, wenn die entsprechende Einwilligung erteilt wurde.« Zu externen Komponentne gibt es einen eigenen Abschnitt.

Allgemeiner bleiben die Hinweise zum berechtigten Interesse. Hier verweist die Aufsicht auf die Orientierungshilfe für Telemedien der DSK und den Drei-Stufen-Test, den auch der EuGH zugrunde legt. Leider bleibt es bei dem allgemeinen Hinweis, dass ein Nachweis dieser Prüfung der Aufsicht auf Verlangen vorzuzeigen ist – konkrete Verarbeitungssituationen auf Webseiten, die sich auf eine Interessenabwägung stützen lassen (oder eben gerade nicht) werden nicht genannt.

Einbettungen externer Dienste

Primär sollen Komponenten intern eingebunden werden, um die Grundsätze der Datenminimierung und des Datenschutzes durch Technikgestaltung erinzuhalten. Bemerkenswert ist, dass die Aufsicht eine Liste mit benannten Diensten benennt, die »unter Umständen« keine Rechtsgrundlage besteht oder Zweifel bestehen, dass sie den Grundsätzen nicht entsprechen:

• Google-Produkte: Tagmanager, Analytics, reCaptcha, Maps, Youtube, Fonts
• statische Dateien wie Schriftarten, CSS-Dateien, JavaScript-Dateien, z.B. jQuery
• Altruja
• collect.chat
• Consentmanager
• Cookiebot
• etracker
• Matomo
• Easy Reading
• Usercentrics
• piwik-sesam.w-commerce.de
• zwei14.app
• Musterhausen
• Carinet

Die Liste wirkt sehr heterogen. Eher invasive Dienste wie Google Analytics stehen neben durchaus sehr datensparsam zu betreibenden wie Matomo oder verschiedene kirchliche Eigenentwicklungen. Gemeint ist wohl ausschließlich eine externe Einbindung, etwa über Content Delivery Networks – lokal eingebundene statische Dateien sind in der Regel kein Problem.

Empfohlen wird, eine mögliche Auftragsverarbeitung, die Rechtsgrundlage und Datenminimierung und Datenschutz zu Technikgestaltung zu prüfen. Nicht erwähnt wird der Fall der gemeinsamen Verantwortlichkeit – die kann durchaus je nach Dienst vorliegen und erfordert dann eine entsprechende Vereinbarung.

Hosting

Nachdrücklich wird empfohlen, einen Hosting-Provider aus dem Europäischen Wirtschaftsraum zu beauftragen – tatsächlich scheinen Fälle von Hosting außerhalb vorgekommen sein (ich vermute Webseiten-Baukästen und Content Delivery Networks). Die Mühen einer Drittlandsübertragung, auf die hingewiesen wird, wird man sich wohl lieber sparen wollen. Auf die Notwendigkeit eines Auftragsverarbeitungsvertrags wird hingewiesen.

Interessant ist, dass auch der Zugriff über VPN und Tor geprüft wurde. Hier empfiehlt die Aufsicht, solche Zugriffsarten nicht auszuschließen: »Da diese Maßnahme der Datenminimierung dienen kann, sollte die Nutzung von Proxies ermöglicht werden.« Probleme kann es hier vermutlich geben, wenn Content Delivery Networks und Load balancer wie Cloudflare genutzt werden.

Bei der Transportverschlüsselung wird es technisch. Die Aufsicht empfiehlt eine sichere und datensparsame TLS-Konfiguration, »also beispielsweise die Verwendung nur als sicher geltender Cipher-Suites und von OCSP-Stapling«. Wie das im Schulsekretariat geprüft werden kann, erfährt man nicht (Hilfreich wäre beispielsweise ein Hinweis auf die TLS-Checkliste des BSI, für die es auch automatisierte Prüftools gibt). Da es hier so in die Tiefen der Technik geht, kann man wohl annehmen, dass unverschlüsselte Webseiten kein in der Realität auftauchendes Problem mehr sind.

Weitere Themen

• Cookies: Nicht immer wurde eine angemessene Rechtsgrundlage für die Speicherung von Daten auf dem Endgerät festgestellt – in der Regel (darauf geht der Bericht nicht ein) dürfte das eine Einwilligung sein.
• Analysedaten: Hier mahnt die Aufsicht zu Datensparsamkeit: Nur das darf erhoben werden, was auch tatsächlich für die Analyse erforderlich ist. (Damit ist es vermutlich einfacher, auf etwa Google Analytics zu verzichten, als große Analyse-Suiten mühsam auf Datensparsamkeit zu trimmen.)
• Datenschutzerklärungen: Vorsicht beim Baukasten – wenn das KDG gilt, muss auch auf das KDG Bezug genommen werden, nicht auf die DSGVO. Es müsse sogar eindeutig aus der Datenschutzerklärung hervorgehen, dass das KDG angewandt wird. (Ob das tatsächlich sein muss, kann man bezweifeln – eine Datenschutzerklärung kann die Pflichtinhalte auch ohne Normverweis enthalten.) Die Nennung der zuständigen Datenschutzaufsicht wird lediglich empfohlen – konsequent, da Pflicht nur der Hinweis auf die Beschwerde bei einer Datenschutzaufsicht ist.

Checkliste

Aus dem Tätigkeitsbericht ergibt sich somit eine technische Checkliste, mit der man eigene Webseiten überprüfen kann:

• Welche externen Dienste werden eingebunden? Ist die Verwendung eines externen Dienstes erforderlich, oder kann das auch lokal gelöst werden?
• Welche personenbezogenen Daten werden erhoben? (Sowohl durch spezielle Dienste als auch durch Cookies und Logdateien)
• Beschränkt sich die Erhebung von Analysedaten auf das Erforderliche?
• Welche Rechtsgrundlage besteht dafür? Wird eine nötige Einwilligung so erhoben, dass erst nach Einwilligung Daten übertragen werden?
• Sind die erforderlichen Verträge zur Auftragsverarbeitung oder Vereinbarungen über gemeinsame Verantwortlichkeit geschlossen?
• Ist der Hosting-Provider im Europäischen Wirtschaftsraum? (Falls nicht: Ist der Drittlandtransfer angemessen geregelt?) Welche Logdateien werden erhoben? Wurde der Auftragsverarbeitungsvertrag geschlossen?
• Ist die Webseite auch über VPNs und Anonymisierungsdienste erreichbar?
• Entspricht die TLS-Konfiguration dem Stand der Technik gemäß BSI-Richtlinie?
• Nimmt die Datenschutzerklärung Bezug auf den richtigen Rechtsrahmen? (Bei Anwendung des KDG also das KDG.)

Fazit

Aus dem Prüfbericht wird deutlich, worauf die Aufsicht bei oberflächlichen (weil automatisierten) Prüfungen von Webseiten achtet. Nichts davon ist im Ergebnis besonders überraschend, das alles sollte ohnehin Standard und regelmäßige Übung sein. Es lohnt sich, den Prüfbericht als Checkliste an die eigene Webseite anzulegen.

Etwas unglücklich ist die Aufzählung sehr verschiedener Dienste, ohne dass weiter differenziert wird. Hier sollte man nicht gleich in Panik verfallen und sie als Blacklist lesen. Sinnvoller ist es, generell eine Prüfung vorzunehmen, was alles auf der Webseite nach draußen funkt, und wie man das entweder durch lokale Alternativen ersetzt, abstellt oder nach einer Einwilligung zulässt.

Dem Prüfformat geschuldet ist, dass es leider zu den vielfältigen Fragen, die Inhalte von Schul-Webseiten mit sich bringen, nichts gibt: Wie geht man mit Fotos von Schüler*innen um hinsichtlich Rechtsgrundlagen und Speicherfristen? Welche Informationen (etwa zum Lehrkörper, zum Vertretungsplan, zu Schulgremien und -organen und deren Protokollen) dürfen offen im Netz stehen und welche müssen zugangsbeschränkt werden? Wie sieht es mit Berichten aus dem Schulleben und Publikationen aus, die personenbezogene Inhalte enthalten? Hier würde es sich lohnen, noch einmal über eine technische Prüfung hinaus tätig zu werden.