Fällt die Sicherheit Ihrer Website unter die DSGVO? HTTPS, Sicherheits-Header und Artikel 32

Beim Thema Datenschutz denken die meisten Website-Betreiber an Texte: Datenschutzhinweise, Cookie-Richtlinie, Einwilligung. Die DSGVO schaut auch darauf, wie Sie die erhobenen Daten schützen. Läuft Ihr Kontaktformular über eine unverschlüsselte Verbindung, schließen sorgfältig formulierte Texte diese Lücke nicht.

Dieser Beitrag behandelt die Sicherheitsebene Ihrer Website, die von außen sichtbar ist: HTTPS und Zertifikat, Sicherheits-Header sowie externe Skripte. Was im Inneren des Servers geschieht, Backups und Zugriffsrechte liegen außerhalb dieses Beitrags.

Die Quellen sind der Text der DSGVO sowie die Leitfäden der französischen Datenschutzbehörde CNIL und der französischen Cybersicherheitsbehörde ANSSI. Der Maßstab der DSGVO lautet, dass eine Maßnahme dem Risiko angemessen ist und regelmäßig überprüft wird. Die Leitfäden zeigen, was dieser Maßstab auf einer Website bedeutet.

Warum Sicherheit ein Datenschutzthema ist

Artikel 5 der DSGVO nennt die Grundsätze für die Verarbeitung personenbezogener Daten. Einer davon ist Integrität und Vertraulichkeit: Daten müssen in einer Weise verarbeitet werden, die eine angemessene Sicherheit gewährleistet, einschließlich des Schutzes vor unbefugter oder unrechtmäßiger Verarbeitung und vor unbeabsichtigtem Verlust, unbeabsichtigter Zerstörung oder Schädigung, durch geeignete technische oder organisatorische Maßnahmen.

Derselbe Artikel enthält die Rechenschaftspflicht: Der Verantwortliche muss die Einhaltung dieser Grundsätze nachweisen können. In der Praxis heißt das, zeigen zu können, welche Maßnahme Sie getroffen haben und wie Sie sie überprüfen.

Was Artikel 32 verlangt

Artikel 32 gibt einen Maßstab vor. Der Verantwortliche und der Auftragsverarbeiter berücksichtigen den Stand der Technik, die Implementierungskosten, Art, Umfang, Umstände und Zwecke der Verarbeitung sowie das Risiko für die Rechte und Freiheiten natürlicher Personen und treffen technische und organisatorische Maßnahmen, die ein dem Risiko angemessenes Schutzniveau gewährleisten.

Der Artikel nennt vier Beispiele: die Verschlüsselung personenbezogener Daten und ihre Verarbeitung in einer Form, die ohne zusätzliche Informationen keiner Person zugeordnet werden kann (Pseudonymisierung), die Fähigkeit, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme auf Dauer sicherzustellen, die Fähigkeit, den Zugang zu den Daten nach einem Zwischenfall rasch wiederherzustellen, und ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit der Maßnahmen.

Führt ein Sicherheitsvorfall zu einer Verletzung des Schutzes personenbezogener Daten, greift eine eigene Pflicht. Nach Artikel 33 meldet der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der Aufsichtsbehörde. Die Meldung entfällt, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt.

Wo auf Ihrer Website personenbezogene Daten übertragen werden

Die DSGVO definiert personenbezogene Daten als alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Ein Name, Standortdaten und Online-Kennungen werden im Artikel als Beispiele genannt. Auch eine kleine Unternehmensseite überträgt in der Regel Daten, die unter diese Definition fallen:

• Kontakt- und Angebotsformulare: Name, E-Mail-Adresse, Telefonnummer, Inhalt der Nachricht.
• Registrierungs- und Login-Seiten: Benutzername, Passwort, Sitzungsdaten.
• Bestell- und Zahlungsschritte: Adresse und Zahlungsdaten.
• Newsletter-Anmeldungen und Bewerbungsformulare.

