S3 Object Storage sicher verwalten

S3 Object Storage sicher verwalten

Tagtäglich fallen mehr und mehr Daten an und müssen gespeichert werden – oft dauerhaft. Gerne geschieht dies als Backup oder zur dauerhaften Archivierung. Meist aber einfach, um sie fallweise zur Verfügung zu haben und in Arbeitsabläufe einzubinden. Der ProfitBricks S3 Object Storage ermöglicht es Ihnen daher, große Datenmengen flexibel und kostengünstig zu speichern und bei Bedarf mit Kollegen, Kunden und Partnern auszutauschen oder für betriebliche Prozesse bereitzustellen – zum Beispiel über APIs.

So erlaubt es S3 als De-facto-Standard ohne weiteres, beliebige Daten vielseitig verfügbar zu machen. Allerdings ist es auch ebenso einfach, die Zugriffsrechte zu großzügig zu gewähren und somit unabsichtlich Daten preis zu geben, die nicht zur Weitergabe bestimmt sind. (z.B. US-Kreditinstitut legt Kundendaten in öffentlich zugänglichem S3-Bucket ab)

In diesem Artikel werden wir daher unseren Anwendern

  • das Berechtigungskonzept von S3 kurz beschreiben,
  • anhand von konkreten Fragestellungen Lösungen aufzeigen,
  • zeigen, worauf bei der Security zu achten ist.

Im Ergebnis sind Sie dann in der Lage, ProfitBricks S3 Object Storage professionell zu nutzen, nämlich einfach eingebunden und trotzdem sehr sicher!

S3-Berechtigungskonzept

Siehe auch ProfitBricks S3 Object Storage  Zugriffsverwaltung.

Permissions

S3 kennt sog. Permissions (Zugriffsrechte) für Buckets und Objekte:

  • Readable: Lesezugriff auf Bucket (Inhalt auflisten) und Objekte (Anzeigen, Herunterladen)
  • Writable: Schreibzugriff auf Bucket (Objekte im Bucket erstellen, verändern, löschen)
  • ACP Readable: Berechtigungen für Bucket bzw. Objekt lesen
  • ACP Writeable: Berechtigungen für Bucket bzw. Objekt ändern

Ordner haben keine Zugriffsberechtigungen.

Grantees

S3 bietet sog. Grantees (Berechtigte):

  • Public: Jeder, ohne Einschränkungen
  • Authenticated Users: Jeder mit einem beliebigen ProfitBricks-Object-Storage-Account
  • Account: Explizit angegebener User mit einem ProfitBricks-Object-Storage-Account oder alle User eines ProfitBricks-Vertrags
  • Owner: Besitzer (Ersteller) des Buckets bzw. Objekte. Dieser hat immer den vollen Zugriff auf eigene Buckets und Objekte

Standardmäßig sind die Berechtigungen für neue Buckets und Objekte so eingestellt, dass nur der Besitzer Zugriff auf diese hat (‚private‘).

Diese Einstellungen bieten den besten Schutz. Man sollte also nur davon abweichen, wenn es nötig ist und auch nur im unbedingt erforderlichen Umfang.

Vererbung

Die bekannte Funktion der Vererbung von Rechten gibt es bei S3 nativ nicht. Vererbung von Rechten eine Funktionalität, die von separaten S3-Clients als individuelles Feature bereitgestellt wird – je nach Client mit unterschiedlichem Komfort.

Hier ist ebenfalls größte Vorsicht geboten, damit nicht bestehende Rechte rekursiv überschrieben werden und Objekte in die falschen Hände gelangen.

Anwendungsbeispiele

