Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Installation et configuration d'un serveur internet
  3. Gestion des utilisateurs et des droits
Extrait - Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
Extraits du livre
Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
2 avis
Revenir à la page d'achat du livre

Gestion des utilisateurs et des droits

Introduction

Pour pouvoir définir les privilèges des personnes sur le serveur, chaque personne ayant accès au serveur recevra son propre nom d’utilisateur ; par ailleurs, chaque utilisateur est membre d’un ou plusieurs groupes. Tous les répertoires, fichiers et applications sur le système appartiennent à un utilisateur et un groupe. Cela permet à l’administrateur système de spécifier quels répertoires, fichiers et applications sont accessibles à quels utilisateurs individuels et à quels groupes.

Utilisateurs et groupes

La majorité des employés n’a pas besoin d’un compte serveur. Les comptes locaux sont réservés aux personnes qui devront modifier des fichiers sur le serveur. Il peut parfois être nécessaire d’expliquer à un manager ou à un directeur que le mot de passe du serveur n’est pas un symbole de prestige, et qu’il peut faire plus de mal que de bien dans les mains d’un non professionnel.

Évidemment, les employés doivent s’identifier pour lire et envoyer du courrier électronique, mais pour cela, il n’est pas nécessaire d’avoir un compte local. La base de données des mots de passe utilisée pour le courriel sera traitée dans la section Lightweight Directory Access Protocol (LDAP) du chapitre Bases de données.

Outre le fait de posséder un compte et le nom d’utilisateur qui va avec, les utilisateurs appartiennent à un ou plusieurs groupes. Le premier de ces groupes est nommé le groupe primaire, en anglais primary group ou login group. C’est celui qui est attribué aux nouveaux fichiers et répertoires si l’utilisateur ne spécifie pas explicitement un autre groupe, et c’est le groupe qui est attribué aux processus lancés par l’utilisateur. Sur la majorité des systèmes Unix modernes, le groupe primaire est un groupe personnel qui porte le même nom que le nom d’utilisateur ; cela contribue à protéger la confidentialité du répertoire personnel, par exemple.

L’administrateur système est libre dans la conception et la distribution de ces groupes, selon les demandes et les exigences du système en question. Par exemple, sur un serveur web, des groupes peuvent exister pour les développeurs et les graphistes, mais sur un serveur intranet, les groupes sont définis en fonction de l’accès aux scanners et imprimantes ; l’administrateur d’un ordinateur de bureau peut vouloir limiter l’accès aux médias externes en créant des groupes pour les utilisateurs qui ont le droit d’utiliser les ports USB et le lecteur DVD.

Sur certains systèmes Unix, dont la famille BSD et les systèmes basés sur Red Hat Linux comme CentOS, il existe un groupe nommé...

Droits d’accès

Quand on parle des droits d’accès, ou droits d’utilisateur, sur les systèmes Unix, on parle généralement du système traditionnel : un fichier ou une application appartient à un utilisateur et à un groupe, un utilisateur peut appartenir à plusieurs groupes et l’administrateur système peut manipuler tout ça pour arriver à la combinaison désirée de droits en lecture, écriture et exécution pour chaque utilisateur.

Cependant, depuis longtemps (FreeBSD 4.0-CURRENT et noyau Linux 2.5.46, publiés en 2002 tous les deux), un système existe pour compléter le système traditionnel quelque peu limité : Access Control Lists ou simplement ACL (Listes de Contrôle d’Accès). Ce système a été publié dans le document POSIX 1003.1e draft 17, et même si ce document n’a jamais été promu comme une norme, il a fait en sorte que les ACL soient implémentées dans les noyaux Unix et que le support pour cette fonctionnalité soit activé par défaut.

Celui qui travaille avec Unix, comme administrateur ou comme utilisateur, ne peut échapper à l’apprentissage du système de droits d’accès traditionnel : ce système est toujours la base de l’autorisation sous Unix. Les ACL peuvent introduire un étalement et une simplification bienvenus du contrôle, mais il est impossible de les implémenter sans une connaissance et une compréhension solides du système traditionnel.

Il est important de comprendre que les droits d’accès sont toujours relatifs, c’est-à-dire qu’un utilisateur ayant les droits corrects pour l’accès à un fichier, mais pas pour le répertoire contenant ce fichier, n’arrivera pas à accéder au fichier. 

Les droits d’accès d’un fichier peuvent être modifiés seulement par le propriétaire de celui-ci et par l’utilisateur root.

1. Traditionnel

Dans le système de droits d’accès Unix traditionnel, chaque fichier et chaque application appartient à un seul utilisateur et un seul groupe, et chaque utilisateur peut appartenir à plusieurs groupes....

Limitation d’accès root

Une erreur de frappe est vite arrivée, et les logiciels comportent parfois des bogues. Tout cela peut s’avérer problématique si cela entraîne par exemple la suppression de fichiers ou leur ineccessibilité.

Or si ces problèmes arrivent à l’utilisateur root, les conséquences peuvent être désastreuses ; en effet, possédant les droits de modification partout sur le système, root a la capacité de rendre le système inutilisable ou inaccessible. C’est pour cette raison que les daemons sont exécutés sous leur propre nom d’utilisateur actuellement, et non plus sous le nom de root.

De plus, le nom d’utilisateur root est le même sur tous les systèmes Unix, ce qui fournit déjà aux attaquants potentiels la moitié des informations nécessaires pour obtenir l’accès administrateur sur le système.

Voilà pourquoi il est fortement recommandé de limiter l’utilisation du compte root et de bloquer complètement l’accès direct à ce compte.

1. sudo

Avant que le compte de root puisse être bloqué, des mesures doivent être prises pour permettre aux utilisateurs autorisés d’exécuter les tâches de l’utilisateur root. L’application sudo (en anglais superuser do, exécuter super-utilisateur) est là pour ça. Cette application permet d’attribuer à certains utilisateurs le droit d’exécuter certaines commandes sous le nom d’autres utilisateurs ; cela permet alors de spécifier très précisément les droits d’administrateur attribués à certains utilisateurs.

La commande which permet de vérifier si sudo est installé :

freebsd$ which sudo 
freebsd$ 
 
debian$ which sudo 
debian$ 
 
centos$ which sudo 
/bin/sudo 
centos$ 

Sur CentOS, sudo fait partie de l’installation de base mais...

Comptes pour d’autres utilisateurs

Les autres utilisateurs, qui n’ont jamais besoin de se connecter directement au serveur mais qui devront s’identifier pour pouvoir accéder à leur courriel, n’auront pas de compte local sur le serveur, mais seront enregistrés dans un service d’annuaire. Le chapitre Bases de données, et plus précisément la section concernant LDAP, détaille ce sujet.

Départ d’un administrateur système

Le changement du mot de passe de root au départ d’un administrateur système n’est pas un acte de méfiance ; c’est un acte de savoir-faire d’administration système. 

Le blocage d’accès est une lame à double tranchant : d’une part, il assure que les administrateurs système restant gardent une vue complète des personnes ayant le droit d’accéder au serveur, maintenant et à l’avenir ; d’autre part, l’ancien administrateur sera protégé contre les suspicions si jamais un problème survient sur le serveur. À son départ, ladministrateur système rappellera à ses collègues de prendre les mesures qui s’imposent.

Il est recommandé de créer une liste des points à organiser au départ d’un administrateur système. Les fichiers en téléchargement de ce livre contiennent un exemple qui pourrait être utilisé comme guide pour la création d’une telle liste.