Sichere Offsite-Sicherung, auch bei Hacker-Root-Zugriff

Ich suche nach einer Möglichkeit, eine sicherere Methode zum Ausführen einer Offsite-Sicherung zu implementieren, die meine Daten auch vor der Situation schützt, in der ein böswilliger Hacker Root-Zugriff auf meinen Server erlangt hat. Auch wenn das Risiko geringer ist als bei anderen Arten von Risiken, wenn die SSH- und Kennwortsicherheit ordnungsgemäß eingerichtet und das System ordnungsgemäß auf dem neuesten Stand gehalten wird, ist die Menge an Schaden, die dauerhaft angerichtet werden kann, sehr hoch und daher auch ich möchte eine Lösung finden, um das zu begrenzen.

Ich habe bereits zwei Möglichkeiten für Offsite-Backups ausprobiert:

• Ein einfaches webdav-Mount mit Root-Schreibberechtigung (und Konfiguration in fstab), in das die gesicherten Daten kopiert werden. Problem : Nicht wirklich eine Offsite-Sicherung, da die Verbindung - und darüber hinaus der Zugriff - zum Offsite-Speicherort als Ordner im Dateisystem ständig offen bleibt. Dies ist ein ausreichender Schutz gegen viele Arten von Angriffen, wenn der Mount über eingeschränkte Zugriffsrechte verfügt (Nur-Root-Lesezugriff), nicht jedoch gegen eine böswillige Person mit Root-Zugriff.

• Borg-Backup über SSH mit Schlüsselauthentifizierung. Problem : Die Verbindung zu diesem externen Server kann mit dem auf dem Host gespeicherten Schlüssel hergestellt werden, wenn der böswillige Benutzer Root-Zugriff auf den Host hat.

Als Lösung denke ich über diese möglichen Wege nach, aber ich weiß nicht wie und womit:

• Backups können nur geschrieben oder an das Ziel angehängt, aber nicht gelöscht werden.
• Die Verwendung einer Sicherungssoftware, die die Offsite-Sicherungen verwaltet und das Massenlöschen der Offsite-Sicherungen vom ersten Host nicht unterstützt.

Lösungen, die in meiner Situation nicht wirklich interessant sind:

• Ein zusätzlicher Sicherungsjob auf dem externen Host, der sie an einen Speicherort überträgt, auf den der erste Host aus technischen Gründen nicht zugreifen kann.

Kann jemand Ratschläge geben, wie eine ordnungsgemäße Offsite-Sicherung für meinen Fall implementiert werden kann?

Alle Ihre Vorschläge haben derzeit eines gemeinsam: Die Sicherungsquelle führt die Sicherung durch und hat Zugriff auf das Sicherungsziel. Unabhängig davon, ob Sie den Speicherort bereitstellen oder Tools wie SSH oder rsync verwenden, hat das Quellsystem irgendwie Zugriff auf die Sicherung. Daher kann ein Kompromiss auf dem Server auch Ihre Sicherungen gefährden.

Was passiert, wenn die Sicherungslösung stattdessen Zugriff auf den Server hat? Das Backup-System kann seine Aufgabe mit einem Nur-Lese- Zugriff erledigen , sodass ein Kompromiss beim Backup-System den Server wahrscheinlich nicht gefährden würde. Das Backup-System kann auch nur für diesen Zweck vorgesehen sein, sodass der Inhalt des Backups der einzige Angriffsvektor ist. Das wäre sehr unwahrscheinlich und würde einen wirklich raffinierten Angriff erfordern.

Führen Sie inkrementelle Sicherungen durch, um zu vermeiden, dass die Sicherungen durch manipulierten oder beschädigten Inhalt überschrieben werden. Auf diese Weise können Sie einen beliebigen vorherigen Status innerhalb des festgelegten Wiederherstellungszeitraums wiederherstellen.

Unveränderlicher Speicher

Eine gute Option besteht darin, den Backup-Speicher unveränderlich zu machen oder zumindest eine zuverlässige Versionierung bereitzustellen, die Ihnen eine effektive Unveränderlichkeit verleiht. Um es klar auszudrücken: Unveränderlich heißt, nicht veränderbar oder dauerhaft.

Es gibt mehrere Dienste, die dies für Sie erledigen können. AWS S3, BackBlaze B2 und ich vermuten, dass Azure und Google einen ähnlichen Service anbieten. Sie könnten wahrscheinlich einen Server dafür einrichten, aber ich bin mir nicht sicher, wie.

Wenn Sie über ein unveränderliches / versionskontrolliertes Repository verfügen, können Sie Ihr Backup zu jedem Zeitpunkt wiederherstellen. Wenn Ihr Host also kompromittiert ist, können Sie es zu jedem Zeitpunkt wiederherstellen.

* AWS S3 **

Ich bin am besten mit AWS S3 vertraut. S3 bietet versionierten, verschlüsselten Speicher mit hoher Lebensdauer.

S3 unterstützt die Versionierung, wodurch Sie eine effektive Unveränderlichkeit erhalten. Sie können festlegen, dass nach einem konfigurierbaren Zeitraum mithilfe von Lebenszyklusregeln alte Dateiversionen gelöscht werden. Sie können Versionen auch im Kühlhaus (Glacier Cold Archive) archivieren, was ungefähr 1 USD / TB / Monat kostet.

Mithilfe der intelligenten Speicherebenenklasse können Sie Kosten senken. Ich entscheide mich für die Verwendung einer Lebenszyklusregel, um alle statischen Daten in eine seltene Zugriffsklasse zu verschieben. Dies ist eine dauerhafte und moderate (Hot-) Leistung, hat jedoch nicht die Skalierbarkeit oder Leistung des S3-Standards.

