Überblick über Sicherheitsfragen bei Amazon S3

S3-Zugangskontrolle ist nett einzustellen und schwer zu verwalten

Für einen Sicherheitspraktiker besteht die Herausforderung bei S3 darin, die Vorteile von Cloud Speicher zu nutzen und dabei die notwendigen Vorsicht walten zu lassen.

Die Vorteile der Cloud-Speicherung:

• Der S3-Dienst wird vollständig von Amazon verwaltet.
  Amazon übernimmt die Verantwortung für Infrastruktur, Hardware, Netzwerk, Betriebssystem, Anwendungssoftware und verantwortet alle entsprechenden Sicherheitsthemen.

• Hohe Sicherheitsstandards
  AWS als Cloud-Anbieter verfügt über die notwendigen Größenvorteile, um die hohen Sicherheitsstandards für den S3-Dienst aufrechtzuerhalten. Auch große Unternehmen tun sich schwer, dieses Niveau in allen IT-Abteilungen halten zu können.

Vorsicht ist geboten, denn:

• Jeder Fehler zählt
  Die grundlegenden Eigenschaften von S3 haben als Cloud-Service keine Verteidigungsschichten, die sonst in Ihrer traditionellen Umgebung vorhanden wären, z.B. keine Firewalls, keine geschlossenen Benutzergruppen.

• Zugriffskontrolle liegt in Ihrer Verantwortung
  Die Sicherheit Ihrer Daten in S3 hängt voll und ganz von den korrekten Zugangskontroll-Einstellungen ab, die in Ihrer Verantwortung liegen und jederzeit eingehalten werden müssen.

Leider ist die S3-Zugriffskontrolle schön einzustellen und schwer zu warten:

• Das Schema der Zugriffsberechtigungen, über sogenannte “Policies”, ist sehr flexibel und der Entwickler kann zunächst alles umsetzen, was für ein bestimmtes Projekt von ihm verlangt wird. Die Kenntnis der eher technischen JSON-Syntax ist für Entwickler keine wirkliche Hürde.

• Nach einiger Zeit müssen die Berechtigungen auf ihre Korrektheit hin überprüft werden, und dies kann nicht nur Know-how bis tief in die spezifischen Details der JSON-Policy erfordern, sondern auch Wissen wo sich die relevanten Policyelemente in verschiedenen Teilen des Systems befinden können.

• Erschwerend kommt hinzu, dass die veraltete Zugriffskontrolle mit ACLs ebenfalls evaluiert werden müssten, wenn sie in einer bestimmten Umgebung existieren würden.

Diskutieren wir die Fragen der Reihe nach.

Grundlegende Eigenschaften von S3 und ihre überraschenden Auswirkungen

Amazon S3 (Simple Storage Service) ist einer der ersten Cloud-Dienste von Amazon, der 2006 von Amazon ins Leben gerufen wurde. Seine Flexibilität zur Speicherung von Objekten aller Größen von mehreren kByte bis zu mehreren TByte hat S3 zu einem der beliebtesten Dienste von AWS gemacht. Im Laufe seiner Geschichte hat S3 jedoch eine Reihe von Funktionen erworben, was für Benutzer, die neu bei AWS sind, überraschend sein mag:

Globaler Dienst und die Verantwortung des Eigentümers

Ein wichtiges Merkmal des S3-Dienstes, das er mit den meisten anderen Cloud-Diensten gemeinsam hat, ist seine universelle Konnektivität: Er kann von überall im Internet erreicht werden, Ausnahmen wären China u.a.. Die Daten in S3 sind in Buckets organisiert und damit von anderen Eigentümern abgegrenzt. Wenn Sie Eigentümer eines Buckets auf S3 sind, sind Sie der Einzige, der festlegen kann und muss, wer Zugriff auf die Daten im Bucket erhält und wer nicht. Es gibt keine andere Instanz, insbesondere nicht AWS, die sich um den Zugriff auf Ihre Daten kümmern würde. Tatsächlich macht ein einziges Attribut in S3, das den Eigentümer bezeichnet, den Unterschied.

Globaler Namensraum

