Vue d'ensemble des cadres applicables

RGPD
Règlement (UE) 2016/679 — applicable depuis mai 2018
Encadre le traitement des données personnelles dans l'UE. Impose des exigences sur les sous-traitants (article 28), les transferts hors UE (chapitre V), la sécurité des traitements (article 32) et la tenue d'un registre des traitements (article 30).
NIS2
Directive (UE) 2022/2555 — en vigueur depuis octobre 2024
Élargit massivement le périmètre de la directive NIS initiale. Impose des mesures de gestion des risques cyber, la sécurité des chaînes d'approvisionnement, la notification des incidents sous 24/72 heures, et la responsabilité personnelle des dirigeants.
ISO 27001:2022
Norme internationale — certification volontaire
Système de management de la sécurité de l'information. La révision 2022 introduit les contrôles A.8.20 (sécurité des réseaux) et A.8.21 (sécurité des services réseau) qui encadrent directement les déploiements VPN et la politique cryptographique.
SOC 2 Type II
AICPA — pertinent pour les prestataires de services
Les Trust Services Criteria CC6 (contrôle d'accès logique) exigent des contrôles documentés sur les accès distants, incluant l'authentification forte et la gestion des droits. Pertinent si votre organisation est elle-même prestataire pour des clients américains.

RGPD : la sous-traitance VPN et ses implications

Si votre VPN est fourni par un tiers et que vos collaborateurs accèdent via ce tunnel à des systèmes contenant des données personnelles (données RH, données clients, données de santé), ce fournisseur est un sous-traitant au sens de l'article 28 du RGPD. Cette qualification entraîne des obligations précises.

Le Data Processing Agreement (DPA)

Un DPA est obligatoire. Il doit préciser : les finalités du traitement (quelle donnée, pour quel usage), les mesures de sécurité techniques et organisationnelles, les conditions de recours à des sous-traitants ultérieurs (data centers tiers, par exemple), les obligations en cas de violation de données, et les dispositions de fin de contrat (suppression ou restitution des données).

L'absence de DPA engage la responsabilité de votre organisation, pas celle du fournisseur. La CNIL a sanctionné des responsables de traitement pour absence de DPA avec leurs sous-traitants, y compris dans des contextes où la violation de données émanait du sous-traitant.

Transferts hors UE : la réalité du CLOUD Act

Si le fournisseur VPN est une entité américaine (même avec des serveurs en Europe), les données qu'il détient peuvent être soumises au CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018). Cette loi permet aux autorités américaines d'exiger d'une entreprise soumise à la juridiction US l'accès à des données qu'elle contrôle, indépendamment de leur localisation physique.

Les Clauses Contractuelles Types (CCT) version 2021 de la Commission européenne — le mécanisme standard pour les transferts hors UE — n'offrent pas de protection contre une injonction émise dans le cadre du CLOUD Act. La Cour de justice de l'UE l'a confirmé dans l'arrêt Schrems II (2020) : les CCT ne suffisent pas si le droit du pays de destination permet un accès gouvernemental sans recours effectif.

Conséquence pratique

Ni la politique de confidentialité d'un fournisseur américain, ni son audit no-logs, ni la localisation de ses serveurs en Europe ne neutralisent le CLOUD Act. Un fournisseur américain peut être légalement contraint de divulguer des données à des autorités américaines sans en informer ses clients. Pour les données soumises à des exigences de confidentialité strictes (secret professionnel, données de santé, données stratégiques), cela conduit à privilégier des fournisseurs européens ou une infrastructure autohébergée.

Transferts hors UE et Transfer Impact Assessment

Depuis l'arrêt Schrems II, tout transfert de données personnelles hors UE doit être accompagné d'un Transfer Impact Assessment (TIA) — une analyse qui évalue si le droit du pays de destination offre une protection équivalente au RGPD. Pour les États-Unis, l'EU-US Data Privacy Framework (2023) offre un cadre d'adéquation, mais son avenir juridique est incertain suite aux recours en cours devant la CJUE.


NIS2 : ce qui s'applique aux accès distants

La directive NIS2 (transposée en France via la loi relative à la résilience des activités d'importance vitale) s'applique aux entités essentielles et importantes dans un périmètre sectoriel élargi : énergie, transports, santé, eau, infrastructures numériques, services postaux, gestion des déchets, chimie, agroalimentaire, industrie manufacturière critique, services numériques.

Sur les accès distants, NIS2 impose plusieurs mesures concrètes qui affectent directement la configuration VPN.

Politiques formalisées d'accès

NIS2 exige la mise en place de politiques formalisées de contrôle d'accès, documentées et auditables. Pour un VPN, cela signifie : une politique écrite qui définit qui peut se connecter depuis l'extérieur, avec quels credentials, depuis quels terminaux, et avec accès à quelles ressources. Cette politique doit être revue périodiquement et les écarts doivent être documentés.

Authentification multifacteur obligatoire

NIS2 impose le MFA pour les accès aux systèmes et réseaux critiques. Pour un VPN qui donne accès au SI interne d'une entité NIS2, le MFA sur la connexion VPN n'est plus une recommandation — c'est une obligation. Les méthodes admissibles sont celles qui résistent au phishing : TOTP, tokens matériels, certificats. Le SMS n'est pas admissible dans ce contexte.

Notification des incidents : 24h / 72h

Un incident de sécurité significatif affectant les accès distants — compromission de credentials VPN avec accès constaté, exploitation d'une CVE sur l'équipement VPN, violation de données via le tunnel — doit être notifié à l'ANSSI dans des délais stricts : 24 heures pour une notification initiale (incident détecté, périmètre estimé), 72 heures pour un rapport intermédiaire (analyse en cours, mesures prises), 1 mois pour un rapport final complet.

Sécurité de la chaîne d'approvisionnement

NIS2 impose d'évaluer les pratiques de sécurité de vos fournisseurs de services numériques — y compris les fournisseurs VPN. L'audit no-logs d'un fournisseur, sa politique de divulgation des vulnérabilités, et ses délais de patching sont des éléments de cette évaluation.


Les audits no-logs : valeur réelle et limites structurelles

Les audits de politiques de non-journalisation publiés par les fournisseurs de VPN managé sont réalisés par des cabinets spécialisés (Cure53, Deloitte, SEC Consult, KPMG pour certains). Ils vérifient, à un instant T et avec l'accès accordé par le fournisseur, que la configuration des serveurs ne produit pas de logs identifiants.

Ce qu'un audit no-logs prouve

Qu'à la date de l'audit, sur les serveurs audités, avec la configuration alors en place, aucun log permettant d'identifier un utilisateur ou une session n'était produit. C'est une vérification d'implémentation ponctuelle — non triviale et utile.

Ce qu'un audit no-logs ne prouve pas

Que la configuration auditée sera maintenue telle quelle en production continue. Que d'autres serveurs non inclus dans le périmètre d'audit produisent les mêmes garanties. Que le fournisseur ne peut pas activer des logs à la demande (technique ou juridique). Que les métadonnées réseau en amont du serveur VPN — celles que détient le fournisseur d'hébergement, pas le fournisseur VPN — ne peuvent pas être exploitées. Que le fournisseur est protégé contre une injonction judiciaire dans sa juridiction.

Un fournisseur qui audite régulièrement (annuellement minimum), publie les rapports complets sans expurgation, et dont les audits portent sur l'ensemble de l'infrastructure (pas seulement les serveurs choisis) est significativement plus crédible qu'un fournisseur avec un audit ponctuel vieux de trois ans. Mais la garantie reste structurellement limitée par la nature de l'exercice.


ISO 27001:2022 : les contrôles qui s'appliquent directement

La révision 2022 de la norme ISO 27001 introduit deux contrôles directement applicables aux déploiements VPN.

A.8.20 — Sécurité des réseaux : exige une politique de sécurité réseau documentée, incluant le contrôle des accès distants, la séparation des réseaux, et la protection contre les menaces réseau. Le déploiement VPN doit être documenté comme contrôle dans le Statement of Applicability (SoA).

A.8.21 — Sécurité des services réseau : exige l'identification des mécanismes de sécurité des services réseau utilisés, incluant les tunnels chiffrés. La justification du choix protocolaire (WireGuard vs IPsec, suites cryptographiques) doit être documentée par rapport à la politique cryptographique de l'organisation (contrôle A.8.24).

Pour un audit de certification ISO 27001, le dossier de preuve sur le déploiement VPN devra inclure : la politique d'accès distant, la liste des protocoles et algorithmes utilisés avec leur justification, le processus de gestion des certificats, les procédures de révocation d'accès, et les journaux d'accès avec leur politique de rétention. La page sur le déploiement couvre la production et la rétention de ces journaux.