Der erste Schritt ist eine Liste dieser Stellen. Ohne zu wissen, auf welchen Seiten ein Formular steht und welche externen Dienste dort laufen, können Sie nicht beurteilen, ob Ihre Maßnahme dem Risiko angemessen ist. Mit einem Scan Ihrer Website sehen Sie die Drittanbieter-Dienste, die auf Ihren Seiten laufen.

HTTPS: Verschlüsselung bei der Übertragung

HTTPS verschlüsselt die Verbindung zwischen dem Browser des Besuchers und Ihrer Website. Die CNIL zählt den Einsatz von TLS auf allen Websites, ausschließlich in den aktuellen Versionen, zu ihren grundlegenden Vorkehrungen. Nach dem Leitfaden soll TLS auf Anmeldeseiten und auf allen Seiten verpflichtend sein, auf denen personenbezogene Daten angezeigt oder übertragen werden.

Im Alltag spricht man weiterhin vom SSL-Zertifikat, doch TLS ist das Protokoll, das SSL abgelöst hat. Der TLS-Leitfaden von ANSSI empfiehlt, SSLv2, SSLv3, TLS 1.0 und TLS 1.1 nicht zu verwenden, TLS 1.3 zu bevorzugen und TLS 1.2 unter den im Leitfaden genannten Bedingungen zu akzeptieren. ANSSI hält es für notwendig, diese Empfehlungen auf jeder Website umzusetzen, auch auf Websites, die keine sensiblen Informationen verarbeiten.

ANSSI weist darauf hin, dass Websites häufig HTTP-Verbindungen annehmen und auf HTTPS umleiten, was einem Angreifer die Gelegenheit lässt, diese Verbindung abzufangen. ANSSI hält dafür den HSTS-Header für notwendig: Er weist den Browser an, bei jedem Zugriff auf die Website HTTPS zu verwenden. Der Browser lernt diese Regel beim ersten Besuch der Website. ANSSI weist darauf hin, dass sich eine Website in eine Liste eintragen lässt, die Browser vorab kennen, um auch den ersten Besuch abzudecken.

Was passiert, wenn das Zertifikat ungültig ist

Jedes Zertifikat hat einen Gültigkeitszeitraum. Wie ANSSI beschreibt, zeigen Browser bei einem ungültigen Zertifikat eine Sicherheitswarnung an. Ist HSTS definiert, kann der Besucher diese Warnung nicht übergehen und die Website nicht aufrufen.

Deshalb gilt ANSSI der dauerhafte HTTPS-Zugang als unverzichtbare Voraussetzung für HSTS. Auch die CNIL zählt zu ihren grundlegenden Vorkehrungen, Zertifikate auf der passenden Stufe zu beziehen und angemessen zu verwalten. ANSSI empfiehlt außerdem, die Certificate-Transparency-Logs zu überwachen, um unrechtmäßige Zertifikate für die eigene Domain zu erkennen.

Wozu Sicherheits-Header dienen

Sicherheits-Header sind Anweisungen, die Ihr Server zusammen mit der Antwort an den Browser sendet. Der Besucher sieht sie nicht, doch sie legen fest, wie der Browser die Seite behandelt. Der Leitfaden von ANSSI zu browserseitigen Sicherheitsstandards empfiehlt insbesondere:

• Strict-Transport-Security (HSTS): sorgt dafür, dass der Browser die Website über HTTPS aufruft.
• Content-Security-Policy (CSP): begrenzt über eine Erlaubnisliste, aus welchen Quellen eine Seite Inhalte laden darf.
• Frame-Schutz: Die Einstellung frame-ancestors innerhalb der CSP schränkt ein, dass Ihre Seite in einem Frame auf einer anderen Website angezeigt wird, und schützt vor Clickjacking. ANSSI empfiehlt zusätzlich den Header X-Frame-Options als ergänzenden Schutz.
• Referrer-Policy: begrenzt die Adressinformationen, die der Browser an eine andere Website sendet. ANSSI empfiehlt, das Standardverhalten nicht beizubehalten.

