Eine sichere Cloud dank eigener Schlüssel

Spätestens seit Covid-19 die Welt in Atem hält ist klar, dass „Online“ das neue „Normal“ ist: Es wird zum Maß aller Dinge. Für gestandene IT-Firmen mag dies weniger herausfordernd sein. Was aber, wenn die eigentliche Dienstleistung typischerweise in Papierform erfolgt? Was, wenn „Präsenz“ bislang die einzige Form persönlicher Begegnungen war?

Technisch gesehen gilt es, drei große Aufgaben zu bewältigen. Da ist zum einen die Digitalisierung der Papier-basierten Prozesse. Das impliziert sofort Aufgabe Nummer zwei: Die neuen Online-Prozesse brauchen eine Plattform, auf der sie laufen und zwar über die üblichen Bürozeiten hinaus rund um die Uhr. Doch damit nicht genug. Institutionen, wie das Bundesamt für Sicherheit in der Informationstechnik (BSI) und die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) haben bereits für den Cloud-Einsatz entsprechende Regularien festgelegt. Einige, darin enthaltene Punkte sind hochverfügbare Sicherheitsgateways, automatische Ausfallsicherungen und Redundanzen kritischer Systemkomponenten, wobei der Fokus auf dem sicheren Regelbetrieb von Cloud-Diensten liegt.

Sicherheit dank Verschlüsselung

Eine Investition in das Rechenzentrum scheint hier unumgänglich. Oder warum nicht gleich die vielfältigen Dienste der Cloud-Giganten nutzen? Server, Datenträger und Netzwerk sind dort vorhanden. Aber sind sie auch sicher? Wichtige, sensible Daten verlassen die eigene Organisation und wandern in Rechenzentren, die andere Institutionen oder Unternehmen betreiben. Geht das überhaupt? Ja. Das Zauberwort heißt Verschlüsselung, von Fachleuten auch allgemeiner als kryptographische Verfahren bezeichnet. Es ist egal, ob die Daten gerade in die Cloud wandern, dort lagern oder auf dem Rückweg sind. Verschlüsselung stellt sicher, dass nur autorisierte Personen die Informationen einsehen oder gar verändern. Neben der Geheimhaltung gibt es auch einen gehörigen Anteil von Datenintegrität.

Das Verschlüsseln von Informationen ist recht einfach. Die eigentliche Herausforderung liegt woanders. Die Rede ist von der Verwaltung der zugehörigen kryptographischen Schlüssel. Wo sind sie aufbewahrt? Wer hat Zugriff? Wie tauscht man alte gegen neue? Ist es ein Unterschied, ob es symmetrische oder asymmetrische Verschlüsselung ist? Diese Fragen sind nur die Spitze des Eisbergs. Die Empfehlungen des BSI in diesem Zusammenhang füllen eine ganze Seite. Das klingt schwierig, ist es aber gar nicht. Die Cloud-Dienstleister haben die Herausforderung ebenfalls erkannt und entsprechende Produkte entwickelt. Das klingt erstmal gut, ist in der Realität aber oft genug nicht ausreichend – dazu gleich mehr.

Herausforderungen bei kryptographischen Schlüsseln

Experten sprechen hier von „Key Management Systemen“. Neben den eben genannten kryptographischen Schlüsseln kümmern sie sich auch um andere Zugangscodes wie beispielsweise Passwörter. Per Internet-Recherche lassen sich diese Produkte mit Stichworten wie „Key“, „Vault“ oder „Management“ sehr schnell finden, viele davon mit Zertifizierungen wie FIPS 140-2 ausgestattet. Ist damit jedoch das eingangs beschriebene Problem gelöst? Die Cloud-Dienstleister stellen eine Plattform bereit, die planbar, immer verfügbar und sogar global ist. Sensible Daten sind durch Verschlüsselung geschützt. Die Verwaltung der „Zugangscodes“ ist dank der Cloud-Dienstleister ebenfalls keine Herkules-Aufgabe.

