archivmail/features/PROJ-55-fix-auditor-tenant-isolation.md

PROJ-55: Fix Tenant-Isolation für Rolle "auditor" + Audit-Log (Sicherheitsbug, DSGVO-relevant)

Status: In Review

Created: 2026-06-21 Last Updated: 2026-06-22

Dependencies

• PROJ-6 (Volltext-Suche & Filterung)
• PROJ-21 (Multi-Mandanten-Fähigkeit)
• PROJ-11 (Audit-Log & Compliance-Berichte)

Hintergrund / Bug (Nutzermeldung)

Ein Account mit Rolle auditor (Tenant "homelocal") sieht in der Mail-Suche Mails anderer Tenants. Zusätzlich sehen Tenant-Admins (domain_admin) im Audit-Log Einträge anderer Tenants. Bei einer SaaS-Freigabe wäre das ein DSGVO-Verstoß (fehlende Mandantentrennung).

Bug 1 — Mail-Suche (internal/api/search_handlers.go)

auditor ist aktuell als globaler Auditor designed: nutzt immer den globalen Index (Zeile ~111), die Fallback-Tenant-Filterung schließt RoleAuditor explizit aus (Zeile ~125: && sess.Role != userstore.RoleAuditor). Per Kommentar soll auditor nur tenant-lose Mails sehen — das wird aber nicht durchgesetzt, wenn Mails fälschlich ohne Tenant-Zuordnung im globalen Index liegen, oder wenn auditor faktisch pro Tenant genutzt wird (hat ein tenant_id-Feld, das ignoriert wird).

Bug 2 — Audit-Log (internal/api/dashboard_handlers.go, internal/audit/audit.go)

handleAuditLog filtert nicht nach Tenant. audit.QueryFilter hat kein Tenant-Feld, buildWhere() entsprechend auch nicht. Jeder mit Zugriff auf /api/audit sieht Log-Einträge aller Tenants.

Entscheidung (Nutzer, 2026-06-21)

• Auditor wird strikt pro Tenant gescoped (nicht mehr global). auditor sieht künftig nur Mails/Logs des eigenen tenant_id — analog zu domain_admin/domain_auditor.
• superadmin bleibt unverändert global (sieht weiterhin alle Tenants, nötig für Betrieb/Support).
• domain_admin/domain_auditor werden im Audit-Log ebenfalls auf den eigenen Tenant beschränkt (waren es vorher nicht).

Acceptance Criteria

• Rolle auditor mit gesetztem tenant_id: Mail-Suche (/api/search) liefert ausschließlich Mails des eigenen Tenants (Per-Tenant-Index oder äquivalente serverseitige Filterung vor Pagination, analog PROJ-54).
• Rolle auditor mit gesetztem tenant_id: handleGetMail/handleGetRaw/handleGetAttachment/Export/eDiscovery/Threads/OCR verweigern Zugriff auf Mails anderer Tenants (403).
• /api/audit (Audit-Log): für domain_admin, domain_auditor, auditor mit tenant_id werden nur Log-Einträge des eigenen Tenants zurückgegeben.
• superadmin ist von beiden Einschränkungen unberührt — sieht weiterhin alle Tenants/Logs.
• Bestehende Pro-Tenant-Filterung für domain_admin/domain_auditor/user bleibt unverändert funktionsfähig (keine Regression).
• Falls ein auditor-Account KEINEN tenant_id gesetzt hat (Altbestand / bewusst globaler Auditor): Verhalten bleibt wie bisher (globaler Zugriff) — kein impliziter Zugriffsverlust für bestehende globale Auditor-Accounts ohne Tenant-Zuordnung. Klar dokumentieren.

Edge Cases

• auditor ohne tenant_id → weiterhin globaler Zugriff (Abwärtskompatibilität, siehe AC oben).
• auditor mit tenant_id, aber Mails ohne Tenant-Zuordnung im Index (Altbestand vor PROJ-21) → diese Mails sind für tenant-gescopte Auditoren NICHT sichtbar (korrekt, da nicht ihrem Tenant zugeordnet).
• Audit-Log-Einträge, die vor Einführung von Multi-Tenancy (PROJ-21) ohne Tenant-Bezug geschrieben wurden → für tenant-gescopte Rollen nicht sichtbar; nur superadmin sieht sie weiterhin.

