Quiconque a déjà essayé de gérer vos postes de travail comme des comptes limités, mais nous allons voir un bon moyen de surmonter les problèmes liés à l’accès limité et à la compatibilité avec l’applicatif déjà en place.
| Contenu complémentaire : - Le groupe utilisateur Cadim (Communauté Active Directory & Identity Management) - Article : Windows Vista fait sien le moindre privilège - Article : Donner des paramètres souples aux utilisateurs - Article : Standards de la fédération d’identités |
Les applications héritées (et parfois mêmes les nouvelles) qui sont régies par le modèle de sécurité de l’utilisateur à moindre privilège, peuvent causer des soucis aux administrateurs IT. En effet, il est fréquent que de tels programmes doivent accéder à des zones du système de fichiers et du registre que les utilisateurs à moindre privilège n’ont pas le droit de modifier. Il arrive alors que certaines applications perdent des fonctionnalités ou cessent purement et simplement de fonctionner. Les utilisateurs disposent de plusieurs méthodes pour exécuter les applications héritées quand ils sont connectés comme un LUA (par exemple la commande Runas).
Beaucoup d’entre elles sont des contournements qui demandent à l’utilisateur une certaine intervention, ou qui introduisent des problèmes d’authentification lors de la connexion aux ressources du réseau. De ce fait, les utilisateurs les acceptent rarement. Pourtant, vous pourriez parfaitement envisager les possibilités suivantes, transparentes pour l’utilisateur final :
• Changer l’ACL sur les fichiers, dossiers ou clés de registres affectés
• Modifier le jeton de sécurité de l’utilisateur seulement pour l’application affectée
• Utiliser l’Application Compatibility Engine pour rediriger les écritures du système de fichiers ou des registres
La méthode la plus courante pour exécuter les applications héritées en tant qu’utilisateur à moindre privilège, consiste à modifier les ACL sur les clés de registres et les fichiers ou dossiers auxquels une application doit accéder. Cette méthode présente deux inconvénients principaux. Premièrement, il faut identifier les clés de registres, les fichiers et les dossiers qui causent le problème. C’est une opération assez longue, même avec des outils d’accès aux fichiers et aux registres.
Deuxièmement, après avoir modifié l’ACL nécessaire, vous risquez de laisser certaines zones du système précédemment protégées, ouvertes au changement. Avec le risque de voir un beau jour l’application cesser de fonctionner. Ce sera le cas, par exemple, si vous devez donner aux utilisateurs l’accès modify à un répertoire d’applications particulier. Des solutions tierces, comme Protection Manager de Winternals Software et Privileges Manager de Beyond Trust, donnent le moyen de modifier le jeton de sécurité de l’utilisateur à la volée.
Quand un utilisateur lance une application, le jeton reçoit le privilège administrateur pour n’exécuter que ce processus particulier. Ce procédé est complètement transparent pour l’utilisateur. Malheureusement, il est onéreux. XP a une solution intégrée pour régler les problèmes de compatibilité LUA : l’Application Compatibility Engine. En l’utilisant conjointement à l’ACT (Application Compatibility Toolkit), vous pouvez analyser une application et configurer XP pour qu’il redirige vers le profil de l’utilisateur, les écritures qui se trouvent dans les zones protégées du système de fichiers et du registre.
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
