Audit Logs dans Grist : Surveiller les Actions pour une Meilleure Sécurité

Les audit logs, ou journaux d'audit, sont des enregistrements automatiques des événements qui se produisent dans votre installation Grist. Si vous gérez une petite entreprise ou une association, ces logs vous aident à suivre qui a fait quoi, quand et comment. Par exemple, vous pouvez vérifier qui a créé un document, modifié des données sensibles ou invité un collaborateur. C'est essentiel pour respecter les règles de conformité, comme le RGPD en Europe, ou simplement pour détecter un problème rapidement sans perdre de temps.

Dans cet article, nous couvrons les bases des audit logs dans Grist pour les installations auto-hébergées (self-managed). Nous expliquons ce qu'ils sont, les événements qu'ils capturent, et comment les configurer pour un streaming vers des outils externes comme Splunk. Tout est adapté aux débutants : pas de jargon technique inutile, juste des étapes claires. Prêts ? Allons-y.

Qu'est-ce que les Audit Logs et Pourquoi les Utiliser ?

Les audit logs sont comme un journal de bord pour votre système Grist. Chaque action importante – création d'un document, changement de permissions, suppression d'un utilisateur – génère un événement enregistré avec des détails précis. Cela inclut :

L'action : Ce qui s'est passé, comme "document.create" pour la création d'un doc.
L'acteur : Qui l'a fait, avec l'ID utilisateur, l'email et le nom.
Le contexte : D'où ça vient, comme l'adresse IP, le navigateur utilisé, et l'ID de session.
Le timestamp : L'heure exacte en UTC.
Les détails : Infos spécifiques, comme l'ID et le nom du document concerné.

Pour une petite équipe, imaginez : un volontaire dans votre association modifie un budget partagé. Les logs vous montrent exactement ce qui a changé, par qui, et à quel moment. Pas besoin de fouiller manuellement dans l'historique des docs – tout est centralisé.

Pourquoi c'est utile pour vous ?

Conformité : Prouvez que vous suivez les accès aux données, idéal pour les audits annuels.
Sécurité : Détectez les anomalies, comme un accès inattendu depuis une IP inconnue.
Dépannage : Si un document disparaît, les logs indiquent qui l'a supprimé et quand.

Ces logs ne s'appliquent qu'aux installations self-managed, pas au Grist cloud gratuit ou pro. Si vous êtes sur cloud, contactez le support pour des options équivalentes. Pas de coûts supplémentaires : c'est inclus une fois activé.

Les Types d'Événements Suivis

Grist enregistre les changements sur les configurations, documents, sites, utilisateurs et workspaces. Voici les principaux types, avec des exemples concrets pour une équipe restreinte.

config.create : Un admin ajoute une destination pour les logs, comme une intégration Splunk. Utile pour démarrer le suivi automatiquement.
document.create : Quelqu'un crée un nouveau fichier, par exemple un tableau de tâches pour un projet associatif. Détails : ID du doc, nom, et workspace parent.
document.modify : Une édition de données, avec le numéro de version et un hash pour vérifier l'intégrité. Parfait pour tracer les mises à jour budgétaires.
site.change_access : Changement de permissions sur un site d'équipe, comme restreindre l'accès à un dossier sensible. Inclut l'ancien et le nouvel état.
user.delete_api_key : Suppression d'une clé API, souvent après le départ d'un membre. Ajoute une couche de sécurité pour les intégrations externes.

Chaque événement est structuré en JSON simple. Exemple pour une création de document :

{
  "id": "806ed0d9-7d25-4df2-9a6c-f7d2f6b8dba6",
  "action": "document.create",
  "actor": {
    "type": "user",
    "user": {
      "id": 146,
      "email": "[email protected]",
      "name": "Flapjack Toasty"
    }
  },
  "context": {
    "ip_address": "39.139.42.243",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36",
    "session_id": "ixVo6maPbcgd1vvoj93teT",
    "site": {
      "id": 42,
      "name": "Grist Labs",
      "domain": "gristlabs"
    }
  },
  "timestamp": "2024-11-13T06:00:51.518Z",
  "details": {
    "document": {
      "id": "4cq1mNTkQmEF5KsUVGiy6H",
      "name": "Untitled document"
    }
  }
}

Pour une SMB, cela signifie que vous pouvez filtrer les logs par utilisateur ou action pour un rapport rapide. Dans une asso, utilisez-les pour justifier des subventions en montrant un contrôle strict des données.

Note : Les logs ne capturent pas les vues passives, seulement les actions modifiantes. Et ils commencent à l'activation – rien avant.

Comment Activer et Configurer les Audit Logs

Pour démarrer, vous devez être admin de l'installation self-managed. Accédez au Panneau Admin via l'icône de profil en haut à droite de Grist.

