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
83 lines
3.8 KiB
Markdown
83 lines
3.8 KiB
Markdown
# ADR 0019: No security base functions in the application (§52 VSA)
|
|
|
|
- Status: proposed
|
|
- Date: 2026-07-29
|
|
|
|
## Context
|
|
|
|
Dorfteich is to be operable inside an IT environment of a German federal
|
|
authority that is approved under the Verschlusssachenanweisung (VSA), for
|
|
content classified VS-NfD. **No BSI certification of Dorfteich itself is
|
|
sought.**
|
|
|
|
§51 VSA makes products that provide a _Sicherheitsgrundfunktion_ subject to
|
|
certification. §52 VSA enumerates those base functions: encryption, media
|
|
protection (Datenträgerschutz), network termination (Netzabschluss), and
|
|
authentication. A product that implements one of them itself moves into the
|
|
certification obligation — an outcome that would end this undertaking on
|
|
cost grounds alone.
|
|
|
|
Today Dorfteich sits close to the right side of that line, partly by
|
|
accident and partly by design: there is no content encryption, no backup
|
|
encryption, no own MFA, and no cryptographic primitive of our own beyond
|
|
signing short-lived collaboration tokens and hashing credentials. What is
|
|
missing is the _decision_ — so that no future feature crosses the line
|
|
because nobody had written down where it runs.
|
|
|
|
## Decision
|
|
|
|
**Dorfteich does not provide any security base function within the meaning
|
|
of §52 VSA. Encryption, media protection, network termination and
|
|
authentication belong to the operator's platform.**
|
|
|
|
Concretely:
|
|
|
|
1. **No encryption of content**, neither in the database nor on the file
|
|
system. Confidentiality of stored data is provided by the platform
|
|
(full-disk / volume encryption).
|
|
2. **No backup encryption in the application.** Media protection is the
|
|
platform's function; the application restricts _where_ backups may go
|
|
(ADR 0026) and nothing more.
|
|
3. **No own MFA, no own password policy engine.** Authentication is
|
|
delegated to the operator's identity provider (ADR 0021). Local
|
|
passwords remain available for non-VS deployments and are hard-switchable
|
|
off.
|
|
4. **No new cryptographic primitives.** Existing crypto is limited to
|
|
credential hashing (Argon2id), token hashing (SHA-256) and signing
|
|
short-lived tokens, and it uses vetted libraries rather than
|
|
hand-written constructions (ADR 0020).
|
|
5. **No TLS termination, no network segmentation** in the application.
|
|
6. **No application-side separation of classification levels.** Levels are
|
|
separated by operating one instance per level; the application only
|
|
_marks_ content (ADR 0022).
|
|
|
|
The application's contribution to security is a different set of
|
|
properties, and these it does own: a central, default-closed permission
|
|
model; complete absence of outbound connections; verifiable marking of
|
|
classified content in every output channel; and an audit trail.
|
|
|
|
## Consequences
|
|
|
|
- Deliberate non-features must be argued as architecture, not apologised
|
|
for as gaps. "No encryption in the code" is the correct division of
|
|
labour under §52 VSA.
|
|
- Every feature proposal is measured against this ADR. Any change that
|
|
would make the application the bearer of a base function needs to amend
|
|
this ADR first — which is the point of writing it down.
|
|
- The operator carries obligations that must be handed over explicitly and
|
|
in writing. This ADR is therefore the **draft of the delimitation
|
|
statement** (Abgrenzungserklärung) that #226 turns into a
|
|
reviewer-facing document; the two must not diverge.
|
|
- Anything the platform cannot supply because it lacks application
|
|
knowledge stays with us. Two cases exist today: marking of classified
|
|
content (only the application knows the classification, ADR 0022) and
|
|
integrity of the application's own payloads (#199).
|
|
- Residual risks arising from delegation are listed in #231 rather than
|
|
silently accepted.
|
|
|
|
## Implementing issues
|
|
|
|
#226 (delimitation statement), #227 (hardening guide), #228 (security
|
|
documentation), #229 (operations manual), #230 (IT-Grundschutz mapping),
|
|
#231 (residual-risk list).
|