Sicherheitsmodell

Diese Seite beschreibt, was die Backups eines Endpoints schützt und wo der Schutz endet. Sie folgt dem Aufbau von Agent und Server. Lesen Sie sie, bevor Sie den Agent breit ausrollen, besonders den Abschnitt über Root-Rechte.

Nur ausgehend

Der Agent öffnet keinen Port, auf dem er lauscht. Er verbindet sich ausgehend per HTTPS mit Ihrer Restow-Instanz und mit nichts sonst. Die Instanz verbindet sich nie mit dem Endpoint. Aufgaben wie „Jetzt sichern“, „Wiederherstellung“ oder „Agent deinstallieren“ reisen in der Antwort auf den regelmäßigen Kontakt des Agents mit der Instanz.

Append-only, von der Instanz erzwungen

Der Agent schreibt in ein restic-Repository, das Ihre Instanz bereitstellt. Die Instanz entscheidet, was der Agent darf, nicht der Agent und nicht restic:

• Der Agent authentifiziert sich mit seinem eigenen Secret. Der Repository-Endpunkt verweigert jedes Löschen und jedes Überschreiben, außer bei den Lock-Dateien, die der Agent selbst geschrieben hat.
• Der Agent ruft selbst auch nie forget, prune oder eine andere Löschoperation auf.
• Aufbewahrung, Prune und Integritätsprüfungen laufen nur auf dem Restow-Server.
• Die Integrationstests lassen den echten Agent gegen den Append-only-REST-Server von restic laufen und stellen sicher, dass restic forget --prune mit den Zugangsdaten des Agents fehlschlägt und die Snapshots unverändert bleiben.

Weitere Schutzmaßnahmen des Repository-Endpunkts:

• Objektnamen müssen ein SHA-256 in Hex sein, sodass kein Pfad das Repository verlassen kann. Der Server prüft beim Hochladen, dass der Inhalt zum Namen passt, und speichert nichts, wenn er nicht passt.
• Bodys über 128 MiB werden abgelehnt. Anfragen sind je Endpoint begrenzt, falsche Zugangsdaten je Adresse.
• Jeder Versuch eines Agents, etwas Verbotenes zu tun, wird im Audit-Log protokolliert (endpoint.repository.denied, höchstens ein Eintrag je Endpoint und Art alle 10 Minuten). Ein Rechner, der versucht, seine Backups zu löschen, ist ein Fall für einen Administrator.
• Ein gesperrter Endpoint wird abgewiesen und sichert nicht mehr. Ein Mandant, der gesperrt ist, wird ebenfalls abgewiesen.

Der Agent hält nie Zugangsdaten des Speicherziels

Der Agent kennt sein eigenes Agent-Secret und das Repository-Passwort seines eigenen Repositorys. Er erhält nie die Zugangsdaten des Speicherziels, etwa S3-Schlüssel oder Mount-Pfade. Er hat keinen Zugriff auf andere Endpoints oder auf das Speicherziel selbst.

Der Agent sendet sein Secret an das Repository, deshalb nimmt er ein Repository nur auf dem Host Ihrer Restow-Instanz an (gleiches Schema und gleicher Hostname), gleich was die Antwort auf das Enrollment oder seine eigene state.json sagt. Eine Repository-Adresse auf einem anderen Host wird abgelehnt, und die Zugangsdaten gehen nie dorthin.

Die Aufbewahrung entscheidet der Server

Aufbewahrung und Prune laufen auf dem Server, und der Server entscheidet anhand von Fakten, die er selbst kontrolliert, was sie entfernen, nicht anhand dessen, was ein Rechner schreibt. Die Zeit in einem restic-Snapshot stammt vom Rechner und entscheidet deshalb nichts:

