Restic: Unterstützt asymmetrische Backups

Eine kurze Zusammenfassung der vorherigen Diskussion:

• Nützlich für Backups von E-Mail-Servern oder Remote-Backups von Protokolldaten für den Fall, dass ein solcher Server kompromittiert wird. Das Backup enthält möglicherweise sensible Daten, die vom Server geschreddert wurden, und es kann nützlich sein, einem Angreifer den Zugriff auf solche historischen Daten zu verweigern. Gleichzeitig wurde diskutiert, dass es sinnvoll sein könnte, einen "Blob-Netzwerkserver" mit einem Capability-System zu haben, mit dem Sie den Nur-Anfügen- / Nur-Lese- / Lese-Schreib-Zugriff entsprechend konfigurieren können. Das Vorhandensein einer asymmetrischen Kryptographie würde die Notwendigkeit beseitigen, _noch einen weiteren_ Satz von symmetrischen Schlüsseln für die Ausgabe von Fähigkeiten zu haben, und würde wahrscheinlich auch die Implementierung eines Fähigkeitssystems vereinfachen.
• In einer Umgebung mit mehreren Maschinen kann mit _einem_ Backup-Schlüssel auf mehrere Backup-Datensätze zugegriffen werden, ohne eine Vielzahl von symmetrischen Schlüsseln verwalten zu müssen. Wenn ein Kryptosystem wie Curve25519 von Daniel Bernstein verwendet wird, kann ein solcher Schlüssel von einer Passphrase abgeleitet werden, dh Sie können mit einer Master-Passphrase Backups verwalten, die von einer (möglicherweise großen) Anzahl verschiedener Sicherheitsdomänen erstellt wurden. Obwohl man mit n symmetrischen Schlüsseln und einem verschlüsselten Schlüsselspeicher natürlich etwas Ähnliches erreichen kann.

@heipei FYI Vielleicht möchten Sie diese Ausgabe abonnieren

Nun, der offensichtlichste und dringendste Anwendungsfall besteht darin, dass die Backups nicht von einem Angreifer gelöscht werden, der in Ihr Produktionssystem (Backup-Client) eingebrochen ist und von dort aus weiß, wie man restic verwendet.

Das ist kaum möglich, nur durch die Verwendung von asymmetrischer Krypto. Der Punkt hier ist, dass alte Backup-Inhalte (nicht unbedingt Metadaten) einem Angreifer, der in einen Server eingebrochen ist, nicht zur Verfügung stehen sollten.

Die Datenvertraulichkeit ( write-only ) wäre für diese Szenarien mit der Implementierung von asymmetrischer Kryptowährung erreichbar.

Die Datenintegrität ist ein etwas anderes Tier:
Sie können zwar asymmetrische Kryptographie (und ein einmaliges Signaturschema) verwenden, um nachzuweisen, dass ein bestimmter Datensatz nicht geändert wurde, Sie können jedoch seine vollständige Entfernung oder Ersetzung nicht verhindern. Dies ist ein Problem, das ein Speichersystem erfordert, das append-only (und read-only für einige Teile) ist.
Dank der diskretionären Zugriffskontrolle, die auf *nix mit einem Backend wie ssh relativ einfach zu implementieren ist (mit Befehlen wie chmod , chown , chattr +i , chattr +a , um die Zugriffsrichtlinien zu konfigurieren). append-only Backups müssen nicht einmal verschlüsselt werden, um zu verhindern, dass Angreifer sie lesen (das ist zum Beispiel ein Teil dessen, was rsyslog tut), aber das macht den Backup-Server plötzlich zu einem interessanten Ziel, und Das Klonen sensibler Daten auf mehr Geräte verbessert nicht gerade die Chancen, die Vertraulichkeit der

Die Implementierung von asymmetrischer Kryptographie würde es den Leuten ermöglichen, diese Art von Backups auf dummen, nicht vertrauenswürdigen Systemen durchzuführen, eines der Dinge, um die es bei restic geht (abgesehen von der verbesserten Deduplizierung und all den anderen netten Funktionen). Ich hoffe, diese Ausarbeitung klärt meinen Standpunkt ein wenig.

Dies ist für uns für die beiden in https://github.com/restic/restic/issues/187#issuecomment -101974306 beschriebenen Fälle von Interesse. Ich abonniere diesen Thread, um das im Auge zu behalten.

