Datenschutz bei Websites

Hallihallo,
worauf sollte man besonders achten, wenn man eine datenschutzkonforme Website erstellen (lassen) möchte?

Das man sich mit dem Thema Cookies und Cookie-Banner auseinander setzt und nur das nötigste im Einsatz hat. Wenn man z.B. Google Web Fonts für die Schriftart benutzen will, kann man dies selber hosten und muss sich die Schriftart nicht von Google Servern aus den USA einbinden lassen mit dem Nebeneffekt, dass man die IP-Adressen der User übermittelt.

→ eine “cleane” Webseite ist Trumpf

1 „Gefällt mir“

Noch als Ergänzung:
Beim Einsatz von Dritten die auf pbD Zugriff haben (Google Analytics, CRM Dienstleister, Web Hoster etc) ist auch auf die Vorgaben zur Auftragsverarbeitung zu achten.

2 „Gefällt mir“

Absolut - War auch nur ein Beispiel, man kann auch sagen Video tools, APIs etc.

2 „Gefällt mir“

Als Ergänzung hierzu: Bei der Einbindung von Drittanbieter Ressourcen Zurückhaltung üben. Aktuell grassiert die Unart fremde Subdomänen über einen Eintrag im CNAME Ressource Record einzubinden. Damit “umgeht” man Blockierlisten von Anti-Tracking-Addons und Browsertrackingprotection.

Hier geht man als Webseitenbetreiber ein gehöriges Risiko ein, wenn hier etwas schief läuft: i) Dangleing DNS / Subdomain Takeover und ii) Cookie-Leaking. Die Folge ist u.U. ein Verstoß gegen Art. 32 DSGVO “Sicherheit der Verarbeitung”.

2 „Gefällt mir“

Das ist schon eine schöne Liste, ich habe da noch ein paar Ergänzungen.

Ich find das ein bisschen verwirrend formuliert; technisch zwingend notwendige Cookies benötigen kein Einverständnis, da reicht ein Hinweis in der Datenschutzerklärung. Alle optionalen (Tracking, Werbung, Analytics) Cookies benötigen eine freiwillige Einwilligung.

Hiervon fällt einiges eher unter die Kategorie “Webserver-Hardening”. Was den Hersteller angeht bin ich mir nicht sicher wie die Vertrauenswürdigkeit des Zertifikatsausstellers zu bewerten ist (unabhängig davon sind nur Zertifikatsaussteller vertrauenswürdig die von den Brwosern akzeptiert werden, aber darüber hinaus?)
Das Zertifikat an sich hat keinen direkten Zusammenhang mit der SSL/TLS-Version die der Server anbietet (Es gibt kein SSLv3-Zertifikat, der Server liefert aber eine SSLv3-Verschlüsselung aus wenn das in der Konfiguration nicht deaktiviert ist.). Allgemein sollte der Webserver so gehärtet sein, dass veraltete oder nicht sichere Verschlüsselungsversionen Serverseitig deaktiviert sind.
Durch HSTS sollte ein unverschlüsselter Besuch der Website gar nicht möglich sein, zusätzlich lässt sich in der Webserverkonfigurations jegliche unverschlüsselte Verbindung deaktivieren. Ein Monitoring welches auch die Gültigkeit des Zertifikats im Blick behält ist sinnvoll.
Zum Thema Webserver und möglichem CMS sollte darauf geachtet werden dass die gesamte Software auf dem aktuellen Stand ist und Aktualisierungen zeitnah (am besten am gleichen Tag) eingespielt werden.

Auch das gehört wieder zum Thema Webserver-Hardening, ich denke nicht dass das Ausblenden von der Versionsnummer einen großen Beitrag zur Sicherheit leistet. In dem Zusammenhang weise ich auch auf mögliche “debug”-Einstellungen hin. Bitte achtet darauf dass jegliche Software im Webserver im Produktivmodus und nicht in einem Entwicklungs- oder Testmodus läuft.

Ich halte, falls du eine robots.txt meinst, das Werkzeug für nicht ausreichend um personenbezogene Daten im Sinne des Rechts auf Löschung zu schützen. Ich glaube nicht dass es einen Weg gibt im Internet veröffentliche Daten dauerhaft verlässlich zu löschen.

Bei diesem ganzen Thema sehe ich eine sehr enge Überschneidung mit dem Thema IT-Sicherheit. Da hat das BSI bestimmt auch ein paar gute Tipps und Hinweise.

