© alphaspirit, 123RF

In öffentlichen Cloudumgebungen ist es ein Muss für Unternehmen, Daten verschlüsselt abzulegen. Open-Stack-Clouds eignen sich dafür nicht sehr gut – doch es gibt Tricks, um das Problem zu umgehen.

Dank Apple ist Verschlüsselung heute selbst für Endbenutzer Standard. Auf dem Mac aktiviert File Vault die Verschlüsselung der Notebook-Festplatte per Mausklick. Microsoft zog 2007 nach und führte mit Bitlocker entsprechende Technik auch in Windows ein. So wurden Verschlüsselungsfunktionen für das Gros der Nutzer verfügbar. Per Luks und Dmcrypt lassen sich die Daten auf SSDs und Festplatten natürlich auch auf Linux-Systemen seit Jahren zuverlässig vor den Blicken Unbefugter schützen.

Viel wichtiger als im Endanwenderbereich ist das Thema Verschlüsselung von Daten auf Datenträgern allerdings im Unternehmensumfeld. Denn dort ist es de facto nicht möglich, Hardware in Rechenzentren dauerhaft dem Zugang Dritter zu entziehen. Zwar schließt jeder, der Server oder Colocation-Platz im Rechenzentrum mietet, einen Vertrag mit dem Anbieter ab, der unbefugten Zugriff ausschließen soll. Doch Papier ist geduldig und nach Edward Snowden ist auch klar, dass solche Zusagen im Zweifelsfall ohne jeden Wert sind. Was für Rechenzentren in der EU gilt, das gilt für Rechenzentren etwa in den USA umso mehr.

Es ist also alles andere als undenkbar, dass Dritte sich Kopien von Daten auf den Festplatten im Rechenzentrum ziehen oder diese gleich ganz mitnehmen. In solchen Situationen ist es für das Unternehmen je nach Inhalt der Datenträger vielleicht überlebenswichtig, dass diese nicht sofort und idealerweise gar nicht auszulesen sind.

Noch schlimmer: Die Cloud

Noch dramatischer stellt sich die Situation in Cloud-Computing-Umgebungen wie Amazons AWS dar – hier weiß ein Unternehmen schließlich gar nicht, wo die jeweilige Festplatte sich physisch befindet, auf der die eigenen Daten gerade liegen. Selbst wenn der Anwender das wüsste, hat er praktisch keinen physischen Zugriff darauf. Auch wenn der jeweilige Server in Deutschland steht, gehört er vielleicht einer Firma, deren Mutterkonzern in den USA oder in Großbritannien beheimatet ist und dort im Zweifelsfall mit den jeweiligen Behörden kooperieren muss.

Wer aus welchen Gründen auch immer Daten in öffentlichen Cloudinstallationen ablegen will, tut also gut daran, sich um die Verschlüsselung der Daten schon im Voraus Gedanken zu machen. Der folgende Artikel beschäftigt sich mit der konkreten Fragestellung am Beispiel einer auf Open Stack basierenden öffentlichen Cloudumgebung. Die gewonnenen Erkenntnisse gelten in vergleichbarer Weise aber auch für andere Public Clouds und sind auf diese entsprechend anwendbar.

Welche Daten sind zu verschlüsseln?

Am Anfang der Überlegungen steht die Frage, welche Daten denn überhaupt zu verschlüsseln sind? Verschiedene Artikel in diesem Linux-Magazin beschreiben, wie sich spezifische Dienste so konfigurieren lassen, dass sie die Daten, mit denen sie hantieren, selbst verschlüsseln – etwa Datenbanken oder Mailserver. Gerade das ist aber nicht der Fokus dieses Artikels. Denn die Ausgangsfrage ist, wie sich der komplette Inhalt von Datenträgern so verschlüsseln lässt, dass er ohne ein entsprechendes Kennwort und außerhalb des gebooteten Systems nicht zu lesen ist.

Darüber hinaus bieten die meisten Clouddienste einen weiteren Dienst an, bei dem Datenverschlüsselung eine Rolle spielt: Objektspeicher etwa auf Grundlage von Amazons S3-Protokoll. Open Stack selbst hat ebenfalls ein Protokoll für diese Art von Objektspeicher, nämlich Swift, das in echten Open-Stack-Umgebungen üblicherweise durch den gleichnamigen Dienst umgesetzt wird.

