Huit lacunes dans les contrôles de connexion Windows

Lacune n°1 : pas de contrôle des connexions simultanées

Windows n'offre aucune possibilité d'empêcher un compte utilisateur donné de se connecter à partir de plusieurs systèmes simultanément avec des crédences identiques (même identifiant, même mot de passe).

S'agissant de sessions interactives à partir de postes de travail ou d'ordinateurs portables, un administrateur système ne peut absolument pas empêcher un utilisateur de se connecter à un ordinateur, de laisser un autre utilisateur l'utiliser avec ses crédences ou de simplement quitter cet ordinateur pour aller se connecter à partir d'un second système.

Et cela tient à l'architecture de Windows, dans la mesure où aucune entité de ce système d'exploitation ne tient le compte des emplacements à partir desquels un utilisateur est connecté, ceci étant géré individuellement par chaque poste de travail.

Les postes de travail communiquent bien sûr avec le contrôleur de domaine, mais celui-ci n'est en fait impliqué que dans l'authentification initiale.

Une fois que le contrôleur de domaine a accepté la connexion (crédences correctes) ou l'a refusé (crédences incorrectes), il « oublie » cette connexion et ne garde aucune trace du fait que cet utilisateur est toujours connecté à partir de cet ordinateur, ce qui explique probablement l'impossibilité dans laquelle se trouve Windows de proposer une fonctionnalité de contrôle des connexions simultanées.

Microsoft a d'abord tenté de résoudre ce problème majeur en publiant un outil non supporté dénommé Cconnect, fourni avec son Windows NT/2000 Resource Kit. Mais compte tenu de sa complexité d'implémentation, de ses fonctionnalités extrêmement limitées, ainsi que des contraintes et des lacunes additionnelles (sic) générées par l'installation de ce logiciel, il ne fut que très peu utilisé.

Avec l'avènement d'Active Directory, Microsoft a revu sa copie. Mais, alors que l'on aurait pu penser que l'éditeur proposerait une solution intégrée satisfaisante, sa nouvelle initiative consista à fournir de nouveau un outil non supporté, basé sur des scripts de connexion, ne répondant que partiellement à la problématique et tout aussi compliqué à déployer et à administrer : LimitLogin.

LimitLogin est en effet particulièrement fastidieux à mettre en œuvre. Pour commencer, il génère une modification irréversible du schéma Active Directory (sic). Ensuite, il crée une nouvelle partition dans Active Directory, nécessite la configuration d'un site Web avec le NET Framework et ASP.NET, ainsi qu'une authentification déléguée Kerberos. Pour finir, il nécessite le déploiement de packages client supportant la communication avec le serveur Web via SOAP.
En bon français, cela s'appelle une usine à gaz …


Pourquoi le contrôle des connexions simultanées est-il si important ?

• cela réduit la capacité des utilisateurs à partager leurs crédences (identifiant et mot de passe) et d'éviter ainsi des cas de figure tel que celui-ci par exemple : un manager en charge de l'approbation des demandes d'achat se connecte avec ses crédences partir du poste de travail de l'un de ses subordonnés et confie ainsi à ce dernier sa tâche de vérification, sabotant ainsi la procédure de contrôle mise en place par l'organisation qui l'emploie.
• le bon fonctionnement de certaines applications dépend de l'interdiction des connexions simultanées dans la mesure où elles sont été conçues et développées à partir de l'hypothèse où un utilisateur ne peut pas ouvrir plusieurs sessions à la fois.
• il est crucial de limiter au mieux toute possibilité d'usurpation d'identité et de s'assurer que l'utilisateur des crédences de Monsieur Martin est bien Monsieur Martin.

De nombreuses enquêtes ont en effet été entravées car un utilisateur délictueux était en capacité de prétendre qu'un tiers était l'auteur du délit, en arguant du fait que ses crédences avaient été utilisées à son insu.

L'absence de contrôle des connexions simultanées crée un véritable problème d'attribution de responsabilité, ce qui explique que l'implémentation de cette fonctionnalité soit requise pour qu'un système d'information soit en conformité avec des systèmes réglementaires majeurs, tels

• le NISPOM (National Industrial Security Program Operating Manual – sections 8-303, 8-602 et 8-609)
• le DCID 6/3 (Director of Central Intelligence Issued Directive 6/3 – sections «Identification and Authentication» et «Enforcement of sessions controls»)

Top

Lacune n°2 : pas de reporting sur les connexions/déconnexions

