Suchen

Tools und Workflows zur Datenspeicherung in der Cloud, Teil 3 Metadaten im AWS-S3-basierten Data Lake

| Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

AWS S3 stellt eine gute wenn nicht die perfekte Lösung für den Primärspeicher im Zuge einer Data-Lake-Strategie dar. In diesem Beitrag wollen wir uns der Umsetzung zuwenden. Dabei beginnen wir mit der Daten-Aufnahme, dem Data-Ingest.

AWS-Konfigurationsregeln helfen dabei sicherzustellen, dass bestimmte Sicherheitsvorgaben auch eingehalten werden.
AWS-Konfigurationsregeln helfen dabei sicherzustellen, dass bestimmte Sicherheitsvorgaben auch eingehalten werden.
(Bild: Drilling / AWS)

Im Rahmen einer Datalake-Strategie sind mehrere Möglichkeiten vorstellbar, wie zu analysierende Daten nach AWS S3 gelangen. Das manuelle oder automatisierte Hochladen über das Internet über die S3-API ist nur für überschaubare Datenmengen praktizierbar. Alternativ können Nutzer verwaltete AWS-Services wie Snowball oder Snowmobile verwenden, um eine initialen Datenbestand in Petabyte-Größe initial in die Cloud zu bekommen.

Im Rahmen einer Data-Lake-Strategie ist dies sicherlich nur der Anfang. Weitere Daten werden dem Data Lake dynamisch hinzugefügt. Soll/muss dies in Echtzeit erfolgen, ist eine verwaltete Streaming-Lösung wie AWS Kinesis eine gute Wahl. Zuvor aber noch ein paar Gedanken zu AWS S3.

Metadaten

AWS S3 ist als Objektspeicher per se erst einmal ein „dummer“ Speicher. Da S3 kein Dateisystem zugrunde liegt, das als Vehikel zum Speichern/Zuordnen von Meta-Informationen dienen könnte, muss sich der S3-Nutzer selbst um das Anreichern des Datenspeichers mit Meta-Informationen kümmern.

AWS S3 verwaltet dazu für jedes in einem Bucket gespeicherte Objekt einen Satz Systemmetadaten und verarbeitet diese Systemmetadaten nach Bedarf, wie z. B. das Erstellungsdatum eines Objekts und seine Größe. Diese Informationen dienen der Objektverwaltung.

Es gibt allerdings zwei Kategorien von Systemmetadaten: Metadaten wie das Erstellungsdatum eines Objekts werden vom System gesteuert, d. h. nur Amazon S3 selbst kann den betreffenden Wert ändern. Beispiele für steuerbare Meta-Informationen sind z. B. die für das Objekt konfigurierte Speicherklasse oder ob für das Objekt eine serverseitige Verschlüsselung aktiviert ist.

Ist ein Bucket beispielsweise als statische Website konfiguriert, ist die Webseite ein Objekt im Bucket. Möchte der Nutzer beispielsweise irgendwann den Zugriff auf eine andere Seite oder zu einer externen URL umleiten, speichert S3 den Wert für die Seitenumleitung ebenfalls als Systemmetadaten.

Erstellt der Nutzer neue Objekte, kann er die Werte dieser Systemmetadaten konfigurieren oder sie nach Bedarf aktualisieren. Folgende Tabelle zeigt eine Auswahl möglicher Metadaten, ergänzt jeweils im einen Hinweis auf die „Steuerbarkeit“ durch den Benutzer.

Name Beschreibung Nutzer kann Wert ändern?
Datum Aktuelles Datum und Uhrzeit. Nein
Content-Length Objektgröße in Bytes. Nein
Letzte Änderung Datum, zu dem das Objekt erstellt wurde, oder das letzte Änderungsdatum, je nachdem, welcher Wert der neueste ist. Nein
Inhalt-MD5
Der base64-verschlüsselte 128-Bit-MD5-Digest des Objekts. Nein
x-amz-server-side-encryption Gibt an, ob die serverseitige-Verschlüsselung für das Objekt aktiviert ist, und ob diese Verschlüsselung vom AWS Key Management Service (SSE-KMS) oder vom AWS-Managed Encryption (SSE-S3) stammt. Ja
x-amz-version-id Objektversion. Wenn Sie das Versioning für einen Bucket aktivieren, weist Amazon S3 allen Objekten, die dem Bucket hinzugefügt werden, eine Versions-ID zu. Nein
x-amz-delete-marker In einem Bucket, für den das Versioning aktiviert ist, gibt dieses Boolesche Kennzeichen an, ob das Objekt eine Löschmarkierung ist. Nein
x-amz-storage-class Speicherklasse, die für die Speicherung des Objekts verwendet wird. Ja
x-amz-website-redirect-location Leitet Anfragen für das jeweilige Objekt auf ein anderes Objekt im selben Bucket oder zu einer externen URL um.
Ja
x-amz-server-side-encryption-aws-kms-key-id Wenn die x-amz-serverseitige-Verschlüsselung vorhanden ist und den Wert von aws:kmsbesitzt, handelt es sich um die ID des AWS Key Management Service (AWS KMS)-Hauptschlüssels, der für dieses Objekt verwendet wurde. Ja
x-amz-server-side-encryption-customer-algorithm Gibt an, ob die serverseitige Verschlüsselung mit vom Kunden bereitgestellten Verschlüsselungsschlüsseln (SSE-C) aktiviert ist.
Ja

In Python ist es vergleichsweise einfach, auf S3-Metadaten zuzugreifen bzw. diese zu verändern:

