SOC 2-Audits sind nicht schwer, weil die Kontrollen kompliziert sind. Sie sind schwer, weil die Evidenz verstreut ist. Zugriffsreviews leben in Ihrem Identity Provider. Verschlüsselungsdetails sind in Infrastrukturkonfigurationen vergraben. Anbieterrisikobewertungen sitzen in Spreadsheets. Incident-Response-Verfahren existieren in einem Wiki, das seit dem letzten Audit nicht aktualisiert wurde. Audit-Logs sind in einer Datenbank, aber niemand hat sie in das Format aggregiert, das Ihr Auditor will.
Jedes Quartal verbringt jemand Tage damit, Daten aus sechs verschiedenen Systemen zu ziehen, sie in einen Bericht zu formatieren und zu hoffen, dass sich seit dem letzten Mal nichts geändert hat.
JieGous SOC 2-Evidenzaggregator eliminiert diese Arbeit. Ein API-Aufruf gibt einen strukturierten Bericht zurück, der sechs Evidenzabschnitte abdeckt — parallel aus Live-Plattformdaten abgerufen, für Performance gecacht und so konzipiert, dass er elegant fehlschlägt, wenn ein Abschnitt vorübergehend nicht verfügbar ist.
Die Berichtsstruktur
Ein einzelnes GET /api/soc2-evidence?accountId=X gibt den vollständigen Bericht zurück. Er enthält neun Abschnitte, organisiert um die Evidenzkategorien, die SOC 2-Auditoren interessieren:
| Abschnitt | Was er enthält | Quelle |
|---|---|---|
| Zugriffsreview | Pro-Benutzer-Rollen, Berechtigungen, Abteilungszuweisungen, Ressourcenzugriffszähler, letzte Aktivität | Governance-Modul + Berechtigungs-Engine |
| Sicherheitsmetriken | Fehlgeschlagene Auth-Versuche, blockierte IPs, API-Schlüssel-Gesundheit, Nutzungsspitzen-Warnungen | Sicherheitsanalysen |
| Verschlüsselungsinventar | 10 Verschlüsselungskontrollen mit Algorithmen, Schlüsselgrößen, Scope und Verwaltungsdetails | Statischer Katalog |
| Anbieterregister | 11 Drittanbieter mit Risikostufen, Zertifizierungen und Datenzugriffsklassifikationen | Statischer Katalog |
| Incident Response | 6 Verfahren über 4 Phasen mit Schweregraddefinitionen, SLAs und Schritt-für-Schritt-Runbooks | Statischer Katalog |
| Compliance-Konfiguration | Aktive Compliance-Frameworks, Datenspeicherortregeln, PII-Erkennungseinstellungen | Kontokonfiguration |
| Datenspeicherort | Pro-Kategorie-Speicherortmodi (nur lokal, Cloud-Sync, Cloud-geschwärzt) | Kontokonfiguration |
| Aufbewahrungsrichtlinie | Audit-Log-Aufbewahrungszeitraum und Konfiguration | Kontokonfiguration |
| Audit-Log-Zusammenfassung | 30-Tage-Event-Zähler, Aktionsaufschlüsselung, Top-10-Akteure nach Aktivität | Firestore audit_logs |
Der Bericht ist versioniert (1.0.0) und mit Zeitstempel versehen. Jeder Abschnitt enthält seinen eigenen generatedAt-Zeitstempel, damit Auditoren genau sehen können, wann jedes Evidenzstück gesammelt wurde.
Zugriffsreview
Der Zugriffsreview-Abschnitt ist derjenige, für den Auditoren am meisten Zeit aufwenden. JieGou generiert ihn automatisch aus Live-Plattformdaten.
Für jeden Benutzer in Ihrem Konto:
- Identität — E-Mail, Anzeigename, Benutzer-ID
- Rolle — Globale Rolle (Owner, Admin, Dept Lead, Member, Auditor, Viewer) mit numerischer Stufe
- Abteilungen — Zu welchen Abteilungen der Benutzer gehört
- Berechtigungen — Die vollständige Liste granularer Berechtigungen, die seine Rolle gewährt (26 Berechtigungen über 8 Kategorien)
- Ressourcenzugriff — Anzahl der für diesen Benutzer zugänglichen Recipes und Workflows
- Zuletzt aktiv — Zeitstempel der letzten Aktivität des Benutzers
Der Bericht enthält auch Rollenverteilung — wie viele Benutzer auf jeder Rollenstufe — damit Auditoren verifizieren können, dass die Privilegienzuweisung dem Prinzip der geringsten Privilegien folgt.
API-Schlüssel-Zusammenfassung rundet den Zugriffsreview ab: Gesamtschlüssel, welche LLM-Anbieter konfiguriert sind und Pro-Schlüssel-Details (Anbieter, Gültigkeitsstatus, Alter). Auditoren können verifizieren, dass keine veralteten oder verwaisten Schlüssel existieren, ohne eine separate Schlüsselverwaltungskonsole durchsuchen zu müssen.
Verschlüsselungsinventar
SOC 2 Trust Services Criteria CC6.1 erfordert, dass Organisationen ihre Verschlüsselungskontrollen dokumentieren. JieGous Verschlüsselungsinventar katalogisiert 10 Kontrollen für Daten im Ruhezustand und bei der Übertragung:
| Kontrolle | Algorithmus | Scope |
|---|---|---|
| BYOK-Schlüsselverschlüsselung | AES-256-GCM | Kunden-API-Schlüssel in Firestore |
| Firestore-Daten im Ruhezustand | AES-256 | Alle Firestore-Collections |
| Session-Cookie-Signierung | RS256 (JWT) | Firebase Auth Session-Cookies |
| Passwortspeicherung | bcrypt / scrypt | Benutzer-Passwort-Hashes |
| TLS — Istio Gateway | TLS 1.3 | Gesamter HTTPS-Traffic zu *.jiegou.ai |
| TLS — Firebase Services | TLS 1.3 | Firestore & Auth API-Traffic |
| TLS — Redis Cluster | TLS 1.2+ | Redis-Cache-Verbindungen |
| Dokumentfrische-Hash | SHA-256 | URL-Dokument-Änderungserkennung |
| Session-Cache-Schlüssel-Hash | SHA-256 | Redis-Session-Cache-Schlüssel |
| Container-Image-Verifizierung | SHA-256 | Docker-Image-Digests in ECR |
Jede Kontrolle enthält die Schlüsselgröße, wer sie verwaltet (JieGou, Google Cloud, AWS, Firebase), das Quellmodul in der Codebasis und ob sie Daten im Ruhezustand, bei der Übertragung oder beides abdeckt. Das ist kein Marketing-Claim — es ist ein maschinenlesbares Inventar, das direkt auf Ihre Infrastruktur abbildet.
Anbieterregister
Drittanbieter-Management ist eine SOC 2-Anforderung. JieGous Anbieterregister katalogisiert 11 Anbieter mit strukturierten Risikobewertungen:
Für jeden Anbieter:
- Risikostufe — kritisch, hoch, mittel oder niedrig
- SOC 2-Zertifizierungsstatus — ob der Anbieter SOC 2 Type II besitzt
- Andere Zertifizierungen — ISO 27001, FedRAMP, PCI DSS, HIPAA und andere
- Datenzugriff — auf welche Daten der Anbieter zugreifen und sie verarbeiten kann
- Mitigationen — spezifische Kontrollen, die das Risiko für diesen Anbieter reduzieren
- Review-Zeitplan — letztes Review-Datum und nächstes Review-Datum
Anbieter reichen von kritisch (GCP, AWS, Firebase Auth — sie hosten Ihre Daten) bis mittel (Resend für E-Mail, Redis für Caching). LLM-Anbieter (Anthropic, OpenAI, Google AI) werden als hoch klassifiziert — sie verarbeiten Kunden-Prompts vorübergehend, aber BYOK-Support und No-Training-Richtlinien mitigieren das Risiko.
Das Register enthält anbieterspezifische Mitigationen, keine generischen Aussagen. Für Stripe: “PCI DSS Level 1-zertifiziert — Kartendaten berühren nie JieGou-Server.” Für Redis: “Cache-Only-Modus (Persistenz deaktiviert) — keine PVs.” Das sind die Details, nach denen Auditoren suchen.
Incident-Response-Runbook
SOC 2 CC7.3 und CC7.4 erfordern dokumentierte Incident-Response-Verfahren. Das Runbook enthält 6 Verfahren über 4 Phasen:
Phase 1: Erkennung & Triage (alle Schweregrade) — Warnung bestätigen, Schweregrad P1-P4 klassifizieren, Incident-Kanal erstellen, initiale Evidenz sichern.
Phase 2: Eindämmung — Drei schweregradspezifische Verfahren:
- Datenverletzung (P1) — Betroffene Konten identifizieren, kompromittierte Benutzer deaktivieren, API-Schlüssel rotieren, Session-Caches leeren, Audit-Logs sichern, Kunden innerhalb von 72 Stunden gemäß DSGVO benachrichtigen
- Unautorisierter Zugriff (P1) — Sessions widerrufen, Konten deaktivieren, IP-Blocking prüfen, Zugriffsreview durchführen, laterale Bewegung untersuchen
- Service-Ausfall (P2) — Circuit Breaker prüfen, auf alternative LLM-Anbieter failovern, Redis Fail-Open verifizieren, Kunden-Statusupdates posten
Phase 3: Beseitigung & Wiederherstellung (P1-P3) — Ursachenanalyse, Fix-Deployment, Produktionsverifizierung, Service-Wiederherstellung.
Phase 4: Post-Mortem (P1-P2) — Blameless Review innerhalb von 48 Stunden, Incident-Timeline-Zusammenstellung, Korrekturmaßnahmen-Tracking.
Jeder Verfahrensschritt enthält die verantwortliche Partei (On-Call-Engineer, Security Lead, Infrastructure Engineer), SLA in Minuten, spezifische Tools (keine generischen Kategorien — tatsächliche Modulnamen und Befehle) und Eskalationsauslöser für den Fall, dass sich die Situation verschlechtert.
Schweregraddefinitionen haben explizite Reaktionszeit-SLAs: P1 Kritisch bei 15 Minuten, P2 Hoch bei 1 Stunde, P3 Mittel bei 4 Stunden, P4 Niedrig bei 24 Stunden.
Audit-Log-Zusammenfassung
Die Audit-Log-Zusammenfassung aggregiert die letzten 30 Tage Aktivität in zwei Ansichten:
Aktionsaufschlüsselung — Zähler pro Aktionstyp. Wie viele Recipe-Ausführungen, Workflow-Runs, Rollenänderungen, API-Schlüssel-Operationen, Konfigurationsupdates und andere auditierbare Events im Zeitraum stattfanden. Das sagt Auditoren, was auf der Plattform passiert und ob die Aktivitätsmuster normal aussehen.
Top-Akteure — Die 10 aktivsten Benutzer nach Event-Anzahl. Auditoren verwenden dies, um zu verifizieren, dass Hochaktivitätskonten erwarteten Benutzern entsprechen (Automatisierungs-Service-Konten, Power-User) statt anomalem Verhalten.
Die Zusammenfassung ist auf 1.000 Events für Performance begrenzt. Für Konten mit höheren Volumina ist das rohe Audit-Log immer über das Governance-Modul verfügbar.
Wie es gebaut ist
Der Evidenzbericht wird generiert, indem alle neun Abschnitte gleichzeitig mit Promise.all parallel abgerufen werden. Sechs Abschnitte kommen aus Live-Abfragen (Zugriffsreview, Sicherheitsmetriken, Compliance-Konfiguration, Datenspeicherort, Aufbewahrungsrichtlinie, Audit-Log-Zusammenfassung). Drei sind statische Kataloge (Verschlüsselungsinventar, Anbieterregister, Incident-Response-Runbook).
Fail-Open-Design. Jeder dynamische Abschnitt ist in einem .catch()-Handler verpackt. Wenn der Sicherheitsmetriken-Service vorübergehend nicht verfügbar ist, wird der Bericht trotzdem mit den anderen acht Abschnitten gefüllt und der fehlgeschlagene Abschnitt mit sicheren Standardwerten gefüllt. Der Bericht wird immer zurückgegeben — er scheitert nie vollständig, weil ein Subsystem langsam ist.
Redis-Caching. Der vollständige Bericht wird 5 Minuten gecacht. Während eines Audits können mehrere Teammitglieder denselben Bericht wiederholt abrufen. Caching verhindert redundante Firestore-Abfragen und hält die Antwortzeiten konsistent.
Abschnitt-Level-Zugriff. Sie brauchen nicht immer den vollständigen Bericht. Fügen Sie ?section=access-review an, um nur den Zugriffsreview zu erhalten, oder ?section=encryption-inventory für nur den Verschlüsselungskatalog. Sechs Abschnitte sind einzeln adressierbar: access-review, security-metrics, encryption-inventory, vendor-register, incident-response, audit-log-summary.
Berechtigungsmodell
Der Endpunkt erfordert die audit:read-Berechtigung, die auf die Auditor-Rolle (Stufe 15) oder höher abbildet. Das bedeutet:
- Auditor, Dept Lead, Admin, Owner — können den Bericht abrufen
- Member, Viewer — können nicht darauf zugreifen
Das entspricht dem Prinzip der geringsten Privilegien. Ihr Compliance-Team kann Evidenz generieren, ohne Admin-Zugriff zu brauchen. Ihre Engineering-Teammitglieder, die Workflows ausführen und Recipes bearbeiten können, bekommen keine Sichtbarkeit in den Sicherheitslagebericht, es sei denn, ihre Rolle rechtfertigt es.
Verfügbarkeit
SOC 2-Evidenzsammlung ist in Enterprise-Plänen verfügbar. Enthält die vollständige Evidenzbericht-API, individuellen Abschnittszugriff, Zugriffsreviews, Verschlüsselungsinventar, Anbieterregister, Incident-Response-Runbook und Audit-Log-Zusammenfassungen. Erfahren Sie mehr über Enterprise-Features oder starten Sie eine Testversion.