Journalisation des audits

Ce que Scrydon enregistre, comment c'est stocké, qui peut le consulter et combien de temps cela est conservé.

Chaque opération sensible dans Scrydon produit un événement d'audit immuable. Le journal d'audit est la source de référence pour la conformité, la réponse aux incidents et l'analyse forensique.

Ce qui est journalisé

Le journal d'audit capture chaque opération qui modifie ou lit un état sensible. L'espace de noms des actions est structuré :

SECRET_*         Coffre à secrets — création, mise à jour, suppression, accès
PROVIDER_*       Fournisseur d'intégration — création, mise à jour, suppression, test
RESOURCE_*       Ressources génériques — création, mise à jour, suppression, accès
AUTH_*           Événements d'authentification — connexion, déconnexion, tentatives échouées
EXECUTION_GRANT_*  Autorisations d'exécution de workflow — création, liaison, expiration, révocation
SCIM_*           Provisionnement SCIM — création, mise à jour, désactivation d'utilisateur / groupe
INTEGRATION_*    Cycle de vie des intégrations — installation, désinstallation, activation, désactivation
SECRET_STRATEGY_*  Changements de stratégie de clé (LOCAL → BYOK → HYOK)
LICENSE_*        Événements d'application et de renouvellement de licence

Chaque événement contient :

Champ	Rôle
`id`	Identifiant stable de l'événement
`action`	Le jeton d'espace de noms d'action (p. ex. `SECRET_ACCESS`)
`resourceType`	Le type de ressource affectée (`secret`, `workflow`, `kb_document`, …)
`resourceId`	L'identifiant de la ressource spécifique
`actorId`	L'utilisateur ou le service qui a effectué l'action
`organizationId`	Le périmètre de l'organisation
`metadata`	Un payload structuré avec le contexte spécifique à l'action (toujours expurgé des valeurs)
`ipAddress`	IP de l'appelant — configurable, capturée par défaut
`userAgent`	User-agent de l'appelant — configurable, capturé par défaut
`createdAt`	Horodatage ISO 8601

Exemple : événement d'accès à un secret

{
  "id": "aud_abc123",
  "action": "SECRET_ACCESS",
  "resourceType": "secret",
  "resourceId": "sec_xyz789",
  "actorId": "usr_456",
  "organizationId": "org_001",
  "metadata": {
    "secretName": "OPENAI_API_KEY",
    "strategy": "LOCAL"
  },
  "ipAddress": "10.0.1.42",
  "userAgent": "Mozilla/5.0...",
  "createdAt": "2026-03-16T10:30:00Z"
}

Le bloc metadata contient le nom et la stratégie du secret mais jamais la valeur. La même règle s'applique à tous les types d'actions.

Qui peut lire le journal d'audit

Rôle	Peut consulter
Propriétaire de l'organisation	Journal d'audit complet de l'organisation
Administrateur de l'organisation	Journal d'audit complet de l'organisation
Propriétaire / administrateur de l'espace de travail	Événements scopés à l'espace de travail uniquement
Membre de l'espace de travail	Ses propres événements uniquement

L'interface du journal d'audit se trouve dans Paramètres → Plateforme → Journaux d'audit. Filtrez par resourceType, action, actorId ou plage de dates ; exportez en CSV / JSON.

Le journal d'audit peut être transféré vers votre SIEM (Splunk, Sumo Logic, Datadog, Elastic, Microsoft Sentinel) via l'intégration du forwarder SIEM. Une fois configuré, chaque événement d'audit est également publié vers le point de terminaison d'ingestion de votre SIEM en quelques secondes. Voir Déploiement → Opérations → Transfert SIEM.

Rétention

Paramètre	Valeur par défaut
Période de rétention	365 jours
Stockage immuable	Oui — les événements sont en ajout uniquement
Détection de falsification	Chaîne de hachage par événement

Certains cadres de conformité exigent une rétention plus longue (SOC 2 accepte généralement 365 jours ; certains régulateurs des services financiers exigent 7 ans). La rétention est configurable par organisation sous Paramètres → Plateforme → Journaux d'audit → Rétention.

L'augmentation de la rétention est possible à tout moment. La réduction de la rétention nécessite l'approbation du propriétaire de l'organisation et ne prend effet que pour les nouveaux événements — les événements existants ne sont pas supprimés rétroactivement.

Ce qui ne figure jamais dans le journal

Le journal d'audit capture qu' une action s'est produite et qui l'a effectuée, pas les données sur lesquelles l'action a porté. Plus précisément :

Les valeurs des secrets ne sont jamais journalisées. Les noms, IDs et stratégies des secrets le sont.
Le contenu des documents de la base de connaissances n'est jamais journalisé. Les IDs de documents, classifications et événements d'accès le sont.
Les payloads d'entrée et de sortie des workflows ne sont jamais journalisés. Les IDs de workflows, durées et résultats le sont.
Le contenu des prompts LLM n'est jamais journalisé. Les comptages de tokens, IDs de modèles, coûts et la source d'intégration le sont.

Cette séparation permet d'exposer le journal d'audit aux auditeurs de conformité sans exposer également les données sous-jacentes.

Voir aussi

Modèle de permissions — qui peut consulter les événements d'audit.
Gestion des secrets — ce que signifie chaque événement SECRET_*.
Conformité — exigences de rétention et d'événements spécifiques aux frameworks.