# L'accès que personne n'avait décidé Langue : fr Identifiant : article:vnc-herite-meshcentral Noa Matout Un accès VNC posé par un script oublié, remplacé par une prise en main centralisée avec authentification forte. Ce que j'ai appris sur les accès hérités. Il y avait du VNC sur les postes. Personne ne l'avait décidé récemment, personne ne l'administrait, et personne n'aurait su dire sur combien de machines il tournait. Il avait été déployé par un script, il y a longtemps, et le script avait continué à faire son travail bien après que plus personne ne le regarde. Je l'ai remplacé par une solution de prise en main à distance centralisée, MeshCentral, avec authentification multifacteur. Ce qui m'intéresse ici n'est pas le produit, c'est la catégorie de problème : l'accès hérité. ## Un accès hérité n'est pas un accès mal configuré La différence compte, parce qu'elle change la façon de traiter le sujet. Un accès mal configuré a un propriétaire. Quelqu'un l'a mis en place, sait pourquoi, et peut le corriger. Un accès hérité n'a plus de propriétaire. Il a été posé pour une raison qui était probablement bonne à l'époque, par quelqu'un qui n'est peut-être plus là, avec un outil qui correspondait à l'état de l'art d'il y a dix ans. Depuis, il s'est propagé par le mécanisme même qui l'a installé : un script de masterisation, une image de référence, une tâche de déploiement. Le résultat est un service qui écoute sur un grand nombre de machines, dont l'inventaire n'existe nulle part, et dont la suppression fait peur parce que personne ne sait qui s'en sert. ## Ce que VNC pose comme problème, concrètement Le protocole n'est pas le coupable, son usage par défaut l'est. Le chiffrement n'est pas garanti. Selon l'implémentation et la configuration, une session peut circuler en clair, ce qui veut dire que le contenu de l'écran et les frappes clavier sont lisibles pour quiconque se trouve sur le chemin. L'authentification est liée à la machine, pas à la personne. Un mot de passe par poste, souvent le même partout, parce qu'un déploiement automatisé n'a pas de raison d'en générer un par machine. Personne n'est donc identifiable : on sait que quelqu'un s'est connecté, pas qui. Il n'y a pas de trace exploitable. Ni journal centralisé, ni enregistrement, ni notion de session. En cas de doute sur une intervention, il n'y a rien à consulter. Et surtout, le service écoute en permanence, sur chaque poste, qu'on en ait besoin ou non. La surface n'est pas proportionnelle à l'usage, elle est proportionnelle au nombre de machines. ## Le déclencheur, et ce que j'ai comparé Le durcissement de nos politiques de sécurité. Le service en place était ancien, et rien ne permettait de savoir qui se connectait à quel poste. Ce n'est pas une configuration à corriger, c'est une configuration à remplacer. J'ai testé deux alternatives avant d'arriver à MeshCentral. Une solution libre plus légère, d'abord. Le produit est bon, mais pas assez complet pour un parc de cette taille : ce qui convient à quelques postes ne convient pas à un parc entier, et la différence se paie en administration quotidienne. La prise en main intégrée à Windows, ensuite. Techniquement disponible, et écartée pour une raison d'usage : elle demande trop d'actions au collaborateur avant d'arriver sur son poste. Un outil de support qui exige que l'utilisateur réussisse une manipulation avant qu'on puisse l'aider a un défaut de conception, parce qu'on l'appelle précisément quand il n'y arrive pas. Ma contrainte était la même que pour le bastion : libre et gratuit. Au premier regard, MeshCentral m'a fait peur par sa rusticité. C'est une interface qui ne cherche pas à plaire. En creusant, j'y ai trouvé une solution complète, et j'en tire une règle : sur un outil d'infrastructure, l'austérité de l'interface est un mauvais indicateur de maturité, et parfois le contraire. ## Ce que le remplacement change Le renversement tient en une phrase : le poste ne publie plus un service, il s'enregistre auprès d'un point central. C'est le sens de la connexion qui change, et cela règle plusieurs choses d'un coup. Il n'y a plus de port à exposer sur chaque machine. L'inventaire existe, puisque toute machine gérée est connue de la console. L'identité redevient celle de l'administrateur, avec un compte nominatif et une authentification multifacteur, et non plus un secret partagé par le parc. Les droits deviennent attribuables par groupe de machines et par personne. L'authentification multifacteur est le point qui compte le plus dans ce type de bascule, et ce n'est pas pour la raison habituelle. Une console de prise en main à distance est, par construction, un moyen de prendre le contrôle de n'importe quel poste géré. Elle concentre donc un pouvoir considérable en un seul endroit. Un mot de passe seul sur cette console serait un recul par rapport à la situation d'avant, pas un progrès. ## Ce que j'ai accepté comme contrepartie Comme pour tout point de passage centralisé, il y a un revers, et je préfère le poser que le taire. La console devient une cible de grande valeur. Un attaquant qui l'atteint obtient d'un coup ce qui était auparavant dispersé et difficile à exploiter à l'échelle. Cela se traite : durcissement, mise à jour, séparation des rôles, journalisation, sauvegarde, et authentification forte pour tout le monde sans exception. Mais cela se traite volontairement, pas par défaut. L'agent installé sur les postes est un composant de plus à maintenir. Il faut suivre ses versions, savoir ce qu'il fait quand il perd le contact avec la console, et vérifier qu'il n'introduit pas lui-même un chemin d'exécution à distance mal protégé. Et il faut accepter que la suppression de l'ancien accès soit un projet à part entière, pas une case à cocher. Le service hérité vit sur des machines qui ne sont pas toutes allumées le même jour, ni toutes joignables, ni toutes à jour. ## La méthode que je retiens pour les accès hérités Elle tient en quatre temps, et le premier est le seul qui soit vraiment difficile. **Inventorier avant de décider.** Tant que je ne sais pas sur combien de machines le service tourne et qui s'en sert réellement, toute décision est une opinion. Un balayage du parc et une observation des connexions sur quelques semaines valent mieux qu'une réunion. **Faire coexister les deux chemins.** Le nouvel accès devient le chemin par défaut, l'ancien reste disponible un temps. Chez moi, un mois de recouvrement sur environ 1 300 postes. Le déploiement lui-même a été simple : une stratégie de groupe a poussé le paquet sur tout le parc, et les postes sont remontés dans la console très rapidement. C'est après, une fois la solution éprouvée partout, que j'ai lancé la vague de désinstallation de l'ancien service. L'ordre compte plus que la durée. Déployer le nouveau partout, le laisser vivre, et seulement ensuite retirer l'ancien. L'inverse laisse des machines sans aucun moyen d'accès distant, et ce sont toujours celles qui étaient éteintes le jour de la bascule. **Couper la source avant de couper les instances.** Tant que la stratégie de groupe, l'image ou la tâche qui installe l'ancien service existe encore, chaque nouvelle machine recrée le problème. Nettoyer les postes sans neutraliser le mécanisme de déploiement, c'est vider une baignoire sans fermer le robinet. Chez moi, l'ancien service était déployé par une stratégie de groupe. Je l'ai donc neutralisée d'abord, et lancé la désinstallation sur les postes ensuite. Dans cet ordre, une machine allumée en retard reçoit la désinstallation et non une réinstallation. Détail que je trouve satisfaisant : c'est le même mécanisme qui a servi aux deux. La stratégie de groupe qui avait propagé le problème pendant des années est celle qui a déployé la solution sur tout le parc. **Documenter pour quelqu'un d'autre.** Un accès centralisé que je suis seul à savoir administrer n'est pas une amélioration de la sécurité. C'est le même problème qu'avant, avec un propriétaire unique au lieu d'aucun. ## Ce que ça dit du métier Les deux projets de sécurité qui m'ont le plus appris cette année sont les mêmes au fond. Remplacer les accès VPN des prestataires par un bastion, et remplacer du VNC hérité par une prise en main centralisée, c'est deux fois le même geste : transformer un accès large, anonyme et sans trace, en un accès nominatif, borné et observable. Ce geste ne s'annonce jamais comme un projet de sécurité, d'ailleurs. Il s'annonce comme un projet d'exploitation, parce que c'est comme ça qu'il passe. ## Périmètre de la mesure migratedWorkstations : 1 300 postes. Postes passés à la prise en main centralisée, valeur approchée. coexistenceMonths : 1 mois. Période pendant laquelle l'ancien accès et le nouveau ont coexisté.