Der Name jedes Buckets wird in einem weltweiten Kontext definiert. Dies hat den etwas ungewohnten Effekt, dass Sie den Namen eines Buckets nicht frei wählen können, da der Name möglicherweise bereits von jemand anderem genommen wurde. Zum Beispiel kann der Bucket “www.amazon.com" nicht von Ihnen erstellt werden. Er ist vermutlich im Besitz von Amazon selbst. Da es mehr als 1 Million Konten bei AWS gibt, können Sie sich vorstellen, dass alle Wörter aus Wörterbüchern und sogar ihre Kombinationen bereits vergeben sind.

Sobald Sie einen Bucket gelöscht haben, können Sie ihn möglicherweise nicht mehr mit demselben Namen neu erstellen:

Tatsächlich erhalten Sie zum Zeitpunkt des Verfassens dieses Artikels (Oktober 2016), wenn Sie einen Bucket löschen und versuchen, ihn in einer anderen Region zu erstellen, etwa 1 Stunde lang folgende Fehlermeldung in der Konsole:

Datenort

Die S3-Konsole ist konsistent mit dem globalen Namensraum und unterscheidet nicht zwischen Regionen. Bei der Erstellung eines Buckets gibt der Eigentümer den Speicherort der Daten an, und Amazon garantiert, dass die Daten in der gleichen Region und damit innerhalb der gleichen Rechtsprechung verbleiben. Es gibt eine Kehrseite der Medaille: Sie können einen Bucket nicht an einen anderen Standort verschieben. Sie müssten ihn löschen und an einem anderen Ort neu erstellen. Letzteres kann sich als nicht möglich erweisen, wenn er einen attraktiven Namen hatte, der in der Zwischenzeit von jemand anderem übernommen wurde.

S3-Zugangskontrolle ist schön einzustellen und schwer zu pflegen

Da der Zugang zu einem Bucket weder durch Konnektivität noch durch Namensraum beschränkt ist, kann jeder eine Anfrage an Ihre Buckets stellen. Dies legt die Last der Zugriffskontrolle vollständig auf die Konfiguration der richtigen Berechtigungen, es gibt keine weitergehende Verteidigung gegen Fehlkonfigurationen.

Sehen wir uns einmal genauer an, wie Berechtigungen konfiguriert und überprüft werden:

Zugriffskontrolle mit ACLs

S3 verfügt über zwei grundlegend unterschiedliche Zugangskontrollmechanismen: Zugriffskontrollliste (ACL) und Bucket-Policy. Während ACL in der Benutzeroberfläche stärker in den Vordergrund gerückt ist, ist es eigentlich die ältere Methode und bietet für viele Anwendungsfälle nicht genügend Flexibilität.

Zugriffskontrolle mit Policy

Die Bucket-Policy ist nach den ACLs gekommen und ist mit ihrem JSON-Format wesentlich leistungsfähiger als ACLs. Der “AWS Policy Generator“ hilft bei der Navigation durch die Möglichkeiten. Wenn jedoch jemand Berechtigungen ändert oder überprüft, muss er/sie die JSON-Syntax und die Semantik verstehen. Ein einfaches Beispiel ist die folgende Policy für die Gewährung von Lesezugriff für jeden, aus der AWS-Referenz:

{
    "Version":"2012-10-17",
    "Statement":[
        {
            "Sid":"AddPerm",
            "Effect":"Allow",
            "Principal": "*",
            "Action":["s3:GetObject"]
            "Resource":["arn:aws:s3:::examplebucket/*"]
        }
    ]
}

Wie Sie an diesem einfachsten Beispiel sehen können, erfordert das Verständnis von ZugangsPolicy Know-how sowohl in der JSON-Syntax als auch im AWS-Vokabular. In der Praxis werden die Berechtigungen sehr viel komplexer, und jeder, der sie ändert oder überprüft, muss die Details vollständig verstehen oder wird unwissentlich Risiken eingehen.

Policy an vielen Stellen

Zusammenfassend lässt sich sagen, dass die folgenden Objekttypen, aufgelistet von generisch bis spezifisch, den Zugriff auf Ihre Daten in S3 gewähren oder verweigern können:

• IAM-Policy
  • AWS-verwaltete Policy, die einem Benutzer, einer Gruppe oder einer Rolle zugeordnet ist
  • von Kunden selbst verwaltete Policy, die einem Benutzer, einer Gruppe oder einer Rolle zugeordnet ist
  • Inline-Policy für einen Benutzer, eine Gruppe oder eine Rolle
• Bucket-Policy
• Bucket-ACL
• Objekt ACL

