Transfert vers un SIEM

Le journal d'audit Scrydon peut être transféré vers votre SIEM en quasi temps réel. Cette page présente les destinations prises en charge et le modèle de configuration.

Destinations prises en charge

Les destinations personnalisées sont prises en charge via l'adaptateur webhook de la plateforme — pointez Scrydon vers l'URL d'ingestion de votre collecteur avec l'authentification appropriée.

Configuration

Sous Paramètres → Plateforme → Journaux d'audit → Transfert, configurez une ou plusieurs destinations :

• Type de destination — choisissez parmi la liste ci-dessus.
• URL du point de terminaison — l'URL d'ingestion de votre collecteur.
• Authentification — token bearer, authentification basique, mTLS ou requête signée, selon la destination.
• Filtre d'événements — optionnel. Transférez tous les événements, ou filtrez par espace de noms d'action.

Plusieurs destinations peuvent être actives simultanément (ex. transférer tous les événements vers votre data lake + les événements critiques vers votre SIEM).

Ce qui est transféré

Chaque événement du journal d'audit est éligible au transfert. Le service de transfert respecte le même filtrage et la même rétention que le journal d'audit lui-même — les événements filtrés hors du journal d'audit local ne sont pas transférés.

Le format filaire est du JSON structuré :

{
  "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"
}

C'est la même structure que celle visible dans l'interface du journal d'audit, de sorte que les mêmes tableaux de bord fonctionnent partout.

Garanties de livraison

• Livraison au moins une fois. Les événements peuvent apparaître plus d'une fois dans votre SIEM après des nouvelles tentatives. Utilisez le champ id pour la déduplication.
• Ordonné par événement. Le service de transfert ne réordonne pas les événements ; les collecteurs en aval peuvent le faire selon leur pipeline d'ingestion.
• Mis en mémoire tampon. Les brèves indisponibilités du SIEM ne perdent pas les événements — le service de transfert les met en mémoire tampon localement et les rejoue une fois la destination rétablie.

Contre-pression

Si votre SIEM rejette des événements pendant une période prolongée (authentification expirée, ingestion désactivée), la mémoire tampon locale se remplit. Lorsqu'elle est pleine, le service de transfert exerce une contre-pression sur le journal d'audit lui-même — c'est une propriété de sécurité : les événements d'audit ne doivent jamais être silencieusement perdus simplement parce que le transfert est défaillant.

Symptômes de contre-pression :

• La métrique audit_log.forwarding_buffer_full dépasse le seuil.
• Les écritures dans le journal d'audit ralentissent.
• Un événement AUDIT_FORWARDING_DEGRADED apparaît dans le journal local.

Correction : rétablissez la destination SIEM ou désactivez temporairement le transfert pendant l'investigation.

Liens connexes

• Journal d'audit — la source des événements transférés.
• Observabilité — pour les métriques + traces (distinct de l'audit).
• Conformité — cadres imposant le transfert vers un SIEM (ISO 27001 A.8.16, SOC 2 CC7).