Sécurisation des comptes admin : une complexité fractale

Le corpus de règles est assez mince. En voici la liste :

• principe du moindre privilège : tout compte utilisateur du SI ne doit posséder que le niveau de privilèges strictement nécessaire à sa mission ;
• séparation des comptes : un utilisateur doit disposer d’un compte utilisateur distinct de son compte à privilèges ;
• gestion des comptes d’administration de domaine (ou de plus hauts privilèges) : nécessité de gérer les arrivées et les départs, le processus d’attribution, les audits, etc. ;
• un compte à hauts privilèges ne dispose pas d’accès à l’Internet ;
• les comptes à privilèges ont une politique spécifique de mot de passe.

La plupart de ces mesures sont décrites en long et en large dans l’excellent guide des mesures d’hygiène de l’Anssi (version 2017).

Outre le fait que ces cinq règles donnent du boulot à un RSSI pendant des années – et des sueurs froides à ceux qui sont chargés de les appliquer –, quand on creuse un peu, on se rend rapidement compte de certaines nuances, et d’un périmètre au contour pas si net. A priori, quand on pense « compte à privilèges », on pense à l’administrateur système, le hipster maigrichon au fond de la salle informatique, avec un tee-shirt métalleux et des figurines de Yoda sur son unité centrale. Certes, mais ce n’est pas le seul : il y a aussi le chef de projet applicatif qui dispose de droits étendus sur les serveurs (physiques ou virtuels) des applications qu’il prend en charge, les petits jeunes de la hot line (faut bien qu’ils prennent la main sur les PC des utilisateurs), mais aussi certains utilisateurs « power users »qui ont des missions spécifiques telles la formation au DPI, l’assistance fonctionnelle de premier niveau, etc. La première difficulté relève donc de la diversité des situations.

Ensuite, tout le monde fantasme sur la gestion des comptes d’administration système du hipster du dessus : en fait, c’est de loin le plus simple. Un compte admin nominatif par ingénieur système sans accès Internet, un compte utilisateur sans privilèges particuliers, un processus (écrit) d’attribution et de révocation des comptes, et une petite revue annuelle. Oui, OK, vos admin vont vous expliquer qu’il est impossible de jongler avec deux comptes, que cela les empêche de travailler, et patati et patata : ils mentent comme des arracheurs de dents : on le fait, point. Et leurs seuls droits, ce sont des droits d’administration de machines (serveurs, routeurs, baies de disques, etc.) : en gros, tous les droits, mais machine par machine. Petite cerise sur le gâteau : en principe, on a des mots de passe complexes (majuscules, minuscules, lettres, chiffres et caractères spéciaux) et d’au moins 12 caractères, voire 16.

La gestion du compte « super-super » admin est un peu plus compliquée : il y a bien un compte admin de domaine qui existe avant tous les autres (l’équivalent de Dieu dans les religions de tout poil). Là, il va falloir prendre quelques précautions : un mot de passe très long et complexe, dans une enveloppe cachetée, le tout stocké dans un coffre-fort (physique ou virtuel) qui trace les accès et dont la clé est détenue par deux ou trois personnes au plus. Et j’allais oublier : il y a non pas un, mais deux comptes qui doivent être gérés de la sorte : l’admin originel du domaine, et l’admin de la forêt AD (le compte qui peut tout modifier dans l’AD). Bon, jusque-là, on s’en sort sans trop de casse.

Cela se complique encore avec les comptes des ingénieurs fonctionnels. Dans la terminologie du présent article, ce ne sont pas des comptes « à hauts privilèges », mais simplement « à privilèges » dans la mesure où ils ne peuvent pas (en principe) créer d’autres comptes à privilèges. Le principe du moindre privilège est carrément plus complexe à mettre en œuvre puisque des variations existent d’un progiciel à l’autre, d’un serveur à l’autre, etc.

Une question délicate est celle du niveau de privilèges au-dessus duquel un utilisateur va devoir disposer de deux comptes (le sien en tant qu’agent, plus celui à privilèges). S’il n’y a pas débat pour l’admin système (vu ses habilitations, il en faut forcément deux), pour certains, c’est plus nuancé : si un agent de la hotline n’a « que » le droit d’effectuer une prise en main à distance des PC des utilisateurs, voire est admin local des PC pour pouvoir installer/désinstaller des logiciels, le besoin de deux comptes est plus discutable. D’autant que ces comptes, il va falloir les suivre, les comptabiliser, les révoquer, etc.

Le nerf de la guerre – ou l’un d’eux en tout cas –, c’est la gestion des groupes dans l’AD. Un simple audit d’un AD avec un produit tel que Varonis, ou PingCastle, vous sort des schémas en graphes ou apparaissent assez rapidement des autoréférences (des groupes qui en contiennent d’autres qui les contiennent à leur tour), voire des comptes qui, par héritages complexes, disposent de droits très étendus (souvent sans que l’agent lui-même en soit conscient).

Curieusement, la gestion de l’AD est souvent prise à la légère, alors que c’est de loin le composant le plus sensible du SI. Ce n’est pas pour rien que les attaques de TV5 Monde (entre autres) sont passées par là.