Verschlüsselung von Daten in Linux-Systemen funktioniert allerdings im Grundsatz anders als die Verschlüsselung von Objekten in S3. Es ist insofern sinnvoll, beide Prinzipien getrennt voneinander zu betrachten. Los geht es mit Daten innerhalb von virtuellen Maschinen.

VM-Verschlüsselung im Fokus

Grundsätzlich sind mehrere Ansätze möglich, gangbare Wege zeichnen sich durch unterschiedlich hohe Komplexität aus. Eher simpel ist der Ansatz, virtuellen Maschinen ebensolche Volumes unterzuschieben, die per se verschlüsselt sind. Das Root-Dateisystem bleibt dann unverschlüsselt und frei zugänglich; eventuelle Dienste sind innerhalb der VM idealerweise so konfiguriert, dass sie relevante Daten ausschließlich auf dem verschlüsselten Volume ablegen.

Schnorchelt im Anschluss jemand die Platte von außen ab, hat er zwar die unverschlüsselte Rootpartition, doch die enthält wenig mehr als eine Standardinstallation einer beliebigen Linux-Distribution. Soll die Rootpartition der VM ebenfalls verschlüsselt sein, wird das Unterfangen ungleich aufwändiger, etwa weil schon während des Bootvorgangs des Systems das Passwort zum Entschlüsseln einzugeben ist.

Wie leicht oder schwierig die Verschlüsselung von VMs in der Cloud wird, hängt auch von der Frage ab, ob die jeweilige Cloudumgebung entsprechende Funktionalität bietet oder nicht. Der Jackpot aus Nutzersicht wäre freilich ein Haken für aktivierte Verschlüsselung, der lediglich beim Start der VM zu setzen wäre. Zumindest auf den ersten Blick, denn eine solche Lösung birgt auch Risiken: Wer garantiert dafür, dass die VM am Ende wirklich verschlüsselt ist und keine Kopie des jeweiligen Schlüssels beim Anbieter liegt?

Bei Open Stack kein Thema

Die gute Nachricht im Falle von Open Stack ist, dass Admins sich über dieses Problem gar keine Gedanken zu machen brauchen. Denn Verschlüsselung in Open Stack ist ein ausgesprochen trauriges Thema – was VMs betrifft. Zwar verfügen die beiden relevanten Komponenten Nova und Cinder über Support für verschlüsselte VMs, in der Praxis ist diese Funktionalität aber nicht zu gebrauchen (Abbildung 1). Denn der digitale Schlüssel, der für die Verschlüsselung der VMs zum Einsatz kommt, ist im Klartext-Format in die Konfigurationsdateien jener Dienste zu schreiben. Das kann freilich nur der Anbieter.

Abbildung 1: Achtung! Falle: Das Dashboard bietet zwar an, Volumes verschlüsselt anzulegen – dabei handelt es sich aber um eine höchst unsichere Sache.

Das Resultat sorgt bei jedem sicherheitsbewussten Admin außerdem zu hochgerollten Fußnägeln: Wenn dieser Modus zum Einsatz kommt, verschlüsseln Nova und Cinder nämlich alle Volumes der gesamten Open-Stack-Installation mit eben jenem einen Schlüssel aus ihrer Konfigurationsdatei. Wer die Konfigurationsdatei hat, kennt folglich auch den Schlüssel und kann auf diese Weise leicht jede Verschlüsselung aushebeln.

Die meisten Anbieter verzichten aus eben diesem Grund darauf, überhaupt Verschlüsselung in Cinder zu aktivieren, und bieten die entsprechende Funktion nicht an. Und wer doch auf eine Public Cloud stößt, die verschlüsselte Volumes zulässt, sollte sehr wachsam sein. Denn entweder hat der Betreiber der Wolke dann selbst den Verschlüsselungsmechanismus repariert oder er setzt auf die beschriebenen und vollkommen nutzlosen Funktionen von Open Stack.

Licht am Ende des Tunnels: Barbican

Es ist übrigens durchaus so, dass den Open-Stack-Entwicklern das Ausmaß der Katastrophe klar ist. Bereits seit einigen Open-Stack-Releases entwickelt das Projekt an Barbican (Abbildung 2), das als zentraler Geheimnisspeicher dienen soll. Den Key für die Verschlüsselung von Volumes sollen Nutzer künftig selbst mit Barbican verwalten und weil Barbican Datenbankeinträge selbst verschlüsselt anlegt, kriegt der Betreiber der Plattform die Schlüssel theoretisch gar nicht mehr zu Gesicht.

