patrickandClaude Sonnet 5
0ea129e71c
seal/open (bzw. wrap/unwrap) in allen vier betroffenen Stellen binden ein Additional Authenticated Data an Chiffretext/DEK-Wrapper: ein Austausch zwischen zwei Kontexten faellt beim Entschluesseln auf, statt still zu funktionieren. - dms/internal/crypto/envelope.go + service.go: AAD = Tenant-Slug (bereits vorhandener Parameter in Service.Seal/Open, Signatur unveraendert -- keine der rund 30 externen Aufrufstellen musste angepasst werden) - archive/internal/backupcrypto/envelope.go + reposecret.go/file.go: gleiches Muster, AAD = Tenant-Slug - mail/internal/crypto/envelope.go + service.go + kekversions.go: gleiches Muster, AAD = Tenant-Slug (inkl. ARC-08 KEK-Versionsverwaltung) - internal/kek/master.go + store.go: wrap/unwrap sowie EncryptWithTenantKEK/DecryptWithTenantKEK binden AAD. Die drei echten externen Aufrufer angepasst: ldapsync (Tenant-ID + Zweck), webhook (Ziel-URL des Abonnements), account-api modulekeys (fester Zweck-Bezeichner -- SecretCipher-Interface aus internal/moduletrust reicht keine Datensatz-ID durch, eine Erweiterung wuerde in andere Module hineinwirken, bewusst nicht Teil dieser Kachel) Rueckwaertskompatibel: jedes open/unwrap versucht zuerst mit AAD, faellt bei Fehlschlag auf kein-AAD zurueck -- vor dieser Aenderung versiegelte Datensaetze bleiben lesbar. Bekannte, dokumentierte Grenze: ein Austausch zwischen zwei Datensaetzen DESSELBEN Mandanten/Kontexts bleibt unerkannt (identisches AAD) -- volle Bindung an den einzelnen Datensatz braeuchte eine Datensatz-ID an rund 30 Aufrufstellen, bewusst nicht Teil dieser kleinstmoeglichen Loesung. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
NEXARCH Archive
Zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und
Backup. Dieses Verzeichnis enthält bisher internal/backup (BAK-01,
Datenbank-Backup-Strategie) — weitere Bausteine folgen ticketweise.
BAK-01: Datenbank-Backup
cmd/backup-cli — Aufrufpunkt für systemd-Timer (siehe
../deploy/systemd/nexarch-archive-backup-*.timer):
export NEXARCH_BACKUP_PG_USER=nexarch_backup
export NEXARCH_BACKUP_PG_PASSWORD=...
export NEXARCH_BACKUP_DIR=/var/nexarch-archiv/backups/postgres # NICHT auf einem ephemeren Test-Dataset (siehe Betrieb)
export NEXARCH_BACKUP_KEEP_GENERATIONS=7 # optional, Default 7
backup-cli full # neue Vollsicherung + Verifikation
backup-cli incremental # inkrementelle Sicherung gegen die neueste Generation
backup-cli rotate # entfernt alle bis auf die neuesten N Generationen
Voraussetzung: die konfigurierte Postgres-Rolle braucht das
REPLICATION-Attribut (pg_basebackup nutzt eine
Replikationsverbindung), und summarize_wal = on muss serverseitig gesetzt
sein (PostgreSQL 17s natives inkrementelles Backup, keine WAL-Archivierung
nötig).
BAK-02: Objekt-Storage-Backup
cmd/objectbackup-cli sichert einen lokalen Verzeichnisbaum (den
FDN-03-LocalDriver-Basisordner direkt, oder — für S3-gestützte
Deployments — einen vorgelagerten rclone-Spiegel) mit
restic (Content-defined Chunking, verschlüsseltes
Repository, geprüftes Tooling statt Eigenbau):
export NEXARCH_OBJECTBACKUP_REPO_DIR=/var/nexarch-archiv/backups/objects
export NEXARCH_OBJECTBACKUP_PASSWORD=...
export NEXARCH_OBJECTBACKUP_KEEP_SNAPSHOTS=30 # optional, Default 7
objectbackup-cli backup /var/nexarch-objects # Sicherung + Verifikation
objectbackup-cli check # vollständiges Lesen aller Datenblöcke
objectbackup-cli rotate # restic forget --keep-last N --prune
Betrieb: Backup-Zielverzeichnis
Backup-Ziele liegen unter /var/nexarch-archiv/ (persistentes ZFS-Dataset,
zfs/data/subvol-1131-disk-0 auf 192.168.1.131), NIEMALS unter
/var/nexarch-test/ (ephemeres Dataset, wird von den reset-test-env.sh-
Skripten der anderen Module geleert). ZFS-seitige Snapshots/Replikation
dieses Datasets sind ein eigenständiges Infra-Runbook (siehe
../../STORAGE-KONZEPT.md Abschnitt 7), kein Ticket-Code — zfs dedup=on bewusst NICHT setzen (hoher RAM-Bedarf), Deduplizierung läuft
ausschließlich App-seitig über restic.
Prüfungen
make check # build + vet + lint + test, analog Core/DMS