syncova-backup/docs/immutability.md

# Unveränderlichkeit und Aufbewahrung

Phase 11. Der Teil der Anlage, der Backups gegen den Fall schützt, für den man
sie am dringendsten braucht: Jemand — Ransomware, ein Bedienfehler, ein
kompromittierter Control Server — will sie loswerden.

Der Implementierungsplan setzt für diese Phase eine Grenze, die den ganzen
Aufbau bestimmt:

> Do not claim true immutability if the underlying storage cannot enforce it.

## Die Durchsetzungsstufe wird gemessen, nicht behauptet

„Unveränderlich" ist in Backup-Produkten ein Wort, das oft eine Datenbankspalte
meint: Die Software weigert sich zu löschen, und jeder mit Dateizugriff löscht
trotzdem. Wer darauf eine Ransomware-Strategie baut, verliert seine Backups.

`POST /repositories/{id}/enforcement/measure` stellt deshalb fest, was das
Dateisystem **tatsächlich** verhindert. Die Messung legt Probedateien im
Metadatenverzeichnis an und versucht, sie zu löschen:

| Stufe | Bedeutung |
| --- | --- |
| `none` | Kein Schutz. |
| `advisory` | Nur diese Software hält sich daran. Wer Dateizugriff hat, löscht trotzdem. |
| `filesystem` | Das Dateisystem verweigert die Löschung. Ein Systemverwalter kann den Schutz weiterhin aufheben. |
| `storage` | Die Speicherebene verhindert es (S3 Object Lock, WORM). **Nicht umgesetzt** — wird nie vergeben. |

Der Bericht nennt die Versuche einzeln, nicht nur das Ergebnis:

```json
{
  "level": "filesystem",
  "observations": [
    { "attempt": "Eine Datei mit den Rechten 0400 loeschen", "prevented": false,
      "detail": "Die Loeschung gelang. Dateirechte schuetzen unter POSIX nicht vor dem Loeschen …" },
    { "attempt": "Eine Datei mit Unveraenderlich-Kennzeichen loeschen", "prevented": true,
      "detail": "Das Betriebssystem verweigerte die Loeschung: … operation not permitted" }
  ]
}
```

### Der Irrtum, mit dem diese Phase begann

Der ursprüngliche gehärtete Modus legte Manifeste mit den Rechten `0400` ab und
nannte das Löschschutz. **Das verhindert kein Löschen.** Unter POSIX hängt das
Entfernen einer Datei am Schreibrecht ihres *Verzeichnisses*, nicht an ihren
eigenen Rechten. Gemessen, bestätigt, und als Regressionstest festgehalten
(`TestReadOnlyPermissionsDoNotPreventDeletion`).

Den Löschschutz leistet das Unveränderlich-Kennzeichen des Dateisystems:
`UF_IMMUTABLE` über `chflags` auf macOS/BSD, `FS_IMMUTABLE_FL` über `ioctl` auf
Linux (ext2/3/4, xfs, btrfs; braucht `CAP_LINUX_IMMUTABLE`). Windows kennt nur
ein Schreibschutz-Attribut, das nicht vor Löschung schützt — dort meldet die
Messung `advisory`, statt etwas zu behaupten.

## Was geschützt wird — und warum alles davon

Zwei Angriffsversuche waren zunächst erfolgreich. Beide Male überlebte das
Manifest, und das Backup war trotzdem verloren:

1. **Die Chunks fehlten.** Zurück blieb ein Manifest, das auf nichts mehr zeigte
   — ein Backup, das sich für vollständig ausgibt und leer ist.
2. **Descriptor und Datenschlüssel fehlten.** Die Daten waren da, aber weder als
   Repository erkennbar noch entschlüsselbar. Der Datenschlüssel ist das
   lohnendste Ziel des gesamten Repositorys: Wer diese eine kleine Datei löscht,
   vernichtet jedes verschlüsselte Backup, ohne einen Datenblock anzufassen.

In einem gehärteten Repository trägt deshalb **jede** Datei das Kennzeichen, die
zur Wiederherstellung gebraucht wird:

| Datei | Geschützt | Grund |
| --- | --- | --- |
| `manifests/*.manifest.json` | ja | Das Backup selbst. |
| `manifests/*.hold.json` | ja | Sonst hübe ein `rm` einer kleinen Datei den Legal Hold auf. |
| `chunks/**` | ja | Ohne sie ist das Manifest wertlos. |
| `format/repository.json` | ja | Einstiegspunkt jedes Wiederaufbaus. |
| `metadata/data-key.json` | ja | Ohne ihn ist alles Geheimtext. |
| `indexes/catalog.json` | **nein** | Nur ein Beschleuniger, wird laufend überschrieben und bei Verlust neu gebaut. |

Nachgewiesen: `rm -rf` gegen ein gehärtetes Repository meldet 15 verweigerte
Löschungen, alle geschützten Dateien überleben, und der anschließende
Tiefenscan meldet das Backup als vollständig.