Bezüglich der Datenintegrität : AFAIK, Sie können append-only Verhalten auf Amazon S3 erreichen, indem Sie Ihren IAM-Anmeldeinformationen nur die Berechtigungen PutObject und GetObject erteilen, aber die DeleteObject zurückhalten Erlaubnis.

Bezüglich der Datenvertraulichkeit möchte ich ein Angriffsszenario erwähnen, das durch den Einsatz von symmetrischer Krypto ermöglicht wird:
Wenn ein Angreifer die Kontrolle über das Benutzerkonto eines Opfers zu einem Zeitpunkt hat, an dem das Opfer restic , um ein Backup durchzuführen, kann er:

• den restic Schlüssel des Opfers stehlen
• die IAM-Anmeldeinformationen/sftp-Login/... des Opfers stehlen

Der Angreifer kann dann sofort jede Spur seines Angriffs vom System des Opfers löschen, wodurch eine Entdeckung weniger wahrscheinlich wird. Da er den Restic Key und die Credentials für das Remote-Storage-System gestohlen hat, liefert ihm das Opfer bequem alle (gesicherten) zukünftigen Daten aus: Unser Angreifer muss nur von Zeit zu Zeit neue Backups vom Remote-Storage-System herunterladen und entschlüsseln Zeit.

Asymmetrische Kryptographie könnte dazu beitragen, dies zu verhindern, indem es dem Opfer ermöglicht, den Schlüssel für die Offline-Wiederherstellung von Backups zu speichern.

Bezüglich der Datenintegrität: AFAIK, Sie können auf Amazon S3 ein Nur-Anhängen-Verhalten erreichen, indem Sie Ihren IAM-Anmeldeinformationen nur die Berechtigungen PutObject und GetObject erteilen, aber die DeleteObject-Berechtigung verweigern.

Leider gibt Ihnen PutObject auch die Berechtigung, eine zuvor hochgeladene Datei zu überschreiben. Vielleicht ist es also nicht die vollständige Datenintegrität?

Asymmetrische Krypto würde auch die Verwendung eines OpenPGP-Schlüssels wie Yubikey oder so ermöglichen.

Heute habe ich festgestellt, dass ich nicht wirklich Unterstützung für asymmetrische Verschlüsselung in Restic möchte, sondern Unterstützung dafür, den Schlüssel NICHT im Repository zu speichern. Ich verstehe, dass die effiziente Verwendung der asymmetrischen Verschlüsselung bedeuten würde, dass Restic neue Backups hochladen kann, ohne das Repository lesen zu können, was ziemlich schwierig ist.

Für mich wäre es also in Ordnung, wenn ich mit dem symmetrischen Schlüssel ohne Restic umgehen könnte und er in keiner Weise in das Repository hochgeladen würde, egal welches komplexe KDF verwendet wird.

Mein Anwendungsfall ist als Systemadministrator für eine Reihe von Servern.

Asymmetrische Backups sind die einzige Möglichkeit, die Backups im Szenario einer Serverkompromittierung zu schützen, bei der ein Angreifer böswillig alle Daten (einschließlich der Backups) zerstört (oder Ransomware verschlüsselt).

Dies erfordert serverseitige Unterstützung durch entweder eine nur anhängende Speicherschicht oder einen Server-Daemon, ähnlich wie rdiff-backup die Option --restrict-update-only hat. Derzeit umgehe ich dies, indem ich schreibgeschützte Snapshots des Backup-Repositorys auf dem Backup-Server (Zugriff über sftp) verwende.

(Vielleicht relevant): Nur Anhängen kann unter Linux durch das append-only Flag in einem Verzeichnis (das das Aufheben der Verknüpfung deaktiviert) zusammen mit dem immutable Flag in den Dateien erreicht werden. Die Befehle, die für das Setzen dieser Flags verantwortlich sind, sind chattr +a /path/to/directory bzw. chattr +i /path/to/directory/myfile01 .

Mein Anwendungsfall hier ist #533 – unbeaufsichtigte Backups. wie dort erwähnt, ist asymmetrische Krypto nur eine der Möglichkeiten, dies zu tun, aber es scheint die erste offensichtliche Lösung für das Problem zu sein.

In einem Szenario, in dem sich das Repository auf einem Remote-Server befindet, sollten nur lokale Befehle im Repository vergessen/bereinigen können.