Étape 1 : Accéder aux Paramètres

Cliquez sur votre icône de profil.
Sélectionnez Admin Panel.
Allez dans la section Audit Logs, puis Log Streaming.

Ici, vous gérez les destinations où envoyer les logs. Sans streaming, les événements ne sont pas stockés localement – Grist les envoie directement pour éviter la surcharge.

Étape 2 : Ajouter une Destination Basique

Choisissez entre Splunk (via HTTP Event Collector) ou "Other" pour un endpoint HTTP générique.

Pour un débutant sans SIEM dédié, commencez par "Other" et testez avec un outil simple comme un webhook vers un fichier JSON.

Prérequis :

Votre installation Grist doit pouvoir atteindre l'endpoint externe (pas de firewall bloquant).
Pour Splunk : Un endpoint HEC configuré (gratuit dans Splunk Cloud ou on-prem).

Une fois activé, tous les événements futurs de tous les sites d'équipe sont envoyés en temps réel.

Streaming des Logs : Intégration avec des Outils Externes

Le streaming rend les logs exploitables. Grist pousse les événements vers un SIEM comme Splunk, ELK Stack ou même un script personnalisé. Avantage pour une petite structure : surveillance en temps réel sans serveur dédié.

Configuration pour Splunk

Splunk est populaire pour les non-profits car gratuit pour les petits volumes (<500MB/jour).

Dans Grist Admin Panel > Audit Logs > Log Streaming > Destinations > Add destination.
Sélectionnez Splunk.
Entrez l'URL de votre HEC endpoint (ex. : https://votre-splunk:8088/services/collector).
Pour le Token : Tapez "Splunk " suivi de votre token HEC (ex. : Splunk B5A79AAD-D822-46CC-80D1-819F80D7BFB0).
Cliquez Add destination.

Les événements arrivent en JSON, prêts à indexer dans Splunk. Vous pouvez créer des dashboards pour visualiser les actions par utilisateur.

Pour d'Autres Systèmes (HTTP Générique)

Idéal si vous utilisez ELK ou un outil maison.

Même chemin : Admin Panel > Audit Logs > Log Streaming > Add destination.
Choisissez Other.
URL : L'endpoint HTTP qui accepte POST JSON (ex. : https://votre-serveur/logs).
Token : La valeur pour l'en-tête Authorization (ex. : Bearer votre-token si requis).
Ajoutez.

Grist envoie un POST avec le JSON d'événement. Testez en créant un doc pour voir si ça arrive.

Vous pouvez ajouter plusieurs destinations (ex. : Splunk + backup local). Pour supprimer : Éditez ou supprimez depuis la liste.

Utilisation Pratique des Logs pour Votre Équipe

Une fois streamés, analysez-les dans votre SIEM.

Rapports quotidiens : Filtrez par "document.modify" pour voir les edits récents. Dans Splunk, une requête simple comme index=grist action=document.modify | stats count by actor.user.email montre les contributeurs les plus actifs.
Alertes : Configurez des notifications pour "user.delete" ou accès suspects (IP inconnue).
Conformité : Exportez les logs pour un audit : prouvez que seul l'admin a changé les accès.

Pour une asso gérant des dons : Suivez les "site.change_access" pour assurer que les volontaires n'accèdent qu'aux données nécessaires.

Exemple concret : Votre équipe crée un doc "Budget 2025". Les logs capturent :

document.create par [email protected] à 10h.
document.modify par [email protected] à 11h (détails : champ "montant" changé de 500 à 550€).

Pas d'overhead : Grist gère le streaming sans ralentir votre interface.

Bonnes Pratiques et Résolution de Problèmes

Commencez petit : Activez pour un site test avant tout.
Rôles clairs : Limitez l'accès Admin Panel aux responsables sécurité.
Rétention : Les SIEM gèrent ça ; prévoyez 6-12 mois pour la conformité.
Test : Créez/supprimez un doc et vérifiez l'arrivée des logs.

Problèmes courants :

Logs manquants : Vérifiez que l'endpoint est reachable (testez avec curl depuis le serveur Grist).
Erreurs auth : Token mal formaté – pour Splunk, assurez "Splunk " prefix.
Pas d'événements : Attendez une action post-activation.

Si bloqué, consultez les logs Grist serveur (via Docker) pour des erreurs de streaming.

Conclusion

Les audit logs de Grist simplifient la surveillance sans complexité. Pour votre SMB ou asso, ils offrent visibilité et paix d'esprit sur un budget serré. Activez-les aujourd'hui via le Panneau Admin, stream vers Splunk si possible, et commencez à tracker. Questions ? Les docs officiels sont votre prochaine étape, ou posez en commentaires.

Audit Logs dans Grist