4.2 Règles de sécurité et droits d'accès au serveur MySQL
4 Administration du serveur
Manuel de Référence MySQL 4.1 : Version Française
. Instructions générales de sécurité
. Comment protéger MySQL contre les pirates
. Options de démarrage qui concernent la sécurité
. Problèmes de sécurité avec LOAD DATA LOCAL
. Rôle du système de privilèges
. Comment fonctionne le système de droits
. Droits fournis par MySQL
. Se connecter au serveur MySQL
->Contrôle d'accès, étape 1 : Vérification de la connexion
. Contrôle d'accès, étape 2 : Vérification de la requête
. Causes des erreurs Access denied
|
4.2.9 Contrôle d'accès, étape 1 : Vérification de la connexion
Lorsque vous tentez de vous connecter au serveur MySQL,
le serveur accepte ou rejette la connexion en fonction de votre
identité et du mot de passe que vous fournissez. Si le mot de passe
ne correspond pas à celui qui est en base, le serveur vous interdit
complètement l'accès. Sinon, le serveur accepte votre connexion et passe
à l'étape 2, et la gestion de commandes.
Votre identité est basée sur trois informations :
-
L'hôte depuis lequel vous vous connectez
-
Votre nom d'utilisateur MySQL
-
Votre mot de passe
La vérification d'identité est réalisée avec les trois colonnes de la table
user
(
Host
,
User
et
Password
). Le serveur accepte la
connexion uniquement si une entrée dans la table
user
correspond à votre
hôte, et que vous fournissez le mot de passe qui correspond.Les valeurs de la table
user
peuvent être paramétrées comme ceci :
-
Une valeur de la colonne
Host
peut être un nom d'hôte, une adresse IP
numérique, ou encore
'localhost'
, qui représente l'hôte local.
-
Vous pouvez utiliser les caractères jokers
'%'
et
'_'
dans le champ
Host
.
-
Une valeur de
'%'
dans la colonne
Host
remplace n'importe quelle autre
valeur.
-
Une valeur vide pour la colonne
Host
indique que les droits doivent être
gérés avec les entrées de la table
host
qui correspond à l'hôte se connectant.
Vous trouverez plus d'informations à ce sujet dans le prochain chapitre.
-
Depuis MySQL version 3.23, les valeurs de
Host
spécifiées sous la forme
d'IP numériques peuvent être complétées avec le masque de réseau qui indique
combien de bits d'adresse sont utilisés. Par exemple :
mysql> GRANT ALL PRIVILEGES ON db.*
-> TO david@'192.58.197.0/255.255.255.0';
|
Cela permet à toute personne se connectant depuis une adresse IP qui
satisfait la contrainte suivante :
user_ip & netmask = host_ip.
|
Dans l'exemple ci-dessus, toutes les IP dans l'intervalle 192.58.197.0 - 192.58.197.255
pourront se connecter au serveur MySQL.
-
Les caractères joker ne sont pas autorisés dans le champ
User
, mais vous
pouvez spécifier une valeur vide qui remplacera tous les noms. Si l'entrée de la
table
user
, qui correspond à une connexion entrante, a un nom d'utilisateur
vide, l'utilisateur est alors considéré comme anonyme (c'est l'utilisateur sans
nom) et non pas le nom d'utilisateur fourni. Cela signifie qu'un utilisateur
fournissant un nom d'utilisateur vide sera utilisé pour identifier ses droits
dans les prochaines étapes.
-
Le champ
Password
peut être vide. Cela ne signifie pas que n'importe quel
mot de passe est valable, mais que l'utilisateur peut se connecter sans fournir
de mot de passe.
Les valeurs non vides du champ
Password
représentent des valeurs
du mot de passe chiffrées. MySQL ne stocke pas les mots de passe en
clair, à la vue de tous. Au contraire, le mot de passe fourni pas l'utilisateur
qui tente de se connecter est chiffré (avec la fonction
PASSWORD()
).
Le mot de passe ainsi chiffré est alors utilisé entre le client et le serveur
pour vérifier s'il est valable. Cela évite que des mots
de passe en clair circulent entre le client et le serveur, sur la connexion.
Notez que du point de vue de MySQL, le mot de passe chiffré est le vrai
mot de passe, ce qui fait que vous ne devez en aucun cas le donner à un
tiers. En particulier, ne donnez pas accès en lecture aux utilisateurs normaux
aux tables d'administration dans la base
mysql
!
A partir de sa version 4.1, MySQL utilise un mécanisme différent pour les logins,
mots de passes qui est sécurisé même si les paquets TCP/IP sont sniffés et/ou que
la base de données mysql est capturée.Les exemples ci-dessous illustrent comment différentes variantes de
Host
et
User
dans la table
user
s'appliquent aux
connexion entrantes :
|
Host
value
|
User
value
|
Connexions autorisées
|
|
'thomas.loc.gov'
|
'fred'
|
fred
, se connectant depuis
thomas.loc.gov
|
|
'thomas.loc.gov'
|
''
|
N'importe quel utilisateur, se connectant depuis
thomas.loc.gov
|
|
'%'
|
'fred'
|
fred
, se connectant depuis n'importe quel hôte
|
|
'%'
|
''
|
N'importe quel utilisateur, se connectant depuis n'importe quel hôte
|
|
'%.loc.gov'
|
'fred'
|
fred
, se connectant depuis n'importe quel hôte dans le domaine
loc.gov
|
|
'x.y.%'
|
'fred'
|
fred
, se connectant depuis
x.y.net
,
x.y.com
,
x.y.edu
, etc. (Ceci n'est probablement pas très utilisé)
|
|
'144.155.166.177'
|
'fred'
|
fred
, se connectant depuis l'hôte d'IP
144.155.166.177
|
|
'144.155.166.%'
|
'fred'
|
fred
, se connectant depuis un hôte d'IP dans la classe C
144.155.166
|
|
'144.155.166.0/255.255.255.0'
|
'fred'
|
Identique à l'exemple précédent
|
Comme vous pouvez utiliser des caractères jokers dans les adresses IP de la
colonne
Host
(par exemple,
'144.155.166.%'
pour identifier tout un sous-réseau),
il est possible d'exploiter cette fonctionnalité en nommant un hôte
144.155.166.kekpart.com
. Pour contrer de telles tentatives, MySQL
interdit les caractères jokers avec les noms d'hôtes qui commencent par des
chiffres ou des points. Par exemple, si vous avez un nom d'hôte tel que
1.2.foo.com
, il ne sera jamais trouvé dans la colonne
Host
des tables de droits. Seule une adresse IP numérique peut
être comparée avec un masque à caractère joker.
Une connexion entrante peut être identifiée par plusieurs entrées dans la
table
user
. Par exemple, une connexion depuis
thomas.loc.gov
par
fred
sera identifiée de plusieurs façons différentes dans
l'exemple ci-dessus. Comment le serveur va-t-il choisir si il y a plusieurs
solutions ? Le serveur résoud cette question en triant les utilisateurs dans la colonne
user
après le démarrage, et il recherchera dans cette liste triée
lorsqu'un utilisateur tente de se connecter. La première ligne qui
satisfait les critères sera alors utilisée.
Le tri de la table
user
suit les règles suivantes. Supposons que votre
table
user
ressemble à ceci :
+-----------+----------+-
| Host | User | ...
+-----------+----------+-
| % | root | ...
| % | jeffrey | ...
| localhost | root | ...
| localhost | | ...
+-----------+----------+-
|
Lorsque le serveur lit cette table, il ordonne les lignes depuis les
valeurs les plus spécialisées de la colonne
Host
jusqu'aux plus
générales (
'%'
dans la colonne
Host
signifie ``tous les hôtes''
et elle est la moins spécifique). Les entrées identiques dans la colonne
Host
sont ordonnées en fonction de la spécificité des valeurs de la colonne
User
(une entrée vide dans la colonne
User
signifie ``n'importe quel utilisateur''
et est spécifique). Le résultat de ce tri donne quelque chose comme ceci :
+-----------+----------+-
| Host | User | ...
+-----------+----------+-
| localhost | root | ...
| localhost | | ...
| % | jeffrey | ...
| % | root | ...
+-----------+----------+-
|
Lorsqu'une connexion est en cours de mise en place, le serveur
regarde dans cette liste, et utilisera la première entrée trouvée. Pour une connexion
depuis l'hôte
localhost
avec le nom d'utilisateur
jeffrey
, les
entrées
'localhost'
dans la colonne
Host
sont trouvées en premier.
Parmi celles-la, la ligne avec un utilisateur vide satisfait les deux contraintes
sur le nom et l'hôte.
'%'/'jeffrey'
pourrait avoir fonctionné, mais comme
ce n'est pas le premier rencontré, il n'est pas utilisé.
Voici un autre exemple. Supposons que la table
user
ressemble à ceci :
+----------------+----------+-
| Host | User | ...
+----------------+----------+-
| % | jeffrey | ...
| thomas.loc.gov | | ...
+----------------+----------+-
|
La table triée ressemble à ceci :
+----------------+----------+-
| Host | User | ...
+----------------+----------+-
| thomas.loc.gov | | ...
| % | jeffrey | ...
+----------------+----------+-
|
Une connexion depuis l'hôte
thomas.loc.gov
avec
jeffrey
satisfait les
conditions de la première ligne, tandis qu'une connexion depuis
whitehouse.gov
avec
jeffrey
satisfait la seconde ligne.Une erreur commune est de penser que pour un utilisateur donné, toutes les
entrées qui utilisent explicitement ce nom seront utilisées en premier lorsque
la connexion est en cours d'établissement. Ceci est tout simplement faux.
L'exemple précédent illustre cette situation, car la connexion depuis l'hôte
thomas.loc.gov
avec
jeffrey
est la première ligne qui est
trouvée, alors que la ligne contenant
'jeffrey'
dans la colonne
User
est ignorée, car il n'y a pas de nom d'utilisateur.
Si vous avez des problèmes lors de la connexion, listez le contenu de la table
user
et triez-la à la main pour savoir quel est la première ligne
qui est trouvée et utilisée.
Si la connexion s'est bien passée, mais que vos privilèges vous semblent
faux, utilisez la fonction
CURRENT_USER()
(ajoutée en version
4.0.6) pour voir quel combinaison d'utilisateur/hôte votre connexion
a utilisé. Fonctions diverses .
|