Das restliche Backup sollte mit einem eindeutigen Schlüssel für dieses System nur mit Wiederherstellungs-/Backup-Berechtigungen verbunden werden.

In einem Szenario, in dem sich das Repository auf einem Remote-Server befindet, sollten nur lokale Befehle im Repository vergessen/bereinigen können.

Dies sollte erreicht werden, indem der Zugriff auf das Löschen/Ändern von Dateien auf Repository-Ebene eingeschränkt wird. Ich denke, es liegt außerhalb des Geltungsbereichs (und nicht einmal sicher) für restic, diese Berechtigungen zu verwalten. Schließlich könnte jemand das Repository oder sogar die Schlüssel löschen, wodurch das gesamte Repository nutzlos wird, unabhängig davon, ob diese Aktion vom restic-Client zugelassen wurde.

In Bezug auf die Verhinderung der Zerstörung von Backup-Daten durch jemanden, der den Server hackt: rest-server hat kürzlich mit PR https://github.com/restic/rest-server/pull/28 einen "Append Only Mode" erhalten, der genau dies verhindert.

Mein Anwendungsfall besteht darin, viele Systeme im selben Repository zu sichern, um den Vorteil der Deduplizierung auf all diesen Maschinen zu nutzen, aber eine Kompromittierung eines Systems (und seines Backup-Skripts), die es dem Angreifer nicht erlaubt, die Backups der anderen Systeme zu lesen.

Die Funktion, nach der ich suche, besteht darin, "Backup" -Schlüssel zu haben, die es einem System ermöglichen, zu schreiben (Sicherung) und zu lesen (Wiederherstellung), aber keine Verwaltung durchführen kann (z. B. beschneiden, Schlüssel hinzufügen oder sogar die Existenz anderer sehen). Schlüssel, (Benutzer) oder Snapshots, die nicht mit $backup_key verknüpft sind). (Obwohl ein Seitenkanalangriff durch den Vergleich von Backup-Zeiten möglich sein könnte, spielt es für mich keine Rolle, ob sie die Existenz von Daten feststellen können, nur dass sie meine Daten nicht erpressen und andere Benutzer nicht sehen können.) Ich würde erwarten, dass der Inhaber eines Backup-(only)-Keys, um seine eigene(n) Passphrase(n) aktualisieren zu können. Im Gegensatz zu der Anfrage von administrieren . (Ich benutze SELinux seit Jahren und bin jetzt ein Fan der Granularität von MAC) Danke fürs Lesen. (Entschuldigung, wenn dies ein eigenes Problem haben sollte.) Mit dieser Funktion #ResticKillsRansomware

Mit dieser Funktion #ResticKillsRansomware

Im Allgemeinen lösen Pull-orientierte Backups (im Gegensatz zu Push-orientierten Backups) Ransomware, oder? :)

Möglicherweise gibt das dann aber Remote-Zugriff und fügt einen weiteren Angriffsvektor hinzu. Wie ich es entworfen habe, dient mein Backup-Server der Datenerhaltung und sollte niemals Zugriff auf meine Produktionsumgebung haben. Klare Abgrenzung der Funktionsdomänen.

Ich vermute, Restic ist dann nicht die Lösung, da es für den direkten Betrieb auf Backup-Repos ausgelegt ist.

Vielleicht könnten Sie etwas mit einer Art Mittelsmann-Server machen. Lassen Sie Ihre Produktionsmaschinen Tarballs auf einen Server hochladen, lassen Sie dann ein anderes System die Tarballs herunterladen, extrahieren Sie sie und sichern Sie den Inhalt lokal. Jede Seite hat nur Zugriff auf den mittleren Server. Das wäre ziemlich einfach zu tun, ohne Restic zu ändern. Es wäre wahrscheinlich auch sicherer und robuster, da alle Fehler in einem Nur-Empfangs-Restic-Modus die Backups anfällig für kompromittierte Backup-Clients machen könnten.

