EQF_SOFTWARE

Ce que les audits prouvent — et leurs limites

Un audit de sécurité tiers sur un fournisseur VPN peut couvrir plusieurs périmètres distincts. La valeur d'un audit dépend entièrement de ce périmètre — un audit d'application client ne dit rien sur la sécurité de l'infrastructure serveur, et vice versa.

Types d'audits et périmètres couverts

Type d'auditCe qui est vérifiéCe qui n'est pas vérifié
Audit no-logs Configuration des serveurs à l'instant T — absence de logs identifiants Configuration future, logs hors périmètre, données upstream (hébergeur)
Pentest application client Vulnérabilités dans les clients desktop/mobile, fuites DNS, kill switch Infrastructure serveur, gestion des clés, accès backend
Audit d'infrastructure Configuration des serveurs, gestion des secrets, accès administrateurs Code source, gestion des incidents passés, politique interne
Audit de code source Vulnérabilités dans le code, portes dérobées, implémentation crypto Configuration de déploiement, pratiques opérationnelles
Audit SOC 2 Type II Contrôles opérés sur une période (6-12 mois) — accès, incidents, logs Qualité du code, configuration technique de bas niveau

Limites structurelles communes à tous les audits

  • Instantané dans le temps : un audit vérifie l'état à la date de l'audit. La configuration peut changer le lendemain. Un programme d'audits récurrents (annuels ou biannuels) avec publication des rapports complets est plus significatif qu'un audit unique.
  • Périmètre défini par le fournisseur : l'auditeur examine ce que le fournisseur lui autorise à examiner. Les systèmes hors périmètre — hébergeur de datacenter, fournisseur de transit réseau, systèmes internes RH — ne sont pas couverts.
  • Indépendance relative : l'auditeur est mandaté et payé par le fournisseur audité. Des cabinets comme Cure53, NCC Group ou Bishop Fox ont des réputations à maintenir — mais l'incitation structurelle à ne pas décevoir le client existe.
  • Publication partielle : certains fournisseurs publient des résumés d'audit plutôt que les rapports complets. Un résumé positif sans accès au rapport détaillé a une valeur probante très limitée.
Critères d'évaluation d'un audit

Rapport complet accessible publiquement (pas un résumé). Auditeur indépendant avec réputation établie. Périmètre clairement défini dans le rapport. Date récente (moins de 18 mois). Findings documentés avec leur statut de correction — un rapport qui ne documente aucune finding a moins de crédibilité qu'un rapport qui documente des findings corrigées.

Ce que "no-logs" signifie réellement

La politique de non-journalisation est l'engagement d'un fournisseur à ne pas conserver de données permettant d'identifier les connexions des utilisateurs — adresses IP source et destination, timestamps de connexion, volume de données, contenu du trafic. La valeur de cet engagement dépend de trois dimensions indépendantes.

Dimension 1 — Portée exacte de la politique

Les politiques no-logs varient considérablement dans leur périmètre. Certains fournisseurs ne conservent pas les logs de connexion mais conservent des données agrégées d'utilisation (bande passante par abonnement). D'autres ne journalisent pas le trafic mais journalisent les événements d'authentification. Lire la politique de confidentialité avec précision — les termes "connection logs", "activity logs", "metadata" ont des définitions distinctes selon les fournisseurs.

Dimension 2 — Vérifiabilité technique

Un audit no-logs vérifie à un instant T que la configuration des serveurs ne produit pas de logs identifiants dans les emplacements inspectés. Il ne peut pas vérifier : les logs produits par l'hyperviseur ou le provider d'hébergement (couche hors contrôle du fournisseur VPN), les logs conservés en mémoire volatile avant écriture sur disque, ou les logs produits par des systèmes tiers dans la chaîne (CDN, anycast, DNS upstream).

Dimension 3 — Juridiction et contraintes légales

Même en l'absence de logs, une injonction légale peut contraindre un fournisseur à commencer à journaliser les connexions d'un utilisateur ciblé, de façon prospective. Les lois sur la rétention des données varient significativement selon les juridictions :

JuridictionMécanismePortée
États-UnisCLOUD Act, NSL (National Security Letter)Données contrôlées par entités US, mondiales. NSL avec interdiction de divulgation.
Union européenneEntraide judiciaire internationaleSur demande judiciaire nationale. Pas de rétention préventive généralisée post-CJUE 2022.
Royaume-UniInvestigatory Powers Act (2016)Rétention de métadonnées imposable aux fournisseurs.
SuisseDroit suisse — entraide via MLATProcédure d'entraide judiciaire requise — délai significatif.
Îles Vierges BritanniquesDroit BVI — entraide limitéePas d'accords d'entraide automatique avec UE ou USA.
Conclusion pratique

Pour une entreprise dont le modèle de menace inclut une injonction légale, la politique no-logs est un facteur secondaire par rapport à la juridiction du fournisseur. Pour une entreprise dont le modèle de menace est limité à la confidentialité vis-à-vis d'observateurs réseau passifs, un audit no-logs récent par un cabinet reconnu est une garantie suffisante.

Évaluer un fournisseur VPN managé pour une PME

La sélection d'un fournisseur VPN managé pour une PME doit être traitée comme un exercice de due diligence fournisseur — pas comme un achat en ligne. Voici les critères techniques et contractuels à évaluer systématiquement.

Critères techniques

  • Protocoles disponibles : WireGuard et/ou IKEv2 obligatoires. Suites cryptographiques documentées et conformes aux recommandations ANSSI/NIST.
  • MFA disponible : TOTP minimum. SAML/OIDC pour intégration IdP. Vérifier que le MFA est imposable à tous les utilisateurs, pas seulement optionnel.
  • Kill switch implémenté : sur tous les clients (Windows, macOS, iOS, Android). Activable par politique d'administration centrale.
  • Gestion centralisée des accès : API ou interface pour provisionner/révoquer les accès. Révocation immédiate opérationnelle — à tester avant déploiement.
  • Export des logs : logs d'authentification et de session exportables vers SIEM (format JSON ou syslog). Indispensable pour la détection d'anomalies et la conformité.

Critères contractuels et juridiques

  • DPA disponible et signable : demander le DPA avant tout engagement. Vérifier qu'il couvre la liste des sous-traitants ultérieurs et les conditions de notification en cas de violation.
  • Juridiction : identifier le pays d'immatriculation de l'entité juridique qui opère le service. Distinguer du pays de localisation des serveurs — les deux peuvent différer.
  • SLA de disponibilité documenté : engagement de disponibilité (99.9% minimum pour un usage professionnel), procédure de notification des incidents, historique public des incidents.
  • Politique de divulgation des vulnérabilités : programme de bug bounty ou contact de sécurité dédié. Historique des CVE publiées et des délais de correction.
  • Audits publiés : rapport complet (pas résumé), auditeur reconnu, date récente. Absence d'audit n'est pas disqualifiante pour une solution autohébergée — mais l'est pour un service managé.

Questions à poser avant signature

  • Qui détient les clés de chiffrement des tunnels — vous ou le fournisseur ?
  • Dans quel délai une révocation d'accès est-elle effective après la demande ?
  • Quels sous-traitants hébergent l'infrastructure et dans quelles juridictions ?
  • Comment le fournisseur répondrait-il à une injonction CLOUD Act ou une demande d'entraide judiciaire ?
  • Quel est le délai moyen de patching pour les CVE de score CVSS ≥ 9.0 ?