Sicherheitsanlage

Wie diese Seite zu lesen ist. Jede Aussage verweist auf eine konkrete Datei oder ein Runbook im Code. Die "Referenz"-Spalte verlinkt die Quelle, sodass externe Auditoren die Implementierungs-Realität — nicht Marketing-Aussagen — verifizieren können.

1. Vertraulichkeit

1.1 Verschlüsselung at-rest

Der Application-Layer-Envelope-Key (ENCRYPTION_KEY) liegt ausschließlich im Plattform-Secret-Store, nie im Quellcode. Die quartalsweise Rotation ist in docs/runbooks/service-account-least-privilege.md dokumentiert.

1.2 Verschlüsselung in-transit

• TLS 1.2+ für alle öffentlichen Endpoints erzwungen (HSTS-Preload via proxy.ts).
• Alle Sub-Auftragsverarbeiter-Verbindungen nutzen TLS 1.2+.
• Server-zu-Server-Credentials (Firebase Admin, Vertex AI, Stripe) per kurzlebigem OIDC oder Service-Account-Key authentifiziert; keine Passwörter im Transit.

1.3 Pseudonymisierung von LLM-Payloads

Hochgeladene Dateien verlassen den Browser nie als Rohdaten zur LLM-Inferenz. An Vertex AI gehen ausschließlich:

• pseudonymisiertes Schema (Spaltennamen, -typen, Sample-Row-Hashes),
• aggregierte Statistiken (Counts, Verteilungen, Distinct-Werte),
• explizit über Governance freigegebene Spalten.

Die Transformation ist in lib/agents/transform/pii.ts implementiert und an der Export-Grenze server-seitig durchgesetzt (lib/server/google/sheets-governance.ts).

2. Integrität

• Manipulationssicheres Audit-Log. Jede administrative Aktion wird in eine hash-verkettete admin_audit-Collection angefügt (lib/server/audit-log.ts). Die Integrität ist offline über scripts/audit-verify.ts verifizierbar.
• Eingabe-Validierung. Alle API-Routes validieren Request-Bodies vor Verarbeitung; ungültige Payloads → 400.
• Rate-Limiting. Persistentes per-User- und per-IP-Rate-Limiting auf Firestore-Basis (lib/server/rate-limit.ts) verhindert Replay/Credential-Stuffing über Instanzen hinweg.
• Circuit Breaker. Externe Integrationen (Stripe, Vertex, Firebase Admin) sind in einen Drei-Zustands-Circuit-Breaker gekapselt (lib/server/circuit-breaker.ts), sodass ein Upstream-Vorfall nicht zum kunden-sichtbaren Sturm eskaliert.

3. Verfügbarkeit und Resilienz

• SLOs. Öffentliche Service-Level-Objectives unter /status: 99,9 % Verfügbarkeit, Agent-p95 < 30 s, Workspace-TTFB-p95 < 1,5 s. Burn-Rate-Alerts feuern bei 50 % und 90 % Budget-Verbrauch.
• Backup. Tägliche Managed-Firestore-Exports nach GCS via scripts/firestore-backup.sh. Recovery-Ziele: RPO 24 h, RTO 4 h, 35-tägige Rolling-Retention. Dokumentiert in docs/runbooks/disaster-recovery.md.
• DR-Drill. Quartalsweiser Drill in einem separaten DR-Projekt; aktuelles Drill-Log in docs/runbooks/disaster-recovery.md §6.
• Incident-Response. Dokumentiert in docs/runbooks/incident-response.md. Öffentliche Status-Seite unter /status zeigt laufende und behobene Vorfälle.

4. Angriffsresistenz

• CSP, X-Frame, HSTS, X-Content-Type-Options. Plattform-weit in proxy.ts gesetzt.
• CSRF. Server-seitige OAuth-Flows nutzen HMAC-signierte state-Parameter (lib/server/google/state.ts).
• SSRF. Sämtliche ausgehenden HTTP-Calls des Crawler-Subsystems laufen über einen Allow-Listen-Fetcher (lib/agents/crawler/ssrf-guard.ts).
• Secret-Scanning. gitleaks läuft in CI (.github/workflows/) und als Pre-Commit-Hook via scripts/install-git-hooks.sh.
• Software-Composition-Analysis. npm audit und osv-scanner bei jedem CI-Build; High-Severity-Findings blockieren das Merge-Gate.
• Server-side Error-Capture. Alle API-Routes kapseln ihre Handler in withErrorCapture (lib/server/error-capture.ts); unbehandelte Exceptions werden per Hash aggregiert und bei Erreichen der SEV-1/SEV-2-Schwellen automatisch zu support_tickets promoted.
• PII-Redaction an Log-Sinks. Alle strukturierten Logs werden vor Übertragung zu Sentry o. a. durch lib/server/redact.ts geführt.

5. Zugriffskontrolle

• Authentifizierung. E-Mail/Passwort (Argon2id via Firebase Auth) und Google OAuth.
• Autorisierung. Firestore-Security-Rules (firestore.rules) verweigern Client-Lesen/-Schreiben für jede in C10 eingeführte administrative oder Telemetrie-Collection.
• Admin-Aktionen. Zwei-stufig (server-seitig requireAdmin + Audit-Log-Eintrag) bei jeder privilegierten Route.
• Least Privilege. GCP-Service-Accounts in docs/runbooks/service-account-least-privilege.md mit quartalsweiser Key-Rotation.

6. Personal

• Aktuell Einzelunternehmen (Marc Cherier). Externe Auftragnehmer unterzeichnen Vertraulichkeits- und AVV-Anhänge vor Zugriffsfreigabe.
• Hardware: Vollverschlüsselung, MFA auf allen Produktionskonten.
• Hintergrundprüfung: vorgesehen für künftige Auftragnehmer mit Produktionszugriff.

7. Datensparsamkeit und Aufbewahrung

• Konto-bezogene Metadaten: für die Lebensdauer des Kontos; gesetzliche Rechnungsdaten 10 Jahre (HGB §257).
• Kundenseitig hochgeladene Daten: solange das Projekt existiert; Löschung in Produktion innerhalb von 30 Tagen nach Projektlöschung; Backup-Lösung innerhalb von 35 Tagen.
• Telemetrie (connector_events, slo_samples, error_signals_aggregated): 90-tägige Rolling-Retention.

8. Schwachstellen-Management

• Disclosure. Siehe /trust/vdp und /.well-known/security.txt.
• Patching-SLA. Kritische CVEs in Produktions-Dependencies innerhalb von 7 Tagen nach Vendor-Disclosure; High-Severity innerhalb von 14 Tagen.
• Penetrationstest. Externer Pen-Test angestrebt für Q3 2026 vor dem Marketing-Launch. Danach jährliche Kadenz.

9. Dokumentations-Verweise

• Disaster Recovery: docs/runbooks/disaster-recovery.md
• Incident Response: docs/runbooks/incident-response.md
• Threat Model (Q2 2026 Snapshot): docs/runbooks/threat-model-2026-q2.md
• Service-Account-Inventar: docs/runbooks/service-account-least-privilege.md
• SLO-Definitionen und Burn-Rate-Logik: lib/server/slo.ts

Dokumentversion: 1.0 — Wirksam ab: 2026-04-17