Die Funktion, nach der ich suche, besteht darin, "Backup" -Schlüssel zu haben, die es einem System ermöglichen, zu schreiben (Sicherung) und zu lesen (Wiederherstellung), aber keine Verwaltung durchführen kann (z. B. beschneiden, Schlüssel hinzufügen oder sogar die Existenz anderer sehen). Schlüssel, (Benutzer) oder Snapshots, die nicht mit $backup_key verknüpft sind). (Obwohl ein Seitenkanalangriff durch den Vergleich von Backup-Zeiten möglich sein könnte, spielt es für mich keine Rolle, ob sie die Existenz von Daten feststellen können, nur dass sie meine Daten nicht erpressen und andere Benutzer nicht sehen können.) Ich würde erwarten, dass der Inhaber eines Backup-(only)-Keys, um seine eigene(n) Passphrase(n) aktualisieren zu können. Im Gegensatz zu der Anfrage von michbsd könnte ich also von einem nicht lokalen Computer aus mit einem privilegierten Schlüssel administrieren. (Ich benutze SELinux seit Jahren und bin jetzt ein Fan der Granularität von MAC) Danke fürs Lesen. (Entschuldigung, wenn dies ein eigenes Problem haben sollte.) Mit dieser Funktion #ResticKillsRansomware

Obwohl dies möglicherweise nicht genau das ist, wonach Sie fragen, können Sie sich rest-server ansehen. Es verfügt über einen Nur-Append-Modus, der das Löschen und Ändern vorhandener Backups verhindert.

Obwohl dies möglicherweise nicht genau das ist, wonach Sie fragen, können Sie sich rest-server ansehen. Es verfügt über einen Nur-Append-Modus, der das Löschen und Ändern vorhandener Backups verhindert.

Ich wusste gar nicht, dass es das gibt. D:

Ich sehe zwei strukturelle Dinge (und leicht unterschiedliche Angreifermodelle), die ich hier ablegen möchte.

Im Moment interagiert restic (meistens) mit "dummem" Speicher (local, s3, b2, gcs, azure, alles außer dem REST-Server mit --append-only ). Es kann Daten in einem Backend speichern, auflisten, abrufen und löschen. Dies ist für ein Backup erforderlich, daher müssen die erforderlichen Anmeldeinformationen für den Zugriff auf das Backend vorhanden sein. Auf der anderen Seite kann restic fast jeden Speicher verwenden, es gibt nur sehr wenige Einschränkungen. Auf der anderen Seite können Angreifer, sobald sie Zugang zu einem Server erhalten, die Zugangsdaten für den Zugriff auf das Backend und das Restic-Passwort leicht extrahieren, was ihnen alle Möglichkeiten bietet: Historische Daten aus dem Repository entschlüsseln, Daten ändern, das gesamte Repository löschen.

Wenn wir asymmetrische Kryptografie hinzufügen, besteht der einzige Unterschied für Angreifer in einer solchen Situation darin, dass sie historische Daten nicht aus dem Repository entschlüsseln können. Alles andere, insbesondere das Löschen aller Daten, ist weiterhin möglich. „Einfach asymmetrisches Krypto hinzufügen“ ist also nicht die ganze Geschichte.

Die andere Idee ist, nicht direkt auf den "dummen" Speicher zuzugreifen, sondern indirekt über eine benutzerdefinierte Serverimplementierung. Wir haben mit dieser Idee herumgespielt und die Option --append-only für den REST-Server hinzugefügt, die als "Adapter" angesehen werden kann, um auf den "dummen" Speicher auf der lokalen Festplatte zuzugreifen. Ich habe mehrere Ideen, wie man diese Idee verbessern kann, nicht unbedingt mit dem REST-Server.

Zum Beispiel möchte ich ein Protokoll für ein Backend definieren, das über ein Paar von Dateideskriptoren gesprochen wird, zB stdin/stdout. Wir können dies dann in einem Programm implementieren, das über SSH auf einem Remote-Rechner ausgeführt wird, genau wie wir es für das sftp-Backend tun. Die Serverimplementierung kann dann entscheiden, wo die Daten gespeichert werden (lokal, s3, b2, was auch immer) und welche Einschränkungen gelten (z könnte beispielsweise über ein ForceCommand bei der Anmeldung über SSH mit einem bestimmten Benutzerkonto oder SSH-Schlüssel gestartet werden.

Ein "nicht-dummer" Speicher allein hilft nicht gegen das Lesen von Daten aus dem Repository (zumindest nicht ohne das Repository-Format zu ändern), verhindert jedoch das Löschen aller Daten im Repository.

Zusammenfassend lässt sich sagen, dass wir, um sich am besten gegen Angreifer zu verteidigen, die einen Server übernehmen, der Restic für Backups verwendet, meiner Meinung nach beides implementieren müssen (nicht dummer Speicher und asymmetrische Krypto). Das ist ein langfristiges Ziel :)