Dies bietet ein hohes Maß an Flexibilität bei der Umsetzung der Zugangskontrolle. Es gibt keinen Rat von AWS, ob der Einsatz von IAM-Policy oder Bucket-Policy generell besser wäre. Stattdessen kann die Wahl je nach spezifischen Anforderungen für jeden Anwendungsfall anders ausfallen. Es gibt sogar Anwendungsfälle, in denen Bucket-ACLs oder sogar Objekt-ACLs verwendet werden müssen, da die Policy nicht alle Aspekte abdecken kann.

Die Kehrseite der Medaille ist die Wartung. Denn jemand, der die Zugriffskontrolle überprüft, muss alle Möglichkeiten abdecken, wo eine relevante Policy gespeichert sein könnte (natürlich neben der Überprüfung der ACLs). Um bei dieser Aufgabe zu helfen, stellt AWS den “IAM Policy Simulator“ zur Verfügung, der eine Policy in Bezug auf ein Zugriffsziel simuliert und den resultierenden Zugriff (allow, deny) anzeigt.

Policy-Simulator und die feineren Details

Der Praktiker kann die Simulation als Anhaltspunkt nutzen, wo er nach weiteren Details suchen muss, kann sich aber nicht vollständig auf die Antwort verlassen, da sie von der genau gewählten Anfrage abhängt. Die im obigen Screenshot gestellte Frage war: “Hat ein bestimmter Benutzer Lesezugriff auf alle Buckete” und die Antwort lautet genau “ja”, da diesem Benutzer die Policy “AmazonS3ReadOnlyAccess” zugewiesen wurde.

Wenn die Simulation jedoch “verweigert” anzeigt, kann dies irreführend sein. Im Beispiel unten wurde z.B. die Frage gestellt, ob ein Benutzer “Dave” Zugriff auf einen bestimmten Bucket hat, und die Antwort lautete “verweigert”.

