VPN pour un petit bureau : tenez-le à l’écart du contrôleur de domaine

Trois conditions décident si l’unique serveur Windows du bureau doit aussi terminer le VPN : combien de logiciels exposés à internet vous êtes prêt à exécuter sur l’annuaire, si vous pouvez authentifier des utilisateurs distants sans ce rôle, et ce qui arrive à votre accès de gestion lorsque l’hôte redémarre. Si l’une des trois a une mauvaise réponse, séparez les rôles. La petitesse du bureau change le budget, pas le risque.

Chaque machine du domaine fait confiance à un contrôleur de domaine ; une passerelle VPN est joignable par n’importe qui sur internet. Cette asymétrie est tout l’argument.

Deux tâches aux deux profils d’exposition différents

La passerelle accepte des connexions de l’extérieur, donc son écouteur, sa pile TLS et sa surface d’authentification sont tous joignables depuis des réseaux non fiables. L’annuaire détient une autorité à laquelle d’autres machines font confiance, c’est pourquoi les recommandations de durcissement de Microsoft traitent le rôle de contrôleur de domaine et son environnement d’hébergement comme particulièrement sensibles. Chaque service ajouté à cet hôte hérite de la position de confiance de l’annuaire tout en ajoutant sa propre surface d’attaque. La commodité d’installation n’est pas une frontière de confiance.

Séparer les rôles ne supprime pas les dépendances. Les utilisateurs distants ont toujours besoin d’authentification, de routes, de DNS et de règles d’accès, et une passerelle qui les ignore n’est pas plus sûre, seulement moins utile.

Authentification sans le rôle d’annuaire

Une passerelle peut valider des identifiants par une intégration externe prise en charge sans héberger l’annuaire lui-même. Quelle que soit cette intégration, donnez-lui un compte dont les droits correspondent à l’objectif : lire les attributs nécessaires à l’authentification, rien de plus. Admettre des utilisateurs VPN n’exige jamais de transformer leurs comptes ordinaires en administrateurs de domaine, ni que la passerelle détienne une copie de l’annuaire.

Limitez ensuite les chemins réseau dont le client distant a réellement besoin. L’accès à un service de fichiers interne, plus les services de résolution de noms et d’identité dont dépend ce flux de travail, est un ensemble défini de chemins. Ce n’est pas une raison d’autoriser chaque port du contrôleur de domaine ni chaque interface administrative depuis la plage VPN.

Un seul hôte reste un seul domaine de défaillance

Deux invités sur un même hyperviseur séparent leur configuration de système d’exploitation et ne séparent pas leur sort. Les administrateurs de l’hyperviseur, la commutation virtuelle, le stockage et les sauvegardes restent partie de la conception, et un redémarrage de l’hôte retire les deux services à la fois. Appeler cela haute disponibilité parce que le schéma montre deux VM est une erreur courante et coûteuse. Si le seul chemin de retour passe par le VPN sur cet hôte, une défaillance emporte la connexion nécessaire pour le réparer.

Planifiez donc une voie de gestion indépendante qui ne dépend pas du tunnel, et notez ce qui reste disponible pendant la maintenance. Planifiez séparément les mises à jour de la passerelle et la maintenance de l’annuaire, en notant quels utilisateurs ou applications chaque interruption touche.

Une fenêtre de maintenance qui exige que le VPN soit actif pour réparer le VPN n’est pas une fenêtre de maintenance.

Déplacez-le sans vous enfermer dehors

Si les rôles partagent déjà une installation, évitez une migration distante précipitée. Inventoriez ce que la passerelle possède aujourd’hui : adresses, règles de transfert, NAT, réglages DNS, configuration d’authentification et tout service publié. Préparez à la fois le remplacement et un chemin de retour avant de déplacer l’écouteur ou de modifier une route par défaut. Testez ensuite le travail réel d’un utilisateur distant ordinaire à travers la nouvelle frontière, et confirmez que l’accès administratif inutile échoue toujours.

L’objectif n’est pas un schéma plus joli. C’est la capacité de réparer ou de reconstruire le VPN sans toucher la machine qui ancre la confiance de l’annuaire pour tout le bureau. Ce sont des objectifs différents, et un seul d’entre eux a besoin d’un second serveur.

Consignez la décision dans tous les cas, y compris les conditions qui la rouvriraient. Un petit bureau grandit, et la réponse adaptée à un serveur ne conviendra peut-être pas au suivant.