Journalisation (logs) et conformité avec un VPN cloud managé

Dans un VPN cloud managé, tout transite par une infrastructure opérée par un fournisseur : authentification, établissement des tunnels, transit vers vos réseaux privés, application des ACL. Cela génère un volume important de journaux (logs) qui peuvent devenir un atout majeur pour la sécurité et la conformité… à condition de les comprendre et de les exploiter correctement.

Ce texte détaille les types de logs que l’on retrouve généralement dans un VPN cloud managé, ce qu’ils permettent de vérifier (ou non), comment les intégrer dans une démarche de sécurité et quels points surveiller côté conformité et protection des données.

1. Quels types de logs produit un VPN cloud managé ?

Un VPN cloud managé génère au minimum trois grandes familles de journaux :

  • Logs d’authentification et de session :
    • connexion / déconnexion des utilisateurs ;
    • succès / échec d’authentification ;
    • type d’authentification (mot de passe, SSO, MFA).
  • Logs d’accès aux ressources :
    • quelles ressources (réseaux, hôtes, applis) ont été atteintes ;
    • depuis quel utilisateur, groupe, adresse IP de sortie ;
    • quel verdict (autorisé / refusé).
  • Logs techniques / d’infrastructure :
    • état des connecteurs (up/down, erreurs) ;
    • établissement / rupture des tunnels ;
    • erreurs de configuration ou d’application des ACL.

Selon le fournisseur, ces logs peuvent être consultés :

  • dans une console web ;
  • via une API ;
  • exportés vers un SIEM ou un collecteur de journaux interne.

2. Distinguer logs techniques et données personnelles

Un point souvent sous-estimé : les logs d’un VPN cloud contiennent très fréquemment des données personnelles ou identifiantes :

  • identifiant utilisateur ou adresse e-mail ;
  • adresse IP d’origine (poste client) ;
  • horodatages précis des connexions ;
  • dans certains cas, informations techniques sur l’appareil (OS, version du client).

Il est donc utile de distinguer :

  • Logs techniques “purs” :
    • statut des connecteurs ;
    • erreurs de tunnel ;
    • ratés de routage, erreurs de configuration.
  • Logs “d’activité utilisateur” :
    • qui s’est connecté, quand, depuis où ;
    • à quelles ressources il a accédé ;
    • quels accès ont été refusés.

Les premiers sont utiles pour l’exploitation purement technique. Les seconds sont utiles pour la sécurité (détection d’anomalies, investigation) mais sont soumis à des règles plus strictes (protection des données, transparence, durées de conservation).

3. Ce qu’on peut faire avec les logs d’authentification et de session

Les logs d’authentification et de session permettent de répondre à des questions simples mais essentielles :

  • Qui s’est connecté, à quelle heure, depuis quelle adresse IP d’origine ?
  • Combien de tentatives échouées pour chaque compte ?
  • Quels comptes ne se connectent plus depuis longtemps (comptes dormants) ?
  • Y a-t-il des connexions depuis des pays inattendus ou des plages IP suspectes ?

Cas d’usages typiques :

  • Surveillance des attaques par force brute :
    • multiples échecs d’authentification sur un même compte ;
    • succès soudain après une série d’échecs depuis une IP exotique.
  • Gestion des comptes :
    • identification de comptes jamais utilisés ou plus utilisés ;
    • vérification que les comptes d’anciens collaborateurs sont bien désactivés.
  • Détection d’accès inhabituels :
    • connexion à des heures très atypiques pour un profil donné ;
    • connexion depuis un pays où l’entreprise n’a aucune activité.

Idéalement, ces logs sont corrélés avec :

  • les logs d’authentification de l’IdP (SSO) ;
  • les outils de sécurité du poste (EDR, MDM) ;
  • les logs applicatifs internes (accès à des données sensibles).

4. Exploiter les logs d’accès aux ressources

Les logs d’accès aux ressources sont encore plus riches : ils documentent les tentatives de connexion à des sous-réseaux, des hôtes ou des applications internes, avec un verdict (autorisé ou refusé).

Ils permettent de :

  • vérifier la bonne application des ACL (ce qui devait être bloqué l’est réellement) ;
  • détecter des comportements anormaux (scans internes, accès massifs à des ressources inattendues) ;
  • documenter finement à quelles ressources un compte a accédé dans une période donnée.

Exemples de signaux intéressants :

  • un utilisateur de type “Support” qui tente régulièrement d’accéder à des segments d’admin ou à des bases critiques ;
  • un compte de partenaire qui enchaîne des tentatives sur des IP internes qui ne figurent dans aucune documentation fournie ;
  • un admin qui, en dehors des heures habituelles, tente de nombreuses connexions vers des systèmes sensibles.

Couplés avec un SIEM et des règles de corrélation, ces logs peuvent alimenter :

  • des alertes temps réel en cas d’activité anormale ;
  • des rapports périodiques sur les accès à des ressources sensibles ;
  • des investigations après incident (traçage des actions d’un compte compromis, par exemple).

5. Logs techniques : connecteurs, tunnels et erreurs

Côté exploitation réseau, les logs techniques intéressent surtout les équipes infra :

  • statut des connecteurs (disponibles, indisponibles, en erreur) ;
  • reconnexions fréquentes ou instables des tunnels ;
  • échecs de résolution DNS pour certaines ressources internes ;
  • messages liés à la non-appliance d’une ACL ou d’une règle de routage.

