| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Chapitre 19. Authentification du client | Avance rapide | Suivant |
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 16.4.2. 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. Néanmoins, crypt n'autorise pas le stockage des mots de passe cryptées dans pg_shadow.
Si vous êtes préoccupé par les attaques par << interception (sniffing) >> de mot de passe, alors md5 est préférable, avec crypt en second choix si vous devez supporter les client pré 7.2. Le simple password devrait particulièrement être évité pour les connexion sur l'Internet ouvert (à 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 la table catalogue système pg_shadow. Les mots de passes 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é fixé, 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 le projet Athena du MIT peuvent être un bon point de départ pour une exploration. Il existe plusieurs sources de distribution Kerberos.
Bien que PostgreSQL supporte Kerberos 4 et 5, seul Kerberos 5 est recommandé. Kerberos 4 est considéré peu sûr et n'est plus recommandé pour un usage classique.
Pour utiliser Kerberos, son support doit être activé au moment de la compilation. Voir le Chapitre 14 pour plus d'informations. Kerberos 4 et 5 sont supportés mais une seule version peut être activée lors d'une compilation.
PostgreSQL fonctionne comme un service Kerberos normal. Le nom du service principal est nom_service/nom_hote@domaine, où servicename est postgres (à moins qu'un nom de service différent soit sélectionné lors de la configuration avec ./configure --with-krb-srvnam=quelquechose). 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 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). L'emplacement du fichier de clés est indiqué grâce au paramètre de configuration krb_server_keyfile fourni à l'exécution. (Voir aussi Section 16.4.) Par défaut le fichier est /etc/srvtab si vous utilisez Kerberos 4 et /usr/local/pgsql/etc/krb5.keytab (ou le répertoire spécifié par sysconfdir à la compilation) avec Kerberos 5.
Pour générer le fichier keytab, utilisez par exemple (avec la version 5) :
kadmin% ank -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
Lisez la documentation Kerberos pour les détails.
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é. Exemple : pour le nom d'utilisateur de la base fred, les "principal" fred@EXAMPLE.COM et fred/users.exemple.com@EXAMPLE.COM peuvent être utilisés pour authentifier le serveur de bases de données.
Si vous utilisez mod_auth_kerb de http://modauthkerb.sf.net 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é crypté 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 réel nom 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 de correspondance d'identité, qui est nommé par défaut pg_ident.conf et qui est 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 map-name est un nom arbitraire qui sera 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 19-2 montre un fichier pg_ident.conf pouvant être utilisé conjointement avec le fichier pg_hba.conf de l'Exemple 19-1. 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 pourrait obtenir d'accès. L'utilisateur Unix robert ne serait autorisé à se connecter que lorsqu'il se connecte sous l'utilisateur PostgreSQL bob et non robert ni n'importe qui d'autre. ann ne serait autorisée à se connecter qu'en tant que ann. L'utilisateur bryanh ne serait autorisé à se connecter qu'en tant que bryanh lui-même ou comme 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.
| Précédent | Sommaire | Suivant |
| Authentification du client | Niveau supérieur | Problèmes d'authentification |