End-to-End-Security, Teil 2

Aus MittelstandsWiki
Version vom 5. Juli 2018, 10:48 Uhr von FEichberger (Diskussion | Beiträge) (korr.)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Einmalschlüssel mit Verfallsdatum

Von Uli Ries

Eine durchgängige End-to-End-Verschlüsselung hat ihre Tücken, nicht nur wenn es um die Sicherheit im Mail-Verkehr geht. Auch beim Umgang mit Dateien kann Verschlüsselung die serverseitigen Dienste ausbremsen, z.B. wenn man Bilder oder Videos beim Cloud-Storage-Anbieter lagert. Dann lassen sich die Inhalte nur lokal nach Download und Entsperren betrachten. Videostreaming oder eine schnelle Durchsicht von Fotoalben sind dann unmöglich, da der Server die Dateien ja nicht einlesen kann.

„Soll ein Server Daten bearbeiten, wie es z.B. bei dynamischem Webcontent oder dem Abarbeiten von SQL-Anfragen notwendig wird, dann muss er auf die Daten zugreifen und sie verstehen können. Dies impliziert, dass die Daten auf dem Server im Klartext zugreifbar sein müssen“, erklärt Udo Schneider von Trend Micro. Hier bliebe dann meist nur der Rückgriff auf die Transportverschlüsselung per SSL/TLS.

Das Gleiche gilt laut Thomas Hemker für die derzeit so beliebten Analysen von großen Datenmengen (Big Data) in der Cloud: Damit der Datenbankcluster des Cloud-Anbieters die jüngsten Verkaufstrends im gigantischen Datenbestand des Kunden ausmachen kann, müssen die Rohdaten ohne weiteren Schutz in der Datenbank abgelegt sein. Einzig die Datenbank selbst lässt sich auf Dateisystemebene schützen und so z.B. gegen Diebe schützen, die sich Zugriff auf die Festplatte im Rechenzentrum des Cloud-Anbieters verschaffen.

Verarbeiten ohne Entschlüsselung
Forscher des renommierten Massachusetts Institute of Technology (MIT) arbeiten zurzeit an einem homomorphen Kryptosystem, das die Probleme von Cloud-Datenbanken beheben möchte. Damit sollen sich Daten auch in Datenbanken verschlüsselt ablegen und dennoch weiterverarbeiten lassen. In der Praxis schickt der Kunde dem Cloud-Provider die Rohdaten und Analyseanweisungen verschlüsselt zu. Nach dem Abarbeiten des Jobs sendet der Provider die nach wie vor verschlüsselten Resultate zurück. Bis diese Technik aber marktreif wird, werden noch einige Jahre ins Land ziehen. Den Forschern zufolge ist das Verfahren derzeit noch zu rechenintensiv, als dass es sich mit der heute gängigen Hardware sinnvoll abbilden ließe.

Standards innerhalb Europas

Auch schon vor der Skandaldiskussion über die NSA-Spähaktionen spielte der Standort des Cloud-Provider-Rechenzentrums eine entscheidende Rolle. Steht das Rechenzentrum in Europa, genügt dem Kunden ein Vertrag zur Auftragsdatenverarbeitung. Dieser ist heute Standard und wird von allen seriösen Anbietern akzeptiert. Er sichert den Kunden rechtlich gegen Datenlecks ab, die der Cloud-Anbieter zu verantworten hat. Bei Data Centern außerhalb von Europa müssen sich Kunde und Anbieter selbst auf Standardvertragsklauseln einigen, die im Fall einer Datenpanne greifen. Aus juristischer Sicht ist die Auftragsdatenverarbeitung zumeist vorzuziehen, da sie einfacher handhabbar ist.

Da besonders sensible Daten die EU laut deutschem Datenschutzrecht gar nicht verlassen dürfen, haben die großen Cloud-Anbieter wie Amazon reagiert: Für Kunden (und Reseller) ist es nun möglich, die Speicherorte zu wählen und dadurch Regionen außerhalb Europas zu vermeiden. Zwischen Recht und Technik klafft jedoch eine deutliche Lücke. Denn natürlich können Datentransfers zwischen einem Endgerät in Deutschland und dem Rechenzentrum in Irland dennoch quer über den Erdball laufen. Genau darum ist es so wichtig, dass man die Transportschicht absichert.

Update: Cloud Computing nach Safe Harbor – Der Europäische Gerichtshofs hat mit Urteil vom 6. Oktober 2015 die bisherige Safe-Harbor-Praxis gekippt: Persönliche Daten europäischer Internet-Nutzer seien in den USA nicht ausreichend vor dem Zugriff durch Behörden geschützt. Ein Sonderbeitrag erklärt, welche Folgen das für deutsche Unternehmen hat und was vorerst zu tun ist.

