From 57e10be05cb188ef45aef69df6860d90fca6ff07 Mon Sep 17 00:00:00 2001 From: patrick Date: Fri, 16 Oct 2026 12:21:16 +0000 Subject: [PATCH] =?UTF-8?q?QA-05:=20abnahme-und-compliance-pr=C3=BCfung-ar?= =?UTF-8?q?chive?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Konsolidiert QA-02 (Retention & WORM), QA-03 (Compliance & eDiscovery) und QA-04 (Backup & Restore) sowie ergänzend QA-06/QA-07 zu einer Gesamtfreigabeentscheidung für das Archive-Board. Bedingte Freigabe: WORM-Storage-Object-Lock (chattr +i) bleibt auf allen bisher geprüften Hosts (131, 204) strukturell nicht nachweisbar (LXC/ZFS-Infrastrukturgrenze), erneut unabhängig reproduziert; Anwendung reagiert fail-closed, kein fabriziertes PASS. Keine Änderung an Produktivcode oder den Einzelprotokollen. Co-Authored-By: Claude Sonnet 5 --- archive/docs/QA-05-PRUEFPROTOKOLL.md | 150 +++++++++++++++++++++++++++ 1 file changed, 150 insertions(+) create mode 100644 archive/docs/QA-05-PRUEFPROTOKOLL.md diff --git a/archive/docs/QA-05-PRUEFPROTOKOLL.md b/archive/docs/QA-05-PRUEFPROTOKOLL.md new file mode 100644 index 00000000..7f1948e7 --- /dev/null +++ b/archive/docs/QA-05-PRUEFPROTOKOLL.md @@ -0,0 +1,150 @@ +# QA-05 – Gesamtabnahme- & Compliance-Prüfung Archive + +Stand: 2026-10-16. Testhost 192.168.1.204 (frischer Klon, `feature/qa-05-abnahme-und-compliance-prüfung-archive`, +abgezweigt von `main`). QA-05 führt keine eigenen fachlichen Prüfungen durch, sondern konsolidiert +die drei geforderten Einzelgates (QA-02, QA-03, QA-04) sowie ergänzend QA-06/QA-07 zu einer +Gesamtfreigabeentscheidung. Keine Änderung an Produktivcode oder an den Einzelprotokollen. + +## Quellenlage + +`main` enthielt zum Start dieses Tickets nur `QA-04-ABNAHMEPROTOKOLL.md` und +`QA-06-PRUEFPROTOKOLL.md` in `archive/docs/`. `QA-02-PRUEFPROTOKOLL.md`, `QA-03-PRUEFPROTOKOLL.md` +und `QA-07-PRUEFPROTOKOLL.md` lagen noch nicht in `main`, sondern nur auf den offenen +Feature-Branches. Diese wurden per `git fetch` gelesen, ohne zu mergen: + +- `origin/feature/qa-02-prüfgate-retention-und-worm:archive/docs/QA-02-PRUEFPROTOKOLL.md` +- `origin/feature/qa-03-prüfgate-compliance-und-ediscovery:archive/docs/QA-03-PRUEFPROTOKOLL.md` +- `origin/feature/qa-07-last-leistungstest:archive/docs/QA-07-PRUEFPROTOKOLL.md` + +`archive/docs/QA-04-ABNAHMEPROTOKOLL.md`, `archive/docs/QA-06-PRUEFPROTOKOLL.md` und +`archive/docs/RET-11-PRUEFPROTOKOLL.md` wurden direkt aus `main` gelesen. + +## 1. Zusammenfassung der drei fachlichen Prüfgates (Akzeptanzkriterium 1/2) + +| Gate | Gegenstand | Einzelergebnis laut eigenem Protokoll | Bewertung für QA-05 | +|---|---|---|---| +| **QA-02** | Retention & WORM (RET-03 Legal Hold, RET-04 WORM-Speicher) | Prüfung 1 (Legal Hold gegen Referenzdatensatz): **bestanden**, 7/7 PASS. Prüfung 2 (WORM-Überschreibschutz): **teilweise bestanden** – Anwendungs-/Dateisystem-Schreibschutz (chmod 0400, `ErrAlreadyExists`, `sudo -u nexarch`-Schreibversuch → Permission denied) real nachgewiesen; die zusätzliche Storage-Object-Lock-Ebene (`chattr +i`) auf Host 204 strukturell nicht prüfbar (7 Tests SKIP). Gesamtergebnis des eigenen Protokolls: "Teilweise bestanden". | **bestanden** im Sinne von Akzeptanzkriterium 1 – die für RET-03/RET-04 geforderte Kernfunktion ist nachgewiesen, der offene Rest ist exakt der unten konsolidierte WORM-Storage-Lock-Punkt, kein zusätzlicher Fund | +| **QA-03** | Compliance & eDiscovery (CMP-03 Export, CMP-06 Vier-Augen-Freigabe) | Beide Pflichtprüfungen **bestanden**: Export-Prüfsummen bei zwei unabhängigen Läufen gegen den Referenzdatensatz identisch; Vier-Augen-Freigabe mit zwei benannten, unabhängigen Testrollen sowohl im Erfolgsfall als auch beim (abgelehnten) Alleingang real verifiziert. Keine Regression in den bestehenden CMP-03/CMP-06-Pflichttests. | **bestanden** | +| **QA-04** | Backup & Restore (BAK-04 bis BAK-07) | Beide Nachhol-Prüfungen (realer Restore-Lauf DB+Objekt, anschließende Reconciliation) **bestanden**, Ergebnis leer/sauber. 5 Restrisiken benannt, keines blockiert laut eigenem Protokoll die Freigabe. Bereits mit Gegenzeichnung "Betreiber" versehen. | **bestanden** | + +**Ergebnis Akzeptanzkriterium 1:** Alle drei fachlichen Prüfgates sind bestanden. QA-02 trägt dabei +einen explizit benannten, nicht neu durch QA-05 eingeführten Restpunkt (Storage-Object-Lock), der +unten konsolidiert wird. + +## 2. Ergänzend konsolidiert (nicht Teil der drei Pflichtgates, aber laut Ausgangslage dieses Tickets relevant) + +| Gate | Ergebnis | +|---|---| +| **QA-06** (Schnittstellen-Vertragstests) | **Bestanden**, bereits vorher in `main` gemergt. Contract-Tests (RET-05-Payloads) grün, Breaking-Change-Erkennung nachgewiesen, CI-Lauf real durchgeführt (Gitea-Actions-Run #30, Status success). | +| **QA-07** (Last- & Leistungstest) | AC1 (Legal-Hold-Abfrage unter Last: p95 = 30,3 ms ≤ 50 ms, Durchsatz 6564,5/s ≥ 3000/s, 0 Fehler über 6000 Anfragen) **bestanden**. AC3 (RET-05-Registrierung, 240 parallele Aufrufe, 0 Fehler, keine Race-Duplikate/-Verluste) **bestanden**. AC2 (WORM-Schreibpfad unter Last) **offen auf Host 204** aus demselben chattr-Grund wie QA-02/RET-11 – Race-Freiheit der Schlüssel-Kollisionslogik zusätzlich per Code-Analyse (POSIX-Atomarität von `O_EXCL`) verifiziert, kein fabriziertes PASS. | + +## 3. Konsolidierte Restrisiken (Prüfung vor der Abnahme 2) + +### 3.1 Zentrales Restrisiko: Storage-Object-Lock (`chattr +i`) auf keinem bisher geprüften Host nachweisbar + +Dreifach unabhängig bestätigt: + +1. `RET-11-PRUEFPROTOKOLL.md` (Host 131, unprivilegiertes LXC auf ZFS-Root): `chattr +i` scheitert + mit `EPERM`, obwohl `cap_linux_immutable` im Namespace-Bounding-Set erscheint – die reale + Kernel-Prüfung greift gegen die gemappte UID, nicht gegen echte Capabilities. +2. `QA-02-PRUEFPROTOKOLL.md` (Host 204): identischer Befund, 7 Tests SKIP. +3. `QA-07-PRUEFPROTOKOLL.md` (Host 204, unter Last): identischer Befund, 2 Lasttests SKIP. + +Zur Verifikation im Rahmen dieser Abnahme wurde der Befund auf Host 204 am frischen +QA-05-Arbeitsverzeichnis ein viertes Mal real reproduziert (eigener, unabhängiger Probe-Lauf, +nicht aus den obigen Protokollen übernommen): + +``` +$ df -T / +rpool/data/subvol-1204-disk-0 zfs ... / +$ chattr +i probe.txt +chattr: Operation not permitted while setting flags on probe.txt +Exit-Code: 1 +``` + +**Bewertung der Tragweite:** `wormstore.Store.Put` (archive/internal/wormstore/wormstore.go) +ruft `lockImmutable` unbedingt auf und entfernt bei Fehlschlag die bereits geschriebene Datei +wieder – fail-closed, kein WORM-Objekt ohne tatsächliche Storage-Sperre. Das verhindert eine +falsche Compliance-Zusage, bedeutet aber auch: auf einem Host, auf dem `chattr +i` nicht wirkt, +schlägt **jeder einzelne** `Put`-Aufruf fehl – keine Archivierung, nicht nur ein Audit-Gap. + +`RET-11-PRUEFPROTOKOLL.md` (Prüfung 3, bestanden) dokumentiert bereits die Betriebsvoraussetzung: +das WORM-Basisverzeichnis muss auf einem chattr-fähigen Dateisystem (ext2/3/4, XFS, Btrfs) liegen, +ausdrücklich NICHT auf ZFS, und der Prozess braucht reale (nicht nur Namespace-gemappte) +`CAP_LINUX_IMMUTABLE`-Rechte. `STORAGE-KONZEPT.md` Abschnitt 2 führt für die Produktions-Zielstufe +"Stufe 1 (Einzel-LXC)" jedoch "lokales Dateisystem ODER ZFS" als gleichwertige Optionen – ohne +Verweis auf die engere WORM-spezifische Einschränkung aus RET-11. Beide bisher geprüften Hosts +(131 und 204) sind exakt die Kombination (unprivilegiertes LXC auf ZFS), die laut RET-11 nicht +funktioniert. Der erfolgreiche Pfad (echtes `chattr +i` auf einem konformen Host) wurde in diesem +Projekt bislang **auf keinem einzigen Host real nachgewiesen** – es existiert bisher nur die +Code-Analyse, dass es auf einem konformen Host funktionieren würde. + +### 3.2 Weitere, nicht blockierende Restrisiken aus den Einzelgates + +- **QA-02:** RET-06/RET-07 (Fristen-Konfiguration, Fristablauf-Benachrichtigung) wurden bewusst + nicht erneut geprüft (außerhalb des QA-02-Scopes); `golangci-lint` auf Host 204 nicht verfügbar + (Projektregel: keine Toolchain-Installation), `go build`/`go vet` liefen ersatzweise clean. +- **QA-03:** Der eDiscovery-Modul-Adapter wurde nur gegen fiktive Testmodule geprüft, nicht gegen + echte laufende DMS-/Mail-Instanzen; die Rollenberechtigung der Vier-Augen-Bestätigung selbst wird + nicht in diesem Paket geprüft (liegt, falls vorhanden, in einer höheren API-Schicht). + QA-03s eigenes Protokoll verweist diese Ende-zu-Ende-Prüfung ausdrücklich an QA-05 – der + vorliegende QA-05-Tickettext begrenzt den Auftrag hier aber bewusst auf Konsolidierung der drei + Gate-Ergebnisse, ohne eigene neue Prüfungen. Diese Diskrepanz wird hier offen benannt statt + stillschweigend übergangen: eine echte Ende-zu-Ende-eDiscovery-Prüfung gegen laufende + DMS-/Mail-Instanzen steht weiterhin aus und sollte als eigenes Folgeticket eingeplant werden. +- **QA-04:** fünf im Einzelprotokoll benannte Restrisiken (fehlende Rotations-Kohärenz zwischen + DB- und Objekt-Backup, manuelle BAK-04-Rollenvergabe je Mandant, BAK-08 deckt keine + Storage-Provider-Lücke bei externem, nicht-kompatiblem Storage, Core-FDN-03/FDN-09-Wiring-Lücke, + leerer Reconciliation-Testbestand) – laut Einzelprotokoll blockiert keines davon die Freigabe, + bereits mit Gegenzeichnung "Betreiber" bestätigt. + +## 4. Freigabeentscheidung (Prüfung vor der Abnahme 3) + +**Bedingte Freigabe des Archive-Boards, mit namentlich benanntem Restrisiko und Empfehlung für ein +Folgeticket.** + +Begründung: + +1. Alle drei geforderten fachlichen Prüfgates (QA-02, QA-03, QA-04) sind real, mit Messprotokoll + und ohne fabrizierte Ergebnisse bestanden. QA-06 und QA-07 bestätigen dies zusätzlich für + Schnittstellenverträge und Last. +2. Das verbleibende Risiko (Storage-Object-Lock/`chattr +i`) ist ein **Fail-Closed**-Verhalten: + `wormstore.Store.Put` gibt niemals eine WORM-Garantie vor, die storage-seitig nicht tatsächlich + besteht – der worst case ist eine verweigerte Schreibung (Verfügbarkeits-/Betriebsproblem), + niemals eine stillschweigend verletzte Unveränderlichkeits- oder Löschsperre + (Integritäts-/Compliance-Problem). Das ist exakt das in der Produkt-DNA geforderte Verhalten + ("keine Freigabe auf Zuruf", hier technisch erzwungen statt nur organisatorisch versprochen) und + entspricht dem Verhalten von S3 Object Lock Compliance-Mode, an dem sich RET-11 orientiert. +3. Das Risiko ist kein neuer oder versteckter Befund, sondern seit RET-11 bekannt, in zwei weiteren, + unabhängigen Prüfläufen (QA-02, QA-07) sowie einer vierten Probe im Rahmen dieser Abnahme erneut + bestätigt, und in `RET-11-PRUEFPROTOKOLL.md` Prüfung 3 bereits als Betriebsvoraussetzung + dokumentiert. +4. Eine Freigabe ohne jede Einschränkung wäre dennoch nicht gerechtfertigt: der erfolgreiche Pfad + (ein Host, auf dem `chattr +i` tatsächlich greift) wurde in diesem Projekt bislang **auf keinem + einzigen Host real bestätigt** – nur per Code-Analyse. Zusätzlich widerspricht + `STORAGE-KONZEPT.md` Abschnitt 2 (ZFS als gleichwertige Stufe-1-Backend-Option) ohne Verweis auf + die RET-11-Einschränkung faktisch der dokumentierten WORM-Betriebsvoraussetzung – ein Ops-Team + könnte Stufe 1 unwissentlich auf ZFS provisionieren und würde dort erst im Betrieb feststellen, + dass jede WORM-geschützte Archivierung fehlschlägt. + +**Bedingungen der Freigabe:** + +- Folgeticket: realer End-to-End-Nachweis von `wormstore.Store.Put`/`Release`/`Destroy` auf + mindestens einem Host mit echtem (nicht Namespace-gemapptem) `CAP_LINUX_IMMUTABLE` auf einem + chattr-fähigen Dateisystem (ext4/xfs/btrfs, privilegierter Container oder VM), bevor WORM in + einer produktiven Stufe-1-Umgebung als abgenommen gilt. +- `STORAGE-KONZEPT.md` Abschnitt 2 um einen expliziten Verweis/Ausnahmevermerk ergänzen: das + WORM-Basisverzeichnis ist von der generischen "lokales Dateisystem oder ZFS"-Option + ausgenommen und benötigt zwingend ein chattr-fähiges Dateisystem mit realen + `CAP_LINUX_IMMUTABLE`-Rechten (vor erster produktiver Stufe-1-Inbetriebnahme). +- Offene, nicht blockierende Folgepunkte aus Abschnitt 3.2 (insbesondere die noch ausstehende + echte Ende-zu-Ende-eDiscovery-Prüfung gegen laufende DMS-/Mail-Instanzen, von QA-03 an QA-05 + verwiesen, hier aber nicht in dessen Scope) als eigenes Ticket einplanen. + +## 5. Unterschriften + +- **Umsetzung:** Claude (Agent), 2026-10-16 — Konsolidierung durchgeführt, Quelldokumente geprüft, + chattr-Befund auf Host 204 eigenständig reproduziert, Protokoll erstellt. +- **Gegenzeichnung:** aussteht (wie bei früheren QA-Gates wird das Gegenlesen im Pull Request + nachgetragen, sobald eine zweite Person verfügbar ist; blockiert nicht das technische + Inkrafttreten dieses Protokolls).