Abbildung 2: Barbican soll in Open Stack künftig die Verwaltung von Zertifikaten, Passwörtern und digitalen Schlüsseln übernehmen – auch für Cinder.

Auf absehbare Zeit stellt sich die Frage nach Barbican aber nicht. Zwar ist es im Zuge der gerade stabilen Open-Stack-Release Kilo offiziell zur Open-Stack-Komponente geworden. Die Entwickler diskutierten zu Redaktionsschluss aber immer noch heftig, wie der neue Dienst sinnvoll an Cinder und Nova anzukoppeln sei. Auch in Open Stack Horizon, also dem Webinterface, war Barbican da noch nicht integriert. Selbst wenn die Funktionalität also vollständig Teil der nächsten stabilen Open-Stack-Version Mitaka im April 2016 werden sollte, wird noch einige Zeit vergehen, bis große Anbieter die neuen Funktionen tatsächlich ihren Kunden offerieren.

Rackspace etwa bastelt seit mindestens zweieinhalb Jahren an einer Barbican-Integration; das zugehörige Produkt heißt Cloud Keep und dürfte bald nach der Integration von Barbican mit Nova und Cinder wieder auf der Rackspace-Tagesordnung landen. Bis dahin gilt: Wer Open Stack mit verschlüsselten Volumes will, kommt nicht darum herum, sich eine Lösung der Marke Eigenbau zu basteln und geht so auf Nummer sicher.

Option 1: Verschlüsselte Volumes

Wie bereits erwähnt ist der Ansatz, lediglich einzelne Volumes innerhalb von Open Stack zu verschlüsseln, der deutlich leichtere Weg. Denn er lässt sich mit den Werkzeugen realisieren, die innerhalb fast jeder Open-Stack-Umgebung ohnehin vorhanden sind. Der Weg zum Ziel führt zunächst über eine einfache virtuelle Maschine, die auf Basis eines der vorhandenen Cloudabbilder zu starten ist. Die Distribution bleibt dabei zweitrangig; wichtig ist nur, dass sich innerhalb des gestarteten Systems später die Luks-Werkzeuge installieren lassen, denn die kümmern sich um die Verschlüsselung des Volume.

Sobald eine laufende VM auf Grundlage eines Image mit den Luks-Werkzeugen läuft, folgt im zweiten Schritt das Ankoppeln des Volume. Bei Open Stack wie bei vielen anderen Cloudumgebungen sind das zwei getrennte Schritte: Erst legt der Admin das entsprechende Volume an, danach verbindet er dieses direkt mit einer VM. In Open-Stack-Clouds lassen sich beide Schritte wahlweise auf der Kommandozeile oder per Open-Stack-Dashboard realisieren, in Horizon finden sich die nötigen Knöpfe unterhalb des Menüpunkts »Volumes« in der Projektansicht nach dem Login.

Nach dem Anlegen des Volume und dem Anhängen (Attach) an eine VM zeigt diese in der Ausgabe von »dmesg« ein neues Speichergerät an. Grundsätzlich nutzen Open-Stack-Umgebungen, die auf KVM setzen, dessen Hot-Plug-Funktionen, um dynamisch Volumes mit VMs zu verbinden oder eine solche Verbindung zu trennen (Abbildung 3).

Abbildung 3: Volumes erkennen VMs in Open Stack durch die Hotplugging-Funktion von KVM als ganz normale Storage-Geräte.

In der VM verhält sich das Cinder-Volume ab sofort wie ein normaler Speicher, der lokal an einen Linux-Computer angeschlossen ist. Das Volume innerhalb der VM lässt sich im weiteren Verlauf also nach Belieben partitionieren oder mit einem gängigen Dateisystem versehen oder verschlüsseln – die Luks-Werkzeuge leisten wertvolle Dienste.

Volumes per Luks verschlüsseln

Luks (Abbildung 4) lässt sich auf jede vorhandene Partition anwenden; allerdings gehen die Daten, die vorher auf dem Volume vorhanden waren, dabei den Bach runter. Wer Luks also auf ein schon länger existierendes Volume anwenden will, macht vorher gegebenenfalls ein Backup und spielt es anschließend zurück.