Il n'existe aucun moyen dans Windows d'obtenir un rapport disant « Jean s'est connecté à 08h00 et s'est déconnecté à 11h00 ».

A nouveau, la raison en est que le contrôleur de domaine de garde pas trace du fait que Jean est encore connecté à partir de tel ordinateur.
Certains d'entre vous pensent peut-être qu'en collationnant les journaux d'événements de ces contrôleurs de domaine et en filtrant correctement ces événements, il serait possible d'obtenir un rapport listant toutes ces connexions initiales ainsi que les connexions vers d'autres serveurs. Si vous avez essayé, vous savez à quel point il peut être compliqué d'obtenir une simple liste de toutes les connexions initiales à partir des événements de sécurité d'un contrôleur de domaine, à moins d'avoir la capacité à corréler et regrouper de multiples événements en un seule ligne.

D'autres pourraient suggérer qu'en traquant tous les événements de connexion et de déconnexion du réseau, puis en les rassemblant, il devrait être possible de savoir quand Jean s'est connecté, combien de temps est-il resté connecté et quand s'est-il déconnecté. Et bien cela ne marche tout simplement pas : lorsqu'un utilisateur « mappe » un lecteur réseau sur un serveur, ouvre un fichier puis le referme, le serveur de fichier ferme cette session (dans un délai de quelques secondes à deux ou trois minutes) et insère un événement de déconnexion dans le journal de sécurité.
L'utilisateur est toujours installé à son poste de travail et n'a aucune idée du fait qu'il vient de se déconnecter du serveur. Lorsqu'il essaie à nouveau d'ouvrir un fichier sur ce serveur, son poste de travail détecte qu'il a été déconnecté et se reconnecte silencieusement au serveur, ce qui génère un nouvel événement de connexion.
Puis lorsque l'utilisateur ferme ce fichier et n'a pas d'autres fichiers ouverts sur ce serveur, le serveur ferme à nouveau la connexion, générant un nouvel événement de déconnexion.

Cela explique pourquoi les serveurs de fichiers génèrent des centaines d'événements de connexion et de déconnexion par utilisateur en une seule journée.


Il n'existe donc aucun moyen de collecter toutes les informations de connexion d'un utilisateur donné en analysant les journaux d'événements d'un contrôleur de domaine ou d'un serveur de fichiers.

Restent donc les journaux de sécurité de tous vos postes de travail… A l'exception de certains réseaux de petite taille hyper-sécurisés, généralement utilisés par des organismes gouvernementaux (services secrets, etc.), il est rarissime qu'une organisation, publique ou privée, collecte l'ensemble des journaux de sécurité de ses postes de travail.
Cela n'est pas théoriquement impossible, mais vous imaginez les coûts de stockage et de licences logicielles générés par une telle tâche, sans compter la difficulté d'obtenir des informations cohérentes et exploitables…

Pourquoi est-il tellement important d'obtenir un reporting fiable sur les connexions/déconnexions ?

Cela permet en particulier de répondre à des questions cruciales lors d'investigations suivant l'occurrence d'un incident. Qui était réellement connecté ? D'où se sont-ils connectés ? Quand se sont-ils connectés ? Combien de temps sont-ils restés connectés ? Quand se sont-ils déconnectés ? A un instant donné, qui était vraiment connecté ?
Les fonctionnalités natives de Windows ne permettent pas de répondre avec précision à ces questions.

Cette fonctionnalité est pourtant indispensable pour la mise en conformité d'un système d'information avec les contraintes réglementaires suivantes :

