Commencer
Intégrer / SDK
Vérification des utilisateurs
Vérification d'entreprise
Surveillance des transactions
Journal des modifications
Pourquoi des journaux d’audit ?
Accéder aux journaux d’audit
Ouvrez Paramètres > Organisation > Journal d’audit dans la console Didit. L’interface affiche une liste chronologique de toutes les requêtes API effectuées au sein de votre organisation. Chaque entrée du journal comprend :Décisions prises par The Investigator
Chaque décision que The Investigator prend de son propre chef est enregistrée sous The Investigator, et non sous un membre ou une clé API : approbation ou refus d’une session ou demande de nouvelle soumission, définition du statut d’une transaction, et résolution d’un dossier, escalade ou demande d’informations sur celui-ci. L’entrée renvoie au rapport de The Investigator à l’origine de la décision. Lorsqu’une personne accepte ou passe outre à une recommandation de The Investigator, l’entrée est enregistrée sous le nom de cette personne.Filtrage et recherche
L’interface des journaux d’audit propose des fonctions de filtrage puissantes pour vous aider à trouver exactement ce que vous cherchez.Recherche intelligente
La barre de recherche détecte automatiquement ce que vous recherchez :Filtres disponibles
Conservation des données
Votre forfait détermine la période pendant laquelle vous pouvez consulter le journal d’audit et si vous pouvez l’exporter :
Un export sur un forfait qui ne le prévoit pas renvoie
403 avec "code": "plan_limit_exceeded".
Sécurité et confidentialité
Ce qui est journalisé
Les journaux d’audit capturent les métadonnées des requêtes API :- Horodatage et durée de la requête
- Identité de l’utilisateur (e-mail, identifiant utilisateur), ou la clé API ayant effectué la requête (son nom et les premiers caractères de son secret, jamais le secret complet)
- Chemin de la requête et paramètres de requête
- Codes de statut des réponses
- Adresse du client et agent utilisateur
Corps des requêtes et des réponses des appels effectués avec une clé API
Pour un appel effectué avec une clé API, le journal d’audit conserve également une copie caviardée du corps JSON de la requête d’écriture, ainsi que de la réponse à une écriture ou à une erreur, afin que vous puissiez comprendre pourquoi un appel a échoué. La réponse à une lecture réussie n’est pas conservée. Le caviardage fonctionne par refus par défaut :- La structure est conservée : noms des champs, imbrication, types de valeurs, longueurs des tableaux et longueurs des chaînes.
- Une valeur n’est conservée que si elle est l’un des identifiants, statuts, codes, compteurs ou horodatages propres à Didit, placée dans un champ défini par Didit, et sous la forme attendue par ce champ.
- Un booléen n’est conservé que dans un champ défini par Didit.
- Toute autre valeur est remplacée par un marqueur indiquant son type et sa longueur, par exemple
[redacted:string:12],[redacted:number:5]ou[redacted:boolean], etnullrestenull. - Un nom de champ qui n’est pas un identifiant simple, comme une adresse e-mail ou un numéro de téléphone utilisé comme clé, est remplacé par
[redacted:key:23]. - Un corps qui n’est pas du JSON, comme un formulaire ou un fichier envoyé, est remplacé par une note indiquant de quoi il s’agissait.
- Le contenu restant est tronqué à 4 096 caractères.
content-type, user-agent et les en-têtes de limite de débit, sont conservés ; tout autre en-tête est supprimé avec sa valeur.
Une valeur envoyée par votre propre système, par exemple dans metadata ou vendor_data, n’est jamais conservée, même lorsque son champ porte un nom similaire à l’un de ceux définis par Didit.
Ce qui n’est PAS journalisé
Pour protéger les données sensibles, les éléments suivants sont automatiquement exclus :- Jetons d’authentification et identifiants
- Mots de passe et secrets
- Données personnelles issues des sessions de vérification
Contrôle d’accès
Consulter le journal d’audit nécessite les autorisations de lecture et de listeaudit-logs. Les rôles Reader, Compliance Officer, Developer, Admin et Owner les possèdent tous, et un rôle personnalisé les obtient en sélectionnant Journaux d’audit dans l’éditeur de rôles.
Cas d’usage courants
Audit de conformité
Audit de conformité
Montrez aux auditeurs que vous avez une visibilité complète sur les personnes ayant accédé aux données de vérification :
- Filtrez par plage de dates correspondant à la période d’audit
- Filtrez par des applications ou des utilisateurs spécifiques, si nécessaire
- Exportez les résultats ou faites-en une capture d’écran pour la documentation
Enquête de sécurité
Enquête de sécurité
Si vous soupçonnez un accès non autorisé :
- Recherchez l’adresse e-mail de l’utilisateur concerné ou les adresses IP suspectes
- Filtrez par plage de dates autour de l’incident présumé
- Recherchez les schémas inhabituels : tentatives d’authentification échouées, endpoints inattendus, horaires inhabituels
Débogage d'intégration
Débogage d'intégration
Lorsque vous résolvez des problèmes d’intégration de l’API :
- Recherchez le chemin de l’endpoint concerné
- Filtrez par codes de statut
4xxou5xxpour trouver les erreurs - Relevez les horodatages pour les corréler avec les journaux de votre application
Revue de l'activité de l'équipe
Revue de l'activité de l'équipe
Suivez la manière dont votre équipe utilise la plateforme :
- Filtrez par les adresses e-mail spécifiques des membres de l’équipe
- Examinez les sessions et les fonctionnalités auxquelles ils ont accédé
- Vérifiez que les membres de l’équipe respectent les procédures en vigueur
Bonnes pratiques
- Revues régulières : examinez périodiquement les journaux d’audit pour détecter rapidement les anomalies.
- Affiner votre recherche : utilisez des filtres précis pour réduire le bruit et trouver plus vite les entrées pertinentes.
- Plages de dates : indiquez toujours une plage de dates pour améliorer les performances sur les grands volumes de données.
- Ajouter les recherches aux favoris : enregistrez les combinaisons de filtres courantes comme marque-pages de votre navigateur pour y accéder rapidement.