Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Introduction a l'administration systeme - Gestion des ressources de l'utilisateur

6.2. Gestion des ressources de l'utilisateur

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�:

  • Qui peut avoir acc�s aux donn�es partag�es�?

  • O� les utilisateurs peuvent-ils avoir acc�s � ces donn�es�?

  • Quelles barri�res sont mises en place afin d'�viter l'abus des ressources�?

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�:

  • Quels groupes cr�er

  • Qui inclure dans un groupe donn�

  • Quel type de permissions donner � ces ressources partag�es

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire