Histoires de BureauAdieu à l'administrateur

Wes Miller

Il y a plus de trois ans, j'ai commencé à transférer mon compte utilisateur sur mon système Windows principal du compte administrateur local au compte utilisateur local. Je travaillais alors chez Microsoft depuis plus de sept ans et je m'étais toujours connecté à Windows en tant qu'administrateur avec des privilèges complets. C'était certes commode, mais ce manque de sécurité effrayant

souligne la remarquable chance que j'ai eue (que tant parmi nous continuent de narguer) à me connecter en tant qu'administrateur tous les jours sans avoir causé davantage de dégâts aux systèmes.

Je me surprends souvent à souhaiter qu'il existe des statistiques précises à cet égard, mais mon instinct et le secteur dans son ensemble me disent que bien trop d'organisations, et de professionnels de l'informatique, exécutent leurs systèmes en tant qu'administrateurs locaux. À Winternals, lorsque j'ai commencé à exécuter mon système en tant qu'utilisateur, c'était avec l'intention de découvrir à quel point c'était difficile (en tant que « prosommateur »), et d'essayer de comprendre comment notre produit, Winternals Protection Manager, pourrait aider une organisation moyenne. Étant donné que la plupart des organisations autorisaient et autorisent toujours leurs employés à exécuter leurs systèmes en tant qu'administrateurs, notre objectif était de permettre aux administrateurs de se connecter en tant qu'utilisateurs, et de faciliter au maximum cette transition. Quelle que soit la technologie que vous utilisez, il n'est pas facile de transformer une organisation où les utilisateurs exécutent leurs systèmes en tant qu'administrateurs en une organisation où ils restent de simples utilisateurs, mais il s'agit du moyen le plus efficace de réduire la surface d'attaque au sein de votre organisation. Vous pourriez voir cela comme une sorte de pare-feu intra-système, car c'est exactement ce dont il s'agit !

Comment en sommes-nous arrivés là ?

Le défi que je vous lance : éprouvez la douleur

Si vous n'avez pas encore pensé à transformer vos administrateurs en utilisateurs, vous devriez sérieusement envisager de le faire. Je vous encourage d'ailleurs à commencer par essayer vous-même. Non, pas sur un ordinateur secondaire, ce serait tricher ! Essayez sur votre système principal, celui que vous utilisez tous les jours. Je vous encouragerais même à essayer sans utiliser le contrôle de compte d’utilisateur (UAC) si vous exécutez Windows Vista®. Lorsque vous voulez prêcher une idée impliquant un changement au sein de votre organisation, il est souvent judicieux de montrer l'exemple et d'être le premier à la pratiquer. Vous vous rendrez compte, je pense, qu'il n'est pas vraiment difficile d'exécuter son système en tant que non administrateur, surtout en sachant que vous renforcez ainsi la sécurité du réseau informatique de votre organisation.

Le fait que la plupart des utilisateurs exécutent leurs systèmes en tant qu'administrateurs est enraciné dans l'histoire même de Windows®. Avec les premières versions de Windows, c'est-à-dire avant Windows NT® 3.1, chaque utilisateur interactif possédait autant de droits que son voisin. D'un point de vue fonctionnel, la sécurité était inexistante. À la maison, cela n'était pas très important ; cela signifiait simplement que tous les logiciels s'installaient la même façon. On partait du principe que l'utilisateur était le propriétaire de l'ordinateur et que tous les logiciels étaient installés pour tous les utilisateurs de cet ordinateur.

Lorsque Windows NT est apparu, il n'a pas immédiatement pris d'assaut le marché des entreprises (et encore moins le segment grand public). Et du fait de la compatibilité Win32® entre Windows 32 bits et Windows NT, la plupart des fournisseurs d'applications n'ont pas reconstruit leurs applications uniquement pour accommoder l'infrastructure de sécurité de Windows NT. En fait, ce n'est vraiment qu'avec Windows 2000 que de nombreux fournisseurs de logiciels indépendants orientés grand public ont commencé à se soucier de Windows NT. Et c'est Windows XP, bien sûr, qui a enfoncé le clou en mettant fin à la famille 9x de Windows.

Malgré cela, ont continué de déferler sur le marché des applications qui partaient du principe que chaque utilisateur du système dispose des droits d'écriture dans Program Files (ce n'est pas le cas des utilisateurs), dans la clé HKEY_LOCAL_MACHINE (HKLM) du Registre (ce n'est pas le cas des utilisateurs) et dans la clé HKEY_CLASSES_ROOT (ce n'est pas le cas des utilisateurs). Les jeux sont souvent parmi les pires logiciels à ignorer les restrictions d'accès ; voir l'article de Matt Clapham à ce sujet sur à l'adresse technetmagazine.com/issues/2007/02/Gaming.

Le problème réside dans le fait que la plupart des applications inter-système stockent leurs fichiers et paramètres de Registre dans ces emplacements, et que vous devez pouvoir lire et écrire dans ces emplacements pour pouvoir les installer. Malheureusement, certaines applications s'évertuent à écrire dans ces clés après leur installation. Par exemple, ma fille possède un jeu basé sur Flash. Il tente d'installer un lecteur personnalisé à chaque exécution, ce qui signifie que lorsque ma fille est connectée en tant qu'utilisateur, et non administrateur, l'application ne démarre pas et lance une erreur irrécupérable. Cet exemple est certes quelque peu extrême et concerne une application grand public, mais la réalité est que de nombreuses applications qui ne sont pas destinées au grand public ne fonctionnent toujours pas correctement dans le monde des utilisateurs non administrateurs. En fait, si vous relevez mon défi (voir l'encadré, « Le défi que je vous lance : éprouvez la douleur »), vous découvrirez que Windows lui-même ne tolère pas d'être exécuté en mode utilisateur.

Si vous jetez un coup d'œil à la figure 1, vous verrez à quoi ressemble l'exécution de IPConfig/release en tant qu'utilisateur sur Windows XP. Si vous comparez cela à la figure 2, vous verrez que cette même commande sous Windows Vista n'est pas vraiment meilleure, mais vous savez au moins pourquoi elle échoue. Notez que les outils réseau dans leur ensemble ont été améliorés pour permettre aux utilisateurs d'actualiser leurs adresses IP. De même, l'exécution de Gestion de l’ordinateur (compmgmt.msc) en tant qu'utilisateur sous l'une ou l'autre version vous permet d'effectuer un nombre limité de tâches, mais qui aboutissent généralement à des impasses, comme illustré à la figure 3. Si Windows Vista n'active pas par défaut un grand nombre des outils présents dans Gestion de l'ordinateur, il affiche en revanche les messages d'accès refusé plus clairement.

Figure 1** Exécution en tant qu'utilisateur sous Windows XP **(Cliquer sur l'image pour l'agrandir)

Figure 2** Exécution en tant qu'utilisateur sous Windows Vista **(Cliquer sur l'image pour l'agrandir)

Figure 3** Message trompeur après l'exécution de compmgmt.msc en tant qu'utilisateur sous Windows XP **(Cliquer sur l'image pour l'agrandir)

Pourquoi c'est important

Mais alors, pourquoi devriez-vous vous y intéresser ? Parce que nous, en tant que professionnels de l'informatique, devrions commencer à obliger les applications à s'aligner sur les utilisateurs de moindre privilège, au lieu de les laisser supposer que l'utilisateur interactif est le propriétaire du système.

Malheureusement, les stratégies qui permettent aux administrateurs d'écrire dans les clés de Registre accordent également à n'importe quel logiciel malveillant exécuté dans leur contexte utilisateur un accès complet à tout ce qui ne lui a pas été explicitement refusé via les listes de contrôle d'accès (ACL). Dans le monde d'UNIX, les gens suivent la règle qui consiste à ne pas exécuter le système en tant que root (l'équivalent fonctionnel du compte administrateur de Windows), principalement parce que l'écosystème de logiciels qui repousse les limites du modèle de sécurité est minuscule voire inexistant.

La meilleure chose à faire est de suivre la même règle et de ne vous connecter en tant qu'administrateur que lorsque c'est absolument nécessaire ou, encore mieux, d'exécuter uniquement des applications individuelles en tant qu'administrateur. Ce faisant, vous activez le pare-feu intra-système que j'ai mentionné précédemment. Si des logiciels malveillants ou espions tentent alors d'infecter votre système en essayant d'effectuer une action non autorisée (installation d'un service ou d'un pilote ou installation pour tous les utilisateurs, par exemple), ils échouent car ils ne peuvent pas écrire dans le Registre ou le système de fichiers. Vous permettez en outre aux logiciels anti-programme malveillant de contenir les logiciels malveillants qu'ils reconnaissent sans mettre en danger le système entier.

Notez, toutefois que les utilisateurs ne sont pas à l'abri des attaques. Bien qu'ils ne soient pas encore très répandus, certains logiciels malveillants sont capables d'infecter le contexte d'un utilisateur individuel ou de détruire ses données. Les risques d'attaque posés par de tels logiciels sont, toutefois, limités. Par conséquent, les facteurs qui contribuent à limiter les instances de logiciels malveillants sur Linux ou Macintosh (le nombre de victimes potentielles très bas décourage les auteurs de logiciels malveillants) peuvent aujourd'hui aider à assurer la sécurité générale de vos utilisateurs finaux, et de vous-même.

Qu'en est-il des utilisateurs avec pouvoir ?

Lorsque nous développions Protection Manager, les clients émettaient souvent le commentaire suivant : « Nous exécutons Windows XP avec tous nos utilisateurs connectés en tant qu'utilisateurs avec pouvoir et non en tant qu'administrateurs. Nous sommes donc en sécurité ». Malheureusement, les utilisateurs avec pouvoir ne sont pas loin d'être des administrateurs. Il existe plusieurs failles potentielles qui pourraient, avec un peu de travail, permettre à un utilisateur avec pouvoir Windows XP de devenir un administrateur. En fait, le groupe Utilisateurs avec pouvoir a été éliminé sur Windows Vista et Windows Server® 2008 ; seul un système mis à niveau depuis une précédente version de Windows comportera un groupe Utilisateurs avec pouvoir. En résumé, vous devriez toujours éviter d'utiliser le groupe Utilisateurs avec pouvoir, même si vous utilisez Windows XP.

Autorisations avec pertes

Si vous lisez mon article du mois de mars sur les clients légers Windows (technetmagazine.com/issues/2008/03/DesktopFiles), vous verrez que j'y avais déconseillé l'allègement de Windows XP afin de gagner de l'espace. Dans la même veine, il existe une pratique courante permettant aux administrateurs de devenir des utilisateurs et que vous devriez envisager, bien qu'avec précaution. Il s'agit de la pratique consistant à ajuster les ACL sur le Registre et le système de fichiers afin que les utilisateurs puissent écrire dans des emplacements qui leur sont normalement interdits et activer ainsi des applications problématiques.

Évidemment, la meilleure solution est d'utiliser une version mise à jour d'une application qui ne nécessite pas une telle modification, mais cela n'est pas toujours possible. Si vous devez modifier des autorisations (c'est-à-dire les annuler), procédez avec précaution. Souvenez-vous que le pare-feu entre un utilisateur et un administrateur est principalement défini par les autorisations d'accès au Registre et au système de fichiers. En étendant ces autorisations à tous le monde, vous affaiblissez votre protection et élargissez potentiellement la surface d'attaque exposée aux logiciels malveillants. Soyez donc très prudent.

Qu'en est-il du contrôle de compte utilisateur (UAC) ?

Aucune discussion concernant la transition entre le statut d'administrateur et celui d'utilisateur n'est complète si elle n'inclut pas le Contrôle de compte utilisateur (UAC) de Windows Vista. L'UAC, tout comme la fonctionnalité similaire sur le système d'exploitation Mac OS X, vous permet d'exécuter le système « en tant qu'administrateur » sans vous exposer à beaucoup de risques.

Comment cela fonctionne-t-il ? Jetons un coup d'œil, à la figure 4, à ce que Process Explorer indique au sujet de cmd.exe. L'instance du cmd.exe de droite a été lancée sans élévation, et je suis connecté en tant qu'administrateur. Par conséquent, bien que l'utilisateur de droite soit identique à celui de gauche (où le cmd.exe a été lancé avec élévation), l'application elle-même ne contient pas les privilèges et jetons requis pour lui permettre (à elle et à l'utilisateur exécutant cette instance) d'effectuer des tâches qui nécessitent des droits administratifs. Le rôle de l'UAC est de réduire la surface d'attaque dans le contexte interactif d'un utilisateur. Le seul problème est que quelque chose doit dire à Windows que cette tâche nécessite des privilèges d'administrateur et que l'utilisateur peut autoriser l'élévation requise pour compléter cette tâche.