Technical Requirements (optional)

• Keine neue Migration nötig (tenant_id existiert bereits auf users, Audit-Log-Einträge müssten ggf. um Tenant-Bezug ergänzt werden — prüfen ob audit_log-Tabelle bereits ein Tenant-Feld hat).

---

Tech Design (Solution Architect)

Übersprungen auf Wunsch des Nutzers — direkte Umsetzung (kritischer Sicherheitsbugfix).

Fix-Plan für Backend Developer:

1. internal/api/search_handlers.go: auditor mit gesetztem tenant_id wie domain_auditor/domain_admin behandeln (Per-Tenant-Index nutzen bzw. Fallback-Filter NICHT mehr explizit ausschließen). auditor ohne tenant_id weiterhin global.
2. Dieselbe Logik für handleGetMail/handleGetRaw/handleGetAttachment und alle Stellen, die mailBelongsToUser/Tenant-Checks für Auditoren machen (export.go, ediscovery.go, thread_handlers.go, ocr_handlers.go).
3. internal/audit/audit.go: QueryFilter um TenantID *int64 erweitern, buildWhere() entsprechend erweitern.
4. internal/api/dashboard_handlers.go (handleAuditLog): für Rollen domain_admin, domain_auditor, auditor (mit tenant_id) TenantID aus Session in den QueryFilter setzen. superadmin unverändert (kein Filter).

Implementation Notes (Backend, 2026-06-21)

Zentrale Entscheidung im Code: Ein auditor gilt nur dann als globaler Auditor (Altbestand, tenant-loser Zugriff), wenn sess.TenantID == nil. Mit gesetztem tenant_id wird er exakt wie domain_auditor behandelt (tenant-gescoped). Dafür wurde ein Helper eingeführt:

• internal/api/search_handlers.go:18 — neue Funktion auditorIsGlobal(sess *auth.Session) bool (return sess.Role == userstore.RoleAuditor && sess.TenantID == nil). Neuer Import archivmail/internal/auth.

Mail-Suche / Mail-Zugriff (internal/api/search_handlers.go)

• Index-Auswahl: sess.Role != userstore.RoleAuditor → !auditorIsGlobal(sess) (Per-Tenant-Index für tenant-gescopte Auditoren).
• Fallback-Tenant-Filter: gleiche Ersetzung (!auditorIsGlobal(sess)).
• Enrichment-No-Tenant-Filter (auditorAllowedIDs): greift jetzt nur noch bei auditorIsGlobal(sess).
• handleGetMail, handleGetAttachment, handleGetRaw: der IsWithoutTenant-Block läuft jetzt nur bei auditorIsGlobal(sess). Tenant-gescopte Auditoren sind durch den vorhandenen sess.TenantID != nil-Block (GetTenantForMail) abgedeckt.

Export (internal/api/export.go)

• handleExportPDF: IsWithoutTenant-Block → auditorIsGlobal(sess).
• handleExportZIP: No-Tenant-Preload (auditorAllowed) → auditorIsGlobal(sess); Tenant-ZIP-Isolation über vorhandenen sess.TenantID != nil-Block.

eDiscovery (internal/api/ediscovery.go)

• Index-Auswahl → !auditorIsGlobal(sess).
• No-Tenant-Preload → auditorIsGlobal(sess).
• (Hinweis: Wie bei domain_auditor existiert hier kein Post-Filter-Fallback, wenn idxMgr == nil — Verhalten bewusst identisch zu domain_auditor gehalten, kein neuer Scope.)

Threads (internal/api/thread_handlers.go)

• handleGetThread: Tenant-gescopte Auditoren werden über GetMailsByThread(ctx, threadID, tenantID) (tenantID != nil) gefiltert. Für globale Auditoren neu hinzugefügt: Vorladen der No-Tenant-IDs (GetAllIDsWithoutTenant) und Per-Mail-Skip — vorher gab es hier KEINE Auditor-Isolation (Pre-existing Gap geschlossen).

OCR (internal/api/ocr_handlers.go)

• handleGetOCRText: IsWithoutTenant-Block → auditorIsGlobal(sess).

