EQF_SOFTWARE

Comparatif des méthodes

MéthodeNiveauRésistance phishingComplexité déploiementCas d'usage
Token matériel FIDO2/WebAuthn Maximal Totale Moyenne (achat tokens) Admins, accès critiques
Certificat client X.509 Élevé Élevée Élevée (PKI requise) Terminaux gérés (MDM)
TOTP + mot de passe Bon Partielle Faible Usage général
Push MFA (IdP) Bon Partielle Faible (si IdP existant) Usage général
SMS OTP Insuffisant Faible Très faible À éviter pour accès réseau
Mot de passe seul Inacceptable Nulle Ne pas utiliser

Tokens matériels FIDO2 — fonctionnement

FIDO2 (WebAuthn + CTAP2) repose sur la cryptographie à clé publique. La clé privée est générée et stockée dans le token matériel (YubiKey, Google Titan, etc.) et n'en sort jamais. L'authentification génère une signature avec la clé privée, vérifiable par le serveur avec la clé publique enregistrée. La résistance au phishing est structurelle : le token vérifie le domaine du service avant de signer — une tentative de phishing sur un faux domaine échoue automatiquement.

TOTP — RFC 6238

Le TOTP (Time-based One-Time Password) génère un code à 6 chiffres valide 30 secondes, dérivé d'un secret partagé et du timestamp courant (HMAC-SHA1 par défaut, HMAC-SHA256 recommandé). La résistance au phishing est partielle : un attaquant peut intercepter le code via une page de phishing en temps réel (attaque AiTM — Adversary in The Middle). Pour les accès à des ressources critiques, préférer FIDO2.

SMS OTP — vecteurs documentés

Le SIM swapping (transfert frauduleux de numéro de téléphone auprès de l'opérateur) permet d'intercepter les SMS OTP. L'interception SS7 (protocole de signalisation des réseaux téléphoniques) est accessible à des acteurs étatiques et à certains acteurs criminels organisés. Le SMS comme facteur d'authentification sur des accès réseau d'entreprise est inacceptable en 2026.

Intégration avec un fournisseur d'identité centralisé

L'intégration du VPN avec un IdP centralisé permet de piloter tous les accès depuis un point unique — onboarding, modification des droits, offboarding. Un collaborateur désactivé dans l'IdP est automatiquement exclu du VPN sans action séparée.

Protocoles d'intégration

  • SAML 2.0 : standard d'assertion d'identité basé sur XML. Large support dans les clients VPN enterprise. Flux SP-initiated ou IdP-initiated. Compatible avec Okta, Entra ID, PingFederate, OneLogin.
  • OIDC (OpenID Connect) : couche d'identité sur OAuth 2.0. Tokens JWT. Préféré pour les nouvelles intégrations — plus léger que SAML, meilleur support mobile.
  • RADIUS : protocole legacy mais universel. Supporte EAP-TLS (certificats), EAP-TTLS/PAP (identifiant + TOTP). Proxy RADIUS vers un IdP moderne via FreeRADIUS ou NPS.
  • LDAP / Active Directory : authentification directe contre l'annuaire. Pas de MFA natif — nécessite un proxy MFA (Duo, Authy) ou une intégration via RADIUS.

Mapping des attributs et contrôle d'accès

L'IdP transmet des attributs sur l'utilisateur lors de l'authentification (groupe d'appartenance, département, niveau d'autorisation). Le concentrateur VPN peut utiliser ces attributs pour appliquer des politiques d'accès différenciées : un utilisateur du groupe "finance" accède à un sous-réseau spécifique, un administrateur accède à l'ensemble du réseau de gestion. Cette fonctionnalité (RBAC sur le VPN) est disponible dans StrongSwan via des attributs EAP/RADIUS.

Infrastructure à clé publique pour VPN d'entreprise

Une PKI interne est nécessaire pour l'authentification par certificats — méthode la plus robuste pour les terminaux gérés. La sécurité de l'ensemble repose sur la protection de la clé privée de la CA racine.

Structure recommandée

  • CA racine hors ligne : clé privée générée sur un poste air-gapped, stockée sur un HSM ou un support chiffré déconnecté. Ne signe que les certificats des CA intermédiaires. Durée de validité longue (10-20 ans). La compromission de la CA racine invalide toute la chaîne — c'est l'actif le plus sensible de la PKI.
  • CA intermédiaires en ligne : émission quotidienne des certificats terminaux. Durée de validité plus courte (5 ans). En cas de compromission, révocable sans invalider la CA racine. Séparer la CA intermédiaire des clients et la CA intermédiaire des serveurs.
  • Certificats terminaux : durée de validité courte (1 an maximum). Renouvellement automatisé via ACME (Let's Encrypt pour PKI privée avec step-ca) ou scripts internes. Profils distincts : clients (EKU Client Authentication), serveurs VPN (EKU Server Authentication).
  • Stockage des clés privées clients : préférer le TPM (Trusted Platform Module) du terminal ou un token matériel. La clé privée ne doit pas être exportable depuis l'appareil.

Révocations — CRL et OCSP

La révocation est le mécanisme par lequel un certificat valide est invalidé avant son expiration — terminal compromis, collaborateur parti, clé privée potentiellement exposée. Deux mécanismes :

CRL (Certificate Revocation List) : liste signée par la CA des numéros de série révoqués. Le client télécharge la CRL périodiquement et vérifie localement. Délai de propagation = fréquence de mise à jour de la CRL (typiquement 24h). Fonctionne hors ligne.

OCSP (Online Certificate Status Protocol, RFC 6960) : requête en temps réel à un répondeur OCSP pour vérifier le statut d'un certificat. Pas de délai de propagation. Nécessite une disponibilité du répondeur — envisager OCSP stapling pour les certificats serveur.

Test de révocation obligatoire

Révoquer un certificat de test et vérifier qu'une tentative de connexion avec ce certificat est effectivement rejetée. Ce test doit être intégré aux procédures de recette et exécuté périodiquement. En production, des configurations CRL mal pointées ou des répondeurs OCSP indisponibles produisent silencieusement des certificats révoqués qui continuent à être acceptés.