Figure 4** Deux instances de cmd.exe avec des privilèges différents **(Cliquer sur l'image pour l'agrandir)

Les petites icônes en forme de bouclier dans Windows Vista vous indiquent les tâches qui nécessitent une élévation (voir la figure 5). Ces tâches nécessitent une élévation à chaque fois que vous les exécutez, et ceci est l'une des faiblesses de Windows Vista que la presse a choisi de mettre en évidence. L'alternative, qui consiste conserver en mémoire les informations d'identification, pose une menace de sécurité potentielle qui pourrait être utilisée pour exploiter plus facilement le système.

Figure 5** Les icônes en forme de bouclier de Windows Vista indiquent le besoin d'élévation **(Cliquer sur l'image pour l'agrandir)

Si le contrôle de compte d'utilisateur est activé et que vos utilisateurs s'exécutent simplement en tant qu'utilisateurs, ils seront invités à fournir une série d'informations d'identification administratives lorsqu'une application nécessite des privilèges d'administrateur. Notez, dans ce cas comme lorsque vous utilisez runas ou psexec, que l'application s'exécute littéralement dans le contexte de l'utilisateur dans lequel vous l'avez lancée, contrairement au mode administrateur sous UAC. Dans ce cas, les tâches s'exécutent dans votre contexte, mais avec des privilèges élevés.