Audit-Log (internal/audit/audit.go, internal/api/dashboard_handlers.go)

• QueryFilter um TenantID *int64 erweitert (audit.go ~Zeile 43).
• buildWhere() um NULL-sichere Klausel tenant_id = $n erweitert (audit.go ~Zeile 318) — Einträge mit NULL-tenant_id sind für tenant-gescopte Rollen damit unsichtbar (spec-konform).
• handleAuditLog (dashboard_handlers.go ~Zeile 47): setzt filter.TenantID = sess.TenantID, wenn sess.TenantID != nil. superadmin (nil TenantID) und ein legacy globaler auditor (nil TenantID) bleiben ungefiltert.

Befund: audit_log.tenant_id-Spalte

Die Spalte EXISTIERT bereits — sie wird in internal/tenantstore/store.go:79 via ALTER TABLE audit_log ADD COLUMN IF NOT EXISTS tenant_id BIGINT REFERENCES tenants(id) angelegt. Keine neue Migration nötig.

Audit-Log: tenant_id beim Schreiben befüllen (GESCHLOSSEN, 2026-06-21)

Der zuvor offene Punkt (neue Einträge mit tenant_id = NULL → für tenant-gescopte Rollen unsichtbar) ist jetzt gefixt. Minimal-invasive Lösung gewählt: Struct- Erweiterung, KEINE Signatur-Änderung von Log().

• audit.Entry um TenantID *int64 erweitert (audit.go ~Zeile 40), Typ identisch zu auth.Session.TenantID und QueryFilter.TenantID.
• Log()-INSERT schreibt jetzt die Spalte tenant_id mit (audit.go ~Zeile 195). Da Entry.TenantID per Zero-Value nil ist, mussten NICHT alle Call-Sites geändert werden — nur jene, wo ein Tenant bekannt ist.
• initSchema() legt tenant_id jetzt selbst idempotent an (ALTER TABLE audit_log ADD COLUMN IF NOT EXISTS tenant_id BIGINT), damit audit.go ohne tenantstore-Migration lauffähig bleibt (Tests, Fresh-Install). Kompatibel zur bestehenden tenantstore-Spalte (IF NOT EXISTS → No-Op bei der jeweils zweiten Anlage).

Geänderte Call-Sites (53 Audit-Einträge mit Tenant-Bezug):