Abbildung 4: Luks funktioniert für Volumes innerhalb der VM genauso wie auf ganz normalen Servern.

Unter der Prämisse, dass das an die VM gehängte Volume per »/dev/vdb« zu erreichen ist, sorgt der Befehl

sudo cryptsetup LuksFormat -c aes-xts-plain64 -s 512 -h sha512 -y

für das Anlegen der Verschlüsselung. Um das Volume anschließend zu nutzen, ist es mit »cryptsetup« zu aktivieren: »sudo cryptsetup LuksOpen /dev/vdb volume-crypt« . Dann folgt das Anlegen des Dateisystems.

Alle in Zukunft auf dem Volume gespeicherten Daten sind verschlüsselt. Weil Volumes in Open Stack grundsätzlich unabhängig von VMs sind, überleben sie auch das Löschen oder den Neustart der VM, der sie gerade zugewiesen sind. Das angelegte Volume ließe sich zu einem beliebigen Zeitpunkt also auch an einer anderen VM betreiben; allerdings ist es dafür wieder nötig, mit dem »LuksOpen« -Befehl von »cryptsetup« das Gerät freizugeben.

Es ist daher sinnvoll, ein eigenes Image zu bauen, das die Luks-Werkzeuge und »dmcrypt« bereits enthält. Alternativ lassen sich jene Pakete natürlich auch mit einer automatischen Konfigurationsverwaltung (Puppet, Chef, Ansible …) oder über ein Shellskript installieren, das eine neue VM beim Start per Metadaten mit auf den Weg bekommt.

Ganz wichtig ist, dass das verschlüsselte Volume tatsächlich so in das System eingebunden ist, dass die zu verschlüsselnden Daten auch darauf landen. Wer etwa die Inhalte seiner MySQL-Datenbank auf dem verschlüsselten Volume abgelegt haben möchte, sorgt dafür, dass das Datenbankverzeichnis von MySQL unterhalb des Mountpoints liegt, an dem das verschlüsselte Volume in das Dateisystem eingehängt ist. Gerade dieser Punkt verursacht oft Probleme, weil auch er automatisiert abzuwickeln ist, wenn die ursprünglich angelegte VM gelöscht wird und das Volume an einer anderen virtuellen Maschine hängt.

Auch hier ist klar im Vorteil, wer automatisches Konfigurationsmanagement nutzt, um seine VMs einzurichten. Wer das nicht tut, muss entweder händisch zu Werke gehen und MySQL entsprechend starten oder tatsächlich ein modifiziertes Image bauen, das von Haus aus entsprechend konfiguriert ist. An dieser Stelle erweist sich die Snapshot-Funktion von Open Stack als sehr nützlich: Denkbar wäre etwa, aus einem frischen Image eine VM zu starten, diese umzukonfigurieren und danach über Open Stack einen Snapshot von dieser virtuellen Maschine anzulegen. Aus diesem Snapshot lässt sich dann per Mausklick ein neues Image erstellen, das unmittelbar danach in Glance zur Verfügung steht.

Option 2: Komplett verschlüsselte VMs

Sehr viel Aufwändiger ist das Projekt, VMs in Clouds wie Open Stack ganz zu verschlüsseln. Zwar kommt eigentlich die gleiche Technik zum Einsatz und die verwendete Software ist ebenfalls identisch. Aber verschlüsselte Rootplatten laufen mehreren Design-Ansätzen von Cloud-VMs entgegen.

Das größte Problem ist, dass ein verschlüsseltes Root-Dateisystem zwangsläufig eine separate Partition für »/boot« bedingt, weil Grub von verschlüsselten Partitionen zwar grundsätzlich lesen kann, dies den Overhead für die Lösung aber in unnötige Höhen katapultieren würde. Eine eigene Bootpartition ist jedoch in fast keinem der fertigen Cloudimages von Red Hat, Suse oder Ubuntu vorgesehen. Das Vorhaben beginnt praktisch also bei Adam und Eva.

Die ersten Schritte sind allerdings identisch zu dem beschriebenen Prozess für verschlüsselte Volumes. Zunächst startet der Admin also eine VM und hängt an diese ein separates Volume an. Anders als zuvor sollte der Admin beim Anlegen des Volume aber darauf achten, dass er es aus einem bestehenden Image heraus anlegen lässt; Open Stack bietet diese Möglichkeit (Abbildung 5). Auf dem Volume liegt dann ein entpacktes Cloudimage und auch der Master Boot Record ist bereits mit Grub versehen.

