Cinq étapes pour sécuriser ACTIVE DIRECTORY

On peut toujours améliorer la sécurité d’AD en automatisant des processus manuels, comme la construction des DC (domain controllers). Mais il n’existe pas encore un langage de programmation capable d’automatiser le comportement humain. C’est pourquoi il faut établir des règles de gestion d’AD par vos administrateurs. Assurez-vous qu’ils respectent les meilleures pratiques suivantes :

Utiliser des comptes administratifs séparés. L’utilisation de comptes administratifs séparés est devenue une pratique standard pour de nombreuses entreprises, mais on peut aller plus loin. Si la machine de l’administrateur se retrouve infectée par un virus, le risque potentiel est bien plus grand parce que, compte tenu des droits administratifs, le virus peut exécuter des programmes ou des scripts. C’est pourquoi les administrateurs doivent utiliser un compte non privilégié (comme un compte utilisateur) pour l’utilisation quotidienne courante et un compte administratif séparé pour effectuer les tâches d’AD privilégiées. On peut utiliser des outils comme la commande Runas pour ouvrir des programmes en tant qu’utilisateur administratif bien qu’on soit connecté avec un compte non administratif. Pour plus de détails sur l’utilisation de la commande Runas, voir le fichier d’aide en ligne Windows.

Utiliser des stations de travail administrateur sécurisées. Malgré les avantages qu’il y a à obliger les administrateurs à se connecter avec des comptes non administratifs et à utiliser des outils comme Runas pour ouvrir les programmes d’administration d’AD, le risque subsiste si le système sous-jacent sur lequel les outils s’exécutent est douteux. Si un assaillant a pris le contrôle de l’ordinateur de l’administrateur à l’insu de ce dernier, le fait d’utiliser des références alternatives procure peu de sécurité : l’assaillant peut en tirer parti. Si vous ne pouvez pas assurer la sécurité des ordinateurs de votre administrateur, il vous faudra créer une station de travail administrateur sécurisée séparée et demander aux administrateurs d’utiliser les services terminaux pour accéder à cette station. Pour sécuriser celleci, vous pouvez la placer dans une OU (organizational unit) spécifique et appliquer des paramètres des stratégies de groupe restrictifs. Et ne négligez pas la sécurité physique. En cas de vol de l’ordinateur d’un administrateur, il faut envisager toutes les conséquences.

Contrôler périodiquement les membres du groupe administratif. Pour obtenir des privilèges élevés, les assaillants ajoutent parfois leur compte à un groupe administratif d’AD, comme Domain Admins, Administrators, ou Enterprise Admins. Sachant cela, il faut surveiller de près les membres des groupes administratifs d’AD. Malheureusement, AD n’a aucun mécanisme intégré permettant d’envoyer des notifications quand les membres de certains groupes changent, mais il est facile d’écrire un script qui énumère les membres des groupes et d’exécuter ce script au moins une fois par jour. Il est aussi judicieux de valider l’audit sur ces groupes parce que vous aurez alors une trace de tout changement survenant dans les journaux d’événements.

Restreindre qui a accès aux mots de passe du compte Administrator. Si un assaillant parvient à obtenir le mot de passe du compte Administrator, il aura d’importants privilèges dans la forêt et ses actions seront difficiles à suivre. Par conséquent, il vaut mieux ne pas utiliser le compte Administrator pour effectuer des tâches d’AD administratives. Il vaut mieux créer des comptes administratifs alternatifs, les ajouter aux groupes Domain Admins ou Enterprise Admins puis utiliser ces comptes pour la plupart des fonctions administratives. Le compte Administrator ne devrait être utilisé qu’en dernier ressort. Et, puisque son utilisation doit être très limitée, le nombre de personnes ayant besoin de connaître le mot de passe devrait l’être tout autant. Et comme tout administrateur peut changer le mot de passe du compte Administrator, pourquoi ne pas aussi surveiller toutes les tentatives de logon pour ce compte.

Avoir une procédure pour changer rapidement le mot de passe du compte Administrator. Même quand on limite l’accès au compte Administrator à une poignée de personnes, il faut pouvoir changer rapidement le mot de passe de ce compte. Ce changement pourrait se faire tous les mois mais, si un administrateur qui connaissait le mot de passe (ou qui avait le droit de le changer) quitte l’entreprise, il faut changer le mot de passe immédiatement. Cette consigne vaut aussi pour le mot de passe DSRM (Directory Services Restore Mode) que l’on définit quand on promeut initialement un DC et des comptes de service possédant des droits administratifs. Le mot de passe DSRM est celui pour le compte administratif que l’on utilise pour se connecter après avoir initialisé dans Restore Mode. Ntdsutil de Windows Server 2003 est un outil ligne de commande simple qui permet de changer ce mot de passe. Lors du changement d’un mot de passe, n’hésitez pas à utiliser des mots de passe aléatoires extrêmement longs (plus de 20 caractères). Il est difficile aux administrateurs de mémoriser de tels mots de passe pour les réutiliser. Une fois le mot de passe défini, donnez-le à un manager qui sera chargé de contrôler qui l’utilise.

Avoir une procédure de désactivation rapide des comptes administratifs. Dans la plupart des organisations d’AD, le plus grand risque vient des administrateurs, particulièrement d’anciens administrateurs revanchards qui auraient une dent contre leurs anciens patrons. Même si vous avez des relations amicales avec un administrateur qui quitte la société, volontairement ou non, vous devez immédiatement supprimer tout l’accès administratif le concernant.