Vous exécutez Windows Vista en tant qu'utilisateur ?

Ma préférence personnelle est d'exécuter Windows Vista en tant qu'utilisateur et non pas administrateur avec UAC, parce que je crois que, dans une entreprise moyenne, cette méthode est toujours la meilleure. Vos utilisateurs disposent ainsi d'un contrôle total sur leurs systèmes et vous réduisez aussi les possibilités d'attaque par des logiciels malveillants.

En outre, si vous envisagez de gérer vos utilisateurs avec la Stratégie de groupe, les logiciels anti-virus, les logiciels anti-programme malveillant ou autres et que vous voulez contrôler vous-mêmes si ces tâches sont appliquées ou complétées, il est très important de veiller à ce que vos utilisateurs finaux ne se connectent pas en tant qu'administrateurs. Si vos utilisateurs sont des administrateurs, ils peuvent arrêter des services, ajouter ou supprimer des pilotes, etc. Bien sûr, un utilisateur final astucieux qui exécute son système en tant qu'utilisateur peut utiliser Windows PE pour contourner certains obstacles de sécurité. BitLocker® peut augmenter la difficulté d'une telle opération, mais là aussi, n'oubliez pas que les utilisateurs finaux disposant d'un accès physique peuvent faire ce qu'ils veulent à leur machine pour peu qu'ils aient le temps, les connaissances et l'enthousiasme nécessaires.

L'exécution de Windows Vista en tant qu'utilisateur n'est pas très différente de l'exécution de Windows XP dans le même mode. J'utilise les mêmes outils, PSExec, RunAs et, à présent, UAC pour exécuter des tâches en tant qu'administrateur lorsque cela s'avère nécessaire. La bonne nouvelle est que bon nombre de tâches qui nécessitaient des privilèges d'administrateur dans Windows XP ne les exigent plus. Par exemple, un utilisateur Windows Vista peut installer une imprimante locale. (Les imprimantes réseau pouvaient être installées par les utilisateurs dans Windows XP, mais l'installation d'une imprimante locale nécessitait des privilèges d'administrateur). Dans Windows Vista, tant que l'utilisateur contrôle physiquement la machine et que le pilote d'imprimante est dans le magasin de pilotes, l'utilisateur peut installer et utiliser une imprimante (voir go.microsoft.com/fwlink/?LinkId=111534 pour plus d'informations). Notez que cette fonctionnalité est désactivée dans Windows Server 2008.

Bien sûr, les utilisateurs se moquent souvent de la présence (ou de l'absence) de la fonctionnalité Horloge lorsqu'ils exécutent Windows XP en tant qu'utilisateurs. Si vous essayez de double-cliquer sur l'horloge en tant qu'utilisateur (chose que l'on a souvent tendance à faire pour voir la date, que cette fonctionnalité ait été conçue à cet effet ou pas), vous obtenez l'erreur illustrée à la figure 6. Pas très convivial. Dans Windows XP, vous pouvez modifier la stratégie afin que les utilisateurs puissent effectuer cette opération, mais dans Windows Vista, elle a déjà été modifiée à cet effet. Ainsi, l'exécution du système en tant qu'utilisateur, que vous utilisiez le contrôle de compte d'utilisateur ou que vous vous connectiez en tant qu'utilisateur formel puis passiez à un autre utilisateur, est généralement plus acceptable sur Windows Vista que sur Windows XP.

Figure 6** Dans Windows XP, les utilisateurs qui n'exécutent pas le système en tant qu'administrateurs ne peuvent pas modifier l'heure **(Cliquer sur l'image pour l'agrandir)

Il y a des limites !

N'oubliez pas que le fait de faire de vos utilisateurs des non-administrateurs n'est pas une panacée. Les utilisateurs finaux assidus se trouvent toujours physiquement sur leur propre PC, et ils peuvent exploiter leurs propres systèmes comme ils l'entendent, surtout si la stratégie ou les privilèges Utilisateur les gênent ou les empêchent de faire leur travail.

Si vos utilisateurs sont connectés en tant qu'administrateurs, ils peuvent aisément contourner la Stratégie de groupe qui a été mise en place. Bien sûr, avec un peu plus de travail, les utilisateurs peuvent démarrer sur Windows PE et modifier des autorisations auxquelles ils n'ont pas normalement accès. En utilisant BitLocker ou un autre chiffrement de lecteur/volume, vous pouvez, toutefois, rendre cette opération impossible ou du moins plus difficile.

La chose la plus importante que vous puissiez faire si votre organisation n'a pas encore commencé cette transition vers le mode Utilisateur est de vous familiariser avec les raisons pour lesquelles votre organisation et vous devriez consacrer du temps, de l'argent et des efforts pour convaincre les utilisateurs de ne plus exécuter leurs systèmes en tant qu'administrateurs.

Bien sûr, il n'est pas aisé d'oublier les applications héritées, mais si vous avez une application qui ne peut pas être exécutée en mode Utilisateur, vous ne devriez pas la garder au risque de compromettre la sécurité de votre organisation. Vous devriez penser à virtualiser cette application, c'est-à-dire la transférer littéralement sur une machine virtuelle que l'utilisateur exécute en tant qu'administrateur. Vous pouvez ainsi exécuter l'application comme elle doit l'être tout en sécurisant le reste du système en transformant les administrateurs en utilisateurs.

Notez que dans cet article, je n'ai pas utilisé une seule fois le mot « verrouillage » ou tout autre mot qui en dérive. Nombreux sont ceux qui utilisent un tel mot pour décrire le passage du mode Administrateur au mode Utilisateur. C'est probablement dû à ma formation de psychologue de formation ou à mon engagement actuel dans le marketing, mais je pense qu'il est important de ne pas utiliser des mots qui peuvent pousser vos utilisateurs finaux à penser que leurs privilèges leur ont été ravis (bien que ce soit le cas au niveau sémantique).

Au lieu de cela, concentrez-vous sur les avantages en matière de sécurité que cette opération apporte à l'organisation et mettez en place un bon plan pour les cas limites où un utilisateur spécifique ne peut absolument pas exécuter son système en tant qu'utilisateur ou où une tâche particulière nécessite des privilèges administratifs. Que vous utilisiez un outil manuel tel que mon script Run.vbs (que vous trouverez à la page technetmagazine.com/issues/2007/03/DesktopFiles) ou une solution commerciale pour vous aider à faire la transition (ainsi qu'à cacher les détails à vos utilisateurs finaux et à bien faire les choses), il est important de commencer à emprunter la voie non administrateur le plus tôt possible. Aaron Margosis, qui collabore fréquemment à TechNet Magazine, est un partisan indéfectible du mode non administrateur. Si vous n'êtes pas familier avec son blog, consultez-le vite! Il représente la meilleure source d'informations sur ce sujet (voir blogs.msdn.com/aaron_margosis). 

Wes Miller est actuellement responsable de produit technique senior pour CoreTrace (www.CoreTrace.com) à Austin au Texas. Il a auparavant travaillé chez Winternals Software et comme responsable de programme pour Microsoft. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.