Die Freigabe, die jeder löschen darf
Im Frühjahr saßen wir mit einem IT-Dienstleister zusammen, der vor allem kleine Büros betreut. Gesichert wurde dort ordentlich: jeden Tag, automatisch, auf ein NAS im selben Haus. Was fehlte, sagte er selbst: „Da muss irgendwie abgekapselt vom lokalen Netz noch ein Backup liegen.“
Er hatte recht. Und das Wort, auf das es ankommt, ist „abgekapselt“. Ein zweites Ziel allein reicht nicht.
Wem eine Freigabe gehört
Eine Sicherung auf einer SMB- oder NFS-Freigabe ist eine Sammlung von Dateien. Wer Schreibrechte auf die Freigabe hat, kann sie ändern, verschlüsseln oder löschen. Das ist der Sinn einer Freigabe.
Diese Schreibrechte hat der Backup-Server, denn er muss ja sichern. Die Zugangsdaten liegen also auf ihm. Wer den Backup-Server übernimmt, übernimmt damit auch die Sicherungen. Genau das tun Angreifer heute zuerst: Sie suchen die Backups, bevor sie verschlüsseln. Ein Backup, das man mit den Rechten des Backup-Servers löschen kann, ist im Ernstfall keins.
Das gilt auch dann, wenn die Freigabe in einem anderen Gebäude steht. Ein entferntes NAS mit denselben Zugangsdaten ist weiter weg, aber nicht sicherer.
Was ein gehärtetes Repository anders macht
Veeam nennt es Hardened Repository: ein Linux-Server, auf dem die Sicherungen für eine feste Frist unveränderbar gesetzt werden. In dieser Zeit lässt sich eine Sicherung weder überschreiben noch löschen, auch nicht über Veeam selbst.
Drei Dinge machen den Unterschied:
- Keine dauerhaften Zugangsdaten. Der Backup-Server bekommt die Anmeldedaten nur einmal, beim Einrichten. Danach liegen sie nirgends mehr, wo ein Angreifer sie finden könnte.
- Kein Löschen über die Backup-Software. Selbst wer Veeam vollständig kontrolliert, kommt vor Ablauf der Frist nicht an die Sicherungen.
- Kaum Angriffsfläche. Ein eigener Server, nicht virtuell, ohne weitere Aufgaben. Veeam prüft das in seinen Sicherheitsberichten ausdrücklich.
Was es nicht leistet
Ein gehärtetes Repository ist nur so hart wie sein Zugang. Wer als Root auf den Linux-Server kommt, kann die Sperre auf Systemebene aufheben. Ein SSH-Zugang mit Passwort ist der kürzeste Weg dorthin. Bei uns ist das deshalb standardmäßig zu und wird nur für Wartung kurz und nach Absprache geöffnet. Bei einem Repository, das man selbst betreibt, muss das jemand genauso konsequent halten, jahrelang.
Auch die Frist will passen. Hält die Sperre länger als die Aufbewahrung im Job, läuft das Ziel still voll. Das haben wir in Wenn die Sperre länger hält als die Aufbewahrung beschrieben.
Warum es außer Haus steht
Ein gehärtetes Repository im eigenen Serverraum schützt vor dem Löschen, nicht vor Feuer, Wasser oder Diebstahl. Und es hängt am selben Netz und an denselben Admins wie alles andere.
Die Regel dazu heißt 3-2-1-1-0: drei Kopien, auf zwei Medien, eine davon außer Haus, eine unveränderbar oder offline, und null Fehler beim Restore-Test.
Die lokale Sicherung auf dem NAS bleibt dabei wichtig, für den schnellen Restore im Alltag. Die zweite Kopie liegt außer Haus und unveränderbar. Wie das bei zwei Serverräumen im selben Haus aussieht, steht in Ein Backup für zwei Brandabschnitte .
Für das Ziel außer Haus gibt es zwei saubere Wege:
- Ein gehärtetes Repository bei einem Dienstleister, angebunden über eine verschlüsselte Verbindung. So betreiben wir den Managed Storage Server .
- Objektspeicher mit Object Lock im Compliance-Modus. Auch dort lässt sich während der Frist nichts löschen, auch nicht mit Administratorrechten auf dem Speicher.
Eine Freigabe, auf die der Backup-Server mit festen Zugangsdaten schreibt, ist keiner der beiden Wege, egal wo sie steht.
Was man heute prüfen kann
- Wohin schreibt die zweite Kopie, und mit welchen Zugangsdaten?
- Könnte jemand, der den Backup-Server übernimmt, diese Kopie löschen?
- Wann wurde zuletzt aus ihr zurückgesichert?
Wer die zweite Frage mit Ja beantwortet, hat ein Backup, aber keinen Plan B. Was danach kommt, wenn der Ernstfall da ist, steht in Ein Scanner, ein altes Passwort, eine Woche zu fünft .