Sécuriser l'Active Directory de l'établissement de santé

L'Active Directory (AD) est une technologie de Microsoft, qui comporte trois fonctions principales au sein d’un système d’information (SI) :

  • base d’annuaire ;
  • base de contrôle d’accès ;
  • base de gestion de parc machines et serveurs.

C’est le composant du SI qui porte l’authentification et les autorisations d’accès de tous les utilisateurs, c’est pourquoi sa sécurisation est une nécessité absolue. Se rendre maître de l’Active Directory permet notamment l’obtention du droit total sur toutes les ressources et le droit sur tous les accès utilisateurs. En somme, la compromission de l’Active Directory signifie la compromission de tout le système d’information. Or, l’AD est une technologie très fréquente dans les établissements de santé français. Ceci est lié au fait que les DSI ont fait le choix de parc de postes de travail essentiellement sous Windows.

Description du fonctionnement de l’Active Directory

Il est impossible de décrire de manière exhaustive le fonctionnement de l’AD dans le cadre de cet article. Décrivons simplement quelques notions essentielles (nous n’expliquerons pas par exemple les notions de forêt et de liens d’approbation).

La notion de domaine : un ensemble de machines et d’utilisateurs partageant le même annuaire Active Directory.

La notion de contrôleur de domaine : « Un serveur hébergeant l'annuaire Active Directory est appelé « contrôleur de domaine ». Active Directory stocke ses informations et paramètres dans une base de données distribuée sur un ou plusieurs contrôleurs de domaine » (source : Wikipédia)

Il existe plusieurs protocoles d’authentification. Du plus ancien au plus récent, citons : LM hash, NTLM et Kerberos.

Focus sur le LM Hash :

LM hash, ou LAN Manager hash est un format développé par Microsoft pour stocker les mots de passe utilisateur qui ont moins de quinze caractères. Il est utilisé dans les premières versions d’Active Directory.

Le principe de fonctionnement est le suivant :

  • Le mot de passe est séparé en deux éléments de 7 caractères.
  • Si le mot de passe a une longueur inférieure à 14 caractères il est complété par des caractères nuls.
  • Le hash de chaque élément est calculé séparément.
  • Les deux hashs concaténés forment le hash LM.

Par ailleurs, le format LM ne gère pas la casse. Tous les caractères minuscules sont remplacés par des caractères majuscules.

Ce mode de fonctionnement a autorisé la mise en place d’attaques faciles et rendues triviales par des outils comme les Rainbow Tables. Les protocoles plus récents (type Kerberos) sont désormais fortement recommandés.

Analysons maintenant 3 scénarii de risques autour de l’Active Directory.

RISQUE 1 : Rétrocompatibilité sur les domaines Windows

Microsoft autorise la rétrocompatibilité au sein d’un domaine Windows, ce qui permet par exemple d’héberger un serveur Windows 2003 dans un domaine Active Directory 2016. Cette rétrocompatibilité est très utile aux établissements de santé pour faire cohabiter des applications métiers de différents âges, s’appuyant parfois sur des OS obsolètes.

Problème principal : il faut maintenir des protocoles anciens comme le LM hash pour les mots de passe. Or, comme nous l’avons vu plus haut, ce type de protocole est très vulnérable.

L’existence d’applications se reposant sur des OS anciens est donc clairement une menace pour le domaine Windows et donc tous les accès utilisateurs de l’établissement. Même si les critères métiers et fonctionnels restent prépondérants dans le choix d’une application, les éditeurs se doivent de prendre en compte cette menace et de proposer des spécificités techniques à jour.

Les DSI sont alors amenés à gérer une transition en douceur, en sortant les applications obsolètes une par une. Mais même une fois les OS en cohérence avec un niveau de domaine Active Directory récent, le protocole est mis à jour uniquement au changement du mot de passe. Ce qui veut dire qu’il leur faut renouveler tous les mots de passe créés en LM pour les voir utiliser un protocole plus récent et plus robuste. Cette opération est évidemment risquée sur les comptes de service des applications.

