[roadmap] Add evidence storage restore drill phase two

[ewilhelm1979-netizen]

Problemstellung und Ziel

Evidence Integrity & Disposition Phase 1 kann Hashes und Disposition-Metadaten verwalten, aber Evidence-Artefakte waren noch nicht ueber eine klar gekapselte Storage-Schicht pruefbar. Dieser PR setzt den Roadmap-Meilenstein "Evidence Object Storage & Restore Drill - Phase 2" um: lokale Evidence-Artefakte werden ueber eine interne Storage-Abstraktion sicher inspiziert und per Restore-/Integrity-Drill gegen die bestehenden SHA-256-Metadaten geprueft.

Ziel ist bewusst kein produktives S3/Object-Storage-Backend, sondern ein erster lokaler Backend-Pfad fuer den bestehenden Media Root mit sicheren Referenzen, tenantgebundenen API-/Web-Flows und auditierbaren Storage-Events.

Geaenderte Funktionen

• Interne Evidence-Artefakt-Storage-Abstraktion mit erstem Backend local_filesystem.
• Sichere Artefaktauflösung unterhalb des Media Root per canonical path containment.
• Blockade von absoluten Pfaden, Directory Traversal und Symlink-Flucht.
• Storage-Metadaten fuer Referenz vorhanden, Artefakt vorhanden, lesbar, leer, Groesse und sichere Fehlerklasse.
• Restore-/Integrity-Drill mit serverseitiger SHA-256-Berechnung und Status valid, mismatch, missing_artifact oder check_failed.
• Audit-Events storage_* fuer Start, Artefakt gefunden, Missing/Unreadable, Hash gueltig, Hash-Mismatch, Drill-Fehler und Abschluss.
• Web-UI-Erweiterung in /evidence/integrity/ mit Storage-Status und Storage-Drill-Aktion fuer schreibende Rollen.
• Aktualisierte Doku, Roadmap, Changelog und PDF-Handbuch.

Betroffene Dateien

• rust/iscy-backend/src/evidence_artifact_storage.rs
• rust/iscy-backend/src/evidence_store.rs
• rust/iscy-backend/src/lib.rs
• rust/iscy-backend/tests/http_tests.rs
• CHANGELOG.md
• docs/ISCY_Handbuch.md
• docs/ISCY_Handbuch.pdf
• docs/ISCY_STRATEGIC_ROADMAP.md

Datenbankmigrationen

Keine neue Migration. Phase 2 nutzt bewusst die vorhandenen Felder und die bestehende Ereignistabelle aus Migration 0033_rust_evidence_integrity_disposition:

• letzter Integritaets-/Storage-Drill-Zeitpunkt
• Integritaetsstatus
• berechneter SHA-256
• sichere Fehlerklasse
• Evidence-Integrity-Events

Dadurch bleiben bestehende Deployments additiv kompatibel und es gibt keine destruktiven Schemaaenderungen.

Neue oder geaenderte API-Endpunkte

• 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

Die bestehenden Evidence-Integrity-Endpunkte bleiben erhalten.

GUI-Aenderungen

• /evidence/integrity/ zeigt jetzt Storage-Backend, Artefaktstatus, sichere Storage-Fehlerklasse und letzten Drill-/Integritaetszeitpunkt.
• Admin-/Editor-Rollen sehen eine Storage-Drill-Aktion.
• Read-only-Rollen sehen nur sichere Metadaten und keine Schreibaktion.

Tenant- und Berechtigungsgrenzen

• Alle Storage-API- und Web-Flows verwenden den bestehenden authentifizierten Tenant-Kontext.
• Detail-, Drill- und Event-Lookups sind in der Datenbank tenantgebunden.
• Fremde Evidence-IDs werden nicht offengelegt und nicht verknuepft.
• Schreibende Drills sind auf Admin-/Editor-Rollen begrenzt.
• Auditoren/Read-only-Rollen koennen sichere Storage-Metadaten lesen, aber keine Drills starten.