Transport Layer Security

Um die Transportschicht kümmert sich seit jeher SSL (Secure Sockets Layer) bzw. dessen Nachfolger TLS (Transport Layer Security). Im Prinzip ist die Transportsicherheit, also die geschützte Übertragung von Daten zwischen Endgerät und (Cloud-)Server über verschlüsselte Verbindungen damit kein Problem. Das Thema galt daher schon als erledigt, wenn der Cloud-Anbieter SSL/TLS anbot – was quasi alle ernst zu nehmenden Provider tun. Insbesondere TLS gilt als hinreichend sicher, die verwendeten kryptografischen Verfahren sind wohl auch in Zukunft schwer bis gar nicht zu knacken. Lauscher haben kaum eine Chance.

Serie: End-to-End-Security
Teil 1 formuliert die Aufgaben einer durchgängigen Verschlüsselung – auch im Cloud Computing. Teil 2 geht genauer auf die Transportsicherheit ein: Perfect Forward Secrecy.

In seiner Standardausprägung ist TLS aber anfällig für eine ganz und gar untechnische Attacke: den Gerichtsbeschluss. Wie im Zusammenhang mit der inzwischen sehr komplexen Diskussion über die Abhörprogramme der NSA gerüchteweise bekannt wurde, wollte sich der Geheimdienst auf rechtlichem Weg den Master Key von US-Online-Diensteanbietern besorgen, die ihre Kommunikation per TLS absichern. Mit diesem Master Key (dem Private Key des TLS-Zertifikats) lassen sich auf einen Schlag alle bereits aufgezeichneten, aber verschlüsselten Nutzersitzungen entschlüsseln. Denn die Sitzungsschlüssel der Übertragungen wurden lediglich mittels des Private Keys gesichert. Doch auch dagegen ist ein Kraut gewachsen.

Perfect Forward Secrecy

Mit der PFS-Technik (Perfect Forward Secrecy) gibt es ein Mittel, dem Geheimnisverrat nach der Methode „Heute mitschneiden, morgen entschlüsseln“ einen Riegel vorzuschieben – und zwar schon seit 1992. Damals wurde das Konzept erstmals beschrieben. „PFS macht es einem Angreifer deutlich schwerer, da der Sitzungsschlüssel auf beiden Seiten dynamisch erzeugt wird und nicht über die Leitung geht“, sagt Udo Schneider, Senior Manager PR Communications bei Trend Micro. Client und Server handeln also für jede Session den Key neu aus, sodass eine spätere Entschlüsselung mittels Master Key unmöglich wird. Einzig eine Brute-Force-Attacke auf jeden einzelnen Session Key könnte zum Knackerfolg führen.

MittelstandsWiki 15.jpg
Schwarz auf Weiß
Dieser Beitrag erschien zuerst in unserem Magazin zur CeBIT 2014. Einen Über­blick mit freien Down­load-Links zu sämt­lichen Einzel­heften bekommen Sie online im Presse­zentrum des MittelstandsWiki.

Obwohl heute quasi jeder Browser und alle gängigen Webserver PFS beherrschen, findet die Technik in der Praxis kaum Anwendung. Der mutmaßliche Grund: Perfect Forward Secrecy verlangt den Servern mehr Rechenarbeit ab, was sich insbesondere bei stark frequentierten Diensten auf die Performance der einzelnen Verbindung auswirken kann. Zwar hat Google bereits im Jahr 2011 den Zugriff auf seine relevanten Online-Dienste per PFS gesichert und auch E-Mail-Anbieter wie United Internet (1&1, Web.de usw.) setzen auf die Technik.

Fazit: Transportsicherheit einklagen

Ansonsten finden sich insbesondere im Umfeld von SaaS-Anbietern aber nur wenige eindeutige Anwendungsbeispiele. Microsofts live.com-Dienst bietet z.B. PFS, andere Login-Seiten im Azure-Umfeld liefern aber uneinheitliche Antworten. Auch login.salesforce.com oder die Anmeldeseite zu Amazons Webservices (AWS) können mit PFS nichts anfangen.

Das Risiko, trotz TLS von staatlichen oder privaten Stellen belauscht zu werden, ist durchaus real. Angesichts dessen sollten Cloud-Kunden das Gespräch mit ihrem Anbieter suchen und auf den Einsatz von PFS hinarbeiten. Wer noch auf Provider-Suche ist, sollte PFS auf der Liste der K.o.-Kriterien deutlich nach oben rücken.

Nützliche Links