sysops
a95ed331cd
- migrations/0009_data_subject_ref: additive nullable Spalte auf retention_objects, schliesst die Luecke fuer 'betroffene Person' in RET-01 - retention.RegisterObjectForSubject: NEUE additive Funktion, RegisterObject selbst unveraendert (kein Diff, keine Produktionsaufrufer betroffen) - archive/internal/dpreport: SubjectReport (Auskunftsbericht), ProcessingOverview (Verarbeitungsuebersicht, statisch gepflegte Zweck/Rechtsgrundlage je Objekttyp), WriteSubjectReportCSV - Mandantentrennung strukturell durch Modell C (ein Pool pro Tenant), real mit zwei physisch getrennten Tenant-DBs bewiesen (tenant_acme/ tenant_globex), nicht nur behauptet - 4 Tests, alle Pflichtpruefungen real bestanden - Migration real auf dms_tenant_test angewendet Pruefungen siehe archive/docs/CMP-02-PRUEFPROTOKOLL.md
70 lines
3.6 KiB
Markdown
70 lines
3.6 KiB
Markdown
# CMP-02 – Prüfprotokoll: DSGVO-/Datenschutz-Berichte
|
||
|
||
Voraussetzung RET-01 – bereits Fertig.
|
||
|
||
## Vorab identifizierte und geklärte Design-Lücke
|
||
|
||
RET-01 (`retention_objects`) führte bislang keine Zuordnung zu einer
|
||
"betroffenen Person" — nur `object_type`/`object_reference` (opake
|
||
modulübergreifende Referenz). Ein Auskunftsbericht "aller Objekte einer
|
||
Person" war damit strukturell unmöglich. Nach Nutzerentscheidung
|
||
(Option 1) additiv gelöst:
|
||
|
||
- `archive/migrations/0009_data_subject_ref.up.sql` — nullable Spalte
|
||
`retention_objects.data_subject_ref` + Index.
|
||
- `archive/internal/retention.RegisterObjectForSubject` — NEUE, additive
|
||
Funktion. `RegisterObject` (RET-01) bleibt UNVERÄNDERT (kein Diff),
|
||
kein bestehender Aufrufer betroffen (Codeprüfung: `RegisterObject`
|
||
hatte ohnehin nur Testaufrufer, keine Produktionsverdrahtung).
|
||
- Leeres `data_subject_ref` bedeutet "nicht personenbezogen", kein
|
||
Fehlerzustand (z. B. Systemkonfigurationsobjekte).
|
||
|
||
## Umsetzung
|
||
|
||
- `archive/internal/dpreport.SubjectReport` – Auskunftsbericht
|
||
(Akzeptanzkriterium 1), nutzt dieselbe "jüngste Zuordnung"-Logik wie
|
||
RET-02 (DISTINCT ON), keine zweite Berechnung.
|
||
- `archive/internal/dpreport.ProcessingOverview` – Verarbeitungsübersicht
|
||
je tatsächlich vorkommendem Objekttyp (Akzeptanzkriterium 2), Zweck/
|
||
Rechtsgrundlage statisch gepflegt (`ProcessingPurposes`) — Rechts-
|
||
bewertungen sind keine aus Nutzdaten ableitbaren Werte.
|
||
- `archive/internal/dpreport.WriteSubjectReportCSV` – CSV-Export
|
||
(Akzeptanzkriterium/Pflichtprüfung 3).
|
||
- **Mandantentrennung (Akzeptanzkriterium 3):** strukturell garantiert
|
||
durch Modell C — `SubjectReport` läuft immer gegen GENAU EINEN
|
||
Tenant-Pool, kein Cross-Tenant-Query technisch möglich.
|
||
|
||
## Prüfungen
|
||
|
||
| # | Prüfung | Ergebnis |
|
||
|---|---|---|
|
||
| 1 | Auskunftsbericht für Testperson mit bekanntem Datenbestand stimmt mit erwarteter Liste überein | **bestanden** – `TestSubjectReport_MatchesKnownDataset`: 3 Objekte für 2 Personen angelegt, Bericht für Person A liefert exakt die 2 erwarteten Objekte (nicht das dritte, das Person B gehört), inkl. korrekter Aufbewahrungsklasse |
|
||
| 2 | Bericht für einen Tenant enthält keine Objekte eines anderen Tenants | **bestanden** – `TestSubjectReport_TenantIsolation`: real gegen ZWEI PHYSISCH GETRENNTE Tenant-Datenbanken (`tenant_acme`, `tenant_globex`) getestet, nicht nur zweimal dieselbe DSN — Objekt in Tenant A angelegt, Bericht für dieselbe `data_subject_ref` gegen Tenant B liefert 0 Treffer |
|
||
| 3 | Export lässt sich als CSV weiterverarbeiten | **bestanden** – `TestWriteSubjectReportCSV_IsParseable`: echte CSV-Ausgabe erzeugt und geparst, Header + genau eine Datenzeile |
|
||
|
||
**Hinweis zur Testkorrektur:** Der erste Testlauf von Prüfung 2 nutzte
|
||
versehentlich denselben `TEST_TENANT_DSN` für beide "Tenants" (dieselbe
|
||
physische Datenbank) und schlug dadurch zurecht fehl — kein
|
||
Code-Defekt, sondern ein Testfehler. Korrigiert auf zwei echte,
|
||
unabhängige Tenant-Datenbanken (`TEST_TENANT_DSN_B`), danach real
|
||
bestanden.
|
||
|
||
## Build/Test-Ergebnis (192.168.1.131)
|
||
|
||
```
|
||
go build ./... -> clean
|
||
go vet ./... -> clean
|
||
golangci-lint run ./... -> 0 issues
|
||
go test ./... -p 1 -> alle Archive-Pakete bestanden (inkl. dpreport, retention)
|
||
```
|
||
|
||
Migration `0009_data_subject_ref` real auf `dms_tenant_test` angewendet.
|
||
|
||
## Gesamtergebnis
|
||
|
||
**Bestanden.** Alle drei Akzeptanzkriterien und alle drei
|
||
Pflichtprüfungen real erfüllt, inklusive einer vorab identifizierten
|
||
und mit dem Nutzer geklärten strukturellen Lücke (fehlende
|
||
Personen-Zuordnung in RET-01), additiv und ohne Änderung an bestehendem
|
||
Verhalten geschlossen.
|