Journal d'audit et accès du support : qui a changé quoi

Prenons Marta, office manager d'une entreprise de 250 personnes répartie sur deux étages, avec un parking. Mardi, 9 h 50. Trois personnes lui écrivent en dix minutes : leurs réservations de bureau ont été libérées pour absence, alors qu'elles sont arrivées à 9 h 40 comme chaque semaine. Quelque chose a changé, et personne ne se souvient de l'avoir changé. L'organisation compte quatre administrateurs, plus une intégration qui synchronise les utilisateurs depuis l'annuaire de l'entreprise. La question est simple : qui a changé quoi, et quand ?

Une semaine plus tard, son délégué à la protection des données (DPO) pose une autre question pour la revue annuelle des fournisseurs : « L'éditeur du logiciel a-t-il consulté nos données cette année, et si oui, quand ? » On répond souvent à ce genre de question par un document de politique interne. Marta aimerait y répondre par une liste.

Cet article montre comment le journal d'audit de Desk & Park répond à ces deux questions, étape par étape, et ce qu'il ne fait pas.

Étape 1 : ouvrir le journal d'audit et trouver la modification

Les administrateurs trouvent le journal sous Journal d'audit. En haut, trois compteurs : les événements des dernières 24 heures, les avertissements et les événements critiques. En dessous, un tableau des entrées les plus récentes, de la plus récente à la plus ancienne, avec ces colonnes :

• Horodatage : le moment où cela s'est produit.
• Gravité : Info, Avertissement ou Critique.
• Acteur : l'adresse e-mail de l'auteur de la modification, avec son rôle en dessous, ou « system » pour les actions automatiques.
• Action et Ressource : ce qui a été fait, et sur quel type d'objet.
• Détails : les valeurs concernées, par exemple role: MEMBER → ADMIN pour un changement de rôle.
• Adresse IP : l'origine de la requête.

Marta saisit « policy » dans le champ de recherche (« Rechercher par acteur, action ou détails... »). L'entrée est là : hier à 17 h 12, l'un des administrateurs a modifié la politique de réservation et raccourci le délai de check-in. L'entrée consigne les valeurs avant et après la modification : la discussion qui suit porte donc sur la pertinence du nouveau délai, et non sur l'identité de son auteur. (Si vous ajustez ce délai, notre article sur les réservations fantômes et la libération automatique explique le compromis.)

Ce qui est consigné

Le journal couvre les modifications qu'un administrateur pourrait avoir besoin de reconstituer : utilisateurs et rôles, réservations, emplacements et plans, sites, politique de réservation, intégrations, paramètres d'authentification unique et de SCIM, synchronisation des calendriers, visiteurs, tablettes en mode kiosque et sauvegardes. Les modifications effectuées automatiquement par le provisionnement SCIM y figurent aussi : « l'annuaire a désactivé cette personne » se distingue ainsi de « un administrateur l'a fait ».

Chaque entrée enregistre l'acteur et son rôle, l'action et l'objet concerné, le résultat, les valeurs avant et après, l'adresse IP et l'agent utilisateur du navigateur.

Le filtre de gravité

Les changements de rôle, les désactivations et les suppressions sont marqués Avertissement. Les actions en échec sont marquées Critique. Filtrer par gravité est la revue hebdomadaire la plus rapide : réglez le filtre sur Avertissement, parcourez qui a été promu ou désactivé, c'est terminé.

Étape 2 : le flux de sécurité, intégré au même tableau

Les modifications de contenu ne sont que la moitié du tableau. Le même tableau affiche aussi le flux de sécurité : connexions réussies et échouées, verrouillages après échecs répétés, codes de double authentification demandés et échoués, double authentification activée ou désactivée, réinitialisations et changements de mot de passe, et réutilisation d'un jeton de session révoqué. Une connexion échouée, un verrouillage ou un jeton réutilisé apparaissent comme Critique ; la désactivation de la double authentification apparaît comme Avertissement.

Pour Marta, cela signifie un seul endroit à consulter. Si un compte a été verrouillé à 7 h 00 et que son rôle a changé à 7 h 05, les deux lignes se suivent.

Étape 3 : répondre au DPO, l'accès du support est consigné dans votre propre journal

Passons à la seconde question. Lorsque l'opérateur de la plateforme, l'équipe qui exploite Desk & Park, ouvre la vue support de votre organisation pour traiter un ticket, le système écrit une entrée dans le journal d'audit de votre propre organisation. Elle apparaît sous l'intitulé TENANT SUPPORT ACCESS, avec l'adresse e-mail de l'opérateur, l'heure et l'adresse IP.

Marta saisit donc « support » dans le champ de recherche et obtient la réponse sous forme de liste : quand quelqu'un côté éditeur a ouvert les données de l'organisation, et de qui il s'agissait. C'est toute la différence entre « nous avons une politique » et « voici l'enregistrement ». L'entrée arrive dans votre journal, et non dans un journal que seul l'éditeur peut lire. Comme la page affiche les entrées les plus récentes, Marta fait de cette vérification une habitude mensuelle et conserve l'export, plutôt que d'attendre la revue annuelle.

Où le journal est stocké, et combien de temps

Chaque organisation dans Desk & Park dispose de sa propre base de données PostgreSQL, avec son propre rôle de connexion à la base, et le journal d'audit y est stocké, aux côtés de vos utilisateurs, plans et réservations. Nous expliquons pourquoi cette architecture compte dans pourquoi vos données workplace méritent une base de données isolée. Le flux de sécurité est conservé par le service de connexion de la plateforme et vous est présenté filtré sur votre organisation.

Les entrées d'audit et de sécurité sont conservées 365 jours par défaut, puis supprimées automatiquement, conformément aux durées de conservation de la politique de confidentialité. Autour du journal se trouvent les autres moyens de contrôle dont dispose un administrateur sur les données de l'organisation :

• Des sauvegardes chiffrées chaque nuit de la base de données de l'organisation, que l'administrateur de l'organisation peut désactiver.
• Un export JSON des données de l'organisation, pour les administrateurs.
• Une demande de suppression de l'organisation entière.

Les conditions de traitement des données figurent dans le DPA.

Conseils pratiques

• Donnez à chacun son propre compte administrateur. Un identifiant partagé du type « admin@ » rend la colonne Acteur inutile. Une personne, un compte.
• Faites une revue hebdomadaire de cinq minutes. Filtrez sur Avertissement, puis sur Critique. Cherchez les changements de rôle inattendus et les échecs de connexion répétés.
• Conservez une copie si vous avez besoin d'un historique plus long. Le bouton Exporter en CSV télécharge les entrées actuellement chargées sur la page, c'est-à-dire les plus récentes. Si vos auditeurs veulent plus d'une année, exportez à intervalles réguliers et stockez les fichiers avec vos autres pièces de conformité.
• Ajoutez l'accès du support à votre revue des fournisseurs. Une fois par mois, recherchez « support », exportez le résultat et classez-le pour la revue annuelle. Cela prend une minute.
• Associez le journal à une connexion administrateur robuste. Le journal vous dit ce qui s'est passé ; la double authentification sur chaque compte administrateur rend moins probable qu'il se passe quelque chose de grave. Voir SSO, clés d'accès et double authentification.

Périmètre : ce que cela ne fait pas

La page d'administration affiche les entrées les plus récentes et propose sur celles-ci une recherche en texte libre et un filtre de gravité, mais pas de filtre par plage de dates. L'export CSV couvre les entrées chargées sur la page, pas l'année entière. Il n'y a pas d'envoi en continu des événements d'audit vers un SIEM. Les entrées plus anciennes que la durée de conservation sont supprimées : l'archivage à long terme, c'est votre export, pas le produit. Enfin, l'isolation décrite plus haut consiste en une base de données distincte par organisation, et non en un matériel distinct.

FAQ

Qui peut voir le journal d'audit ?

Les administrateurs de l'organisation. La page présente dans un seul tableau les modifications de contenu (utilisateurs, rôles, réservations, plans, politique, intégrations) et le flux de sécurité (connexions, échecs, verrouillages, événements liés à la double authentification et aux mots de passe).

Peut-on savoir quand l'équipe support de l'éditeur a accédé à nos données ?

Oui. Lorsque l'opérateur de la plateforme ouvre la vue support de votre organisation, une entrée TENANT SUPPORT ACCESS, avec l'e-mail de l'opérateur, l'heure et l'adresse IP, est écrite dans votre propre journal d'audit. Recherchez « support » pour lister les plus récentes, et exportez-les régulièrement si vous voulez un historique sur une année complète.

Combien de temps les entrées d'audit sont-elles conservées ?

365 jours par défaut ; les entrées plus anciennes sont supprimées automatiquement. Si vous avez besoin d'un historique plus long, exportez régulièrement le journal en CSV et conservez vous-même les fichiers.

Peut-on filtrer le journal d'audit par date ?

Pas sur la page d'administration. Vous pouvez rechercher dans les entrées les plus récentes par acteur, action ou détails, les filtrer par gravité et les exporter en CSV pour les analyser dans un tableur.

Le journal d'audit est-il stocké séparément de celui des autres clients ?

Oui. Le journal d'audit de chaque organisation est stocké dans la base de données PostgreSQL propre à cette organisation, avec ses utilisateurs, ses plans et ses réservations.