Ich werde diesen Text in den ersten Kommentar in dieser Ausgabe kopieren, damit er leichter zu finden ist.

Ja, wenn ich darüber nachdenke, stimme ich zu, dass asym-Krypto nicht so nützlich ist, um sich gegen Übernahmen zu verteidigen - es ist nützlicher für unbeaufsichtigte Backups (#533).

Ein natives Kommunikationsprotokoll zu haben könnte nützlich sein, aber ich bin mir nicht sicher, was Sie damit über den aktuellen REST-Server gewinnen - könnten Sie das erweitern? attic/borg ging so: Es gibt dort ein "proprietäres" (wie in borg-spezifisches) Client-zu-Server-Protokoll und es ist möglich, einige Einschränkungen für Clients zu implementieren. und ja, dies basiert auf ForceCommand und "borg serve" eingeschränkten Flags ... es gibt einige relevante Hinweise in den Borg-Dokumenten dazu und Nachteile, die Sie kennen sollten.

und natürlich die natürlichste Art und Weise zu schützen Backups von einem kompromittierten Client ist einfach nicht auf dem Client zu ermöglichen, die Sicherungen selbst ausführen, sondern hat die Server - Pull - Dateien aus den Backups „bacula-Stil“ ( "Es kommt in dem Nacht und saugt die Essenz aus Ihren Computern", für diejenigen, die sich an diesen eingängigen Satz erinnern). es scheint auch keine gut dokumentierte oder elegante Möglichkeit zu geben, dies in borg zu tun, die FAQ verweist auf https://github.com/borgbackup/borg/issues/900 als Diskussion zu diesem Thema. hier wird dies in #299 verfolgt, das hier noch nicht erwähnt wurde.

So lange Rede kurzer Sinn, ich würde den Fokus der asymmetrischen Krypto-Unterstützung einfach halten: Erleichtern Sie die Offsite-Schlüsselspeicherung und automatisierte Backups. Es gibt andere Möglichkeiten, kompromittierte Clients zu sichern, und ich denke, Pull-Unterstützung ist die interessanteste. Tatsächlich habe ich in meinen optimalen Backup-Lösungen alle Clients, die ihre Backups auf einen zentralen Server verschieben, und dann auf einen externen Server , der vom Haupt-Backup-Server

1. der Backup-Server benötigt nicht auf allen Maschinen Root-Zugriff
2. dennoch ist die Kompromittierung einer Maschine immer noch wiederherstellbar, selbst wenn sie in der Lage sind, mit den Backups herumzuspielen

Ich finde es eigentlich seltsam, dass dieses Thema in "Ich möchte mich gegen Kundenübernahme absichern" geändert wurde - vielleicht verwechseln wir hier die Lösung mit dem Problem. :)

Hi,

Es scheint, dass es bei diesem Problem nicht nur um asymmetrische Krypto-Backups geht, sondern eher um verschiedene Angriffsvektoren.
Ich habe den Code nicht gelesen, also habe ich wirklich eine naive Frage, aber mein Anwendungsfall besteht hauptsächlich darin, Daten sichern zu können, ohne den geheimen Schlüssel preiszugeben (durch Verwendung des öffentlichen Schlüssels eines privaten Offline-Schlüssels des Sicherungsbesitzers). Ist es für diesen Anwendungsfall einfach zu implementieren?

Mein Verständnis zu diesem Thema ist, dass im Moment alle Blobs mit demselben Schlüssel verschlüsselt sind, und es funktioniert großartig.
Wenn wir asymmetrische Krypto verwenden würden, wie OpenPGP funktioniert, würde jeder erstellte Snapshot einen symmetrischen Schlüssel generieren, der mit dem öffentlichen Schlüssel verschlüsselt ist, und ihn dem Repository hinzufügen. Aber ich denke, das Problem ist, dass Sie in der Lage sein sollten, zuerst die Informationen zu lesen, um herauszufinden, was zu deduplizieren und was zu sichern ist, daher benötigen Sie auch den privaten Schlüssel. Ist das richtig?
Wenn dies der Fall ist, könnte ein Null-Wissens-Beweis in dieser Richtung helfen?

@dolanor bitte füge keine neuen Anwendungsfälle oder Fragen zu diesem Problem hinzu, nutze das Forum für Fragen. Außerdem ist es viel zu früh, um über Details der Implementierung zu sprechen.