Möchtest du nicht lieber zum BSI gehen? :slight_smile:

2 „Gefällt mir“

Schade, ich vermute dass es dem BSI gut tun würde wenn du zu denen gehst damit die die unsinnigen Sachen abstellen und du dem BSI beibringen kannst wie das eigentlich sein sollte. :slight_smile:

Grundsätzlich kann ich nachvollziehen was du meinst. Ich habe geschrieben dass ich nicht der Meinung bin dass es einen hohen Sicherheitsgewinn bei dieser Maßnahme gibt. Das fühlt sich für mich nach der typischen Security through Obscurity-Diuskussion an, daher versuche ich das ein wenig deutlicher zu formulieren.
Systeme auf den aktuellen Patchlevel zu bringen, in welchem alle bekannten Sicherheitslücken geschlossen sind, halte ich für wichtiger und wirkungsvoller als die Versionsnummer zu verstecken damit nicht auf den ersten Blick klar ist welche Sicherheitslücken im System offen sind.
Ja, die Versionsnummer ausblenden macht das System ein Stück weit sicherer, aber andere Maßnahmen verbessern die IT-Sicherheit deutlicher und sind hilfreicher.

1 „Gefällt mir“

In diesem Kontext eine ergänzende Frage:
Bei kostenlosen/kostenpflichtigen Tools zur automatisierten (Vor-)Prüfung einer Website fallen mir ad hoc:

ein.

Wie steht ihr zu dem Thema und welche Tools (inkl. Kostenplan/Paket) nutzt ihr?
Welche Erfahrungen habt ihr mit automatisierten Websiteprüfungen (teilweise mit angepriesener automatisierter Prüfung der Rechtstexte) gemacht?

1 „Gefällt mir“

Hier noch ein paar weitere Anmerkungen

Cookies

Wie sichere ich den einen Keks ab? Vorm Krümelmonster verstecken? Nein ernsthaft, wie sichere ich so einen ab?

Was man ja machen kann, ist ein Cookie nur für einen bestimmten Pfad setzen.

Ein Hauptanwendungsfall von Cookies ist die Speicherung des Sitzungsidentifikators. Kommt man an dieses Cookie ran und die Sitzungseinstellungen der Anwendung sind auf eine Zeitüberschreitung der Sitzung nach 10 Tagen eingestellt, kann dieses Cookie ohne Abmeldung des betroffenen Nutzers so lange verwendet werden. Also wäre hier eine “abgesicherte” Sitzungskonfiguration wohl eher zu empfehlen.

Man könnte das Sitzungscookie auch verschlüsseln, bloß bringt das vermutlich nichts. Ob man das verschlüsselte oder unverschlüsselte Cookie als Angreifer an den Server sendet ist ja egal.

Bei einigen Cookies könnte Verschlüsselung aber schon Sinn machen. Um z. B. Angreifern keine interne Struktur der Anwendung zu verraten, die über die Cookies bekannt werden würde.

Was gemacht werden kann sind folgende Cookie-Eigenschaften zu setzen wenn benötigt:

  • path für den das Cookie gültig ist
  • secure wenn gesetzt, wird das Cookie nur über mit TLS verschlüsselte Verbindungen gesendet (Vertraulichkeit & Authentizität)
  • port Liste von Ports bei welchen das Cookie bei der Anfrage mitgegeben wird
  • domain zum expliziten angeben der Domäne bei welcher das Cookie mitgesendet werden soll
  • discard um Nutzer Agenten explizit mitzuteilen, dass das Cookie nach beenden des Browsers gelöscht werden soll
  • max-age wie lange das Cookie gültig ist
    Siehe auch RFC 2965

Keine Cookies zu verwenden ist zwar schwierig, sollte aber in jedem Fall angestrebt werden.

Zertifikate

Bezüglich der TLS Zertifikate und der Konfiguration der entsprechenden Webserver, Datendanksysteme und eventuell für die Webseite vorhandene Mailserver ist der TLS Konfigurationsgenerator von Mozilla meinerseits zu empfehlen.

Dadurch geht man dem Problem aus dem Weg, welche Cipher Suites noch sicher bzw. zu empfehlen sind. Natürlich alles unter der Voraussetzung, dass der Konfigurator aktuell gehalten wird.

