© Elnur Amikishiyev, 123RF

Als US-Firma und Cloud-Marktführer muss sich Amazon Web Services besonders viele Gedanken zum Thema Datenhoheit machen – nirgendwo sonst liegen so viele geschäftskritische Daten herum wie dort. Hier eine AWS-praxisgerechte Bestandsaufnahme zu Verschlüsselungsmöglichkeiten und Key-Features.

T-Shirts mit dem Aufdruck “There is no Cloud, it’s just someone else’s Computer” erfreuen sich bei den Skeptikern von Cloudtechnologien großer Beliebtheit. Das Unbehagen resultiert aus den rein auf Effizienz und Kosten ausgelegten Anweisungen aus dem Management vieler Firmen, möglichst schnell möglichst viele IT-Dienste auszulagern. Datensicherheit wird dann zum Nebenfeature, das die im Gegenzug schrumpfende IT-Abteilung irgendwie gewährleisten soll.

Die Wahrheit liegt dazwischen. Admins, die ihre Anwendungen einfach in der Cloud laufen lassen, geraten in das auch finanziell bedeutsame Risiko, die DSGVO zu verletzen, etwa wenn sie personenbezogene Daten auf Servern außerhalb der EU ungeschützt ablegen. Andererseits zeigt die Onlinebank N26, die vollständig in AWS läuft und (diesbezüglich) eine Bafin-Prüfung überstanden hat, dass es machbar ist, Clouddienste unter Einhaltung strenger Regeln zu betreiben.

Neben der Wahl der Ablaufumgebung, die der Admin bei Amazon wie den meisten Cloudanbietern unter dem Begriff Region konfiguriert, bieten sich mehrere Möglichkeiten, die Daten auf dem Weg in die Cloud und bei der Ablage dort zu verschlüsseln. Auf dem letzten AWS Summit in Berlin trug der CTO von AWS, Werner Vogels, nicht von ungefähr ein T-Shirt mit dem Aufdruck “Encrypt Everything”. Nur: Wer alles hat Zugriff auf die Schlüssel und wo liegen sie?!

Wer darf was?

Eine weitere Dimension für die Datensicherheit in der Cloud liefert die Frage: Wer darf lesen oder schreiben? Sie stellt sich beim Bereitstellen jeder Art von IT-Service und fängt mit der Benutzerverwaltung an. Ab hier ein komplexes Rechtekonstrukt zu flechten, welcher User auf welche Daten, Server und sonstige Ressourcen zugreifen darf, gerät zur Sisyphos-Arbeit, da im IT-Betrieb ständig Änderungen eintreten.

In einer Cloud wie Amazon ist die Menge möglicher Berechtigungen, die der Admin zum Zusammenstellen von Rollen und Diensten angeboten bekommt, im Vergleich zu einer eigenen IT ungleich größer. Hier jene zu finden, die notwendig sind, damit ein bestimmter Clouddienst funktioniert, ohne zu viel zu erlauben, ist nirgendwo trivial. Die Komplexität der Aufgabe kann Admins so entnerven, dass sie “Alles erlauben” anklicken und damit vertrauliche Kundendaten in einem offen zugänglichen S3-Bucket (Amazons Objectstore) freigeben. Das ist zwar nicht entschuldbar, aber aus eigener Erfahrung zumindest nachzuempfinden.

Des Weiteren steht der Begleitschutz der Daten auf dem Weg in die Cloud und wieder raus sowie beim Binnentransfer zwischen den Diensten auf der Agenda. Viele Admins werden sagen: Kein Problem, wir schalten TLS an. Aber in der Praxis hängt das Vorhaben oft an der Frage, wo die Zertifikate herkommen.

Über die Vielzahl von AWS-Diensten, auf die die Zugriffskontrolle einwirkt, könnte der Autor mehrere Bücher schreiben. Daher beschränkt sich diese Artikel auf zwei der Basisdienste, den Object Storage S3 und den VM-Dienst EC2. Als Zuschlag gibt es das Schlüsselmanagement von AWS sowie ein paar Teile des Identity und Access Management (IAM), das die Benutzer und deren Rechte verteilt.

Dreifaltigkeit

Das Thema Daten wird gern unter dem Dogma “Confidentiality, Integrity, Availability” betrachtet – ob das entstehende Kürzel CIA freiwillig oder unfreiwillig ironisch rüberkommt, ist nicht überliefert. Confidentiality (Vertraulichkeit) bedeutet, dass nur berechtigte Nutzer den Inhalt der Daten sehen. Bei einer öffentlichen Webseite wird die Gruppe der Berechtigten häufig “Alle” sein.

