Warum das Aktivieren von Object Lock Ihre alten Backups möglicherweise nicht schützt
Object Lock, der Mechanismus hinter unveränderlichen Backups in Cloud-Objektspeichern, ist eine der am häufigsten missverstandenen Sicherheitskontrollen. In einem Blogbeitrag von Backblaze beschreibt Kari Wilson, Senior Product Marketing Manager bei Backblaze, die Lücke zwischen dem Umschalten eines Object-Lock-Schalters und dem tatsächlichen Schutz von Daten. Die Diskussion greift reale Probleme auf, die in technischen Gesprächen mit IT-Administratoren und Systemarchitekten auftauchen, nachdem die Dokumentation gelesen wurde, aber bevor die Konfiguration vollständig vertraut ist.
Eine der ersten Verwirrungen ist der Unterschied zwischen Unveränderlichkeit und Verschlüsselung. Verschlüsselung schützt Menschen davor, Ihre Daten zu sehen. Object Lock schützt sie davor, sie zu löschen. Ein verschlüsseltes Backup, das ein Angreifer löschen kann, ist keine Wiederherstellungsoption. Ein unveränderliches Backup, das ein Angreifer im Klartext lesen kann, ist immer noch ein brauchbarer Wiederherstellungspunkt. Beides ist wichtig, aber sie erfüllen unterschiedliche Funktionen. Sie als austauschbar zu behandeln, führt dazu, dass Organisationen Lücken in die eine oder andere Richtung haben.
Eine verwandte Sorge ist, dass unveränderliche Daten schwer wiederherzustellen sind. Das sind sie nicht. Unveränderliche Daten bleiben während des gesamten Unveränderlichkeitszeitraums vollständig lesbar und herunterladbar. Sie können daraus wiederherstellen, auf einzelne Dateien zugreifen und neue Versionen neben den geschützten hochladen. Das Einzige, was Object Lock verhindert, ist die Änderung und Löschung vor Ablauf des Unveränderlichkeitszeitraums. Das ist der ganze Sinn.
Bei Backblaze B2 kann Object Lock bei der Bucket-Erstellung aktiviert oder später zu einem bestehenden Bucket hinzugefügt werden. Einmal aktiviert, kann es nicht mehr ausgeschaltet werden, die Änderung ist also in dieser Richtung dauerhaft. Das Aktivieren von Object Lock bei einem bestehenden Bucket schützt jedoch nicht rückwirkend die bereits darin enthaltenen Dateien. Nur Dateien, die nach der Aktivierung von Object Lock in den Bucket hochgeladen oder kopiert werden, können gesperrt werden. Dateien, die vorher dort waren, sind nicht betroffen. Die praktische Konsequenz ist klar: Wenn Sie Object Lock zu einem Bucket mit bestehenden Backups hinzufügen, gehen Sie nicht davon aus, dass diese älteren Dateien jetzt geschützt sind. Neue Backups, die nach der Änderung geschrieben werden, sind geschützt, aber alles, was bereits im Bucket liegt, erfordert, dass individuelle Sperreinstellungen manuell angewendet werden.
Es gibt auch eine verbreitete Annahme, dass Unveränderlichkeit auf Bucket-Ebene konfiguriert wird. Bei vielen Backup-Anwendungen ist das nur die halbe Wahrheit. Bei der Verwendung von Veeam oder ähnlichen Enterprise-Tools verwaltet die Backup-Anwendung Object Lock auf Dateibasis. Der Bucket muss Object Lock als Funktion aktiviert haben, aber die Anwendung steuert, welche Dateien gesperrt werden und für wie lange. Stellen Sie sich die Bucket-Einstellung als das Öffnen der Tür vor; die Backup-Software entscheidet, was hindurchgeht. Beide Seiten müssen konfiguriert werden: Object Lock auf dem Bucket aktiviert und Unveränderlichkeit innerhalb der Backup-Anwendung aktiviert. Das eine ohne das andere bewirkt nichts.
Aufbewahrungszeitraum und Unveränderlichkeitszeitraum sind getrennte Einstellungen, die unabhängig voneinander funktionieren. Eine vierjährige Aufbewahrungsrichtlinie bedeutet, dass Ihre Backup-Anwendung die Daten vier Jahre lang aufbewahrt. Ein 14-tägiger Unveränderlichkeitszeitraum bedeutet, dass Dateien 14 Tage nach dem Schreiben nicht gelöscht oder geändert werden können. Nach Ablauf der 14 Tage wird die Object Lock aufgehoben. Die Datei ist immer noch da, unterliegt Ihrer Aufbewahrungsrichtlinie, ist aber nicht mehr unveränderlich. Die beiden Einstellungen müssen nicht übereinstimmen. Ein typisches Setup verwendet eine lange Aufbewahrungsrichtlinie mit einem kürzeren Unveränderlichkeitsfenster, das den Zeitraum abdeckt, in dem Ransomware oder ein böswilliger Akteur am wahrscheinlichsten versucht zu löschen.
Wie lang sollte der Unveränderlichkeitszeitraum sein? Die häufigste Empfehlung ist 7 bis 14 Tage, wobei 14 Tage ein vernünftiger Standard für die meisten Umgebungen sind. Die Logik ist, dass Sie, wenn Ransomware oder ein Angriff Ihre Umgebung trifft, innerhalb von Stunden, vielleicht ein paar Tagen, davon erfahren. Der Unveränderlichkeitszeitraum muss nicht Monate potenzieller Kompromittierung abdecken. Er muss das Fenster zwischen dem Auftreten eines Angriffs und Ihrer Erkennung und Reaktion abdecken. Sicherheitsteams, die ihre Incident-Response-Workflows getestet haben, stellen oft fest, dass 7 Tage gut funktionieren. Der Punkt ist, den Zeitraum an Ihre Erkennungsfähigkeit anzupassen, nicht ihn willkürlich zu maximieren.
Es gibt auch einen Kostenaspekt, der leicht zu übersehen ist. Jedes Mal, wenn Backup-Software eine Object Lock schreibt oder erneuert, führt sie einen PUT-Klassen-API-Aufruf durch, um die Aufbewahrungsmetadaten für dieses Objekt zu aktualisieren. Bei AWS S3 werden diese Aufrufe als Standard-PUT-Anfragen zu 0,005 $ pro 1.000 abgerechnet. In großen Umgebungen mit häufigen Backup-Jobs summieren sich diese Transaktionsgebühren. Backblaze B2 berechnet keine Gebühren für PUT-Anfragen, daher sind Lock-Schreibvorgänge und -Erneuerungen in Ihrem Speicher enthalten. In der Praxis bedeutet dies, dass kürzere Unveränderlichkeitsfenster bei B2 keine Kostenstrafe verursachen und es keinen Anreiz gibt, Lock-Erneuerungen zu minimieren, um Ihre API-Rechnung zu senken.
Wenn Sie in Veeam einen 7-tägigen Unveränderlichkeitszeitraum konfigurieren und dann die tatsächlichen Sperrablaufdaten in Ihrem Bucket überprüfen, wundern Sie sich nicht, wenn Dateien bis Tag 10, 14 oder sogar 17 gesperrt sind. Veeam fügt dem Unveränderlichkeitszeitraum über das hinaus, was Sie konfigurieren, zusätzliche Tage hinzu. Dies ist beabsichtigtes Verhalten. Veeam schützt sich gegen das Szenario, in dem eine Datei spät in einem Backup-Job geschrieben wird und eine Aufbewahrungsbereinigung versuchen würde, sie zu löschen, bevor der Unveränderlichkeitszeitraum vollständig abgelaufen ist. Die zusätzlichen Tage schaffen einen Puffer. Die praktische Konsequenz ist die Speicherkapazitätsplanung: Wenn Sie 7 Tage unveränderlichen Speicher einplanen, müssen Sie möglicherweise tatsächlich näher an 14 Tage Daten berücksichtigen, die zu einem bestimmten Zeitpunkt nicht gelöscht werden können. Planen Sie diese Abweichung ein.
Bucket-Lebenszyklusregeln, die Daten automatisch basierend auf dem Alter oder anderen Kriterien löschen, stehen im Konflikt damit, wie Backup-Anwendungen ihren eigenen Datenlebenszyklus verwalten. Wenn Sie Veeam oder eine andere Anwendung Ihre Backup-Kette verwalten lassen, verfolgt diese Anwendung, welche Dateien aktiv sind, welche abgelaufen sind und wann jede entfernt werden sollte. Wenn Sie eine Bucket-Lebenszyklusregel festlegen, die Dateien nach 30 Tagen löscht, und Ihre Backup-Anwendung immer noch auf eine Datei verweist, die 32 Tage alt ist, haben Sie die Kette unterbrochen. Der richtige Ansatz ist, Bucket-Lebenszyklusregeln in Ruhe zu lassen und die Backup-Software die gesamte Datenverwaltung übernehmen zu lassen. Wenn Ihre Backup-Anwendung korrekt funktioniert, sind keine Bucket-Löschregeln erforderlich. Wenn etwas nicht korrekt funktioniert, wird eine Lebenszyklusregel das Problem verschlimmern.
Nicht jede Backup-Software unterstützt Object Lock. Consumer-Sync-Tools und einfache Datei-Backup-Anwendungen unterstützen im Allgemeinen keine unveränderlichen Backups. Wenn sie auf ein unveränderliches Objekt stoßen, schlägt der Schreibvorgang zum Löschen oder Ändern fehl, was den Backup-Job unterbricht. Enterprise-Backup-Anwendungen wie Veeam und Commvault haben native Unterstützung für Object Lock. Sie wissen, wie man Unveränderlichkeitsflags schreibt, Aufbewahrungszeiträume verwaltet und die S3-API-Aufrufe korrekt handhabt. Wenn Ihr aktuelles Backup-Tool nicht auf der Enterprise-Liste steht, überprüfen Sie die Dokumentation, bevor Sie davon ausgehen, dass Unveränderlichkeit funktioniert. Eine Backup-Kette, die aufgrund inkompatibler Object-Lock-Verarbeitung stillschweigend fehlschlägt, schützt nichts.
Sobald ein Objekt mit einem bestimmten Ablaufdatum gesperrt ist, kann dieses Datum nur vorwärts verschoben werden. Sie können den Unveränderlichkeitszeitraum verlängern, aber nicht verkürzen. Dies ist eine bewusste Designbeschränkung: Der ganze Wert der Unveränderlichkeit besteht darin, dass sie nicht rückwirkend geschwächt werden kann. Wenn ein kompromittiertes Konto oder ein böswilliger Akteur die Sperre verkürzen oder entfernen könnte, wäre der Schutz bedeutungslos. Das gleiche Prinzip gilt für Governance-Modus- versus Compliance-Modus-Konfigurationen. Der Compliance-Modus macht die Datenlöschung sogar für Kontoadministratoren während des Aufbewahrungszeitraums unmöglich. Der Governance-Modus erlaubt bestimmten privilegierten Benutzern, die Sperre zu ändern. Für ernsthaften Ransomware-Schutz ist der Compliance-Modus im Allgemeinen die stärkere Wahl.
Object Lock verhindert, dass irgendeine Person unveränderliche Objekte innerhalb Ihres Kontos löscht. Selbst ein Administrator mit vollen Berechtigungen kann ein gesperrtes Objekt vor Ablauf seines Aufbewahrungszeitraums nicht löschen. Wenn jedoch jemand mit Zugriff auf Kontoebene das gesamte Konto löscht, rettet dieser Schutz die Daten nicht. Dies gilt für jeden Cloud-Speicheranbieter, nicht nur für Backblaze. Es ist keine Lücke in Object Lock, sondern eine völlig andere Angriffsfläche. Die Abhilfe ist Kontosicherheit: Zwei-Faktor-Authentifizierung, eingeschränkte administrative Berechtigungen und Überwachung auf ungewöhnliche Kontoaktivitäten. Object Lock und Kontosicherheit arbeiten zusammen. Keines macht das andere überflüssig.
Bei Backblaze B2 ist Unveränderlichkeit im Standard-Speicherabonnement enthalten. Einige Speicheranbieter berechnen separat Gebühren für Object-Lock-API-Aufrufe, einschließlich der PUT-Anfragen, die Sperrmetadaten erneuern oder schreiben. Diese Transaktionsgebühren können sich in Umgebungen mit hohen Dateizahlen oder häufigen Sperrerneuerungen erheblich summieren. Bei B2 zahlen Sie für den Speicher, den Sie nutzen, einschließlich des zusätzlichen Speichers, der durch Daten verbraucht wird, die während ihres Unveränderlichkeitszeitraums nicht gelöscht werden können. Die Funktion selbst hat keinen Aufpreis. Wenn Sie die Versionierung neben der Unveränderlichkeit aktivieren, zählen alle Versionen einer Datei zu Ihrer Speichernutzung, nicht nur die aktuelle. Wenn eine Datei 50 Mal geändert wurde und Sie 50 Versionen speichern, zahlen Sie für alle 50, unabhängig davon, wie viele davon derzeit unveränderlich sind. Die richtige Versionierungskonfiguration hängt von Ihren Wiederherstellungszielen und Ihrem Budget ab. Jede Version auf unbestimmte Zeit aufzubewahren ist selten notwendig, und die meisten Backup-Anwendungen geben Ihnen die Kontrolle darüber, wie viele Versionen aufbewahrt werden sollen.
Bevor Object Lock in Produktion geht, empfiehlt Wilson eine kurze Checkliste. Überprüfen Sie, ob Ihre Backup-Anwendung native Object-Lock-Unterstützung hat und ob Sie die Unveränderlichkeit in den Anwendungseinstellungen aktiviert haben, nicht nur auf Bucket-Ebene. Erstellen Sie Ihren Bucket mit aktiviertem Object Lock, auch wenn Sie nicht vorhaben, es am ersten Tag zu nutzen, da Sie es später nicht mehr aktivieren können. Überspringen Sie Bucket-Lebenszyklusregeln, wenn Ihre Backup-Software den Datenlebenszyklus verwaltet. Berücksichtigen Sie Veeams zusätzliche Tage bei der Speicherkapazitätsplanung, da das tatsächliche Sperrfenster länger sein wird als das, was Sie konfigurieren. Überprüfen Sie schließlich Ihren Unveränderlichkeitszeitraum im Kontext Ihrer Fähigkeit zur Erkennung von Vorfällen. Ein 30-tägiges Unveränderlichkeitsfenster ist nicht sicherer als ein 14-tägiges Fenster, wenn Ihr Sicherheitsteam einen Vorfall innerhalb von 48 Stunden erkennen kann. Object Lock ist eines der zuverlässigeren verfügbaren Tools zum Schutz von Backup-Daten vor Ransomware, aber die meisten Implementierungsfehler sind leicht zu beheben, sobald Sie wissen, wo Sie suchen müssen. Für Teams, die Object-Lock-Einstellungen lieber nicht über mehrere Backup-Tools hinweg verwalten möchten, bietet ein europäischer Anbieter für verwaltete Cloud- und Dateninfrastruktur wie AEU Data automatisierte Backups, verschlüsselten Speicher und Überwachung, die diese Konfigurationslücken reduzieren können.