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)
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, nous utilisons constamment utilisateur de bases de données 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, par lequel il détermine si l'application client (ou l'utilisateur sous le nom de laquelle elle fonctionne) est autorisée à se connecter sous le nom d'utilisateur demandé de la base de données.
PostgreSQL™ offre quantité de méthodes d'authentification différentes. La méthode d'authentification d'une connexion client particulière peut être sélectionnée d'après l'adresse, la base de données et l'utilisateur de l'hôte client.
Les noms d'utilisateurs de la base de données PostgreSQL™ sont séparés de façon logique des noms d'utilisateurs 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 des noms d'utilisateurs de la base de données qui correspondent aux noms d'utilisateurs du système d'exploitation. Cependant, un serveur qui accepte les connexions distantes peut avoir plusieurs utilisateurs de base de données dépourvus de compte correspondant sur le système d'exploitation, dans de tels cas il n'y a pas besoin de correspondance entre noms d'utilisateurs de bases de données et noms d'utilisateurs du système d'exploitation.
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 être continué sur plusieurs lignes.
Chaque enregistrement détermine 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 correspondant 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 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 :
Cet enregistrement intercepte les tentatives de connexion utilisant les sockets du domaine Unix. Sans un enregistrement de ce type, les connexions de sockets du domaine Unix ne sont pas autorisées.
Cet enregistrement intercepte les tentatives de connexion utilisant les réseaux TCP/IP. Les lignes host enregistrent des tentatives de connexion soit SSL soit non SSL.
Supprimer les connexions TCP/IP ne sera pas possible si le serveur est lancé avec la valeur appropriée pour le paramètre de configuration listen_addresses car le comportement par défaut est d'écouter les connexions TCP/IP provenant seulement de l'adresse local localhost.
Cet enregistrement intercepte les tentatives de connexions utilisant TCP/IP mais seulement quand ces connexions utilisent le chiffrement SSL.
Pour être en mesure de faire usage de cette fonction, le serveur doit être compilé avec le support de SSL. De plus, SSL doit être activé au lancement 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).
Cet enregistrement a une logique opposée à hostssl : il n'intercepte que les tentatives de connexion n'utilisant pas SSL.
Indique quels noms de bases de données l'enregistrement concerne. La valeur all indique qu'il concerne toutes les bases de données. La valeur sameuser spécifie que l'enregistrement n'intercepte que si la base de données demandée a le même nom que l'utilisateur demandé. La valeur samerole spécifie 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 façon alternative d'écrire samerole.). Sinon, c'est le nom d'une base de données PostgreSQL™ particulière. Des noms de bases de données multiples peuvent être fournis en les séparant par des virgules. Un fichier séparé contenant des noms de bases de données peut être indiqué en faisant précéder le nom de fichier de @.
Indique à quels utilisateurs de la base de données cet enregistrement correspond. La valeur all indique qu'il concerne tous les utilisateurs. Sinon, il s'agit soit du nom d'un utilisateur spécifique de la base de données soit d'un nom de groupe précédé par un + (rappelez-vous qu'il n'existe pas de vraies distinctions entre les utilisateurs et les groupes dans PostgreSQL™ ; un + signifie réellement « é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 avec des virgules. Un fichier séparé contenant des noms d'utilisateurs peut être spécifié en précédant le nom du fichier avec un @.
Spécifie l'échelle d'adresses IP du client auquel correspond cet enregistrement. Il contient une adresse IP dans la notation décimale standard et une longueur de masque CIDR (les adresses IP peuvent seulement être spécifiées numériquement, mais pas en tant que nom d'hôte ou de domaine). La longueur du masque indique le nombre de bits pour lequel une correspondance doit être apportée avec l'adresse IP du client. Les bits à droite doivent valoir zéro dans l'adresse IP indiquée. Il ne doit y avoir aucun espace blanc 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 ou 172.20.143.0/24 pour un réseau. Pour spécifier un seul hôte, utilisez un masque de 32 pour IPv4 ou 128 pour IPv6.
Une adresse IP au format IPv4 correspondra aux connexions IPv6 qui auront l'adresse correspondante. Par exemple, 127.0.0.1 correspondra à l'adresse IPv6 ::ffff:127.0.0.1. Une entrée donnée au format IPv6 correspondra uniquement aux connexions IPv6 même si l'adresse représentée est dans le domaine IPv4-vers-IPv6. Notez que les adresses au format IPv6 seront 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.
Ces champs pourraient être utilisés comme alternative à la notation CIDR-address. Au lieu de spécifier la longueur du masque, le masque actuel est spécifié comme une colonne séparée. 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.
Détermine 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 ».
Autorise la connexion sans conditions. Cette méthode permet à n'importe qui de se connecter au serveur de bases de données PostgreSQL™, de s'enregistrer comme n'importe quel utilisateur PostgreSQL™ de son choix sans nécessiter de mot de passe. Voir la Section 20.2.1, « Authentification Trust » pour les détails.
Rejette la connexion sans conditions. Ce cas est utile pour « filtrer » certains hôtes d'un groupe.
Demande au client de fournir un mot de passe chiffré MD5 pour son authentification. Voir la Section 20.2.2, « Authentification par mot de passe » pour les détails.
Cette option est seulement recommandée pour pouvoir 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.
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 sûrs. De plus, cette option ne fonctionne pas avec les applications clients compatibles avec les threads. Voir la Section 20.2.2, « Authentification par mot de passe » pour les détails.
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.
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 en tant qu'utilisateur de la base de données demandé en consultant la correspondance indiquée après le mot clé ident. Voir la Section 20.2.4, « Authentification basée sur l'identification » ci-dessous pour les détails.
Authentifie en utilisant les Pluggable Authentification Modules (PAM) fournis par le système d'exploitation. Voir la Section 20.2.5, « Authentification PAM » pour les détails.
La signification de ce champ optionnel dépend de la méthode d'authentification choisie. Des 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 par soit des espaces blancs soit des virgules. Les commentaires sont introduits par le caractère # comme dans pg_hba.conf, et les constructions @ imbriquées sont autorisées. Sauf si le nom du fichier suivant @ est 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 significatif. Généralement, les premiers enregistrements auront des paramètres d'interception de connexions plus stricts alors que les enregistrements suivants auront des paramètres plus larges et des méthodes d'authentification plus fortes. Par exemple, on pourrait 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, un enregistrement spécifiant une authentification trust pour les connexions issues de 127.0.0.1 apparaîtrait avant un enregistrement spécifiant une authentifications 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 quand le processus serveur principal (postmaster) reçoit un signal SIGHUP. Si vous éditez le fichier sur un système actif, vous aurez à signaler au postmaster (en utilisant pg_ctl reload ou kill -HUP) de relire le fichier.
Quelques exemples des entrées de pg_hba.conf sont décrit 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
# Permet à n'importe quel utilisateur du système local de se connecter à la base # de données sous n'importe quel nom d'utilisateur de la base de données en # utilisant les sockets du domaine Unix. (par défaut pour les connexions locales) # # TYPE DATABASE USER CIDR-ADDRESS METHOD local all all trust # Identique à ci-dessus mais utilise les connexions TCP/IP locales loopback. # # TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 127.0.0.1/32 trust # Identique à la dernière ligne mais en utilisant une colonne netmask séparée CDIR. # # TYPE DATABASE USER IP-ADDRESS IP-mask METHOD host all all 127.0.0.1 255.255.255.255 trust # Permet à n'importe que 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 même nom # d'utilisateur que l'identification le 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 fourni sans # erreur. # # TYPE DATABASE USER CIDR-ADDRESS METHOD host postgres all 192.168.12.10/32 md5 # En l'absence de lignes "host" antérieures, ces deux lignes rejetteront toutes # les connexions en provenance de 192.168.54.1 (puisque cette entrée déclenchera # en premier), mais autorisera les connexions Kerberos 5 de n'importe où # ailleurs sur l'Internet. Le masque zéro signifie qu'aucun bit sur 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 # Permet à tous les utilisateurs de se connecter depuis 192.168.x.x à n'importe # quelle base de données si ils passent la verification d'identification. Si, # par exemple, l'identification 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 ce sont les trois seules lignes traitant les connexions locales, elles # autoriseront les utilisateurs locaux à se connecter uniquement à leur propre # base de données (bases de données ayant le même nom que leur nom # d'utilisateur de la base de données) exception faite pour les administrateurs # et les 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