Bezüglich TLS Protokoll Versionen ist mir aus einer Kryptographie Vorlesung bekannt, dass Versionen 1.2 und 1.3 aktuell als sicher gelten und guten Gewissens empfohlen werden können. Das deckt sich auch mit den deaktivierten Versionen (Intermediate Configuration siehe Konfigurator Verweis oben).

HPKP wird anscheinend nicht mehr empfohlen

Skripte und Verweise

Wenn möglich kein Javascript verwenden, ansonsten die CSP Kopfzeile entsprechend der vertrauenswürdigen Quellen richtig konfigurieren.
Zusätzlich kann die Integrität (siehe SRI) der zu ladenden Skripte und Verweise mittels eines Hash-Werts überprüft werden. Dieser kann als integrity Attribut bei Skripten (script) und Links (link) angegeben werden und beschränkt sich dabei nicht auf Skripte und Stilvorlagen.
Eine Beispiel:

<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.12.0/css/all.css"
      integrity="sha256-ybRkN9dBjhcS2qrW1z+hfCxq+1aBdwyQM5wlQoQVt/0=" crossorigin="anonymous"/>
<script src="http://code.jquery.com/jquery-3.5.1.min.js"
    integrity="sha256-9/aliU8dGd2tb6OSsuzixeV4y/faTqgFtohetphbbj0=" crossorigin="anonymous"></script>

Wichtig zu erwähnen ist hier wohl, dass wenn die Ressource von einer anderen Domäne geladen wird das crossorigin="anonymous" Attribut explizit gesetzt werden muss. Andernfalls prüft der Browser die Prüfsumme nicht und die entsprechende Prüfsumme ist nutzlos.
Hier ein SRI Onlinegenerator und auch der Befehl für openssl.

HTTP Kopfzeilen

  • HSTS (siehe RFC)
  • XSS Schutz (Die üblichen Kopfzeilen sind nur noch für ältere Browser notwendig, sonst seit CSP obsolet… Siehe MDN)
  • CSP Zum Einstellen, von welcher Domäne ein Frame eingebunden werden darf, woher Skripte geladen werden dürfen etc. Siehe W3C Arbeitsentwurf
1 „Gefällt mir“

Über das ganze technische sollten natürlich auch die Grundsätze der Datensparsamkeit etc. nicht in Vergessenheit geraten. Das kann man natürlich beliebig weit drehen und nobody is perfect.