Im Folgenden soll anhand von Beispielen die Rechtevergabe und deren Auswirkungen erläutert werden.
Dabei werden wir mit folgenden Benutzern arbeiten, die alle den ProfitBricks-Object-Storage nutzen dürfen:

  • User JB ist Vertragsinhaber mit
    ACL UserID 31789654|d57ca150-57d8-411a-acb0-33292878e159
    Canonical ID 1deec1eddb397e13089b4ca0550074ac
    E-Mail juergen.buchhammer@profitbricks.com
  • In dem Vertrag gibt es den Sub-Account SUB mit
    ACL UserID 31789654|0aa0d7b9-dbfb-4b53-b055-d6ffa84a89fa
    Canonical ID a2535f2348b2d9cab28b8dcbb2cce92e
    E-Mail juergen.buchhammer+s3@profitbricks.com
  • In dem Vertrag gibt es den Sub-Account ANON mit
    ACL UserID 31789654|653b5f4f-9105-4194-9053-d25a2345bd2a
    Canonical ID f54ddf9a882ae263d91820bd8edee4af
    E-Mail juergen.buchhammer+anon@profitbricks.com

Gemeinsamer Informationsbereich für Sub-User

Als User JB möchte ich den gemeinsamen Arbeitsbereich ‚team-area‘ mit meinem Sub-Account SUB einrichten, sodass wir einfach Dateien gemeinsam nutzen und austauschen können.

Als ProfitBricks-Vertragsinhaber (Contract Owner) steht Ihnen automatisch der ProfitBricks S3 Object Storage zur Verfügung. In Ihrem Vertrag können Sie weitere Benutzer anlegen und ihnen den Zugriff auf den ProfitBricks S3 Object Storage erteilen (s. ProfitBricks S3 Object Storage im DCD verwalten).

In der Object-Storage-Management-Console hat jeder Benutzer seine eigene Ansicht, die ausschließlich die eigenen Buckets enthält. Das heißt, der Sub-Account sieht nicht die vom Vertragsinhaber erstellten Buckets, und der Vertragsinhaber sieht nicht die vom Sub-Account erstellten Buckets.

Dies ändert sich auch nicht, wenn Buckets für den Sub-Account über die ACLs freigegeben werden. Über die Management-Console können diese externen Buckets leider nicht eingebunden werden. Daher werden wir hierfür einen 3rd-Party-S3-Client verwenden, zum Beispiel den S3 Browser.

Der User SUB hat ein eigenes Bucket ‚s3-sub‘ erstellt. In S3Browser sieht dies wie folgt aus:

SUB-S3

Object Storage User SUB

Damit der User SUB Zugriff auf das Bucket ‚team-area‘ von JB hat, muss er zuerst mit der Permission ‚Readable‘ eingetragen werden. In der Management-Console sieht dies dann wie folgt aus:

User SUB kann nun über den S3-Client das externe Bucket ‚team-area‘ in seine Bucket-Übersicht aufnehmen:

Danach sieht SUB auch das Bucket ‚team-area‘ (externe Buckets werden hier andersfarbig dargestellt). SUB kann wegen der Berechtigung ‚Readable‘ nun auch das Bucket öffnen und sich den Inhalt anzeigen lassen:

Für das Objekt ‚ReadMe.txt‘ selbst sind User SUB noch keine Berechtigungen vergeben worden. SUB kann das Objekt nicht anzeigen lassen oder die Berechtigungen einsehen. Trotzdem kann SUB sich von allen Objekten in dem Bucket bereits einige Eigenschaften anzeigen lassen:

Merke: Allein durch die Berechtigung ‚Readable‘ für ein Bucket können sich User Objekteigenschaften wie Name, Größe und Änderungsdatum aller Objekte anzeigen lassen. Diese können bereits schützenswerte Informationen enthalten, z.B. ‚Kündigung_Mitarbeiter_XYZ.pdf‘.

Nun soll der User SUB natürlich die Objekte in ‚team-area‘, wie z.B. ‚ReadMe.txt‘ lesen können. Daher vergeben wir die Berechtigung ‚Readable‘ für das Objekt ‚ReadMe.txt‘ an SUB:

Beachten Sie, dass es hier keine Berechtigung für ‚Writable‘ gibt.

User SUB kann sich nun ‚ReadMe.txt‘ herunterladen und anzeigen lassen:

