Claude Opus 5
fd07f716f6
All checks were successful
CI / Lint, typecheck, test (pull_request) Successful in 4m42s
CI / Build container images (pull_request) Successful in 1m11s
CI / Auth e2e pack (pull_request) Successful in 7m47s
CI / Import/export fidelity gate (pull_request) Successful in 55s
CD / Build and push images (push) Successful in 18s
CD / Deploy to Test (push) Successful in 14s
CD / Smoke tests against Test (push) Successful in 1m16s
CD / Promote to Int (push) Successful in 11s
CI / Lint, typecheck, test (push) Successful in 4m50s
CI / Build container images (push) Has been skipped
CI / Auth e2e pack (push) Successful in 7m38s
CI / Import/export fidelity gate (push) Successful in 56s
Add docs/vs-nfd/: the analysis brief, the as-is assessment (42 findings, all verified against the code), the prioritized action plan rev. 2 with issue references written back to every checkbox, the two-stage issue/ADR brief, and the full reviewed draft used to create the forge state. Add eight proposed ADRs 0019-0026 covering the VS-NfD architecture decisions: no security base functions (par. 52 VSA anchor), HKDF token key separation, external authentication, page classification, read-access audit trail (variant A), reproducible offline deployment, plugin trust model, and backup target restriction. Forge state created alongside this commit: 11 labels, milestones M24-M31, issues #188-#236 (docs-only change, no code touched). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Ph5uBmHm8X28CSVpbpnJ
54 lines
2.4 KiB
Markdown
54 lines
2.4 KiB
Markdown
# ADR 0026: Backup target restriction
|
|
|
|
- Status: proposed
|
|
- Date: 2026-07-29
|
|
|
|
## Context
|
|
|
|
Backups are the largest single egress path in the system: the entire
|
|
content of the instance, in one artefact. Today the remote destination is a
|
|
freely configurable WebDAV/Nextcloud URL in `instance_settings`, validated
|
|
as a URL but not restricted to any host, plus an rsync mirror to a private
|
|
host (ADR 0015, issue #84). Anyone with Site-Admin can therefore direct a
|
|
full copy of the instance to an arbitrary server.
|
|
|
|
The tempting answer is to encrypt backups in the application. ADR 0019
|
|
rules that out: media protection is the platform's base function, and
|
|
implementing it here would move Dorfteich into the certification
|
|
obligation under §51 VSA.
|
|
|
|
## Decision
|
|
|
|
1. **A deploy-level allowlist constrains permissible backup
|
|
destinations.** Deploy-level, not a runtime setting, so a compromised
|
|
Site-Admin account cannot widen it.
|
|
2. **An empty allowlist disables every remote target** — WebDAV and rsync
|
|
mirror alike. "Local only" is the VS-NfD reference configuration.
|
|
3. **The admin UI distinguishes "unavailable" from "unconfigured"**, so an
|
|
operator is never left guessing whether a missing backup is a
|
|
misconfiguration or policy.
|
|
4. **No application-side backup encryption**, following ADR 0019. Backup
|
|
media are protected by the platform.
|
|
5. **Integrity of backup artefacts is in scope**, unlike their
|
|
confidentiality: checksums let a restore be verified, which is an
|
|
application concern because only we know what the artefact should
|
|
contain (see #199 for the same reasoning on attachments).
|
|
|
|
## Consequences
|
|
|
|
- Existing deployments that use a remote target must have it added to the
|
|
allowlist, or backups stop. This is a breaking change and is called out
|
|
in the release notes.
|
|
- The delimitation statement (#226) must state plainly that backups leave
|
|
the application unencrypted and that media protection is the operator's
|
|
duty. That sentence will be read closely; it is the correct one.
|
|
- Off-site backup in an airgapped deployment becomes an operator process
|
|
(media handling), not an application feature.
|
|
- Restore stays unchanged, including the maintenance-mode interlock that
|
|
closes collab sessions during a restore.
|
|
|
|
## Implementing issues
|
|
|
|
#192 (allowlist + deploy-level disable). Related: #199 (integrity
|
|
hashes), #229 (backup/restore chapter of the operations manual).
|