Man kann jedoch an der Policy JSON auf der linken Seite erkennen, dass der Zugang für einen Pfad “/dave/*“ innerhalb des Buckets gewährt wird. Wenn man die Simulation erneut mit der richtigen Frage durchführt, ob Dave Zugriff auf den Inhalt des Ordners “/dave/*“ hat, erhält man das genaue Ergebnis “allow”:

Empfehlungen

Konfigurationsprüfungen

• Überprüfen Sie den Speicherort Ihrer Buckets
  Wenn Sie Buckets programmgesteuert erstellt haben und dabei den Standort nicht angegeben haben, wurde der Bucket in den USA (Region us-east-1) erstellt. Dies ist eine Fehlerquelle, die überprüft werden sollte.

• Reservieren Sie Ihre Bucket-Namen im globalen Namensraum
  Ich würde empfehlen, dass Sie Buckets für Ihre registrierten DNS-Namen erstellen.
  Es gibt Verbindungen zwischen DNS-Namen in Route 53 und Bucket-Namen in S3 für das Website-Hosting. Da Amazon keine Beschränkungen für Markennamen durchsetzt, kann es später zu Problemen kommen.

Zugriffsprüfungen

• Vermeiden Sie die Verwendung von ACLs für Bucket
  ACLs auf Bucket werden nur in Einzelfällen wie z.B. bei der Logsammlung benötigt.
  Für alle anderen Fälle schreiben Sie die ACLs in Bezug auf die Policy neu und entfernen Sie die ACL mit Ausnahme der Standardeinstellung “Selbst” “Vollzugriff”, um Überraschungen durch unerwünschte Zugriffe zu vermeiden.

• Führen Sie eine regelmäßige Überprüfung des Zugriffs auf Ihre Buckets durch
  Die Zugriffsübersicht sollte alle relevanten Policies auflisten und angeben, welcher Benutzer auf welchen Bucket Zugriff hat.

Hacking, Sicherheitsbulletins, Patching und Notfälle

Dieses Dokument ist keinesfalls eine Anleitung zum Hacken von S3. Ganz im Gegenteil, wir gehen davon aus, dass S3 wie beschrieben funktioniert und wir spielen einfach nach den von AWS festgelegten Regeln. Wir wissen jedoch, dass nicht jeder nach den Regeln spielt und versuchen kann, die S3-Kontrollen, die von AWS gepflegt werden, zu brechen. Trotz aller Zertifizierungen von AWS besteht immer die Möglichkeit, dass eine Schwachstelle besteht und ausgenutzt werden kann. AWS informiert über Schwachstellen über Security Bulletins von AWS, z.B. https://aws.amazon.com/security/security-bulletins/openssl-security-advisory-may-2016/. In vielen Fällen hat AWS die Verantwortung, die Schwachstelle durch Patches zu beheben, insbesondere bei S3. In anderen Fällen können Maßnahmen unsererseits erforderlich sein. In extremen Fällen wäre es unsere Pflicht zu entscheiden, ob wir unsere Dienste einstellen müssen, um mögliche Schäden zu vermeiden. Zum Glück ist dies eher eine theoretische Möglichkeit als eine praktische Überlegung, da der größte Teil der S3-Infrastruktur unter der Kontrolle von AWS steht.

Verschlüsselung

Verschlüsselung wird oft als eine wichtige Sicherheitsmaßnahme für Cloud Computing genannt. Dies gilt sicherlich für Data-in-Transit, und alle Datenübertragungen zu und von S3 werden mit SSL verschlüsselt, wenn die üblichen Zugriffspfade (Console, AWS SDK, AWS CLI) verwendet werden. Die möglichen Ausnahmen sind öffentliche Websites, die auf S3 gehostet werden. Dies funktioniert so gut, dass der Cloud-Nutzer es gar nicht bemerkt.

Auch Data-at-Rest kann auf S3 verschlüsselt werden, indem ein Attribut am Objekt selbst gesetzt wird, es gibt keine Einstellung für den Bucket:

Die Verschlüsselung wird durch den S3-Dienst völlig transparent für den Benutzer durchgeführt. Die vom Benutzer empfangenen Daten werden verschlüsselt, bevor sie auf der Festplatte gespeichert werden, und werden von der Festplatte gelesen und entschlüsselt, bevor sie an den Benutzer gesendet werden. Da der Benutzer keinen Unterschied feststellen wird, kann und sollte die Verschlüsselung für jedes Objekt aktiviert werden.

Die serverseitige Verschlüsselung kann jedoch nur vor internen Bedrohungen innerhalb der AWS schützen, z.B. wenn ein Hacker Zugriff auf das dem S3-Dienst zugrunde liegende Dateisystem hätte oder eine Festplatte verloren ginge. Sie würde die Zugriffskontrolle nicht stärken, da alle Benutzer mit Zugriff, ob legitim oder nicht, die entschlüsselten Daten erhalten. Wenn mehr Schutz für die Daten erforderlich wäre, sollte in Bezug auf die Schlüsselverwaltung gehandelt werden.

Schlüsselverwaltung

Die Verschlüsselung funktioniert deshalb so einfach, weil die Schlüsselverwaltung von AWS übernommen wird, die die Schlüssel sicher aufbewahren muss. Wenn ein Schlüssel verloren ginge, wären die entsprechenden Daten verloren. Eine zuverlässige und sichere Schlüsselverwaltung ist eine zwingende Voraussetzung für die Verschlüsselung von Daten im Ruhezustand.

Höhere Schutzanforderungen, die einige Unternehmen möglicherweise für einige ihrer Daten haben können, werden in diesem Dokument nicht behandelt. In diesem Fall müsste die Cloud-Nutzerorganisation eine eigene Schlüsselverwaltung und/oder Ver- und Entschlüsselung selber durchführen. Um dies zu erleichtern, bietet AWS den KMS (Key Management Service) und die zugehörigen Verschlüsselungsbibliotheken mit ihren SDKs an.

Die Implementierung einer Schlüsselverwaltung und/oder Verschlüsselung könnte erheblichen Aufwand bedeuten und würde den Vorteil von S3 als universelle Schnittstelle für die Speicherung zunichte machen. Daten werden selten von einer einzigen Anwendung gespeichert und abgerufen, sondern dienen in der Regel vielen Anwendungen, die alle Zugriff auf die Schlüssel haben und den Entschlüsselungsalgorithmus implementieren müssen. Folglich ist für die meisten Anwendungsfälle eine eigene Schlüsselverwaltung und Verschlüsselung zu unflexibel und wirtschaftlich nicht durchführbar.

Zusammenfassung

Es lässt sich sagen, dass die S3-Sicherheit täuschend einfach aussieht, aber der Aufwand hoch ist, sie richtig zu machen und die Daten sicher zu halten.
Von Ekkard Schnedermann, Oktober 2016