Gestion des mots de passe
Dans un service d’exploitation, les administrateurs ont besoin de récupérer très
facilement le mot de passe des dispositifs sur lesquels ils doivent intervenir. Il faut donc
allier la protection de ces mots de passe avec une mise à disposition simple et rapide.
Pour résoudre cette problématique, plusieurs approches de gestion des mots de passe sont
envisageables.
Les systèmes Unix ont généralement vocation à être des serveurs. Aussi relativement peu
d’utilisateurs sont déclarés dans ces systèmes. Par défaut, les systèmes Unix entreposent
les empreintes des mots de passe dans le fichier /etc/shadow, qui n’est pas en lecture
pour tous.
Attention
Aussi étonnant que cela puisse paraître, il arrive encore que certains systèmes très anciens stockent les
empreintes dans le fichier /etc/passwd. Or, il se trouve que ce fichier est en lecture pour tous. Ainsi, tout
un chacun peut lancer sur ce fichier un outil de cassage pour récupérer les mots de passe des comptes. Il
n’est pas inutile que le RSSI identifie les très vieux systèmes, car ils sont susceptibles de présenter cette
vulnérabilité.
Le mécanisme /etc/shadow a pour conséquence qu’il faut déclarer chaque utilisateur sur
chacun des serveurs. Si cette logique est acceptable à très petite échelle (une dizaine de
machines, tout au plus), elle devient très rapidement ingérable, car le moindre
changement dans la liste des utilisateurs doit être répercuté à la main sur tous les
serveurs. Dans le contexte d’exploitation d’un parc de plusieurs centaines de serveurs,
voire de plusieurs milliers, une autre solution est nécessaire. Cette autre solution consiste
à recourir à un annuaire centralisant tous les comptes et les empreintes qui leur sont
associées. Lorsqu’une personne veut se connecter sur un serveur, ce dernier consulte
l’annuaire avant de donner l’accès à l’utilisateur. Sur le principe, c’est une solution
proche de celle des contrôleurs de domaine Windows.
Un autre problème qui se pose est qu’il faut bien stocker quelque part les mots de passe
des comptes administrateur local des serveurs Windows, ainsi que les mots de passe des
comptes root de chaque système Unix. Dans un contexte d’exploitation de parc, il faut
donc centraliser tous ces éléments dans un fichier unique, connu de tous les
administrateurs et partagé par eux. De nombreux outils gratuits et payants, dédiés à cet
usage, permettent de chiffrer le fichier central contenant tous les mots de passe sensibles.
L’accès à ce fichier est protégé par un système d’authentification, qui va du simple mot
de passe, connu de tous les administrateurs, aux certificats clients, gérés dans le cadre
d’une PKI.
Ces outils sont de très bonne qualité et ont amplement fait leurs preuves. Cependant, ils
ont leurs limites lorsque les administrateurs sont nombreux et qu’ils sont amenés à
changer très régulièrement. Le mot de passe unique partagé par tous pour accéder au
fichier central des mots de passe d’administration devrait en principe être changé chaque
fois qu’un administrateur quitte la société. De son côté, la solution basée sur une PKI
nécessite une véritable gestion qui peut s’avérer très lourde à l’usage. D’autres approches
Dans un service d’exploitation, les administrateurs ont besoin de récupérer très
facilement le mot de passe des dispositifs sur lesquels ils doivent intervenir. Il faut donc
allier la protection de ces mots de passe avec une mise à disposition simple et rapide.
Pour résoudre cette problématique, plusieurs approches de gestion des mots de passe sont
envisageables.
Les systèmes Unix ont généralement vocation à être des serveurs. Aussi relativement peu
d’utilisateurs sont déclarés dans ces systèmes. Par défaut, les systèmes Unix entreposent
les empreintes des mots de passe dans le fichier /etc/shadow, qui n’est pas en lecture
pour tous.
Attention
Aussi étonnant que cela puisse paraître, il arrive encore que certains systèmes très anciens stockent les
empreintes dans le fichier /etc/passwd. Or, il se trouve que ce fichier est en lecture pour tous. Ainsi, tout
un chacun peut lancer sur ce fichier un outil de cassage pour récupérer les mots de passe des comptes. Il
n’est pas inutile que le RSSI identifie les très vieux systèmes, car ils sont susceptibles de présenter cette
vulnérabilité.
Le mécanisme /etc/shadow a pour conséquence qu’il faut déclarer chaque utilisateur sur
chacun des serveurs. Si cette logique est acceptable à très petite échelle (une dizaine de
machines, tout au plus), elle devient très rapidement ingérable, car le moindre
changement dans la liste des utilisateurs doit être répercuté à la main sur tous les
serveurs. Dans le contexte d’exploitation d’un parc de plusieurs centaines de serveurs,
voire de plusieurs milliers, une autre solution est nécessaire. Cette autre solution consiste
à recourir à un annuaire centralisant tous les comptes et les empreintes qui leur sont
associées. Lorsqu’une personne veut se connecter sur un serveur, ce dernier consulte
l’annuaire avant de donner l’accès à l’utilisateur. Sur le principe, c’est une solution
proche de celle des contrôleurs de domaine Windows.
Un autre problème qui se pose est qu’il faut bien stocker quelque part les mots de passe
des comptes administrateur local des serveurs Windows, ainsi que les mots de passe des
comptes root de chaque système Unix. Dans un contexte d’exploitation de parc, il faut
donc centraliser tous ces éléments dans un fichier unique, connu de tous les
administrateurs et partagé par eux. De nombreux outils gratuits et payants, dédiés à cet
usage, permettent de chiffrer le fichier central contenant tous les mots de passe sensibles.
L’accès à ce fichier est protégé par un système d’authentification, qui va du simple mot
de passe, connu de tous les administrateurs, aux certificats clients, gérés dans le cadre
d’une PKI.
Ces outils sont de très bonne qualité et ont amplement fait leurs preuves. Cependant, ils
ont leurs limites lorsque les administrateurs sont nombreux et qu’ils sont amenés à
changer très régulièrement. Le mot de passe unique partagé par tous pour accéder au
fichier central des mots de passe d’administration devrait en principe être changé chaque
fois qu’un administrateur quitte la société. De son côté, la solution basée sur une PKI
nécessite une véritable gestion qui peut s’avérer très lourde à l’usage. D’autres approches