Verschlüsselung ist oft ein Thema für die Sicherheit, aber auch für den Datenschutz. Das Ziel der Verschlüsselung besteht darin, zu verhindern, dass andere die verschlüsselten Informationen lesen. Sie können jedoch andere daran hindern, Ihre Informationen zu lesen. Dies ist eine Möglichkeit, sie vertraulich zu halten. Nutzer haben oft nur eingeschränkte Möglichkeiten, dies selbst zu tun, aber mit Ihrer Hilfe als Anbieter eines von ihnen verwendeten Dienstes kann die Verschlüsselung dazu beitragen, dass ihre Daten behalten.
Es gibt drei relevante Möglichkeiten, die Verschlüsselung zugunsten des Datenschutzes anzuwenden: Verschlüsselung während der Übertragung, Verschlüsselung inaktiver Daten und Ende-zu-Ende-Verschlüsselung:
- Bei der Verschlüsselung bei der Übertragung werden Daten zwischen dem Nutzer und Ihrer Website verschlüsselt, d. h. über HTTPS. Sie haben wahrscheinlich HTTPS für Ihre Websites eingerichtet, aber sind Sie sicher, dass alle Daten bei der Übertragung an Ihre Websites verschlüsselt sind? Dazu dienen Weiterleitung und HSTS. Sie werden unten beschrieben und sollten Teil der HTTPS-Einrichtung sein.
- Bei der Verschlüsselung ruhender Daten werden die auf Ihren Servern gespeicherten Daten verschlüsselt. Dies schützt vor Datenpannen und ist ein wichtiger Bestandteil Ihrer Sicherheitsposition.
- Bei der Ende-zu-Ende-Verschlüsselung werden Daten auf dem Client verschlüsselt, bevor sie Ihren Server erreichen. So werden Nutzerdaten auch vor Ihnen geschützt: Sie können die Daten Ihrer Nutzer zwar speichern, aber nicht lesen. Dies ist schwierig zu implementieren und nicht für alle Arten von Anwendungen geeignet. Es trägt jedoch stark zum Datenschutz für Nutzer bei, da niemand ihre Daten außer sich selbst sehen kann.
HTTPS
Der erste Schritt besteht darin, Ihren Webdienst über HTTPS bereitzustellen. Es ist sehr wahrscheinlich, dass Sie dies bereits getan haben, aber wenn nicht, ist er ein wichtiger Schritt. HTTPS ist HTTP. Das Protokoll, mit dem ein Browser Webseiten von einem Server anfordert, aber mit SSL verschlüsselt ist. Das bedeutet, dass ein externer Angreifer eine HTTPS-Anfrage zwischen dem Absender (Ihr Nutzer) und dem Empfänger (Ihnen) nicht lesen oder beeinflussen kann, da sie verschlüsselt ist und sie daher weder gelesen noch geändert werden kann. Dabei handelt es sich um Verschlüsselung bei der Übertragung, also während der Übertragung von Daten von Nutzer zu Ihnen oder von Ihnen zu Nutzer. Außerdem wird durch die HTTPS-Verschlüsselung bei der Übertragung verhindert, dass der Internetanbieter des Nutzers oder der Anbieter des verwendeten WLANs die Daten lesen kann, die er im Rahmen seiner Beziehung zu deinem Dienst an dich sendet. Dies kann sich auch auf die Funktionen Ihres Dienstes auswirken: Für viele Verwendungen vorhandener JavaScript APIs muss die Website über HTTPS bereitgestellt werden. Das MDN bietet eine umfassendere Liste. Zu den APIs, die hinter einem sicheren Kontext stehen, gehören aber auch Service Worker, Push-Benachrichtigungen, Webshare- und Web-Kryptowährungen sowie einige Geräte-APIs.
Sie benötigen ein SSL-Zertifikat, um Ihre Website über HTTPS bereitzustellen. Diese können über Let's Encrypt kostenlos erstellt werden oder gegebenenfalls von Ihrem Hostingdienst bereitgestellt werden. Es ist auch möglich, einen Drittanbieterdienst zu verwenden, der Ihren Webdienst als Proxy fungiert und HTTPS-, Caching- und CDN-Dienste bereitstellt. Es gibt zahlreiche Beispiele für solche Dienste, z. B. Cloudflare und Fastly. Welche davon genau Sie verwenden sollten, hängt von Ihrer aktuellen Infrastruktur ab. In der Vergangenheit konnte die Implementierung von HTTPS aufwändig oder teuer sein. Deshalb wurde es meist nur auf Zahlungsseiten oder besonders sicheren Ursprüngen eingesetzt. Aber durch frei verfügbare Zertifikate, Standardsverbesserungen und die zunehmende Verbreitung von Browsern sind all diese Hindernisse überwunden.
Das sollten Sie tun:
- Aktivieren Sie HTTPS auf Ihren Servern für alles, unabhängig davon, für welche Methode Sie sich entscheiden.
- Sie können vor Ihren Servern einen Proxy verwenden, z. B. Cloudflare (siehe httpsiseasy.com/).
- In Let's Encrypt erfahren Sie, wie Sie Ihr eigenes SSL-Zertifikat erstellen.
- Sie können auch direkt mit OpenSSL ein eigenes Zertifikat erstellen und von einer Zertifizierungsstelle signieren lassen. Unter HTTPS aktivieren finden Sie eine detaillierte Anleitung dazu.
Welchen Ansatz Sie wählen, hängt von geschäftlichen Kompromissen ab. Wenn Sie die SSL-Verbindung von einem Drittanbieter verwalten lassen, ist die Einrichtung am einfachsten und bietet weitere Vorteile wie Load-Balancing, Caching und Analysen. Allerdings bedeutet dies auch, dass Sie dem Drittanbieter eine gewisse Kontrolle und unvermeidbare Abhängigkeit von seinen Diensten (und möglicher Bezahlung, abhängig von den verwendeten Diensten und Ihrem Traffic-Aufkommen) abwenden.
Bisher wurde der SSL-Prozess so durchgeführt, dass Zertifikate generiert und von einer Zertifizierungsstelle signiert werden. Let's Encrypt kann jedoch einfacher sein, wenn es von Ihrem Anbieter unterstützt wird oder wenn Ihr Serverteam technisch versiert genug dafür ist, und es ist kostenlos. Es ist auch üblich, dass Ihr Anbieter SSL als Dienst anbietet, wenn Sie einen Dienst auf einer höheren Ebene als Cloud-Hosting verwenden. Daher lohnt es sich, eine Prüfung durchzuführen.
Gute Gründe
Sicherheit ist ein Teil Ihrer datenschutzbezogenen Story: Wenn Sie nachweisen können, dass Sie Nutzerdaten vor Störungen schützen, schaffen Sie Vertrauen. Wenn Sie kein HTTPS verwenden, werden Ihre Websites von Browsern ebenfalls als „nicht sicher“ gekennzeichnet. Dies wird schon seit einiger Zeit der Fall sein. Vorhandene JavaScript APIs sind häufig nur für HTTPS-Seiten („sicherer Ursprung“) verfügbar. Außerdem sind Ihre Nutzer so vor ihren Internetnutzungsdaten für den Internetanbieter geschützt. Dies ist auf jeden Fall eine Best Practice. Es gibt wenig bis keinen Grund, HTTPS derzeit nicht für Websites zu verwenden.
So präsentieren Browser eine nicht sichere HTTP-Seite
Zu HTTPS weiterleiten
Wenn Ihre Website sowohl unter „http:“- als auch unter „https:“-URLs verfügbar ist, sollten Sie alle HTTP-URL-Zugriffe zu „https“ weiterleiten. Dies ist auf die oben genannten Gründe zurückzuführen. Außerdem wird dadurch sichergestellt, dass Ihre Website nicht auf whynohttps.com erscheint, wenn sie beliebt wird. Die genaue Vorgehensweise hängt stark von Ihrer Infrastruktur ab. Wenn Sie auf AWS gehostet werden, können Sie einen klassischen oder einen Anwendungs-Load-Balancer verwenden. Google Cloud ist ähnlich. In Azure können Sie eine Front Door erstellen, in Node mit Express check for request.secure, in Nginx alle Port 80 erfassen und 301 zurückgeben und in Apache eine RewriteRule verwenden. Wenn Sie einen Hostingdienst verwenden, übernimmt dieser mit großer Wahrscheinlichkeit automatisch die Weiterleitung zu HTTPS-URLs für Sie, z. B. Netlify, Firebase und GitHub-Seiten.
HSTS
HSTS ist die Abkürzung für „HTTP Strict-Transport-Security“. Damit können Browser dauerhaft für die Nutzung von HTTPS für Ihren Dienst gesperrt werden. Wenn Sie mit der Migration zu HTTPS zufrieden sind oder dies bereits getan haben, können Sie Ihren ausgehenden Antworten einen HTTP-Antwortheader für Strict-Transport-Security hinzufügen. Ein Browser, der schon einmal auf Ihre Website zugegriffen hat, zeichnet auf, dass dieser Header gesehen wurde und greift von nun an automatisch über HTTPS auf diese Website zu, auch wenn Sie HTTP anfordern. Dadurch wird die Weiterleitung wie oben beschrieben vermieden: Es ist, als würde der Browser alle Anfragen an Ihren Dienst im Hintergrund auf HTTPS aktualisieren.
Ebenso können Sie den Header Upgrade-Insecure-Requests zusammen mit Ihren Seiten bereitstellen. Der Fehler hat etwas anderes als Strict-Transport-Security. Wenn Sie Upgrade-Insecure-Requests: 1 hinzufügen, werden Anfragen von dieser Seite an andere Ressourcen (Images, Skripts) als HTTPS angefordert, auch wenn der Link HTTP ist. Der Browser fordert die Seite selbst jedoch nicht noch einmal als HTTPS an und merkt sich diese für das nächste Mal nicht. In der Praxis ist „Upgrade-Insecure-Requests“ nützlich, wenn Sie eine bestehende Website mit vielen Links zu HTTPS konvertieren und die Konvertierung der Link-URLs im Inhalt schwierig ist. Es ist jedoch besser, den Inhalt nach Möglichkeit zu ändern.
HSTS ist in erster Linie eine Sicherheitsfunktion: Ihre Website wird für Nutzer, die die Website schon einmal besucht haben, auf HTTPS gesperrt. Wie oben erwähnt, ist HTTPS jedoch gut für den Datenschutz und HSTS gut für HTTPS. Upgrade-Insecure-Requests ist ebenfalls nicht erforderlich, wenn Sie alle Ihre Inhalte aktualisieren. Es ist jedoch ein nützlicher Ansatz mit geschweiften Klammern, um einen tiefgreifenden Schutz zu ermöglichen, damit Ihre Website immer über HTTPS funktioniert.
Das sollten Sie tun:
Fügen Sie Ihren ausgehenden Antworten den HSTS-Header hinzu:
Strict-Transport-Security: max-age=300; includeSubDomains
Mit dem Parameter „max-age“ wird festgelegt, wie lange (in Sekunden) der Browser das HTTPS-Upgrade speichern und erzwingen soll. (Hier haben wir die Dauer auf 300 Sekunden eingestellt, also fünf Minuten.) Am Ende sollten Sie als Wert 6.3072.000 angeben, was zwei Jahren entspricht. Dies ist der Wert, den hstspreload.org empfiehlt. Er lässt sich jedoch nur schwer wiederherstellen, wenn es Probleme gibt. Daher empfiehlt es sich, zuerst eine niedrige Zahl (300) festzulegen, zu testen, ob nichts kaputt ist, und dann die Anzahl schrittweise erhöhen.
Fügen Sie Ihren ausgehenden Antworten die Header Upgrade-Insecure-Requests hinzu:
Upgrade-Insecure-Requests: 1
Content-Security-Policy: upgrade-insecure-requests
Ende-zu-Ende-Verschlüsselung
Eine gute Möglichkeit, Nutzerdaten zu schützen, besteht darin, sie nur dem Nutzer und auch nur Ihnen zu zeigen. Das ist sehr hilfreich für Ihre Vertrauensstellung: Wenn Sie die Daten Ihrer Nutzer nicht haben, ist klar, dass Sie damit nichts tun können, was sie nicht möchten. Eine Möglichkeit besteht darin, alle Daten clientseitig auf ihrem Gerät zu speichern, damit die Daten gar nicht das Gerät verlassen. Dieser Ansatz funktioniert, hat aber Einschränkungen für eine reine clientseitige Anwendung: Die Größe der Browserdaten kann begrenzt sein und in einigen Browsern werden nur wenige oder keine Warnung angezeigt. Außerdem ist es schwierig oder unmöglich, über zwei Geräte, z. B. einen Laptop und ein Mobiltelefon, auf Ihre Daten zuzugreifen. Aus diesem Grund kann es sinnvoll sein, Daten wie gewohnt an den Server zu senden, sie jedoch mit einem nur dem Nutzer bekannten Schlüssel zu verschlüsseln, damit der Server nicht auf die Daten zugreifen kann (weil er sie nicht entschlüsseln kann), sie aber speichern kann.
Wie funktioniert das?
Dieser Ansatz wird häufig von Messaging-Anwendungen verwendet, bei denen er als „Ende-zu-Ende-Verschlüsselung“ oder „e2e“ bezeichnet wird. Auf diese Weise können zwei Personen, die die Schlüssel des anderen kennen, ihre Nachrichten ver- und entschlüsseln und diese Nachrichten über den Messaging-Anbieter senden. Der Messaging-Anbieter (der diese Schlüssel nicht hat) kann die Nachrichten jedoch nicht lesen. Die meisten Anwendungen sind keine Messaging-Anwendungen. Es ist jedoch möglich, die beiden Ansätze – ein rein clientseitiger Datenspeicher und die Datenverschlüsselung mit einem dem Client bekannten Schlüssel – zu kombinieren, um Daten lokal zu speichern und sie auch verschlüsselt an den Server zu senden. Beachten Sie, dass dieser Ansatz Grenzen hat: Dies ist nicht für alle Dienste möglich. Insbesondere kann er nicht verwendet werden, wenn Sie als Dienstanbieter Zugriff auf die vom Nutzer gespeicherten Daten benötigen. Wie in Teil 2 dieser Reihe beschrieben, sollte das Prinzip der Datenminimierung befolgt werden; möglichst keine Daten erheben. Wenn der Nutzer Datenspeicher benötigt, Sie aber keinen Zugriff auf diese Daten benötigen, um den Dienst bereitzustellen, ist die Ende-zu-Ende-Verschlüsselung eine nützliche Alternative. Wenn Sie Dienste anbieten, für die Daten verfügbar sein müssen, die der Nutzer für die Bereitstellung des Dienstes gespeichert hat, ist die Ende-zu-Ende-Verschlüsselung nicht geeignet. Andernfalls können Sie alle Daten, die an den Server gesendet werden, mit dem clientseitigen JavaScript Ihres Webdienstes verschlüsseln und empfangen.
Beispiel: Excalidraw
Excalidraw erklärt dies in einem Blogpost und erklärt dies entsprechend. Es ist eine Vektor-Zeichen-App, die Zeichnungen auf dem Server speichert, die mit einem zufällig ausgewählten Schlüssel verschlüsselt werden. Excalidraw kann diese Ende-zu-Ende-Verschlüsselung unter anderem mit relativ wenig Code implementieren, weil Kryptografiebibliotheken jetzt mithilfe von window.crypto in den Browser integriert sind. Dies ist eine Reihe von JavaScript APIs, die in allen modernen Browsern unterstützt werden. Die Kryptografie ist schwierig und
die Implementierung der Algorithmen birgt viele Grenzfälle. Wenn der Browser den Großteil der Arbeit hier übernimmt, wird die Verschlüsselung für Webentwickler leichter zugänglich und erleichtert die Implementierung des Datenschutzes über verschlüsselte Daten. Wie Excalidraw in seiner Beschreibung beschreibt, bleibt der Verschlüsselungsschlüssel clientseitig auf der Clientseite erhalten, da er Teil des URL-Fragments ist: Wenn ein Browser eine URL https://example.com/path?param=1#fraghere aufruft, werden der Pfad der URL (/path) und die Parameter (param=1) an den Server (example.com) übergeben, aber das Fragment (fraghere) nicht. Daher sieht der Server ihn nie. Das bedeutet, dass der Verschlüsselungsschlüssel selbst dann nicht weitergegeben wird, wenn die verschlüsselten Daten den Server durchlaufen. Der Datenschutz bleibt erhalten, da die Daten mit Ende-zu-Ende-Verschlüsselung geschützt sind.
Beschränkungen
Diese Art der Verschlüsselung von Nutzerdaten ist nicht absolut zuverlässig. Sie trägt zu Ihrer Vertrauensstellung bei Ihren Nutzern bei, kann sie aber nicht vollständig ersetzen. Ihre Nutzer müssen Ihrem Dienst dennoch vertrauen, da Sie Client-seitigen JavaScript-Dienst jederzeit gegen sehr ähnliches JavaScript austauschen können, das Daten nicht undurchdringlich verschlüsselt. Auch wenn es als Nutzer möglich ist, zu erkennen, ob eine von Ihnen verwendete Website dies bereits getan hat, ist dies äußerst schwierig. In der Praxis müssen Ihre Nutzer aber darauf vertrauen, dass Sie einem Anbieter nicht absichtlich einen so vertrauenswürdigen Anbieter von Daten lesen und missbrauchen können.
Eines der Ziele der Ende-zu-Ende-Verschlüsselung besteht darin, dich als Websiteinhaber daran zu hindern, die Daten zu lesen. Das ist gut für den Datenschutz, bedeutet aber auch, dass Sie bei Problemen nicht helfen können. Im Wesentlichen übernimmt ein Dienst mit Ende-zu-Ende-Verschlüsselung die Verantwortung für die Verschlüsselungsschlüssel. (Dies ist möglicherweise nicht offensichtlich oder offen, aber jemand muss den Schlüssel haben, und wenn Daten vor Ihnen geheim gehalten werden, dann sind Sie das nicht.) Wenn diese Schlüssel verloren gehen, können Sie nichts weiter tun. Wahrscheinlich gehen dann auch alle mit diesen Schlüsseln verschlüsselten Daten verloren. Es gibt einen guten Balanceakt zwischen Datenschutz und Nutzerfreundlichkeit: Sie sollten die Daten vor allen anderen durch Verschlüsselung schützen, aber vermeiden Sie es, Nutzer dazu zu zwingen, Kryptologieexperten zu sein, die ihre eigenen Schlüssel auf sichere Weise verwalten.
Verschlüsselung inaktiver Daten
Neben der Verschlüsselung der Nutzerdaten bei der Übertragung ist es auch wichtig, die auf dem Server gespeicherten Daten zu verschlüsseln. Dies trägt zum Schutz vor Datenpannen bei, da jeder unautorisierten Zugriff auf Ihre gespeicherten Daten über verschlüsselte Daten verfügt, die dann hoffentlich nicht die Schlüssel zum Entschlüsseln haben. Es gibt zwei verschiedene und komplementäre Ansätze zum Verschlüsseln von inaktiven Daten: die von Ihnen hinzugefügte Verschlüsselung und die von Ihrem Cloud Storage-Anbieter hinzugefügte Verschlüsselung (falls Sie einen Cloud Storage-Anbieter verwenden). Die Verschlüsselung des Speicheranbieters bietet keinen großen Schutz vor Datenpannen über Ihre Software, da die Verschlüsselung des Speicheranbieters für Sie als Nutzer seines Dienstes in der Regel transparent ist. Sie hilft jedoch vor Sicherheitsverletzungen in der Infrastruktur des Anbieters. Die Aktivierung ist oft einfach und lohnt sich daher. Dieses Feld ändert sich schnell und Ihr Sicherheitsteam (oder sicherheitsversierte Entwickler in Ihrem Team) kann Sie am besten beraten. Alle Cloud Storage-Anbieter bieten jedoch eine Verschlüsselung inaktiver Daten für Blockspeicher, Amazon S3, standardmäßig, Azure Storage und Google Cloud Storage, sowie für die Datenspeicherung in Datenbanken AWS RDS, Azure SQL, Google Cloud SQL an. Wenden Sie sich an Ihren Cloud Storage-Anbieter, falls Sie einen verwenden. Die Verschlüsselung inaktiver Daten zum Schutz von Nutzerdaten vor Datenpannen ist schwieriger. Dies liegt daran, dass die Logistik der Verschlüsselungsschlüssel sicher verwaltet und für den Code verfügbar gemacht werden muss, ohne sie auch Angreifern zugänglich zu machen. Dies ist nicht der beste Ort, um bei Sicherheitsproblemen dieser Ebene zu beraten. Sprechen Sie mit Ihren sicherheitsversierten Entwicklern oder dedizierten Teams darüber oder mit externen Sicherheitsbehörden.