La mode est au DLP, les gourous de la sécurité cherchent de plus en plus à sécuriser « l’information »… parfois au détriment de l’infrastructure. Il existe pourtant un outil simplissime qui, à la fois, facilite les « politiques d’accès » et, indirectement, résout les questions de fuite ou de modification d’informations.
Userlock d’IS Décisions en quelques mots ? Un logiciel de gestion des accès destiné à toute la gamme des serveurs Windows actuellement en service (nos essais se sont déroulés sous 2008 Server). Mais surtout un logiciel capable d’appliquer à des groupes entiers (d’utilisateurs, de stations, ou les deux associés) des restrictions ou autorisations d’accès à des ressources, des plages temporelles d’utilisation, le moyen de forcer un verrouillage ou une déconnexion à distance d’un utilisateur en particulier… le tout accompagné d’un solide outil de reporting. En termes plus simples …
… les trois avantages principaux de Userlock
– l’interdiction de login d’un utilisateur ou groupe sur deux consoles simultanées (ou en dehors de stations préalablement définies),
– l’application de règle « par groupe » (par défaut, les restrictions sous Windows s’appliquent fastidieusement « user par user ») et
– la possibilité de « jeter » rapidement un intrus d’un simple mouvement de souris depuis la console d’administration. Le tout avec un niveau de complexité proche de celui nécessaire à la maîtrise de Powerpoint. C’est dire.
A qui s’adresse-t-il ?
Aux administrateurs souhaitant renforcer les politiques de logon sans avoir à écrire le moindre script ni modifier le plus petit service en place : Administrations, établissements hospitaliers, Lycées ou Universités, et entreprises constituées de plusieurs départements ou filiales exigeant un niveau minimum de cloisonnement entre fonctions et emplacements géographiques. Il n’existe strictement aucune limite haute ou basse du nombre d’administrés pris en compte. Si historiquement ce logiciel se destine surtout aux infrastructures de plusieurs milliers de postes, rien n’interdit de l’installer sur un petit système SBS appartenant à une entreprise « à données sensibles » et haute valeur ajoutée. Le tarif le plus élevé (configuration de 10 à 19 postes) ne dépasse pas 8 euros par station et chute à moins de 5 euros entre 100 et 200 postes.
Installation/configuration… R.A.S. et RAS
Il s’agit là de la seule question épineuse que pose l’installation de Userlock : l’étendue du domaine d’influence. Forêt entière ou simple Unité Organisationnelle ?
La procédure d’installation ne pose pratiquement qu’une seule question : quelle est l’étendue sur laquelle s’étendra le contrôle des utilisateur ? L’intégralité du domaine ou de la forêt, ou simplement une des « unités organisationnelles » de l’entreprise. Quelques secondes plus tard, au lancement de la console principale, l’on est prêt à définir les groupes de machines et d’usagers qui seront soumis aux autorisations/restrictions d’accès. Une sélection là encore effectuée sans le moindre effort, puisque se limitant à aller piocher utilisateurs, groupes et machines dans la base de données des ADS. Rien à Signaler donc. Peut-être est-ce à ce moment-là que l’on se rend compte des incohérences de certains choix passés lors de la définition des groupes. Userlock peut être un révélateur de « fouillis organisationnel »… pour ne pas utiliser un autre mot.
Les groupes une fois définis ou sélectionnés, il suffit de cocher des cases d’autorisations d’accès définissant le nombre de sessions possibles, que celles-ci soit « locales » ou via une connexion distante de quelque nature que ce soit (TSE, RAS etc). Les liaisons Remote Access Services ne présentant pas d’adresse IP dès l’initialisation de la session, de très légères différences de comportement les distinguent des ouvertures de session normale, mais ce n’est là qu’un détail. Si les groupes définis dans une OU (unité organisationnelle) ne nécessitent pas d’ajustements particuliers, il faut moins d’une heure pour dresser un premier jet de « logon policy » portant sur une centaine de postes. D’un coup de souris l’on définit les horaires d’accès autorisés, l’association des logins et des stations accessibles par telle ou telle personne ou groupe. Une définition des « heures de travail » et des « jours ouvrables » s’appliquant à tout un groupe s’opère en 5 minutes. Sans Userlock, en étant très rapide, il faut compter 3 minutes par compte, soit, pour une centaine d’utilisateurs… quelques week-ends en perspective.
D’un seul coup d’œil, l’administrateur dispose d’un état des connexions et des sessions ouvertes. C’est également à partir de cette vue qu’il lui est possible de verrouiller ou de « tuer » une session ouverte. Divers filtres facilitent le tri des informations affichées (non activés sur la capture présente compte tenu du faible nombre d’usagers connectés)
Les réels problèmes commencent avec la définition des types de restriction à imposer aux comptes avec pouvoir, à appliquer sans froisser les susceptibilités de chacun. Il est des « droits de mamamouchi » qui ont la vie dure… particulièrement chez les administrateurs, et qui doivent disparaître pour d’évidentes raisons de sécurité. En revanche, trop de « parano » peut entraver la liberté d’action des collaborateurs d’une entreprise. Comme pour toute définition de politique, le juste milieu est parfois difficile à situer. Ceci étant dit, certaines caractéristiques du programme permettent l’assouplissement de certaines contraintes. Ainsi, un utilisateur limité à 3 sessions peut, si le droit lui en est donné, clore à distance l’une de ses sessions sans avoir à se déplacer sur la console « fautive ». A l’administrateur tout de même le soin de sensibiliser ses ouailles sur les conséquences d’un logout brutal lorsque des documents sont en cours d’édition.
Qui se connecte, à partir de quelle station et avec quel mode de connexion ? Les histogrammes facilitent la détection et la mise en évidence des alertes et des états anormaux, sans avoir à plonger dans un tableur abstrus
Les politiques une fois définies, il ne reste plus qu’à déployer l’agent Userlock sur les différentes stations de travail supervisées par le programme. Là encore, l’opération est totalement automatique (le serveur utilisé lors de nos essais était à la fois contrôleur de domaine ET DNS principal). Cette distribution nécessite d’activer sur chaque station les « remote registry services » (registres distants) sur les systèmes à administrer. Ce genre de détail est d’ailleurs documenté très clairement dans les FAQ de l’éditeur.
La suppression d’une machine du cercle des systèmes administrés s’effectue de la même manière, via l’interface de déploiement d’agents… détail à ne pas oublier, car l’élimination de ce code « à la main » est un peu plus fastidieuse.
A partir de ce moment précis, toute ouverture de session est soumise au « bon vouloir » de Userlock, sans ajout de composant additionnel, sans opération shamanique dans la bdr ni torture des «group policy ». Une connexion en dehors des horaires ou jours ouvrables ou depuis une console « non autorisée » sera impossible. Toute tentative de connexion non conforme à la politique génère une alerte sur l’écran de la station (une réprimande très vite comprise par les usagers un peu trop fantaisistes), sur le log de la console, et émet éventuellement un email à l’attention de l’administrateur concerné. Chacun de ces messages est d’ailleurs totalement paramétrable. Détail amusant, nous avons été surpris de constater que lesdits messages étaient tous rédigés par défaut en anglais. Userlock détecte en effet la « localisation » du serveur et adapte son vocabulaire à la langue « native » du serveur (et non celle installée par configuration ou via d’éventuels « Language Pack »). Comme nos tests, par prudence et habitude, sont systématiquement effectués sur des serveurs US et des stations FR, cette configuration a déclenché ce « vrai-faux bug ». Un choix de la localisation des alertes mériterait d’être ajouté lors de l’installation, les bugs de « localisation de Service-Pack » et de rustines de sécurité ayant poussé bon nombre d’administrateurs à ne plus jamais acheter des serveurs Français.
La section « reporting » et la sortie des Etats de connexions. Le plus difficile est de les générer… en activant d’un revers de souris une icône « lancer » située dans la barre de tâche de la console principale (la « logique » de la MMC Microsoft nous a tout d’abord fait chercher un sous-menu par « clic droit »)
… 2 mois plus tard
En deux mois d’utilisation, un serveur et une trentaine de stations, dont 8 « physiques » sur LAN, 5 VM sous HyperV et Virtual PC et 6 « distantes » via RAS, pas une seule fois Userlock n’a failli à sa tâche ni entravé l’usage du réseau avec des comportements non prévus. Les statistiques d’usage, les logs d’alerte sont clairs, simples à interpréter… même pour un journaliste. Certes, il y a un monde entre une petite « config de test » et une exploitation dans la « vraie vie ». Mais le mariage avec les ADS est si transparent que l’extrapolation à une organisation comptant plusieurs centaines de postes et comptes d’utilisateurs ne paraît pas poser le moindre problème.
Les défauts de Userlock ? Ceux de tous les outils de gestion : c’est un formidable révélateur de pagaille. A titre d’exemple, notre configuration de base comportait deux serveurs Linux (Un partage de fichier SMB, une base de données), dont les ACL étaient indépendants et calqués sur les comptes déjà créés sur le 2008 Server. Situation échappant bien entendu totalement à Userlock, qui ne pouvait prendre la main sur ces serveurs autonomes. Il a fallu rapidement plonger dans la documentation de SaMBa pour paramétrer correctement ces machines, synchroniser et inféoder l’accès à leurs ressources aux ADS de 2008 et non plus aux systèmes d’authentification locaux.
Editeur : isdecision
Version installée : Userlock 5.5
Configuration nécessaire : Serveur Windows 2000 à 2008 R2, IIS et ADS installés
Prix : 4,63 € (HT) par poste pour 100 à 200 licences
