Audit logs
Statut
Document de cadrage sécurité — version initiale.
Objectif
Les audit logs doivent permettre de comprendre qui a fait quoi, quand, sur quelle ressource et dans quel contexte.
Ils servent à la sécurité, au support, à la modération, à l'administration et à la conformité, sans devenir une collecte excessive de données.
État actuel visible
Le repo montre déjà des logs techniques dans certains traitements :
- webhooks Stripe ;
- erreurs Stripe ;
- jobs ;
- configuration Nginx avec logs d'accès et d'erreur ;
- logs applicatifs Laravel possibles via la configuration standard.
Cela ne suffit pas à confirmer un système complet d'audit logs métier. La cible doit le formaliser.
Actions à auditer
| Domaine | Actions à journaliser |
|---|---|
| Administration | changement de rôle, accès admin, modification de configuration. |
| Acteurs | revendication, validation, rattachement, changement propriétaire. |
| Publications | création sensible, modification, suppression, modération, signalement. |
| Mairie | alertes, services, contenus officiels, délégations. |
| Abonnements | changement de plan, boost, événement Stripe, synchronisation. |
| IA | usage, coût, provider, type de tâche, refus, modération assistée. |
| Sécurité | échecs répétés, refus d'accès, révocation de token, rotation secret. |
| Support | consultation ou modification manuelle d'un dossier. |
Champs recommandés
Un audit log métier devrait contenir :
- identifiant de l'acteur humain ou système ;
- rôle au moment de l'action ;
- application source ;
- type d'action ;
- ressource ciblée ;
- résultat ;
- horodatage ;
- adresse IP ou contexte technique si justifié ;
- identifiant de corrélation ;
- métadonnées minimales utiles.
Il ne doit pas contenir de secret, token, mot de passe, clé API ou donnée bancaire sensible.
Différence avec logs techniques
| Type | Usage |
|---|---|
| Logs techniques | Debug, erreurs, performance, infrastructure. |
| Audit logs | Traçabilité métier et sécurité. |
| Analytics | Mesure produit agrégée. |
| Logs IA | Usage, coûts, sécurité et qualité IA. |
Ces catégories peuvent se croiser mais ne doivent pas être confondues.
Rétention
La durée de conservation doit dépendre :
- de la sensibilité de l'action ;
- des obligations légales ou contractuelles ;
- du besoin support ;
- du risque sécurité ;
- du principe de minimisation RGPD.
La cible doit définir des durées par catégorie plutôt qu'une durée unique.
Vision cible
- Créer une couche d'audit métier centralisée.
- Déclencher les logs depuis les services ou événements métier.
- Protéger l'accès aux audit logs.
- Prévoir recherche et export contrôlés pour support et sécurité.
- Relier les audit logs aux actions admin, mairie, IA, paiement et modération.
- Nettoyer ou anonymiser selon les politiques de rétention.
Points à clarifier
- Schéma cible des audit logs.
- Liste exacte des actions obligatoires.
- Durée de conservation par domaine.
- Accès support et admin aux journaux.
- Alertes automatiques sur comportements suspects.
- Séparation entre logs applicatifs, audit logs et analytics.