| Documentation PostgreSQL 7.4.29 | ||||
|---|---|---|---|---|
| Pr�c�dent | Arri�re rapide | Chapitre 19. Authentification du client | Avance rapide | Suivant |
La suite d�crit 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). 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.1. 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. 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.
Pour restreindre l'ensemble des utilisateurs autoris�s � se connecter � certaines bases de donn�es, indiquez la liste des utilisateurs dans la colonne user de pg_hba.conf, comme expliqu� dans la section pr�c�dente.
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 nomservice/nomhote@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). nomhote 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 FILE:/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/usersexemple.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 inspectant les noms d'utilisateurs du syst�me d'exploitation et 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 | ||
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.
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 que l'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 pg_ident.conf du r�pertoire data, qui 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. 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. Pour plus d'informations sur PAM, vous pouvez 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 |