Admin-Read-Audit
Nachvollziehbarkeit und Kontrolle privilegierter Lesezugriffe
1. Schutzzweck und Geltungsbereich
Diese Seite ist technische Dokumentation zur Compliance-Transparenz für privilegierte Lesezugriffe auf sensible Datendomänen innerhalb der prokodo Marketplace-Plattform.
Sie ist nicht Teil der Vertragsdokumente, enthält keine eigenständige Leistungszusage und keine Garantie; maßgeblich sind die vertraglich einbezogenen Dokumente (insbesondere AGB, Seller-Bedingungen, Verification Policy und Refund & Dispute Policy).
Bei Widersprüchen zwischen dieser Seite und den Vertragsdokumenten gehen die Vertragsdokumente vor.
Der Geltungsbereich umfasst insbesondere: Nutzerprofile, Compliance-Dokumente (Löschanträge, Löschrichtlinien), Erasure-Jobs und deren Status, Audit-Event-Kollektionen, Tombstone-Daten und sicherheitsrelevante Metadaten.
Privilegierter Zugriff ist definiert als jeder lesende Zugriff, der über die Berechtigungen eines regulären, nicht-administrativen Nutzers hinausgeht — unabhängig davon, ob er über die Anwendungsoberfläche, direkte Datenbankabfragen oder Admin-SDK-Operationen erfolgt.
Stand: 16. Februar 2026. Änderungen vorbehalten.
2. Mindestkontrollen (Minimum Controls)
Privilegierter Lesezugriff soll nach den folgenden kumulativen Bedingungen erfolgen. Diese Kontrollen beschreiben den vorgesehenen Governance-Rahmen; strengere Regelungen können teamspezifisch gelten.
- RBAC (Role-Based Access Control): Zugriff basiert auf zugewiesener Administratorrolle, bestimmt durch Firestore-Rollenfeld oder Firebase Custom Claims. Default-Deny in Firestore Security Rules und Storage Rules
- Need-to-know und Least Privilege: Zugriff nur auf diejenigen Datendomänen, die für die konkrete Aufgabe erforderlich sind
- Zweckbindung: Verpflichtende Angabe des Zugriffszwecks vor sensitiven Read-Operationen. Implementiert als Pflichtfeld in Admin-Audit-Events (Feld: reasonCode und note)
- Vier-Augen-Prinzip: Für hochsensible oder großvolumige Lesezugriffe vorgesehen (z. B. Massen-Export, Compliance-Prüfungen). Interner Validierungshinweis (ohne vertragliche Zusage): technische Durchsetzung für definierte Hochrisiko-Operationen wird intern bewertet und ggf. umgesetzt.
- Stichprobenprüfung: Regelmäßige manuelle oder automatisierte Prüfung der Audit-Protokolle auf Anomalien und unbegründete Zugriffe. Interner Validierungshinweis (ohne vertragliche Zusage): Prüfintervall und Stichprobengröße werden intern festgelegt.
3. Audit-Evidenz-Anforderungen (Who/When/What/Why)
Privilegierte Lesezugriffe auf sensible Datendomänen sollen mit folgenden Mindestfeldern protokolliert werden. Die folgende Darstellung beschreibt den aktuellen technischen Ziel- und Ist-Rahmen der Audit-Event-Struktur:
- Wer (Who): actorUid (Nutzer-ID des zugreifenden Administrators) und actorEmailHash (pseudonymisierter HMAC-SHA256-Hash der E-Mail-Adresse des Administrators – kein Klartext gespeichert)
- Wann (When): createdAt (Server-Zeitstempel des Zugriffs)
- Was (What): actionType (Art der Aktion, z. B. CANCEL_RUN, FAIL_RUN, RETRY_RUN, VERSION_RELEASED, VERSION_REJECTED), listingId, semver, runId (kontextuelle Identifikatoren)
- Warum (Why): reasonCode (maschinenlesbar) und note (Freitextfeld, max. 500 Zeichen, automatisch bereinigt für Secrets: GitHub-Tokens, AWS-Schlüssel, Stripe-Schlüssel, private Schlüssel)
- Deduplizierung: requestId als eindeutiger Schlüssel je Audit-Event
- Speicherort: Dedizierte Firestore-Kollektion. Firestore Security Rules: lesender Zugriff nur für Administratoren; kein Client-Schreibzugriff (schreibende Zugriffe ausschließlich server-seitig)
- Integrität: Audit-Notes werden auf enthaltene Credentials geprüft und bereinigt. Kein Client-seitiger Schreibzugriff auf die Audit-Kollektion. Interner Validierungshinweis (ohne vertragliche Zusage): zu bestätigen ist, ob Append-only-Write oder Write-only-Separation implementiert ist oder intern geplant wird.
4. Löschstatus-Kommunikation (Guardrails)
Die Kommunikation des Löschstatus gegenüber Nutzern und Support-Mitarbeitern ist strikt an den technischen Verarbeitungsstand gebunden. Ein Vorgreifen auf nicht erreichte Zustände ist unzulässig.
- erased_core: Kernidentitäten im primären Nutzerprofil und Auth-System entfernt/anonymisiert. Externe Konnektoren (Stripe, Mailchimp, Typesense, Storage) können noch ausstehen. Zulässige Kommunikation: "Konto deaktiviert; endgültige Löschung wird durchgeführt."
- erased_complete: Alle sechs konfigurierten Löschziele terminal (succeeded oder skipped/NOT_APPLICABLE). Evidenz im Erasure-Job dokumentiert. Zulässige Kommunikation: "Löschung gemäß Richtlinie abgeschlossen; nur gesetzlich erforderliche Restdaten verbleiben."
- Aussage "Löschung abgeschlossen" ist ausschließlich bei erreichtem Status erased_complete zulässig
- Bei Legal Hold (LEGAL_HOLD, OPEN_DISPUTE, FRAUD_REVIEW): Nur minimal erforderliche Restdaten mit dokumentierter Rechtsgrundlage. Kommunikation: "Löschung aufgrund gesetzlicher Verpflichtung vorübergehend ausgesetzt."
- Backups und Log-Streams: Ergänzender Hinweis, dass Löschung aus Sicherungssystemen über konfigurierte Aufbewahrungsfenster erfolgt
5. Retentionswerte und kanonische Matrix
Die folgenden Werte basieren auf der aktuellen Infrastrukturkonfiguration (Firestore TTL-Ressourcen, Terraform-definiert) und den Konstanten im Erasure-Worker-Code. Die kanonische Retention-Matrix ist die verbindliche Primärquelle.
- Erasure-Jobs (Orchestrierungsdaten): 90 Tage — TTL-durchgesetzt via Firestore expiresAt-Feld
- Erasure-Audit-Events (Compliance-Nachweis): 180 Tage — TTL-durchgesetzt via Firestore expiresAt-Feld
- Erasure-Dead-Letters (Fehler-/Wiederherstellungsnachweise): 180 Tage — TTL-durchgesetzt via Firestore expiresAt-Feld
- User-Tombstones (pseudonymisierte Unterdrückungsdaten): 365 Tage — TTL-durchgesetzt via Firestore expiresAt-Feld
- Firestore-Backups: 14 Wochen (8.467.200 Sekunden; konfiguriert in Terraform). Keine Einzelobjektlöschung; Entfernung über Backup-Rotation
- Cloud Logging: gemäß Log-Senken-Retention-Einstellung. Keine Einzelobjektlöschung
- Fehlertelemetrie (Bugsnag): gemäß Anbieter-Retention-Einstellung. Keine direkte Per-User-Löschgarantie
- Typesense-Snapshots: 14 Tage (konfiguriert). Artefakt-Registry-Images: 7 Tage alt / 10 neueste behalten
- Temporäre Uploads (GCS uploads/*): 14 Tage (Lifecycle-Rule)
6. Review- und Sanktionsmechanismus (Enforcement)
Folgende Kontrollmechanismen dienen der Sicherstellung der Einhaltung der vorstehenden Anforderungen:
- Monatliches Compliance-Review der Zugriffsprotokoll-Anomalien (geplant). Interner Validierungshinweis (ohne vertragliche Zusage): Review-Prozess und Owner werden intern formalisiert.
- Sofort-Eskalation bei unzulässigem Zugriff ohne dokumentierte Zweckbegründung
- Dokumentierte Korrekturmaßnahmen (Corrective Actions) und Präventionsmaßnahmen (Preventive Actions) bei festgestellten Abweichungen
- Management-Reporting zu kritischen Abweichungen und Trendanalyse
- Wiederholte Verstöße sind als Governance-Risiko zu klassifizieren und erfordern verschärfte Kontrollen (z. B. erweiterte Protokollierung, Zugriffseinschränkung, disziplinarische Maßnahmen)
- Auditergebnisse und Korrekturmaßnahmen sind mindestens für den Retention-Zeitraum der zugrundeliegenden Audit-Events aufzubewahren