Integrität bedeutet, dass nur berechtigte Benutzer die Daten modifizieren dürfen. Gegebenenfalls darf ein Teil der Berechtigten einige Daten auch nur innerhalb festgelegter Wertebereiche ändern. Ein Bankmitarbeiter etwa kann nur die Überweisungen der Kunden auf den Konten ausführen und nicht freihändig Geld umschichten. Availability beschreibt die Verfügbarkeit. Liegen alle wichtigen Firmendaten auf einer einzelnen Festplatte ohne Sicherung und diese segnet das Zeitliche, sind die Daten nicht mehr verfügbar.

Schutz vor wem?

Bei der Frage des Schutzes vor unberechtigtem lesenden (C) und schreibenden (I) Zugriff auf die Daten muss sich der Admin im Cloudkontext auch noch die Frage “Schutz vor wem?” stellen. Hier gibt es den öffentlichen Zugriff über das Internet sowie den geschlossenen Kreis aus Anwendern mit unterschiedlichen Berechtigungsstufen – die Auftragsabwicklung hat nichts in der Gehaltstabelle der Personalabteilung zu suchen.

Da das Ganze auf der Infrastruktur von anderen läuft, ist zudem der Schutz vor den Mitarbeitern des Cloudanbieters von Relevanz. Verwandt damit ist die Zugriffssteuerung für die firmeneigenen Administratoren, welche die Systeme verwalten. Sie kommt gerade bei personenbezogenen Daten zum Tragen, beispielsweise für Gehaltstabellen.

Das A von CIA können AWS-Kunden zumeist als gegeben annehmen. Im S3-Dienst beispielsweise müsste der Benutzer die Hochverfügbarkeit aktiv abstellen, um bei einem Crash in den Genuss eines Datenverlusts zu kommen. Zudem unterstützt der Object Store Versionierung, sodass der Kunde in Fehlerfällen auf ältere Versionen zurückgreifen kann.

Benutzer, Rollen und Rechte

In der AWS-Cloud sind in der einfachsten Hierarchiestufe Accounts definiert, und in diesen gibt es Benutzer, die innerhalb des Accounts Rechte zugewiesen bekommen, etwa das Anlegen und Starten von VMs oder Datenbanken. Der Konfigurationsbereich »IAM« dient zur Verwaltung von Benutzern oder Admins.

Es ist möglich und von AWS auch empfohlen, Accounts mit Unterkonten einzurichten. Über eine solche Organisation kann der AWS-Kunde dann organisationsweite Policies stülpen, sodass selbst ein Admin mit vollen Rechten in einem Unteraccount nicht gegen die Organisationsregeln verstoßen kann.

Beim Anlegen eines Accounts erzeugt AWS die Credentials des Superusers dieses Accounts ebenfalls. Klickt der Admin danach auf die Liste der Benutzer, findet er genau diesen wieder. Der Benutzer genießt vollen Zugriff auf alle Funktionen, die AWS bietet (die Ausnahme wäre ein Subaccount mit einer Organisations-Policy). Legt der Admin hier einen zweiten Benutzer an, bekommt dieser nur explizit zugewiesene Rechte. Beim Anlegen eines neuen Benutzers stellt die Konsole eingangs die Frage nach dem Benutzernamen und wie sich dieser Benutzer anmeldet, ob per CLI/API und/oder über die Web Console.

Bereits im nächsten Schritt vergibt der Admin die Rechte. Er wählt sie aus existierenden Benutzergruppen (zum Beispiel »S3 Admins«, »Netzwerkadmins« et cetera), über Rollen (»S3 Admin«, »Netzwerkadmin«) oder vergibt sie individuell auf Policy-Ebene. Wer sein Leben gern kompliziert gestaltet, darf dem neuen Benutzer auch eine freie Kombination aus diesen Rechten zuteilen.

Damit niemand aus Versehen zu viele Rechte auswählt, lässt sich eine Permission Boundary definieren, in der etwa der für AWS zuständige Security-Administrator in einer Policy Rechte eingrenzt. Entsteht dann ein Widerspruch zwischen dieser Begrenzung und den zugeteilten Rechten, dann gewinnt die Begrenzung.

Rechte auf Ressourcen

Die Steuerung der Zugriffe regelt AWS mit Policies (»Richtlinien« bei deutscher Lokalisierung der Console). Eine Richtlinie besteht aus einer Reihe von Statements, die jeweils ein oder mehrere Rechte auf eine Ressource (mit Wildcards) an eine Rolle oder einen Benutzer geben. Dabei sind optional Bedingungen möglich. Listing 1 zeigt einen Ausschnitt aus einer Richtlinie aus [1] im Json-Format.

