Systèmes obsolètes dans Active Directory : inventorier, isoler et tenir un registre d'exceptions

Pourquoi un système obsolète est un risque pour tout le domaine

Une machine en fin de support ne reçoit plus de correctifs de sécurité : les vulnérabilités découvertes après la date de fin de support restent ouvertes indéfiniment. Mais le problème dépasse la machine elle-même. En tant que membre du domaine, elle manipule des identités : elle met en cache des identifiants, elle participe aux protocoles d'authentification, elle fait confiance aux mêmes contrôleurs de domaine que les serveurs critiques. Un attaquant qui prend pied sur un vieux serveur se trouve déjà à l'intérieur, dans une position où il peut tenter de récupérer des secrets ou de rebondir.

Les systèmes anciens posent aussi un obstacle au durcissement général : ils sont souvent la raison invoquée pour maintenir des protocoles affaiblis, comme d'anciennes versions de TLS, le chiffrement RC4 pour Kerberos ou NTLM. Un seul système obsolète peut ainsi retarder la modernisation de tout le domaine.

Inventorier à partir de l'annuaire

Active Directory lui-même fournit un premier inventaire. Chaque objet ordinateur porte les attributs operatingSystem et operatingSystemVersion, renseignés par la machine lors de son authentification. Un filtre sur ces attributs donne la liste des systèmes serveur et client, par version. Deux précautions :

• ces attributs ne sont fiables que si l'objet est encore utilisé : croisez-les avec l'attribut lastLogonTimestamp pour écarter les objets dormants, qui relèvent d'un nettoyage et non d'une isolation ;
• certains équipements (appliances, systèmes non Windows joints au domaine) renseignent ces champs de façon approximative : l'inventaire de l'annuaire doit être recoupé avec celui de la gestion de parc.

Au terme de l'exercice, vous disposez d'une liste nominative des machines concernées, de leur rôle supposé et de leur dernière activité. C'est le point de départ de toute décision.

Décider : migrer, retirer ou isoler

Pour chaque système identifié, trois issues sont possibles.

1. Migrer vers une version prise en charge : c'est toujours l'objectif, même quand il paraît lointain. Une application réputée incompatible l'est souvent moins qu'on ne le croit une fois le projet lancé.
2. Retirer : nombre de ces machines ne servent plus réellement et peuvent être décommissionnées. C'est le meilleur résultat.
3. Isoler lorsque le maintien est inévitable à court terme : c'est une mesure de réduction du risque, pas une solution.

Isoler correctement

Isoler ne consiste pas seulement à « mettre dans un VLAN à part ». Une isolation sérieuse combine plusieurs mesures : filtrage réseau strict n'autorisant que les flux applicatifs indispensables, interdiction d'ouvrir des sessions privilégiées sur ces machines pour ne pas y exposer d'identifiants sensibles, retrait des comptes d'administration de haut niveau de leurs administrateurs locaux, et surveillance renforcée. Lorsque c'est possible, placer ces systèmes dans des unités d'organisation dédiées facilite l'application de stratégies spécifiques et la revue périodique. L'idée directrice : si la machine tombe, l'attaquant doit y rester confiné.

Tenir un registre d'exceptions

Chaque système obsolète maintenu doit faire l'objet d'une dérogation formelle, consignée dans un registre. Pour chaque entrée : la machine, la justification métier, le risque accepté, les mesures de compensation en place, un propriétaire nommé et une date de réexamen. Ce registre transforme une accumulation subie en décisions explicites et datées. Il rend visible la dette, la met devant les responsables qui l'assument, et évite qu'une exception « provisoire » accordée il y a cinq ans ne soit oubliée. C'est aussi un élément attendu par la plupart des référentiels de conformité.

Ce qu'un audit vérifie

• L'inventaire des systèmes en fin de support, issu de l'annuaire et recoupé avec la gestion de parc.
• La présence éventuelle de contrôleurs de domaine sous un système non supporté.
• Les protocoles affaiblis maintenus à cause de ces systèmes.
• Les mesures d'isolation réellement appliquées, au-delà de la simple séparation réseau.
• L'absence d'identifiants privilégiés exposés sur ces machines.
• L'existence d'un registre d'exceptions à jour, avec propriétaire et date de réexamen.