Unveränderliche Backups gegen Ransomware
Wie schützen Sie die Backups Ihres Unternehmens mit unveränderlichem Objektspeicher vor Ransomware?
Unveränderlicher Objektspeicher schützt Backups vor Ransomware, indem er sie unlöschbar macht. Wenn für einen Bucket eine Objektsperre festgelegt ist, verweigert die Speicherschicht jede Lösch- oder Überschreibanforderung, bis der Aufbewahrungszeitraum abgelaufen ist, einschließlich Anforderungen mit gültigen Administrator-Anmeldeinformationen.
Warum Backups das erste Ziel moderner Ransomware sind
Das gezielte Angriffsmuster: Verschlüsseln oder Löschen der Backups, dann der Produktion
Moderne Ransomware-Betreiber haben ihr Playbook professionalisiert. Bevor sie die Verschlüsselungs-Payload in der Produktion auslösen, verbringen Angreifer Tage damit, das Netzwerk auf der Suche nach Lücken in der Netzwerksicherheit zu kartieren: Identifizierung des Backup-Servers, der Anmeldeinformationen der Mitarbeiter und der in Skripten hinterlassenen Passwörter sowie der Zugriffsrichtlinie, die jedes Repository schützt. Sobald sie Zugriff erlangen und in Position sind, deaktivieren oder löschen sie zuerst diese Kopien und verschlüsseln dann die Produktionsdaten.
Die Reihenfolge ist bewusst gewählt. Ein Unternehmen, das innerhalb weniger Stunden wiederherstellen kann, hat kaum einen Anreiz zu zahlen; eines, dessen Kopien Tage zuvor gelöscht wurden, hat diese Option nicht, und darauf setzt der Angreifer. Bei einem Angriff dieser Art geht es nicht nur um die Verschlüsselung von Daten, sondern darum, jeden Wiederherstellungspfad zu entfernen, den ein Unternehmen hat.
Deshalb ist ein einzelner kompromittierter Anmeldeinformationssatz heute das größte Risiko in einer Schutzstrategie. Zugriffskontrolle sowie Ihre Identitäts-, Sicherheits- und Betriebsschutzmaßnahmen sind die erste Verteidigungslinie, aber Hacker und unbefugte Zugriffsversuche hören dort nicht auf: Ein Konto mit Schreibzugriff auf einen Storage-Bucket kann innerhalb von Minuten jedes Objekt und jedes Aufbewahrungsdatum löschen, es sei denn, etwas in der Speicherschicht selbst verweigert diese Anweisung.
Schließen Sie den Zugangspfad: MFA, Phishing-Sensibilisierung und Wiederherstellungstests
Unveränderlichkeit schützt die Kopie, aber sie schützt nicht die Tür, durch die der Angreifer gekommen ist. Fast jeder Vorfall beginnt mit einem gestohlenen Anmeldeinformationssatz, und Phishing bleibt die häufigste Übermittlungsmethode, meist eine E-Mail, die routinemäßig aussieht. Drei Kontrollen sind rund um die Speicherschicht selbst wichtig.
Verlangen Sie MFA für die Speicherkonsole und für jedes Konto, das eine Aufbewahrungsrichtlinie ändern kann. Die Multi-Faktor-Authentifizierung ist hier die wertvollste Kontrolle überhaupt, da MFA den Schritt der Wiederholung von Anmeldeinformationen unterbricht, von dem Cyberangriffe dieser Art abhängen, und MFA auf der Konsole ist schnell eingeführt. Bewahren Sie Dienst-Anmeldeinformationen in einem Passwort-Manager auf, nicht in Skripten, und überprüfen Sie, ob die Passwortrotation tatsächlich stattfindet. Führen Sie regelmäßige Schulungen für Mitarbeiter zu verdächtigen E-Mails und Passwort-Managern durch, damit ein Mitarbeiter, der eine solche erhält, sie meldet, anstatt sie zu öffnen. Mitarbeiter, die das Bedrohungsmodell kennen, sind eine billigere Verteidigung als jedes Produkt, und Bedrohungen, die einen informierten Mitarbeiter erreichen, stoppen dort normalerweise, und ein Mitarbeiterbericht ist oft das früheste Signal, das ein Mitarbeiter Ihnen gibt. Und führen Sie regelmäßig einen Wiederherstellungstest durch: Der einzige Weg, einen defekten Wiederherstellungspfad zu identifizieren, besteht darin, ihn zu testen, bevor ein Vorfall dies tut. Verfolgen Sie auch Löschversuche im Bucket: Ein Anstieg abgelehnter Löschungen ist ein zuverlässiges frühes Signal dafür, dass Anmeldeinformationen kompromittiert wurden. Verfolgen Sie auch Richtlinienaktualisierungen, da Aktualisierungen der Aufbewahrungsfristen das sind, was ein Angreifer zuerst versucht.
Nichts davon ersetzt die Netzwerksegmentierung oder den Endpunktschutz auf der Produktionsseite, und es ist kein vollständiges Cybersicherheits-Framework. Es ist die Ebene, die verhindert, dass ein einzelnes kompromittiertes Mitarbeiterkonto zu einem unternehmensweiten Ausfall wird.
Cyber-Versicherungen und Audits erfordern jetzt nachweisbare unveränderliche Kopien
Versicherer, die Cyber-Policen verlängern, stellen jetzt direkte Fragen: Sind diese Kopien unveränderlich, sind sie logisch von der Produktion isoliert und können Sie einen erfolgreichen Wiederherstellungstest nachweisen? Unternehmen, die dies nicht mit Nachweisen beantworten können, müssen mit höheren Prämien oder einer Ablehnung der Police rechnen. Die meisten Unternehmen entdecken dies erst bei der Verlängerung, nicht vorher. Der erste Schritt besteht darin, Ihre Backup-Wiederherstellungsprozesse zu etablieren und zu dokumentieren, dann regelmäßige Wiederherstellungstests und eine laufende Überwachung durchzuführen, um sicherzustellen, dass sie bei Änderungen Ihrer Umgebung weiterhin funktionieren.
Compliance-Anforderungen haben sich in die gleiche Richtung entwickelt, ebenso wie Fragebögen zur Datensicherheit von Kunden. Ob es sich um ISO 27001-Kontrollen, branchenspezifische Audits oder die eigene Risikobewertung eines Kunden handelt, „wir haben Backups“ ist keine akzeptable Antwort mehr. Jede Organisation, die mit modernen Cyberangriffsbedrohungen konfrontiert ist, muss zunehmend nachweisen, dass eine Backup-Kopie für einen definierten Aufbewahrungszeitraum nicht geändert oder gelöscht werden kann, unabhängig davon, welche Mitarbeiter oder Konten dies versuchen.
Dieser Nachweis ist wichtig, da ein unveränderliches Backup die Wahrscheinlichkeit messbar verringert, dass ein kompromittierter Anmeldeinformationssatz sowohl die Produktion als auch deren Wiederherstellungspfad zerstört. Die Messlatte hat sich von „ein Backup existiert“ zu „wir können einen Wiederherstellungspfad nachweisen, den ein Angreifer nicht einfach zerstören kann“ verschoben.
Das 3-2-1-Prinzip und warum die unveränderliche Kopie diejenige ist, die Sie rettet
Drei Kopien, zwei Medientypen, eine extern (und eine unveränderlich)
Die 3-2-1-Regel, drei Kopien auf zwei Medientypen, von denen eine extern gelagert wird, bildet seit einem Jahrzehnt die Grundlage für den Datenschutz, und die Logik dahinter ist stichhaltig: Wenn ein System oder ein Standort ausfällt, bleibt ein anderer Weg bestehen.
Ransomware ändert diese Kalkulation. Wenn ein Angreifer über dieselben Anmeldedaten oder denselben Netzwerkpfad auf jede Kopie zugreifen kann, schützt „extern“ allein Ihr Unternehmen nicht; es verlagert das Risiko lediglich an einen anderen Ort. Deshalb behandeln viele Unternehmen und Backup-Teams die Regel heute als 3-2-1 plus eine unveränderliche Kopie: ein Backup, das selbst dann überlebt, wenn der Rest der Umgebung kompromittiert wurde.
Was „unveränderlich“ auf der Objektspeicherebene tatsächlich bedeutet
Unveränderlichkeit ist keine Einstellung in Ihrer Software, sondern eine Garantie, die durch die Speicherebene erzwungen wird. Wenn Object Lock aktiviert ist und eine Aufbewahrungsfrist festgelegt wurde, verweigert das System bis zum Ablauf dieser Frist jegliches Löschen oder Überschreiben, auch bei Anfragen mit gültigem Administratorzugriff.
Es spielt keine Rolle, ob die Anfrage ein gültiges Mitarbeiterpasswort, ein kompromittiertes Konto oder die Ransomware-Payload selbst verwendet: Das System lässt die Änderung aufgrund seines Designs nicht zu. Dies schützt die Kopie vor genau der Technik, auf die diese Malware setzt: die Nutzung gestohlener Zugriffsrechte, um alles zu modifizieren oder zu löschen, was sie erreichen kann.
Drei Möglichkeiten für Backups auf OVHcloud Object Storage
Für Unternehmen, die ein zuverlässiges, souveränes Objektspeicherziel (S3-kompatibel)* für ihre Aufbewahrungsstrategie wünschen, bietet OVHcloud Backup-Teams drei praktische Wege, je nachdem, ob sie eine verwaltete Option, einen Do-it-yourself-Workflow oder die Integration in eine bestehende Plattform bevorzugen.
Verwaltet OVHcloud-native Instance, Volume und Databases Backup
Für Public-Cloud-Workloads schreiben die nativen Dienste von OVHcloud – Instance Backup, Volume Backup und Databases Backup – direkt in den Objektspeicher, ohne dass eine S3-Pipeline erstellt oder gewartet werden muss. Dieser Weg eignet sich für Teams, die eine Absicherung mit minimalem betrieblichem Aufwand wünschen. Wenn Ihre Workloads auf Kubernetes laufen, erstreckt sich derselbe Schutz auf persistente Volumes über den Managed Kubernetes Service. Die Steuerungsebene, einschließlich etcd, wird von OVHcloud verwaltet und muss daher nicht von Ihrem Team gesichert werden.
Bauen Sie es selbst mit der S3-API (awscli, Rclone, Plakar, Restic, Duplicati)
Teams mit S3-Erfahrung können ihre eigene Pipeline mit Standard-Tools an einen Bucket anbinden: awscli oder die AWS SDKs für skriptbasierte Jobs, Rclone für Synchronisierungs-Workflows oder Open-Source-Tools wie Plakar, Restic, Duplicati und viele andere für deduplizierte, verschlüsselte Kopien. Plakar ist eine souveräne Open-Source-Option ohne Abhängigkeit von den Tools eines einzelnen Anbieters. Da die S3-API der kleinste gemeinsame Nenner ist, testen Sie lokal und gehen mit nur einer Änderung des Endpunkts in die Produktion.
Bringen Sie Ihr vorhandenes Tool mit: Veeam, HYCU, Cohesity, Veritas NetBackup, CloudCasa und viele andere Tools.
Die meisten Unternehmensumgebungen betreiben bereits eine Schutzplattform. OVHcloud Object Storage ist Veeam Ready-zertifiziert, wobei HYCU, Cohesity und Veritas NetBackup ebenfalls kompatibel sind. Für Kubernetes unterstützen sowohl Velero als auch CloudCasa Object Storage als Ziel über die S3-API. Unveränderlichkeit wird im Tool für den Bucket konfiguriert, sodass der Schutz auch dann besteht, wenn die Anwendung kompromittiert ist: Die Speicherschicht erzwingt die Aufbewahrung unabhängig.
Der Vier-Schichten-Schutz, der für alle drei Pfade gilt
Egal für welchen Pfad Sie sich entscheiden, das Sicherheitsmodell bleibt gleich: Machen Sie die Kopie unlöschbar, bewahren Sie eine saubere Historie, isolieren Sie sie an einem zweiten Standort und schützen Sie sensible Daten sowie deren Vertraulichkeit. Diese Sicherheitsmaßnahmen wirken zusammen, um zu verhindern, dass ein einzelnes kompromittiertes Mitarbeiterkonto Ihren gesamten Wiederherstellungspunkt zerstört.
Object Lock (WORM): für die Aufbewahrungsfrist nicht löschbar
Object Lock macht ein gespeichertes Objekt zu etwas, das bis zum Ablauf seiner Aufbewahrungsfrist nicht gelöscht oder überschrieben werden kann, selbst von einem Konto mit Administratorzugriff. Sobald Object Lock aktiviert ist, ist es für diesen Bucket konzeptbedingt unwiderruflich, was es auch vor einem Insider schützt. Legal Hold fügt eine unbefristete Sperre für bestimmte Objekte hinzu, was nützlich ist, wenn eine Reihe von Dateien über den Standardzeitraum hinaus aufbewahrt werden muss. Diese Kontrolle macht Unveränderlichkeit real statt theoretisch, und Ihr Incident-Response-Plan sollte sie nach Bucket und Aufbewahrungsfrist dokumentieren.
Versioning: Bewahren Sie eine saubere Historie jedes Objekts auf
Versioning bewahrt jede frühere Version einer Datei auf, anstatt sie direkt zu ersetzen, sodass eine beschädigte Datei niemals ihre eigene Historie überschreibt. Wenn eine Datei überschrieben oder geändert wird, bevor die Sperre wirksam wird, bleibt eine frühere saubere Version dieser Datei verfügbar, Datei für Datei, was eine Wiederherstellung auf Dateiebene überhaupt erst möglich macht. Versioning ist erforderlich, damit Object Lock korrekt funktioniert; aktivieren Sie daher beides bei der Bucket-Erstellung. Es schützt auch vor menschlichem Versagen und versehentlichem Löschen durch Mitarbeiter in der Backup-Pipeline selbst, nicht nur vor Ransomware.
S3 Async Replication: eine isolierte Kopie in einer zweiten Region
S3 Async Replication erstellt eine automatisierte Kopie des Buckets in einer separaten OVHcloud-Region, unabhängig von den primären Anmeldedaten, sofern der Zugriff nicht explizit gewährt wurde. Das bietet die isolierte externe Kopie, die 3-2-1 erfordert, ohne manuellen Transfer. In Kombination mit Object Lock müsste ein Angreifer über Anmeldedaten in zwei Regionen verfügen, um jede Kopie zu erreichen.
Verschlüsselung im Ruhezustand: SSE-C und SSE-OVHcloud Managed Keys
Verschlüsselung im Ruhezustand schützt die Vertraulichkeit sensibler Dateien, falls die Speicherebene jemals von einem Außenstehenden erreicht wird, und Verschlüsselung bei der Übertragung sichert sie auf dem Weg dorthin von Ihren Anwendungen und Datenbanken, unabhängig davon, ob die Pipeline lokal oder von einer entfernten Region aus ausgeführt wird. OVHcloud Object Storage unterstützt SSE-C, bei dem Sie den Verschlüsselungsschlüssel verwalten, und SSE-OVHcloud Managed Keys, bei dem OVHcloud den Lebenszyklus des Schlüssels verwaltet, was Ihnen in jedem Fall eine sichere Option bietet und eine häufige Schwachstelle in DIY-Pipelines schließt. Die Integration mit dem Key Management Service zur unabhängigen Kontrolle des Schlüsselmaterials steht auf der Roadmap für Object Storage, planen Sie also vorerst mit SSE-C. Diese Ebene befasst sich eher mit Vertraulichkeit als mit Unveränderlichkeit, ist aber dennoch wichtig, da Datenschutzverletzungen danach beurteilt werden, was lesbar war: verschlüsselte Objekte sind für einen Angreifer weitaus weniger nützlich als lesbare.
Für regulierte Umgebungen über 5 TiB oder wenn Sie eine zweite Meinung zum Design von Aufbewahrung und Replikation wünschen, kann ein Solutions Architect Ihre Architektur überprüfen, ein Referenzdesign teilen und Ihnen helfen, die Aufbewahrungsrichtlinie zu sichern, nach der ein Prüfer fragen wird, und bestätigen, dass sie Ihrem Wiederherstellungsziel entspricht.
Wiederherstellung ohne zweiten Treffer
11 Neunen Dauerhaftigkeit und eine 99,99 % Verfügbarkeits-SLA bei 3-AZ
Ein Backup, das Sie nicht schnell wiederherstellen können, ist wenig nützlich. Die gesamte OVHcloud Object Storage-Infrastruktur ist auf eine Dauerhaftigkeit von elf Neunen (99,999999999 %) ausgelegt, nicht nur die 3-AZ-Regionen, sodass Datenverlust durch Hardwareausfälle überall dort, wo sich die Kopie befindet, außerordentlich unwahrscheinlich ist. Die 99,99 % Verfügbarkeits-SLA gilt für den 3-AZ-Bereitstellungsmodus. Administratoren benötigen das Wiederherstellungsziel, wenn ein Sicherheitsvorfall eintritt, nicht nur den Nachweis, dass die Daten zuvor sicher waren. Dies ist auch die Dimension, die Kunden am höchsten bewerten: Stabilität mit 4,51/5 und Verfügbarkeit mit 4,50/5 in NPS-Scores.
Keine Egress-Gebühren bei der Wiederherstellung zwischen OVHcloud-Diensten
Die Wiederherstellung eines großen Datenvolumens nach einem Vorfall sollte keine unvorhersehbare Rechnung zu einem ohnehin schon kostspieligen Ereignis hinzufügen. Es fallen keine Egress-Gebühren zwischen OVHcloud-Diensten an. Die Wiederherstellung auf einer Public Cloud-Instanz, einem Bare Metal-Server oder einer anderen OVHcloud-Ressource verursacht daher keine separaten Übertragungskosten, und die Kosten für eine Wiederherstellung bleiben vorhersehbar. Das macht die Wiederherstellung einfacher planbar, wenn es auf Zeit ankommt.
Staffeln Sie Ihre Aufbewahrung zur Kostenkontrolle: Standard → Active Archive → Cold Archive
Nicht jede Kopie benötigt dieselbe Speicherklasse für denselben Zeitraum. Lifecycle-Richtlinien verschieben Objekte von Standard in Active Archive für die mittelfristige Aufbewahrung und dann in Cold Archive für die regulatorische Aufbewahrung, während Object Lock für jede Klasse in Kraft bleibt.
Active Archive kostet etwa 4,5 € pro TiB und Cold
Archive etwa 1,7 € pro TiB; beide liegen weit unter dem Standard für Daten, die Sie selten wiederherstellen. Diese Staffelung ermöglicht es Ihrem Unternehmen, eine mehrjährige, unveränderliche Aufbewahrungsrichtlinie für Compliance-Zwecke beizubehalten, die den meisten Branchenanforderungen entspricht, ohne die ganze Zeit Premium-Speicherraten zu zahlen. Überprüfen und aktualisieren Sie die Lifecycle-Richtlinie regelmäßig, wenn sich Aufbewahrungsanforderungen oder Datenvolumina ändern.
Datensouveränität und Compliance: DSGVO, HDS, ISO 27701, keine CLOUD Act-Exposition
Backup-Daten enthalten oft einige der wertvollsten und sensibelsten Informationen eines Unternehmens: Datenbank-Dumps, Anwendungsstatus, geistiges Eigentum, vollständige System-Snapshots und manchmal personenbezogene Daten, die unter die DSGVO fallen. Wo diese Daten gespeichert sind und welche Rechtsordnung gilt, ist wichtig für die digitale Souveränität, den Datenschutz und für branchenspezifische Anforderungen wie HDS oder ISO 27701, auch für Betreiber kritischer Infrastrukturen und regulierte Branchen.
OVHcloud Object Storage wird in europäischen Rechenzentren gehostet und betrieben, ohne CLOUD Act-Exposition, da OVHcloud kein Unternehmen ist, das den Offenlegungspflichten dieses Gesetzes unterliegt. Zu den aktuellen Zertifizierungen gehören ISO 27001, 27017, 27018 und 27701 für das Datenschutzmanagement; die SecNumCloud-Qualifizierung für Object Storage ist geplant. Dadurch wird dieser Speicher zu einem Teil des umfassenderen Risikomanagements, der Compliance-Strategie und des Geschäftsbetriebs des Unternehmens und nicht nur zu einem operativen Hilfsmittel.
Erste Schritte: 200 € Testguthaben, der Backup-Hub und ein Solutions Architect
Erstellen Sie ein Public Cloud -Projekt, aktivieren Sie Object Lock und Versionierung für einen neuen Bucket, verweisen Sie dann Ihr vorhandenes Tool auf den Endpunkt und führen Sie einen echten Job aus. Ein Testguthaben von 200 € deckt diesen Test und die Wiederherstellung ab, die dessen Funktionalität belegt. Für regulierte Daten oder ein Multi-Region-Replikationsdesign kontaktieren Sie bitte einen Solutions Architect. Die Seite Object Storage und der Hub Identity, Security & Operations decken den Rest ab.
* S3 ist eine eingetragene Marke von Amazon Technologies, Inc. OVHcloud Dienste werden in keiner Weise von Amazon Technologies, Inc. gesponsert oder befürwortet und stehen auch nicht mit dem Unternehmen in Verbindung.