[roadmap] Add evidence storage restore drill phase two

CHANGELOG.md

@@ -8,6 +8,9 @@ The project uses release tags for immutable release points. Changes under **Unre
 
 ### Added
 
+- add Evidence Object Storage & Restore Drill Phase 2 with an internal local-filesystem artifact storage abstraction
+- add tenant-scoped Evidence storage overview/detail APIs, bounded storage drill APIs, and storage event filtering without introducing production S3 or cloud credentials
+- extend `/evidence/integrity/` with local storage metadata and administrator/editor Storage-Drill actions
 - add Evidence Integrity & Disposition Phase 1 through additive migration `0033_rust_evidence_integrity_disposition`
 - add tenant-scoped Evidence integrity overview, manual and bounded batch SHA-256 re-check APIs, Legal Hold metadata, disposition decisions, and integrity/disposition audit events
 - add Web UI support under `/evidence/integrity/` for safe Evidence integrity metadata, re-hash actions, Legal Hold set/release, and metadata-only disposition decisions
@@ -31,6 +34,9 @@ The project uses release tags for immutable release points. Changes under **Unre
 
 ### Security
 
+- route Evidence artifact checks through a canonical media-root-contained filesystem backend that blocks traversal, absolute-path references, and symlink escapes
+- audit Evidence storage drills, artifact presence, unreadable/missing artifacts, hash matches, hash mismatches, drill failures, and drill completion without exposing absolute paths, raw payloads, SQL details, or secrets
+- reuse the existing Evidence Integrity metadata and audit table for storage drills, avoiding a new Evidence engine or destructive migration
 - keep Evidence re-hash, Legal Hold, and disposition writes tenant-scoped and restricted to administrator/editor roles while allowing read-only roles to inspect safe metadata
 - audit Evidence integrity checks, hash mismatches, missing artifacts, Legal Hold changes, and disposition decisions without storing raw file payloads, secret values, authorization material, SQL details, or absolute media paths
 - make `disposition_completed_metadata_only` an explicit governance decision state; this release does not physically delete Evidence files or implement data destruction

docs/ISCY_Handbuch.md

@@ -456,6 +456,9 @@ Typische Funktionen:
 - Legal Hold mit Begruendung setzen oder freigeben
 - Disposition-/Retention-Entscheidungen als Governance-Metadaten dokumentieren
 - Integritaets-, Legal-Hold- und Disposition-Ereignisse auditierbar nachvollziehen
+- lokale Evidence-Artefakte ueber eine interne Storage-Abstraktion pruefen
+- Storage-/Restore-Drills fuer Vorhandensein, Lesbarkeit und SHA-256-Konsistenz ausloesen
+- sichere Storage-Fehlerklassen sehen, ohne absolute Dateipfade oder Rohpayloads offenzulegen
 
 Fachlicher Nutzen:
 
@@ -466,6 +469,7 @@ Fachlicher Nutzen:
 - belastbarere Aussage, ob Nachweise nur vorhanden oder wirklich reviewt und verwertbar sind
 - nachvollziehbare Integritaet und Lifecycle-Steuerung ohne pauschal fest codierte gesetzliche Aufbewahrungsfrist
 - klare Trennung zwischen Nachweisqualitaet, Integritaetspruefung, Legal Hold und metadata-only Disposition
+- belastbarer Restore-/Integrity-Nachweis fuer lokal referenzierte Artefakte, ohne produktives Cloud-Storage vorauszusetzen
 
 Fuer Nicht-Sicherheitsleute:
 Evidence ist der Ordner mit den Belegen, aber strukturiert und auswertbar.
@@ -1232,6 +1236,63 @@ Objektspeicher/S3, kontrollierte physische Loeschung, technische
 Datenvernichtung, eine neue Evidence-, Risk-, Control- oder Notification-Engine
 sowie Plattform-, Docker-, Postgres-, nginx-, Nix- oder Dependency-Upgrades.
 