• Sarbanes-Oxley (section 404 et 802)
• LSF (sections «Contrôle d'implémentation» et «Reporting»)
• Bâle II (sections «Collecte et journalisation des incidents» et «Reporting»)
• PCI (sections «Surveillance» et «Suivi et archivage»)
• US Patriot Act (section «User monitoring and management»)

Top

Lacune n°3: pas de surveillance des connexions/déconnexions

La surveillance des connexions/déconnexions diffère du reporting sur les connexions/déconnexions.

Surveiller les connexions/déconnexions consiste à être capable de dire, en temps réel, qui est connecté et à partir de quels ordinateurs et à répondre à deux questions :

• quels sont tous les ordinateurs à partir desquels un utilisateur donné est actuellement connecté ?
• qui sont tous les utilisateurs connectés à partir de tel ordinateur ?

Et pour les mêmes raisons, cela est impossible avec les fonctionnalités natives de Windows.

La seule chose que vous puissiez faire consiste à examiner vos serveurs un par un (Gestion de l'ordinateur > Dossiers partagés > Sessions).
Imaginez la difficulté d'avoir à vérifier chaque ordinateur individuellement …

Mais cette surveillance s'avère encore plus cruciale dans certains cas de figure (par exemple lors de licenciements) lorsque vous avez besoin de déterminer immédiatement où se trouve un utilisateur donné et quels sont tous les ordinateurs sur lesquels celui-ci est potentiellement connecté, car vous devez le déconnecter de votre réseau.

Cela peut également être utile dans le cadre de l'optimisation de vos ressources informatiques : si un ordinateur est verrouillé par un utilisateur mais que ce dernier ne se trouve pas à son poste habituel, un administrateur système sera dans l'incapacité de le joindre (par téléphone ou de toute autre manière) afin de lui demander de déverrouiller le poste de travail en question.

Et la surveillance des connexions/déconnexions fait également partie des obligations instaurées par les contraintes réglementaires suivantes :

• FISMA / NIST 800-53 / FIPS PUB 200 (domaine «Access control»)
• GLBA (Gramm-Leach-Bliley Act - section «Access control»)
• HIPAA (Health Insurance Portability and Accountability Act – domaine «Medical data protection»)
• US Patriot Act (section «User monitoring and management»)

Top

Lacune n°4: pas de déconnexion (ou de verrouillage) à distance d'un utilisateur

Si un administrateur système a besoin de déconnecter un utilisateur donné et à moins qu'il ne dispose d'un utilitaire spécifique, il va devoir se déplacer physiquement sur le lieu de travail de cet utilisateur afin de le faire.
Et il existe beaucoup de bonnes raisons de vouloir déconnecter un utilisateur (ou de verrouiller sa session) :

• sécuriser un ordinateur laissé sans surveillance (même si un économiseur d'écran protégé par mot de passe est activé)
• libérer des ressources bloquées
• gérer des situations d'urgence

Imaginez par exemple qu'un employé (appelons le Jacques) s'apprête à être mis à pied et que celui-ci sache qu'une telle sanction disciplinaire va être prise à son encontre.
Jacques est connecté à 16h00 et à 16h05 un administrateur système désactive et/ou supprime son compte. Que se passe-t-il alors ? Jacques est toujours connecté sur son poste de travail et peut-être à certains serveurs. Tout ce qu'il lui reste à faire est de déverrouiller ce poste de travail (car les postes de travail ne vérifient pas les requêtes de déverrouillage auprès de leur contrôleur de domaine) et le voilà connecté, alors même que son compte a été désactivé et supprimé…

Cette capacité de déconnexion à distance fait cependant partie des fonctionnalités obligatoires pour se conformer aux exigences des réglementations suivantes :

• FISMA / NIST 800-53 / FIPS PUB 200 (domaine «Access control»)
• GLBA (Gramm-Leach-Bliley Act - (section «Access control»)

Top

Lacune n°5: pas de restriction horaires de connexion par groupe

Windows propose une fonctionnalité de restrictions horaires, mais seulement utilisateur par utilisateur.

Un administrateur peut accéder à un compte utilisateur et restreindre son accès à certaines heures de certains jours de la semaine.

Mais il n'est pas possible de procéder à cette opération par groupe. La seule possibilité offerte par Windows consiste à sélectionner plusieurs utilisateurs simultanément, ce qui est bien sûr très peu pratique, en particulier dans le cas de grands ou très grands réseaux.

La possibilité de restreindre les horaires de connexion fait elle aussi partie des contraintes à respecter afin d'être en conformité avec les réglementations suivantes :

• Sarbanes-Oxley (section 409)
• LSF (section «Surveillance»)
• PCI (section «Surveillance»)
• FISMA / NIST 800-53 / FIPS PUB 200 (domaine «Access control»)
• GLBA (Gramm-Leach-Bliley Act - (section «Access control»)
• HIPAA (Health Insurance Portability and Accountability Act – domaine «Medical data protection»)
• US Patriot Act (section «User monitoring and management»)

Top

Lacune n°6 : pas de restrictions d'accès par poste de travail et par groupe

Ici également, Windows ne permet une restriction d'accès par poste de travail qu'utilisateur par utilisateur.
Un administrateur peut accéder à un compte utilisateur et le contraindre à ne pouvoir utiliser que certains ordinateurs pour se connecter au réseau, mais il ne dispose d'aucun moyen de le faire par groupe, ce qui constitue un véritable handicap à la mise en place et au respect d'une politique efficace de sécurisation des accès.

Il est en effet très pertinent de réduire au maximum le nombre d'ordinateurs à partir desquels un compte peut être attaqué ou exploité si quelqu'un en découvre le mot de passe ou l'obtient à l'aide de techniques d'ingénierie sociale : cela réduit la surface d'attaque de votre réseau Windows.

C'est donc très logiquement que cette fonctionnalité est requise pour se conformer aux règles édictées par les régulations suivantes :

• FISMA / NIST 800-53 / FIPS PUB 200 (domaine «System and information integrity»)
• GLBA (Gramm-Leach-Bliley Act - (section «Protection against menaces»)
• HIPAA (Health Insurance Portability and Accountability Act – domaine «Medical data protection»)

Top

Lacune n°7 : pas de déconnexion à l'issue des horaires de connexion autorisés

En utilisant les fonctionnalités d'Active Directory, un administrateur système peut contraindre un utilisateur (appelons-la Carole cette fois-ci) à ne pouvoir se connecter que de 07h00 à 17h00. Mais que se passe t‘il vraiment si Carole se connecte à 13h00 et reste connectée après 17h00 ? Windows ne la déconnectera pas à 17h00 car il n'existe aucune fonctionnalité native en capacité de le faire dans le système d'exploitation de Microsoft.

Il existe bien un paramètre ( dans Stratégies locales > Options de sécurité) qui pourrait vous faire penser que cela fonctionne : «Automatically logoff users when logon time expires.»

Mais cela ne s'applique qu'aux serveurs de fichiers et d'impression (composant SMB).

Concrètement, Carole se connecte à partir de son poste de travail et accède à un serveur de fichiers. Si elle reste connectée (et à la condition qu'elle n'ait aucun fichier ouvert sur ce serveur de fichiers) au-delà de 17h00, le serveur de fichiers la déconnectera effectivement à 17h00 et l'empêchera de se reconnecter à lui.
Mais il n'existe absolument rien dans Windows qui déconnectera Carole de son poste de travail à partir duquel elle a ouvert une session interactive …

Cette capacité de véritable déconnexion est, elle aussi, obligatoire dans le cadre d'une conformité aux dispositions réglementaires suivantes :

• FISMA / NIST 800-53 / FIPS PUB 200 (domaine «System and information integrity»)
• HIPAA (Health Insurance Portability and Accountability Act – domaine «Medical data protection»)
• US Patriot Act (section «User monitoring and management»)

Top

Lacune n°8: Pas d'affichage d'informations à propos de la dernière connexion

Imaginez le scénario suivant : un utilisateur se connecte à partir de son poste de travail et, après avoir correctement saisi son identifiant et son mot de passe, l'ordinateur affiche le message suivant : «Bonjour Jean Dupont, vous avez été authentifié. La dernière connexion de votre compte utilisateur s'est produite à 14h05, à partir de tel poste de travail. »
Et si l'utilisateur en question se rend compte qu'il ne s'est pas connecté à cette heure-là ou à partir de cet ordinateur ? Cela indiquerait que quelqu'un d'autre a utilisé ses crédences et a usurpé son identité.
Voilà une des manières les plus efficaces de détecter les usurpations de comptes utilisateur.

Windows ne permet pas l'affichage de ces informations bien que cette fonctionnalité soit obligatoire pour se conformer aux exigences des régulations suivantes :

• NISPOM (National Industrial Security Program Operating Manual – section 8-609 b3)
• DCID 6/3 (Director of Central Intelligence Issued Directive 6/3 – section 4.B.4.a)

Top

Windows ne propose donc pas les fonctionnalités de contrôle de sessions interactives qui permettrait aux administrateurs système de limiter efficacement les menaces internes et de mettre en conformité leur système d'information.

La situation économique actuelle rend pourtant encore plus cruciale l'implémentation de telles fonctionnalités. Comme Mark Raskino (vice-président – Gartner) l'a récemment affirmé : "Une récession suivie d'une reprise économique crée des bouleversements massifs. Les processus et les outils pour gérer et empêcher les connexions [à un réseau informatique] vont devenir critiques."

Les professionnels de l'informatique n'ont plus donc que le choix de se tourner vers d'efficaces solutions tierce-partie…