• 46× internal/api/* via TenantID: sess.TenantID (alle Handler mit sess := sessionFromCtx(...) und Username: sess.Username) — per Skript eingefügt, gofmt-konform ausgerichtet.
• 3× internal/api/v1_handlers.go (externe API-Key-Sessions): neuer Helper apiKeyTenantPtr(akSess.TenantID) (API-Key-Tenant ist int64, 0 = tenant-los → nil).
• 2× internal/api/auth_handlers.go (Login erfolgreich + TOTP-pending): user.TenantID.
• 1× internal/api/totp_handlers.go (TOTP-Login abgeschlossen): user.TenantID.
• 3× internal/api/onboarding_handlers.go (invite_used → inviteTok.TenantID, signup/password_reset_requested → u.TenantID).
• 1× internal/imap/scheduler.go (imap_uidvalidity_reset): acc.TenantID.
• 1× internal/imapserver/server.go (imap_login erfolgreich): user.TenantID.

Bewusst NULL belassen (Tenant nicht zuverlässig ermittelbar / System-/superadmin-Event, nur superadmin sieht sie — spec-konform):

• Fehlgeschlagene Logins vor Authentifizierung: auth_handlers.go (rate-limited, invalid credentials), totp_handlers.go (totp_login_failed), imapserver/server.go (imap_login_failed) — kein User-/Tenant-Bezug vorhanden.
• onboarding_handlers.go: email_verified, password_reset_done — nur Token mit UserID vorhanden, kein Tenant ohne zusätzliche Abfrage; bewusst nil.
• Aktionen, bei denen sess.TenantID == nil ist (superadmin), bleiben automatisch systemweit — z.B. tenant_created (typischerweise durch superadmin).

Damit ist der Cross-Tenant-Filter nicht nur fail-closed isoliert, sondern liefert tenant-gescopten Rollen ab sofort auch tatsächlich ihre eigenen Einträge.

Implementation Notes — QA-Fixes (Backend, 2026-06-21)

BUG-1 behoben — eDiscovery fail-closed Post-Filter-Fallback

internal/api/ediscovery.go (handleExportEDiscovery):

• Index-Auswahl-Block (~Zeile 77-82): neues Flag usedTenantIndex eingeführt, gesetzt wenn der Per-Tenant-Index verwendet wird (analog handleSearch).
• Nach dem searchIdx.Search(...) (~Zeile 89-110): neuer Post-Filter ergänzt. Wenn tenantID != nil && !usedTenantIndex && !auditorIsGlobal(sess) (Fallback auf globalen Index bei nicht-verdrahtetem idxMgr), werden die Treffer über s.store.GetAllIDsByTenant(ctx, tenantID) serverseitig auf den eigenen Tenant gefiltert. Fail-closed: bei einem Fehler des Tenant-ID-Lookups bricht der Export mit HTTP 500 ("access check failed") ab, statt ungefilterte Treffer zu liefern (strenger als handleSearch, das den Fehler ignoriert — beim Export ist Fail-Closed angemessen).
• Schließt den latenten Cross-Tenant-Datenabfluss-Vektor, der zuvor identisch zu domain_auditor bestand. Da der Fallback rollenneutral greift (!auditorIsGlobal), ist damit auch domain_auditor mit abgedeckt.

BEFUND-3 behoben — tenant_id im tamper-evidenten Flat-File-Audit-Log

internal/audit/audit.go:

• fileEntry-Struct (~Zeile 76-89) um TenantID *int64 mit Tag json:"tenant_id,omitempty" erweitert — identisch zu Entry.TenantID.
• writeFile() (~Zeile 234-247) befüllt TenantID: entry.TenantID beim Schreiben der JSON-Lines-Zeile. DB-INSERT und Flat-File sind jetzt konsistent im Tenant-Bezug; tenant-lose/System-Events lassen das Feld dank omitempty weg.

QA Test Results (Code-Review + Red-Team, 2026-06-21)

Methodik: Statische Code-Review + Red-Team-Analyse aller in den Implementation Notes genannten Pfade (search_handlers.go, export.go, ediscovery.go, thread_handlers.go, ocr_handlers.go, audit.go, dashboard_handlers.go, admin_handlers.go, server.go, v1_handlers.go). Kein Live-HTTP-Test gegen 192.168.1.132 durchgeführt (reine Quellcode-Bewertung) — siehe Empfehlung unten.

Acceptance Criteria

AC	Ergebnis	Anmerkung
AC1 — auditor mit tenant_id: /api/search nur eigener Tenant	PASS	auditorIsGlobal() schließt tenant-gescopten Auditor aus dem No-Tenant-Pfad aus; Per-Tenant-Index (Zeile 123) bzw. GetAllIDsByTenant-Fallback vor Pagination (Zeile 137) greift wie bei domain_auditor.
AC2 — handleGetMail/Raw/Attachment/Export/eDiscovery/Threads/OCR verweigern Fremd-Tenant (403)	PASS	GetMail/Raw/Attachment/PDF/ZIP/OCR: tenant-gescopt durch sess.TenantID != nil-Block (GetTenantForMail-Vergleich) — korrekt. Threads: GetMailsByThread(…, tenantID) filtert serverseitig — korrekt. eDiscovery: BUG-1 in Re-Test 2026-06-21 als geschlossen verifiziert (fail-closed Post-Filter ergänzt).
AC3 — /api/audit tenant-gescopt für domain_admin/domain_auditor/auditor	PASS	handleAuditLog setzt filter.TenantID = sess.TenantID bei != nil; buildWhere erzeugt NULL-sicheres tenant_id = $n. RBAC-Route requireRole(RoleAuditor) erlaubt alle vier Rollen.
AC4 — superadmin unberührt (alle Tenants/Logs)	PASS	superadmin hat TenantID == nil → kein Index-Scoping, kein Audit-Filter.
AC5 — keine Regression für domain_admin/domain_auditor/user	PASS	Bestehende Blöcke unverändert; auditorIsGlobal() liefert für Nicht-Auditor-Rollen immer false, ändert deren Pfade also nicht.
AC6 — auditor ohne tenant_id behält globalen Zugriff	PASS	auditorIsGlobal() true → alle No-Tenant-Pfade aktiv wie zuvor. Dokumentiert in den Implementation Notes.

Acceptance Criteria: 6/6 PASS (AC2 mit dokumentiertem Vorbehalt, siehe BUG-1).

Sicherheits-Befunde (Red Team)

BUG-1 — eDiscovery: kein Post-Filter-Fallback bei idxMgr == nil (Severity: Medium, latent) internal/api/ediscovery.go:78 — Wenn der Per-Tenant-Index-Manager nicht verdrahtet ist (s.idxMgr == nil), fällt ein tenant-gescopter Auditor/domain_auditor auf searchIdx = s.idx (globaler Index) zurück. Da auditorIsGlobal(sess) dann false ist, wird auditorAllowed nicht gesetzt, und es gibt — anders als in handleSearch (Zeile 137, GetAllIDsByTenant) — KEINEN serverseitigen Tenant-Post-Filter. Folge: eDiscovery-Export würde Mails ALLER Tenants liefern.

• Reproduktion: Deployment mit nicht-verdrahtetem idxMgr (Test/Fehlkonfiguration), Auditor mit tenant_id ruft POST /api/export/ediscovery auf → erhält Fremd-Tenant-Mails.
• In Produktion nicht ausgelöst: main.go:350 SetIndexManager(idxMgr) setzt idxMgr immer ungleich nil. Risiko ist rein latent (Defense-in-Depth-Lücke), aber bei DSGVO-Kritikalität und der ausdrücklichen Frage im Auftrag relevant.
• Implementation Notes bestätigen das bewusst ("kein Post-Filter-Fallback, identisch zu domain_auditor"). Bewertung: das Verhalten ist konsistent mit domain_auditor, aber damit ist domain_auditor genauso betroffen — die Konsistenz heilt das Leck nicht.
• Empfehlung Backend: In handleExportEDiscovery denselben GetAllIDsByTenant-Post-Filter wie in handleSearch ergänzen, wenn tenantID != nil && !usedTenantIndex. Fail-closed.

BEFUND-2 — NULL-Assignment-Eskalation NICHT ausnutzbar (PASS, Severity: keine) Geprüft auf die Auftragsfrage "kann ein Tenant-Admin seinem Auditor versehentlich tenant_id=NULL zuweisen?": Nein.

• handleCreateUser (admin_handlers.go:80-83) setzt tenantID = sess.TenantID zwingend aus der Session des Erstellers. Ein domain_admin (tenant_id gesetzt) kann KEINEN tenant-losen Auditor anlegen — der Wert wird ignoriert/überschrieben, der Request-Body enthält gar kein tenant_id-Feld.
• handleUpdateUser (admin_handlers.go:135-140) hat kein tenant_id-Feld im Request-Struct — die Tenant-Zuordnung ist per API überhaupt nicht änderbar.
• Nur ein superadmin (tenant_id == nil) erzeugt beim Anlegen eines Auditors tenant_id=NULL → bewusst globaler Auditor. Das ist spec-konform und nicht eskalierbar von unten.

BEFUND-3 — Flat-File-Audit-Log enthält kein tenant_id (Severity: Low) audit.go:76-85 fileEntry und writeFile schreiben tenant_id NICHT in die tamper-evidente JSON-Lines-Datei (PROJ-48), obwohl die DB-Spalte jetzt befüllt wird. Keine Isolations-Lücke (Datei ist nur superadmin/forensisch zugänglich), aber Inkonsistenz: DB- und Datei-Audit divergieren im Tenant-Bezug. Für vollständige GoBD-/forensische Nachvollziehbarkeit sollte tenant_id auch in fileEntry aufgenommen werden.

BEFUND-4 — domain_auditor-ohne-Tenant-Guard in eDiscovery vorhanden, aber Auditor-ohne-Tenant NICHT geblockt (PASS, by design) ediscovery.go:48 blockt RoleDomainAuditor ohne Tenant. Ein globaler auditor (RoleAuditor, tenant_id nil) wird hier bewusst NICHT geblockt — er ist legitim global und wird über auditorAllowed (No-Tenant-IDs) korrekt eingegrenzt. Konsistent mit AC6. Kein Bug.

BEFUND-5 — Audit-Logging schreibender Operationen (PASS) Search/Export/PDF/ZIP/OCR/eDiscovery/UserMgmt setzen TenantID: sess.TenantID in audit.Entry — stichprobenartig verifiziert. Cross-Tenant-Filter liefert tenant-gescopten Rollen damit ihre eigenen Einträge. Login-/System-Events bleiben bewusst NULL (nur superadmin- sichtbar), spec-konform.

Regression

• domain_auditor/domain_admin/user-Pfade: unverändert, auditorIsGlobal() ist für sie immer false. Kein Regressionsrisiko erkennbar.
• PROJ-54 (User-Pagination): AnyAddress-Filter unberührt.

Zusammenfassung

• Acceptance Criteria: 6 PASS / 0 FAIL (AC2 mit Vorbehalt BUG-1).
• Bugs: 1× Medium (latent, BUG-1 eDiscovery Fail-Open), 1× Low (BEFUND-3 Flat-File tenant_id).
• Kein Critical, kein High. NULL-Eskalation-Vektor geprüft und ausgeschlossen.

Production-Ready-Bewertung: BEDINGT READY

Kein Critical/High → formal deploybar. Wegen DSGVO-Kritikalität und der ausdrücklich strengen Bewertung lautet die Empfehlung jedoch: BUG-1 (eDiscovery Post-Filter-Fallback) vor SaaS-/ Multi-Tenant-Produktivfreigabe schließen (fail-closed analog handleSearch), da der eDiscovery- Export der höchste Cross-Tenant-Datenabfluss-Vektor ist. BEFUND-3 (Flat-File) als Folge-Ticket. Vor Deploy zusätzlich Live-Verifikation auf 192.168.1.132 mit echtem tenant-gescopten Auditor empfohlen (Code-Review ersetzt keinen Integrationstest gegen Manticore-Index-Auswahl).

QA Re-Test nach Fixes (Code-Review, 2026-06-21)

Auftrag: Verifizieren, ob BUG-1 (eDiscovery fehlender Tenant-Post-Filter-Fallback) und BEFUND-3 (Flat-File-Audit-Log fehlendes tenant_id) korrekt geschlossen sind.

BUG-1 — eDiscovery Post-Filter-Fallback: GESCHLOSSEN (verifiziert)

internal/api/ediscovery.go handleExportEDiscovery:

• Index-Auswahl-Block (Zeile 77-82) führt usedTenantIndex ein — gesetzt, sobald der Per-Tenant-Index via s.idxMgr.ForTenant(tenantID) verwendet wird. Identisch zur Referenzlogik in handleSearch (search_handlers.go:122-126).
• Post-Filter (Zeile 95-113): Bedingung tenantID != nil && !usedTenantIndex && len(result.Hits) > 0 && !auditorIsGlobal(sess) greift exakt im Fallback-Fall (globaler Index trotz tenant-gescopter Session). Filtert die Treffer serverseitig über s.store.GetAllIDsByTenant(ctx, tenantID) VOR der ZIP-Erzeugung.
• Fail-closed bestätigt: Bei idErr != nil bricht der Export mit HTTP 500 ("access check failed") ab (Zeile 97-100) — strenger als handleSearch, das den Fehler ignoriert (search_handlers.go:139 if idErr == nil). Für einen Export ist Fail-Closed die korrekte und sicherere Wahl. Kein ungefilterter Datenabfluss möglich.
• Greift rollenneutral (!auditorIsGlobal) → deckt sowohl tenant-gescopten auditor als auch domain_auditor ab. Der zuvor latente Fail-Open-Vektor (Cross-Tenant-Leck bei nicht-verdrahtetem idxMgr) ist geschlossen.
• Ergebnis: PASS. BUG-1 korrekt behoben.

BEFUND-3 — Flat-File-Audit-Log tenant_id: GESCHLOSSEN (verifiziert)

internal/audit/audit.go:

• fileEntry-Struct (Zeile 76-89) enthält jetzt TenantID *int64 mit Tag json:"tenant_id,omitempty" — typgleich zu Entry.TenantID und QueryFilter.TenantID.
• writeFile() (Zeile 230-256) befüllt TenantID: entry.TenantID (Zeile 247) beim Marshalling der JSON-Lines-Zeile. DB-INSERT (Zeile 207-218) und Flat-File sind damit konsistent im Tenant-Bezug. Tenant-lose/System-Events lassen das Feld dank omitempty weg — kein leeres/null-Feld in der tamper-evidenten Datei.
• Ergebnis: PASS. BEFUND-3 korrekt behoben. DB- und Datei-Audit divergieren nicht mehr; GoBD-/forensische Nachvollziehbarkeit hergestellt.

Stützende Verifikation

• Helper auditorIsGlobal() existiert (search_handlers.go:24), Store-Methode GetAllIDsByTenant() existiert (storage.go:1194). Keine fehlenden Symbole.
• Lokaler go build nicht möglich (kein Go im lokalen PATH, projektkonform — Build nur per SSH auf Testserver). Code ist gofmt-konform strukturiert; keine offensichtlichen Compile-Risiken in den geänderten Pfaden.

Re-Test-Fazit: Beide offenen Punkte geschlossen.

• Bugs offen: 0 (kein Critical, High, Medium oder Low mehr offen).
• Acceptance Criteria: 6/6 PASS (AC2-Vorbehalt durch BUG-1-Fix aufgehoben).

Production-Ready-Bewertung (final): JA

Alle in der vorherigen QA-Runde gefundenen Befunde sind geschlossen. Code-Review ist schlüssig — kein Live-Test für die Bewertung erforderlich.

Wichtiger Vorbehalt: Eine Live-Verifikation auf 192.168.1.132 mit einem echten tenant-gescopten auditor-Account (eDiscovery-Export + Audit-Log-Abruf gegen reale Manticore-Index-Auswahl und PostgreSQL) wird vor dem SaaS-/Multi-Tenant-Go-Live weiterhin ausdrücklich empfohlen. Code-Review ersetzt keinen Integrationstest gegen die tatsächliche Index-/DB-Schicht. Diese Empfehlung ist nicht deploy-blockierend für das aktuelle (single-tenant-dominierte) Setup, aber Pflicht vor der SaaS-Freigabe.

Live-Verifikation auf 192.168.1.132 (2026-06-22)

Test-Account homelocal-auditor@homelocal.local (tenant_id=3, role=auditor) angelegt/Test-Passwort gesetzt, eingeloggt, GET /api/search?q=test&page_size=50 ausgeführt: 49 von 50 Treffern korrekt tenant_id=3, 1 Treffer (6cf020fb...d5a, emails.tenant_id=1) initial als Cross-Tenant-Leak verdächtigt.

Nachverifikation: Kein Leak. Die Mail ging von patrick@perlbach24.de (Tenant 1) an bundyxl@gmx.de, welcher im Tenant "homelocal" (Tenant 3) als patrick.perlbach@gmx.de archiviert wird. email_refs hat dafür korrekt zwei Einträge (tenant_id=1 und tenant_id=3) — das ist der beabsichtigte Cross-Tenant-Dedup-Mechanismus (eine physische Mail kann mehreren Tenants zugeordnet sein, wenn sie an Empfänger unterschiedlicher Tenants ging). Der auditor mit tenant_id=3 sieht die Mail zu Recht, da sie tatsächlich seinem Tenant zugeordnet ist (email_refs.tenant_id=3).

Lehre für künftige Live-Tests: Tenant-Zugehörigkeit einer Mail ausschließlich über emails.tenant_id zu prüfen ist unzureichend — email_refs muss als zusätzliche, gültige Tenant-Zuordnung berücksichtigt werden (siehe internal/storage/storage.go:1194 GetAllIDsByTenant, nutzt email_refs, nicht emails.tenant_id).

PROJ-55 Live-Verifikation: PASS. Keine offenen Befunde mehr.

Deployment

• Test: 192.168.1.132 — update.sh (Commit 1d27dc2), Backend+Frontend laufen, neuer HTTP-Health-Check bestätigt funktionsfähig, Reindex-Schritt korrekt entfernt. Live-Test PROJ-55 bestanden (siehe oben).
• Produktion: 192.168.1.131 — ausstehend