+### 6.13 Evidence Object Storage & Restore Drill Phase 2
+
+Phase 2 fuehrt eine interne Storage-Abstraktion fuer Evidence-Artefakte ein,
+ohne produktives S3, Cloud-Credentials oder ein neues Speichersystem
+einzufuehren. Das erste Backend ist bewusst nur `local_filesystem` und nutzt
+weiter den bestehenden Media Root. Bestehende Uploads und gespeicherte
+Evidence-Pfade bleiben kompatibel.
+
+Die Storage-Schicht kapselt:
+
+- sichere Artefaktreferenzen
+- canonical path containment unterhalb des Media Root
+- Blockade von absoluten Pfaden, Directory Traversal und Symlink-Flucht
+- sichere Metadaten wie Backend, Referenz vorhanden, Artefakt vorhanden,
+  lesbar, leer und Groesse
+- serverseitige SHA-256-Berechnung fuer Drills
+- sichere Fehlerklassen ohne absolute Pfade
+
+Die API ergaenzt:
+
+- `GET /api/v1/evidence/storage`
+- `GET /api/v1/evidence/{evidence_id}/storage`
+- `POST /api/v1/evidence/{evidence_id}/storage-drill`
+- `POST /api/v1/evidence/storage-drills`
+- `GET /api/v1/evidence/{evidence_id}/storage-events`
+
+Der Storage-/Restore-Drill prueft, ob der Evidence-Datensatz tenantgebunden
+existiert, ob eine Artefaktreferenz vorhanden ist, ob das lokale Artefakt sicher
+unterhalb des Media Root erreichbar und lesbar ist und ob der serverseitig
+berechnete SHA-256 mit dem gespeicherten Evidence-Hash uebereinstimmt.
+Fehlende Artefakte, unsichere Referenzen, fehlende erwartete Hashes und
+Hash-Mismatches werden mit sicheren Fehlerklassen klassifiziert.
+
+Die Webansicht `/evidence/integrity/` zeigt Storage-Backend, Artefaktstatus,
+sichere Fehlerklasse, letzten Drill-/Integritaetszeitpunkt und den vorhandenen
+Integrity-, Legal-Hold- und Disposition-Kontext. Admin- und Editor-Rollen
+duerfen Storage-Drills ausloesen. Read-only-Rollen sehen nur sichere
+Metadaten.
+
+Auditereignisse nutzen die bestehende Evidence-Integrity-Ereignistabelle und
+werden als `storage_*` Events geschrieben, darunter Start, Artefakt gefunden,
+Artefakt fehlt, Artefakt nicht lesbar, Hash gueltig, Hash-Mismatch, Drill
+fehlgeschlagen und Drill abgeschlossen. Auditdetails enthalten keine Secrets,
+Tokens, Authorization Header, Rohpayloads, vertraulichen Dateiinhalte,
+SQL-Details, fremden Tenant-IDs oder absoluten Dateipfade.
+
+Fuer Phase 2 ist keine neue Datenbankmigration noetig: Die bestehenden
+Integrity-Felder aus Migration `0033_rust_evidence_integrity_disposition`
+speichern letzten Pruefzeitpunkt, Status, berechneten Hash und sichere
+Fehlerklasse bereits ausreichend. Storage-Events werden in der bestehenden
+Ereignistabelle auditierbar gefuehrt.
+
+Bewusst nicht umgesetzt sind produktives S3/Object Storage, Cloud-Credentials,
+physische Loeschung, technische Datenvernichtung, Backup-Restore aus externem
+Storage, komplexer Scheduler, neue Evidence-/Risk-/Control-/Notification-
+Engines sowie Docker-, Postgres-, nginx-, Nix- oder Dependency-Upgrades.
+
 ## 7. Was die wichtigsten Begriffe bedeuten
 
 - ISO 27001: internationaler Standard fuer Informationssicherheits-Managementsysteme
@@ -1272,12 +1333,12 @@ ISCY strukturiert, dokumentiert, priorisiert und verbindet. Entscheidungen muess
 
 ## 10. Strategische Weiterentwicklung
 
