Accès VPN par compte de service : certificat ou connexion partagée

Deux conceptions couvrent presque toutes les installations VPN sans surveillance : une connexion humaine partagée conservée dans un script, ou un certificat de machine lié à l’hôte. Elles échouent à des endroits différents, ce qui compte plus que la vitesse d’installation. Un mot de passe stocké casse quand son propriétaire le change ou part ; un certificat casse quand il expire ou quand l’hôte est reconstruit sans la clé. Trois conditions décident du coût que vous pouvez porter, et aucune des deux conceptions ne limite quoi que ce soit tant que la politique d’autorisation ne le fait pas.

Partez de la tâche, pas du compte

La tâche définit la frontière : quelles destinations, quels services, quelles heures, combien de temps une session peut durer. Une route de tunnel n’en est que la moitié. La passerelle décide si la session est autorisée ; la ressource derrière décide de ce que la session peut faire. Écrivez d’abord la liste, avec un propriétaire nommé, car les deux conceptions d’identité doivent la satisfaire.

Gardez l’authentification et l’autorisation séparées pendant que vous l’écrivez. L’authentification répond qui se connecte ; l’autorisation répond ce que la session peut atteindre ensuite. RADIUS transporte la seconde partie sous forme d’attributs comme Filter-Id, Framed-IP-Address, Session-Timeout et Class, et la passerelle les attache une fois la connexion réussie. Une conception qui échange la connexion et laisse l’autorisation intacte n’a rien limité.

Connexion humaine partagée : le mot de passe devient la frontière

Réutiliser un compte humain est le chemin le plus rapide et celui qui vieillit le plus mal. Le secret est un mot de passe, il finit donc dans un script, un fichier d’environnement et une configuration d’ordonnanceur, et chaque copie exige une rotation. Quand le propriétaire le change un vendredi, la tâche échoue à l’exécution suivante et personne ne regarde.

Le MFA est là où cette conception s’effondre généralement. Un script ne peut pas répondre à une demande push, donc le compte est exclu de la politique, et c’est exactement le compte qu’un attaquant choisirait. Les exclusions, les contournements de localisation de confiance et les exemptions par compte se multiplient, et aucune n’est visible pour la personne suivante qui lit les paramètres du locataire.

L’attribution est l’autre coût. Chaque session du journal de la passerelle porte le même nom d’utilisateur, la synchronisation nocturne ne se distingue donc pas du travail de la personne qui l’a écrite, et révoquer la tâche revient à révoquer cette personne.

Certificat de machine : identité liée à l’hôte

Un certificat change la question de ce que le compte sait à ce qu’est l’hôte. Avec EAP-TLS, le client présente un certificat et prouve la possession de la clé privée correspondante ; le serveur de politique mappe le sujet ou le compte d’ordinateur à un groupe et applique la politique de ce groupe. Aucune invite, aucun secret partagé dans un fichier texte.

La frontière qu’il crée est plus étroite qu’on ne l’attend. Un certificat authentifie l’hôte, pas la tâche, et quiconque possède les droits root ou administrateur local peut utiliser cette clé sur cet hôte. Gardez la clé là où la plateforme la protège : non exportable dans le magasin de certificats Windows, adossée au TPM là où le profil le permet, ou un fichier 0600 appartenant à root sous Linux. Compromettre l’hôte, c’est compromettre le secret.

L’expiration est la panne récurrente. Un certificat qui expire un dimanche arrête la tâche le dimanche, et la passerelle signale généralement un échec d’authentification générique au lieu de nommer la date. Vérifiez les dates depuis l’hôte de la tâche dans le runbook :

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

La révocation exige un chemin que la passerelle vérifie. OpenVPN lit une CRL via l’option crl-verify, et strongSwan dépend de CRL ou OCSP selon la construction du profil de connexion. Si ni l’un ni l’autre n’est branché, retirer un hôte signifie attendre l’expiration du certificat.

Trois conditions qui décident entre les deux

Faites la comparaison avec la plateforme que vous avez, pas avec une conception de référence.

Première condition : la passerelle peut-elle autoriser une identité de machine ? Si elle ne fait que mapper un nom d’utilisateur RADIUS à un utilisateur d’annuaire, un certificat authentifie l’hôte puis cale à l’autorisation. Deuxième condition : la tâche a-t-elle besoin d’un accès à une ressource que seul un compte utilisateur porte, comme un partage monté ou une licence par poste ? Alors une identité de machine ne peut pas se substituer, et la réponse honnête est un compte utilisateur dédié avec une politique restreinte. Troisième condition : qui peut faire tourner le secret sans personne dans la boucle ? L’enrôlement automatique rend les certificats peu coûteux à garder ; un mot de passe connu d’une seule personne, non.

Lisez le tableau comme une liste de coûts, pas comme un classement. La colonne du secret stocké gagne en vitesse de révocation et en compatibilité avec les ressources qui ne comprennent que les comptes utilisateurs ; la colonne du certificat gagne en rotation et en n’affaiblissant pas le MFA pour faire fonctionner un script.

Placez la limite dans la politique, après l’authentification

Quelle que soit l’identité choisie, la limite de permissions appartient à la politique qui s’exécute après l’authentification. Dans NPS, les politiques réseau sont évaluées dans l’ordre et la première politique qui correspond à chaque condition applique ses paramètres, si bien qu’une politique large placée au-dessus d’une politique étroite décide du résultat, quoi que présente le client. Microsoft documente le modèle de conditions et de paramètres dans sa présentation des politiques NPS.

Donnez à la tâche son propre groupe ou sa propre condition de politique, fondé sur ce que porte l’identité de machine : un modèle de certificat, un identifiant de station appelante ou une adresse d’un pool dédié. Encadrez ensuite la session par des attributs : un Filter-Id pour le rôle auquel votre passerelle la mappe, un Session-Timeout court pour qu’une tâche bloquée se réauthentifie au lieu de tenir une session pendant des jours, et une Framed-IP-Address d’un pool que vous filtrez de l’autre côté. L’autorisation applicative reste séparée : un tunnel vers un serveur de base de données n’est pas l’autorisation de lire une table à l’intérieur.

Vérifiez les refus, puis planifiez le retrait

Un accès qui fonctionne ne prouve rien sur le moindre privilège. Testez plutôt les refus : connectez-vous avec l’identité de la tâche et tentez d’atteindre une destination hors de la liste, ouvrez une seconde session simultanée si la passerelle ne doit en autoriser qu’une, et répétez la connexion après révocation du secret.

Confirmez ensuite la même session à deux endroits. Le journal de la passerelle montre l’identité qui s’est authentifiée ; le journal du serveur de politique montre quelle politique a correspondu et quels attributs elle a renvoyés. Sur OpenVPN, le serveur enregistre le nom commun du certificat, et ipsec statusall sur strongSwan affiche le tunnel établi avec l’identité utilisée. Si les deux journaux ne s’accordent pas sur l’identité, la politique correspond à autre chose que ce que vous supposez.

Le retrait fait partie de la conception, pas d’un sprint de nettoyage. Écrivez tout ce qu’il faut supprimer (certificat ou compte, appartenance à un groupe, politique réseau, entrée de pool, règle de pare-feu sur la cible) et exécutez-le une fois pendant que la tâche est facile à reconstruire.

Si vous commencez aujourd’hui, travaillez dans cet ordre : écrivez la liste des ressources, choisissez l’identité avec les trois conditions, placez la limite dans la politique et exercez un refus avant la mise en service.