Skip to main content
How to enable StorageGRID in your environment
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Ransomware-Verteidigung durch replizierten Bucket mit Versionierung

Beitragende
PDFs

Erfahren Sie, wie Sie Objekte mit StorageGRID CloudMirror in einen sekundären Bucket replizieren.

Nicht alle Applikationen und Workloads werden mit Objektsperre kompatibel sein. Eine weitere Option besteht darin, die Objekte auf einen sekundären Bucket zu replizieren, entweder im selben Grid (vorzugsweise ein anderer Mandant mit eingeschränktem Zugriff) oder auf einen anderen S3-Endpunkt mit dem StorageGRID-Plattformservice CloudMirror.

StorageGRID CloudMirror ist eine Komponente von StorageGRID, die so konfiguriert werden kann, dass Objekte eines Buckets auf ein definiertes Ziel repliziert werden, da sie in den Quell-Bucket aufgenommen werden und Löschungen nicht repliziert werden. Da CloudMirror eine integrierte Komponente von StorageGRID ist, kann sie nicht durch einen S3-API-basierten Angriff deaktiviert oder manipuliert werden. Sie können diesen replizierten Bucket mit aktivierter Versionierung konfigurieren. In diesem Szenario benötigen Sie eine automatisierte Bereinigung der alten Versionen des replizierten Buckets, die sicher zu verwerfen sind. Dazu können Sie die StorageGRID ILM-Richtlinien-Engine verwenden. Erstellen Sie Regeln, um die Objektplatzierung auf Basis der nicht aktuellen Zeit für mehrere Tage zu verwalten, die ausreichend sind, um einen Angriff identifiziert und wiederhergestellt zu haben.

Ein Nachteil dieses Ansatzes besteht darin, dass mehr Storage verbraucht wird. Dazu ist eine vollständige zweite Kopie des Buckets und mehrere Versionen der Objekte verfügbar, die einige Zeit aufbewahrt werden. Darüber hinaus müssen die Objekte, die absichtlich aus dem primären Bucket gelöscht wurden, manuell aus dem replizierten Bucket entfernt werden. Außerhalb des Produkts gibt es weitere Replizierungsoptionen, wie z. B. NetApp CloudSync, mit denen Löschvorgänge für eine ähnliche Lösung repliziert werden können. Ein weiterer Nachteil für den sekundären Bucket, bei dem die Versionierung aktiviert und nicht die Objektsperre aktiviert ist, besteht darin, dass eine Reihe privilegierter Konten vorhanden ist, die verwendet werden könnten, um Schäden am sekundären Standort zu verursachen. Der Vorteil ist, dass es sich um ein eindeutiges Konto für diesen Endpunkt oder Mandanten-Bucket handeln sollte, und der Kompromiss wahrscheinlich keinen Zugriff auf Konten am primären Standort oder umgekehrt umfasst.

Nachdem die Quell- und Ziel-Buckets erstellt und das Ziel mit Versionierung konfiguriert wurde, können Sie die Replikation wie folgt konfigurieren und aktivieren:

Schritte

  1. Erstellen Sie zum Konfigurieren von CloudMirror einen Plattformservices-Endpunkt für das S3-Ziel.

    ransomware-Schutz – Erstellung von Endpunkten

  2. Konfigurieren Sie auf dem Quell-Bucket die Replikation zur Verwendung des konfigurierten Endpunkts.

    <ReplicationConfiguration>
    <Role></Role>
    <Rule>
        <Status>Enabled</Status>
        <Prefix></Prefix>
        <Destination>
            <Bucket>arn:aws:s3:::mybucket</Bucket>
            <StorageClass>STANDARD</StorageClass>
        </Destination>
    </Rule>
</ReplicationConfiguration>

  3. Erstellen Sie ILM-Regeln, um die Storage-Platzierung und das Versionsspeicherzeitmanagement zu managen. In diesem Beispiel werden die nicht aktuellen Versionen der zu speichernden Objekte konfiguriert.

    Erstellung einer ilm-Regel für ransomware-Schutz

    ransomware-Protection-create-ilm-rule-Step-2

    An Standort 1 sind 30 Tage lang zwei Kopien vorhanden. Sie konfigurieren außerdem die Regeln für die aktuelle Version der Objekte basierend auf der Verwendung der Aufnahmezeit als Referenzzeit in der ILM-Regel, um der Speicherdauer des Quell-Buckets anzupassen. Die Storage-Platzierung für die Objektversionen kann Erasure Coded oder repliziert werden.