Erweiterung auf gegenseitigen Austausch

User SUB soll nun die Datei um seinen Namen und die ACL UserID ergänzen. In der lokalen Kopie ist dies möglich, allerdings kann die geänderte Datei nicht wieder hochgeladen werden.

Dafür muss für SUB zusätzlich die Berechtigung ‚Writable‘ am Bucket ‚team-area‘ vergeben werden.

Merke: Die Berechtigung ‚Writable‘ kann nicht individuell für einzelne Objekte vergeben werden. Writeable wird am Bucket eingestellt und erlaubt damit, alle Objekte im Bucket zu ändern, zu löschen und neue Objekte hochzuladen.

SUB hat nun wie gewünscht ‚ReadMe.txt‘ angepasst und hochgeladen. Zusätzlich hat SUB eine weitere Datei hochgeladen:

Schauen wir uns nun die Eigenschaften und Berechtigungen als User SUB an, ist SUB nun nicht nur Owner des neuen Objektes ‚SUB_ist_neu_im Team.txt‘, sondern auch des ursprünglich vom User JB erstellten Objektes ‚ReadMe.txt‘:

Was bedeutet das nun für den ehemaligen Besitzer JB?

User JB sieht in der Management-Console gar keine Berechtigungen mehr, auch nicht für ‚ReadMe.txt‘, und weiß nun nicht einmal mehr, wer der neue Besitzer ist:

Nun ist JB ja weiterhin Owner des Buckets mit vollem Zugriff, also auch Readable und Writeable im Bucket.

Und tatsächlich: JB kann nun seine lokale Kopie wieder hochladen und das Objekt als Owner übernehmen:

Merke: Auch wenn ein Objekt nicht lesbar ist, kann durch Writeable am Bucket das Objekt gelöscht oder ersetzt und dadurch der Besitz übernommen werden.

Policies verhindern das Chaos

Das Hin und Her der Besitzer und damit auch der jeweiligen Berechtigungen könnte organisatorisch gelöst werden. Erfahrungsgemäß stellen sich dabei aber über kurz oder lang Sicherheitslücken ein – spätestens wenn ein User aus dem Bereich ausscheidet.

Amazon hat die Unzulänglichkeit erkannt und mit Bucket- und User-Policies eine Möglichkeit geschaffen, eventuellem Chaos vorzubeugen.

Diese Policies werden nicht von jedem S3-Client (und leider auch nicht von der Management-Console) unterstützt. Der Client ‚S3 Browser‘ ist jedoch in der Lage, Bucket-Policies im Object-Storage zu hinterlegen.

Als Bucket-Owner erstellen wir folgende Policy:

Diese besteht aus zwei Statements:

Das erste erlaubt den Usern SUB und ANON den Upload von Objekten, wenn hierbei im http-Header der Parameter x-amz-acl = bucket-owner-full-control mitgegeben wird.

Das zweite Statement erzwingt, dass der Parameter unbedingt mitgegeben werden muss, auch wenn ggf. noch weitere Regeln existieren.

Dadurch wird für jedes hochgeladene Objekt der beiden User immer der volle Zugriff für den Bucket-Owner JB gewährleistet.

Durch die Policy können wir nun aber die Permission ‚Writable‘ am Bucket wieder entziehen. Dies bringt uns einen weiteren Vorteil: In den Statements ist nur die Aktion ‚PutObject‘ erlaubt. Writable am Bucket erlaubt noch zusätzlich DeleteObject – und genau das ist jetzt nicht mehr möglich. User ANON kann nun nicht mehr Objekte der anderen User löschen. Für die eigenen Objekte hat er als Owner weiterhin vollen Zugriff.

Merke: Durch Policies können Berechtigungen detaillierter vergeben werden als durch die Permission der ACL. Durch Policies können auch Berechtigungen erzwungen werden.

Versionen sichern gegen Verlust