Auch dieses Forum z.B. lässt beim Passwort-zurücksetzen einfach zu, herauszufinden, welche Mailadressen registriert sind und welche nicht, weil die Rückmeldung unnötig eindeutig ist (wenn auch komfortabel für den Benutzer oder die Benutzerin bei Typos, das ist ja immer das Dilemma. :wink: Bei uns wäre das so erst einmal nicht zulässig.

Oder gehört das eher in den Thread zum Forum??

https://forum.bfdi.bund.de/t/zum-forum/62?u=stonie

2 „Gefällt mir“

Ich sag mal danke für die ganzen Hinweise, was euch nicht hindern soll, hier noch weiter zu schreiben. :+1::star_struck:

1 „Gefällt mir“

Das kommt darauf an, welche Daten mit dieser Webseite verarbeitet werden sollen. Für eine normale Webseite, mit der keine personenbezogenen Daten verarbeitet werden, würde sogar HTTP genügen. Für einen Online-Shop liegt die Hürde schon höher. Habt Ihr etwas spezielles geplant? Was soll der Zweck der Webseite sein?

Das kann ich nicht bestätigen.

Datenschutzkonform bedeutet nach meinem Verständnis die Anwendung der Datenschutzvorschriften (DSGVO, BDSG u.a.). Gem. Art.2 ist die DSGVO grundsätzlich anwendbar, wenn personenbezogene Daten verarbeitet werden. Das heißt im Umkehrschluss: Werden keine personenbezogenen Daten verarbeitet, ist sie nicht anwendbar. Woraus folgt: Für eine normale Webseite, mit der keine personenbezogenen Daten verarbeitet werden, gilt die DSGVO nicht. Warum die Zuordnung der Datenschutzvorschriften zu datenschutzkonform? Diese unterliegen im Gegensatz zu gefühltem Datenschutz dem Rechtsstaatsprinzip.

Unabhängig von einer solchen normalen Webseite sehe ich die Hintergrundprozesse (Webserver etc.), denn diese verarbeiten regelmäßig personenbezogene Daten. Diese Daten existieren unabhängig von HTTP / HTTPS und darauf sind die Vorschriften idR anzuwenden.

Selbstverständlich kann man bei jeder Webseite HTTPS einsetzen, jedoch kann man es nicht in jedem Fall mit datenschutzkonform begründen.

Etwas anderes ist eine für jegliche Daten einsetzbare Informationssicherheit, bei der man sich dieselben Fragen wie beim Datenschutz stellen kann: Wie hoch ist das Risiko, dass eine normale Webseite auf dem Weg zum Anwender manipuliert wird? Wer könnte so etwas unter welchen Voraussetzungen umsetzen? Ein Angreifer benötigte dafür den Zugriff auf eine Komponente in der Auslieferungskette (Webserver, Router etc.).

Besteht die Gefahr der Manipulation (zB Austausch eines Bildes durch ein Bild mit eingebettetem Bundestrojaner), wäre HTTPS eine Möglichkeit dies einzuschränken, sofern das Root-Zertifikat vertrauenswürdig ist. Nach meiner Ansicht ist ein Root-Zertifikat vertrauenswürdig, wenn es aus der eigenen PKI stammt. Was bei Webseiten regelmäßig nicht der Fall ist, da zum überwiegenden Teil die Zertifikate fremder Anbieter genutzt werden. Ich kann mich an an diverse Anbieter erinnern, deren Root-Zertifikate aus den Browsern entfernt wurden. Bei Überlegungen zu MITM sollte man außerdem im Hinterkopf behalten, dass die Voraussetzungen für eine Manipulation von HTTPS dieselben wie bei HTTP sind.

Fragt aber jemand nach einer datenschutzkonformen Webseite, ist die Standardfrage zunächst dieselbe wie bei allen Verarbeitungen: Welche Daten soll die Webseite zu welchem Zweck verarbeiten? An dieser Verarbeitung richten sich Risikoeinschätzung und Einsatz technischer Maßnahmen aus (wie zB der Einsatz einer eigenen PKI).

Mein erster Anlaufpunkt für Informationen zur Sicherheit von Webseiten, die auch beim Datenschutz zum Tragen kommt, wäre wohl OWASP.

Gut, ich präzisiere: Aus eigener Erfahrung kann ich nicht bestätigen, dass “viele Suchmaschinen die Website bei HTTP systematisch ausschließen” und “auch viele Browser […] diese inzwischen gar nicht mehr anzeigen”. Ebenso wenig sehe ich Auswirkungen auf das Ranking oder eine Abhängigkeit von der Beliebtheit. Der “marketing-2”-Link erzählt mir etwas von Google Chrome. Das ist ein Browser und nicht viele.

Aber es ist schön, dass wir tun, was Google will, während die Browserentwickler nicht einmal prüfen, wovor sie warnen. Dabei wäre es so einfach, keine Formularfelder im Quelltext zu finden, um festzustellen, dass es keine Eingabemöglichkeiten gibt, vor denen gewarnt werden müsste. Und was täten wir nur ohne diese fürsorglichen Browserentwickler, die die Anzeige von Protokoll und Subdomain durch Eigeninterpretationen ersetzen - nicht aus Sicherheitsgründen sondern wegen vermeintlicher Trivialität. *daumen hoch such*

Für die Frage nach Datenschutzkonformität ist dies jedoch irrelevant. Spätestens bei der Verwendung einer eigenen PKI geben die mir bekannten Browser eine Warnung aus, wenn das Root-Zertifikat nicht im Zertifikatsstore vorhanden ist. Soviel zu Sinn und Unsinn im Teufelskreis.

Tja, dann haben wir wohl verschiedene Ansichten.

In jedem Fall wird bei dem Besuch der Website ja die Besucher-IP verarbeitet. Websitenutzung ohne personenbezogene Daten kann ich mir deshalb nicht recht vorstellen…

1 „Gefällt mir“

Wenn Du eine Agentur zu Rate ziehen willst, dann solltest Du eine solche Agentur sorgsam auswählen.

Wie Du hier lesen kannst, ist technisches Know-How genauso wichtig wie rechtliches Wissen.
Ein Anhaltspunkt für einen bewussten Umgang mit Daten (technisch wie rechtlich) sind z.B. die einschlägigen ISO-Zertifikate. Kleinere Agenturen werden damit nicht aufwarten können, aber nichtsdestotrotz sollten auch diese Agenturen technische und organisatorische Maßnahmen (TOMn) zur Gewährleistungs der Datensicherheit aufgestellt haben und kontinuierlich aktualisieren. Lass sie Dir doch mal zeigen oder in einem Meeting nebenbei erläutern. :wink:

P.S.:

Dito! :star_struck:

1 „Gefällt mir“

Das ist richtig. Die Meinungsverschiedenheit zwischen @anon52331922 und mir drehte sich aber um HTTP vs. HTTPS in Bezug auf Datenschutzkonformität bzw. auf Akzeptanz seitens der Browserhersteller und Suchmaschinen.

Wenn eine Webseite keine Eingabemöglichkeiten für personenbezogene Daten beinhaltet, vom Anwender außer der IP und den Browserdaten (OS-Version, User-Agent, Schriftarten etc.) keine weiteren personenbezogenen Daten übertragen werden, dann kommen nur die oben genannten Hintergrundprozesse zum Einsatz. Bei einem Online-Shop zum Beispiel sieht das anders aus. Dort muss sich angemeldet, eine Adresse eingegeben werden usw. Hier übermittelt der Browser diese zusätzlich eingegebenen Daten und dann ist eine HTTPS-Verbindung natürlich erforderlich. Doch sowohl bei HTTPS als auch bei HTTP wird die IP übermittelt. Der Unterschied bei einer Webseite ohne Eingabemöglichkeiten (und Cookies, Analysetools o.ä.) besteht darin, dass bei HTTP für einen Lauscher zusätzlich die Browserdaten sichtbar sind. Über das Risiko, das diese Browserdaten bergen, kann man sich streiten. Nach meiner Ansicht besteht eines, wenn der Anwender gezielt ausspioniert wird, zB weil jemand den Anwender direkt angreifen will oder einen Browser bestimmten Typs aufs Korn nimmt. Das setzt allerdings voraus, dass der Angreifer oder “Spion” als Man-in-the-Middle agieren kann.
Der Verantwortliche hingegen erhält diese Daten immer, unabhängig von HTTP oder HTTPS, und mus sich überlegen, inwieweit er diese Daten in seinen Hintergrundprozessen verarbeitet.

Übrigens kann man auch HTTP-Seiten mit einer Content-Security-Policy versehen und die Möglichkeiten einer Manipulation einschränken.

2 „Gefällt mir“

Hier noch ein Link zum RFC welcher die älteren TLS Versionen als veraltet ausweist.

Ich habe es in letzter Zeit immer öfter gesehen, dass man auf Webseiten die Cookies nur noch selbst umständlich durch die Browsereinstellungen ausschalten kann.
Bei der Cookie-Abfrage wird der Banner mit “Ok” oder “Einverstanden” angezeigt und ich muss dann in der Datenschutzerklärung nachlesen, dass trotzdem Third Party- Cookies eingesetzt werden. Diese können nur über die Browser-Einstellung “ausgeschaltet” werden. Ich kann also auf der Webseite nichts anderes tun, als die Cookies zu akzeptieren.

Ich lese dann folgenden Text so oder so ähnlich in der Datenschutzerklärung: "Wenn Sie Ihre Zustimmung widerrufen möchten, können Sie jederzeit mithilfe Ihrer Browsereinstellungen Cookies auf Ihrem Gerät ablehnen oder entfernen. Dies kann jedoch verhindert, dass Sie die volle Funktionalität unserer Webseite nutzen können.

Wenn Sie Google-Anzeigen, […] deaktivieren möchten, können Sie die Seiten von Google zur Deaktivierung aufrufen: …"

Meiner Meinung nach ist das nicht dsgvo-konfrom. Ist es dem Verbraucher wirklich zumutbar, dass er das selbst im Browser einstellen muss? Ich weiß, dass es nicht schwer ist diese Einstellungen zu machen, aber der uninteressierte Normalbürger klickt ja noch nicht einmal auf die Schaltfläche “alle ablehnen”, wenn er die Möglichkeit dazu bekommt. Nudging steht ja auch scharf in der Kritik, wobei man hier wenigstens noch tatsächlich auf der Webseite wählen kann.

Wie seht ihr das? Ich lass mich da gerne eines besseren belehren :slight_smile:

1 „Gefällt mir“