Security-Entscheidungen

• Keine absoluten Pfade, Media-Root-Pfade, SQL-Details, Secrets, Tokens, Authorization Header oder Rohpayloads in API/Web/Audit-Ausgaben.
• Lokale Artefaktpfade werden nur ueber sichere Referenzen verarbeitet.
• Das Filesystem-Backend prueft canonical containment und verweigert Traversal, absolute Referenzen und Symlink-Flucht.
• Fehlende oder manipulierte Artefakte werden mit sicheren Fehlerklassen behandelt.
• Es gibt keine Cloud-Credentials, keinen S3-SDK-Pfad und keine produktive Object-Storage-Konfiguration in diesem PR.
• Es gibt keine physische Loeschung und keine technische Datenvernichtung.

Ausgefuehrte Tests

• cargo fmt --manifest-path rust/iscy-backend/Cargo.toml -- --check
• git diff --check
• cargo clippy --locked --manifest-path rust/iscy-backend/Cargo.toml --all-targets -- -D warnings
• cargo test --locked --manifest-path rust/iscy-backend/Cargo.toml
• gezielt: cargo test --locked --manifest-path rust/iscy-backend/Cargo.toml evidence_storage_drill_uses_local_backend_and_keeps_tenant_boundaries -- --nocapture
• cargo audit --file rust/iscy-backend/Cargo.lock --ignore RUSTSEC-2023-0071
• cargo deny --manifest-path rust/iscy-backend/Cargo.toml check advisories licenses sources
• make rust-smoke
• make rust-restore-smoke
• nix flake check
• Docker Compose config fuer dev/stage/prod mit .env.example
• make docs-pdf

Hinweis: cargo audit lief mit Exit 0; lokal konnte der crates.io-Index nicht aktualisiert werden (registry: No such file or directory), die RustSec-Datenbank wurde geladen und der Lockfile-Scan hatte keine Funde. Die Compose-Validierung mit der echten .env war lokal wegen Dateirechten nicht moeglich (.env gehoert nobody:nogroup, 0600); fuer Syntaxvalidierung wurde die versionierte .env.example verwendet. Der hardened Docker-Build konnte lokal nicht ausgefuehrt werden, weil kein Docker-Daemon unter /var/run/docker.sock erreichbar ist.

Bekannte Einschraenkungen

• Erstes Backend ist ausschliesslich local_filesystem.
• Kein produktives S3/Object Storage.
• Kein Cloud-Credential-Handling.
• Kein externer Backup-Restore aus Object Storage.
• Kein periodischer Scheduler/Worker.
• Keine physische Evidence-Loeschung und keine technische Datenvernichtung.
• Keine neue Evidence-, Risk-, Control- oder Notification-Engine.

Bewusst nicht umgesetzt

• PR enthaelt keine Dependency-, Docker-, Postgres-, nginx-, Nixpkgs- oder GitHub-Actions-Upgrades.
• PR veraendert keine Dependabot-/Bot-PRs.
• PR fuehrt keine neuen Migrationen ein.
• PR schwaecht keine CI-, CodeQL-, cargo-audit- oder cargo-deny-Pruefungen ab.
• PR trifft keine rechtliche Bewertung und ersetzt keine Zertifizierung.

AI assistance

Prepared with OpenAI Codex assistance. Human review remains required for correctness, security, licensing, provenance, and operational acceptance.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b76d75f9ae

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Filter storage events before limiting history

This filters storage events only after evidence_integrity_events(..., 100) has already loaded the 100 most recent events of all types. For evidence items with more than 100 newer integrity/legal-hold/disposition events, /storage-events will return an empty or incomplete storage audit trail even though older storage drill events exist. The storage predicate needs to be applied in the event query, or the endpoint needs storage-specific pagination before the limit is enforced.

Useful? React with 👍 / 👎.