• Der Server listet die Snapshot-Dateien im Speicher und zählt nur Snapshots, die ein Sicherungslauf gemeldet hat.
• Jeden datiert er auf den früheren von zwei Zeitpunkten: wann der Speicher seine Datei erhalten hat (das kann der Agent weder setzen noch ändern, weil ein vorhandenes Objekt nie überschrieben wird) und wann der meldende Lauf endete, wie der Server es aufgezeichnet hat.
• Auf diese Daten wendet er die Aufbewahrungsregeln an (standardmäßig 30 täglich, 12 wöchentlich, 12 monatlich), in der Zeitzone des Mandanten, lässt restic genau die gewählten Snapshots vergessen und räumt danach auf.
• Snapshots, die kein Lauf gemeldet hat oder die in der Zukunft datiert sind, werden nie gelöscht. Sie werden in den Wiederherstellungspunkten markiert und einmal mit dem Alarm endpoint.suspicious_snapshot gemeldet.

Ein kompromittierter Rechner kann die Aufbewahrung also nicht dazu bringen, echte Backups zu löschen, indem er Snapshots mit Zeiten in der Zukunft schreibt. Ein Rechner, der weiter täglich Unsinn sichert und meldet, verdrängt nach 30 Tagen die echten täglichen Snapshots. Die wöchentlichen und monatlichen bleiben, und die Restore-Tests werden rot. Das ist dieselbe Grenze wie bei jedem Rechner, der Unsinn sichert.

Seit 0.4.0 kommen zwei weitere Schichten hinzu. Die Ransomware-Erkennung beurteilt jeden neuen Sicherungsstand eines Rechners, und solange ein Rechner einen ungeklärten verdächtigen Sicherungsstand hat, ist seine Aufbewahrung angehalten: Nichts wird vergessen oder bereinigt, bis eine Administration den Befund als Fehlalarm markiert oder die Aufbewahrung freigibt. Sie ist eine Heuristik und beurteilt, was die Sicherung an Änderungen gesehen hat; ein Rechner, der langsam oder in einer Weise sichert, die gewöhnlich aussieht, kann sie also passieren. Bei einem Repository mit unveränderbaren Backups weigert sich außerdem der Speicher, gesperrte Objekte zu löschen, wer auch immer fragt.

Speicherbudgets und Sperren

• Speicherbudgets. Jedes Endpoint-Repository hat ein Budget (RESTOW_ENDPOINT_QUOTA_GIB, Standard 2 TiB, je Rechner einstellbar), und alle Endpoints eines Mandanten teilen sich ein weiteres (RESTOW_ENDPOINT_TENANT_QUOTA_GIB, Standard 20 TiB). Ein Upload, der nicht passt, wird abgelehnt, ein Rechner füllt das Speicherziel also höchstens bis zu seinem Budget. Lock-Dateien zählen nicht mit, Wiederherstellungen funktionieren also weiter. Siehe Überblick.
• Wem eine Sperre gehört. Der Server merkt sich jede Lock-Datei, die ein Agent schreibt, und lässt den Agent nur diese löschen. Jede andere Sperre, etwa die exklusive Sperre des Servers während eines Prune, bleibt, und der Versuch steht im Audit-Log (endpoint.repository.denied, Grund foreign_lock).
• Verwaiste Sperren. Vor der Aufbewahrung und der Repository-Prüfung entfernt der Server Lock-Dateien, die der Speicher vor mehr als 30 Minuten erhalten hat, gleich was in ihnen steht. restic schreibt für eine Sperre, die in Gebrauch ist, alle fünf Minuten eine neue Lock-Datei.
• Eine Wartung nach der anderen. Die eigenen Arbeiten des Servers an einem Repository überschneiden sich nie: Aufbewahrung und Prüfung halten es exklusiv, Restore-Tests, Snapshot-Listen, Durchsuchen und Downloads teilen es sich. Ein Rechner kann die Wartung weiterhin aufhalten, indem er einen Lauf offen hält und seine Sperren erneuert, wie es eine sehr lange Sicherung tut, aber nicht unbemerkt: Sechs gesperrte Versuche in Folge über mindestens 12 Stunden lösen endpoint.repository_locked aus, und ein Lauf ohne Fortschritt wird nach sechs Stunden geschlossen.

Ein Repository und ein Passwort pro Endpoint

Der Server erzeugt das Repository-Passwort, speichert es mit dem Mandantenschlüssel verschlüsselt und gibt es beim Enrollment an den Agent. Weil der Server es behält, kann ein Administrator auch dann wiederherstellen, wenn der Endpoint nicht mehr existiert. Der Server legt das Passwort außerdem versiegelt mit dem Mandantenschlüssel neben das Repository, sodass Master-Key und Speicher für einen Restore ohne Datenbank genügen. Siehe Restore.

Wie der Server das Repository erreicht

Aufbewahrung, Repository-Prüfungen, Restore-Tests, Durchsuchen, Downloads und das Anlegen des Repositorys brauchen mehr als Append-only-Zugriff. Sie laufen als restic-Prozesse auf dem Server, über einen Listener auf 127.0.0.1, der genau eine Operation lang lebt. Seine Zugangsdaten sind für diesen einen Listener zufällig und gehen über die Umgebung an restic. Es gibt keinen öffentlich erreichbaren Wartungszugang und kein gespeichertes Wartungs-Passwort. Diese restic-Prozesse erhalten nur PATH, TMPDIR und die RESTIC_*-Variablen, nicht die Umgebung des Servers, sie sehen also weder die Datenbank-URL noch den Master-Key.

Geheimnisse

Geheimnis	Wo es liegt	Wie
Enrollment-Token	Einmal angezeigt, neben dem Installationsbefehl, nicht darin	24 Stunden gültig, einmal verwendbar. Restow speichert nur einen SHA-256-Hash. Das Installationsskript liest es mit verdeckter Eingabe oder aus einer Datei, die nur root lesen kann, und übergibt es restow-agent enroll in der Umgebung dieses einen Prozesses. Es erscheint nie in einer Kommandozeile, einer URL oder einem Log. Der Agent entfernt es sofort aus der Umgebung.
Agent-Secret	/etc/restow-agent/state.json auf dem Endpoint	Auf dem Server nur als SHA-256-Hash gespeichert.
Repository-Passwort	/etc/restow-agent/state.json auf dem Endpoint	Auf dem Server mit dem Mandantenschlüssel verschlüsselt, und neben dem Repository im Speicherziel, versiegelt mit dem Mandantenschlüssel.

• Ruhend auf dem Endpoint. /etc/restow-agent/state.json enthält Agent-Secret und Repository-Passwort im Klartext. Die Datei hat Modus 0600 in einem Ordner mit Modus 0700, Besitzer root. Der Agent korrigiert zu offene Berechtigungen und verweigert eine Datei, die jemand anderem gehört. Sonst wird nichts Geheimes gespeichert. status.json ist für alle lesbar und enthält keine Geheimnisse.
• In Benutzung. restic erhält Repository-Passwort und REST-Zugangsdaten nur über Umgebungsvariablen, nie in einer Kommandozeile. Kindprozesse (restic und Hooks) erben nur eine kurze Liste von Variablen.
• In Logs. Alles, was der Agent protokolliert, das an den Server gesendete Log-Ende und Fehlermeldungen laufen durch eine Schwärzung. Sie maskiert die genauen Geheimnis-Werte, Tokens, Authorization-Header, Zugangsdaten in URLs und NAME=wert-Paare, deren Name auf ein Geheimnis hindeutet. Ein Hook, der ein eigenes Geheimnis ausgibt, wird nicht erfasst, siehe Profile, Zeitplan und Hooks.
• Auf dem Server. Keines dieser Geheimnisse erscheint in Logs oder Audit-Details, und Fehlermeldungen von restic werden geschwärzt. Auf die Schwärzung des Agents verlässt sich der Server nicht: Bevor er einen Lauf-Bericht speichert, schwärzt er Fehlermeldungen und Log-Ende erneut, auch einzelne Werte mit den Präfixen rset_, rsea_ und rsk_ sowie Variablen, deren Name auf Zugangsdaten hindeutet, etwa PGPASSWORD=. Ein Hook oder restic kann alles ausgeben.

Integrität dessen, was installiert wird

Signierte Releases. Jedes Agent-Release (Agent, restic und die Lizenzhinweise THIRD_PARTY_NOTICES.txt, für jede Plattform) ist vom Maintainer mit einem Ed25519-Schlüssel signiert, der dessen Rechner nie verlässt. Die Signatur hat das OpenSSH-Format (ssh-keygen -Y sign, Namensraum restow-agent-release) und deckt die SHA256SUMS des Releases ab, die das SHA-256 jeder Datei auflistet. Der öffentliche Schlüssel (Fingerabdruck SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o) ist in den Agent einkompiliert und steht in den Installationsskripten. Eine kompromittierte Restow-Instanz kann einen installierten Agent deshalb nicht dazu bringen, eine eigene Binärdatei auszuführen.

• Das Installationsskript prüft die Signatur mit ssh-keygen -Y verify (OpenSSH 8.1 oder neuer) oder OpenSSL 3, danach das SHA-256 beider Binärdateien und der Lizenzhinweise, bevor es irgendetwas ausführt. Es gibt den Fingerabdruck des Release-Schlüssels aus, gegen den es geprüft hat. Siehe Installation.
• Das Selbst-Update. Der Agent prüft alle 6 Stunden auf eine neuere Version. Zuerst lädt er SHA256SUMS und SHA256SUMS.sig des Releases von Ihrer Instanz und prüft die Signatur gegen den einkompilierten Schlüssel. Von einem unsignierten oder falsch signierten Release wird nichts verwendet. Dann lädt er die Lizenzhinweise, restic (wenn das Release ein anderes festlegt) und den Agent in dieser Reihenfolge vom selben Host, prüft jede Datei gegen ihr signiertes SHA-256, legt sie unter einem Zufallsnamen im root-eigenen Ordner ab, startet version des neuen Agents erst nach diesen Prüfungen und ersetzt erst dann die aktuelle Binärdatei. Die alte bleibt als restow-agent.prev erhalten. Updates werden nur angewendet, solange kein Lauf aktiv ist, und ein Mandant kann sie mit Automatische Agent-Updates auf der Seite Inventar (Server & Clients → Inventar) pausieren.
• restic ist auf Version 0.19.1 festgelegt, mit Prüfsummen, die gegen die GPG-signierte SHA256SUMS des offiziellen Releases geprüft wurden.

Root-eigene Installation. Die Binärdateien liegen in /opt/restow-agent/bin unter Linux und in /Library/Application Support/Restow/bin unter macOS, die Lizenzhinweise einen Ordner darüber (/opt/restow-agent/THIRD_PARTY_NOTICES.txt, /Library/Application Support/Restow/THIRD_PARTY_NOTICES.txt, für alle lesbar). Das Installationsskript und der Agent prüfen jeden Ordner des Pfades: Jeder muss root gehören und darf weder für die Gruppe noch für andere schreibbar sein. Sonst verweigert das Skript die Installation. /usr/local/bin/restow-agent ist nur ein Link für Administratoren, und nur dort, wo /usr/local/bin root gehört, denn ein Link in einem Ordner, den ein Benutzer kontrolliert, ließe sich austauschen und dann mit sudo ausführen.

Der Agent tut nichts, bis seine Installation sicher ist. Vor allem anderen prüft der Agent, dass seine Binärdatei, restic und jeder Ordner darüber root gehören und für andere nicht schreibbar sind. Ist das nicht so, führt er kein Backup, keine Aufgabe und keinen Hook aus, schreibt den Grund alle 30 Minuten in sein Log und versucht es alle 5 Minuten erneut. Erneutes Ausführen des Installationsbefehls repariert die Installation.

Grenze: die erste Installation. Die erste Installation vertraut dem Installationsskript, das Ihre Instanz ausliefert, wie jedes curl | sh. Um in diesem Moment eine kompromittierte Instanz auszuschließen, vergleichen Sie den Fingerabdruck, den das Skript ausgibt, mit SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o (steht auch in den Release Notes), oder prüfen Sie das Release von Hand. Siehe Installation.

Der Agent läuft als root

Der Agent muss jede Datei lesen, die er sichert, und Restores überall hin schreiben, deshalb läuft er als root, und das Dateisystem bleibt für ihn vollständig sichtbar und beschreibbar.

Hooks brauchen die Zustimmung des Rechners. Hooks sind in Restow eingestellte Befehle, die der Agent vor und nach einem Backup als root ausführt. Ob ein Rechner sie ausführt, entscheidet root auf dem Rechner, und Restow kann das nicht ändern:

• off (Standard): Kein Hook aus Restow läuft. Ein trotzdem eingestellter Hook wird übersprungen, und das Backup ist teilweise.
• scripts: Nur Skripte, die root in /etc/restow-agent/hooks.d abgelegt hat und die der Hook nennt, laufen, direkt, ohne Shell und ohne Argumente.
• any: Jeder Befehl läuft über /bin/sh -c. Mit dieser Regel kann jeder, der die Einstellungen des Endpoints in Restow ändern darf, Befehle als root auf diesem Rechner ausführen.

Restow zeigt die Regel jedes Rechners, nimmt für einen scripts-Rechner nur Skriptnamen an und lehnt Hook-Einstellungen ab, die der Rechner nicht ausführen würde. Einen Hook zu setzen oder zu ändern erfordert außerdem eine Anmeldung aus den letzten 10 Minuten. Diese Prüfung kommt zur Zustimmung des Rechners hinzu, sie ersetzt sie nicht. Siehe Profile, Zeitplan und Hooks.

Härtung des Dienstes. Die systemd-Unit ergänzt, was ein Backup-Agent, der alles liest und überall hin wiederherstellt, noch zulässt: NoNewPrivileges, ProtectKernelTunables, ProtectKernelLogs, ProtectControlGroups, ProtectHostname, kein Laden von Kernelmodulen, RestrictNamespaces, RestrictRealtime, LockPersonality, nur native Systemaufrufe und UMask=0077. Unter macOS setzt der LaunchDaemon die Umask 077. ProtectSystem, ProtectHome und PrivateTmp werden bewusst nicht genutzt, weil Backups beliebiger Pfade und Restores dorthin das ganze Dateisystem brauchen. Hooks erben die Härtung: Ein Hook, der Namespaces braucht (rootlose Container) oder Kernelmodule lädt, läuft nicht.

Der Dienst läuft mit niedriger CPU- und I/O-Priorität und wird von systemd oder launchd neu gestartet, wenn er stoppt.

Wer was darf

Die meisten Endpoint-Funktionen in der Weboberfläche und der API verlangen einen Mandanten-Administrator oder einen Provider-Administrator. Seit 0.4.0 ist ein Teil auch der Restore-Rolle offen: Restore-Operatoren (Mitgliedsrolle „restore“) öffnen Server & Clients → Datei-Restore, listen die Rechner des Mandanten auf, lesen die Sicherungsstände eines Rechners und ob sie unveränderbar sind, durchsuchen sie, laden Dateien als ZIP herunter und stellen Dateien auf dem Rechner wieder her. Sichern (es antwortet 403), Einstellungen, Tokens, Jobs, Restore-Tests, Sperren, Deinstallieren und das Repository-Passwort bleiben bei den Administrationen, und jedes Lesen, jeder Download und jede Wiederherstellung wird mit dem Operator als Akteur im Audit-Log festgehalten. Siehe Was ein Restore-Operator erreicht. Die Rollen des Provider-Teams sind so aufgeteilt:

Provider-Rolle	Darf
Nur lesen	Liste, Details, Läufe und Wiederherstellungspunkte sehen.
Techniker	Jetzt sichern, Restore, Restore-Test, gesicherte Dateien durchsuchen und herunterladen.
Administrator	Installationsbefehle erstellen und widerrufen, Konfiguration und Hooks ändern, Endpoints sperren und deinstallieren, gesperrte Rechner aus Restow entfernen (mit frischer Anmeldung), das Repository-Passwort anzeigen.

Die Rollen selbst beschreibt Team und Rollen.

• Richtlinie der Agenten (seit 0.4.0: ein Sicherungsfenster, Verpasste Sicherungen nachholen, ein Upload-Limit, Nur am Netzteil und Automatische Wiederholungen) wird auf drei Ebenen festgelegt, siehe Richtlinie der Agenten. Sie ändert, wann und wie schnell ein Agent sichert, nicht, was er mit dem Repository tun darf: Die Append-only-Regeln oben bleiben, wie sie sind. Jede Änderung wird im Audit-Log festgehalten (settings.agent_policy.updated, tenant.agent_policy.updated, endpoint.config.changed).
• Hook-Texte sehen nur, wer die Einstellungen des Endpoints ändern darf. Nur lesen und Techniker sehen, ob ein Hook eingestellt ist, und einen kurzen Fingerabdruck.
• Eine frische Anmeldung ist nötig, um einen Hook zu setzen oder zu ändern und um das Repository-Passwort anzuzeigen: eine Anmeldung aus den letzten 10 Minuten mit Passkey, Passwort mit Code aus der Authenticator-App oder Single Sign-on (OIDC). Sonst bittet Restow Sie zuerst zu bestätigen, dass Sie es sind (recent-sign-in-required). Alle Hooks eines Rechners zu entfernen erfordert keine Bestätigung.

Was ein kompromittierter Endpoint kann und nicht kann

Der Endpoint hält Passwort und Zugangsdaten seines eigenen Repositorys, weil er schreiben und für Restores lesen muss. Wer root auf dem Endpoint hat, kann deshalb:

• neue Backups hinzufügen, auch Müll (Restore-Tests und Repository-Prüfungen bewerten das, die Aufbewahrung räumt auf),
• sein eigenes Repository lesen und damit entschlüsseln,
• kein Backup löschen oder überschreiben und keine neue Repository-Konfiguration schreiben. Das erzwingt die Instanz,
• nicht erreichen, dass die Aufbewahrung echte Backups löscht, denn der Server entscheidet nach seinen eigenen Aufzeichnungen, nicht nach den Zeiten in den Snapshots,
• keine Sperre des Servers lösen und die Wartung nicht unbemerkt aufhalten,
• das Speicherziel nicht über das Speicherbudget des Rechners hinaus füllen,
• nicht auf andere Endpoints, andere Mandanten oder das Speicherziel zugreifen.

Ein gestohlenes Agent-Secret ergibt dasselbe: neue Backups in das Repository dieses Endpoints schreiben und es lesen, aber nichts löschen. Um es abzuschneiden, sperren Sie den Endpoint in Restow.

Audit-Log

Jedes Lesen gesicherter Dateien und jede Änderung wird im Audit-Log protokolliert, in jeder Edition. Das Ansehen des Logs (Liste, Filter, Details, Kettenprüfung) gehört zu Business und Service Provider und ist verfügbar, ebenso seit 0.3.1 der Audit-Log-Export (CSV, JSON mit Hashes). Siehe Audit-Log.