Ich habe die Zusammenfassung im ersten Beitrag aktualisiert. Inzwischen ist das rclone Backend hinzugekommen, dieses kann wie oben beschrieben als "Adapter" verwendet und zB per SSH angesprochen werden.

Auf der anderen Seite können Angreifer, sobald sie Zugang zu einem Server erhalten, die Zugangsdaten für den Zugriff auf das Backend und das restliche Passwort leicht extrahieren

Ich hoffe, dies ist ein Tippfehler: Sie haben das verschlüsselte Keyfile-Material hier, nicht wahr? Hoffentlich hat ein Angreifer, der sich Zugang zum Server verschafft, keinen Zugriff auf das Klartext-Passwort. Das Schlimmste, was sie tun können, ist zu versuchen, das "Benutzerpasswort" zu erraten oder zu erraten, das verwendet wird, um die Hauptverschlüsselungs- und Authentifizierungsschlüssel für das Repository zu entschlüsseln.

Wenn das richtig ist, würde ich Ihnen dringend empfehlen, die Zusammenfassung noch einmal zu ändern, um dies zu verdeutlichen, denn so sieht es sicher schlecht aus. :)

Hoffentlich hat ein Angreifer, der sich Zugang zum Server verschafft, keinen Zugriff auf das Klartext-Passwort. Das Schlimmste, was sie tun können, ist zu versuchen, das "Benutzerpasswort" zu erraten oder zu erraten, das verwendet wird, um die Hauptverschlüsselungs- und Authentifizierungsschlüssel für das Repository zu entschlüsseln.

Ich vermute, es hängt vom genauen Szenario ab: Wenn Sie das Passwort manuell eingeben, richtig. Wenn Sie hingegen geplante automatische Backups durchführen, muss das "Benutzerpasswort" irgendwo auf dem Server gespeichert werden.

Und natürlich könnte ein Angreifer die Restic-Binärdatei durch eine ersetzen, die das eingegebene Passwort preisgibt, und darauf warten, dass Sie es eingeben. Einem kompromittierten System kann man nicht vertrauen.

das "Benutzerpasswort" muss irgendwo auf dem Server gespeichert werden.

mit "Server" meinen Sie "die Maschine, auf der wir die Daten speichern" oder "die Maschine, die die Daten aus dem Backup empfängt/speichert"?

es ist ziemlich zweideutig und die Quelle meiner Bedenken: Es macht mir nichts aus, dass der Backup- Client (die Maschine, die wir sichern und auf der Restic läuft) das Passwort im Klartext hat: Der gesamte Datensatz ist sowieso da, also wenn er kompromittiert ist, sind die Daten sowieso kompromittiert. Ich hoffe aber, dass der Backup- Server keinen Zugriff auf den Klartext hat!

mit "Server" meinen Sie "die Maschine, auf der wir die Daten speichern" oder "die Maschine, die die Daten aus dem Backup empfängt/speichert"?

Die Maschine, auf der wir laufen, hängt davon ab, auf der wir die Daten speichern.

Ich verstehe Ihren Punkt, Sie haben Recht, er ist mehrdeutig. Mein Verständnis von allem, was ich über das Modell von Restic weiß, ist dasselbe wie Ihres, da bin ich mir ziemlich sicher, aber ich kann Ihnen nicht die definitive Bestätigung geben, die Sie wollen.

In der Zusammenfassung wird die Option --append-only für den REST-Server erwähnt. Vielleicht sollte dies die einzige offiziell empfohlene Methode für das Nur-Anhängen-Backup bleiben, aber es könnte gut sein, zu dokumentieren, welche Dateien in Restic für den normalen Betrieb beschreibbar sein müssen, um herauszufinden, wie andere Ansätze eingerichtet werden können.

Ich glaube, dass restic backup in Ordnung wäre, wenn data , index , keys und snapshots das Erstellen, aber nicht das Ändern oder Löschen von Dateien erlaubt ( und config wurde ebenfalls geschützt). Ich denke jedoch, dass locks das Löschen zulassen müsste, damit das Repository nicht dauerhaft gesperrt wird. Außerdem sind einige Nur-Anhängen-Implementierungen (wie das Attribut für ext4- und xfs-Dateisysteme) nicht rekursiv, sodass die 256 zweistelligen Unterverzeichnisse von data zuerst vorgeneriert werden müssten und dann das Attribut auf sie gesetzt werden.

Einige Backends wie S3 unterstützen nicht nur das Anhängen, sondern unterstützen die Objektversionierung, die den gleichen Effekt erzielen könnte. Dies erfordert jedoch eine sorgfältige Überprüfung des Zugriffskontrollmodells. B2 verfügt beispielsweise über Lebenszyklusregeln, die eine Objektversionierung ermöglichen, aber der zum Sichern auf B2 erforderliche API-Schlüssel kann die Lebenszyklusregeln ändern (B2 hat noch nicht wirklich viel von einem Berechtigungssystem).

Beiseite: Ich mag etwas übersehen, aber wenn die asymmetrische Verschlüsselung nur historische Daten vor einem Angreifer schützt, der den Client kompromittiert hat, scheint dies eine niedrige Priorität zu haben. Es wäre schön, aber in den meisten Fällen sind die aktuellen Daten wertvoller als frühere Versionen (obwohl manchmal etwas Wertvolles versehentlich gesichert, gelöscht, aber nicht gelöscht wird).

@willsALMANJ gute Beobachtungen. Für S3 frage ich mich, ob die Einwandversionen aufgezeichnet werden könnten, um eine kohärente Ansicht der Blobs abzurufen, die zum Wiederherstellen eines bestimmten Snapshots erforderlich sind (obwohl Sie sie basierend auf ihrem Inhalt validieren können, also nicht sehr wichtig).

Re: Dein letzter Absatz:

• Der Hauptvorteil der asymmetrischen Verschlüsselung besteht neben dem von Ihnen erwähnten Szenario des "Entschlüsselns historischer Dinge" darin, dass Sie Backups von mehreren unabhängigen Computern im selben Backup-Repository speichern können, ohne einzelne Schlüssel bereitstellen zu müssen (was erfordert, dass der Backup-Schlüssel jedes Mal irgendwo gespeichert wird einen neuen Client-Rechner installieren). Wenn Sie einen gemeinsamen Schlüssel verwenden, erhalten Sie das lästige Bedrohungsszenario, bei dem Client1 die Daten von Client2 lesen kann, was nicht ideal ist.

@fd0 Ich denke, ich habe ein anständiges Schema für die asymmetrische Verschlüsselung mit HMAC-Adressierung mit abgeleiteten gemeinsamen Geheimnissen. Auch einige Ideen zur serverseitigen Garbage Collection ohne Datenlecks, ich bin mir nicht sicher, ob Sie interessiert sind, aber wenn Sie es sind, würde ich gerne darüber sprechen.

Ich weiß nicht, ob ich hier etwas übersehe, aber ich führe restic erfolgreich mit dieser Richtlinieneinstellung auf S3-Speicher aus. Es hindert einen Angreifer nicht daran, die Daten zu lesen, aber es hindert ihn am Löschen.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

Die Bereinigungs-/Forget-Befehle werden dann von einem vertrauenswürdigen Gerät ausgeführt, das über Schreibberechtigungen verfügt. Ich erstelle auch zwei Schlüssel in jedem Restic-Repository. Eine für den Server und eine für das vertrauenswürdige Gerät, damit das vertrauenswürdige Gerät einen Angreifer aussperren kann (der Angreifer jedoch nicht, da er in Schlüsseln/* nicht löschen kann).

Edit: Sorry, habe übersehen, dass das schon besprochen wurde. Wollte diesen Thread nicht kapern.
PutObject ist tatsächlich in der Lage, Objekte zu überschreiben, daher ist dies keine Lösung zum Schutz von Backups .

@freswa Ich bin kein S3-Experte, daher bin ich mir nicht sicher, ob dies richtig ist, aber der Punkt, der oben in dieser Diskussion erwähnt wurde, ist, dass die Berechtigung PutObject zum Überschreiben Ihrer Daten verwendet werden kann, was genauso schlecht ist als löschen. In meinem obigen Beitrag habe ich festgestellt, dass Sie dieses Problem umgehen können, indem Sie die Objektversionsverwaltung verwenden (geben Sie dem Backup-System keinen Zugriff zum Löschen von Versionen).

@andrewchambers Ich bin ein bisschen mit anderen

Bei diesem Problem geht es also (eventuell) darum, asymmetrische Backups zu implementieren, nicht auf die Zugriffskonfiguration für den Backend-Speicher. Vielen Dank! :)

@fd0 Hoffentlich erklärt dies, was ich meinte https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : Nur für den Fall, dass Sie noch nicht auf das Nur-Schreiben-Problem https://github.com/ncw/rclone/issues/2499.

@andrewchambers danke fürs Aufschreiben, ich bin sehr daran interessiert, wie die tatsächliche Implementierung aussieht. Der Blogpost hat einige interessante Stellen offen gelassen :)

Ich mag es, dass es einen weiteren Konkurrenten im Bereich der kostenlosen Software-Backup-Programme geben wird. Es ist immer großartig, Benutzern mehr Optionen zu geben!

So lässt sich eine interessante Parallele zu den beiden Verschlüsselungsmechanismen des Git-Repositorys ziehen.

Auf der einen Seite haben Sie git-crypt : Dies verwendet git smudge/clean-Filter, um (bzw.) Dateien zwischen dem Blob-Speicher und der ausgecheckten Kopie zu verschlüsseln / zu entschlüsseln. Das funktioniert gut und ist ziemlich optimal, hat aber eine eklatante Lücke: Die Git-Commits selbst sind nicht verschlüsselt, nur der Inhalt der Blobs, was bedeutet, dass Dateinamen, Commitlogs, Autoren, Datumsangaben und andere Metadaten klar gespeichert werden. Das ist für viele Anwendungsfälle ein No-Go und ist nur effektiv, wenn Sie ein öffentliches Repository haben, in dem Sie (sagen wir) einige Bits (aber nicht alle) verschlüsseln möchten.

Auf der anderen Seite haben Sie git-remote-gcrypt : das verwendet das git remote helpers-Protokoll, um alles zu verschlüsseln,

Nun, das sind git-spezifische Implementierungsherausforderungen, aber ich denke, sie passen gut zu den Problemen, die Sie hier bekommen könnten. Vielleicht bin ich hier völlig überfordert und diese Parallele ist irrelevant, aber ich dachte, sie könnte hier von Interesse sein ...

Abgesehen davon gibt es einen Mittelweg, der derzeit (wahrscheinlich) relativ einfach implementiert werden könnte: Erlauben Sie, dass Schlüssel außerhalb des Repositorys gespeichert werden.

Einer der Angriffsvektoren, der angegangen wird, besteht darin, dass der Angreifer ein Schlüsselpasswort in die Hände bekommt und dann (da die Schlüssel im Repository gespeichert sind) einen Schlüssel problemlos entschlüsseln kann.

Was ist, wenn wir die Angabe eines separaten Schlüsselverzeichnisses zulassen, in dem die Schlüsseldateien gespeichert werden? Dieses Verzeichnis könnte lokal auf jedem Computer gespeichert werden, der Backups durchführen muss, und es könnte selbst bei einem anderen Cloud-Anbieter oder sogar einem QR-Code (~500 Bytes sind genug klein, um QR-codiert zu werden) für die Offline-Speicherung gespeichert werden zum Beispiel in einem Safe.

Wenn die verschlüsselten Schlüssel niemals einen Cloud-Anbieter berühren, verschwindet der Angriffsvektor vollständig. Die Schlüssel müssten beispielsweise von den physischen Räumlichkeiten kompromittiert oder mit Schadsoftware exfiltriert werden.

Dies _kann bereits auf Restic durchgeführt werden_, wenn eine lokale Kopie des Repositorys aufbewahrt wird -- schließen Sie einfach das Schlüsselverzeichnis von der Synchronisierung mit der nicht vertrauenswürdigen Fernbedienung aus, wenn Sie rclone ausführen. Dies ist _nicht_ möglich, wenn keine lokale Kopie vorhanden ist und restic direkt mit der nicht vertrauenswürdigen Fernbedienung interagiert.

Ich denke, wir sollten das Single-Responsibility-Prinzip anwenden und die Dinge in 2 Aufgaben aufteilen:

1. Schützen Sie Ihre Daten vor Entschlüsselung.
2. Schützen Sie Ihre Daten vor unbefugten Löschaktionen.

Es sind 2 verschiedene Aspekte der Datensicherheit. Technisch sind sie nicht aufeinander angewiesen.

Für (1) können wir natürlich "einfach asymmetrische Verschlüsselungsunterstützung hinzufügen". Für (2) gibt es meiner Meinung nach viele mögliche Lösungen (zum Beispiel, wie oben erwähnt, nur S3-Setup zum Anhängen).