Ils permettent :

  • de diagnostiquer rapidement un problème d’accès (VPN cloud up, mais connecteur down, par exemple) ;
  • de détecter des surcharges (connecteur saturé, latence accrue côté fournisseur) ;
  • de vérifier que les modifications de configuration (routes, ACL) sont correctement prises en compte.

Même s’ils contiennent peu d’informations personnelles, ces logs sont essentiels pour garantir la disponibilité et la performance du service.

6. Intégration des logs dans un SIEM ou une solution de log centralisée

Pour tirer réellement parti des logs d’un VPN cloud managé, il est recommandé de les exporter vers une solution centralisée plutôt que de se limiter à la console du fournisseur.

Intérêt :

  • corrélation avec d’autres sources (authentification, EDR, firewall, proxies, logs applicatifs) ;
  • recherche et investigation plus avancées (requêtes complexes, filtrage multi-critères) ;
  • mise en place de tableaux de bord (kibanisation, reporting sécurité).

Points techniques à prévoir :

  • format des logs (JSON, syslog, CSV, API) ;
  • fréquence et mode d’export (push, pull, streaming) ;
  • gestion de l’authentification pour l’accès à l’API de logs ;
  • volume et coût de stockage (surtout si la rétention est longue).

7. Conformité, confidentialité et durées de conservation

Sur le plan conformité et protection des données, plusieurs sujets se posent :

7.1 Transparence vis-à-vis des utilisateurs

Si les logs contiennent des données personnelles (ce qui est quasiment toujours le cas) :

  • les utilisateurs doivent être informés de l’existence de ces logs ;
  • l’usage qui en est fait doit être clair (sécurité, audit, conformité) ;
  • l’accès à ces journaux doit être restreint (équipe sécurité, admin désignés).

7.2 Durées de conservation

Il est important de définir :

  • une durée de conservation “technique” minimale pour la supervision au quotidien ;
  • une durée de conservation plus longue pour les besoins d’audit ou de détection à froid (par exemple en cas d’attaque découverte tardivement) ;
  • des politiques d’archivage ou d’anonymisation pour dépasser certaines durées sans conserver indéfiniment des données identifiantes.

Les logs ne devraient pas être conservés “pour toujours” sans justification claire.

7.3 Localisation et transfert des logs

Dans un contexte multi-pays, il peut être nécessaire de vérifier :

  • où sont stockés les logs (région, pays, datacenter) ;
  • si des transferts hors de votre zone juridique sont effectués ;
  • quelles garanties contractuelles et techniques existent (chiffrement au repos, contrôle d’accès, journalisation des accès aux logs eux-mêmes).

Ces éléments doivent idéalement être documentés dans vos politiques de sécurité et de conformité internes.

8. Qui a accès aux logs et avec quels droits ?

Un autre aspect souvent négligé : l’accès aux logs eux-mêmes. Il est nécessaire de définir :

  • qui peut consulter les logs techniques (état des connecteurs, erreurs, tunnels) ;
  • qui peut consulter les logs d’activité utilisateur (connexions, ressources accédées) ;
  • comment cet accès est tracé et audité.

Bonnes pratiques :

  • séparer les rôles “admin technique” et “analyste sécurité” ;
  • journaliser les accès à la console de logs du fournisseur (et, si possible, à votre SIEM) ;
  • limiter le nombre de comptes ayant accès aux données les plus sensibles (activité détaillée des utilisateurs).

9. Exemple de politique de journalisation autour d’un VPN cloud managé

Une politique de journalisation cohérente peut inclure :

  • Périmètre :
    • logs d’authentification et de session des utilisateurs ;
    • logs d’accès aux ressources (autorisés et refusés) ;
    • logs de statut des connecteurs et des tunnels.
  • Rétention :
    • X jours en stockage chaud (consultation rapide) ;
    • Y mois en stockage d’archive, éventuellement avec anonymisation partielle.
  • Accès :
    • équipe réseau / infra : principalement logs techniques ;
    • équipe sécurité : logs d’activité utilisateur et d’accès ;
    • accès via comptes nominatifs, MFA obligatoire.
  • Usage :
    • détection et investigation de sécurité ;
    • audit interne ou externe ;
    • analyse de capacité et d’usage (charge, pics, besoins futurs).

Cette politique doit être alignée sur vos obligations réglementaires et partagée avec les équipes concernées.

Conclusion

Les logs d’un VPN cloud managé ne sont pas un simple “bonus” de la console d’admin : ils sont au cœur de la visibilité sur l’accès distant à vos ressources internes.

Bien exploités, ils permettent de :

  • suivre précisément qui se connecte, quand, et à quoi ;
  • vérifier l’efficacité de vos ACL et détecter des comportements anormaux ;
  • diagnostiquer rapidement des problèmes de connecteurs, de tunnels, de DNS ou de routage ;
  • alimenter vos processus de sécurité, d’audit et de conformité.

En contrepartie, ils exigent :

  • une gestion rigoureuse de l’accès à ces journaux ;
  • des durées de conservation définies et justifiées ;
  • une transparence vis-à-vis des utilisateurs et une intégration avec vos politiques internes de protection des données.

Un VPN cloud managé sans stratégie de logs claire est une boîte noire. Avec une politique de journalisation et une intégration à vos outils de sécurité, il devient au contraire un point de contrôle et de traçabilité précieux dans votre architecture d’accès distant.