-Die Rust-Migration ist abgeschlossen. Mit V23.7.19 ist das regulatorische Organisationsprofil als erster strategischer Baustein umgesetzt; V23.7.20 ergaenzt Management-Review- und Audit-Pakete als steuerbaren Review-Workflow; V23.7.21 liefert Exporte, Snapshot-Ruecklinks und Evidence-Qualitaet; V23.7.22 setzt Third-Party-/Supplier-Risk als eigenes Rust-Web-/API-Modul um; V23.7.23 baut Product Security um VEX, SBOM-Diff und CRA-Readiness aus; V23.7.24 fuegt AI Governance hinzu; V23.7.25 schliesst Agent-Policy-Profile, erwartete Flottenabdeckung und aktive Policy-Webhooks an; V23.7.26 ergaenzt versionierte Product-Security-Evidence-Pakete. Migration `0027_rust_ai_governance_links` verbindet AI-Systeme tenantgebunden mit Risiken, Roadmap-Tasks, Incidents und Changes. Migration `0028_rust_guided_agent_onboarding` ergaenzt den gefuehrten, tenantgebundenen Agent-Rollout mit Token-Lifecycle, Policy-Zuordnung und Auditspur. Migration `0029_rust_cross_domain_notifications` fuehrt Evidence-, CVE-, Incident- und Roadmap-Signale in denselben sicheren Kanalbetrieb. Migration `0031_rust_supplier_review_workflow` ergaenzt Supplier-Reviews mit Freigabehistorie, Subprocessors, Vertragslaufzeiten, Exit-Test-Nachweisen und tenantgesicherten Evidence-/Control-/Risk-Links. Migration `0032_rust_management_regulatory_templates` ergaenzt Management-/Regulatory-Templates fuer ISO 27001, NIS2, DORA, KRITIS und generische Security-Governance-Reviews. Migration `0033_rust_evidence_integrity_disposition` ergaenzt Evidence Integrity & Disposition Phase 1 mit manueller und begrenzter Batch-Re-Hash-Pruefung, Legal-Hold-Metadaten, metadata-only Disposition und auditierbaren Integritaetsereignissen. Die weitere ISCY-Agenda konzentriert sich deshalb nicht mehr auf Abloesung alter Python-/Django-Pfade, sondern auf fachliche Produktreife.
+Die Rust-Migration ist abgeschlossen. Mit V23.7.19 ist das regulatorische Organisationsprofil als erster strategischer Baustein umgesetzt; V23.7.20 ergaenzt Management-Review- und Audit-Pakete als steuerbaren Review-Workflow; V23.7.21 liefert Exporte, Snapshot-Ruecklinks und Evidence-Qualitaet; V23.7.22 setzt Third-Party-/Supplier-Risk als eigenes Rust-Web-/API-Modul um; V23.7.23 baut Product Security um VEX, SBOM-Diff und CRA-Readiness aus; V23.7.24 fuegt AI Governance hinzu; V23.7.25 schliesst Agent-Policy-Profile, erwartete Flottenabdeckung und aktive Policy-Webhooks an; V23.7.26 ergaenzt versionierte Product-Security-Evidence-Pakete. Migration `0027_rust_ai_governance_links` verbindet AI-Systeme tenantgebunden mit Risiken, Roadmap-Tasks, Incidents und Changes. Migration `0028_rust_guided_agent_onboarding` ergaenzt den gefuehrten, tenantgebundenen Agent-Rollout mit Token-Lifecycle, Policy-Zuordnung und Auditspur. Migration `0029_rust_cross_domain_notifications` fuehrt Evidence-, CVE-, Incident- und Roadmap-Signale in denselben sicheren Kanalbetrieb. Migration `0031_rust_supplier_review_workflow` ergaenzt Supplier-Reviews mit Freigabehistorie, Subprocessors, Vertragslaufzeiten, Exit-Test-Nachweisen und tenantgesicherten Evidence-/Control-/Risk-Links. Migration `0032_rust_management_regulatory_templates` ergaenzt Management-/Regulatory-Templates fuer ISO 27001, NIS2, DORA, KRITIS und generische Security-Governance-Reviews. Migration `0033_rust_evidence_integrity_disposition` ergaenzt Evidence Integrity & Disposition Phase 1 mit manueller und begrenzter Batch-Re-Hash-Pruefung, Legal-Hold-Metadaten, metadata-only Disposition und auditierbaren Integritaetsereignissen. Evidence Object Storage & Restore Drill Phase 2 nutzt diese bestehenden Metadaten fuer eine interne lokale Storage-Abstraktion, sichere Artefaktreferenzen und tenantgebundene Restore-/Integritaetsdrills ohne neues Speichersystem. Die weitere ISCY-Agenda konzentriert sich deshalb nicht mehr auf Abloesung alter Python-/Django-Pfade, sondern auf fachliche Produktreife.
 
 Die priorisierte Roadmap liegt in `docs/ISCY_STRATEGIC_ROADMAP.md` und umfasst:
 
 1. Feinere Management-/Regulatory-Template-Varianten und kontextsensitive Pruefpakete
-2. Evidence-Integrity-Worker, kontrollierte physische Disposition und optionales Objektspeicher-Backend
+2. Evidence-Integrity-Worker, kontrollierte physische Disposition und spaeteres produktives Objektspeicher-Backend
 3. Signierte Agent-Pakete sowie eine spaetere getrennte CA-/PKI-Stufe
 4. Performance-, HA- und visuelle Regressionstests
 

docs/ISCY_STRATEGIC_ROADMAP.md

@@ -74,7 +74,7 @@ Erfolgskriterium:
 
 Ziel: Evidence soll nicht nur vorhanden sein, sondern belastbar bewertet werden.
 
-Status: In V23.7.21 als Evidence-Quality-API und Webansicht umgesetzt; am 2026-06-27 um den persistierten Evidence-Lifecycle erweitert. Im Unreleased-Stand kommt Evidence Integrity & Disposition Phase 1 hinzu.
+Status: In V23.7.21 als Evidence-Quality-API und Webansicht umgesetzt; am 2026-06-27 um den persistierten Evidence-Lifecycle erweitert. Im Unreleased-Stand kommen Evidence Integrity & Disposition Phase 1 sowie Evidence Object Storage & Restore Drill Phase 2 hinzu.
 
 Umgesetzt:
 