Die CNIL zählt außerdem zu ihren grundlegenden Vorkehrungen, bei allen verwendeten Cookies die Optionen Secure und HttpOnly zu setzen.

Die Sicherheitsseite externer Skripte

Der Code eines Analyse-Tools oder einer Bibliothek aus einem Content Delivery Network liegt nicht auf Ihrem Server. Für Websites mit HTTPS empfiehlt ANSSI, die Integritätsprüfung (Subresource Integrity) systematisch einzusetzen, insbesondere für Ressourcen aus Content Delivery Networks. Stimmt die Datei nicht mit dem erwarteten Hashwert überein, blockiert der Browser sie. Nach dem Leitfaden funktioniert diese Prüfung nur bei CSS- und JavaScript-Dateien und setzt in der Regel Ressourcen voraus, deren Adresse eine Versionsnummer enthält.

ANSSI weist außerdem darauf hin, dass sich mit einer Content Security Policy sicherstellen lässt, dass auf Seiten, auf denen sensible Daten wie Passwörter oder Bankdaten eingegeben werden, keine Werbe- und Analyse-Skripte vorhanden sind. Die grundlegende Vorkehrung der CNIL weist in dieselbe Richtung: die Zahl der eingesetzten Komponenten begrenzen, sie beobachten und aktuell halten.

Regelmäßige Prüfung

Artikel 32 nennt auch ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit der Maßnahmen. Für Software, die auf Servern läuft, rät die CNIL, bei den kritischsten Verarbeitungen Werkzeuge zur Erkennung von Schwachstellen einzusetzen. Nach dem Leitfaden sollen diese Tests regelmäßig und vor jeder Inbetriebnahme einer neuen Softwareversion durchgeführt werden.

Wird ein neues Plugin installiert oder zieht das Hosting um, können sich auch die Einstellungen ändern. Wer die Prüfung in festen Abständen wiederholt und das Ergebnis aufbewahrt, kann auch leichter zeigen, welche Maßnahme wann geprüft wurde. Die Funktionsseite zeigt, wie der geplante Scan funktioniert.

Fünf häufige Fehler

• HTTPS nur auf der Login- oder Zahlungsseite einschalten und die übrigen Seiten unverschlüsselt lassen.
• Weiterhin HTTP-Verbindungen annehmen, ohne HSTS zu definieren.
• Das Zertifikat auf einer Website mit HSTS ungültig werden lassen.
• Externe Skripte ohne Integritätsprüfung auf jeder Seite laden, auch auf Seiten mit Formularen.
• Die Sicherheit einmal beim Start einrichten und nie wieder prüfen.

Checkliste

• Gibt es eine Liste der Seiten Ihrer Website, auf denen personenbezogene Daten erhoben werden?
• Werden alle Seiten über HTTPS aufgerufen?
• Lehnt Ihr Server Verbindungen über SSLv2, SSLv3, TLS 1.0 und TLS 1.1 ab?
• Wer behält das Ablaufdatum Ihres Zertifikats im Blick, und wie?
• Sind die Header HSTS, Content-Security-Policy, Frame-Schutz und Referrer-Policy definiert?
• Sind bei Ihren Cookies die Optionen Secure und HttpOnly gesetzt?
• Ist die Liste Ihrer externen Skripte aktuell, und wurden die nicht benötigten von Seiten mit Formularen entfernt?
• Werden diese Prüfungen in regelmäßigen Abständen wiederholt und die Ergebnisse aufbewahrt?

Die meisten Punkte dieser Liste lassen sich prüfen, indem man die Website von außen betrachtet. DILAYS scannt Ihre Website und zeigt die Ergebnisse für SSL, DNS, Sicherheits-Header und Cookies getrennt an. Welche Maßnahme Ihrem Risiko angemessen ist, entscheiden Sie.