S3 verwendet IAM-Benutzer und -Richtlinien (Identity Access Management, dh Benutzerverwaltung). Auf diese Weise können Sie sehr genau steuern, was Ihre Sicherungssoftware mit Ihrem Speicher tun kann. Sie können dem Sicherungsbenutzer die Berechtigung zum Hochladen erteilen, das Aktualisieren und Löschen jedoch verweigern. Sie können auch eine Multi-Faktor-Authentifizierung benötigen, um Dateien zu löschen, oder sogar eine Objektsperre bereitstellen , damit Dateien nicht gelöscht werden können.

Vorgeschlagene Software

Ich erstelle inkrementelle Backups mit Restic . Restic lädt die neuen Dateien in Ihren Speicherort hoch. Ich glaube (aber ich könnte falsch sein), dass es neue Dateien erstellt, aber im Allgemeinen werden keine Dateien aktualisiert oder gelöscht.

Borg ist eine weitere Option. Früher habe ich Borg verwendet, aber ich habe festgestellt, dass meine mittelgroßen Backups mit Hunderten von MB effektiv alle meine Daten jeden Tag von EC2 auf S3 hochgeladen haben. Für mich ist das nicht inkrementell, also habe ich aufgehört, es zu verwenden. Ich habe Dokumentation dazu gefunden, aber keinen Link.

Es gibt Dutzende von Software-Komponenten, die in den Cloud-Speicher hochgeladen werden können.

Geschützter Speicher

Mit einer Sicherungssoftware können Sie versuchen, dem IAM-Benutzer die Berechtigung zum Schreiben neuer Dateien zu erteilen, vorhandene Dateien jedoch nicht zu aktualisieren. Es ist einfach, diese Einschränkung mit AWS IAM vorzunehmen, aber gemäß dem folgenden Kommentar funktioniert Restic mit diesen Berechtigungen nicht. Sie können auch eine Multi-Faktor-Authentifizierung einrichten, um Dateien aus S3 zu löschen.

Sie könnten einen anderen IAM-Benutzer haben, der von Ihrem PC aus ausgeführt wird, der die regelmäßige Bereinigung des Archivs durchführt und Versionen gemäß der von Ihnen festgelegten Richtlinie verwirft.

Borg Backup unterstützt Remote-Repositorys, die nur Anhänge enthalten . Jegliche Gefährdung des zu sichernden Servers kann dazu führen, dass nur neue Sicherungen erstellt und nicht nur alte überschrieben werden.

Lösungen, die in meiner Situation nicht wirklich interessant sind:

Ein zusätzlicher Sicherungsjob auf dem externen Host, der sie an einen Speicherort überträgt, auf den der erste Host nicht zugreifen kann.

Das grundlegende Problem ist, dass der Hacker auch auf Ihre Backups zugreifen kann, wenn Sie remote auf sie zugreifen können .

(Aufgrund technischer Einschränkungen)

Technische Einschränkungen sind zu überwinden.

Kann jemand Ratschläge geben, wie eine ordnungsgemäße Offsite-Sicherung für meinen Fall implementiert werden kann?

Bandlaufwerke bieten seit fast 70 Jahren einen sicheren Schutz außerhalb des Standorts gegen alle Arten von Katastrophen - einschließlich Hacker.

Sie können Speicherdienste wie AWS S3 (oder möglicherweise das Äquivalent von Google oder Azure) verwenden, um Ihrem Stammkonto PUT-Berechtigungen für Ihren Bucket zu erteilen, aber keine DELETE-Berechtigungen. Auf diese Weise können Sie ein Push-Modell verwenden und der Angreifer kann das Backup nicht löschen.

Es gibt weitere Sicherheitsmaßnahmen, die Sie mit AWS ergreifen können, z. B. die Anforderung, dass MFA DELETEs für den Bucket ausführt, aber PUTs und GETs ohne MFA zulässt. Auf diese Weise können Sie Ihre Daten sichern und abrufen, um Ihre Dienste wiederherzustellen, ohne Ihr MFA-Gerät zu verwenden. Dies kann in extremen Fällen (und möglicherweise zu dunkel, um dies auch nur zu erwähnen) hilfreich sein, in denen der Zugriff auf das MFA-Gerät zu einer Gefährdung führen kann.

Außerdem gibt es verschiedene Möglichkeiten, S3 und ähnliche Dienste für das automatische Failover zu konfigurieren, falls die Hauptdatenquelle offline ist.

Borg-Backup über SSH mit Schlüsselauthentifizierung. Problem: Die Verbindung zu diesem externen Server kann mit dem Schlüssel hergestellt werden, der auf dem Host gespeichert ist, wenn der böswillige Benutzer Root-Zugriff auf den Host hat.

Sie können den Befehl option in Ihren authorized_keys verwenden. Sie korrigieren den in remote zulässigen Befehl.

wie man Befehle in ssh authorized_keys hinzufügt

Selbst wenn ein Angreifer den Anmeldestamm wiederherstellt, kann er nur den definierten Befehl ausführen.

Eine Technik, die Sie einrichten können, besteht darin, die Synchronisierung zwischen Ihrem Server und einem Remote-Backup-Server zu verwenden und den Remote-Backup-Server Snapshots oder was auch immer an seinem Ende ausführen zu lassen, damit das Löschen des Servers nicht zum Löschen außerhalb des Standorts führt.