La rétrocompatibilité offerte par l’Active Directory est donc une arme à double tranchant pour les DSI des établissements de santé.

RISQUE 2 : l’administrateur du domaine

Le meilleur ennemi d’un domaine Windows est son administrateur. Ce type de compte a tous les droits sur le domaine : révocation et création d’utilisateur, changement possible de tous les mots de passe etc… Alors que multiplier les comptes administrateurs du domaine et leur laisser la possibilité de se connecter sur n’importe quel poste de travail peut paraître pratique, c’est en fait un vecteur d’attaque idéal.

Mettons-nous en situation : un administrateur du domaine utilise son compte administrateur sur son poste de travail au quotidien. Pour réaliser ses gestes d’administration sur le domaine Active Directory… mais aussi pour ouvrir sa messagerie, naviguer sur internet, ouvrir des applications métiers, l’intranet etc… Un compte utilisateur simple, aux accès restreints pourrait suffire pour réaliser ces dernières tâches. Oui, mais cela signifierait nécessiterait que notre administrateur utilise deux comptes différents pour se connecter : un accès utilisateur et un accès administrateur. Pas pratique à gérer au quotidien !

Imaginons désormais le scénario catastrophe (et déjà vécu par des établissements de santé) : l’administrateur du domaine ouvre un cryptovirus via sa messagerie, avec ses accès et droits administrateur. Le cryptovirus se propage sur le poste de travail mais aussi sur tous les répertoires réseaux accessibles à l’administrateur, donc potentiellement toutes les ressources du domaine… dont l’AD même. C’est le système d’information entier va être bloqué, l’Active Directory complétement compromis, AD qu’il faudra reconstruire complétement. Ce sont plusieurs jours d’indisponibilités garantis !

Des règles d’hygiène spécifiques aux administrateurs du domaine sont à respecter selon l’ANSSI : voir les recommandations de l'ANSSI

Plus globalement, l’administrateur du domaine se doit d’être un utilisateur vigilant, formé et sensibilisé. A grand pouvoir, grandes responsabilités.

RISQUE 3 : le contrôleur de domaine

Même s’ils sont des serveurs sous Windows, les contrôleurs de domaine ne sont pas des serveurs comme les autres. Portant la base de données d’Active Directory et les fonctionnalités inhérentes, les accès doivent être limités et la surface d’attaque réduite au maximum.
En quelques lignes, voici les bases du durcissement d’un Active Directory. Pour plus de détails, nous vous renvoyons au document de l’ANSSI :

  • segmentation réseau ;
  • durcissement OS ;
  • patch management ;
  • réduction de la surface d’attaque : aucun autre logiciel autorisé.

« Aucun autre logiciel autorisé » … ce qui pose la question de l’antivirus : faut-il en installer ce type d’outil sur un Active Directory ?

L’antivirus peut être perçu comme le dernier rempart face à un malware mais aussi un vecteur d’attaque supplémentaire. Ce n’est après tout qu’un logiciel, faillible comme les autres, avec ses erreurs de code. Combien de chevaux de Troie ont-ils utilisé les failles d’un antivirus pour infiltrer un SI ? Un peu trop à notre goût…

Alors, antimalware or not antimalware ? Pour le RSSI, la réponse est dans le contexte de son SI. Les défenses périmétriques autour de l’AD sont-ils suffisants ? Les accès sont-ils suffisamment restreints ? Les administrateurs du domaine sont-ils suffisamment vigilants et formés ? Y a-t-il déjà un passif avec les antivirus ? Le RSSI agira en gestionnaire du risque pour déterminer les meilleures mesures à prendre.

Les 3 scénarii présentés sont représentatifs du risque encouru par une absence de maîtrise et un manque d’expertise sur une technologie, l’Active Directory, indispensable aux établissements de santé. Les guides de l’ANSSI et de Microsoft sur le sujet sont une lecture nécessaire pour une prise en compte du sujet et pour se poser les bonnes questions.

Article rédigé par Christophe Jodry, Directeur des offres eSanté et PCIDSS chez Claranet.

Webographie :