Des identités VPN individuelles pour une petite équipe, sans annuaire

Six personnes partagent un identifiant VPN, l’une d’elles s’en va, et le seul moyen de retirer son accès est de changer le secret que tout le monde utilise. C’est là le vrai problème, et il ne faut pas Active Directory pour le résoudre. Un petit bureau peut conserver des identités distinctes dans le magasin local que sa passerelle prend en charge et traiter malgré tout les départs comme une routine. Le travail consiste à choisir le magasin et à écrire les étapes de retrait avant d’en avoir besoin.

Commencez par l’identifiant que chacun détient

Listez ce avec quoi chaque personne se connecte avant de choisir un backend. Un portable, un téléphone, peut-être un poste fixe à la maison, et chacun de ces éléments est un identifiant distinct ou un certificat d’appareil distinct. Si vous ne pouvez pas nommer l’identifiant qu’une personne détient, vous ne pourrez pas le retirer plus tard.

Deux personnes qui partagent un profil est le cas qui rend chaque étape suivante plus difficile. Réglez cela d’abord, car aucun annuaire ne résout un secret partagé.

Choisissez le magasin que la passerelle prend réellement en charge

Choisissez le magasin d’identités que la passerelle prend déjà en charge, plutôt que celui que vous aimeriez exploiter. Une passerelle dotée d’une base d’utilisateurs locale peut conserver des comptes individuels avec une politique par utilisateur. Un déploiement IKEv2 peut associer une identité EAP à un secret précis, à condition que la méthode du client et le vérificateur concordent. Les configurations à base de certificats peuvent émettre un certificat par appareil depuis une autorité commune, ce qui garde l’ancre de confiance partagée tandis que les identifiants restent distincts.

L’emplacement du magasin compte moins que ses opérations : enrôlement, sauvegarde, renouvellement et révocation. Si l’une de ces opérations n’a pas de réponse, le choix n’est pas terminé.

Si la passerelle propose à la fois des comptes locaux et des certificats, préférez celle que votre équipe peut exploiter à deux heures du matin sans le fournisseur au téléphone. Cette préférence concerne le temps de rétablissement, pas la question de savoir quelle option est techniquement la plus solide.

Séparez la personne des appareils

Décidez ce que représente un identifiant : une personne, un appareil, ou les deux. Un portable et un téléphone appartenant à un même salarié sont deux appareils et une personne, et perdre le téléphone ne devrait pas nécessairement désactiver le portable. Écrivez ce modèle, car il détermine ce que signifie le retrait.

Consignez le propriétaire, l’appareil, la date d’émission et le chemin de révocation de chaque identifiant. Gardez ce registre là où le bureau peut le lire sans la personne qui l’a mis en place. Un tableau avec ces quatre colonnes suffit pour six personnes et passe encore à soixante.

Faites du retrait une opération ordinaire

Écrivez la procédure de départ avant le premier départ. Désactivez l’identité, terminez toute session active et confirmez que le tunnel tombe réellement au lieu d’attendre un minuteur de réauthentification. Vérifiez ensuite que l’ancien identifiant échoue depuis une machine hors du réseau du bureau. Toute la séquence devrait prendre quelques minutes et n’exiger aucune réémission pour quiconque.

sudo swanctl --terminate --ike alice-laptop

Conservez un chemin de récupération administrateur qui ne dépend pas du compte désactivé et réconciliez les comptes locaux qui migreront plus tard vers un annuaire. L’objectif est simple : retirer une personne est une tâche de routine, pas un projet qui touche le profil de tous les autres. L’authentification locale d’Access Server est un exemple documenté d’un magasin qui correspond à cette forme.