Wie sicher sind Objektspeicher?

Fachartikel

Objektspeicher erfreut sich immer größerer Beliebtheit – und das nicht ohne Grund. Besonders die S3 API ist ein sehr geschätztes Merkmal. Der Simple Storage Service, kurz S3, wird seinem Namen gerecht und vereinfacht die Anwendungsentwicklung deutlich. Object Storage eignet sich für die Speicherung größter Datenmengen. Er zeichnet sich dabei durch die enorme Skalierbarkeit, einen attraktiven Preis pro GB und die Hochverfügbarkeit aus. Letztere wird von den Speicherherstellern oder Cloudanbietern gerne als Prozentzahl angegeben, die die verfügbare Betriebszeit ausdrückt. Eine Verfügbarkeit von 99,9 % beispielsweise erlaubt eine maximale Ausfallzeit von 8:45:58 Stunden pro Jahr.

Die hohe Verfügbarkeit erreichen Systeme durch redundante Komponenten, Erasure Coding und Replikation. Doch trotz beeindruckender Prozentangaben darf Hochverfügbarkeit nicht mit Datensicherheit verwechselt werden. Es schlummern viele bekannte Gefahren, die auch vor einem Objektspeicher nicht haltmachen.

Somit stellen sich die folgenden Fragen: Welche Szenarien drohen und wie sicher sind Objektspeicher?

1. Festplatten-Ausfall

Je nach Ausbaustufe sind in Objektspeichern schnell hunderte oder gar tausende Festplatten verbaut. Der Ausfall von Festplatten gehört somit zur Tagesordnung. Zum Schutz vor Datenverlust wird Erasure Coding verwendet. Damit fallen die Wiederherstellungszeiten deutlich kürzer aus als bei einem klassischen RAID. Wie viele Festplatten gleichzeitig ausfallen dürfen, hängt von der eingestellten Erasure Coding Rate ab und wird letztlich durch einen höheren Overhead bezahlt.

Als Alternative zu Erasure Coding können Daten durch Replikation geschützt werden, sodass eine oder mehrere Kopien des Objektes auf verschiedenen Knoten gespeichert werden.

2. Knoten-Ausfall

Ursachen für einen Knoten-Ausfall können ganz unterschiedlich sein. So kann zum Beispiel eine getrennte Netzwerkverbindung der Grund sein, die Stromversorgung kann unterbrochen sein, oder ein Hardwaredefekt führt zum Stillstand des Knotens. Dank Erasure Coding bzw. Replikation kann der Betrieb fortgesetzt werden. Gerade kleine Installationen mit wenigen Knoten haben hier eine geringe Toleranz. Ist der Ausfall unwiederbringlich und fällt gleichzeitig in einem anderen Knoten eine Festplatte aus oder ein zweiter Knoten versagt, kann dies Datenverlust bedeuten. Daher ist die jeweils minimal mögliche Knotenanzahl mit Vorsicht zu genießen.

3. Rack-Ausfall

Je nach Objektspeicher kann bei der Einrichtung der RZ-Aufbau berücksichtigt werden, sodass der Ausfall eines Racks den Betrieb nicht beeinflusst. Separate Brandabschnitte können somit die Gefahr eines vollständigen Standort-Ausfalls verringern. Auch hier kommen Erasure Coding oder Replikation zum Tragen.

4. Standort-Ausfall

Viele Unternehmen verfügen über zwei Rechenzentren, die sie in einem Aktiv/Aktiv- oder Aktiv/Passiv-Aufbau betreiben, um auch bei einem vollständigen Standort-Ausfall den IT-Betrieb aufrechtzuerhalten. Während bei zwei Standorten eine Replikation für die redundante Speicherung sorgt, kann bei drei oder mehr Standorten das Erasure Coding seine Stärken ausspielen und den Storage Overhead niedrig halten.

5. Softwarefehler

Trotz höchster Verfügbarkeit können Softwarefehler im Objektspeicher einen Datenverlust zur Folge haben. Unternehmen können sich durch eine Datenkopie auf einem separaten und unabhängigen System schützen, das idealweise auf eine andere Speichertechnologie setzt als das primäre System. Besonders wirtschaftlich ist der Einsatz der Tape-Technologie.

Das PoINT Archival Gateway ist eine Lösung, die alle Vorteile eines S3 Objektspeichers bietet, jedoch die Daten nicht auf Festplatten oder SSDs, sondern auf Tape speichert. Somit eignet sich das PoINT Archival Gateway hervorragend als Replikationsziel oder Backupspeicher für den primären Objektspeicher. Außerdem ist ein oft geforderter Medienbruch realisiert, und das Format bleibt dennoch erhalten: Objekte werden als Objekte gespeichert und lassen sich via S3 abrufen.

6. Versehentliches oder böswilliges Löschen

Eine simple S3 Operation genügt, um in einem Rutsch bis zu 1000 Objekte zu löschen, vorausgesetzt man verfügt über die notwendigen Berechtigungen oder hat sich den Zugriff erschlichen. Eine standortübergreifende Spiegelung oder Erasure Coding helfen in diesem Fall nicht. Eine Hürde stellt Versionierung dar, insofern der verwendete Object Storage diese Option bietet. MinIO beispielsweise unterstützt Versionierung nicht.

Ist Versionierung auf dem Bucket aktiviert, wird ein Objekt nicht tatsächlich gelöscht, sondern es wird ein Delete-Marker gesetzt. Zu erkennen ist dies in der entsprechenden Antwort auf den Löschbefehl, die ein <DeleteMarker>true</DeleteMarker> enthält. Löscht man den Delete-Marker, ist das ursprüngliche Objekt wieder sichtbar. Wird jedoch gezielt eine Version eines Objektes gelöscht, stellt Versionierung kein Hindernis dar. Hierzu wird in der Löschoperation die gewünschte Versions-ID des Objektes mit angegeben. Nach S3 API Referenz kann ein Bucket nur gelöscht werden, wenn er leer ist. Dennoch lassen sich per Knopfdruck ganze Buckets inkl. Objekten und trotz aktivierter Versionierung löschen. Zunächst fragt man eine Liste aller Objektversionen ab, löscht dann in einer Schleife jede Version und entfernt schließlich noch das leere Bucket. Ein Schutz durch Versionierung ist daher nur bedingt gegeben.

Was auf der einen Seite sehr praktisch ist, kann andererseits die S3 Rechnung in die Höhe schnellen lassen. Jede Objektversion belegt Speicherplatz und verursacht entsprechende Kosten. Wer Versionierung nutzt, sollte überlegen, vorherige Versionen auf einen günstigeren Speicher zu verlagern. NetApp StorageGRID oder Cloudian HyperStore beispielweise erlauben es, über ihr integriertes ILM bzw. Storage Tiering eine Regel für „Non-Current“-Objektversionen zu erstellen. In Kombination mit dem PoINT Archival Gateway landen alte Versionen dann auf Tape.

Wer bei AWS die Multi-Factor Authentication (MFA) nutzt, erschwert böswillige Löschaktionen. Ohne die Übermittlung eines zusätzlich generierten Authentifizierungscodes können weder Objekte gelöscht, noch kann der Versionierungsstatus des Buckets geändert werden. Es hängt natürlich stark vom Anwendungsfall ab, ob sich MFA in den Workflow integrieren lässt.

Eine weitere Option, um das Löschen von Objekten zu verhindern, ist WORM (Write Once Read Many). Aber auch hier gilt: Es muss zum Anwendungsfall passen. Während WORM für die langfristige Archivierung Sinn ergibt, ist es in Fällen mit hohen Änderungsraten hinderlich.

Neben Gefahren über die S3 API muss auch an die GUI oder CLI zur Administration des Object Storage gedacht werden. Wer hier root-Zugang erlangt, dem stehen alle Türen offen.

Wurden trotz aller Sicherheitsvorkehrungen Daten vom Object Storage gelöscht, hilft nur die Wiederherstellung aus einem Backup – sofern eines vorhanden ist. Denn genau dieser Punkt wird leider von Unternehmen vernachlässigt. Viele Objektspeicher bieten eine sog. Cross Region Replication (CRR) an und erlauben dabei die Angabe eines externen fremden Zielsystems, wie dem PoINT Archival Gateway. Sobald der primäre Objektspeicher ein neues Objekt erhält, löst dies eine Replikation via S3 zum PoINT Archival Gateway aus, welches die Kopie auf Tape schreibt. Löschvorgange werden nicht weitergegeben, bzw. es wird nur ein Delete-Marker gesetzt.

7. Ransomware

Seit ein paar Jahren treibt Ransomware ihr Unwesen und richtet große Schäden an. Auf infizierten Computern verschlüsselt die Schad-Software Daten. Für die Entschlüsselung fordern die Täter ein Lösegeld von den Inhabern. Auch wenn Ransomware bisher auf File Systeme abzielt, sind Objektspeicher davor nicht immun. Wie ein solcher Angriff auf Objektspeicher, in diesem Fall AWS, aussehen kann, hat Rhino Security Labs, ein Anbieter von Penetrationstests, skizziert.

