Les audits SOC 2 ne sont pas difficiles parce que les contrôles sont compliqués. Ils sont difficiles parce que les preuves sont dispersées. Les revues d’accès vivent dans votre fournisseur d’identité. Les détails de chiffrement sont enfouis dans les configurations d’infrastructure. Les évaluations de risques fournisseurs sont dans des tableurs. Les procédures de réponse aux incidents existent dans un wiki qui n’a pas été mis à jour depuis le dernier audit. Les journaux d’audit sont dans une base de données, mais personne ne les a agrégés dans le format que votre auditeur souhaite.
Chaque trimestre, quelqu’un passe des jours à extraire des données de six systèmes différents, à les formater en rapport, en espérant que rien n’a changé depuis la dernière vérification.
L’agrégateur de preuves SOC 2 de JieGou élimine ce travail. Un appel API retourne un rapport structuré couvrant six sections de preuves — récupérées en parallèle depuis les données en direct de la plateforme, mises en cache pour la performance, et conçues pour échouer gracieusement si une section est temporairement indisponible.
La structure du rapport
Un seul GET /api/soc2-evidence?accountId=X retourne le rapport complet. Il contient neuf sections organisées autour des catégories de preuves qui importent aux auditeurs SOC 2 :
| Section | Ce qu’elle contient | Source |
|---|---|---|
| Revue d’accès | Rôles par utilisateur, permissions, affectations départementales, comptages d’accès aux ressources, dernière activité | Module de gouvernance + moteur de permissions |
| Métriques de sécurité | Tentatives d’authentification échouées, IP bloquées, santé des clés API, alertes de pics d’utilisation | Analytique de sécurité |
| Inventaire de chiffrement | 10 contrôles de chiffrement avec algorithmes, tailles de clés, portée et détails de gestion | Catalogue statique |
| Registre des fournisseurs | 11 fournisseurs tiers avec niveaux de risque, certifications et classifications d’accès aux données | Catalogue statique |
| Réponse aux incidents | 6 procédures à travers 4 phases avec définitions de sévérité, SLA et runbooks étape par étape | Catalogue statique |
| Configuration de conformité | Cadres de conformité actifs, règles de résidence des données, paramètres de détection PII | Configuration du compte |
| Résidence des données | Modes de résidence par catégorie (local uniquement, synchronisation cloud, cloud expurgé) | Configuration du compte |
| Politique de rétention | Période de rétention des journaux d’audit et configuration | Configuration du compte |
| Résumé des journaux d’audit | Comptage d’événements sur 30 jours, ventilation par action, top 10 des acteurs par activité | Firestore audit_logs |
Le rapport est versionné (1.0.0) et horodaté. Chaque section inclut son propre horodatage generatedAt pour que les auditeurs puissent voir exactement quand chaque preuve a été collectée.
Revue d’accès
La section de revue d’accès est celle sur laquelle les auditeurs passent le plus de temps. JieGou la génère automatiquement à partir des données en direct de la plateforme.
Pour chaque utilisateur de votre compte :
- Identité — email, nom d’affichage, identifiant utilisateur
- Rôle — rôle global (Owner, Admin, Dept Lead, Member, Auditor, Viewer) avec niveau numérique
- Départements — à quels départements l’utilisateur appartient
- Permissions — la liste complète des permissions granulaires accordées par son rôle (26 permissions dans 8 catégories)
- Accès aux ressources — nombre de recettes et workflows accessibles à cet utilisateur
- Dernière activité — horodatage de l’activité la plus récente de l’utilisateur
Le rapport inclut également la distribution des rôles — combien d’utilisateurs à chaque niveau de rôle — pour que les auditeurs puissent vérifier que l’allocation des privilèges suit le principe du moindre privilège.
Le résumé des clés API complète la revue d’accès : total de clés, quels fournisseurs LLM sont configurés, et détails par clé (fournisseur, statut de validité, âge). Les auditeurs peuvent vérifier qu’aucune clé obsolète ou orpheline n’existe sans fouiller dans une console de gestion de clés séparée.
Inventaire de chiffrement
Le critère SOC 2 Trust Services CC6.1 exige que les organisations documentent leurs contrôles de chiffrement. L’inventaire de chiffrement de JieGou catalogue 10 contrôles couvrant les données au repos et en transit :
| Contrôle | Algorithme | Portée |
|---|---|---|
| Chiffrement de clés BYOK | AES-256-GCM | Clés API clients stockées dans Firestore |
| Données Firestore au repos | AES-256 | Toutes les collections Firestore |
| Signature de cookies de session | RS256 (JWT) | Cookies de session Firebase Auth |
| Stockage de mots de passe | bcrypt / scrypt | Hashes de mots de passe utilisateur |
| TLS — Istio Gateway | TLS 1.3 | Tout le trafic HTTPS vers *.jiegou.ai |
| TLS — Services Firebase | TLS 1.3 | Trafic API Firestore & Auth |
| TLS — Cluster Redis | TLS 1.2+ | Connexions au cache Redis |
| Hash de fraîcheur de document | SHA-256 | Détection de changement de documents URL |
| Hash de clé de cache de session | SHA-256 | Clés de cache de session Redis |
| Vérification d’image de conteneur | SHA-256 | Digests d’images Docker dans ECR |
Chaque contrôle inclut la taille de la clé, qui le gère (JieGou, Google Cloud, AWS, Firebase), le module source dans le codebase, et s’il couvre les données au repos, en transit, ou les deux. Ce n’est pas une affirmation marketing — c’est un inventaire lisible par machine qui correspond directement à votre infrastructure.
Registre des fournisseurs
La gestion des fournisseurs tiers est une exigence SOC 2. Le registre des fournisseurs de JieGou catalogue 11 fournisseurs avec des évaluations de risques structurées :
Pour chaque fournisseur :
- Niveau de risque — critique, élevé, moyen ou faible
- Statut de certification SOC 2 — si le fournisseur détient un SOC 2 Type II
- Autres certifications — ISO 27001, FedRAMP, PCI DSS, HIPAA et autres
- Accès aux données — quelles données le fournisseur peut accéder et traiter
- Atténuations — contrôles spécifiques qui réduisent le risque pour ce fournisseur
- Calendrier de revue — date de dernière revue et date de prochaine revue
Les fournisseurs vont de critique (GCP, AWS, Firebase Auth — ils hébergent vos données) à moyen (Resend pour l’email, Redis pour le cache). Les fournisseurs LLM (Anthropic, OpenAI, Google AI) sont classés comme élevé — ils traitent les prompts clients de manière transitoire, mais le support BYOK et les politiques de non-entraînement atténuent le risque.
Le registre inclut des atténuations spécifiques au fournisseur, pas des déclarations génériques. Pour Stripe : « Certifié PCI DSS Niveau 1 — les données de carte ne touchent jamais les serveurs JieGou. » Pour Redis : « Mode cache uniquement (persistance désactivée) — pas de PV. » Ce sont les détails que les auditeurs recherchent.
Runbook de réponse aux incidents
Les critères SOC 2 CC7.3 et CC7.4 exigent des procédures de réponse aux incidents documentées. Le runbook inclut 6 procédures à travers 4 phases :
Phase 1 : Détection et triage (toutes sévérités) — Confirmer l’alerte, classifier la sévérité P1-P4, créer un canal d’incident, préserver les preuves initiales.
Phase 2 : Confinement — Trois procédures spécifiques par sévérité :
- Violation de données (P1) — Identifier les comptes affectés, désactiver les utilisateurs compromis, faire la rotation des clés API, vider les caches de session, préserver les journaux d’audit, notifier les clients dans les 72 heures conformément au RGPD
- Accès non autorisé (P1) — Révoquer les sessions, désactiver les comptes, vérifier le blocage IP, exécuter une revue d’accès, enquêter sur les mouvements latéraux
- Panne de service (P2) — Vérifier les circuit breakers, basculer vers des fournisseurs LLM alternatifs, vérifier le fail-open Redis, publier des mises à jour de statut client
Phase 3 : Éradication et récupération (P1-P3) — Analyse de cause racine, déploiement du correctif, vérification en production, restauration du service.
Phase 4 : Post-mortem (P1-P2) — Revue sans blâme dans les 48 heures, compilation de la chronologie de l’incident, suivi des actions correctives.
Chaque étape de procédure inclut le responsable (ingénieur d’astreinte, responsable sécurité, ingénieur infrastructure), le SLA en minutes, les outils spécifiques à utiliser (pas des catégories génériques — des noms de modules et commandes réels), et les déclencheurs d’escalade pour quand la situation s’aggrave.
Les définitions de sévérité ont des SLA de temps de réponse explicites : P1 Critique à 15 minutes, P2 Élevé à 1 heure, P3 Moyen à 4 heures, P4 Faible à 24 heures.
Résumé des journaux d’audit
Le résumé des journaux d’audit agrège les 30 derniers jours d’activité en deux vues :
Ventilation par action — comptages par type d’action. Combien d’exécutions de recettes, d’exécutions de workflows, de changements de rôles, d’opérations sur clés API, de mises à jour de configuration et d’autres événements auditables se sont produits pendant la période. Cela indique aux auditeurs ce qui se passe sur la plateforme et si les patterns d’activité semblent normaux.
Top des acteurs — les 10 utilisateurs les plus actifs par nombre d’événements. Les auditeurs l’utilisent pour vérifier que les comptes à forte activité correspondent aux utilisateurs attendus (comptes de service d’automatisation, power users) plutôt qu’à un comportement anormal.
Le résumé est plafonné à 1 000 événements pour la performance. Pour les comptes avec des volumes plus élevés, le journal d’audit brut est toujours disponible via le module de gouvernance.
Comment c’est construit
Le rapport de preuves est généré en récupérant en parallèle les neuf sections simultanément avec Promise.all. Six sections proviennent de requêtes en direct (revue d’accès, métriques de sécurité, configuration de conformité, résidence des données, politique de rétention, résumé des journaux d’audit). Trois sont des catalogues statiques (inventaire de chiffrement, registre des fournisseurs, runbook de réponse aux incidents).
Conception fail-open. Chaque section dynamique est enveloppée dans un handler .catch(). Si le service de métriques de sécurité est temporairement indisponible, le rapport retourne quand même avec les huit autres sections remplies et la section en échec avec des valeurs par défaut sûres. Le rapport retourne toujours — il n’échoue jamais entièrement parce qu’un sous-système est lent.
Mise en cache Redis. Le rapport complet est mis en cache pour 5 minutes. Pendant un audit, plusieurs membres de l’équipe peuvent extraire le même rapport à répétition. La mise en cache évite les requêtes Firestore redondantes et maintient des temps de réponse cohérents.
Accès par section. Vous n’avez pas toujours besoin du rapport complet. Ajoutez ?section=access-review pour obtenir uniquement la revue d’accès, ou ?section=encryption-inventory pour uniquement le catalogue de chiffrement. Six sections sont individuellement adressables : access-review, security-metrics, encryption-inventory, vendor-register, incident-response, audit-log-summary.
Modèle de permissions
L’endpoint requiert la permission audit:read, qui correspond au rôle Auditor (niveau 15) ou supérieur. Cela signifie :
- Auditor, Dept Lead, Admin, Owner — peuvent extraire le rapport
- Member, Viewer — ne peuvent pas y accéder
Cela s’aligne avec le principe du moindre privilège. Votre équipe de conformité peut générer des preuves sans avoir besoin d’un accès administrateur. Les membres de votre équipe d’ingénierie, qui peuvent exécuter des workflows et modifier des recettes, n’ont pas de visibilité sur le rapport de posture de sécurité à moins que leur rôle ne le justifie.
Disponibilité
La collecte de preuves SOC 2 est disponible sur les plans Enterprise. Inclut l’API de rapport de preuves complet, l’accès par section individuelle, les revues d’accès, l’inventaire de chiffrement, le registre des fournisseurs, le runbook de réponse aux incidents et les résumés de journaux d’audit. En savoir plus sur les fonctionnalités enterprise ou démarrer un essai.