Les sous-sections suivantes décrivent les méthodes d'authentification en détail.
Quand l'authentification trust est utilisée, PostgreSQL™ considère que quiconque peut se connecter au serveur est autorisé à accéder à la base de données quel que soit le nom d'utilisateur de bases de données qu'il fournit (ce qui inclut les super-utilisateurs). Les restrictions apportées dans les colonnes database et user continuent évidemment de s'appliquer. Cette méthode ne doit être utilisée que si le système assure un contrôle adéquat des connexions au serveur.
L'authentification trust est appropriée et très pratique pour les connexions locales sur une station de travail mono-utilisateur. Elle n'est généralement pas appropriée en soi sur une machine multi-utilisateur. Cependant, trust peut tout de même être utilisé sur une machine multi-utilisateur, si l'accès au fichier socket de domaine Unix est restreint par les permissions du système de fichiers. Pour ce faire, on peut positionner les paramètres de configuration unix_socket_permissions (et au besoin unix_socket_group) comme cela est décrit dans la Section 18.3, « Connexions et authentification ». On peut également positionner le paramètre de configuration unix_socket_directory pour placer le fichier de socket dans un répertoire à l'accès convenablement restreint.
Le réglage des droits du système de fichiers n'a d'intérêt que le cas de connexions par les sockets Unix. Cela ne restreint pas les connexions TCP/IP locales ; ainsi, pour utiliser les droits du système de fichiers pour assurer la sécurité locale, il faut supprimer la ligne host ...127.0.0.1 ... de pg_hba.conf ou la modifier pour utiliser une méthode d'authentification différente de trust.
L'authentification trust n'est envisageable, pour les connexions TCP/IP, que si chaque utilisateur de chaque machine autorisée à se connecter au serveur par les lignes trust du fichier pg_hba.conf est digne de confiance. Il est rarement raisonnable d'utiliser trust pour les connexions autres que celles issues de localhost (127.0.0.1).
Les méthodes fondées sur une authentification par mot de passe sont md5, crypt et password. Ces méthodes fonctionnent de façon analogue à l'exception du mode d'envoi du mot de passe à travers la connexion : respectivement, hachage MD5, chiffrement via crypt et texte en clair. Une limitation de la méthode crypt est qu'elle ne fonctionne pas avec les mots de passe chiffrés dans pg_authid.
S'il existe un risque d'attaque par « interception (sniffing) » des mots de passe, il est préférable d'utiliser md5, crypt devant être limité aux client pré-7.2. L'utilisation de password, en clair, est tout particulièrement à éviter lors de connexions ouvertes sur l'Internet (à moins d'utiliser SSL, SSH ou tout autre système de sécurisation par encapsulation de la connexion).
Les mots de passe PostgreSQL™ sont distincts des mots de passe du système d'exploitation. Le mot de passe de chaque utilisateur est enregistré dans le catalogue système pg_authid. Ils peuvent être gérés avec les commandes SQL CREATE USER et ALTER USER. Ainsi, par exemple, CREATE USER foo WITH PASSWORD 'secret';. Par défaut, c'est à dire si aucun mot de passe n'est indiqué, le mot de passe enregistré est nul et l'authentification par mot de passe échoue systématiquement pour cet utilisateur.
GSSAPI™ est un protocole du standard de l'industrie pour l'authentification sécurisée définie dans RFC 2743. PostgreSQL™ supporte GSSAPI™ avec l'authentification Kerberos™ suivant la RFC 1964. GSSAPI™ fournit une authentification automatique (single sign-on) pour les systèmes qui le supportent. L'authentification elle-même est sécurisée mais les données envoyées sur la connexion seront en clair sauf si SSL est utilisé.
Quand GSSAPI™ passe par Kerberos™, il utilise un principal standard dans le format nomservice/nomhôte@domaine. Pour des informations sur les parties du principal et sur la façon de configurer les clés requises, voir Section 21.2.5, « Authentification Kerberos ». Le support de GSSAPI doit être activé lors de la construction de PostgreSQL™ ; voir Chapitre 15, Procédure d'installation de PostgreSQL™ pour plus d'informations.
SSPI™ est une technologie Windows™ pour l'authentification sécurisée avec single sign-on. PostgreSQL™ utilise SSPI dans un mode de négociation (negotiate) qui utilise Kerberos™ si possible et NTLM™ sinon. L'authentification SSPI™ ne fonctionne que lorsque serveur et client utilisent Windows™.
Lorsque Kerberos™ est utilisé, SSPI™ fonctionne de la même façon que GSSAPI™. Voir Section 21.2.3, « Authentification GSSAPI » pour les détails.
![[Note]](images/note.png)
L'authentification Kerberos native est obsolète et ne doit être utilisée que pour assurer la compatibilité ascendante. Les nouvelles installations et les mises à jour utiliseront préférentiellement le standard d'authentification de l'industrie, GSSAPI™ (voir Section 21.2.3, « Authentification GSSAPI »).
Kerberos™ est un système d'authentification sécurisée de standard industriel destiné à l'informatique distribuée sur un réseau public. La description de Kerberos™ dépasse largement les objectifs de ce document même dans les généralités, c'est assez complexe (bien que puissant). La FAQ Kerberos ou la page Kerberos du MIT sont un bon point de départ à l'exploration. Il existe plusieurs sources de distribution Kerberos™. Kerberos™ fournit une authentification sécurisée mais ne chiffre pas les requêtes ou les données passées sur le réseau ; pour cela, SSL doit être utilisé.
PostgreSQL™ supporte Kerberos version 5. Le support de Kerberos doit être activé lors de la construction de PostgreSQL™ ; voir le Chapitre 15, Procédure d'installation de PostgreSQL™ pour plus d'informations.
PostgreSQL™ opère comme un service Kerberos normal. Le nom du service principal est nomservice/nomhôte@domaine.
nomservice peut être configuré du côté serveur en utilisant le paramètre de configuration krb_srvname (voir aussi Section 30.1, « Fonctions de contrôle de connexion à la base de données »). La valeur par défaut à l'installation, postgres, peut être modifiée lors de la construction avec ./configure --with-krb-srvnam=quelquechose. Dans la plupart des environnements, il est inutile de modifier cette valeur. Néanmoins, pour supporter plusieurs installations de PostgreSQL™ sur le même hôte, cela devient nécessaire. Quelques implantations de Kerberos peuvent imposer un nom de service différent, comme Microsoft Active Directory qui réclame un nom du service en majuscules (POSTGRES).
nom_hote est le nom de l'hôte pleinement qualifié (fully qualified host name) de la machine serveur. Le domaine du service principal (client) est le domaine préféré du serveur.
Les principaux (clients) doivent contenir le nom de leur utilisateur PostgreSQL™ comme premier composant, nomutilisateurpg@domaine, par exemple. Par défaut, le domaine du client n'est pas vérifié par PostgreSQL™. Si l'authentification inter-domaine (cross-realm) est activée, on utilise le paramètre krb_realm.
Le fichier de clés du serveur doit être lisible (et de préférence uniquement lisible) par le compte serveur PostgreSQL™ (voir aussi la Section 17.1, « Compte utilisateur PostgreSQL™ »). L'emplacement du fichier de clés est indiqué grâce au paramètre de configuration krb_server_keyfile fourni à l'exécution. La valeur par défaut est /etc/srvtab, si Kerberos 4 est utilisé, et /usr/local/pgsql/etc/krb5.keytab sinon (ou tout autre répertoire indiqué comme sysconfdir à la compilation).
Le fichier de clés est engendré par le logiciel Kerberos ; voir la documentation de Kerberos pour les détails. L'exemple suivant correspond à des implantations de Kerberos 5 compatibles avec MIT :
kadmin% ank -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
Lors de la connexion à la base de données, il faut s'assurer de posséder un ticket pour le principal correspondant au nom d'utilisateur de base de données souhaité. Par exemple, pour le nom d'utilisateur fred, les deux principaux fred@EXAMPLE.COM et fred/users.exemple.com@EXAMPLE.COM peuvent être utilisés pour authentifier le serveur de bases de données.
Si mod_auth_kerb et mod_perl sont utilisés sur le serveur web Apache™, AuthType KerberosV5SaveCredentials peut être utilisé avec un script mod_perl. Cela fournit un accès sûr aux bases de données, sans demander de mot de passe supplémentaire.
La méthode d'authentification par ident fonctionne en obtenant les noms des utilisateurs du système d'exploitation, puis en déterminant les noms des utilisateurs de bases de données autorisés à l'aide d'un fichier de correspondance qui liste les paires autorisées de concordance de noms. La résolution du nom d'utilisateur du client est le point de sécurité critique. Elle fonctionne différemment selon le type de connexion.
Le « protocole d'identification » est décrit dans la RFC 1413. Théoriquement, chaque système d'exploitation de type Unix contient un serveur ident qui écoute par défaut sur le port TCP 113. La fonctionnalité basique d'un serveur ident est de répondre aux questions telles que : « Quel utilisateur a initié la connexion qui sort du port X et se connecte à mon port Y? ». Puisque PostgreSQL™ connaît X et Y dès lors qu'une connexion physique est établie, il peut interroger le serveur ident de l'hôte du client qui se connecte et peut ainsi théoriquement déterminer l'utilisateur du système d'exploitation pour n'importe quelle connexion.
Le revers de cette procédure est qu'elle dépend de l'intégrité du client : si la machine cliente est douteuse ou compromise, un attaquant peut lancer n'importe quel programme sur le port 113 et retourner un nom d'utilisateur de son choix. Cette méthode d'authentification n'est, par conséquent, appropriée que dans le cas de réseaux fermés dans lesquels chaque machine cliente est soumise à un contrôle strict et dans lesquels les administrateurs système et de bases de données opèrent en étroite collaboration. En d'autres mots, il faut pouvoir faire confiance à la machine hébergeant le serveur d'identification. Cet avertissement doit être gardé à l'esprit :
|
Le protocole d'identification n'a pas vocation à être un protocole d'autorisation ou de contrôle d'accès. |
||
| --RFC 1413 | ||
Certains serveurs ident ont une option non standard qui chiffre le nom de l'utilisateur retourné à l'aide d'une clé connue du seul administrateur de la machine dont émane la connexion. Cette option ne doit pas être employée lorsque le serveur ident est utilisé avec PostgreSQL™ car PostgreSQL™ n'a aucun moyen de déchiffré la chaîne renvoyée pour déterminer le nom réel de l'utilisateur.
Sur les systèmes qui supportent les requêtes SO_PEERCRED pour les sockets de domaine Unix (actuellement Linux, FreeBSD, NetBSD, OpenBSD et BSD/OS), l'authentification par ident peut aussi être appliquée aux connexions locales. Dans ce cas, l'utilisation de l'authentification par ident n'ajoute aucun risque de sécurité en fait, c'est même un choix préférable sur ce genre de système.
Sur les systèmes sans requête SO_PEERCRED, l'authentification par ident n'est disponible que pour les connexions TCP/IP. Pour pallier ceci, il est possible de préciser l'adresse localhost 127.0.0.1 et d'établir une connexion à cette adresse. Si le serveur ident local est digne de confiance, alors cette méthode l'est aussi.
Lorsque l'authentification par ident est utilisée, après avoir déterminé le nom de l'utilisateur du système d'exploitation qui a initié la connexion, PostgreSQL™ vérifie si cet utilisateur est autorisé à se connecter avec le nom d'utilisateur de bases de données souhaité. Ceci est contrôlé par l'argument ident map qui suit le mot clé ident dans le fichier pg_hba.conf. Il existe une correspondance d'identité prédéfinie, sameuser, qui permet à n'importe quel utilisateur du système d'exploitation de se connecter en tant qu'utilisateur de même nom au serveur de bases de données (si ce dernier existe). Les autres correspondances doivent être créées manuellement.
Les correspondances d'identité autres que sameuser sont définies dans le fichier de concordance, par défaut nommé pg_ident.conf et stocké dans le répertoire data (il est possible de placer ce fichier ailleurs ; voir le paramètre de configuration ident_file). Ce fichier contient des lignes de la forme :
nom-correspondance nomutilisateur-ident base-donnee-utilisateur
Les commentaires et les espaces sont gérés comme dans le fichier pg_hba.conf. Le nom-correspondance est un nom arbitraire utilisé pour se référer à cette correspondance dans pg_hba.conf. Les deux autres champs indiquent le nom de l'utilisateur du système d'exploitation et le nom de l'utilisateur de base avec lequel il est autorisé à se connecter. Le même nom-correspondance peut être répété pour indiquer plusieurs correspondances d'utilisateur au sein d'une même table de correspondance. Il n'y a pas de restriction sur le nombre d'utilisateurs de bases de données auxquels un utilisateur de système d'exploitation donné peut correspondre et vice-versa.
Le fichier pg_ident.conf est lu au démarrage et à chaque fois que le processus serveur principal reçoit un signal SIGHUP. Si le fichier est édité sur un système actif, il est nécessaire de signaler au serveur (à l'aide de la commande pg_ctl reload ou kill -HUP) qu'il doit relire le fichier.
L'Exemple 21.2, « Un fichier d'exemple pg_ident.conf » présente un fichier pg_ident.conf utilisable conjointement avec le fichier pg_hba.conf de l'Exemple 21.1, « Exemple d'entrées de pg_hba.conf ». Dans cette configuration, quiconque est connecté sur une machine du réseau 192.168 et n'a pas pour nom d'utilisateur Unix bryanh, ann ou robert ne peut obtenir d'accès. L'utilisateur Unix robert n'est autorisé à se connecter que sous l'utilisateur PostgreSQL™ bob et non robert ou n'importe quel autre utilisateur. ann n'est autorisée à se connecter qu'en tant que ann. L'utilisateur bryanh n'est autorisé à se connecter qu'en tant que bryanh lui-même ou guest1.
Exemple 21.2. Un fichier d'exemple pg_ident.conf
# CORRESPONDANCE NOMUTILISATEUR-IDENT NOMUTILISATEUR-PG omicron bryanh bryanh omicron ann ann # bob a le nom d'utilisateur robert sur ces machines omicron robert bob # bryanh peut aussi se connecter en tant que guest1 omicron bryanh guest1
Ce mécanisme d'authentification opère de façon similaire à password à ceci près qu'il utilise LDAP comme méthode d'authentification. LDAP n'est utilisé que pour valider les paires nom d'utilisateur/mot de passe. De ce fait, pour pouvoir utiliser LDAP comme méthode d'authentification, l'utilisateur doit préalablement exister dans la base. Le serveur et les paramètres utilisés sont indiqués après le mot clé ldap dans le fichier pg_hba.conf. Le format de ce paramètre est :
Authentification du client
ldap[s]://nom_serveur[:port]/base dn[;préfixe[;suffixe]]
Les virgules sont utilisées pour préciser plusieurs éléments dans un composant ldap. Néanmoins, comme les virgules sans guillemets sont traités comme des séparateurs d'éléments dans pg_hba.conf, il est conseillé de mettre entre guillemets doubles l'URL ldap pour préserver les virgules présentes. Par exemple :
"ldap://ldap.example.net/dc=example,dc=net;EXAMPLE\"
Si ldaps est indiqué à la place de ldap, le chiffrement TLS est activé pour la connexion. Seule la connexion entre le serveur PostgreSQL et le serveur LDAP est chiffrée. La connexion entre le client et le serveur PostgreSQL n'est pas affectée par cette configuration. Pour pouvoir utiliser le chiffrement TLS, la bibliothèque LDAP doit être configurée préalablement à la configuration de PostgreSQL™. Le chiffrement de LDAP n'est disponible que si la bibliothèque LDAP de la plateforme le supporte.
Si aucun port n'est indiqué, le port par défaut tel que configuré au niveau de la bibliothèque LDAP est utilisé.
Le serveur se lie au nom distingué indiqué comme base dn avec le nom d'utilisateur fourni par le client. Si préfixe et suffixe sont indiqués, ils sont ajoutés au nom de l'utilisateur avant la création du lien. Le paramètre préfixe est utilisé pour préciser un cn= ou un DOMAIN\ dans un environnement Active Directory.
Ce mécanisme d'authentification fonctionne de façon similaire à password à ceci près qu'il utilise PAM (Pluggable Authentication Modules) comme méthode d'authentification. Le nom du service PAM par défaut est postgresql. Le nom de service personnel peut être fourni grâce au mot clé pam du pg_hba.conf. PAM n'est utilisé que pour valider des paires nom utilisateur/mot de passe. De ce fait, avant de pouvoir utiliser PAM pour l'authentification, l'utilisateur doit préalablement exister dans la base de données. Pour plus d'informations sur PAM, merci de lire la page Linux-PAM™ et la page PAM Solaris.
Si PAM est configuré pour lire /etc/shadow, l'authentification échoue car le serveur PostgreSQL est exécuté en tant qu'utilisateur standard. Ce n'est toutefois pas un problème avec LDAP ou les autres méthodes d'authentification.