La cr�ation de comptes utilisateur repr�sente seulement une des t�ches faisant partie du travail d'un administrateur syst�me. La gestion des ressources de l'utilisateur est �galement une t�ches essentielle. � cet �gard, trois aspects doivent �tre pris en consid�ration�:
Les sections suivantes passent bri�vement en revue chacun des ces aspects.
6.2.1. Qui peut avoir acc�s aux donn�es partag�es�?
L'acc�s d'un utilisateur � une application, fichier ou r�pertoire sp�cifiques est d�termin� par les permissions donn�es � l'application, au fichier ou au r�pertoire en question.
De plus, il est souvent utile de pouvoir appliquer des permissions diff�rentes � des classes d'utilisateurs diff�rentes. Par exemple, la m�moire temporaire partag�e devrait permettre d'�viter la suppression accidentelle (ou malveillante) des fichiers d'un utilisateur par tout autre utilisateur que lui-m�me, tout en garantissant un acc�s complet au propri�taire des fichiers.
L'acc�s octroy� au r�pertoire personnel (parfois appel� home ou maison) d'un utilisateur constitue un autre exemple. Seul le propri�taire du r�pertoire personnel devrait �tre en mesure de cr�er ou examiner des fichiers dans cet emplacement. L'acc�s de tout autre utilisateur devrait �tre refus� (du moins sans l'autorisation du propri�taire). Cette diff�renciation au niveau de l'autorisation de l'acc�s permet non seulement d'augmenter la confidentialit� de l'utilisateur mais permet �galement d'emp�cher le d�tournement de fichiers personnels.
Ceci �tant, de nombreuses situations n�cessitent l'acc�s de multiples utilisateurs aux m�mes ressources d'un ordinateur. Dans ce cas pr�cis, la cr�ation minutieuse de groupes partag�s sera peut-�tre n�cessaire.
6.2.1.1. Groupes et donn�es partag�es
Comme nous l'avons mentionn� dans l'introduction, les groupes sont des entit�s logiques pouvant �tre utilis�es pour regrouper des comptes utilisateurs oeuvrant dans un but pr�cis.
Lors de la gestion des utilisateurs au sein d'une entreprise, il est sage d'identifier les donn�es particuli�res auxquelles certains services devraient avoir acc�s, celles dont l'acc�s devrait �tre refus� � d'autres services et celles qui devraient �tre partag�es par tout le personnel de l'entreprise. En d�terminant pr�alablement ces points pr�cis, il sera plus facile non seulement de cr�er une structure de groupe appropri�e, mais �galement d'octroyer les permissions ad�quates devant s'appliquer aux donn�es partag�es.
Par exemple, imaginez que le service des finances doivent tenir une liste des comptes des mauvais payeurs. Le service de recouvrement de dettes doit �galement avoir acc�s � cette liste. Si le personnel des deux services fait partie du m�me groupe appel� comptes, ces informations peuvent �tre plac�es dans le m�me r�pertoire (dont le groupe comptes est propri�taire) qui est a des permissions en lecture et �criture s'appliquant � l'ensemble du groupe.
6.2.1.2. �tablissement d'une structure de groupe
Parmi les d�fis auxquels les administrateurs syst�me doivent faire face lors de la cr�ation de groupes partag�es figurent points suivants�:
Pour faire face � ces d�fis, il est utile d'adopter une approche bas�e sur le bon sens. Une possibilit� consiste � copier la structure de votre organisation lors de la cr�ation de groupes. Par exemple, si votre entreprise a un service des finances, cr�ez un groupe appel� finances auquel tous les membres du personnel de ce service appartiendront. Si les informations financi�res sont trop confidentielles pour �tre disponibles dans toute l'entreprise mais sont absolument essentielles pour les �chelons sup�rieurs de la direction de l'entreprise, il suffit d'accorder � la direction des permissions de groupe afin que ses membres puissent avoir acc�s aux r�pertoires et donn�es utilis�s par le service des finances�; pour ce faire, ajoutez au groupe finances tous les membres des �chelons sup�rieurs de la direction de l'entreprise.
Il est �galement bon d'�tre tr�s prudent lors de l'octroi de permissions aux utilisateurs. De cette mani�re, il y a moins de risques que des informations confidentielles ne tombent dans de mauvaises mains.
En traitant la cr�ation de la structure des groupes de votre entreprise de la sorte, vous serez plus � m�me de satisfaire de mani�re s�re et efficace, les besoins d'acc�s aux donn�es partag�es au sein de votre entreprise.
6.2.2. O� les utilisateurs peuvent-ils avoir acc�s aux donn�es partag�es�?
Lors du partage de donn�es parmi des utilisateurs, il est courant d'avoir un serveur central (ou un groupe de serveurs) mettant certains r�pertoires � disposition d'autres ordinateurs sur le r�seau. De la sorte, les donn�es sont stock�es en un seul endroit et la synchronisation des donn�es entre de multiples ordinateurs n'est par cons�quent pas n�cessaire.
Avant d'adopter cette approche, vous devez d'abord d�terminer les syst�mes qui devront avoir acc�s aux donn�es stock�es localement. Lors de ce processus, prenez note des syst�mes d'exploitation utilis�s par les diff�rents syst�mes. Ces informations influenceront la facilit� avec laquelle vous impl�menterez une telle approche �tant donn� que votre serveur de stockage doit �tre en mesure de transf�rer ses donn�es � chacun des syst�mes d'exploitation utilis�s dans votre entreprise.
Malheureusement, d�s l'instant o� des donn�es sont partag�es entre de multiples ordinateurs d'un m�me r�seau, des risques de conflit au niveau de la propri�t� des fichiers apparaissent.
6.2.2.1. Probl�mes de propri�t� globale
Le stockage central de donn�es auxquelles de multiples ordinateurs d'un r�seau peuvent avoir acc�s offre un certain nombre d'avantages. Toutefois, supposez pour un instant que chacun de ces ordinateurs ait une liste de comptes utilisateur maintenue localement. Que se passe-t-il si la liste des utilisateurs maintenue sur chacun de ces syst�mes n'est pas semblable � celle pr�sente sur le serveur central�? Pis encore, que se passe-t-il si les diff�rentes listes d'utilisateurs pr�sentes sur chacun de ces syst�mes ne sont pas homog�nes entre elles�?
La situation d�pend certes de la mani�re selon laquelle les utilisateurs et permissions d'acc�s sont impl�ment�s sur chacun des syst�mes, mais dans certains cas, il est fort possible que l'utilisateur A d'un syst�me soit connu en tant qu'utilisateur B sur un autre syst�me. Une telle situation devient vraiment probl�matique lorsque des donn�es sont partag�es entre ces syst�mes, dans la mesure o� celles auxquelles l'utilisateur A peut avoir acc�s depuis un syst�me particulier peuvent �galement �tre lues par l'utilisateur B d'un autre syst�me.
C'est la raison pour laquelle de nombreuses entreprises utilisent une base de donn�es d'utilisateurs centrale. De cette mani�re, les listes d'utilisateurs ne se chevauchent pas sur diff�rents syst�mes.
6.2.2.2. R�pertoires personnels
Un autre aspect auquel les administrateurs syst�me sont confront�s est la possibilit� offerte ou non aux utilisateurs d'avoir des r�pertoires personnels stock�s localement.
L'avantage essentiel de la centralisation des r�pertoires personnels sur un serveur branch� au r�seau est que si un utilisateur se connecte � un ordinateur quelconque du r�seau, il pourra avoir acc�s aux fichiers contenus dans son r�pertoire personnel.
L'inconv�nient est que si le r�seau tombe en panne, les utilisateurs de toute l'entreprise n'auront plus acc�s � leurs fichiers. Dans certains cas (par exemple dans des entreprises o� l'utilisation des ordinateurs portables est tr�s r�pandue), il n'est pas recommand� d'avoir des r�pertoires personnels centralis�s. Ceci �tant, si le d�ploiement de r�pertoires personnels centralis�s est une option appropri�e dans votre situation particuli�re, votre travail d'administrateur syst�me n'en sera que simplifi�.
6.2.3. Quelles barri�res sont mises en place afin d'�viter la mauvaise utilisation des ressources�?
L'organisation minutieuse des groupes et l'attribution des permissions pour les ressources partag�es repr�sentent certaines des t�ches les plus importantes qu'un administrateur syst�me puisse effectuer afin d'�viter la mauvaise utilisation des ressources par les utilisateurs au sein d'une entreprise. Gr�ce � cette minutie, il est possible de cibler l'interdiction de l'acc�s aux ressources confidentielles et donc de refuser l'acc�s aux personnes non autoris�es.
Quelle que soit l'approche adopt�e par votre entreprise, la meilleure protection contre la mauvaise utilisation des ressources est toujours une vigilance soutenue de la part de l'administrateur syst�me. En surveillant bien la situation, vous �viterez souvent d'�tre accueilli au bureau un beau matin par une pile de mauvaises surprises en attente de r�solution.