Abbildung 5: Beim Anlegen eines Volume ist es möglich, als Basis ein Image zu nutzen. Das neue Volume hat dann automatisch den Inhalt des Image.

Dann geht die Arbeit los: In Schritt 1 steht das Anlegen einer neuen Partitionstabelle für das Volume an. Zuvor ist freilich der Inhalt des Dateisystems an einem anderen Ort zu sichern – denn der soll ja später wieder auf der dann verschlüsselten Partition des Volume landen. »rsync« hat sich als nützliches Werkzeug für diese Aufgabe erwiesen.

Wenn zwei Partitionen angelegt sind, ist Partition 1 des Volume mit einem Dateisystem zu versehen, hierzu eignet sich Ext 4. Die zweite, größere Partition erhält ihre Verschlüsselung per »cryptsetup« wie oben beschrieben. Wie zuvor sollte auf der verschlüsselten Partition auch ein Dateisystem vorhanden sein, die Empfehlung ist erneut Ext 4. Im konkreten Beispiel von Ubuntu empfiehlt es sich zudem, dieses Dateisystem mit dem Label »cloudimg-rootfs« zu versehen, weil dies Anpassungsarbeiten im weiteren Verlauf unnötig macht. Danach ist die verschlüsselte Partition zu aktivieren und per »mount« in das Dateisystem der laufenden Instanz einzuhängen.

Der Befehl »mkdir boot« legt einen Ordner für die »/boot« -Partition an, damit sich im Anschluss die erste Partition des Volume dort einhängen lässt. Nun folgt das Zurückspielen der zuvor gesicherten Inhalte des Dateisystems. Am Ende des Vorgangs existiert ein Open-Stack-Volume mit zwei Partitionen. Die zweite Partition ist per Luks verschlüsselt.

Beide Partitionen sind aktiv und in das Dateisystem der laufenden Instanz eingehängt. Die Blanko-Inhalte des Cloudabbilds, aus dem das Volume ursprünglich erstellt worden ist, sind auf dem verschlüsselten Volume wieder vorhanden. Ab hier sollte es möglich sein, sich mit Hilfe von »chroot« direkt in das virtuelle System auf der verschlüsselten Partition einzuloggen.

Viel Nacharbeit

Die eigentlichen Mühen liegen aber noch vor dem Admin: Nun stehen nämlich all jene Nacharbeiten an, die aus dem angehängten Cinder-Volume ein tatsächlich bootbares Image machen. Anzupassen ist jedenfalls »/etc/fstab« , das ab Werk keinen Eintrag für eine separate »/boot« -Partition hat. Der Gerätename ist dabei im Normalfall »/dev/vda1« .

Auch die Grub-Konfiguration ist so zu ändern, dass der Bootmanager von der separaten »/boot« -Partition weiß und diese nutzt. Zudem ist sicherzustellen, dass die Initram-FS-Datei für Luks vorbereitet ist und den Passwortprompt anzeigt, wenn sie beim Booten merkt, dass die »/« -Partition verschlüsselt ist. Eine vollständige Anleitung mit den nötigen Schritten enthält das Wiki von Ubuntu Users in deutscher Sprache unter [1].

Sind alle Vorarbeiten erledigt, legt der Admin wieder über den zuvor beschriebenen Snapshot-Umweg ein neues Open- Stack-Image an. Wie gewohnt lassen sich danach aus dem Image heraus VMs starten. Dabei sind aber zwei Dinge zu beachten: Einerseits ist der Encryption-Key bei allen VMs, die aus demselben Image entstehen, derselbe. Andererseits ist beim Booten einer VM natürlich das Passwort für die Freigabe des verschlüsselten Datenträgers einzugeben. De facto geht genau das aber nur über die VNC-Konsole des Open-Stack-Dashboards, auf das man für diesen Zweck Zugriff benötigt.

Bei Paranoia ungeeignet

Der Seriosität wegen sei erwähnt, dass das vorgestellte Prozedere noch einen offensichtlichen Angriffspunkt hat: Theoretisch denkbar ist, dass der bei »cryptsetup« angegebene Schlüssel aus der VM heraus seitens des Anbieters während der Eingabe abgefangen wird. Denn der hat trotz allem Zugriff auf die Hardware und findet möglicherweise Mittel und Wege, um die Eingabe zu sehen, nachdem sie die sichere SSH-Verbindung schon verlassen hat. So ließen sich später verschlüsselte Volumes auch außerhalb der VM ohne Probleme knacken.