Doch wie sieht es mit den Schlüsseln selbst aus? Zur Veranschaulichung des Sachverhalts hilft eine Analogie. Der Cloud-Dienstleister ist der Betreiber eines Hotels. Zum Angebot gehören Zimmer, Schlösser und natürlich auch zugehörige Schlüssel. Ein Gast bewahrt seine privaten und schützenswerten Dinge im Zimmer auf – geschützt durch Schloss und Schlüssel. Hat sonst wirklich niemand weiter Zugriff? Es fällt schwer zu glauben, dass dem so ist. Insbesondere im Zeitalter von „digitalen Schlüsseln“ muss die Anfertigung eines „Nachschlüssels“ einfach sein. Immerhin besitzt das Hotel alle Informationen über Gast, Zimmer und Infrastruktur. Ein ähnliches Gesamtpaket gibt es auch bei den großen Dienstleistern in der Cloud.

Dazu gleich mehr und nun erstmal raus aus der Analogie und zurück zur IT. Wie sieht es dort aus? Und wie verhält es sich diesbezüglich in der IT? Bekannte Beispiele sind SSH-Schlüssel (Secure Shell) oder Passwörter für x509-Zertifikate. Beide sind inzwischen essentiell für sichere Kommunikation im Netz. Mit SSH erfolgt der Zugriff auf Betriebssystem-Ebene und nicht nur für Administratoren. Die x509-Zertifikate dienen dem de-facto-Standard von abgesicherter Kommunikation für Browser oder auch Smartphone-Apps. Es geht also um die Verwaltung dieser SSH-Schlüssel oder den Entsprechungen in der x509-Welt. Der Nutzer verwendet die Angebote der Cloud-Dienstleister zum Erzeugen von kryptographischen Schlüsseln, Passwörtern und Ähnlichem. Das ist einfach, ist es aber auch sicher?

Eigenbeitrag eigener Schlüssel

Dieses Dilemma lässt sich lösen. Experten raten zu einer klaren Trennung zwischen den kryptographischen Schlüsseln und dem System zu deren Verwaltung. Für Letztere darf der Anwender gerne auf die umfassenden Angebote der Cloud-Dienstleister zurückgreifen. Schließlich sind sie die Lösung für einige der oben genannten Herausforderungen. Allerdings sind diese spezifisch für den jeweiligen Anbieter. Wer mehr als einen Cloud-Dienstleister verwendet, sieht sich mit einem deutlichen Mehraufwand konfrontiert. Das nächste Kapitel geht genauer darauf ein.

Nur der kryptographische Schlüssel selbst muss von außerhalb der Cloud kommen. Das betrifft insbesondere deren Generierung sowie eventuell verwendete sensible Zusatzinformationen.

Im Fall von SSH betrifft das den privaten und den öffentlichen Schlüssel. Diese lassen sich sehr einfach auf den gängigen Betriebssystemen erzeugen. Analoges gilt für x509-Zertifikate. Im Normalfall gibt es hier ebenfalls eine Art privaten Schlüssel und dieser ist durch ein Passwort geschützt. Für den Normalbetrieb in der Cloud ist nur der öffentliche Teil nötig. Diesen muss der Anwender dem Cloud-Dienstleister mitteilen. Anders gesagt: der „private“ Teil bleibt beim Nutzer. Den „öffentlichen“ Teil publiziert er in der Cloud. Im Englischen hat sich das Akronym BYOK (Bring Your Own Key) etabliert. Das macht deutlich, dass der Anwender seine eigenen kryptographischen Schlüssel in die Cloud mitbringt.

Multi-Cloud ohne Mehraufwand

