Tests gegen synthetische Fixtures je Akzeptanzkriterium sowie
Pruefprotokoll mit real ausgefuehrten Ergebnissen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
LDAP-Sync ergaenzt eine fehlende ldap_uid bei einem Treffer nachtraeglich,
ohne den Lauf bei fehlender UID zu blockieren.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
seal/open (bzw. wrap/unwrap) in allen vier betroffenen Stellen binden
ein Additional Authenticated Data an Chiffretext/DEK-Wrapper: ein
Austausch zwischen zwei Kontexten faellt beim Entschluesseln auf,
statt still zu funktionieren.
- dms/internal/crypto/envelope.go + service.go: AAD = Tenant-Slug
(bereits vorhandener Parameter in Service.Seal/Open, Signatur
unveraendert -- keine der rund 30 externen Aufrufstellen musste
angepasst werden)
- archive/internal/backupcrypto/envelope.go + reposecret.go/file.go:
gleiches Muster, AAD = Tenant-Slug
- mail/internal/crypto/envelope.go + service.go + kekversions.go:
gleiches Muster, AAD = Tenant-Slug (inkl. ARC-08
KEK-Versionsverwaltung)
- internal/kek/master.go + store.go: wrap/unwrap sowie
EncryptWithTenantKEK/DecryptWithTenantKEK binden AAD. Die drei
echten externen Aufrufer angepasst: ldapsync (Tenant-ID + Zweck),
webhook (Ziel-URL des Abonnements), account-api modulekeys (fester
Zweck-Bezeichner -- SecretCipher-Interface aus internal/moduletrust
reicht keine Datensatz-ID durch, eine Erweiterung wuerde in andere
Module hineinwirken, bewusst nicht Teil dieser Kachel)
Rueckwaertskompatibel: jedes open/unwrap versucht zuerst mit AAD,
faellt bei Fehlschlag auf kein-AAD zurueck -- vor dieser Aenderung
versiegelte Datensaetze bleiben lesbar.
Bekannte, dokumentierte Grenze: ein Austausch zwischen zwei
Datensaetzen DESSELBEN Mandanten/Kontexts bleibt unerkannt (identisches
AAD) -- volle Bindung an den einzelnen Datensatz braeuchte eine
Datensatz-ID an rund 30 Aufrufstellen, bewusst nicht Teil dieser
kleinstmoeglichen Loesung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zwei kleine Nacharbeiten aus dem Testlauf auf 131:
- ConfigStore.Save nutzte einen Multi-Statement-Exec (DELETE; INSERT), den
pgx im extended protocol ablehnt ("cannot insert multiple commands into a
prepared statement") -- jetzt als Transaktion mit zwei Exec-Aufrufen.
- Das Test-Setup fuer die tenants-Tabelle in config_store_test.go war
schlanker als das in internal/kek/kek_test.go verwendete Vollschema
(fehlende Spalten previous_status/deletion_scheduled_at/
retention_block_reason/retention_checked_at). Da beide Pakete im
Gesamttestlauf dieselbe Test-Datenbank per CREATE TABLE IF NOT EXISTS
teilen, hat das schlankere Schema (wenn zuerst angelegt) den kek-Test
TestTenantKEKHandler_AllowsActiveModuleForTenant zum Fehlschlagen
gebracht. Jetzt identisches Vollschema wie kek_test.go.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
Speichert das LDAP-Bind-Passwort je Tenant ausschliesslich verschluesselt
mit dem Tenant-KEK aus API-10 (AES-256-GCM, kek.EncryptWithTenantKEK/
DecryptWithTenantKEK) statt in einem separaten Secret-Schema oder Klartext
(Keycloak-Antipattern bewusst vermieden). Neue Tabelle ldap_bind_config in
der Tenant-Datenbank (Migration 0009), neuer internal/ldapsync.ConfigStore
fuer Save/Get, rein additiv zu IAM-05 (Syncer/RoleMappingStore unveraendert).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP
internal/ldapsync: Client ist eine Schnittstelle (Search() liefert Entry-
Liste) — in dieser Umgebung steht kein echter LDAP/AD-Server zur Verfuegung
(analog AUD-05/Archive), daher ist die Sync-/Rollenzuordnungs-Logik
vollstaendig gegen einen Fake getestet, eine echte Verbindungspruefung gegen
LDAP/AD steht noch aus.
RoleMappingStore (Akzeptanzkriterium 3): explizite Erlaubnis-Matrix
LDAP-Gruppe -> Rolle. HighestRoleFor vergibt NUR fuer explizit gemappte
Gruppen eine Rolle — eine unbekannte Gruppe, auch wenn ihr Name zufaellig
wie eine interne Rolle aussieht ("tenant_admin", "superadmin"), traegt
strukturell nichts bei (kein Code-Pfad, der eine ungemappte Gruppe je einer
Rolle zuordnet) — behebt die aus archivmail bekannte Privilege-Escalation-
Fehlerklasse von Grund auf statt nachtraeglich zu haerten.
Syncer.Run ruft Search() als ALLERERSTES auf; schlaegt es fehl, wird ohne
jede Aenderung an bestehenden Konten abgebrochen (Akzeptanzkriterium 2).
Pro Eintrag isolierte Fehler landen in SyncResult.Failed, ohne andere
Eintraege zu beeintraechtigen. Deaktivierung in LDAP wird als
users.Deactivate uebernommen (Akzeptanzkriterium 3). ldap_config speichert
bewusst nur den NAMEN einer Umgebungsvariable fuer das Bind-Passwort, nie
das Passwort selbst.
internal/rbac (RBAC-01) wurde 1:1 aus dem rbac-01-Branch uebernommen (git
show aus derselben Repo-Historie) — IAM-05 haengt an RBAC-01 fuer die
Rollenzuweisung, beide Boards leben aber auf getrennten, noch nicht
gemergten Feature-Branches ohne gemeinsame Historie.
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Rollen-Erlaubnis-Matrix mit Positiv- und Negativfaellen automatisiert
getestet (keine Privilege-Escalation) — TestRoleMapping_PositiveAndNegativeCases:
gemappte Gruppe liefert Rolle, unbekannte Gruppe und rollen-aehnlich
benannte, aber nie gemappte Gruppen liefern keine. PASS.
2. Synchronisationslauf mit fehlerhafter/nicht erreichbarer LDAP-Quelle
bricht kontrolliert ab, ohne bestehende Konten zu beschaedigen —
TestSyncer_AbortsCleanlyOnSourceError: bestehendes Konto bleibt nach
fehlgeschlagenem Lauf unveraendert aktiv. PASS.
3. Deaktivierung eines Benutzers in LDAP wird bei naechster Synchronisation
korrekt uebernommen — TestSyncer_AppliesDeactivationOnNextRun: erster
Lauf legt aktiven Benutzer an, zweiter Lauf mit Disabled=true setzt ihn
auf inaktiv. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
patrick