Auch wenn dieses Angriffsszenario sehr theoretisch wirkt, ist es doch zumindest nicht vollkommen undenkbar. Vermeiden lässt sich das Problem gerade im Fall der vollständig verschlüsselten Partition nur dadurch, dass der Admin die Vorarbeiten lokal in KVM oder VMware erledigt und dann ein fertiges Qcow2-Abbild in Open Stack hochlädt. Wer seinem Anbieter diese Art von Angriff zutraut, der tut wohl obendrein gut daran, sich einen anderen zu suchen.

S3 und Open Stack Swift

Wie eingangs erwähnt bieten Clouds üblicherweise nicht nur VMs an, sondern stellen ihren Nutzern auch skalierbaren Speicher “on demand” zur Verfügung. Bei Amazon heißt das Feature S3 und bei Open Stack Swift. Die Idee ist simpel: Per standardisiertem Protokoll verbindet sich ein Client über ein Rest-Interface mit den Servern des Anbieters und lädt einzelne Dateien in den Speicher. Auch hier besteht offensichtlich die Notwendigkeit, sensible Daten zu verschlüsseln, wenn sich ihr Upload in das öffentliche System nicht verhindern lässt. Denn wie bei VMs lägen die Daten ansonsten unverschlüsselt irgendwo auf den Platten des Anbieters.

Bei einem typischen Einsatzzweck für diese Art von Speicher wäre eben das ein großes Problem: Viele Backup-Programme bieten mittlerweile die Option, nicht nur lokale Backups auf externen Datenträgern anzulegen, sondern diese in einem zweiten Schritt auch in ein öffentliches Cloudverzeichnis zu laden. Das wirkt gerade für Privatanwender verlockend, weil so ein echtes Off-Site-Backup entsteht, das selbst dann noch verfügbar ist, wenn das eigene Haus samt Platte mit den Backups und den Computern abgebrannt ist. Wer die hochgeladenen Daten nicht verschlüsselt, legt aber eben auch den kompletten Inhalt des privaten Computers offen.

Die schlechte Nachricht ist, dass weder im S3-Standard noch in Swift das Thema Verschlüsselung überhaupt vorkommt. Der amerikanische Open-Stack-Anbieter Rackspace hat 2013 zwar an einer Verschlüsselungstechnik für Swift gearbeitet, diese aber bis heute nicht in die Komponente integrieren können. In der offiziellen Swift-Dokumentation findet sich jedenfalls kein Wort zum Thema. Damit ist klar, dass die Verschlüsselung der Daten bereits vor dem Upload erfolgen muss. Wer wie beschrieben etwa Backups in Swift ablegt, achtet darauf, dass die Software für diese Aufgabe die Verschlüsselung selbst durchführt.

Fazit: Wenig Licht und viel Schatten

Es gestaltet sich alles andere als leicht, virtuelle Maschinen innerhalb von Open-Stack-Umgebungen sinnvoll zu verschlüsseln. Das gilt sowohl für die Verschlüsselung einzelner Volumes als auch für die ganzer VMs. Eingedenk der Tatsache, dass die Risiken von unverschlüsselten Datenträgern in öffentlichen Cloudinstallationen offensichtlich sind, verwundert dieser Umstand umso mehr. Es bleibt abzuwarten, inwiefern Barbican das Problem lindern oder lösen wird; bis dato ist davon auf Nutzer-Seite leider noch nichts zu sehen.

Amazon bietet für seine EBS-Volumes, die ähnlich wie Cinder funktionieren, bereits seit 2014 funktionierende Verschlüsselung. Wer Volumes nur an seine VMs anhängt und diese nicht als Root-Festplatte nutzen will, erspart sich damit Arbeit, muss aber letztlich auch darauf vertrauen, dass die Amazon-Implementation hält, was sie verspricht. Ähnlich sieht es bei S3-Speichern aus: Hier muss das Programm, das Daten im Onlinespeicher ablegt, sich selbst um die Verschlüsselung kümmern. Denn weder S3 noch seine Klone oder Open Stack Swift bieten solche Funktionen.