Une connexion VPN n’accorde pas de droits d’administrateur local

Trois choses se confondent quand quelqu’un demande si le VPN professionnel donne à l’entreprise des droits d’administrateur sur un PC personnel : l’accessibilité, l’installation de logiciels et la gestion de l’appareil. Une connexion VPN fournit la première, le paquet client apporte la seconde, et seule une inscription distincte procure la troisième. Le mécanisme derrière chacune est différent, et une seule implique un identifiant Windows.

Rien dans un tunnel ne transforme un compte de domaine en compte local.

Un chemin réseau, pas un identifiant

Un tunnel rend les ressources de l’entreprise accessibles et peut fournir un chemin vers le client lui-même, sous réserve du routage, de l’isolation du client et des filtres d’hôte. Il ne crée pas de compte Windows local, n’élève pas un compte existant et n’ajoute personne à un groupe local. Un service qui écoute sur la machine conserve sa propre politique d’admission, quel que soit le réseau d’où vient la requête. C’est pourquoi les partages exposés et les points de gestion à distance ont toujours besoin d’une protection délibérée.

La portée du tunnel est une question distincte : un tunnel complet transporte plus de trafic applicatif qu’un tunnel fractionné, et aucune des deux portées ne donne accès aux fichiers du disque.

Le client est un paquet, pas un tuyau

Les clients d’entreprise sont modulaires. Un déploiement peut inclure le tunnel ainsi que des composants de posture, de filtrage ou de sécurité, chacun avec sa propre configuration et son propre comportement de collecte. Déduire l’ensemble installé à partir du nom du produit ou d’une icône connectée relève de la devinette. Ces composants peuvent suivre leur propre politique de module plutôt que la durée de vie d’une session, si bien que déconnecter le tunnel n’est pas un bouton d’arrêt universel.

Un inventaire des composants installés répond à une autre question que celle à laquelle répond l’icône connectée.

Les scripts s’exécutent sous votre identité, pas en root

Le scriptage côté client existe et mérite d’être compris : des crochets documentés de connexion et de déconnexion peuvent s’exécuter pendant une session, et ils restent désactivés sauf si le profil et le déploiement les activent. Sous Windows, ils s’exécutent dans les restrictions de sécurité existantes de l’utilisateur, donc ils ne peuvent appeler que ce à quoi cet utilisateur a droit. Activer un crochet est une capacité supplémentaire réelle ; le décrire comme une attribution automatique d’administrateur n’est pas exact.

La distinction compte dans les deux sens. C’est plus qu’un tuyau passif, et moins qu’un compte d’administrateur de domaine.

La livraison et les mises à jour sont la véritable frontière de confiance

Celui qui contrôle le paquet et le canal de mise à jour a plus d’autorité qu’un site auquel vous avez donné un mot de passe, car il peut changer ce qui s’exécute sur la machine. C’est une raison légitime d’examiner comment le client est livré et mis à jour avant de l’installer. Ce n’est toujours pas la même opération que rejoindre un domaine ou s’inscrire à la gestion, qui restent des relations distinctes avec leur propre statut visible.

Si l’organisation exige un appareil géré, utilisez son dispositif approuvé pour appareil de travail plutôt que de supposer qu’un client personnel peut fournir ce statut. Si la machine est déjà inscrite, déconnecter le tunnel n’annule pas l’inscription.

Demandez un inventaire de ce qui est installé et de qui contrôle ses mises à jour. Cette question a une réponse ; la rassurance n’en a pas.