AWS bietet den sogenannten Key Management Service (KMS) an, der die Verwaltung von kryptografischen Schlüsseln vereinfachen soll. So kann beispielsweise für die Verschlüsselung von S3 Objekten auf KMS zurückgegriffen werden. Interessant ist die Tatsache, dass Schlüssel AWS Account-übergreifend genutzt werden können.

Das von Rhino Security Labs entwickelte Proof of Concept sieht die folgenden Schritte vor:

  1. Der Angreifer erstellt einen KMS Schlüssel und macht diesen für andere zur Verschlüsselung verfügbar, jedoch nicht zur Entschlüsselung.
  2. Der Angreifer erlangt durch eine Sicherheitslücke Schreibzugriff auf einen Bucket seines Opfers.
  3. Der Angreifer prüft die Bucket-Konfiguration auf S3 Versionierung und MFA.
  4. Der Angreifer nutzt die S3 API, um jedes Objekt durch eine Kopie des Objektes zu ersetzen. Diese ist aber nun mit dem KMS Schlüssel des Angreifers verschlüsselt.
  5. Der Angreifer setzt einen Zeitplan für die Löschung des KMS Schlüssels.
  6. Der Angreifer lädt eine unverschlüsselte Anweisung für sein Opfer hoch.

Rhino Security Labs konnte auf diese Weise einen 100 GB großen Datensatz mit ca. 2000 Objekten in 1 Minute und 47 Sekunden verschlüsseln. Selbst wenn nur 10 Minuten vergehen, ehe eine Protokollierung Alarm schlägt und Gegenmaßnahmen ergriffen werden, sind bereits mehr als 500 GB verloren.

Am Ende gilt für File Systeme und Object Storage gleichermaßen: Die wichtigste Maßnahme im Kampf gegen Ransomware ist ein Backup der Daten.

8. Faktor Mensch

Menschen machen Fehler, und IT-Administratoren sind auch nur Menschen. Durch falsch konfigurierte S3 Buckets kommt es immer wieder zu Datenschutzverletzungen. Hier ein paar Beispiele:

Ebenso muss man mit Verschlüsselung sorgfältig umgehen. Verschlüsselung schafft Sicherheit, aber wer den Schlüssel verliert, der sperrt sich aus.

Auch an Objektspeichern sind immer wieder Wartungsarbeiten notwendig. Fehler beim Einspielen von Patches oder bei der Aktualisierung der Softwareplattform sind schnell passiert.

Fazit: Sichern Sie Ihren Objektspeicher

Ohne Zweifel sind Objektspeicher hochverfügbar. Dank Erasure Coding kann ein Objektspeicher den Ausfall von Festplatten, Knoten, Racks und sogar von Standorten überstehen.

Versionierung bietet nur einen sehr bedingten Schutz vor versehentlichem oder böswilligem Löschen. WORM und MFA erschweren dies deutlich, insofern diese Optionen für den Anwendungsfall in Frage kommen.

Objektspeicher sind nicht immun gegen Ransomware und ebenso wenig gegen menschliche Fehler.

Nicht anders als Daten in NAS- oder SAN-Infrastrukturen brauchen auch Daten auf Objektspeichern eine Sicherung. Eine Herausforderung sind allerdings die immensen Datenmengen. Zudem muss die Lösung eine rasche Wiederherstellung einzelner Objekte ermöglichen.

PoINT Software & Systems bietet mit dem PoINT Archival Gateway einen hochverfügbaren Tape-basierten Objektspeicher zur Sicherung von primären S3 Objektspeichern. Kunden können mittels Cross Region Replication (CRR) einen automatischen asynchronen Kopiervorgang einrichten, der alle neuen Objekte von ihrem festplattenbasierten Objektspeicher zum PoINT Archival Gateway sendet, das die Daten auf Tape ablegt. Durch die native S3 API ist der Zugriff auf gesicherte Objekte äußerst einfach.

Weitere Möglichkeiten bietet der „Pull“-Ansatz des PoINT Archival Gateway, der inkrementell auf Objekt-Level und herstellerunabhängig arbeitet. Für diesen Ansatz benötigt der primäre Object Storage keinen Schreibzugriff auf den Zielspeicher, was die Sicherheit erhöht. Die Daten sind somit besser abgeschottet und das PoINT Archival Gateway kann in einer stark isolierten Umgebung betrieben werden.

Wir freuen uns auf Ihr Feedback zum PoINT-Blog und zu diesem Beitrag. Kontaktieren Sie uns unter info@point-blog.de.