Aktion	Wird protokolliert, wenn
endpoint.token.created, endpoint.token.revoked	Ein Installationsbefehl erstellt oder widerrufen wird.
endpoint.enrolled	Ein Rechner sich anmeldet (Hostname, System, Architektur, Profil, Token-ID, nie ein Geheimnis).
endpoint.config.changed	Einstellungen sich ändern. Bei Hooks ein Fingerabdruck, nicht der Text.
endpoint.backup.requested, endpoint.restore_test.requested	Jemand ein Backup oder einen Restore-Test startet.
endpoint.backup.cancelled	Jemand eine laufende Sicherung stoppt oder eine angeforderte zurückzieht (seit 0.4.2).
endpoint.update_requested	Jemand Auf X.Y.Z aktualisieren für einen Rechner wählt oder das Server-Update ihn zum Aktualisieren auffordert (seit 0.4.2).
endpoint.snapshot.browsed, endpoint.snapshot.downloaded	Gesicherte Dateien durchsucht oder heruntergeladen werden.
endpoint.restore.requested, endpoint.restore.finished	Ein Restore auf den Rechner angefordert wird und wenn er endet.
endpoint.repository.password.revealed	Jemand das Repository-Passwort anzeigt.
endpoint.uninstall.requested, endpoint.revoked	Eine Deinstallation angefordert oder ein Endpoint gesperrt wird.
endpoint.removed, endpoint.removal.held, endpoint.removal.deferred, endpoint.removal.completed, endpoint.removal.failed	Ein gesperrter Rechner aus Restow entfernt wird (seit 0.4.5), und was mit seinen Sicherungen geschieht: von einer Legal Hold oder einem Verdacht gehalten, durch eine Speichersperre zurückgestellt, gelöscht oder das Löschen fehlgeschlagen.
endpoint.repository.denied	Ein Agent etwas versucht, das die Append-only-Regeln verbieten, auch eine Sperre zu löschen, die er nicht geschrieben hat (foreign_lock).
endpoint.updates.paused, endpoint.updates.resumed	Automatische Agent-Updates für den Mandanten pausiert oder fortgesetzt werden.

Bekannte Grenzen

• Noch kein mTLS. Version 1 authentifiziert jeden Agent mit einem eigenen Secret über HTTPS. Ein gestohlenes Secret (root auf dem Endpoint) erlaubt, neue Backups in das Repository dieses Endpoints zu schreiben und es zu lesen. Es erlaubt nicht, etwas zu löschen. mTLS je Agent ist für ein späteres Release geplant.
• Die erste Installation vertraut dem Installationsskript. Das Skript kommt von Ihrer Instanz. Vergleichen Sie den Fingerabdruck des Release-Schlüssels, den es ausgibt, mit dem veröffentlichten (SHA256:2LB7RPpIS0wqbcZ2NA8MjuQN7ZfFPqBX3CwrGFSu76o). Danach schützen Signaturen die Binärdateien und jedes Update.
• Root und Hooks. Der Agent und seine Hooks laufen als root. Mit der Hook-Regel any kann jeder, der die Einstellungen des Endpoints in Restow ändern darf, Befehle als root auf dem Rechner ausführen. Bevorzugen Sie scripts.
• Metadaten, die der Agent hinzufügt. restic prune vertraut den Index-Dateien des Repositorys, und der Agent darf neue hinzufügen. Ein kompromittierter Agent könnte Index- oder Snapshot-Dateien anlegen, die restic nicht lesen kann. Dann scheitern Aufbewahrung oder Repository-Prüfung, und die wöchentliche Prüfung bewertet das Repository als beschädigt (scrub.corrupt). Gelöscht wird nichts, was der Server nicht gewählt hat, und ein gescheiterter Aufbewahrungslauf schreibt einen Bericht mit der Fehlermeldung.
• Das Repository-Passwort entschlüsselt das gesamte Backup eines Endpoints. Wer es besitzt und das Speicherziel lesen kann, kann jede gesicherte Datei lesen.
• Append-only erzwingt die Instanz, nicht der Speicher, solange Sie den Speicher nicht sperren. Wer das Speicherziel direkt erreicht, kann Daten löschen. Seit 0.4.0 kann ein Repository unveränderbare Backups haben: Bei einem S3-Bucket mit Object Lock weigert sich der Speicher dann, die Objekte data/, snapshots/, keys/ und config des Repositorys jedes Rechners vor ihrem Datum zu löschen oder zu überschreiben, auch bei jemandem, der den Speicherschlüssel von Restow hat. Es ist aus, bis eine Administration es einschaltet, und wurde gegen einen nachgebauten S3-Dienst getestet, noch nicht gegen einen echten. Die restic-Dateien in locks/ und index/ sind nicht gesperrt (restic repair index baut den Index aus den gesperrten Packs neu auf). Ein Verzeichnis bekommt nur eine Löschverzögerung, die Restow selbst einhält und die keine Unveränderbarkeit ist.