Die Kehrseite steht ausdrücklich hier: **Ein gehärtetes Repository lässt sich
nicht mit `rm -rf` entfernen.** Wer es ausmustern will, hebt den Schutz Datei für
Datei auf (`ReleaseImmutableFlagForMaintenance`). Eine rekursive Fassung gibt es
nicht — sie wäre genau das Werkzeug, das ein Angreifer sucht.

## Aufbewahrungsschutz und Legal Hold

Die Frist eines Repositorys steht in seinem Descriptor, nicht in der Datenbank:
Wer das Repository an einen fremden Server anhängt, soll die geltende Frist
vorfinden und nicht die des neuen Servers untergeschoben bekommen. Ohne Angabe
gelten 30 Tage.

- **Verlängern ja, verkürzen nie** — auch nicht für einen Administrator. Wäre es
  möglich, bestünde der Schutz nur aus einer Zahl, die der Angreifer zuallererst
  ändern würde.
- **Legal Hold** ist unbefristet und endet nicht von selbst. Er verlangt eine
  Begründung: Ohne sie wäre er nach einem Jahr nicht mehr auflösbar, weil sich
  niemand traut, einen Schutz aufzuheben, dessen Anlass unbekannt ist.
- Ein aufgehobener Legal Hold gibt ein Backup **nicht** frei, das noch unter
  Frist steht. Beide Schutzarten gelten nebeneinander.

### Der Schutzvermerk liegt neben dem Manifest

Verlängerung und Legal Hold stehen in `manifests/<id>.hold.json`, nicht im
Manifest. Das Manifest ist mit seinem `ContentHash` **versiegelt** — es ist der
Abschlussvermerk des Backups. Ein Feld darin nachträglich zu ändern machte
entweder den Hash ungültig oder verlangte, ihn neu zu bilden; im zweiten Fall
wäre das Manifest nicht mehr das, was beim Commit geprüft wurde. Beides
untergrübe die Eigenschaft, auf der die gesamte Integritätsprüfung beruht.

Der Vermerk führt seine eigene Historie mit — wer wann was warum geändert hat.
Ein Repository muss ohne Control Server deutbar bleiben, also gehört die Frage
„warum wird das noch gehalten?" ins Repository und nicht nur in die Datenbank.

**Ein unlesbarer Schutzvermerk gilt als Schutz**, nicht als dessen Abwesenheit.
Das ist der gefährlichste Fehlerfall der Phase: Die umgekehrte Auslegung machte
aus einer beschädigten Datei einen Datenverlust.

## Aufbewahrungsregeln

Zwei Formen, kombinierbar (PROMPT.md §16):

```text
7 / 14 / 30 / 90 Tage, 1 Jahr        →  keep_within
GFS: 30 täglich, 8 wöchentlich,      →  keep_daily / keep_weekly /
     12 monatlich, 7 jährlich            keep_monthly / keep_yearly
```

Die Reihenfolge der Prüfungen ist die Sicherheitsarchitektur: Erst **alle**
Gründe zu behalten, dann erst die Löschung. Ein Backup fällt nur heraus, wenn
keine Regel es hält.

- **`keep_last` schützt das letzte vorhandene Backup.** Jede mitgelieferte Regel
  enthält es. Ohne diese Ergänzung löschte „7 Tage" bei einem System, das drei
  Wochen nicht gesichert hat, *jedes* Backup — die Regel träfe genau dann zu,
  wenn man die Daten am dringendsten braucht.
- **Eine Regel ohne jede Haltevorgabe wird abgelehnt**, nicht als „behalte
  nichts" ausgeführt. Der Unterschied ist der zwischen einem Tippfehler und
  einem Datenverlust.
- Wird `keep_last` bei sonst gültiger Regel weggelassen, ergänzt die API eine 1
  **und sagt es** in der Antwort. Eine stille Korrektur der Eingabe fällt sonst
  erst auf, wenn die Regel etwas anderes tut als gedacht.
- **Die Zeitzone gehört zur Regel.** Ohne sie liefe die Tageseinteilung in UTC,
  und wer täglich um 00:30 deutscher Zeit sichert, verlöre systematisch die
  falschen Backups.
- **Der Aufbewahrungsschutz steht über jeder Regel.** Ein fälliges, aber
  geschütztes Backup erscheint im Plan als „wäre fällig, ist aber geschützt" —
  das erklärt, warum der Speicher trotz Aufräumen nicht kleiner wird.

### Elternbackups einer Kette

Bei Syncova trägt **jedes** Manifest die Blockverweise aller Objekte, auch das
einer Zusatzsicherung (Phase 6). Ein Elternbackup zu löschen beschädigt das Kind
nicht. Diese Zusicherung steht seit Phase 11 im Manifest selbst
(`self_contained_restore`).