@@ -95,12 +95,17 @@ Umgesetzt:
 - Serverseitige SHA-256-Neuberechnung vorhandener Evidence-Artefakte mit Status `valid`, `mismatch`, `missing_artifact` oder `check_failed`.
 - Legal Hold kann Disposition-Entscheidungen blockieren und wird mit Begruendung, Akteurreferenz und Zeitpunkt auditierbar gefuehrt.
 - Disposition bleibt in Phase 1 ein Governance-/Audit-Metadatenmodell; `disposition_completed_metadata_only` loescht keine Dateien.
+- Interne Storage-Abstraktion fuer Evidence-Artefakte mit erstem Backend `local_filesystem`.
+- Storage-API-Pfade fuer Uebersicht, Detail, einzelne Drills, begrenzte Batch-Drills und Storage-Events.
+- Die bestehende Weboberflaeche `/evidence/integrity/` zeigt lokale Storage-Metadaten und bietet fuer Admin/Editor einen Storage-/Restore-Drill an.
+- Filesystem-Backend prueft Artefaktreferenzen ueber canonical path containment, blockiert Traversal, absolute Pfade und Symlink-Flucht aus dem Media Root und gibt nur sichere Fehlerklassen zurueck.
+- Restore-/Integrity-Drill belegt, dass referenzierte Artefakte am erwarteten lokalen Storage-Ort vorhanden, lesbar und SHA-256-konsistent sind; Ergebnisse werden in den bestehenden Evidence-Integrity-Feldern und `storage_*` Audit-Events dokumentiert.
 
 Naechste Vertiefung:
 
 - Periodischen Re-Hash-Worker mit Betriebssignalen und Queue-Steuerung ergaenzen.
 - Kontrollierte physische Loeschung/Datenvernichtung als getrennten, spaeteren Meilenstein entwerfen.
-- Optionales S3-/Objektspeicher-Backend inklusive Restore- und Integritaetsdrill.
+- Optionales produktives S3-/Objektspeicher-Backend inklusive Restore- und Integritaetsdrill als spaeteren, separaten Meilenstein pruefen.
 
 Erfolgskriterium:
 
@@ -231,7 +236,7 @@ Erfolgskriterium:
 ## Empfohlene Umsetzungsreihenfolge
 
 1. Feinere Template-Varianten und kontextsensitive NIS2-/DORA-/DSGVO-Pruefpakete auf Basis der neuen Management-/Regulatory-Template-Schicht.
-2. Evidence-Integrity-Worker, kontrollierte physische Disposition und optionales Objektspeicher-Backend.
+2. Evidence-Integrity-Worker, kontrollierte physische Disposition und optionales produktives Objektspeicher-Backend.
 3. Signierte Agent-Pakete, Release-Provenance und eine spaetere getrennte CA-/PKI-Stufe.
 
 ## Verbleibende Roadmap
@@ -247,7 +252,8 @@ Erfolgskriterium:
 | Unreleased | Supplier-Review-Workflow | Kritische Lieferanten erhalten Freigabehistorie, Unterauftragnehmer, Vertragsfristen, Exit-Test-Nachweise und tenantgesicherte Evidence-/Control-/Risk-Links. |
 | Umgesetzt / Vertiefung | Management-/Regulatory-Templates | Wiederholbare ISO-27001-, NIS2-, DORA-, KRITIS- und Governance-Pakete werden aus bestehenden Snapshots erzeugt; feinere Varianten koennen spaeter folgen. |
 | Unreleased | Evidence Integrity & Disposition Phase 1 | Manuelle und begrenzte Batch-Re-Hash-Pruefung, Legal Hold, metadata-only Disposition und auditierbare Integritaetsereignisse sind tenantgebunden verfuegbar. |
-| Reifegrad | Evidence-Worker, physische Disposition und Objektspeicher | Periodische Integritaetspruefung, kontrollierte Datenvernichtung und Storage-Restore sind auditierbar. |
+| Unreleased | Evidence Object Storage & Restore Drill Phase 2 | Eine interne Storage-Abstraktion mit lokalem Filesystem-Backend prueft referenzierte Artefakte sicher auf Vorhandensein, Lesbarkeit und Hash-Konsistenz. |
+| Reifegrad | Evidence-Worker, physische Disposition und produktiver Objektspeicher | Periodische Integritaetspruefung, kontrollierte Datenvernichtung und Storage-Restore sind auditierbar. |
 | Reifegrad | Performance, HA und visuelle Regression | Lastgrenzen, Mehrinstanzbetrieb und UI-Regressionen sind messbar abgesichert. |
 
 ## Abgrenzung