Les sous-sections suivantes décrivent les méthodes d'authentification plus en détail.
Quand l'authentification trust est spécifiée, PostgreSQL™ suppose que n'importe qui pouvant se connecter au serveur est autorisé à accéder à la base de données quel que soit le nom d'utilisateur de base de données qu'il fournisse (incluant le super-utilisateur de la base de données). Bien sûr, les restrictions apportées dans les colonnes database et user s'appliquent toujours. Cette méthode ne devrait être utilisée que s'il existe des protections au niveau système portant sur les connexions au serveur.
L'authentification trust est appropriée et très pratique lors de 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, vous pouvez utiliser trust même sur une machine multi-utilisateur, si vous restreignez l'accès au fichier socket du domaine Unix en utilisant les permissions du système de fichiers. Pour ce faire, positionnez les paramètres de configuration unix_socket_permissions (et si besoin unix_socket_group) comme décrit dans la Section 17.3, « Connexions et authentification ». Vous pouvez aussi positionner le paramètre de configuration unix_socket_directory de façon à placer le fichier de socket dans un répertoire à l'accès convenablement restreint.
Utiliser les droits du système de fichiers n'est utile que dans le cas de connexions utilisant des sockets Unix. Cela ne restreint pas les connexions TCP/IP locales ; ainsi, si vous voulez utiliser les droits du système de fichiers pour assurer la sécurité locale, supprimez la ligne host ...127.0.0.1 ... de pg_hba.conf ou changez-la - indiquer une méthode d'authentification différente de trust.
L'authentification trust n'est utile pour les connexions TCP/IP que si chaque utilisateur de chaque machine autorisée à se connecter au serveur par les lignes pg_hba.conf indiquant trust est digne de confiance. Il est rarement raisonnable d'utiliser trust pour une connexion autre que celles issues de localhost (127.0.0.1).
Les méthodes basées sur une authentification par mot de passe sont md5, crypt et password. Ces méthodes fonctionnent de façon analogue sauf pour le mode d'envoi du mot de passe au travers de 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.
Si vous êtes préoccupé par les attaques par « interception (sniffing) » de mot de passe, alors md5 est préférable, avec crypt à n'utiliser que si vous devez supporter les client pré 7.2. Le simple password devrait particulièrement être évité pour les connexions ouvertes sur l'Internet (à moins d'utiliser SSL, SSH ou d'autres systèmes de sécurité par encapsulation de connexion).
Les mots de passe de bases de données 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. Les mots de passe peuvent être gérés avec les commandes SQL CREATE USER et ALTER USER, par exemple CREATE USER foo WITH PASSWORD 'secret';. Par défaut, si aucun mot de passe n'a été indiqué, le mot de passe enregistré sera nul et l'authentification par mot de passe échouera systématiquement pour cet utilisateur.
Kerberos™ est un système d'authentification sécurisé de standard industriel destiné à l'informatique distribuée sur un réseau public. Une description du système Kerberos™ est bien au-delà des objectifs de ce document c'est généralement assez complexe (bien que puissant). La FAQ Kerberos ou la page Kerberos du MIT peuvent être un bon point de départ pour une exploration. Il existe plusieurs sources de distribution Kerberos™.
PostgreSQL™ supporte Kerberos version 5. Le support de Kerberos doit avoir été activé lors de la construction de PostgreSQL™ ; voir le Chapitre 14, Procédure d'installation 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 28.1, « Fonctions de contrôle de connexion à la base de données »). La valeur par défaut à l'installation, postgres, peut être modifié au moment de la construction en utilisant ./configure --with-krb-srvnam=quelquechose. Dans la plupart des environnements, ce paramètre n'a jamais besoin d'être modifié. Néanmoins, pour supporter plusieurs installations de PostgreSQL™ sur le même hôte, cela devient nécessaire. Quelques implémentations de Kerberos pourraient aussi réclamer un nom de service différent, comme Microsoft Active Directory qui réclame que le nom du service soit en majuscule (POSTGRES).
nom_hote est le nom de l'hôte pleinement qualifié (fully qualified host name) de la machine serveur. Le domaine principal du service est le domaine préféré du serveur.
Les principaux clients doivent avoir leur nom d'utilisateur de la base de données PostgreSQL™ comme premier composant, par exemple nomutilisateurpg/autreschoses@domaine. Actuellement, le domaine du client n'est pas vérifié par PostgreSQL™ ; ainsi si vous avez activé l'authentification "cross-realm", chaque "principal" de chaque domaine qui peut communiquer avec le vôtre sera accepté.
Assurez-vous que le fichier de clés du serveur est en lecture (et de préférence en lecture seule) pour le compte serveur PostgreSQL™ (voir aussi la Section 16.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 vous utilisez Kerberos 4 et /usr/local/pgsql/etc/krb5.keytab (ou quel que soit le répertoire spécifié par sysconfdir à la compilation).
Le fichier de clés est généré par le logiciel Kerberos ; voir la documentation de Kerberos pour les détails. L'exemple suivant corresponds à des implémentations 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, assurez-vous que vous avez un ticket pour un "principal" correspondant au nom d'utilisateur de la base de données demandé. Un exemple : pour le nom d'utilisateur de la base fred, les "principal" fred@EXAMPLE.COM et fred/users.exemple.com@EXAMPLE.COM devraient être utilisés pour authentifier le serveur de bases de données.
Si vous utilisez mod_auth_kerb et mod_perl sur votre serveur web Apache™, vous pouvez utiliser AuthType KerberosV5SaveCredentials avec un script mod_perl. Cela fournit un accès sûr aux bases de données, sans demander de mots de passe supplémentaires.
La méthode d'authentification par identification fonctionne en obtenant les noms d'utilisateurs du système d'exploitation, puis en déterminant les noms d'utilisateurs de bases de données autorisés, en utilisant un fichier de correspondance qui liste les paires d'utilisateurs correspondants. Déterminer le nom d'utilisateur du client est le point critique en matière de sécurité, et il 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 d'identification qui écoute par défaut le port TCP 113. La fonctionnalité basique d'un serveur d'identification est la réponse aux questions telles que « Quel utilisateur a initié la connexion qui sort de votre port X et se connecte à mon port Y? ». PostgreSQL™ connaissant X et Y quand une connexion physique est établie, il peut interroger le serveur d'identification de l'hôte du client qui se connecte et peut ainsi théoriquement déterminer quel est l'utilisateur du système d'exploitation pour n'importe quelle connexion.
Le défaut de cette procédure est qu'elle dépend de l'intégrité du client : si la machine client est douteuse ou compromise, un attaquant peut lancer n'importe quel programme sur le port 113 et renvoyer 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 client est soumise à un contrôle strict et dans lesquels les administrateurs du système et des bases de données opèrent en proche collaboration. En d'autres mots, vous devez pouvoir faire confiance à la machine hébergeant le serveur d'identification. Considérez cet avertissement:
|
Le protocole d'identification n'a pas vocation à être un protocole d'autorisation ou de contrôle d'accès. |
||
| --RFC 1413 | ||
Quelques serveurs ident ont une option non standard qui font que le nom de l'utilisateur est renvoyé non chiffré en utilisant une clé que seul l'administrateur de la machine d'origine connaît. Cette option ne doit pas être utilisée lors de l'utilisation du serveur ident avec PostgreSQL™ car PostgreSQL™ n'a aucun moyen de décrire la chaîne renvoyée pour déterminer le nom réel de l'utilisateur.
Sur les systèmes supportant les requêtes SO_PEERCRED pour les sockets du domaine Unix (actuellement Linux, FreeBSD, NetBSD, OpenBSD et BSD/OS), l'authentification par identification peut aussi être appliquée aux connexions locales. Dans ce cas, l'utilisation de l'authentification par identification n'ajoute aucun risque lié à la sécurité.
Sur les systèmes sans requêtes SO_PEERCRED, l'authentification par identification n'est disponible que pour les connexions TCP/IP. En complément, il est possible de préciser l'adresse localhost 127.0.0.1 et d'établir une connexion à cette adresse. Vous pouvez avoir confiance en cette méthode si vous avez confiance dans le serveur ident local.
Lorsque vous utilisez l'authentification basée sur l'identification, 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 par le nom d'utilisateur de base de données qu'il demande. 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 base de données du même nom (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 nommé par défaut pg_ident.conf et stocké par défaut dans le répertoire data (il est possible de placer le fichier de correspondance ailleurs ; voir le paramètre de configuration ident_file). Ce fichier contient des lignes de la forme suivante :
nom-correspondance nomutilisateur-ident base-donnee-utilisateur
Les commentaires et les espaces sont gérés de la façon habituelle 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 spécifient quel utilisateur du système d'exploitation est autorisé à se connecter sous quel nom d'utilisateur de base de données. Le même nom-correspondance peut être répété pour spécifier plusieurs correspondances d'utilisateurs 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 quand le processus serveur principal (postmaster) reçoit un signal SIGHUP. Si vous éditez le fichier sur un système actif, vous aurez besoin de signaler au postmaster (en utilisant pg_ctl reload ou kill -HUP) qu'il doit relire le fichier.
L'Exemple 20.2, « Un fichier d'exemple pg_ident.conf » montre un fichier pg_ident.conf pouvant être utilisé conjointement avec le fichier pg_hba.conf de l'Exemple 20.1, « Exemple d'entrées de pg_hba.conf ». Dans cette configuration d'exemple, n'importe qui connecté sur une machine du réseau 192.168 qui n'a pas de nom utilisateur Unix bryanh, ann, ou robert ne pourra obtenir d'accès. L'utilisateur Unix robert ne sera autorisé à se connecter que lorsqu'il se connecte sous l'utilisateur PostgreSQL™ bob et non robert ni n'importe qui d'autre. ann ne sera autorisée à se connecter qu'en tant que ann. L'utilisateur bryanh ne sera autorisé à se connecter qu'en tant que bryanh lui-même ou comme guest1.
Exemple 20.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
Cette méthode d'authentification fonctionne de façon similaire à password à ceci près qu'elle utilise PAM (Pluggable Authentication Modules) comme mécanisme d'authentification. Le nom du service PAM par défaut est postgresql. Vous pouvez éventuellement fournir votre nom de service grâce au mot clé pam du pg_hba.conf. PAM est seulement utilisé pour valider des paires nom utilisateur/mot de passe. Du coup, l'utilisateur doit déjà exister dans la base de données avant que PAM ne puisse être utilisé pour l'authentification. Pour plus d'informations sur PAM, merci de lire la page Linux-PAM™ et la page PAM Solaris.
Authentification du client