Der Grund ist ein Fund aus dem Nachweis: Ohne die Angabe wäre in einer
fortlaufenden Kette **jedes** Backup außer dem jüngsten ein Elternteil — die
Aufbewahrung räumte nie auf, während der Betreiber glaubt, eine zu haben. Ein
Manifest ohne das Feld (ältere Läufe, fremde Repositories) bedeutet weiterhin
„unbekannt" und schützt seine Kette.

Der Regressionstest löscht das Elternbackup und liest anschließend jeden Block
des Kindes — die Behauptung allein genügt nicht.

### „Gelöscht, aber nichts frei"

Wegen der Deduplizierung gibt ein gelöschtes Backup nur den Speicher frei, den
kein anderes mehr braucht. Bei wachsenden Daten verweist das jüngste Backup auf
sämtliche Blöcke der älteren; dann werden Backups gelöscht und **kein Byte**
frei. Die Zusammenfassung sagt das ausdrücklich, sonst erzeugt jede solche
Ausgabe eine Rückfrage.

## Endpunkte

| Methode | Pfad | Recht |
| --- | --- | --- |
| GET | `/api/v1/retention-policies` | `repositories.read` |
| POST | `/api/v1/retention-policies` | `retention.write` |
| PATCH | `/api/v1/retention-policies/{id}` | `retention.write` |
| DELETE | `/api/v1/retention-policies/{id}` | `retention.write` |
| POST | `/api/v1/repositories/{id}/retention/preview` | `repositories.read` |
| POST | `/api/v1/repositories/{id}/retention/apply` | `retention.write` |
| POST | `/api/v1/repositories/{id}/enforcement/measure` | `repositories.write` |
| GET | `/api/v1/backups/{id}/protection` | `backups.read` |
| POST | `/api/v1/backups/{id}/retention/extend` | `immutability.manage` |
| POST | `/api/v1/backups/{id}/legal-hold` | `immutability.manage` |
| DELETE | `/api/v1/backups/{id}/legal-hold` | `immutability.manage` |
| DELETE | `/api/v1/backups/{id}` | `backups.delete` |

**Die Trennung von `backups.delete` und `immutability.manage` ist der Kern der
Zugriffssteuerung dieser Phase.** Wer aufräumen darf, darf deshalb noch lange
keinen Aufbewahrungsschutz aufheben: Das Aufheben ist der Schritt, der einem
Angreifer den Weg öffnet. `immutability.manage` haben nur Super Administrator
und Security Administrator.

### Bestätigungen

Zwei Stellen verlangen eine wörtliche Wiederholung:

- `DELETE /backups/{id}` — `confirm_backup_id` wiederholt die Kennung des
  Backups im Repository.
- `POST …/retention/apply` — `confirm_deletion` wiederholt die **Zahl** der zu
  löschenden Backups aus der Vorschau.

Löscht ein Lauf nichts, entfällt die Bestätigung: Ein Ritual ohne Anlass gewöhnt
das Wegklicken an.

## Nachgewiesen

Gegen den laufenden Dienst mit echten Repositories:

| Versuch | Ergebnis |
| --- | --- |
| Durchsetzungsstufe messen | `filesystem`, mit beiden Beobachtungen belegt |
| Backup im gehärteten Repository löschen (Recht + Bestätigung) | 409 — Aufbewahrungsschutz |
| Löschen ohne / mit falscher Bestätigung | 422 |
| Legal Hold ohne Begründung | 422 |
| Frist verkürzen | 422 — „verlängern ja, verkürzen nie" |
| `rm -rf` gegen das gehärtete Repository | 15 Löschungen verweigert, Backup danach vollständig |
| Aufbewahrung: 4 Backups, Regel „nur das letzte" | 2 gelöscht, 2 behalten, Tiefenscan sauber |
| `backup_operator` setzt Legal Hold | 403 |
| Abgewehrter Löschversuch | `BACKUP_DELETION_DENIED` im Audit |

## Bekannte Grenzen

- **Kein S3 Object Lock, kein WORM.** Die Stufe `storage` existiert als Begriff
  und wird von der Messung nie vergeben.
- **Der Schutz gilt gegenüber dem Dienstbenutzer, nicht gegenüber root.** Wer
  Systemverwalter ist, kann das Kennzeichen entfernen. Das steht in jeder
  Erklärung der Stufe `filesystem` — verschwiegen wird es nicht. Ein echter
  Schutz gegen root verlangt ein zweites System (Repository-Appliance mit
  eigenem Benutzerkreis) oder Speicher-WORM.
- **Aufbewahrung läuft nicht nach Zeitplan.** Sie wird über die API angestoßen;
  eine Anbindung an den Scheduler fehlt. Bis dahin gilt: Wer nicht anwendet,
  räumt nicht auf.
- **`minimum_retention_seconds` wird gespeichert, aber noch nicht erzwungen.**
  Die Sperre gegen das Absenken der Repository-Frist fehlt; die Frist eines
  einzelnen Backups lässt sich bereits nicht verkürzen.