Auch wenn Objekte anderer Owner nicht mehr gelöscht werden können, besteht immer noch die Möglichkeit, diese durch ein erneutes Hochladen zu überschreiben, im schlimmsten Fall durch eine leere Datei praktisch zu vernichten.

Wird allerdings die Versionierung eingeschaltet, bleiben auch die vorigen Inhalte verfügbar und können wieder hergestellt werden.

Download einzelner Objekte

Eine Besonderheit des S3-Berechtigungskonzept ist es, dass die Permissions von Buckets und Objekten unabhängig voneinander sein können.

Wir werden im Folgenden sehen, dass ein User ein Objekt herunterladen kann, ohne auch nur Leseberechtigung am Bucket zu haben.
Nicht jeder S3-Client unterstützt dieses Vorgehen, aber mit den CLI-Tools des S3Browsers lässt sich dies problemlos durchführen.

Für das Bucket ‚pb-ps‘ ist der User ANON nicht als Grantee eingetragen, hat also keine Berechtigungen:

In dem Bucket hat ANON aber Leserechte auf das Objekt ‚CB-Impression.PNG‘:

User ANON hat seine Zugangsdaten in S3Browser als Account ‚PB-Anon‘ hinterlegt. Über das CLI-Tool s3browser-con kann er nun direkt das Objekt in das Verzeichnis ‚test-dl‘ herunterladen:

Merke: Der Zugriff auf Objekte kann unabhängig von Buckets vergeben werden. Um den Zugriff zu entziehen, müssen die Permissions an den Objekten entfernt werden. Das Leserecht am Bucket zu entfernen reicht nicht aus.

Objektzugriff für nicht registrierte Anwender

In vorigen Beispiel musste der User einen gültigen Account im Objekt-Storage haben. Objekte lassen sich aber auch ohne diese Einschränkung bereitstellen, nämlich über den ‚Public URL Access‘.
Für jedes Objekt kann dies in den Properties aktiviert werden:

Den Zugriff kann man sowohl durch eine maximale Anzahl an Downloads beschränken als auch durch eine Verfallszeit.

Bei der Begrenzung durch die Anzahl an Downloads gilt es allerdings zu beachten, dass jeder GET-Call den Download-Zähler erhöht. Das umfasst nicht nur abgebrochene Versuche. Auch die oft von Clients zur Beschleunigung verwendeten parallelen Downloads einzelner Teile erhöhen jeweils den Zähler. Es ist also praktisch nicht vorhersehbar, wie die Anzahl eingestellt werden muss. Wir setzen diese also auf -1, d.h. beliebig viele.

Besser geeignet ist damit die zeitliche Begrenzung. Wir aktivieren noch ‚Secure URL (https)‘ und erhalten durch ‚Apply‘ die URL für den Download:

Diese sogenannte pre-signed URL ist anhand meiner Zugangsdaten signiert und ermöglicht den direkten Zugriff auf das Objekt zum Download.

Dieser Zugriff ist damit aber nicht auf bestimmte User beschränkt. Jeder, der diese URL kennt, kann auf das Objekt zugreifen. Daher ist es je nach Inhalt wichtig, den Zugriff zeitlich einzuschränken und ggf. zu verschlüsseln.

Merke: Über ‚Public URL Access‘ können Objekte für nicht registrierte User bereitgestellt werden. Jeder, der die URL kennt, kann das Objekt herunterladen. Vertrauliche Informationen sollten so also nicht ausgetauscht werden.

Verschlüsselung

S3 Object Storage bietet die Möglichkeit der sogenannten ‚Server Side Encryption‘. Das klingt zunächst sicher, bietet allerdings nur an einer Stelle Schutz: Wenn ein Angreifer Zugriff auf die Hardware erlangt.

Bei einer ‚Server Side Encryption‘ wird bei einem Upload das Objekt nach dem Transfer auf dem Server verschlüsselt und vor dem Transfer auf dem Server entschlüsselt.

Damit ist für jeden berechtigten Zugriff die Verschlüsselung transparent. Das heißt: Jeder User mit Lesezugriff kann das Objekt lesen, ohne sich um die Verschlüsselung kümmern zu müssen.

Ein wirklicher Schutz ist nur bei ‚Client Side Encryption‘ gegeben, also die Verschlüsselung durch einen User vor dem Upload.

Zum Abschluss

In diesem Blog haben wir  gemeinsam die Sicherheit von S3 Object Storages anhand einiger üblicherSzenarien betrachtet. Amazon hat mit S3 als De-facto-Standard leider einige Möglichkeiten geschaffen, mit denen ein S3-Object Storage User unbeabsichtigt vertrauliche Daten preisgeben kann.

Daher noch einmal einige wichtige Hinweise:

  • S3 Object Storage ist sicher, wenn Sie die Berechtigungen auf dem voreingestellten privaten Zugriff belassen.
  • Wenn Sie die Berechtigungen erweitern, dann vergeben Sie so wenige Berechtigungen wie möglich.
  • Testen Sie mit anderen User-Accounts alle möglichen Szenarien.
  • Berücksichtigen Sie auch, dass User wieder verschwinden, z.B. ein ausscheidender Mitarbeiter.

Beherzigen Sie diese Ratschläge, so wird ProfitBricks S3 Object Storage Ihr wertvoller Begleiter im Storage-Alltag in der Cloud sein. Zögern Sie bei Fragen nicht, unseren kostenfreien 24/7-Support durch ausgebildete Systemadministratoren zu kontaktieren, wenn Sie weitere Fragen haben.

2 Replies to “S3 Object Storage sicher verwalten”

  1. Eine Frage hat sich mir doch gestellt. Es gibt bei der server-side-encryption auch die Möglichkeit, selbst einen Schlüssel bereitzustellen. Ist dies nicht auch sicher, weil man beim Download oder Öffnen der Datei dann diesen Schlüssel wieder benötigt?

    1. Hallo Florian,

      ja, wenn die Verschlüsselung mit vom Kunden bereitgestellten Keys erfolgt (SSE-C), wird nicht der Key selbst auf dem Server gespeichert. Dieser muss bei jedem GET/PUT/POST im Request-Header gesendet werden.

      Der Abschnitt war bewußt sehr scharf formuliert.
      Wir haben in unseren Kundengesprächen die Erfahrung gemacht, dass die Server-side encryption (SSE) schnell als Rundum-sorglos-Lösung gesehen wird. Das ist sie in der einfachen Form nicht und das wollte ich bewusst machen.

      SSE-C ist allerdings leider auch nicht ohne Tücken:
      Für jeden Request, egal ob mit oder ohne SSE, muss ich mich Authentifizieren. Bei SSE-C benötige ich zusätzlich den Encryption Key.
      Aber wo ist dieser hinterlegt, wenn ich über einen S3-Client auf meine Objekte zugreife?
      Dies wird in der Regel das gleiche System bzw. die gleiche Applikation sein, in der ich auch Access- und Secret Key hinterlegt habe.
      Damit wären dann alle Keys über einen gemeinsamen Angriffsvektor zu erreichen.

      Vergessen darf man natürlich auch nicht, dass der Verlust des Encryption Keys auch den Verlust der Daten zur Folge hat. Ohne den Key kann ich sie nicht mehr entschlüsseln.

      Dieses Problem habe ich aber auch bei einer Client-seitigen Verschlüsselung:
      Welche Maßnahmen muss ich gegen den Verlust etablieren?
      Und welche Maßnahmen muss ich für den Fall eines Diebstahls vorsehen?

      Client-seitige Verschlüsselung hat den Vorteil, dass ich die Verschlüsselung komplett von der Speicherung trennen kann.
      Dafür muss ich dann wiederum mehr Aufwand in Kauf nehmen (getrennte Systeme, Austausch der Daten bei Upload und Download, Synchronisierung etc.).

      Alles in allem wäre das Thema Verschlüsselung wohl einen eigenen Artikel wert.

      Danke für die Frage und auch Anregung

      Jürgen

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *