Protéger les comptes à privilèges dans son SI

Véritables pièces maîtresses du SI, ils peuvent, entre de mauvaises mains, compromettre tout ou partie des données de l’entreprise, enrayer son bon fonctionnement et porter une grave atteinte à son image. Dans un monde ouvert où les menaces viennent tout autant de l’intérieur que de l’extérieur de l’entreprise, ces derniers remparts du SI doivent être drastiquement protégés et contrôlés.

Des menaces permanentes, à l’extérieur comme à l’intérieur de l’entreprise

Le piratage et le vol de données informatiques semblent s’être inexorablement installés en une de nos blogs et de nos journaux: sites Web marchands, industriels, Etats ou entreprises privées, toute organisation apparaît désormais comme une cible potentielle. En 2013, l’affaire « Snowden », avec les retentissements médiatiques et diplomatiques que l’on sait, a ainsi démontré que même la NSA, l’Agence Nationale de Sécurité de la première puissance économique et militaire du monde, pouvait se faire subtiliser des données ultra-sensibles et éminemment confidentielles, avec une simple clé USB placée dans les mains d’un administrateur systèmes travaillant pour un prestataire externe.

Si un tel vol de données a été possible dans le Système d’Information de la NSA, les responsables informatiques du monde entier peuvent légitimement avoir quelques craintes ou au moins quelques doutes sur la sécurité de leurs propres SI, surtout en vérifiant par cette piqûre de rappel médiatique que la menace peut aussi venir de leurs propres collaborateurs et partenaires. En sa qualité d’administrateur systèmes, Edward Snowden possédait en effet des accès privilégiés, c’est à dire des comptes informatiques lui permettant d’accéder à des serveurs, des répertoires, des applications et des données sensibles. Comme tout administrateur systèmes, Edward Snowden devait ainsi posséder des comptes nominatifs et/ou requérant une authentification forte personnelle (par exemple par carte à puce ou par un système biométrique), mais probablement aussi un certain nombre de comptes partagés avec d’autres administrateurs et protégés par de simples mots de passe. Car cela peut paraître paradoxal à une époque où tout un chacun peut protéger son compte Gmail par un code à usage unique transmis par SMS, mais de très nombreux composants des SI ne voient souvent leurs accès restreints que par une simple chaîne de caractères : comptes root Unix, administrateurs locaux de serveurs Windows ou de domaines Active Directory, administrateurs Sharepoint, sysadmin de bases de données etc.

(((IMG6765)))
Authentification en deux étapes par code SMS pour les services Google.

Les limites des solutions décentralisées (Excel, Keepass, etc.)

Tout administrateur informatique sait à quel point la liste de ces comptes et de ces mots de passe peut être longue, et se pose alors la question de leur stockage et de leur référencement. Or, si beaucoup de responsables de SI prétendront le contraire, nombreuses sont encore les équipes d’administrateurs qui stockent cette liste dans un simple fichier Excel, le plus souvent protégé par les seuls restrictions d’un partage Windows. Une autre solution très répandue : les coffres chiffrés, tels que ceux proposés par le logiciel Open Source Keepass, très populaire chez de nombreux informaticiens. Bien entendu, dans des Systèmes d’Information un tant soit peu conséquents, Excel et Keepass ne sont pas des solutions viables. D’une part parce que leur caractère décentralisé fait qu’un fichier de mots de passe peut, plus ou moins facilement, se retrouver sur une clé USB à partir de laquelle un pirate aura tout le temps et le loisir de tenter de casser la passphrase permettant de déchiffrer le fichier. D’autre part, le caractère le plus souvent partagé des comptes  à privilèges fait qu’il est difficile de les organiser sous formes de fichiers : ainsi, si Pierre, un interne, doit avoir accès aux comptes administrateurs Windows et aux comptes admin des boîtiers Cisco, peut-être que Paul, prestataire externe, ne doit avoir accès qu’aux seuls comptes administrateurs Windows. On pourra bien entendu penser à créer deux fichiers Keepass ou Excel distincts en fonction des périmètres technologiques, mais que faire si Jacques, stagiaire, ne doit avoir accès qu’à un seul des comptes administrateurs Windows ?

(((IMG6766)))
Keepass, coffre chiffré de mots de passe.

La sécurité apportée par les solutions centralisées

Ce problème de granularité est adressé par les éditeurs de solutions Web centralisées de gestion des comptes à privilèges (Shared Account Password Management en anglais).

On peut notamment citer Thycotic Secret Server, CyberArk Enterprise Password Vault, ManageEngine Password Manager ou encore Quest One Privileged Password Manager. Avec de telles solutions, l’accès aux comptes à privilèges peut être régi par des règles très fines : par exemple, seul Pierre pourra visualiser le mot de passe du compte root d’un serveur donné ou bien encore seuls les utilisateurs possédant le rôle « groupe de support des bases de données » pourront accéder au compte sa de MS SQL Server, mais sans pour autant pouvoir changer son mot de passe, droit qui sera réservé aux seuls utilisateurs dans le rôle « groupe des administrateurs des bases de données ».

Globalement, les solutions de gestion des comptes à privilèges offrent trois niveaux de contrôle :

1.    Un contrôle a priori, répondant en premier lieu à la problématique de ne présenter (et de n’autoriser) qu’aux seuls utilisateurs habilités les comptes et mots de passe auxquels ils peuvent prétendre. Seuls les utilisateurs humains ont été évoqués jusqu’ici, mais d’autres composants du SI peuvent aussi requérir de telles informations, comme par exemple une application Web Java qui nécessiterait la connaissance du login et du mot de passe de connexion à une base de données Oracle. Avec une solution de gestion des comptes à privilèges, cette application peut récupérer, par une API de type Web Services, ces informations de connexion auprès du coffre de mots de passe centralisé.

Le contrôle a priori s’exerce également sur les mots de passe eux-mêmes dans le sens où ils peuvent être régulièrement et automatiquement modifiés dans le coffre et propagés dans les systèmes cibles, cette fonctionnalité répondant à une problématique bien connue des RSSI à savoir « comment imposer, sans douleur, et de manière transparente, une Password Policy sur les composants d’infrastructure ? ». Cette fonctionnalité peut même être étendue en ne fournissant aux administrateurs que des mots de passe à usage unique, immédiatement modifiés dans le coffre et propagés sur les serveurs après leur utilisation.

2.    Un contrôle pendant la demande d’accès aux comptes à privilèges, celle-ci pouvant en effet être soumise à un circuit de type « workflow » avant de pouvoir aboutir : si Paul veut utiliser le compte d’administration du proxy, il faudra que Jacques autorise cette demande particulière qui lui aura été signifiée dans sa boîte mail.

(((IMG6764)))
Demande d’accès à un compte à privilèges soumise à validation dans Thycotic Secret Server.

3.    Un contrôle a posteriori, centré sur les traces. Les solutions de gestion des comptes à privilèges placent en effet toutes les demandes d’accès dans des pistes d’audit qui peuvent ensuite être requêtées par critères, comme par exemple les derniers accès demandés par Paul ou bien encore les accès demandés pour le compte root d’un serveur Unix le mois dernier. Certaines solutions, comme Thycotic Secret Server, vont même encore plus loin puisqu’elles permettent de tracer sous la forme d’un enregistrement vidéo, les actions d’un administrateur sur un serveur cible à partir du moment où il a sélectionné le compte à privilèges dans le coffre de sécurité. Les responsables informatiques qui ont dû participer à des investigations d’informatique légale suite à des incidents, savent à quel point une telle fonctionnalité se révèle être une véritable mine d’or.

Réussir la mise en œuvre d’une solution de gestion des comptes à privilèges

Le choix de la solution technique doit bien entendu être regardé de près. D’une part pour les fonctionnalités avancées proposées (ex: authentification des administrateurs par OTP, découverte automatique des comptes à référencer, intégration avec des solutions SIEM etc.), mais aussi pour les prix pratiqués, les écarts pouvant être très significatifs entre éditeurs ou pour un même éditeur entre solutions commerciales proposées (SMB, Enterprise etc.).

Néanmoins la phase la plus délicate consiste à référencer l’intégralité des comptes et de leurs informations (parfois dispersées dans plusieurs fichiers non maintenus ou non synchronisés), puis à établir les périmètres de responsabilité et les rôles associés : Qui est maître sur la donnée ? Qui doit avoir accès à cette information sans néanmoins pouvoir la modifier ? Etc.

Les rôles et plus globalement la solution utilisés devront être intégrés à la démarche de gestion des identités et des accès mise en œuvre par l’entreprise, car si un administrateur systèmes et réseaux possède bien un rôle métier parmi d’autres, il possède aussi de très importants pouvoirs sur le Système d’Information, associables, par accident ou par malveillance, à de très grands risques pour l’entreprise.