key.put(Metadata={'meta1': 'Das ist meine Metadaten-Wert'})
print(key.metadata['meta1'])

Angenommen Sie arbeiten in Python mit S3-Objekten, die bekanntlich durch ihren Object-Key im betreffenden Bucket identifiziert werden. Im folgenden Beispiel ist die S3-Versionierung aktiv, es gibt also Revisionen jedes Objektes. Sie können wie folgt sämtliche Object-Keys abrufen und aus den Objekt-Metadaten den Typ „revisions“ extrahieren.

backups = {}
for key in bucket:
key = bucket.get_key(key.name)
backups[key.name] = key.get_metadata('revision')

Darüber hinaus braucht man im Rahmen einer Data-Lake-Strategie vor allem „inhaltsbezogene“ Meta-Daten, denn ohne einen vernünftigen Index, weiß am Ende niemand mehr, welche Daten im Data Lake gespeichert sind, sodass man auch nicht nach ihnen suchen kann.

Um dies Problem zu lösen, kann man sich die Benachrichtigungsfunktion von S3 zunutze zu machen. Diese erlaubt es nicht nur dem Benutzer, sich benachrichtigen zu lassen, wenn ein neues Objekt hochgeladen oder gelöscht wird, sondern kann z. B. auch einen automatisierten Eintrag in einer DynamoDB-Table erzeugen (Index) oder eine beliebige andere Lambda-Funktionen zur Erweiterung der Intelligenz des Datalakes anstoßen.

Man könnte sogar noch einen Schritt weiter gehen und Suchfelder aus den Daten extrahieren, die man z. B. in AWS Elastic Search zugänglich macht, um die Suchfelder mit einer Volltextsuche durchsuchen zu können. Bevor wir das im nächsten Teil dieses Workshops tun, noch ein paar Worte zur Sicherheit.

Sicherheit im Data Lake

Auch die Sicherheits- und Privacy-Anforderungen an ein Data Lake erfüllt AWS S3 zusammen mit weiteren AWS Services wie AWS Cloud Trial und AWS Config in besonderer Weise. Hier geht es primär um die Frage, wer Zugriff auf welchen Daten bekommt.

Darüber hinaus kann S3 alle Objekte wie oben erwähnt transparent serverseitig verschlüsseln, wobei z. B. AWS KMS die Schlüssel dazu erstellt und verwaltet. Der Dienst AWS Config kann dann überprüfen bzw. erzwingen, dass Objekte auch tatsächlich verschlüsselt abgelegt werden.

AWS-Konfigurationsregeln helfen dabei sicherzustellen, dass bestimmte Sicherheitsvorgaben auch eingehalten werden.
AWS-Konfigurationsregeln helfen dabei sicherzustellen, dass bestimmte Sicherheitsvorgaben auch eingehalten werden.
(Bild: Drilling / AWS)

Hierzu kommt eine so genannte AWS-Config-Regel zum Einsatz. Diese überprüft z. B. kontinuierlich, ob die gewünschten Konfigurationsregeln wie z. B. die Verwendung der Server-seitigen S3-Verschlüsselung auch eingehalten werden und setzt bei einer Verletzung eine Benachrichtigung ab.

Mit Cloud Trial schließlich können Data-Lake-Admins Nutzungsaktivitäten im AWS Konto verfolgen, da Cloud Trail jeden API Call loggt. So ist z. B. schnell erkennbar ist, wer wann auf welchen Objekt zugegriffen hat oder wer die Sicherheitseinstellungen eines S3-Buckets geändert hat. Alle Dienste sind über IAM miteinander integriert, sodass sich die Zugriffsberechtigungen auf die Daten sehr fein regeln und Nutzer auf sich auf Wunsch auch mit einem gehosteten oder (on premise) bestehenden AD integrieren lassen.

Apropos serverseitige S3-Verschlüsslung. Nutzer haben 3 Möglichkeiten diese mehr oder weniger transparent zu nutzen wahlweise mit von S3 selbst erstellten Keys oder mit Hilfe von AWS KMS, wobei KMS erlaubt, wahlweise eigene AES-Keys hochzuladen oder Key-Management-Schlüssel für die S3-Verschlüsselung zu generieren.

In diesem läge der „Root-of-Trust“ zwar immer noch bei AWS, allerdings wird die Schlüsselerstellung und Verwaltung mit KMS auditierbar, da man schnell erkennt, wer wann welche Schlüssel verwendet hat. Schließlich ermöglicht AWS mit dem Dienst AWS Cloud HSM auch noch einen von AWS verwalteten Zugriff auf ein Hardware Security Modul von Safenet Luna, um Schlüssel hardwaregestützt erstellen und verwalten zu können.

Nicht zuletzt ist es – ausreichend Kenntnisse mit den verfügbaren AWS-SDKs vorausgesetzt – möglich, dass Unternehmen ein Self Service Discovery mit einer eigenen API implementieren. Dieses könnte externen Nutzern einen kontrollierten aber temporären Zugriff auf die Daten und den Index z. B. über den Security Token Service (STS) ermöglichen.

Anwender müssen dann über ein Portal einen Request erstellen, um zeitlich beschränkten Zugriff auf eine definierte Menge an Daten zu erhalten, sofern der Zugriff genehmigt wurde. Mit Hilfe solcher Aproval-Prozesse lässt sich über die STS-API und die jeweiligen SDKs auch aus einer eigens dazu erstellten Anwendung fein granular steuern, wer wann auf welche Daten zugreifen darf. Das Anbieten solcher generischen APIs für entsprechende Dienste vereinfacht die Integration zu anderen Services.

(ID:45673085)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist