20. Authentification du client
Quand une application client se connecte au serveur de base de
données, elle indique le nom de l'utilisateur de la base de données
PostgreSQL™ sous lequel elle
désire se connecter, comme lorsqu'on se connecte sur un ordinateur
Unix sous un nom d'utilisateur particulier. Au sein de
l'environnement SQL, le nom d'utilisateur de la base de données
active détermine les droits régissant l'accès aux objets de la base
de données -- voir le Chapitre 18,
Rôles et droits de la base de données pour plus d'informations.
Ainsi, il est essentiel de limiter le nombre des bases de données
auxquelles les utilisateurs peuvent se connecter.
![[Note]](images/note.png)
Note
Comme expliqué dans le Chapitre 18,
Rôles et droits de la base de données, PostgreSQL™ gère les droits par
l'intermédiaire des « rôles ». Dans ce chapitre, le terme
utilisateur de bases de données est
utilisé pour signifier « rôle disposant
du droit LOGIN
».
L'authentification est le processus par
lequel le serveur de bases de données établit l'identité du client
et, par extension, détermine si l'application client (ou
l'utilisateur qui l'utilise) est autorisée à se connecter avec le nom
d'utilisateur de la base de données indiqué.
PostgreSQL™ offre quantité de
méthodes d'authentification différentes. La méthode utilisée pour
authentifier une connexion client particulière peut être sélectionnée
d'après l'adresse (du client), la base de données et l'utilisateur.
Les noms d'utilisateur de la base de données sont séparés de façon
logique des noms d'utilisateur du système d'exploitation sur lequel
tourne le serveur. Si tous les utilisateurs d'un serveur donné ont
aussi des comptes sur la machine serveur, il peut être pertinent
d'attribuer aux utilisateurs de la base de données des noms qui
correspondent à ceux des utilisateurs du système d'exploitation.
Cependant, un serveur qui accepte des connexions distantes peut avoir
des utilisateurs de base de données dépourvus de compte correspondant
sur le système d'exploitation. Dans ce cas, aucune correspondance
entre les noms n'est nécessaire.
20.1. Le fichier pg_hba.conf
L'authentification du client est contrôlée par un fichier,
traditionnellement nommé pg_hba.conf et
situé dans le répertoire data du groupe de bases de données, par
exemple /usr/local/pgsql/data/pg_hba.conf
(HBA signifie
« host-based authentication »
: authentification fondée sur l'hôte.) Un fichier pg_hba.conf par défaut est installé lorsque le
répertoire data est initialisé par
initdb
. Néanmoins, il est
possible de placer le fichier de configuration de
l'authentification ailleurs ; voir le paramètre de configuration
hba_file.
Le format général du fichier pg_hba.conf
est un ensemble d'enregistrements, un par ligne. Les lignes vides
sont ignorées tout comme n'importe quel texte placé après le
caractère de commentaire #. Un
enregistrement est constitué d'un certain nombre de champs séparés
par des espace et/ou des tabulations. Les champs peuvent contenir
des espaces si la valeur du champ est mise entre guillemets. Un
enregistrement ne peut pas s'étendre sur plusieurs lignes.
Chaque enregistrement précise un type de connexion, une plage
d'adresses IP (si approprié au type de connexion), un nom de base
de données, un nom d'utilisateur et la méthode d'authentification à
utiliser pour les connexions correspondant à ces paramètres. Le
premier enregistrement qui correspond au type de connexion, à
l'adresse client, à la base de données demandée et au nom
d'utilisateur est utilisé pour effectuer l'authentification. Il n'y
a pas de suite après une erreur (« fall-through » ou « backup ») : si un enregistrement est choisi et
que l'authentification échoue, les enregistrements suivants ne sont
pas considérés. Si aucun enregistrement ne correspond, l'accès est
refusé.
Un enregistrement peut avoir l'un des formats suivants.
local database user auth-method [auth-option]
host database user CIDR-address auth-method [auth-option]
hostssl database user CIDR-address auth-method [auth-option]
hostnossl database user CIDR-address auth-method [auth-option]
host database user IP-address IP-mask auth-method [auth-option]
hostssl database user IP-address IP-mask auth-method [auth-option]
hostnossl database user IP-address IP-mask auth-method [auth-option]
La signification des champs est la suivante :
-
local
-
Cet enregistrement intercepte les tentatives de connexion qui
utilise les sockets du domaine Unix. Sans enregistrement de
ce type, les connexions de sockets du domaine Unix ne sont
pas autorisées.
-
host
-
Cet enregistrement intercepte les tentatives de connexion par
TCP/IP. Les lignes host s'appliquent
à toute tentative de connexion, SSL ou non.
Note
Les connexions TCP/IP ne sont pas autorisées si le
serveur n'est pas démarré avec la valeur appropriée du
paramètre de configuration listen_addresses.
En effet, par défaut, le serveur n'écoute que les
connexions TCP/IP en provenance de l'adresse loopback locale, localhost.
-
hostssl
-
Cet enregistrement intercepte les seules tentatives de
connexions par TCP/IP qui utilisent le chiffrement
SSL.
Pour utiliser cette fonction, le serveur doit être compilé
avec le support de SSL. De
plus, SSL doit être activé
au démarrage du serveur en positionnant le paramètre de
configuration ssl (voir la
Section 16.7,
« Connexions tcp/ip sécurisées avec ssl » pour
plus d'informations).
-
hostnossl
-
Cet enregistrement a une logique opposée à hostssl : il n'intercepte que les tentatives
de connexion qui n'utilisent pas SSL.
-
database
-
Indique les noms des bases de données concernées par
l'enregistrement. La valeur all
indique qu'il concerne toutes les bases de données. Le terme
sameuser indique que
l'enregistrement coïncide si la base de données demandée a le
même nom que l'utilisateur demandé. Le terme samerole indique que l'utilisateur demandé
doit être membre du rôle portant le même nom que la base de
données demandée (samegroup est
obsolète bien qu'il soit toujours accepté comme écriture
alternative de samerole.). Dans tous
les autres cas, c'est le nom d'une base de données
particulière. Des noms de bases de données multiples peuvent
être fournis en les séparant par des virgules. Un fichier
contenant des noms de bases de données peut être indiqué en
faisant précéder le nom du fichier de @.
-
user
-
Indique les utilisateurs de la base de données auxquels cet
enregistrement correspond. La valeur all indique qu'il concerne tous les
utilisateurs. Dans le cas contraire, il s'agit soit du nom
d'un utilisateur spécifique de la base de données ou d'un nom
de groupe précédé par un + (il
n'existe pas de véritable distinction entre les utilisateurs
et les groupes dans PostgreSQL™ ; un + signifie exactement « établit une correspondance pour tous les rôles
faisant parti directement ou indirectement de ce
rôle » alors qu'un nom sans + établit une correspondance avec ce rôle
spécifique). Plusieurs noms d'utilisateurs peuvent être
fournis en les séparant par des virgules. Un fichier
contenant des noms d'utilisateurs peut être indiqué en
faisant précéder le nom du fichier de @.
-
CIDR-address
-
Indique la plage d'adresses IP client à laquelle correspond
cet enregistrement. Il contient une adresse IP dans la
notation décimale standard et une longueur de masque CIDR
(les adresses IP ne peuvent qu'être indiquées numériquement,
pas en tant que nom d'hôte ou de domaine). La longueur du
masque indique le nombre de bits forts pour lesquels une
correspondance doit être trouvée avec l'adresse IP du client.
Les bits de droite doivent valoir zéro dans l'adresse IP
indiquée. Il ne doit y avoir aucune espace entre l'adresse
IP, le / et la longueur du masque
CIDR.
Une adresse CIDR (
CIDR-address
) est typiquement
172.20.143.89/32 pour un hôte seul,
172.20.143.0/24 pour un petit réseau
ou 10.6.0.0/16 pour un réseau plus
grand. Pour n'indiquer qu'un seul hôte, on utilise un masque
de 32 pour IPv4 ou 128 pour IPv6. Dans une adresse réseau, ne
pas oublier les zéros finaux.
Une adresse IP indiquée au format IPv4 coïncide avec les
connexions IPv6 d'adresse correspondante. Par exemple,
127.0.0.1 correspond à l'adresse
IPv6 ::ffff:127.0.0.1. Une entrée
donnée au format IPv6 correspond uniquement aux connexions
IPv6 même si l'adresse représentée est dans le domaine
IPv4-vers-IPv6. Les adresses au format IPv6 sont rejetées si
la bibliothèque système C ne supporte pas les adresses IPv6.
Ce champ ne concerne que les enregistrements host, hostssl et
hostnossl.
-
IP-address
,
IP-mask
-
Ces champs peuvent être utilisés comme alternative à la
notation
CIDR-address
.
Au lieu de spécifier la longueur du masque, le masque réel
est indiquée dans une colonne distincte. Par exemple,
255.0.0.0 représente une longueur de
masque CIDR IPv4 de 8, et 255.255.255.255 représente une longueur de
masque de 32.
Ces champ ne concernent que les enregistrements host, hostssl et
hostnossl.
-
auth-method
-
Indique la méthode d'authentification à utiliser lors d'une
connexion via cet enregistrement. Les choix possibles sont
résumés ici ; les détails se trouvent dans la Section 20.2,
« Méthodes d'authentification ».
-
trust
-
Autorise la connexion sans condition. Cette méthode
permet à quiconque peut se connecter au serveur de
bases de données de s'enregistrer sous n'importe quel
utilisateur PostgreSQL™ de son choix
sans mot de passe. Voir la Section 20.2.1,
« Authentification trust » pour les
détails.
-
reject
-
Rejette la connexion sans condition. Ce cas est utile
pour « filtrer »
certains hôtes d'un groupe.
-
md5
-
Demande au client de fournir un mot de passe chiffré
MD5 pour l'authentification. Voir la Section 20.2.2,
« Authentification par mot de passe »
pour les détails.
-
crypt
-
Note
Cette option est uniquement recommandée pour
communiquer avec les clients de version antérieure
à la 7.2.
Requiert que le client fournisse un mot de passe
chiffré avec crypt() pour
l'authentification. md5 est
maintenant recommandé à la place de crypt. Voir la Section 20.2.2,
« Authentification par mot de passe »
pour les détails.
-
password
-
Requiert que le client fournisse un mot de passe non
chiffré pour l'authentification. Comme le mot de passe
est envoyé en clair sur le réseau, ceci ne doit pas
être utilisé sur des réseaux non dignes de confiance.
De plus, cette option ne fonctionne pas avec les
applications client qui utilisent les threads. Voir la
Section 20.2.2,
« Authentification par mot de passe »
pour les détails.
-
krb5
-
Utilise Kerberos V5 pour authentifier l'utilisateur.
Ceci n'est disponible que pour les connexions TCP/IP.
Voir la Section 20.2.3,
« Authentification Kerberos » pour les
détails.
-
ident
-
Récupère le nom de l'utilisateur du système
d'exploitation du client (pour les connexions TCP/IP en
contactant le serveur d'identification sur le client,
pour les connexions locales en l'obtenant du système
d'exploitation) et vérifie si l'utilisateur est
autorisé à se connecter avec l'utilisateur de base de
données indiqué en consultant la correspondance
indiquée après le mot clé ident. Voir la Section 20.2.4,
« Authentification fondée sur ident »
ci-dessous pour les détails.
-
ldap
-
Authentifie avec LDAP comme serveur central. Voir la
Section 20.2.5,
« Authentification LDAP » pour les
détails.
-
pam
-
Authentifie avec les Pluggable Authentification Modules
(PAM) fournis par le système d'exploitation. Voir la
Section 20.2.6,
« Authentification PAM » pour les
détails.
-
auth-option
-
La signification de ce champ optionnel dépend de la méthode
d'authentification choisie. Les détails sont disponibles
ci-dessous.
Les fichiers inclus par les constructions @ sont lus comme des listes de noms, qui peuvent
être séparés soit par des espaces soit par des virgules. Les
commentaires sont introduits par le caractère # comme dans pg_hba.conf,
et les constructions @ imbriquées sont
autorisées. À moins que le nom du fichier qui suit @ ne soit un chemin absolu, il est supposé relatif
au répertoire contenant le fichier le référençant.
Les enregistrements du fichier pg_hba.conf sont examinés séquentiellement pour
chaque tentative de connexion, l'ordre des enregistrements est donc
significatif. Généralement, les premiers enregistrements ont des
paramètres d'interception de connexions stricts et des méthodes
d'authentification peu restrictives tandis que les enregistrements
suivants ont des paramètres plus larges et des méthodes
d'authentification plus fortes. Par exemple, on peut souhaiter
utiliser l'authentification trust pour les
connexions TCP/IP locales mais demander un mot de passe pour les
connexion TCP/IP distantes. Dans ce cas, l'enregistrement précisant
une authentification trust pour les
connexions issues de 127.0.0.1 apparaît avant un enregistrement
indiquant une authentification par mot de passe pour une plage plus
étendue d'adresses IP client autorisées.
Le fichier pg_hba.conf est lu au
démarrage et lorsque le processus serveur principal reçoit un
signal SIGHUP. Si le fichier est édité
sur un système actif, on peut signaler au serveur (en utilisant
pg_ctl reload ou kill
-HUP) de relire le fichier.
![[Astuce]](images/tip.png)
Astuce
Pour se connecter à une base particulière, un utilisateur doit
non seulement passer les vérifications de pg_hba.conf mais doit également avoir le droit
CONNECT sur cette base. Pour contrôler
qui peut se connecter à quelles bases, il est en général plus
facile de le faire en donnant ou retirant le privilège
CONNECT plutôt qu'en plaçant des
règles dans le fichier pg_hba.conf.
Quelques exemples d'entrées de pg_hba.conf sont donnés ci-dessous dans l'Exemple 20.1,
« Exemple d'entrées de pg_hba.conf ». Voir la section suivante
pour les détails des méthodes d'authentification.
Exemple 20.1. Exemple d'entrées de pg_hba.conf
# Permettre à n'importe quel utilisateur du système local de se connecter
# à la base de données sous n'importe quel nom d'utilisateur au travers
# des sockets de domaine Unix (par défaut pour les connexions locales).
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
local all all trust
# La même chose en utilisant les connexions TCP/IP locales loopback.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 127.0.0.1/32 trust
# Pareil mais en utilisant une colonne netmask distincte.
#
# TYPE DATABASE USER IP-ADDRESS IP-mask METHOD
host all all 127.0.0.1 255.255.255.255 trust
# Permettre à n'importe quel utilisateur de n'importe quel hôte avec l'adresse IP
# 192.168.93.x de se connecter à la base de données "postgres" sous le nom
# d'utilisateur qu'ident signale à la connexion (généralement le
# nom utilisateur Unix).
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host postgres all 192.168.93.0/24 ident sameuser
# Permet à un utilisateur de l'hôte 192.168.12.10 de se connecter à la base de
# données "postgres" si le mot de passe de l'utilisateur est correctement fourni.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host postgres all 192.168.12.10/32 md5
# Si aucune ligne "host" ne précède, ces deux lignes rejettent toutes
# les connexions en provenance de 192.168.54.1 (puisque cette entrée déclenche
# en premier), mais autorisent les connexions Kerberos 5 de n'importe où
# ailleurs sur l'Internet. Le masque zéro signifie qu'aucun bit de l'ip de
# l'hôte n'est considéré, de sorte à correspondre à tous les hôtes.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 192.168.54.1/32 reject
host all all 0.0.0.0/0 krb5
# Permettre à tous les utilisateurs de se connecter depuis 192.168.x.x à n'importe
# quelle base de données s'ils passent la verification d'identification. Si,
# par exemple, ident indique que l'utilisateur est "bryanh" et qu'il
# demande à se connecter en tant qu'utilisateur PostgreSQL "guest1", la
# connexion n'est permise que s'il existe une entrée dans pg_ident.conf pour la
# correspondance "omicron" disant que "bryanh" est autorisé à se connecter en
# tant que "guest1".
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
host all all 192.168.0.0/16 ident omicron
# Si ces trois lignes traitant seules les connexions locales, elles
# n'autorisent les utilisateurs locaux qu'à se connecter à leur propre
# base de données (bases ayant le même nom que leur nom
# d'utilisateur) exception faite des administrateurs
# et des membres du rôle "support" qui peuvent se connecter à toutes les bases
# de données. Le fichier $PGDATA/admins contient une liste de noms
# d'administrateurs. Un mot de passe est requis dans tous les cas.
#
# TYPE DATABASE USER CIDR-ADDRESS METHOD
local sameuser all md5
local all @admins md5
local all +support md5
# Les deux dernières lignes ci-dessus peuvent être combinées en une seule ligne :
local all @admins,+support md5
# La colonne database peut aussi utiliser des listes et des noms de fichiers :
local db1,db2,@demodbs all md5
|
Tablespaces
