Im vierten Teil unserer Serie über die Datenresidenz gehen wir auf die verschiedenen Verschlüsselungstechniken ein und beleuchten ihre Vor- und Nachteile.
Nachrichten und Informationen werden schon seit dem Altertum verschlüsselt. Die moderne Zeit setzt allerdings neue Anforderungen. Damit der Schutz maximal ist, muss er möglichst nah beim User beginnen: Verschlüsselung muss benutzerfreundlich sein, transparent funktionieren und eine hohe Betriebssicherheit gewährleisten.
Grundsätzlich können Daten in zwei unterschiedlichen Formen in der Cloud vorliegen:
- Als File (das kann auch eine eMail sein) in einer unstrukturierten Datenhaltung
Diese Daten können als gesamtes Set geschützt werden, indem das File als Ganzes verschlüsselt wird. - Als Feld in einem Record (etwa eine Zeile oder ein Tabelleneintrag) einer strukturierten Datenhaltung
Felder sind wesentlich komplexer zu schützten, weil die Applikation in der Cloud eine genaue Vorstellung hat, wie diese Daten aussehen sollen. Ein Datum muss in einer bestimmten Form vorliegen und eine eMail hat ebenfalls bestimmte Erkennungsmerkmale. Entspricht der Feldinhalt nicht diesen Vorstellungen, kann es zu einem Feld-Konsistenz-Fehler kommen: Die Applikation rapportiert einen Fehler und verweigert die Speicherung.
Mit zunehmender Digitalisierung werden Daten vermehrt als Felder statt als File abgelegt werden. Es sollten also zwingend beide Formen geschützt werden: Daten in Files, solange die Cloud primär als «Platform as a Service» (PaaS) verwendet wird wie bei SAP oder Microsoft Azure, und Daten in Feldern, wenn die Cloud vermehrt als «Software as a Service» (SaaS) wie etwa bei Microsoft 365 genutzt wird.
Wo kann verschlüsselt werden?
Verschlüsselung soll einfach und benutzerfreundlich sein – idealerweise haben die Endbenutzer gar nichts damit zu tun. So kommen folgende Orte für die Ver- und Entschlüsselung in Frage:
… auf dem Endpoint im Browser
Die Verschlüsselung würde wohl als Java-Script oder in einer ähnlichen Form implementiert. Da der Browser Schlüssel erhalten müsste, weil die Methode mit dem Java-Script geliefert würde und der Ort des Geschehens der Browser ist, ist die Lösung nur so sicher, wie der Browser den Schlüssel schützen und den Benutzer authentisieren kann. Das wäre faktisch möglich, wird aber wegen der grossen Fehleranfälligkeit üblicherweise nicht gemacht. Zudem kann es via Browsereinstellung einfach gekippt werden und das böswillige Mitschneiden wäre auch nicht besonders schwierig. Aus meiner Sicht ergibt der Schutz des Endpoints keinen Sinn.
… via eine aktive Komponente nahe am Betriebssystem
Eine Software auf dem Endpoint würde sich einerseits ins Filesystem (für Files) und andererseits ins Netzwerksystem (für Felder) integrieren. Die invasive Art und Weise, die dieser Ansatz verfolgt, lässt sich kaum stabil betreiben: Zu schnell, häufig und unterschiedlich sind die Systeme unter Windows, Mac, Android et al.
… direkt in einer Applikation
Die Applikation auf dem Endpoint kann mit der Verschlüsselung umgehen. Das macht etwa Microsoft mit ihrem Rights Management für Files so. Bei Feldern via eine Webapplikation funktioniert dieser Ansatz allerdings nicht. Er ist also primär mit Files möglich.
… in einer Inlinenetzwerkkomponente irgendwo zwischen Benutzer und Provider
Die Kommunikation zwischen Benutzer und dem Provider wird dazwischen abgefangen und dort wird ver- und entschlüsselt. Der Benutzer bemerkt davon in der Regel nichts, und der Vorgang ist schnell. Allerdings muss ein «dazwischen» möglich sein. Während das bei Feldern in der Regel gut funktioniert, ist es bei Dateien etwas komplizierter. Das hat damit zu tun, wie die Daten der Fileablagen in der Cloud zwischen Lokal und der Cloud synchronisiert werden. In der Regel wird die Datei nicht bei jeder Änderung als gesamtes verschoben, sondern nur die geänderten Teile werden kopiert. Die Verschlüsselungs-Appliance kann aber schlecht die ganze Datei konsistent verschlüsseln, wenn sie nur einzelne Teile davon bekommt. Bei Feldern funktioniert das in der Regel jedoch sehr gut.
… in einer aktiven Komponente, die mit dem Provider spricht
Die Daten kommen beim Provider unverschlüsselt an (abgesehen von der Transportverschlüsselung). Stellt der Provider diese Information nun via API zur Verfügung, kann eine aktive Komponente wie etwa ein Cloud Access Security Broker (CASB) die unverschlüsselten Daten via API beziehen und die verschlüsselten Daten wieder via API zurückgeben. Das Problem dabei ist, dass der Provider die unverschlüsselten Daten gesehen und in der Regel mindestens temporär gespeichert hat. Es kommt nun auf die Implementation an, ob die unverschlüsselten Daten schnell gelöscht werden oder nicht. Wiederum eine Vertrauensfrage, ohne Garantie, dass das nicht in Zukunft verändert werden kann.
… beim Provider vor der Applikation
Der Provider bietet eine Verschlüsselung direkt vor seinem User-Interface an. Das wird noch selten gemacht. Bei dieser Lösung kommt es darauf an, woher der Schlüssel kommt, wie gut die Verschlüsselung ist und ob sichergestellt ist, dass die Daten nicht im unverschlüsselten Zustand noch irgendwo überleben.
…beim Provider in der Applikation
Die Applikation wird gleich von Beginn weg so gebaut, dass die Daten nach dem Logik-Layer verschlüsselt werden, bevor sie abgelegt werden. Grössere Provider wie Salesforce oder ServiceNow können das, kleinere in der Regel nicht. Ein nachträglicher Einbau ist komplex, sehr teuer und die Datenmigration eine eher schwierige Aufgabe. Zudem kommt es auch bei dieser Lösung darauf an, woher der Schlüssel kommt und wie gut der Mechanismus ist. Die Kontrolle, ob das richtig gemacht wird, liegt ausschliesslich beim Provider. Eine unverschlüsselte Schattenkopie könnte problemlos hergestellt werden.
… beim Provider at Rest
Der Provider verschlüsselt die Daten bei der Ablage in der Datenbank oder als File auf seinem File-Container. Auch diese Lösung muss bezüglich Schlüsselherkunft, verwendetem Mechanismus und Ort des Geschehens (Standort der Datenbank/Fileservers) genauer analysiert werden. Die Kontrolle liegt ausschliesslich beim Provider.
Maximale Sicherheit gewährt die Option «Inlinenetzwerkkomponente irgendwo zwischen Benutzer und Provider», da der Provider den unverschlüsselten Inhalt nicht sieht. Diese Lösung hat aber auch ihre Limiten: Der Provider kann mit den verschlüsselten Daten nicht mehr «rechnen» und üblicherweise auch keine weitere, komplexere Funktionalität ausführen. Dieser Ansatz erlaubt somit eher eine Anonymisierung der Daten in der Cloud. In den meisten Fällen genügt dies.
Entscheidend ist, wo die Daten verschlüsselt werden, mit welchem Mechanismus, und wer den Schlüssel in der Hand behält.
Wer kontrolliert meine Verschlüsselung?
Bei einer Verschlüsselung sind drei wichtige Elemente beteiligt:
- Der Schlüssel sollte nicht in die Hände Dritter gelangen. Schlechte Schüssel erzeugen eine schwache Verschlüsselung, und fällt ein Schlüssel in die Hände Dritter, kann dieser die Daten entschlüsseln und allenfalls böswillig ändern oder neue Daten faken.
- Der Verschlüsselungs-Mechanismus sollte gut sein. Es gibt umfangreiche Literatur über die verschiedenen Mechanismen, deren Stärken, Schwächen und idealen Verwendungszwecke. Aber ein veränderter Mechanismus kann gegen Sie eingesetzt werden, indem zwar der Schlüssel gut ist, der Mechanismus aber schwach ist und keine gute Verschlüsselung produziert. Es ist deshalb wichtig, dass der angewendete Mechanismus gut und der dafür verwendete Code vertrauenswürdig ist.
- Wo die Verschlüsselung stattfindet, ist natürlich auch wichtig. Findet diese nicht lokal statt, so verhindert niemand den Ersatz von Schlüssel oder Mechanismus mit einer schwächenden Version.
Nur wenn alle drei Elemente kontrolliert werden können, ist die Verschlüsselung unter Kontrolle. Gerät ein Element in die Hände Dritter, kann Ihre Verschlüsselung von dieser dritten Stelle, deren Angestellten, Lieferanten, fremden Staaten oder Cyber-Kriminellen ausgenutzt werden. Es gibt hier also nur sehr wenig Spielraum.
BYOK steht für «bring your own key» oder auf Deutsch «bring deinen eigenen Schlüssel» bzw. «gib mir deinen Schlüssel». Der Schlüssel wird dabei üblicherweise dem Provider ausgehändigt, welcher dann einen von ihm kontrollierten Mechanismus an einem Ort seiner Wahl einsetzt. Oft wird dieser Mechanismus als «sichere Lösung» proklamiert. Faktisch erhöht er nur den Aufwand des Kunden (der muss das Schlüsselmanagement jetzt machen) ohne signifikante Erhöhung des Schutzes. Eine Mogelpackung aus der Marketingabteilung des Providers.
Besser ist eine BYOE «bring your own encryption». Dabei werden Schlüssel, Mechanismus und Ort vom Kunden kontrolliert und sind deshalb wesentlich vertrauenswürdiger. Diese Option hat auch das Potential, die Residency-Aspekte Ihres Schutzbedarf zu lösen. Das können die meisten anderen Ansätze nicht.
Wer kontrolliert meine Verschlüsselung?
- Optimaler Schutz bietet eine BYOE-Verschlüsselung, also eine lokale Verschlüsselung. Provider erhalten nur verschlüsselte Informationen. Für Multi-Cloud gibt es wenig Alternativen. Auch bezüglich der Residency-Problematik ist dieser Ansatz in der Lage, pro Land dedizierte Schlüssel zu verwenden. Diese Funktionalität wird üblicherweise von verschlüsselnden CASB-Lösungen wie centraya.com angeboten.
- Es ist auch möglich, dass die Verschlüsselung zwar lokal, aber auf der Software des Providers stattfindet – etwa die Double Key Encryption von Microsoft oder die ServiceNow Edge Encryption. Dieser Ansatz macht allerdings Abstriche bei der Kontrolle des Mechanismus.
- «Hold your own Key» (HYOK) ist ein Ansatz, bei dem die Sie als Kunden Ihren Schlüssel nicht aus der Hand geben. In der Regel benötigen Sie auch lokale Infrastruktur, was die HYOK-Verschlüsselung zu einer lokalen Verschlüsselung mit Providerbindung macht. Für einen einzelnen Provider/Anwendung ist das ein sicherer Ansatz. Kommen verschiedene Provider zum Einsatz, benötigt jeder in der Regel eine dedizierte HYOK-Lösung. Provider- oder anwendungsübergreifende Lösungen erzeugen eine signifikante Infrastruktur-Komplexität in Ihrem Datacenter.
- Von einer «Provider Managed Key»-Lösung sprechen wir dann, wenn der Provider pro Kunde einen dedizierten Schlüssel verwaltet. Der Schlüssel bleibt unter Kontrolle des Providers, dieser wählt auch Mechanismus und Ort. Der Kunde hat faktisch keine Kontrolle über die Verschlüsselung. Provider Managed Key ist die häufigste Lösung, welche Provider anbieten. Grundsätzlich geben sie damit nur Auskunft, dass die etwas verschlüsseln. Schlüssel, Mechanismus und Ort werden ausschliesslich durch den Provider kontrolliert.
Nur die ersten drei oben aufgeführten Verschlüsselungsansätze erhöhen Ihre Sicherheit signifikant. Eine “Provider Managed Key”-Lösung hat dafür ein kleines Störpotential für die Provider-Funktionalität. Es bleibt eine Abwägung von Sicherheit vs. Funktionalität. Wir empfehlen aufgrund von Multi-Cloud eine Lösung auf der Basis einer BYOE-Verschlüsselung, welche den Fokus auf «Person Identifying Information» (PII) legt. Damit ist der Schutz von persönlichen Daten hoch und das Störpotential für die Funktionalität klein.
Eines muss Ihnen bewusst sein: sobald Sie (sensitive) Daten nicht mehr nur lokal speichern – und das ist bei den meisten Unternehmen längst Realität – geben Sie die Kontrolle über ihre Daten ab. Gut klingende Begriffe für die Verschlüsselungsarten, die etwa von Providern angeboten werden, wie «Bring your own key» wecken zwar intuitiv Vertrauen in den Nutzern, aber sind deswegen noch kein Garant für Datensicherheit. Entscheidend ist, wo die Daten verschlüsselt werden, mit welchem Mechanismus, und wer den Schlüssel in der Hand behält.
Wenn die Cloud Ihre Strategie ist, sollten Sie den nächsten Blog dieser Serie nicht verpassen. Dort geht es um die Multi-Cloud und ihre speziellen Bedürfnisse. Cheers.
DE 
EN 