Das Feld »Sid« ist ein Name für das Recht, aber optional. »Effect« erlaubt (»Allow«) oder verbietet (»Deny«) den Zugriff. Das »Action«-Feld enthält eine Liste der API-Zugriffe, um die es geht. Im Beispiel sind dies alle Auflistungs- und Herunterladen-Operationen im S3-API. Im Feld »Resource« steht eine Liste der Ziele für die Operationen, formuliert sind sie als Amazon Resource Names (ARNs). Im Beispiel geht es um einen Bucket mit dem Namen »confidential_data« und dessen Inhalt. Ohne das letzte Feld »Condition« wäre diese Richtlinie allgemeingültig.

Die Bedingung am Ende sorgt dafür, dass der Benutzer beim Zugriff mittels Multifaktoranmeldung authentisiert sein muss, damit diese Regel greift. Je nach abzubildender Logik schreibt der Admin entweder einzelne Richtlinien in dieser Form und kombiniert sie oder er packt mehrere Statements in eine Richtlinie.

01 {
02   "Version": "2012-10-17",
03   {
04       "Sid": "s3zugriff",
05       "Effect": "Allow",
06       "Action": [
07         "s3:List*",
08         "s3:Get*"
09       ],
10       "Resource": [
11         "arn:aws:s3:::confidential-data",
12         "arn:aws:s3:::confidential-data/*"
13       ],
14       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
15     }
16   ]
17 }

Das Recht zu interagieren

Richtlinien kommen nicht nur bei der Zugriffssteuerung von Anwendern zum Einsatz, sondern auch in der Interaktion von AWS-Entitäten. Eine Lambda-Funktion, die SNS (Simple Notification Service) versenden möchte, benötigt etwa eine Rolle, die eine Richtlinie mit den entsprechenden Rechten im SNS-Bereich enthält.

Richtlinien bestimmen also, welche Operationen auf welchen Objekten erlaubt sind. Der Admin ordnet sie Benutzern oder Funktionen zu. Eine Richtlinie steuert aus Sicht des CIA-Tripel, wer innerhalb der angelegten AWS-Objekte auf die Daten zugreifen darf. Die Ziele C und I gegenüber den Administratoren von AWS sind so noch nicht bedacht.

AWS S3

Einer der ältesten Dienste von AWS ist der Simple Storage Service [3] oder kurz S3. Er unterteilt sich auf der obersten Ebene in so genannte Buckets. In einem Bucket gibt es Ordner und Objekte/Dateien. S3-Buckets sind auch der einfachste Weg, eine statische Website in AWS zu starten. Der Admin legt die Dateien, die die Website ausmachen, in einen Bucket und kann sie mit wenigen Klicks per HTTP(S) bereitstellen. Dies ging in der Vergangenheit auch einige Male schief, weil so versehentlich vertrauliche Daten offen im Internet standen.

Abbildung 1 zeigt die Einstellungen beim Anlegen eines Bucket. Ist die Verschlüsselung hier aktiviert, kann der Anwender auswählen, ob das AWS-System automatisch generierte oder die im Key Management Service (KMS) hinterlegten verwenden soll. Die Verschlüsselung gilt für die Objekte im Bucket. In der Standardeinstellung ist auch der öffentliche Zugang gesperrt (Abbildung 2).

Auch auf Ebene eines Ordners kann der Admin steuern, welche Verschlüsselung greift (Abbildung 3). Als letzte Stufe bleibt das einzelne Objekt (eine Datei beispielsweise). Auch hier kann der Anwender einstellen, ob und welche Kryptomethode zum Tragen kommt.

Alternativ bleibt immer die Möglichkeit übrig, dass der Anwender die Objekte vor dem Hochladen in S3 lokal verschlüsselt, sodass es kein Schlüsselmaterial in AWS gibt, das sie entschlüsseln könnte.

Abbildung 1: Einstellungen beim Anlegen eines S3-Bucket.

Abbildung 2: Die zweite Seite der Einstellungen beim Erstellen eines Bucket.

Abbildung 3: Die Verschlüsselungs-Optionen für Ordner in S3.

AWE KMS

Bisher ist geklärt, wie der Kunde seine Daten verschlüsselt ablegt. Wie gezeigt verwenden Amazon-Dienste auf Zuruf automatisch generierte Schlüssel. Das ist schnell eingerichtet, und die Daten sind verschlüsselt. Allerdings bleiben so die CIA-Ziele C und I gegenüber den Amazon-Admins unerreicht.

Wer mehr Kontrolle über die Schlüssel will, verwendet den Key Management Service (KMS, [4]). In der KMS-Console bietet AWS eine Liste der implizit generierten Schlüssel an, um etwa Datenbanken zu verschlüsseln. Der zweite Punkt sind Kunden-verwaltete Schlüssel, die der Admin in der Console generiert und mit einer Richtlinie versieht. In diesem Fall hängt eine Richtlinie an einem Schlüssel – wer den Schlüssel verwendet, darf tun, was in der Richtlinie steht.