Damit scheinen alle Herausforderungen gemeistert: Dank Verschlüsselung sind die Daten sicher und geschützt. Das gilt sowohl für den Transport als auch für die Ablage. Die Cloud-Dienstleister stellen die notwendigen kryptographischen Methoden und sogar Systeme zur Verwaltung der zugehörigen Schlüssel bereit. Dank BYOK bleibt die Kontrolle beim Anwender. Im Alltag zeigt sich dann doch noch eine weitere Aufgabe. Das Stichwort lautet Multi-Cloud. Wer das Beste aus allen Cloud-Angeboten nutzen will, muss sich auch mit den jeweiligen Unterschieden auseinandersetzen. Im ungünstigen Fall würde dies jeweils Cloud-spezifische Prozesse für kryptographische Schlüssel bedeuten. Einfach gesagt: wer Google, Azure und AWS benutzt, hat drei separate Vorgänge für sein BYOK. Das ist nicht erstrebenswert.

Zur Verdeutlichung sei noch einmal das Beispiel der SSH-Schlüssel bemüht. Natürlich benötigt der Anwender pro Cloud ein anderes Schlüsselpaar. Technisch ist die Generierung einfach. Aber es sind Prozesse nötig, welche die jeweiligen Schlüssel auch der Cloud beziehungsweise der Anwendung zuordnen. Mit jeder zusätzlichen Cloud und sogar mit jedem neuen Schlüsselpaar erhöht sich die Komplexität. Das Befolgen von üblichen Sicherheitsprinzipien lässt den Aufwand exponentiell wachsen. Wie soll das skalieren?

Die Lösung ist eine Art Abstraktionsschicht. Unabhängig von der tatsächlich verwendeten Cloud nutzt der Anwender immer dieselben Prozesse und Vorgänge. Im Hintergrund übersetzt die Abstraktionsschicht diese in eine Dienstleister-spezifische „Sprache“. Dies vereinfacht nicht nur das BYOK-Konzept in der Multi-Cloud. Analog gilt das auch, wenn ein Wechsel des Dienstleisters ansteht. Die Prozesse bleiben unverändert, auch wenn im Hintergrund eine andere Cloud genutzt wird.

Wie könnte so eine Abstraktionsschicht funktionieren? Sie muss den gesamten Zyklus von der Erstellung über die Benutzung bis zur Löschung eines Schlüssels oder Passworts steuern. Nochmal zur Erinnerung: Dies erfolgt außerhalb der Umgebung des Cloud-Dienstleisters. BYOK ist das Stichwort. Implizit kommt die Anforderung an einen protokollierten und sicheren Zugriff auf diesen Schlüssel beziehungsweise auf dieses Passwort. Idealerweise kann der Anwender beliebige Speichertechnologien wählen und sekundengenau sehen, wann welcher Zugriff erfolgte. Natürlich muss diese Abstraktionsschicht die jeweiligen Spezifika der Cloud-Dienstleister verstehen. Welche Informationen, Rollen, Konfigurationen sind für einen erfolgreichen Zugriff nötig? Wie muss der Schlüssel oder das Passwort beschaffen sein? Welche Schnittstellen und Mechanismen stehen bereit? Und das ist erst der Anfang. Die nächste Ausbaustufe inkludiert automatisch generierte Rollen und „Wegwerf-Passwörter“. Klingt nicht so einfach – aber es gibt bereits fertige Lösungen dafür. Damit sind BYOK und Multi-Cloud sehr gut miteinander vereinbar.

Fazit

Sicherheit bei der Nutzung von Cloud-Diensten ist kein Mythos, sondern Realität. Die Verschlüsselung sensibler Daten ist ein wichtiger Baustein. Entsprechende Produkte und Methoden stellen die großen Cloud-Dienstleister bereit. Die Verwendung eigener kryptographischer Schlüssel entsprechend der DSGVO lässt dabei die Kontrolle beim Anwender. Für die gleichzeitige Nutzung mehrerer Cloud-Dienstleister oder den Wechsel zwischen unterschiedlichen Clouds gibt es bereits Lösungen, die den einfachen Weg in die Cloud ebnen.

Autor: Lance Haig, Regional Manager of Solutions Engineering bei Hashicorp