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
136 lines
5.8 KiB
Markdown
136 lines
5.8 KiB
Markdown
# Analyse-Auftrag: VS-NfD-Ist-Aufnahme Dorfteich
|
|
|
|
> Diese Datei in das Repo legen (z. B. `docs/vs-nfd/00-analyse-auftrag.md`)
|
|
> und Claude Code anweisen: _„Arbeite `docs/vs-nfd/00-analyse-auftrag.md` ab."_
|
|
|
|
---
|
|
|
|
## Rahmen
|
|
|
|
**Ziel des Vorhabens:** Dorfteich soll in einer nach VSA freigegebenen
|
|
IT-Umgebung einer Bundesbehörde betrieben werden können — Einstufung
|
|
VS-NfD. Es wird **keine** eigene BSI-Zulassung angestrebt.
|
|
|
|
**Leitprinzip, an dem alles zu messen ist:**
|
|
Dorfteich darf **keine Sicherheitsgrundfunktion im Sinne von §52 VSA selbst
|
|
implementieren**. Verschlüsselung, Authentisierung, Netzabschluss und
|
|
Datenträgerschutz gehören auf die Plattform der Behörde. Jede Stelle, an der
|
|
die Anwendung selbst schützt statt zu delegieren, ist ein Befund.
|
|
|
|
**Diese Analyse ist read-only.** Keine Codeänderungen, keine Refactorings,
|
|
keine Bugfixes. Nur Befunde.
|
|
|
|
---
|
|
|
|
## Arbeitsweise
|
|
|
|
- Jeder Befund braucht einen **Fundort**: `pfad/zur/datei.ts:123`.
|
|
- Wo du unsicher bist, schreib „unklar" statt zu raten. Eine ehrliche
|
|
Wissenslücke ist brauchbar, eine erfundene Antwort ist gefährlich.
|
|
- Keine Verbesserungsvorschläge im Fließtext — dafür gibt es die Spalte
|
|
„Handlungsbedarf".
|
|
- Bewertungsskala pro Befund:
|
|
- **OK** — unkritisch, keine Anpassung nötig
|
|
- **ANPASSEN** — muss geändert werden, aber überschaubar
|
|
- **BLOCKIEREND** — verhindert den Einsatz, bis es gelöst ist
|
|
- **UNKLAR** — nicht abschließend bewertbar
|
|
|
|
---
|
|
|
|
## 1. Sicherheitsgrundfunktionen (höchste Priorität)
|
|
|
|
Beantworte präzise, was die Anwendung **selbst** tut:
|
|
|
|
1. **Authentisierung** — Gibt es eine eigene Benutzer-/Passwortdatenbank?
|
|
Welches Hashing-Verfahren? Existiert bereits OIDC-/SAML-/LDAP-Anbindung
|
|
oder Unterstützung für Client-Zertifikate / Reverse-Proxy-Header?
|
|
2. **Session-Verwaltung** — Eigene Implementierung oder Framework?
|
|
Wo liegen Sessions (Cookie, Server, Redis)? Wie lange gültig?
|
|
3. **Kryptographie** — Wird irgendwo im Code selbst ver-/entschlüsselt
|
|
oder signiert? Suche nach eigenen Krypto-Aufrufen, nicht nur nach
|
|
Bibliotheken. Falls ja: Was, womit, warum?
|
|
4. **Zugriffskontrolle** — Wie ist das Berechtigungsmodell aufgebaut?
|
|
Wo wird es durchgesetzt (zentral im Middleware-Layer oder verstreut)?
|
|
Gibt es Pfade, die es umgehen (API, Suche, Export, Anhänge)?
|
|
5. **Integrität** — Gibt es Prüfsummen, Signaturen, Manipulationsschutz?
|
|
|
|
## 2. Datenhaltung
|
|
|
|
6. Wo liegen Seiteninhalte — Datenbank, Filesystem, beides?
|
|
7. Wo liegen Anhänge und hochgeladene Dateien?
|
|
8. Existiert ein Volltextsuchindex? Welche Technologie, wo persistiert er,
|
|
und enthält er Klartext der Seiteninhalte?
|
|
9. Welche weiteren Kopien der Inhalte entstehen im Betrieb — Caches,
|
|
Thumbnails, Vorschaubilder, Render-Artefakte, Temp-Dateien?
|
|
10. Wie ist die Revisions-/Versionshistorie abgelegt?
|
|
|
|
## 3. Löschen und Vernichtung
|
|
|
|
11. Was passiert beim Löschen einer Seite — Soft- oder Hard-Delete?
|
|
12. Werden dabei erfasst: Revisionen, Anhänge, Suchindex, Caches,
|
|
Thumbnails, Papierkorb, Backlinks?
|
|
13. Gibt es einen Weg, eine Seite samt **aller** Spuren rückstandsfrei zu
|
|
entfernen? Falls nein: Was bleibt konkret übrig und wo?
|
|
|
|
## 4. Ausgehende Verbindungen
|
|
|
|
14. Liste **jede** Stelle, an der die Anwendung eine Verbindung nach außen
|
|
aufbaut oder aufbauen könnte: Update-Checks, Telemetrie, Analytics,
|
|
Crash-Reporting, Lizenzprüfung, Link-Vorschauen, oEmbed, Avatar-Dienste,
|
|
Karten, externe Schriften, Icons, Skripte.
|
|
15. Prüfe auch die gepinnten Fremdmodule (Editor, Flowchart) — laden diese
|
|
zur Laufzeit etwas nach?
|
|
16. Backups: Wohin kann konfiguriert werden? Gibt es eine Einschränkung oder
|
|
ist jedes Ziel erlaubt? Werden Backups verschlüsselt, und wenn ja, wie?
|
|
17. Läuft die Anwendung vollständig ohne Internetzugang? Was bricht?
|
|
|
|
## 5. Ausgabekanäle (für die Kennzeichnungspflicht)
|
|
|
|
18. Liste alle Wege, auf denen Inhalte die Anwendung verlassen:
|
|
Web-Ansicht, Druck, PDF-/DOCX-Export, API, Feeds, Suchergebnisse,
|
|
Anhang-Download, Backup.
|
|
19. Gibt es bereits ein Metadatenmodell pro Seite, in das eine Einstufung
|
|
aufgenommen werden könnte? Wie ist es strukturiert, und wird es an die
|
|
Ausgabekanäle durchgereicht?
|
|
20. Wo genau müsste eingegriffen werden, damit ein Kopf-/Fußaufdruck in
|
|
_allen_ Ausgaben erscheint? Nenne die konkreten Stellen.
|
|
|
|
## 6. Protokollierung
|
|
|
|
21. Was wird heute protokolliert — nur Änderungen oder auch Lesezugriffe?
|
|
22. Wohin (Datei, stdout, DB)? Ist Syslog-/SIEM-Export möglich?
|
|
23. Ist die Aufbewahrungsdauer konfigurierbar?
|
|
24. Landen Inhalte oder personenbezogene Daten in Logs, die dort nicht
|
|
hingehören?
|
|
|
|
## 7. Lieferkette
|
|
|
|
25. Erzeuge eine vollständige Abhängigkeitsliste mit Versionen und Lizenzen.
|
|
26. Welche Abhängigkeiten sind nicht aus EU-/DACH-Quellen oder haben einen
|
|
unklaren Maintainer-Status?
|
|
27. Sind alle Versionen tatsächlich gepinnt — auch transitiv (Lockfiles)?
|
|
28. Wie läuft das Deployment: Container-Images (welche Basis?), Pakete,
|
|
Quellcode? Wäre eine Offline-Installation möglich?
|
|
|
|
## 8. Betriebsmodell
|
|
|
|
29. Ist die Anwendung mandantenfähig oder Single-Tenant?
|
|
30. Welche Konfiguration ist zur Laufzeit änderbar, welche nur beim Deploy?
|
|
31. Gibt es Funktionen, die ein Betreiber hart abschalten kann (Feature-Flags)?
|
|
|
|
---
|
|
|
|
## Ergebnis
|
|
|
|
Schreibe das Resultat nach `docs/vs-nfd/10-ist-aufnahme.md` mit folgendem
|
|
Aufbau:
|
|
|
|
1. **Management-Zusammenfassung** — max. 15 Zeilen. Wie weit ist Dorfteich
|
|
vom Ziel entfernt? Was sind die drei größten Brocken?
|
|
2. **Befundtabelle** — je Zeile: Nr. | Thema | Fundort | Ist-Zustand |
|
|
Bewertung | Handlungsbedarf | grobe Aufwandsschätzung (S/M/L)
|
|
3. **Detailbefunde** — pro Kapitel oben, mit Codeauszügen wo hilfreich
|
|
4. **Offene Punkte** — was du nicht klären konntest und warum
|
|
|
|
Sortiere die Befundtabelle nach Bewertung: BLOCKIEREND zuerst.
|