Legt der Benutzer im KMS einen eigenen Schlüssel an und verwendet KMS zum Erzeugen des Schlüssels, so fragt der Dialog ab, wer den Schlüssel verwalten und wer ihn zum Ver- und Entschlüsseln benutzen darf. Daraus errechnet die Benutzerführung eine Richtlinie, die sie an den Schlüssel hängt.

Statt AWS einen Schlüssel generieren zu lassen, ist es auch möglich, einen extern erzeugten Schlüssel zu hinterlegen. In diesem Fall verlangt die Console vom Admin die Auswahl eines Algorithmus, mit dem der Schlüssel vor dem Hochladen zu verpacken ist, sowie ein Token, mit dem AWS den Schlüssel dann wieder auspacken kann. Ein Beispiel, wie der Admin das macht, findet sich unter [5].

Schließlich offeriert Amazon einen so genannten Cloud HSM Cluster ([6], HSM steht für Hardware-Sicherheitsmodul). Wählt der Admin diese Option, bindet er einen Strauß aus mehreren Hardware-Security-Modulen, in denen Schlüsselmaterial Manipulations-sicher liegt, und erreicht das höchste Kontroll-Niveau, das im Cloudkontext möglich ist.

Alle Anfragen zur Verschlüsselung beantworten die HSMs, ihre Hardware stellt sicher, dass niemand die Schlüssel ausliest. Als Cluster ausgelegt, ist Amazon Cloud HSM hochverfügbar (A in CIA) – was für alle wichtig ist, die große Teile ihrer Infrastruktur per HSM absichern.

Durch die Austauschbarkeit der Komponenten und die API-Kompatibilität muss der große Schritt zum Cloud HSM in einer Architektur nicht gleich am Anfang der Entwicklung erfolgen. In dieser Konfiguration bleibt als Vertrauensthema übrig, dass die Clients des Keymanagement-Service unter Kontrolle von AWS stehen, sie also entschlüsselte Daten im Hauptspeicher halten.

VMs mit verschlüsselten Festplatten

Amazons VM-Service EC2 verwendet für die virtuellen Festplatten natürlich den S3-Service. Daher ist es auch möglich, die Festplatten zu verschlüsseln. Linux-Administratoren kennen das schon lange auf Ebene verschlüsselter Partitionen oder Volumes. Das bedeutet aber entweder, dass der Admin beim Booten der Maschine ein Passwort eingeben oder das Passwort im Bootloader hinterlegt sein muss. Im letzten Fall bleiben bei einem Diebstahl die Daten ungeschützt.

Die AWS Cloud verwendet hinter den Kulissen KMS. Legt ein Admin eine neue VM an, bietet ihm das Menü zur Speicherverwaltung die Option an, die Festplatte zu verschlüsseln (Abbildung 4). In der Auswahlliste erscheinen die in der gewählten AWS-Region erzeugten Schlüssel des Anwenders.

Abbildung 4: Verschlüsselungsoption in AWS EC2 beim Anlegen einer VM.

Startet die VM, holt sich der Hypervisor die Daten zur Entschlüsselung. Admins jedoch, die beim Anlegen des Schlüssels keine Zugriffsberechtigung auf diesen erlangt haben, dürfen zwar die Festplatte an eine VM hängen, können aber wie bei einem anderweitig verschlüsselten Volume die Daten nicht lesen.

Da AWS leider keine Konsole zu einer Linux-VM bietet, funktioniert das Arbeiten mit Bordmitteln von Linux nicht für das Rootvolume. Liegen aus Sicht der VM die vertraulichen Daten auf einer getrennten Partition, kann der Admin wie sonst auch die VM Booten, das Volume manuell mounten und das Passwort eingeben, und somit liegt kein Schlüssel bei AWS.

Fazit

Auch der Cloud-Marktführer kann das grundsätzliche Problem nicht lösen, dass private Schlüssel auf aus Kundensicht fremden Servern nicht gegen jede Form von Bedrohung immunisierbar sind. Die Dienste des angebotenen AWS HSM Cluster zu beanspruchen, geleitet Admins jedoch bereits ein weites Stück des Weges hin zu einem akzeptablen Schutzniveau ihrer Unternehmsdaten. Einen gewissen Vertrauensvorschuss muss der Anwender Amazon jedenfalls geben oder – wo das sachlich möglich ist – die Architektur in der Cloud so anpassen, dass dort keine sensiblen Daten liegen.

In Sachen Akzeptanz macht der KMS die Anwendung von Verschlüsselung relativ einfach und dämpft so die Neigung weniger Datenschutz-affiner Anwender, gar nichts zu verschlüsseln.